← вся теориятеория к собесу · SRE и надёжность

Инциденты и постмортемы

Инциденты и разбор после

Время недоступности складывается из трёх кусков: сколько шли до обнаружения, сколько разбирались и сколько чинили. При цели 99,9% весь месячный бюджет ошибок - то есть разрешённое время неуспеха - составляет 43 минуты. Значит, авария, о которой узнали через двадцать минут из жалобы пользователя, уже съела половину бюджета, ещё не начав чиниться.

Стержень: сначала вернуть работу, потом искать причину; разбор после - про механику, а не про виноватых.

// Формулировки: «что делаете первым делом в аварии?», «зачем постмортем?», «как сокращать время восстановления?»

Сначала вернуть работу

В аварии есть два разных занятия, и их путают. Митигация - вернуть сервис в рабочее состояние любым доступным способом. Расследование - понять, почему сломалось. Правильный порядок жёсткий: сначала митигация, расследование потом, по логам и данным, собранным по ходу.

Способы митигации обычно известны заранее и их немного: откатить последнюю выкатку, увести трафик на другую площадку, отключить сломавшуюся функцию флагом (переключателем, который гасит её без выпуска новой версии), увеличить ресурс, включить упрощённый режим. Заметь, что все они не требуют понимания причины. Именно поэтому первый вопрос в аварии - не «почему», а «что мы можем сделать прямо сейчас».

// Отсюда практика: держать список действий митигации написанным заранее и проверенным. И держать откат по-настоящему рабочим - выкатка, которую ни разу не откатывали, откатывается не с первого раза. Отдельно стоит запретить себе «сейчас быстро посмотрю в логи»: это ровно то, что превращает пять минут простоя в сорок.

митигация: вернуть работу любым способом, не разбираясь в причине
расследование: поиск причины; делается после возвращения работы

Роли и связь во время аварии

Когда в чат сбегается десять человек, начинается второй инцидент - организационный. Поэтому роли распределяют заранее. Ведущий инцидента не чинит руками: он держит картину, принимает решения и следит за временем. Тот, кто чинит, занят руками и не общается наружу. Отдельный человек ведёт хронику - что сделали и когда - и отвечает на вопросы бизнеса.

Хроника важнее, чем кажется. Без неё через два дня никто не восстановит порядок событий, а именно порядок и объясняет, что чему причина. Пишется она по ходу, в общем канале, простыми строчками со временем.

// Отдельно про объявление аварии. Порог должен быть низким: объявить и через десять минут закрыть - нормально, а вот «полчаса ковырялись, потому что казалось, само пройдёт» - типичный способ потратить весь бюджет. Заведите один явный критерий, при котором объявляют автоматически, например «затронуто больше N пользователей» или «горит симптомный алерт дольше пяти минут».

ведущий инцидента: держит картину и принимает решения; руками не чинит
хроника: запись действий со временем, ведётся по ходу аварии

Разбор после и почему без виноватых

Разбор после аварии нужен ровно для одного - чтобы этот класс аварий больше не повторился. Отсюда и формат: хроника событий, влияние в числах (сколько минут, сколько пользователей, сколько бюджета ошибок), что сработало, что нет, и список действий с ответственными и сроками.

Правило «без поиска виноватых» - не про вежливость, а про качество данных. Если за ошибку наказывают, люди перестают рассказывать детали, и разбор превращается в художественное произведение. А без деталей нельзя найти настоящую причину. Формулировка «инженер выкатил плохой конфиг» бесполезна; полезна «конфиг выкатывается без проверки, а откат занимает 20 минут».

// Хороший тест качества разбора: содержит ли он действия, которые сработали бы, даже если бы человек ошибся ровно так же. Проверка конфига перед применением, выпуск сначала на малую долю трафика, автоматический откат по метрикам - это защита от класса ошибок. «Быть внимательнее» - не защита ни от чего.

разбор после: документ с хроникой, влиянием в числах и действиями со сроками
без поиска виноватых: условие честного рассказа о деталях, без которого причину не найти

Как отвечать: «Прод лежит. Ваши действия?»

Первым делом объявляю инцидент, чтобы включились роли и началась хроника, - порог для объявления у меня низкий, закрыть через десять минут не стыдно. Дальше не ищу причину, а возвращаю работу: смотрю, что менялось за последний час, и откатываю последнюю выкатку; если не помогло - увожу трафик, отключаю флагом сломавшуюся функцию, включаю упрощённый режим. Все эти действия не требуют понимания причины, и в этом их ценность. Параллельно кто-то один пишет хронику со временем, а я держу связь наружу, чтобы чинящий не отвлекался. Причину разбираю после, когда работа вернулась, по собранным логам и метрикам. И считаю влияние в числах: сколько минут, сколько пользователей, сколько бюджета ошибок съедено. Это же число потом обосновывает работу по надёжности.

