Гарантии доступности в SLA: ставьте цели, которые команда реально поддержит

Что идёт не так, когда обещают доступность слишком рано

Проблемы обычно начинаются задолго до того, как кто‑то ставит себе цель их вызвать. Отдел продаж хочет цифру, которую примет покупатель. Юристы стремятся к знакомой формулировке. Закупки просят более высокий порог, потому что так кажется безопаснее. Потом операционные команды читают черновик и понимают, что никто не проверял, сможет ли команда реально отслеживать, измерять и поддерживать это обещание.

Так обязательство по доступности превращается в ежедневный стресс. Строка вроде "99.95% доступности" звучит невесомо на встрече. На бумаге это кажется близким к 99.9%. На практике это оставляет гораздо меньше пространства для сбоев, увеличивает давление на ночные ответы и сокращает окно для планового обслуживания.

Для двух человек в команде этот разрыв проявляется быстро. Если оповещения приходят в 2:00 ночи, контракт не принимает во внимание, что один человек в отпуске, а другой уже занят деплойментами, поддержкой и вопросами от поставщиков. Цель, которая казалась безобидной при согласовании закупками, может тихо превратиться в постоянную ночную и уикенд‑работу.

Нагрузка на отчётность тоже часто упускается. Одна расплывчатая фраза про доступность, исключения или реакцию на инциденты может заставить кого‑то составлять ручные отчёты каждый месяц. В итоге люди вытаскивают логи из разных инструментов, спорят о том, что считать простоем, и по пунктам объясняют разрывы заказчику. Это ничего не улучшает в продукте — только съедает время.

Бизнес‑последствия просты. Чрезмерные обещания увеличивают расходы на поддержку, отвлекают инженеров от поставки функционала и повышают вероятность запросов на возврат средств или споров по контракту. Это также может заставить маленькую компанию раньше заплатить за мониторинг, систему оповещений и резервные решения.

Более безопасный подход прост и немного скучен. Обещайте то, что ваша команда может измерить сегодня, поддерживать при текущем составе и отчитывать без ручной сборки данных. Цифру всегда можно повысить позже. Отзывать уже подписанное обещание гораздо сложнее.

Что на самом деле означает доступность в вашем контракте

Большинство споров начинается с одной расплывчатой фразы. В контракте написано "99.9% доступности", но никто не согласовал, что считать доступным, что — простоем и кто обязан реагировать.

Первое различие очень важно. Доступность — это не то же самое, что время реакции или время восстановления. Доступность отвечает на простой вопрос: могли ли пользователи пользоваться сервисом? Время реакции — как быстро команда начинает работать над инцидентом. Время восстановления — сколько потребуется, чтобы вернуть сервис в норму. Если смешать эти понятия, вы создадите обещание, которое команда не сможет чисто отслеживать.

В контракте также должно быть чётко указано, какой именно сервис покрывается, а не вся компания. Если у вас есть портал для клиентов, API и внутренний админ‑инструмент, скажите — какой из них покрывает SLA. Обещание на весь бизнес выглядит аккуратно в черновике, но втягивает системы, которыми клиенты могут никогда не пользоваться, и которые команда не мониторит одинаково.

Потом определите, что такое простой. Полный отказ очевиден. Частичная неисправность — там начинаются споры. Если вход в систему не работает у 40% пользователей или платежи падают, а главная страница всё ещё загружается — считается ли это простоем? Запишите это до того, как юристы и закупщики расширят формулировку.

Небольшой блок определений обычно экономит недели согласований:

• Покрываемый сервис: названный продукт, API или набор клиентских функций
• Доступность: работает ли этот покрываемый сервис для пользователей в период измерения
• Реакция на инцидент: как быстро команда подтверждает проблему и начинает работу
• Восстановление: когда сервис возвращается к нормальному использованию
• Исключения: события, которые не считаются уменьшением доступности

Окна обслуживания требуют той же ясности. Если вы патчите системы каждое воскресенье в 02:00, укажите, исключается ли это время из расчёта. Если обслуживание может повлиять на клиентов, требуйте уведомления и задайте лимит. Без ясности рутинная работа на бумаге может выглядеть как нарушение.

Чистое определение SLA специально скучно. И это хорошо: скучная формулировка легче в исполнении, чем обещание, о котором команда будет спорить каждый месяц.

