Керування інцидентами та постмортеми

Коротко: Упорядкована обробка збоїв: швидко виявити, усунути, повідомити і потім без пошуку винних винести уроки.

Докладніше: Інцидент — це подія, що несподівано погіршує роботу сервісу, наприклад збій або різко зросла частка помилок. Керування інцидентами регулює ролі, порядок дій і комунікацію, щоб людям не доводилося імпровізувати під тиском. Постмортем (розбір) фіксує, що сталося і як запобігти цьому в майбутньому.

Подробиці

Процес під час інциденту

1. Виявити: сповіщення моніторингу або повідомлення від користувачів.
2. Класифікувати: наскільки це серйозно (критичність, зачеплені користувачі)?
3. Координувати: одна людина керує (incident commander), решта розслідують, один повідомляє.
4. Пом’якшити: спочатку зупинити вплив (відкат, вимкнення, перемикання на резерв), лише потім шукати причину.
5. Інформувати: сторінка статусу та повідомлення клієнтам із чесним описом стану справ.
6. Закрити: підтвердити нормальну роботу.

Постмортем

Він містить стислий опис, хронологію з часом, вплив (тривалість, кількість зачеплених), причини (зазвичай кілька, а не просто «одна помилка»), що минуло добре й погано, та конкретні дії з відповідальними й термінами. Допомагає кілька разів поспіль питати «чому?» («п’ять чому»).

Без пошуку винних

«Blameless»-постмортем питає не про те, хто винен, а про те, чому система дозволила людині помилитися. Люди, що бояться звинувачень, приховують факти, і організація вчиться менше. Людські помилки зазвичай ознака відсутніх запобіжників — рев’ю, тестів чи запасних варіантів.

Метрики

Поширені MTTD (час виявлення), MTTR (час відновлення) і кількість інцидентів. Вони мають давати підказки, а не слугувати змаганням. Навіть невеликим проєктам корисна коротка нотатка після кожного збою.

Див. також: SLI, SLO і бюджет помилок, SLA, рівень підтримки та система тікетів, Хаос-інжиніринг