Регламент реагирования на сбой сайта: роли, действия и шаблон журнала
Регламент реагирования на сбои сайта определяет, кто принимает сообщение о проблеме, кто руководит восстановлением, какие действия разрешены и как подтверждается результат. Он нужен, чтобы после тревоги команда сразу переходила к согласованной работе: проверяла влияние на пользователей, привлекала нужного специалиста и фиксировала изменения.
Без такого порядка даже небольшая неисправность может затянуться. Владелец пишет разработчику, маркетолог обращается к хостеру, подрядчик перезапускает приложение, а другой специалист одновременно меняет настройки. Каждый действует с полезной целью, но общей картины нет.
Ниже — практическая структура для сайта услуг, магазина или небольшого веб-сервиса. Здесь есть шаблон регламента, форма журнала и учебная хронология. Все сроки в примерах являются условной политикой команды: их нужно согласовать с реальными часами поддержки, критичностью операций и возможностями подрядчиков.
Когда обычную ошибку нужно объявлять инцидентом
Инцидент стоит определять через нарушенное действие и необходимость согласованного вмешательства. Например, посетители не могут оформить заказ, заявки перестали поступать менеджерам или существенная часть страниц недоступна. Наличие одного технического предупреждения ещё не описывает масштаб проблемы, но требует предусмотренной первичной проверки.
В главе Google SRE об incident response заранее определённая структура помогает разделить восстановление сервиса и координацию участников. Для своего сайта переведите этот принцип в наблюдаемые условия: какое действие нарушено, кто затронут и когда необходим общий процесс реагирования.
| Условная категория | Пример влияния | Организация реакции |
|---|---|---|
| Критический сбой | Ключевое действие массово недоступно, рабочего обходного пути нет | Сразу назначить координатора и вызвать ответственного исполнителя |
| Существенная деградация | Часть пользователей или важная функция работает с нарушениями | Оценить охват, подключить владельца функции, определить приоритет |
| Локальная неисправность | Ограниченный дефект с допустимым обходным решением | Назначить задачу и срок; повысить уровень при расширении влияния |
Это пример классификации, а не универсальная шкала. Для одного бизнеса невозможность скачать документ критична, для другого допустима временная задержка. Укажите условия повышения категории: рост числа затронутых операций, отсутствие прогресса, потеря обходного решения или необходимость подключить другую команду.
Не требуйте сначала доказать первопричину. Можно объявить инцидент с формулировкой «отправка формы не завершается, причина выясняется». Подтверждение влияния и точное объяснение причины — разные результаты работы.
Какие роли нужны и можно ли совмещать их
Для небольшого проекта достаточно распределить три функции: координацию, техническое выполнение и коммуникацию. Важны не названия должностей, а конкретные ответственные в текущем инциденте. Владелец бизнеса может координировать работу, пока разработчик восстанавливает приложение, а менеджер сообщает пользователям согласованную информацию.
Модель ролей PagerDuty допускает совмещение функций с учётом масштаба происшествия. При этом управление состоянием инцидента, техническое устранение и общение с заинтересованными сторонами различаются. Это полезный ориентир для распределения нагрузки, а не требование создавать большой штаб.
| Роль | Ответственность | Что должно быть видно остальным |
|---|---|---|
| Координатор | Приоритет, задачи участников, согласование действий, эскалация и решение о завершении | Кто сейчас управляет работой и когда следующее обновление |
| Технический исполнитель | Проверки, оценка вариантов восстановления, выполнение разрешённых изменений | Что делает, какого результата ждёт и когда его проверит |
| Ответственный за связь и журнал | Значимые события, сообщения сотрудникам и пользователям | Актуальное влияние и подтверждённые действия без противоречий |
Если один человек закрывает несколько функций, это должно быть записано. При подключении второго специалиста полезно передать ему часть нагрузки явно. Фраза «все смотрят проблему» не заменяет владельца решения и не определяет, кто вправе менять рабочую систему.
Что делать после первого сообщения о сбое
Первый ответственный должен подтвердить приём сигнала, собрать минимальные факты и определить необходимость объявления инцидента. Это короткий этап, который не должен превращаться в длительную самостоятельную диагностику без связи с остальными.
- Зафиксировать сигнал. Время с часовым поясом, URL, источник и ожидаемое действие.
- Проверить влияние. Подтвердить проблему разрешённым способом, определить известный охват и ограничения проверки.
- Назначить координатора. Записать его имя и канал связи.
- Открыть карточку инцидента. Присвоить номер, указать категорию и текущий статус.
- Подключить исполнителя. Передать факты и получить подтверждение принятия задачи.
- Объявить следующий шаг. Кто выполняет проверку, что ожидается и когда будет обновление.
Минимальная карточка не требует длинного описания. Достаточно: «Форма расчёта не выдаёт подтверждение, проблема воспроизводится на двух тестовых отправках, начало влияния уточняется». Если известен только момент обнаружения, не выдавайте его за точное время начала сбоя.
Если первичную проверку нельзя выполнить из-за отсутствия доступа или инструментов, запишите это ограничение и привлеките того, кто может её провести. Не превращайте невозможность проверки в вывод «проблемы нет». При нескольких независимых сообщениях о нарушении важной функции допустимо начать координацию, одновременно уточняя фактический охват.
В инструкции PagerDuty для работы во время инцидента роли и общий канал объявляются явно, а действия распределяются между специалистами. На своём проекте заранее разместите контакты и ссылки на рабочие инструкции там, где их можно открыть даже при недоступности основного сайта.
Как передать проблему подрядчику и не потерять ответственность
Отправленное сообщение ещё не означает, что подрядчик начал работу. В регламенте нужны основной и резервный контакты, доступные часы поддержки, способ срочного вызова и срок ожидания подтверждения. Эти условия должны соответствовать существующим договорённостям, а не появляться только во время аварии.
Обращение содержит номер инцидента, проверенный симптом, затронутое действие, время, известные изменения и ссылку на журнал. Укажите, какую помощь ждёте: проверку конкретной системы, оценку отката или восстановление компонента. Пароли и секретные ключи передавайте только через предусмотренный для этого способ доступа, а не внутри общего описания.
Подтверждение должно быть предметным: кто принял задачу, что проверяет и когда сообщит результат. Если ответа нет в согласованный интервал, координатор обращается к резервному контакту или владельцу услуги. Пока другой человек явно не принял функцию, ответственность за координацию остаётся у назначенного координатора.
Если задачу приняли, но пропустили согласованное время обновления, координатор запрашивает текущий статус и при отсутствии связи использует следующий контакт из регламента. Новому исполнителю передают сведения об активных действиях, чтобы он не начал конфликтующее изменение.
Если участвуют несколько подрядчиков, не оставляйте им задачу «разберитесь между собой» без общего состояния. Разделите участки, назначьте конкретные проверки и собирайте результаты в одном журнале. Это помогает избежать взаимного ожидания, когда хостер ждёт разработчика, а разработчик — хостера.
Отдельно опишите реакцию вне рабочего времени. Если круглосуточного дежурства нет, сам факт доставки сообщения в мессенджер его не создаёт. Владелец должен понимать, какие действия доступны ночью, кому разрешено применять заранее подготовленную меру и когда подключается специалист. Для критичного сайта эту схему согласуют до запуска рекламной кампании или значимого мероприятия.
Какие действия разрешить заранее и как согласовывать откат
Во время сбоя команда должна иметь возможность выполнить предусмотренные меры без поиска случайного согласующего. Заранее определите допустимые действия, исполнителей и границы полномочий. Например, остановка дальнейшего развёртывания и возврат известной совместимой конфигурации могут иметь разные правила, чем изменение данных или отключение важной функции.
У каждой процедуры восстановления нужны условия применения, ожидаемый эффект и способ проверить результат. Для отката укажите известную предыдущую версию, совместимость с текущими данными, затронутые компоненты и поведение незавершённых операций. Само слово «откат» не гарантирует обратимость: после изменения схемы данных простой возврат кода может быть неподходящим.
Перед действием исполнитель кратко сообщает: «Предлагаю вернуть конфигурацию версии А; затронута отправка формы; ожидаю восстановление приёма; проверка — тестовая заявка с подтверждённым результатом». Координатор фиксирует решение в пределах своих полномочий. Если действие требует другого владельца, его подключают по заранее указанному маршруту.
Несколько специалистов могут параллельно собирать данные, но изменения одной системы должны быть согласованы. Записывайте начало, результат и условия остановки каждого вмешательства. Если проверка не подтвердила ожидаемый эффект, это тоже полезный результат: следующий участник не будет повторять ту же попытку вслепую.
Как вести один журнал значимых действий
Журнал нужен прежде всего текущей команде. Он позволяет новому участнику понять влияние, уже выполненные проверки, активные изменения и ближайший шаг. Не требуется записывать каждую реплику или копировать полные технические логи.
| Поле записи | Что указывать |
|---|---|
| Время и часовой пояс | Когда произошло событие; позднее внесённую запись помечать отдельно |
| Автор и роль | Кто наблюдал событие или выполнял действие |
| Тип записи | Факт, гипотеза, решение, действие, результат или передача ответственности |
| Содержание | Конкретный симптом, изменение, согласование или проверка |
| Подтверждение | Ссылка на измерение, номер проверки или краткий наблюдаемый результат |
| Следующий шаг | Ответственный, ожидаемый результат и время обновления |
Разделяйте факты и предположения. «Ошибки начались после обновления конфигурации» — наблюдаемая временная связь. «Конфигурация вызвала сбой» — вывод, для которого нужны дополнительные основания. Такая маркировка помогает не привязать всю команду к первой правдоподобной версии.
В верхней части карточки держите актуальное состояние, ниже — хронологию. Исправляйте неточные сведения новой записью или явным пояснением, сохраняя понимание, что было известно на каждом этапе. Для длинного инцидента краткое текущее резюме полезнее перечитывания сотен сообщений.
Как передавать смену или роль координатора
При затянувшейся работе передача ответственности должна быть отдельным событием. Уходящий участник сообщает текущее влияние, проверенные факты, активные действия, ограничения, ожидаемые ответы и следующее время обновления. Принимающий подтверждает, что понял состояние и берёт функцию.
В руководстве Google SRE по управлению инцидентами подчёркивается явная передача координации с подтверждением принимающей стороны. Сообщение «я написал коллеге» не обеспечивает непрерывного управления. После подтверждения команда должна знать, кто стал новым координатором.
Рабочая формулировка для своего регламента: «В 14:20 UTC роль координатора передана Марии; Мария подтвердила принятие. Форма восстановлена, идёт наблюдение; подрядчик проверяет накопленные обращения; следующий статус в 14:30». Это авторский пример записи, который показывает и нового владельца, и незавершённую работу.
Тот же принцип применим к отдельной технической задаче. Передайте не только ссылку на чат, но и последний подтверждённый результат, уже выполненные изменения и состояние текущей попытки. Так смена специалиста не превращается в повторный старт расследования.
Что сообщать сотрудникам и пользователям
Внутреннему участнику нужны детали для следующего действия, а пользователю — понятное влияние и доступный вариант поведения. Назначьте человека, который собирает подтверждённую информацию и публикует согласованные обновления. Техническому исполнителю не должно приходиться отвечать на одинаковые вопросы в нескольких чатах.
Рекомендации PagerDuty по внешней коммуникации предлагают заранее определить условия публикации и шаблоны для разных стадий. Для своего сайта укажите затронутую функцию, известный охват и время следующего сообщения. Частоту обновлений выбирайте по значимости и длительности сбоя.
Авторский пример первого статуса: «Наблюдаем затруднения при отправке заявок с сайта. Специалист проверяет проблему. Пока можно обратиться по указанному на странице телефону. Следующее обновление — в 12:30 по московскому времени». Используйте обходной путь только тогда, когда он действительно работает и может принять обращения.
Не обещайте время восстановления без основания. Если срок неизвестен, сообщайте время следующего обновления и текущий этап. После изменения влияния обновляйте статус вне расписания. Сообщение о восстановлении должно опираться на выполненные проверки; наличие оставшихся задержек описывайте отдельно.
Компактный шаблон регламента реагирования
Ниже — заготовка, которую можно заполнить для конкретного сайта и разместить рядом с контактами поддержки. Поля в квадратных скобках заменяют фактическими данными. Технические процедуры лучше хранить по отдельным ссылкам, чтобы общий регламент оставался коротким и применимым к разным сбоям.
| Раздел | Что записать в регламент |
|---|---|
| Область действия | [Домен], [ключевые операции], [окружение], [часы поддержки] |
| Условия объявления | [Наблюдаемые признаки], [категории влияния], [кто может объявить инцидент] |
| Приём сигнала | [Основной контакт], [резерв], [способ вызова], [срок подтверждения] |
| Координация | [Основной координатор], [замена], [порядок подтверждённой передачи] |
| Исполнение | [Владелец приложения], [хостинг], [интеграции], [доступные часы и контакты] |
| Общий канал | [Чат или звонок], [резервный способ связи], [место актуального состояния] |
| Журнал | [Шаблон карточки], [ответственный], [часовой пояс], [допустимые сведения] |
| Первые действия | Подтвердить влияние, назначить роли, открыть карточку, вызвать исполнителя, объявить следующий шаг |
| Эскалация | [Кого вызвать при отсутствии ответа], [действия при пропуске согласованного обновления], [когда подключать дополнительного специалиста] |
| Полномочия | [Предварительно разрешённые процедуры], [кто согласует остальные изменения], [условия остановки] |
| Коммуникация | [Кто готовит и публикует статус], [аудитории], [интервал обновлений] |
| Восстановление | [Проверяемые операции], [подтверждение результата], [срок наблюдения], [контроль накопленного] |
| Завершение | [Кто объявляет], [как учитываются остаточные ограничения], [кому передаются следующие задачи] |
Для конкретной аварийной процедуры добавьте карточку: условие запуска, необходимые доступы, последовательность действий, ожидаемый результат, проверку и откат самой меры. Например, инструкция возврата конфигурации должна ссылаться на реальные версии и команды проекта. Общий шаблон не должен подменять технические сведения выдуманными универсальными командами.
Пример журнала: форма перестала принимать заявки
Рассмотрим учебный сбой без утверждений о реальном проекте. Команда использует UTC, для этого сценария заранее согласовала десятиминутное наблюдение после восстановления и назначила координатора. Времена ниже показывают порядок действий, а не норматив скорости работы.
| Время | Событие и решение | Ответственный и результат |
|---|---|---|
| 11:02 | Внешняя проверка обнаружила отсутствие ожидаемого подтверждения формы | Дежурный сохранил URL и время сигнала |
| 11:04 | Контролируемая проверка подтвердила нарушение отправки | Создан инцидент DEMO-115, назначен координатор |
| 11:07 | Подрядчик подтвердил принятие задачи | Исполнитель проверяет приложение; следующее обновление согласовано |
| 11:10 | Найдена временная связь с изменением конфигурации | Записана гипотеза; первопричина ещё не объявлена |
| 11:12 | Согласован возврат совместимой конфигурации по готовой процедуре | Указаны исполнитель и проверка результата |
| 11:15 | Исполнитель завершил возврат конфигурации | Другие изменения приложения пока не выполняются |
| 11:18 | Проверены отправка, подтверждение и появление тестовой заявки | Начато согласованное наблюдение, проверяется судьба обращений периода сбоя |
| 11:28 | Проверки устойчивы; обращения периода сбоя сверены, необработанного остатка не найдено | Координатор завершил инцидент и передал оставшиеся технические задачи |
В этой хронологии восстановление не приравнено к завершению команды отката. Между изменением и закрытием есть проверка пользовательского результата и отдельная сверка возможного остатка. Если бы накопленные обращения ещё требовали обработки, их состояние пришлось бы явно отразить в решении о дальнейшей работе.
По каким признакам завершать инцидент
Заранее определите, что означает восстановление каждой ключевой операции. Для формы это не только открывшаяся страница, но и подтверждённый приём контролируемого обращения. Для магазина могут понадобиться проверка заказа и состояние связанных процессов в пределах согласованного сценария.
- Нарушенное действие снова проходит предусмотренную проверку.
- Результат подтверждён подходящими внешними и внутренними данными.
- В течение выбранного периода наблюдения нет повторения проблемы.
- Накопленные или неопределённые операции проверены либо переданы конкретному владельцу с явным статусом.
- Временные изменения и оставшиеся ограничения записаны.
- Сотрудники и пользователи получили соответствующее обновление.
Время восстановления функции, окончания наблюдения и закрытия карточки может различаться. Сохраняйте эти отметки отдельно. Не нужно удерживать аварийный созвон ради несрочной доработки, но нельзя сообщать о полном восстановлении, пока существенное влияние сохраняется.
Оставшимся задачам назначают владельцев и сроки. Журнал сохраняют для дальнейшего анализа; подробное исследование причин проводится отдельно и не должно мешать подтверждению текущего состояния сервиса.
Как проверить, что регламент действительно работает
Проведите настольное упражнение без вмешательства в рабочий сайт. Участник получает условный сигнал, находит контакт, объявляет категорию, открывает карточку и передаёт задачу. Затем добавьте осложнение: основной специалист недоступен или требуется смена координатора.
Проверьте, доступны ли документы, понятны ли полномочия и может ли новый участник продолжить работу по журналу. Если для каждого шага требуется устное пояснение автора, исправьте соответствующий пункт. После смены подрядчика, контактов или инфраструктуры актуализируйте затронутые разделы и назначьте владельца документа.
Результатом упражнения должен быть короткий список обнаруженных пробелов с ответственными. Например: резервный контакт не отвечает, инструкция хранится на недоступном сервере, право на откат не определено. Исправление таких конкретных препятствий делает следующий вызов заметно понятнее для всей команды.
Как связать уведомления с готовым процессом
Мониторинг приносит больше пользы, когда у каждого важного сигнала есть ответственный, проверяемое действие и понятная эскалация. Сначала договоритесь, что команда делает после уведомления, затем проверьте этот путь на контролируемом примере.
Внешний контроль HTTP-доступности через SiteGuard дополнит ваш регламент. Проверку влияния, эскалацию и подтверждение восстановления закрепите за командой.