Сопоставьте обещанное покрытие с реальным

Многие обязательства по доступности терпят неудачу по простой причине: в контракте предполагается, что кто‑то всегда наготове, а команда не укомплектована таким образом. Прежде чем соглашаться на цель, зафиксируйте, кто реально следит за сервисом и кто может действовать при сбое.

Начните с рабочих часов. Привяжите реальные имена к обработке оповещений, а не общие названия команды. Если оповещения приходят в общий почтовый ящик или в шумный чат, считайте это слабым каналом. Один человек должен быть ответственным за первичный ответ в рабочее время, и кто‑то ещё должен подменять его, когда тот в совещании, в отпуске или загружен другой задачей.

Поддержка вне рабочего времени обычно вскрывает разрыв. Многие маленькие команды хорошо поддерживают продукт с 9:00 до 18:00, но у них нет реальной ротации на вечера, выходные или праздники. Это нормально, если контракт это отражает.

Задайте четыре прямых вопроса. В рабочее время кто получает первичное оповещение? Вне рабочего времени кто проверяет и отвечает? На выходных и праздниках кто может зайти в систему и исправить проблему? Если первый человек пропустил оповещение, кто берёт на себя ответственность?

Небольшой стартап с двумя инженерами может думать, что он обеспечивает круглосуточную поддержку, потому что оба основателя держат телефоны под рукой. Это обычно разваливается через несколько недель. Люди спят, путешествуют, болеют или пропускают уведомления. Контракты должны соответствовать тому составу команды, который у вас есть сейчас, а не тому, которого вы надеетесь нанять.

Проверьте скорость на каждом этапе. Сколько времени уходит на то, чтобы команда увидела оповещение, подтвердила, что это реальная проблема, и эскалировала её тому, кто может исправить? Это отдельные действия. Если оповещения приходят мгновенно, но никто их не просматривает 45 минут после полуночи, ваше реальное окно поддержки медленнее, чем кажется из черновика.

Запишите это в простой таблице для будних дней, ночей, выходных и праздников. Сравнив обещанное покрытие и фактический состав, слабые места становятся очевидны. Вы можете обнаружить, что сегодня можете поддерживать крепкое SLA в рабочие часы и добавить послерабочее покрытие позже. Это гораздо безопаснее, чем подписываться на круглосуточную поддержку, которую команда не выдержит.

Проверьте, что вы можете измерить сегодня

Ваш SLA должен опираться на системы, которые команда использует каждую неделю. Если число берётся из скриншотов, памяти или таблицы, которую кто‑то обновляет вручную, обещание рухнет, как только клиент попросит доказательства.

Перечислите точные инструменты, которые сегодня показывают доступность. Для кого‑то это внешний мониторинг. Для других — cloud health checks, отчёт балансировщика нагрузки или дашборд Prometheus и Grafana. Если вы также используете Sentry, логи и тикеты инцидентов, отметьте это. Нужен один ясный источник правды для числа доступности и одно простое правило расчёта.

Потом проследите, где хранятся доказательства. Логи могут быть в одном месте, история оповещений — в другом, а заметки по инцидентам — в чате. Это нормально, но становится проблемой, когда закупки просят месячные отчёты или сервисные кредиты. Вы должны знать, где лежат сырые логи, где — история оповещений, и где кто‑то фиксирует простои, плановое обслуживание и статус‑обновления.

Несколько проверок выявляют большинство слабых мест. Какой инструмент выдаёт официальный показатель доступности? Где команда может посмотреть историю оповещений за весь месяц? Где хранится хронология инцидентов и записи об обслуживании? Может ли кто‑то экспортировать данные в месячный отчёт без ручной чистки?

Если любой ответ расплывчат, метрика не готова к контрактной формулировке.

Месячный экспорт важнее, чем команды думают. Метрика полезна только если её можно выгрузить в конце месяца, объяснить, как она была посчитана, и повторить тем же методом в следующем месяце. Если одному человеку приходится штопать данные с дашбордов, чата и тикетов, процесс сломается под давлением.

Откажитесь от любой метрики, которую нельзя измерять одинаково каждый раз. Не обещайте порог ухудшения производительности, если вы его не отслеживаете. Не обещайте время реакции по степеням серьёзности, если степень не фиксируется в единой системе. Жёсткая формулировка хороша в черновике, но немеряемые обещания превращаются в еженедельные споры.

