Культура postmortems или как мы учимся на ̶с̶в̶о̶и̶х̶ факапах

  • Сначала я расскажу зачем нам были нужны postmortems
  • История их развития в открытом мире
  • Наш шаблон postmortem
  • Примеры факапов “моего друга”
  • Выводы
  • Зафиксировать факт инцидента
  • Оценить эффект
  • Описать как тушили пожар
  • Зафиксировать что нужно сделать, чтобы проблема не повторилась
  • И зафиксировать ответственных за эти действия
  • Postmortem должен содержать детализированный отчет произошедшего, составленный без страха наказания или возмездия
  • Отсутствие страха позволит избежать в будущем “cover-your-ass” engineering
  • От человека совершившего ошибочные действия мы ждем деталей относительно того, почему он сделал эти действия
  • Для того, чтобы понять причину неудачи, мы сначала должны понять нашу реакцию на эту ошибку
  • Postmortem должен быть без обвинительным (blameless) и конструктивным
  • Все postmortems должны изучаться и разбираться, если вы этого не делаете, то проще вообще их совсем не писать
  • Надо явно хвалить тех людей, которые делали правильные вещи для исправления факапа
  • Надо собирать обратную связь об эффективности работы с postmortems
  • Пользователи заметили деградацию сервиса
  • Были потеряны любые данные
  • Потребовалось вмешательство дежурного инженера, например, чтобы вручную откатить релиз
  • Решение проблемы заняло слишком много времени. Если какая-то задача решалась за 2 часа, а тут на нее потратили неделю — это инцидент, который требует разбирательства
  • Мониторинг не сработал. Например, о проблеме вы узнали от пользователей
  • Ясность
  • Конкретные action items
  • Безобвинительность (blameless)
  • Глубина
  • Своевременность
  • Лаконичность
  • Моделируйте и усиливайте без обвинительное (blameless) поведение
  • Хвалите по результатам postmortem отличившихся
  • Открыто публикуйте postmortems (как минимум внутри компании)
  • Реагируйте на фейлы культуры postmortem
  • Надо искать не причину отказа, а думать как это работало раньше. Отсюда уже искать проблему
  • Задавать вопрос не “why”, а “how
    — “why” генерирует цепочку причинно-следственных связей
    и часто под желаемый результат
    — “how” генерирует независимые истории, по которым проще найти концы

Как мы работаем с postmortems

  • Issue Summary
  • Timeline
  • Root Cause
  • Resolution & Recovery
  • Corrective & Preventive measures
  • краткое описание ситуации
  • описание проблемы
  • описание решения
  • выводы
  • В одну из несчастливых недель у нас было целых два часовых outage оркестратора контейнеров с production apps “друга”
  • Postmortems у внешней команды, поддерживающей Rancher, тогда не практиковались, доступного разбора инцидента не было, но по слухам причины были в
    1) Первый раз в неудачном обновлении Rancher
    2) Второй раз в распухших метаданных и тормозящей базе данных
  • Принятые меры
    - Наши приложения съехали из Rancher на виртуалки с docker compose
    - Мы ввели работу с postmortems в нашем подразделении
  • Очередные релизы фронтовых приложений
  • Через неделю просели почти по всем SEO позициям
  • Причина проседания — отвалились все метатеги
  • Эффект — минус XXX $ из-за потери части органического трафика
  • Приложение — сильно связный монолит
  • Плохое проектирование общего функционала для работы с metatags (не было нормального интерфейса и точек расширения)
  • Отсутствие автотестов на этот функционал
  • Библиотеку для metatags правили >= 20 команд
  • Отсутствие проверки при регрессе
  • Исправили процесс тестирования, добавив в регресс важные проверки на metategs, важные для SEO
  • Исправили архитектуру общего компонента
  • Получили еще один аргумент в копилку разъезда на отдельные приложения
  • Python + Django в качестве API для вебприложения
  • Часть запросов к API — долгие
  • Приложение развернуто в K8s с liveness и readiness пробами
  • Покупка рекламного трафика и резкий всплеск нагрузки
  • Приложение частично в downtime, контейнеры умирают и поднимаются по кругу
  • Эффект — минус XXX $ из-за потери части рекламного трафика
  • Python + Django — однопоточные
  • Долгие запросы — особенности cпроектированного API
  • Liveness и readiness пробы обрабатываются наравне с пользовательскими запросами
  • Несколько раз не успел ответить на пробы — оркестратор придет и перезапустит pod
  • В итоге — комбо и получаем бесконечные рестарты pods
  • Написание cloud native веб-приложений требует знаний того, как это будет крутится в runtime
  • Факт того, что приложение переподнимется не защитит вас от цикла падений и перезапусков:)
  • Проектировать API надо тщательно продумывая нагрузку и постепенную деградацию + probesusual requests
  • Postmortems помогают в непрерывном улучшении
  • С определенного размера команд и сложности проектов процесс работы с postmortems необходим
  • По результатам postmortem должны происходить изменения, зафиксированные в action items
  • С определенного момента этот процесс должен быть автоматизирован (заведение postmortems, сбор информации о происходящем и так далее)

Источники

--

--

--

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Alexander Polomodov

Alexander Polomodov

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

More from Medium

🔎 Comparisons of Drawing&Note Applications

S.O.L.I.D Principles

Digital Identity?

A simple tool to troubleshoot the performance issues