Артём Марченко, студент курса «Руководитель поддержки пользователей в IT», руководитель проектов высшей категории в «1С-КСУ».
Для чего всё это нужно
Постмортем инцидентов (некая разновидность ретроспективы) – это критический анализ, который проводят после возникновения проблемы. Например, после сбоя в работе сервиса.
Постмортем поможет вам понять:
- что произошло
- почему это случилось
- как можно предотвратить подобные случаи в будущем
Первое и очевидное преимущество постмортема: вы сможете глубоко разобраться в причинах инцидента. Речь не только о точном определении технического сбоя, но и о раскрытии последовательности событий, которые привели к аварии.
Глубоко погружаясь в вопросы «как?» и «почему?», мы обнаружим не только внешние симптомы проблемы, но и проникнем в причины уязвимости системы, в технический и человеческий фактор инцидента.
То есть мы не просто тушим пожар, а стараемся понять, почему именно произошло возгорание.
Наша команда сопровождает системно-техническую инфраструктуру поставщика SaaS-решения. И мы предполагаем, что внедрение такой практики может принести несколько ключевых преимуществ:
- повысить качество работы сервиса
- ускорить время решения инцидентов
- предотвратить новые инциденты
- повысить эффективность управления рисками
Если проводить постмортемы на регулярной основе, можно выявить не только технические неполадки, но и любые неэффективные действия в процессе реагирования на инциденты. То есть обнаруживать потенциальные риски до того, как они проявятся в виде реальных сбоев. Заблаговременно обнаруживая эти уязвимости, наша компания может лучше управлять безопасностью данных заказчика.
Что планировалось
- С помощью постмортемов начать собирать информацию по завершённым инцидентам для последующего анализа.
- Получать структурированную информацию, чтобы в дальнейшем добавить её в базу знаний поддержки.
- Использовать полученные знания в ежедневной работе: рассмотрение и разрешение различных инцидентов расширяет набор навыков и готовит команду к будущим задачам.
Что получилось
- Внедрили постмортемы в работу службы поддержки на обязательной основе.
- По результатам постмортемов поставили первые задачи. Например, на доработку системы мониторинга.
Что интересно. Проанализировав документы постмортемов, мы стали более пристально следить за случаями нестандартного поведения отдельных элементов системы (при получении нескольких обращений от пользователей и отсутствии «объективных» сигналов со стороны системы мониторинга). Так мы стараемся выявить проблему на самых ранних этапах. Такой превентивный подход поможет не просто реагировать на возникающие проблемы, а обнаруживать «аномалии», которые их порождают.
Что пока не получилось
- Своевременно заполнять документы постмортемов. Когда авария позади, кажется, что можно расслабиться, а потом наступает новый день и появляются новые проблемы.
- Отслеживать, как выполняются рекомендации, созданные по результатам анализа постмортема.
- Выйти на общесистемный уровень и рассматривать, как более широкие элементы системы – управление, процессы, технологии – могли повлиять на инцидент.
- Отработать процесс дальнейшего распространения и использования полученных знаний.
Выводы и планы по развитию
Пока что постмортемы показывают себя эффективно.
Но сейчас всю работу [по процедуре постмортема] выполняет руководитель службы поддержки. Поэтому нужно наладить делегирование и контроль за выполнением.
Регулярные постмортемы мы рассматриваем, как вклад в культуру, которая помогает обмениваться знаниями и решать проблемы коллективно. Когда члены команды изучают и расширяют список различных типов инцидентов, повышается способность эффективно действовать в нестандартных ситуациях.
Важно. К постомортему следует подходить с «правильным настроем». То есть делать упор на обучение, а не на обвинение других. Ведь мы хотим создать среду, в которой ошибки рассматриваются, как возможность для совершенствования.
Если практика постмортемов даст видимые положительные результаты, то в дальнейшем можно распространить её и на другие проекты компании.