Меньшее обещание с чистыми доказательствами лучше, чем амбициозная цель, которую никто не сможет отстоять.

Устанавливайте цель шаг за шагом

Начинайте с фактов, а не с амбиций. Если ваш сервис держался в пределах 99.6%–99.8% последние несколько месяцев, не обещайте 99.95% только потому, что это звучит лучше в черновике. Большинство плохих SLA появляются из описания сервиса, который вы хотите иметь, а не из того, который у вас есть сейчас.

Сначала выберите одну ясную границу. Выберите ту часть, на которую клиенты реально полагаются — публичное приложение или API — и не включайте внутренние инструменты, админ‑панели и сторонние аддоны, если вы не можете мониторить их так же. Одна граница сохраняет честность показателя и уменьшает вероятность спора.

Дальше выберите один метод измерения и придерживайтесь его. Внешние проверки каждую минуту легко объяснить. Смешение внутренних логов, заявок в поддержку и ручного суждения обычно приводит к спорам в конце месяца.

Простой процесс работает лучше. Посмотрите реальную доступность за последние 3–6 месяцев. Выберите одну границу сервиса и опишите её простыми словами. Используйте один источник правды для измерения. Подберите цель, исходя из укомплектованности, настроек отказоустойчивости и часов поддержки. И убедитесь, что кто‑то может ежемесячно отчитываться без импровизаций.

Штат важнее, чем многие команды признают. Маленькая команда с поддержкой только в рабочие часы должна быть осторожна с очень высокими целями. Если никто не смотрит оповещения в 2:00 ночи, контракт не должен молча предполагать круглосуточный ответ.

Добавьте правила по обслуживанию, прежде чем закупки превратят их в расплывчатый юридический текст. Скажите, когда можно проводить плановое обслуживание, сколько уведомления вы даёте и учитывается ли это время в доступности. Ясно укажите исключения, например проблемы с интернетом на стороне клиента или сбои у третьей стороны, которую вы не контролируете.

Один быстрый тест помогает. Попросите команду посчитать показатель доступности за прошлый месяц тем методом, который описан в черновике. Если инженерия, поддержка и финансы получают разные результаты, цель ещё не готова.

Реалистичная первая цель часто лучше впечатляющей, но нереальной. Если сейчас сервис держится на 99.7%, вы можете пообещать 99.5% для публичного API, исключив плановое обслуживание, и поднять цифру позже после улучшения резервирования и покрытия поддержки.

Пропишите жёсткие грани ясно

Расплывчатый SLA выглядит вежливо в черновике и болезненно в реальной жизни. Если поддержка работает только по будням, скажите это прямо. Пропишите часы в фиксированной временной зоне, например UTC, и добавьте локальное время клиента в скобках, если нужно.

Эта мелочь избегает распространённого конфликта. Клиент читает "рабочие часы" как свои рабочие часы. Ваша команда читает их как свои. Контракт должен убрать этот разрыв до подписания.

Плановое обслуживание требует той же конкретики. Укажите, когда вы можете его проводить, сколько уведомления даёте и учитывается ли это время в расчёте доступности. Если окно обслуживания — воскресенье 02:00–04:00 UTC, запишите именно это.

Нужны также чёткие грани по инцидентам вне вашего контроля. Если клиент испортил собственную конфигурацию, изменил DNS, отключил интеграцию или проигнорировал требование безопасности — это не ваш простой. То же самое касается сбоев у внешних поставщиков, когда ваш сервис по‑прежнему работает в рамках своего дизайна.

Большинство команд закрывают это четырьмя короткими пунктами: часы поддержки и окна реакции, уведомление и время для планового обслуживания, исключённые причины простоев и метод расчёта сервисных кредитов с понятным лимитом.

Сервисные кредиты должны соответствовать размеру сделки. Небольшие контракты не должны нести открытые штрафы. Простая таблица кредитов, привязанная к месячной плате, проще в управлении и легче защищается в закупках.

Например: если клиент платит $3,000 в месяц, разумен кредит, ограниченный частью этой месячной платы. Обещания о широких возвратах, дополнительной работе и штрафных выплатах поверх кредитов — это путь, по которому обязательство по доступности превращается в неподъёмную нагрузку для команды.