Ответ показывает правильный порядок, называет конкретные способы вернуть работу и заканчивается измерением влияния. Про хронику и роли вспоминают те, кто дежурил не один раз.

На чём валятся

−Начинают с расследования и держат прод лежащим, пока ищут причину.
−Не объявляют инцидент, пока не станет очевидно: полчаса уходит в бюджет ошибок.
−Чинящий одновременно отвечает на вопросы бизнеса и не чинит.
−Не ведут хронику и через два дня не могут восстановить порядок событий.
−Пишут в разборе «быть внимательнее» вместо защиты от класса ошибок.

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 7, остальные разбираются в тренажёре.

#dvo_incidents1 / 5
Что делает постмортем полезным, а не ритуальным?
A)Разбор системных причин и задачи с владельцами и сроками
B)Точное указание, чья ошибка привела к сбою
C)Подробная хронология с точностью до секунды
D)Вывод о том, что нужно больше тестировать перед релизом
показать ответ и разбор
+A)Разбор системных причин и задачи с владельцами и сроками
// разбор: Ценность разбора — в изменениях, которые он порождает: почему систему вообще можно было сломать таким действием, почему сломалось незаметно, почему чинили полчаса. Отсюда задачи с ответственными и сроками, попадающие в обычный бэклог. Поиск виноватого даёт обратный эффект: люди перестают рассказывать детали, и следующая авария приходит той же дорогой, но уже без предупреждений.
#dvo_incidents2 / 5
Инженер в одиночку молча копает упавший прод уже полчаса. Что он упускает по процессу инцидента?
A)Ничего: главное — быстрее найти и починить причину
B)Сначала написать подробный постмортем, потом чинить
C)Объявить инцидент и вести коммуникацию о статусе
D)Дождаться, пока проблему заметят пользователи сами
показать ответ и разбор
+C)Объявить инцидент и вести коммуникацию о статусе
// разбор: Даже если человек компетентен, молчаливый разбор в одиночку — процессная ошибка: об инциденте надо объявить (поднять по процессу) и вести коммуникацию — статус для затронутых команд, поддержки, руководства, обновления на статус-странице. Это подключает нужных людей, снимает дубли усилий и даёт бизнесу принимать решения. Технический разбор и коммуникация идут параллельно, а не «сначала починю, потом расскажу».
#dvo_incidents3 / 5
Постмортемы в команде свелись к поиску, «кто накосячил». Чем это вредит и как надо?
A)Виновных находить полезно: это дисциплинирует команду
B)Поиск виноватых прячет причины
C)Вред только в испорченных отношениях внутри команды
D)Надо наказывать за ошибки, тогда их станет меньше
показать ответ и разбор
+B)Поиск виноватых прячет причины
// разбор: Разбор «кто виноват» заставляет людей защищаться и скрывать детали — и настоящие, системные причины остаются ненайденными, инцидент повторяется. Безобвинительный (blameless) постмортем исходит из того, что человек действовал разумно в данных ему условиях, и чинит систему: почему стало возможно ошибиться, где не хватило защит, автоматики, понятных процедур. Так растёт честность и реальная надёжность.
#dvo_incidents4 / 5
Инциденты чинят быстро, но общее время простоя велико. Оказалось, львиную долю съедают обнаружение и диагностика. Куда вкладываться?
A)В обнаружение и диагностику проблемы
B)В скорость набора команды инженеров на пейджер
C)В более подробные постмортемы после инцидентов
D)В увеличение числа реплик всех сервисов заранее
показать ответ и разбор
+A)В обнаружение и диагностику проблемы
// разбор: Время простоя (MTTR) складывается из обнаружения + диагностики + устранения, и часто первые две части доминируют: пока заметили, пока поняли что и где. Поэтому вкладываются в сокращение времени до обнаружения (хорошие симптомные алерты, дашборды) и до диагноза (трейсинг, рунбуки, корреляция), а также в быстрый безопасный откат как универсальное «устранение». Ускорять только саму починку — оптимизировать наименьшую часть.
#dvo_incidents5 / 5
Что называют инцидентом в эксплуатации сервиса?
A)Заметная пользователям деградация
B)Любую ошибку в логах приложения
C)Плановые работы с остановкой сервиса
D)Задачу на исправление найденного бага
показать ответ и разбор
+A)Заметная пользователям деградация
// разбор: Инцидент определяют по влиянию на пользователей, а не по наличию ошибок в логах: ошибки идут постоянно и сами по себе инцидентом не являются. Плановые работы тоже не инцидент — о них предупредили заранее.

дальше

Теорию прочитали. Навык ставится повторением

В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.

Открыть тренажёр Вся тема: SRE и надёжность