Первое дежурство DevOps: чек-лист до смены, первые пять минут после алерта и когда будить старшего

На первом дежурстве от вас не ждут, что вы в одиночку почините всё. Ждут другого: быстро подтвердить алерт, понять, насколько всё плохо, снять влияние на пользователей по runbook или позвать того, кто знает систему лучше, — и всё это время писать в канал, что происходит.

Остальное — подготовка. Доступы, оповещения, runbook и контакты для эскалации проверяются днём, до смены. Тогда в три часа ночи вы не будете искать пароль от VPN, а просто пройдёте по короткому списку. Ниже — этот список, собранный по открытым практикам Google SRE и PagerDuty.

Что от вас на самом деле ждут

В руководстве PagerDuty для дежурных есть раздел о том, что в обязанности дежурного не входит. Никто не ждёт, что вы первым подтвердите каждый алерт: для этого есть backup и эскалация. И никто не ждёт, что вы всё почините сами: владельцы сервисов знают свои системы лучше, и позвать их — нормально. Девиз оттуда же — «Never hesitate to escalate», никогда не стесняйтесь эскалировать.

В книге Google SRE три главные опоры дежурного — понятные пути эскалации, описанный процесс работы с инцидентами и разборы без поиска виноватых. Если в вашей команде есть все три, первое дежурство куда менее страшное, чем кажется. Если какой-то нет — спросите о ней до смены. Как вообще устроены дежурства, — в статье что такое on-call.

Чек-лист до смены

Если смену приходится менять из-за поездки или визита к врачу, договоритесь о подмене заранее, — PagerDuty прямо включает это в подготовку. А если в команде есть практика «тени», попроситесь сначала подежурить вместе с опытным коллегой: PagerDuty рекомендует новичкам первые недели получать все алерты и просто следить, что делает основной дежурный.

Первые 5 минут после алерта

1. Подтвердите алерт. Это сигнал, что им занимаются, и он останавливает эскалацию. Во многих командах на это есть около 5 минут, потом алерт уходит следующему.
2. Прочитайте алерт целиком. Какой сервис, какой симптом, с какого времени, есть ли ссылка на runbook и дашборд.
3. Оцените влияние. Страдают ли пользователи, какая их доля, растёт ли проблема. От этого зависит severity и то, надо ли будить людей.
4. Проверьте, что менялось. Недавний релиз, правка конфигурации, плановые работы, рост трафика — самые частые причины, и руководство PagerDuty начинает разбор именно с них.
5. Напишите в канал. Первое сообщение — сразу, даже если вы ещё ничего не знаете.
6. Решите: чинить самому по runbook или эскалировать. Если runbook есть и понятен — действуйте по нему. Если нет — зовите.

Прежде чем что-то менять, убедитесь, что вы там, где думаете:

hostname                          # тот ли сервер
kubectl config current-context    # тот ли кластер
kubectl get pods -n orders        # тот ли namespace и что с подами

Ночь, усталость и чужой терминал — ровно та обстановка, в которой инженер GitLab в 2017 году удалил каталог базы на основном сервере вместо реплики. Разбор — в статье сбой GitLab 2017.

Как писать в канал инцидента

Канал — это журнал инцидента и способ не отвечать каждому по отдельности. В книге Google чат называют бесценным журналом: по нему потом восстанавливают, кто что делал и когда. Хорошее сообщение отвечает на четыре вопроса: что видим, какое влияние, что делаем, когда следующее обновление.

Первое сообщение:

[03:14] Взял алерт OrdersApiErrors: с 03:05 около 7% запросов к orders-api отвечают 5xx.
Влияние: часть заказов не оформляется. В 02:50 был релиз orders-api 2.9, проверяю его.
Следующее обновление — в 03:30.

Обновление:

[03:32] Откатили orders-api на 2.8, доля ошибок снижается: 7% → 0,4%.
Причину пока не знаем. Наблюдаем 15 минут, следующее обновление — в 03:50.

Закрытие:

[03:52] Решено. Ошибки на обычном уровне с 03:35, влияние на пользователей — 03:05–03:35.
Релиз 2.9 заблокирован до разбора. Постмортем — до пятницы.

Несколько правил:

• время у каждого сообщения и факты вместо догадок: «не знаем» — нормальный ответ;
• о действии пишите до того, как его сделать: «перезапускаю orders-api на prod-app-03» — чтобы двое не сделали одно и то же;
• обновления по расписанию, даже если новостей нет: в PagerDuty сводку для руководства дают примерно раз в 30 минут, коротко и по делу;
• обсуждение — в одном месте: в канале инцидента, а не в личных сообщениях.

