Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Опишите наблюдаемую проблему
Дежурный получает сигнал о росте ошибок входа. У него нет времени читать историю создания сервиса. Начало runbook должно отвечать на три вопроса: когда применять документ, как подтвердить симптом и какие действия запрещены без дополнительного согласования. В нашем примере проверяются доля ошибок, затронутые пользователи и состояние зависимого провайдера идентификации. Не вставляйте в документ реальные токены доступа. Укажите ссылку на принятую систему хранения секретов и необходимую роль. Сама структура runbook ниже является практической рекомендацией для эксплуатации; Confluence предоставляет средства публикации и организации содержимого.
Разведите диагностику и изменения
Сначала перечислите проверки, которые не меняют состояние системы: доступность страницы входа, последние изменения конфигурации, характер ошибок в журнале. У каждого шага укажите ожидаемое наблюдение и следующий переход. Например, проблема только у одного пользователя ведёт к проверке его прав, а массовый отказ после развёртывания — к анализу релиза. Не советуйте перезапускать все компоненты первым действием. Это может стереть полезные признаки и увеличить влияние. Для команды, которая действительно изменяет состояние, укажите последствия, условия выполнения и способ проверки. Не смешивайте команды разных сред в одном копируемом блоке.
Зафиксируйте границы полномочий
Дежурный должен понимать, когда он вправе применить временный обход и когда обязан передать управление. В инструкции укажите роли, канал эскалации, резервный контакт и условие привлечения безопасности. Контакты конкретных людей быстро устаревают, поэтому основной маршрут лучше привязать к действующему расписанию или группе. Проверьте, что новая смена имеет доступ к самой странице и связанным диагностическим материалам. Закрытые подробности архитектуры можно вынести в отдельный раздел с нужными ограничениями, но критичный маршрут эскалации должен оставаться доступным всем участникам реагирования. Права проверяются под реальной ролью дежурного.
Определите критерий восстановления
Исчезновение одной ошибки не означает завершение инцидента. Для сценария входа задайте несколько наблюдений: успешная авторизация тестового пользователя, возвращение показателей к согласованной норме и отсутствие повторного роста в течение выбранного окна. Конкретные пороги команда устанавливает по своему сервису, а не копирует из чужой статьи. Если применялся временный обход, укажите срок его отмены и отдельную задачу на постоянное исправление. При откате релиза проверьте совместимость данных и зависимостей по эксплуатационному регламенту. Confluence хранит инструкцию, но не гарантирует безопасность команд, которые в неё вставил автор.
Проведите учебный прогон
Соберите дежурного, наблюдателя и владельца сервиса. На тестовой среде смоделируйте отказ зависимости или разберите запись прошлого инцидента без вмешательства в production. Дежурный должен пройти документ без подсказок, объясняя свои выводы. Наблюдатель отмечает непонятные термины, недоступные ссылки и отсутствующие права. После упражнения исправьте развилки, а не просто добавьте ещё одну страницу общего текста. Проверьте, что команды можно безопасно скопировать и что они не содержат скрытых значений от старого окружения. Время до правильного решения важнее числа страниц в базе эксплуатации.
Обновляйте по итогам реального опыта
После инцидента внесите только проверенные изменения: новый симптом, дополнительную проверку или уточнённое условие остановки. Для обычных страниц Confluence история версий помогает видеть изменения и восстанавливать текст. Отмечайте дату практического прогона и владельца runbook. Не превращайте документ в полный отчёт об инциденте: подробный разбор разместите отдельно и свяжите ссылкой. Если новая процедура не прошла упражнение, сохраните рабочую предыдущую последовательность и продолжайте проверку в тестовой среде. Раз в согласованный период пересматривайте маршруты эскалации, доступ и зависимости. Именно они часто меняются раньше основных диагностических шагов.
Карточка решения дежурного
Для каждой развилки runbook удобно подготовить короткую карточку: наблюдение, вывод, допустимое действие и условие прекращения. В сценарии ошибок входа первое наблюдение может звучать как «ошибка воспроизводится для нескольких тестовых пользователей из разных сетей». Вывод при этом остаётся ограниченным: проблема шире одной учётной записи, но причина ещё не установлена. Не делайте скачок сразу к перезапуску провайдера идентификации. Следующий шаг должен проверить конкретную гипотезу и сохранить полезные свидетельства. На учебном разборе попросите дежурного объяснить, почему альтернативная ветка сейчас не подходит. Это выявляет скрытые предположения лучше, чем механическое чтение списка команд. После упражнения добавьте в runbook только необходимое уточнение. Если каждое обсуждение увеличивает документ на несколько страниц, вынесите справочные сведения отдельно и оставьте в аварийном маршруте короткие решения.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу