Как был устроен oncall, в нашей команде в Amazon

Все разработчики нашей команды по очереди выполняют саппорт наших компонентов. Дежурство длится 1 неделю и повторяется примерно каждые 1,5–2 месяца. Таким образом, за год приходится дежурить до 8 раз (то есть 2 месяца из 12 посвящены поддержке).

Ops Review
Дежурство начинается с митинга под названием Ops Review, на котором вся команда разработчиков собирается вместе. Предыдущий oncall рассказывает, какие тикеты были закрыты на прошлой неделе, какие остаются открытыми, а также делится тем, что было сделано для улучшения ситуации с тикетами. Во время митинга открываются основные дашборды и метрики, чтобы убедиться, что всё в порядке.
Отдельно мы трекаем тикеты, которые повторяются часто, и добавляем их в список задач для поиска долгосрочных решений. Цель — сделать так, чтобы подобные тикеты либо не появлялись вообще, либо возникали реже.

Тикеты
Наши компоненты генерируют огромное количество различных метрик. Код эмитирует эти метрики в специальную внутреннюю систему, похожую на AWS CloudWatch (иногда мы использовали и её). Это могут быть как бизнесовые, так и операционные метрики. Для их мониторинга у нас были созданы дашборды и, что особенно важно, настроены алармы.
В определённых условиях, если метрика отклоняется от ожидаемого поведения, автоматически создаётся тикет, который попадает в ticket queue текущего oncall. В описании тикета указана причина его создания, метрика, которая вызвала срабатывание, и runbook — инструкция, что делать в этой ситуации. Однако иногда runbook отсутствует, и тогда приходится самостоятельно разбираться и искать root cause.
Помимо стандартных тикетов, система может создавать инциденты (sev) с разными уровнями приоритетов. Например:
Sev 0 — упал критически важный компонент, затрагивающий всю компанию. Это обычно становится очевидно не только нам, но и СМИ.
Sev 1 — отказ критического компонента для конкретной функциональности и т.д.
Как только создаётся инцидент (sev), текущего oncall не только уведомляют тикетом, но и пейджат. Это значит, что рабочий телефон начинает орать, и oncall обязан принять пейджинг в течение нескольких минут — даже если это случилось ночью. Если кнопку принятия не нажать, пейджер переадресует вызов на вашего менеджера, затем на менеджера вашего менеджера и так далее, вплоть до CTO или CEO компании, если это sev 0.
При работе над sev вначале важно митигировать проблему, а не искать и устранять root cause. Нужно очень быстро сделать rollback, рестарт, восстановление из бэкапа, выключить какую-то функциональность и т.д. Как только митигация сделана, на следующий день уже можно заняться рук козом.
Если над sev вам нужно работать в том числе и ночью, то над обычными тикетами вы можете работать только днем. Вы можете искать их причины, устранять их. Иногда алармы слишком чувствительны и нужно изменить их настройки, чтобы он не срабатывал без существенной причины. Иногда алармы часто повторяются и вы можете придумать решение, которое это предотвратит.
Тикеты могут быть созданы автоматически по метрикам или исключениям, которые бросает код. Но также их можно создать руками. Если другие команды что-то от вас хотят в плане поддержки они могут руками создать тикет.