В SLA поддержки стоит обещать срок восстановления, а не часы работы агента

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

Часы нужны, но у них разный смысл. Срок до восстановления можно задать в часах; количество часов, потраченных исполнителем, не показывает, сколько бизнес простоял.

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

Форматы и цены сопровождения без своей команды разобраны отдельно. Здесь выбираем то, что подрядчик должен измерить и показать после сбоя.

Быстрый ответ означает, что проблему приняли в работу. Автоматическое «заявка зарегистрирована» не подтверждает, что инженер увидел остановку бизнеса.

Восстановление означает, что согласованный рабочий путь снова действует. Иногда его возвращает откат последней правки; постоянное исправление готовят после.

Устранение причины защищает от повторения сбоя. В руководстве Atlassian аварийный ответ заканчивается после прекращения влияния на бизнес, а разбор и оставшиеся работы идут дальше.

Кто принимает рискованную правку и отвечает за ошибки агента, разбираем в соседней статье. Ускорение написания кода не снимает ни проверку, ни ответственность.

Приоритет зависит от последствий сбоя. Недоступная кнопка оплаты и съехавшая подпись могут быть одинаково маленькими правками, но требуют разного порядка работы.

Для каждого уровня нужен узнаваемый признак. «Всё срочно» не помогает выбрать, какой путь восстанавливать первым.

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

Агенту можно поручить поиск причины и черновик исправления. Приоритет определяют потери бизнеса, а не сложность задачи для модели.

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

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

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

Срок обычной доработки считают по потоку и очереди задач. У аварии дополнительно есть простой бизнеса, который очередь не должна скрывать.

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

Успешный ответ сервера проверяет только часть пути. Google SRE отдельно описывает наблюдение снаружи: оно ловит симптомы, которых внутренние проверки не видят.

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

В приёмке нужна проверка исходной поломки и последующее наблюдение. «Тесты прошли» не закрывает инцидент, если сломавшийся путь тестом не проверялся.

На странице подписки 7 октября 2026 стоит обещание «Задача в среднем за 48 часов». Слово «в среднем» не задаёт предельный срок устранения отдельной аварии.

Там же описан поток: одна задача в работе, следующая ждёт. Из такого порядка нельзя вывести правило «авария немедленно прерывает очередь».

На открытой странице машины измерена другая работа: 115 задач своего сайта, срез 27 августа 2026. Это история доставки задач от реплики до мержа, а не журнал аварий клиента.

Если путь должен работать ночью, обсуждайте дежурство отдельно. В нашу подписку ночные дежурства не входят.

Автоматический запуск агента не заменяет дежурного. Кто-то должен разрешить рискованный шаг и подтвердить восстановление.

Пауза тоже требует передачи ответственности. Если разработку остановили, кто-то должен продолжать принимать сигналы о работающем продукте.

Начните с пути, остановку которого бизнес не может терпеть. Подрядчик должен показать, как узнает о сбое, кому передаст сигнал и чем подтвердит восстановление.

Вместо запроса «дайте хороший SLA» принесите описание последствий. Сможет ли компания принимать заявки вручную, ждать рабочего окна или откатить последнее изменение?

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

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

1. Часы труда и время простоя отвечают на разные вопросы. В поддержке выберите срок возвращения рабочего пути.
2. Разделите ответ, восстановление и устранение причины. Назовите результат каждого этапа.
3. Согласуйте событие начала, календарь и паузы. Полный простой бизнеса оставьте видимым отдельно.
4. Принимайте ремонт по исходной поломке. Вместе с починкой проверьте наблюдение против повтора.
5. Для ночной работы назовите дежурного заранее. Средний срок обычной задачи не обещает аварийного режима.