Простые формулировки помогают. Напишите "мы отвечаем в течение 4 рабочих часов" вместо "будут предприняты коммерчески разумные усилия". Напишите "простой не включает некорректную конфигурацию клиента" вместо абзаца, приглашающего дебаты.

Если один инженер покрывает внерабочие оповещения, не позволяйте закупкам превратить это в формулировку, будто у вас полностью укомплектованный круглосуточный операционный стол. Контракт должен описывать команду, какая у вас есть, а не ту, которую кто‑то вообразил.

Простой пример до того, как закупки перепишут черновик

Стартап продаёт одно хостированное приложение и в раннем черновике ставит "99.95% доступности". На бумаге это выглядит разумно. На практике это позволяет примерно 22 минуты простоя в месяц — что мало для маленькой команды с одной ротацией on‑call и без полноценного стола поддержки.

Потом закупки присылают правки. Они хотят, чтобы сервисные кредиты начинали начисляться раньше, расширяют определение простоя и требуют более быстрой реакции. Вдруг обещание, которое выглядело простым, становится ежедневным операционным риском.

Первая проблема — область охвата. Закупки могут попытаться считать простоями почти всё: медленные страницы, сломанные сторонние интеграции, проблемы в сети клиента, плановое обслуживание и админ‑инструменты, которыми конечные пользователи никогда не пользуются. Если команда примет такую формулировку, она берёт на себя ответственность за системы, которые не полностью контролирует.

Поэтому команда сужает черновик. Они определяют доступность как доступность production‑приложения, измеряемую мониторингом с публичного интернета. Они исключают плановое обслуживание, бета‑фичи, проблемы на стороне клиента и сбои у третьих сторон за пределами их границы системы. Они также разделяют серьёзность инцидента и часы поддержки.

Это даёт версию, которую реально поддерживать:

• 99.95% применимо только к production‑хостированному приложению
• Доступность измеряется ежемесячно по проверкам команды мониторинга
• Плановое обслуживание не считается, если команда дала уведомление
• За простоем считается только полный или крупный отказ сервиса
• Критические инциденты покрываются круглосуточной ротацией on‑call, обычная поддержка — в рабочее время

Они также корректируют кредиты. Вместо триггера по каждой короткой вспышке, кредиты начисляются только когда месячная доступность опускается заметно ниже целевой. Это даёт команде пространство управлять кратковременными инцидентами без превращения каждого события в спор по контракту.

Итоговый черновик менее эффектен, но намного безопаснее. Отдел продаж всё ещё может предложить сильную цель. Операции могут её мониторить, поддерживать и объяснять. Юристы получают чище сформулированный текст. Это лучшее положение до того, как закупки начнут настаивать на условиях, которые команда не сможет выполнить.

Ошибки, которые превращают обещание в ежедневную боль

Плохой SLA часто начинается с одного упрощения. Кто‑то копирует текст у крупного поставщика, меняет название компании и думает, что остальное как‑то уладится. Не уладится. Команда из 200 человек может обещать то, что команда из пяти человек не выдержит, не выгорев.

Ситуация усугубляется, когда в черновике смешиваются коммерческая речь отдела продаж, юридические правки и оптимистичные предположения операций. Контракт звучит чисто, но люди, которые будут его выполнять, знают, что он построен на домыслах.

Большая часть проблем повторяется. Команды копируют enterprise‑тексты SLA, не проверяя, кто будет отвечать на оповещения, владеть инцидентами и утверждать исключения. Они обещают круглосуточную поддержку, потому что этого ждёт клиент, хотя на деле никто не находится на дежурстве 24/7. Они включают сторонние сервисы в цель доступности, даже когда не контролируют их. Смешивают доступность, время реакции и время восстановления в одном расплывчатом обещании. И забывают, что финансам нужен чёткий способ считать сервисные кредиты.

Типичная ловушка выглядит так: контракт обещает 99.95% доступности, круглосуточную реакцию и кредиты за любой простой свыше 15 минут. У компании есть один дневной инженер, базовый мониторинг и несколько внешних зависимостей. Это не амбициозная цель — это ловушка.

Перед тем как закупки начнут править черновик, сопоставьте каждое обещание с одним простым вопросом: кто будет это мониторить, кто будет поддерживать и как вы измерите это в плохой день? Если никто не может ответить на все три, формулировка требует изменений.