Когда будить старшего

Будить — нормально. Ошибка «разбудил зря» стоит человеку полчаса сна, ошибка «не разбудил» может стоить часов простоя. В руководстве PagerDuty про координатора инцидента сказано прямо: лучше вызвать его и не понадобиться, чем наоборот.

В книге Google событие считают инцидентом, если верно хотя бы одно:

• для исправления нужна вторая команда;
• сбой видят клиенты;
• проблема не решена даже после часа сосредоточенного анализа.

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

• runbook не покрывает ситуацию или вы не понимаете, что происходит;
• нужное действие необратимо: удаление данных, переключение базы, массовый перезапуск;
• надо трогать систему другой команды;
• есть признаки проблемы с безопасностью или утечки данных;
• вы чувствуете, что паникуете. Это прямой совет из книги Google: если накрывает паника или вы перегружены, просите поддержку.

Как не наломать дров

• Сначала снять влияние, потом искать причину. Порядок из книги Google: остановить ущерб, восстановить сервис, сохранить улики для разбора.
• Откат вместо исправления наугад. Если проблема началась после релиза, первое действие в руководстве PagerDuty — откатить его.
• Сохранить улики до перезапуска. Логи, kubectl describe, дампы: после перезапуска их уже не будет, и на разборе останется только гадать.
• Одно изменение за раз и объявлять его в канале. Google описывает антипаттерн «фриланс»: инженер с лучшими намерениями меняет систему, ни с кем не согласовав, и делает хуже.
• Необратимое — только вдвоём. rm -rf, DROP, переключение базы, git push --force в общую ветку — с второй парой глаз и лучше по runbook.
• Не отключать алерт, чтобы не мешал. Если проблема правда не срочная, отложите алерт до утра и заведите задачу. Пример из PagerDuty: диск заполняется, но места ещё много и тренд спокойный — это работа на день, а не на ночь. Как такие случаи разбирать днём, — в статье закончилось место на диске.

После смены

• Передайте смену: что осталось нерешённым, что «мигало», за чем следить. PagerDuty считает это обязанностью уходящего дежурного.
• Если информацию было трудно найти — допишите runbook, пока помните.
• Если был инцидент — нужен разбор: как писать постмортем и почему он должен быть blameless.
• Если за ночь было много ложных алертов, вынесите это на обсуждение: шумные алерты — задача команды, а не испытание для дежурного.

В симуляторе DevOps KAI Lab первое дежурство — стажёрское, в первом месяце работы в вымышленной компании Qoima. Алерты приходят пачкой, и нужно решить, что горит, что подождёт до утра и кого звать. Всего за год таких дежурств девять, и после каждого — постмортем. Проверить, как вы рассуждаете в рабочих ситуациях, можно в бесплатном тесте навыков DevOps: 18 ситуаций, 10–15 минут, без регистрации.

Частые вопросы

Что делать, если пришёл алерт, а я не знаю, как чинить? Подтвердить алерт, оценить влияние, написать в канал, что видите, и эскалировать по цепочке. Незнание системы на первом дежурстве — нормальная причина позвать владельца сервиса.

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

Сколько ждать перед эскалацией? Договоритесь с командой заранее. В книге Google SRE крайний срок — час сосредоточенного анализа без результата; на первых дежурствах порог разумно поставить ниже.

Что писать в канал инцидента? Время, что видим, какое влияние, что делаем и когда следующее обновление. О каждом изменении в системе — до того, как его сделать.

Как подготовиться к первому дежурству? Проверить доступы и оповещения днём, прочитать runbook к частым алертам, узнать цепочку эскалации и попросить передачу смены у предыдущего дежурного. Если можно — сначала подежурить «тенью» рядом с опытным коллегой.

Источники

• PagerDuty Incident Response. Being On-Call — подготовка, что не входит в обязанности, «Never hesitate to escalate», тень для новичков, передача смены.
• PagerDuty Incident Response. During an Incident — первые действия, откат релиза, сбор данных до перезапуска, обновления для руководства.
• Google. Site Reliability Engineering, глава 11 «Being On-Call» — опоры дежурного: эскалация, процесс, разборы без виноватых.
• Google. Site Reliability Engineering, глава 14 «Managing Incidents» — когда объявлять инцидент, «фриланс», чат как журнал, лучшие практики.
• GitLab. Postmortem of database outage of January 31, 10.02.2017.