Когда меняется ответственный за приложение, недостаточно передать список задач или отправить ссылки в чат. Тому, кто принимает дежурство, нужно понимать, какой сервис затронут, какие решения ещё не приняты, что можно сделать и как подтвердить, что вмешательство помогло. Без этого контекста команда тратит время на восстановление хронологии, может повторить уже выполненные действия или оставить риски без внимания.
Передача технического дежурства по PHP-приложениям должна представлять собой актуальное операционное резюме, ориентированное на следующее действие. Она не заменяет систему учёта инцидентов, систему управления задачами или runbook’и, а связывает эти ресурсы и объясняет, как ими пользоваться в период ответственности нового дежурного.
Определите, за что отвечает принимающий дежурство
Прежде чем согласовать формат, определите, какие решения дежурный вправе принимать самостоятельно, а в каких ситуациях нужно передать вопрос другой функции или команде. В обязанности могут входить мониторинг алертов, первичная диагностика, обратимые меры по снижению воздействия и координация восстановления. Для деструктивных изменений, миграций данных или решений о внешних коммуникациях может потребоваться явное разрешение.
В передаче нужно как минимум указать пять пунктов: затронутый сервис, текущее состояние, известное влияние, ответственного за следующее действие и критерий проверки результата. Если чего-то из этого не хватает, принимающий дежурство может знать о проблеме, но не понимать, как действовать дальше.
Также стоит договориться, когда обновлять документ, какой часовой пояс использует команда и по какому каналу объявлять чрезвычайную ситуацию. Время последнего обновления данных имеет значение: метрика или статус инцидента без временной отметки могут побудить действовать исходя из ситуации, которая уже разрешилась.
Фиксируйте инциденты и задачи без дублирования отслеживания
Запись о передаче дежурства не должна превращаться в ещё одну очередь задач. Ведите каждый инцидент в уже используемой для этого системе, а в резюме указывайте его идентификатор, ссылку, статус и следующий шаг. Так вы избежите расхождений между двумя копиями, когда кто-то обновит одну и забудет про другую.
Для открытого инцидента кратко зафиксируйте факты, необходимые для продолжения работы:
- Сервис и окружение: PHP-приложение, затронутый компонент и место возникновения проблемы: production, staging или другое окружение.
- Наблюдаемое влияние: нарушенная функциональность, известные затронутые пользователи и масштаб, который ещё не удалось подтвердить.
- Состояние и хронология: примерное время начала, значимые изменения и время последней проверки с указанием часового пояса.
- Выполненные действия: что изменили и какой результат наблюдали; отделяйте факты от гипотез.
- Следующее действие и ответственный: конкретная задача, ответственное лицо или роль и время проверки.
- Эскалация: условие, при котором нужно уведомить другого человека или команду.
Для незавершённых задач, не связанных с инцидентами, может быть достаточно тикета. Включайте их в передачу, только если они влияют на принимающего дежурство, например если срок выполнения приходится на его смену или задача ограничивает операционное вмешательство.
Связывайте runbook’и с условиями применения и проверками
Ссылка на runbook не объясняет, когда им пользоваться и какого результата ожидать. Добавьте фразу с описанием сигнала, при котором следует запустить процедуру, и ограничений её применения. Например: «Использовать, если проверки работоспособности в production завершаются ошибкой; не перезапускать процесс, пока не выяснено, выполняется ли миграция». Указания должны соответствовать реальной системе команды, а не предположениям.
В процедуре следует указать необходимые разрешения, шаги диагностики, безопасное действие, способ проверить восстановление и порядок эскалации, если проверка не пройдена. Для PHP-приложения это могут быть ссылки на логи ошибок, состояние процессов, метрики, очереди или внешние зависимости — при условии, что такие сигналы существуют и доступны дежурному.
Если инструкция зависит от конкретной конфигурации, версии или инфраструктуры, задокументируйте это ограничение. Не включайте в передачу учётные данные и секреты: вместо этого укажите разрешённые способы получения доступа. Устаревший runbook или процедура, требующая отсутствующих у всех разрешений, — это риск, а не помощь.
Явно указывайте риски, зависимости и ограничения восстановления
Фиксируйте известные риски, которые могут повлиять на ответные действия: деградацию зависимости, приостановленную задачу по расписанию, временное решение или недавнее изменение, за которым ещё наблюдают. Для каждого риска укажите сигнал, который его подтвердит, и соответствующее действие. Если причина не доказана, обозначьте её как гипотезу; не выдавайте корреляцию за окончательный диагноз.
Необходимо также чётко обозначить ограничения восстановления. Какие действия обратимы? Какая операция может повлиять на данные? Проверено ли восстановление из резервной копии или существует только политика резервного копирования? Кто разрешает восстановление или изменение конфигурации? Различение задокументированной возможности и проверенной на практике возможности помогает не создавать ложную уверенность.
Если система состоит из нескольких компонентов, укажите зависимости и контактные команды, добавив соответствующие внутренние ссылки. Не предполагайте, что принимающий дежурство знает, объясняется ли наблюдаемый симптом сбоем внешнего API, базы данных или очереди.
Используйте краткий шаблон и проверьте, помогает ли он действовать
Шаблон должен быть достаточно кратким, чтобы его можно было поддерживать в актуальном состоянии в течение смены, и достаточно точным, чтобы он помогал принимать решения. Условный пример может иллюстрировать формат, но для каждого сервиса значения нужно заполнять на основе наблюдаемых данных.
Сервис и окружение: [приложение / компонент / окружение] Период дежурства: [начало и конец с указанием часового пояса] Текущее состояние: [норма / деградация / открытый инцидент] Наблюдаемое влияние: [факты и известный масштаб] Инциденты: [идентификатор, статус и ссылка] Последняя проверка: [время, сигнал и результат] Выполненные действия: [изменения и наблюдаемый результат] Следующее действие: [конкретный шаг, ответственный и срок] Риски или гипотезы: [сигнал, ограничение и способ их различить] Применимый runbook: [ссылка и условие применения] Эскалация: [кому и при каком условии] Ожидающие решения: [решение, ответственный и дата пересмотра]
Например, команда может отметить, что алерт по очереди остаётся активным, дать ссылку на существующий инцидент и поручить принимающей роли проверить динамику. Нужно указать время последнего наблюдения и порог или сигнал, который подтвердит нормализацию ситуации. Копировать каждое событие из тикета не нужно: важно зафиксировать исходное состояние и следующую проверку.
Проверьте передачу с точки зрения принимающего дежурство
Полный документ ещё не означает, что им удобно пользоваться. Практическая проверка заключается в том, может ли принимающий объяснить текущее состояние, найти актуальный источник информации, определить первое действие и понять, как проверить результат, не полагаясь на память передающего дежурство. Если приходится снова и снова уточнять одно и то же, формат или runbook не решает эту задачу.
Периодически проверяйте записи о передаче: ищите пустые поля, неработающие ссылки, неоднозначно указанных ответственных и инструкции, которые никто не проверял. После инцидента добавляйте полученные знания в runbook или соответствующий процесс, а не превращайте каждую передачу в трудный для поиска архив.
Итоговый критерий — операционная пригодность: информация отделяет факты от гипотез, указывает, насколько она актуальна, назначает следующее действие и определяет порядок эскалации и проверки. Так смена дежурного сохраняет контекст, не создавая параллельную систему документации или отслеживания.