Быстрые проверки перед отправкой контракта

Отправляйте черновик только после того, как протестировали обещание на реальных операциях. Именно там обещание по доступности перестаёт быть строкой продаж и становится обязанностью on‑call.

Начните с обнаружения. Если мониторинг требует 20 минут, чтобы зафиксировать простой, линия реакции в 5 минут бессмысленна. Команда должна знать, как быстро она сегодня может заметить реальную проблему с текущими инструментами, а не с инструментами, которые планируется добавить.

Потом проверьте подтверждение оповещений. В контракте может стоять "15 минут", но кому‑то всё равно нужно увидеть пейдж, подтвердить проблему и начать работу. Если ночи, выходные или праздники зависят от одного уставшего инженера, корректируйте обещание или ограничьте окно поддержки.

Небольшое несоответствие между финансами и операциями быстро приносит проблемы. Кредиты выглядят просто, пока обе стороны не начнут считать по разным формулам. Одна команда может считать частичный отказ простоем, другая — исключать его. Согласуйте точную математику заранее.

Ваш месячный отчёт тоже важен. Если вы не можете получить чистый отчёт о доступности из текущего стека мониторинга, контракт опережает процесс. Нужен один источник правды, чёткий отчётный период и простой способ объяснить окна обслуживания, исключённые события и инциденты, затронувшие только часть сервиса.

Короткая внутренняя проверка ловит большинство проблем:

• Сколько минут нужно, чтобы обнаружить реальный простой?
• Кто отвечает вечерами, по выходным и в праздники?
• Могут ли финансы и операции одинаково посчитать пример кредита?
• Можете ли вы выгрузить пример ежемесячного отчёта из текущих данных?
• Обещаете ли вы что‑то, что команда не сможет поддерживать ежемесячно?

Эта проверка скучна, но экономит много боли. Если нужно ещё одно мнение, внештатный CTO может прогнать формулировки через мониторинг, штат и процесс инцидентов до того, как закупки превратят свободный черновик в жёсткое обязательство.

Следующие шаги перед подписью

Контракт становится дорогим, когда обещание на бумаге выглядит ясно, а в повседневной работе рушится. Прежде чем подписывать, покажите последний черновик людям, которые будут его выполнять: операционным, поддержке, финансам и юристам. Каждая группа увидит разные риски, и слабые места обычно проявляются быстро.

Операции должны подтвердить, что команда может мониторить сервис, кто получает оповещения и как инцидент идёт от обнаружения к реакции. Поддержка — проверить часы покрытия, пути эскалации и кто отвечает по ночам, в выходные и праздники. Финансы — просмотреть сервисные кредиты, риск штрафов и реальную стоимость расширенного покрытия. Юристы — убедиться, что формулировка соответствует тому, что команда реально способна сделать.

Будьте строги с цифрами. Если цель доступности зависит от инструмента, которого у вас нет, удалите её или перепишите. Обещание, основанное на будущих наймах, планах по мониторингу или дашборде, который вы собираетесь построить позже, — это всё ещё догадка.

То же относится и к отчётности. Если контракт требует, чтобы вы измеряли простои, исключения, времена реакции или сбои третьих сторон определённым способом, убедитесь, что вы можете сгенерировать такой отчёт сегодня. Если не можете — контракт опережает операции.

Полезно сделать ещё один прогон. Можете ли вы измерить доступность текущими инструментами? Может ли команда поддерживать заявленные часы каждую неделю? Соответствуют ли сервисные кредиты масштабу сделки? Соответствует ли язык реальному процессу эскалации? Не покажется ли обещание трагикомичным в ваш самый загруженный месяц?

Если команда уже перегружена, остановитесь и возьмите второе мнение перед подписью. На oleg.is Oleg Sotnikov просматривает условия SLA, настройки мониторинга и покрытие поддержки с практической операционной точки зрения — именно такой обзор помогает обнаружить проблемы на ранней стадии.

Лучший черновик обычно простой. Он соответствует штату, инструментам и часам поддержки, которые у вас есть сейчас. Даже если это значит предложить меньшую гарантию сегодня, это всё равно лучше, чем подписать большую, которую команда будет защищать каждый месяц.