Problem management: про что это и почему без него не обойтись?

Сопровождение продукта – одна из услуг, которую мы предлагаем нашим партнерам. Наша команда не первый год показывает стабильные результаты, что подтверждает доверие заказчиков. Но не только оперативное реагирование позволяет нам показывать высокие результаты, но и «превентивные меры». Предотвращать повторение инцидентов нам помогает problem management. А как - делимся в статье :)

В жизни каждого IT-продукта наступают моменты, когда случаются поломки серьезнее типовых ошибок. Например, недоступность сервиса или массовый сбой для пользователей. По методологии мировых практик ITIL любые ошибки и риски уже являются инцидентами. В российской практике настолько жесткий «режим паники» на каждое событие мониторинга используется редко. Мы считаем инцидентом всё-таки произошедшее событие с существенным влиянием на функционал приложения, либо, когда действительно возникли репутационные риски.

Если коротко, то problem management – процесс управления проблемами. В этой статье мы поговорим именно об управлении проблемами по произошедшим событиям. Это поиск корневых причин у возникших инцидентов, выявление мер по их устранению, выполнение этих мер и контроль за ними.

Если инцидент произошёл, то за его решение принимаются наши лучшие кадры из разных направлений – разработчики, DevOps, ПМ-ы, аналитики и, конечно, инженеры сопровождения. Часто именно инженер сопровождения первым узнает о проблеме по мониторингам или по обращениям от заказчика. Он ведет записи с хронологией звонков, переписок, установок хот-фиксов и принятых решениях.

После того, как инцидент решен, формируется файл отчета «постмортем» («post mortem», «посмертный снимок») - слепок инцидента в разных плоскостях.

В «постмортеме» есть:

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

Как мы работаем с «постмортемом» по принципам Problem management

Отслеживаем. Раньше «постмортемы» фиксировались в Confluence-пространствах конкретных заказчиков. Фиксация — это уже очень хорошо, но не хватало общей картины. С 2022 г. мы начали вести реестр произошедших инцидентов по всем заказчикам в одном месте с отслеживанием принятых мер. Главное в этом – видим системно, что ещё не сделано.

Исправл

2. Ищем «корни». При составлении «постмортема» пункту с мерами по предотвращению отводится самая большая часть работы. Как правило, инженер сопровождения после того, как инцидент был устранен, проводит общий созвон-«мозговой штурм» с теми, кто принимал участие. К группе могут быть подключены аналитики, служба безопасности, архитектор. На созвоне мы смотрим на инцидент немного «сверху», ищем источник его возникновения в процессах, в архитектуре решения, в подверженности системы человеческому фактору, в пропущенных критических ошибках, в узких местах приложений и т. п. Это творческая и интеллектуальная работа. Если не устранить корневую проблему, то чинить инциденты можно будет бесконечно.

3. Контролируем исполнение. Бывают комплексные причины, когда проблема кроется сразу в нескольких областях. Например, один инцидент вскрыл сразу несколько проблем: в архитектуре самого решения, в процессах на нашей стороне и процессах на стороне заказчика. Инженер сопровождения на регулярной основе контролирует выполнение запланированных мер. Если это исправление архитектуры – отслеживает, что выставленные доработки двигались в бэклоге разработки, попадали в спринты и «доезжали» до промышленной системы. Если это процессы – то контролирует, что участники обновленного процесса в нашей компании снабжены информацией о нем и действительно им пользуются. Ещё сложнее, если требуется изменение процессов со стороны заказчика – это потребует удвоенного контроля и умения договариваться.

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

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

Что в итоге?

Когда мы только начали системно подходить к problem management, уровень выполненных мер по устранению проблем составлял 40%. Затем стали планомерно работать над повышением этого показателя. Наша текущая цель – оставаться на уровне 90%, даже с учетом того, что новые инциденты периодически происходят и пополняют список. Сейчас статистика в нашу пользу - похожие инциденты, вызванные одной и той же проблемой, не повторяются.

Как говорят в Atlassian, «инциденты называют незапланированными инвестициями в надежное обслуживание в будущем, а эффективное управление проблемами позволяет повысить качество обслуживания».