RCA: как эффективно разбирать инциденты
Сервис перезапускался каждые полчаса, добавили памяти, всё стабилизировалось, тикет закрыт. Через две недели повторилось. Разберём, как устроен поиск первопричины и почему без него поддержка превращается в пожарную команду.
Инцидент — это ещё не проблема
В терминологии ITIL инцидент — это незапланированное прерывание услуги или снижение её качества. Сайт не открывается, оплата не проходит, разделы грузятся втрое дольше обычного.
Цель работы с инцидентом одна: как можно быстрее вернуть работоспособность. Не разобраться, не найти виноватых, а восстановить сервис. Перезапустить, откатить релиз, добавить ресурсов, переключить трафик на резервный контур — любой способ, который работает прямо сейчас.
Проблема — это причина, стоящая за одним или несколькими инцидентами. Она живёт по другому календарю: её изучают, а не тушат, и закрывают исправлением, которое может занять недели.
Смешивать эти две сущности вредно в обе стороны. Если во время аварии начать разбираться в первопричине, сервис будет лежать дольше, чем мог бы. Если после восстановления не завести проблему, вы гарантированно встретите тот же инцидент снова — и второй раз он обойдётся дороже, потому что за это время о нём успели забыть.
Зачем нужен RCA
Root Cause Analysis — это и есть поиск того, что лежит в основе. Проводится после восстановления, в спокойном режиме.
Без него происходит характерная деформация: команда становится всё лучше в тушении и не становится лучше ни в чём другом. Инженеры знают наизусть, какой сервис чем перезапускается, среднее время восстановления даже улучшается — а количество инцидентов не падает.
Плюс чисто экономический аргумент. Добавление ресурсов в ответ на каждую нехватку памяти — это счёт за инфраструктуру, который растёт линейно и бесконечно.
Пять почему на конкретном примере
Метод простой до неприличия: берёте симптом и последовательно спрашиваете «почему», пока не упрётесь в то, что можно реально исправить. Пять — ориентир, а не правило; бывает три, бывает семь.
Возьмём тот самый сервис с перезапусками.
Почему сервис перезапускался? Потому что заканчивалась оперативная память, и механизм ядра принудительно завершал процесс.
Почему заканчивалась память? Потому что её забирал модуль генерации отчётов.
Почему модуль отчётов забирал всю память? Потому что пользователи выгружали отчёты сразу за несколько лет одним файлом, и весь объём собирался в памяти.
Почему это возможно? Потому что в коде нет ограничения на период выгрузки и нет постраничной обработки.
Почему ограничения нет? Потому что доработку внесли в бэклог и не реализовали — она не выглядела срочной.
Разница в результатах колоссальная. Первая версия записи в базе знаний выглядела бы как «нехватка памяти, решение — увеличить ресурсы». Вторая — «в выгрузке отчётов нет ограничения периода, задача такая-то в команду такую-то».
Попутно появляются два побочных действия, о которых легко забыть. Пользователей модуля нужно предупредить, чтобы до исправления они дробили выгрузки на части. А мониторинг стоит донастроить так, чтобы рост потребления памяти этим сервисом был виден заранее, а не по факту перезапуска.
Где метод подводит
У пяти почему есть репутация универсального инструмента, и она незаслуженная.
Метод строит одну линейную цепочку, а реальные аварии обычно устроены иначе: совпало несколько факторов, и ни один по отдельности к сбою бы не привёл. Выбрав на втором шаге одну ветку, вы потеряете остальные — и напишете аккуратный отчёт, объясняющий треть случившегося.
Результат зависит от того, кто задаёт вопросы. Две группы, разбирающие один инцидент, приходят к разным первопричинам просто потому, что по-разному формулируют ответы.
И есть соблазн остановиться на удобном шаге. Цепочка, которая заканчивается на «разработчик невнимательно проверил» или «пользователь сделал не то», — это не первопричина, а точка, где расследование бросили. Настоящий ответ лежит дальше: почему система позволила невнимательности привести к аварии.
Признак того, что вы дошли: найденное можно исправить, и исправление помешает повториться не только этому инциденту, но и соседним.
Разбор без поиска виноватых
Формат разбора важен не меньше метода. Если после каждой аварии ищут, кого наказать, происходит предсказуемое: люди перестают сообщать о мелких сбоях, перекладывают ответственность и избегают рискованных, но нужных действий. Информация об инцидентах начинает поступать с опозданием или не поступать вовсе.
Отсюда правило безвиновного разбора: виноваты не люди, а процессы и системы, которые позволили человеку ошибиться.
Допустим, инженер удалил таблицу на боевой базе. Вопросы, которые стоит задать, звучат так: почему у него вообще были права на удаление в проде? Почему перед выполнением не создавалась автоматическая резервная копия? Почему об этом узнали от пользователей, а не от мониторинга?
Ответы превращаются в задачи: пересмотреть права доступа, настроить алерт на аномальную активность в базе, описать безопасную процедуру. Увольнение конкретного человека не решает ни одну из этих задач — следующий на его месте наступит на те же грабли.
Постмортем: что записывать
Документ по итогам разбора имеет смысл, только если его потом читают. Поэтому короткий и по делу:
- хронология с точным временем — когда началось, когда заметили, когда локализовали, когда восстановили;
- влияние: сколько пользователей, какие функции, сколько это стоило в деньгах или в бюджете ошибок;
- как обнаружили — мониторинг или обращения пользователей (второе почти всегда означает пробел в наблюдаемости);
- что делали для восстановления;
- первопричина;
- задачи с ответственными и сроками.
Из этого списка чаще всего проваливаются последние два пункта. Постмортем без задач с конкретными исполнителями — это сочинение о том, как мы провели вторник.