Всем привет! Меня зовут Даша Мельникова, я ведущий релиз-менеджер в МКБ.
У нас в IT более 2500 сотрудников в 120+ команд, и этими силами мы раз в две недели выпускаем более 500 релизов. В рамках этой статьи мы будем говорить об инцидентах, и их количество относительно общего числа задач будет небольшим, но мы будем улучшать сами процессы.
О каких инцидентах поговорим — инцидент сам по себе это некорректная работа функционала, но мы обсудим инциденты, которые переходят на третью линию (на команду разработки). А еще есть такая сущность, как инцидент ЗНО. Это сервисный запрос, обращение пользователя, в рамках которого мы лишь консультируем человека, а не правим код, то есть просто даем советы. Но если в рамках консультации возникает необходимость что-то доработать, то это выливается в создание новой фичи.
Критерии влияния
Мы делим инциденты в зависимости от:
приоритета
степени отклонения
степени влияния
критичности
срочности
Например, у нас есть отчет, который мы выгружаем 27-го числа каждого месяца. Первого числа этот отчет для нас не является критичным, потому что у нас есть плановый релиз, в рамках которого мы можем исправить этот инцидент, так что не спешим. А вот если мы с таким инцидентом столкнемся 26-го числа, тогда он становится блокирующим, ведь на следующий день пользователь не сможет сделать выгрузку этого отчета.
Поэтому каждый инцидент довольно сильно ситуативен, само собой, если мы не говорим о чем-то совсем серьезном, как неработающая авторизация.
В начале нашего пути мы столкнулись с тем, что у нас было 757 открытых инцидентов. Формально в рамках тех задач, что мы выпускаем, это не так-то и много, но все же мы решили улучшить это дело.
Как видите, инцидентов было много, да еще и на половине из них было нарушение SLA. Плюс у нас создавалось инцидентов больше, чем решалось.
Вот как выглядела картина, до уровня которой мы захотели все улучшить:
не более 300 инцидентов
SLA выполняется у 70%
создаем меньше, чем решаем, ибо чем больше решаем — тем меньше наш портфель
Что мы сделали
Сначала мы пошли более простым путем — собрали статистику и направили ее на команды, затем с помощью пряника попросили решать инциденты. После этого число инцидентов сократилось, но не особо заметно. Мы решили достать пряник потверже и ввели KPI.
Для каждой из команд стал обязателен один из двух пунктов:
либо сократить количество инцидентов в портфеле на 10%
либо выполнять SLA по инцидентам
Сразу скажу, что KPI мы вводили не для «наказания» команд, а для улучшения качества и процессов, просто для этого нужны были небольшие рамки влияния.
Считали все вот так.
Например, у нас было 15 инцидентов, чтобы узнать, сколько выполнено по SLA, мы смотрим те, у которых SLA соблюден, затем смотрим общее количество и получаем нужную цифру. Число незакрытых инцидентов — это инциденты, которые не являются выполненными (те, что в работе в данный момент).
В рамках такого KPI мы начали прорабатывать с командой запросы — например, у кого-то портфель не сокращался, у кого-то возникали сложности с соблюдением SLA. И в этот момент мы сразу начинали разобраться, что же случилось, как помочь.
Такой подход привел к увеличению соблюдения SLA на 15% (было 30, стало 45), а портфель сократился в полтора раза.
Важно — это промежуточный результат, на котором мы не остановились. На графике красные столбики — это созданные инциденты, а серые — решенные. И видно, что серые стали преобладать.
Что еще важно — мы улучшили расчеты SLA, если инцидент являлся некритичным, мы увеличили количество дней, отведенных на его решение. Скажем, если какая-то кнопка недостаточно зеленая, это не значит, что мы сразу побежим это чинить. А вот если у нас не работают переводы в банке, само собой, это куда серьезнее, и решать это будем в первую очередь. Так что время реакции на критичные инциденты благодаря такому подходу сократилось. Как и сроки их решения.
Такая же история и для описанных мною выше ЗНО — при критичных консультациях мы подключаемся сразу, а при некритичных вопросах — решаем их не так спешно.
Результаты после введения KPI
наш портфель в первой итерации KPI сократился в 2,2 раза
SLA вырос на 30% (в промежуточных — 15%, теперь 30%)
для удобства доработали несколько процессов в таск-трекере между командами разработки и сопровождения. Например, стало нельзя создавать инциденты без указания команды (это улучшило матрицы по назначению команд), а еще появились дополнительные поля, которые требовались для заполнения и ведения статистики, что улучшало процессы при проседании показателей.
По графику видно, как много инцидентов теперь имеют статус «Решено».
Документация
Чтобы с инцидентами было удобнее работать, мы подготовили дополнительные регламенты. Например:
1. Регламент по отмене инцидентов
Мы начали оценивать, какие инциденты в целом не являются инцидентами и в каком случае мы можем просто закрыть его. Скажем, если у нас уже есть один инцидент и создан точно такой же второй, то дубль можем закрыть и работать с первым.
2. Регламент по методам предотвращения
Это база знаний, показывающая, как решить тот или иной инцидент. В случае работы с инцидентом мы можем возвратиться к проблеме, если она возникала ранее. То есть часть таких инцидентов, например, может закрывать команда сопровождения, и это не будет уходить на третью линию. Если же ситуация уникальна, то ее можно потом использовать для передачи знаний между другими подразделениями.
3. Регламент по проработке причин пропуска и возникновения
Это разбор того, почему мы вообще пропустили какой‑то инцидент и почему он в принципе случился. Позволило нам дополнительно оценить, какой команде и в каких случаях нужна помощь.
4. Регламент разбора
Что мы делаем, когда получаем инцидент. Мы создали дашборды и структуры, которые позволяют командам в реальном времени отслеживать, что происходит в конкретный момент. К тому же в рамках рабочей группы по инцидентам мы начали рассматривать те инциденты, которые являются сложными и которые нужно эскалировать — это те, по которым либо возникают вопросы, либо по ним есть настолько интересные методы решения, которые точно стоит показать другим командам.
Кстати, о рабочей группе.
Задачи рабочей группы
Прежде всего это изучение причин, просмотр статистики и улучшение процессов. А также:
понимание, как не допустить инцидент. Например, если каких‑то данных не хватало, то мы их получали и после этого инциденты не повторялись. При необходимости дорабатывались и регламенты.
если возникали какие‑то проблемы в установке релиза, приводящие (либо могущие) привести к инцидентам, то это тоже прорабатывалось. Например, мы что‑то такое выявили и успели решить до того, как инцидент возник. Это помогает улучшить мониторинг и дополнять инструкции по установке.
Все это повышает качество. Если по пунктам, до повышается качество вот таким образом:
мы не просто работаем с инцидентами, мы теперь предотвращаем их (улучшаем качество с точки зрения тестирования, улучшается автоматизация, повышается количество нагрузки, проводим регресс)
проводится аудит команд, это помогает нам понять, как хорошо мы работаем с инцидентами
благодаря фулстек‑спецам у нас появляется больше людей, которые могут предотвращать инциденты (опять же, спасибо автоматизации тестирования)
в рамках мониторинга сред мы выявляем недоступность той или иной среды, что дает нам больше времени (чем если бы мониторинга не было вовсе), мы находим ошибке на предпроде
Дополнение KPI
В общем, процессы мы улучшили. Но нам этого не хватило, и мы захотели сделать еще лучше — дополнить KPI и улучшить историю с инцидентами. Спойлер — да, улучшили.
Прежде всего, потребовалось выполнить несколько пунктов одновременно.
соблюдение SLA в том же процентном соотношении, как раньше (10%)
плюс сокращение портфеля инцидентов на 10% (если он менее 10%, то на 1).
А еще мы смотрели на тренд — помесячно, но если он ежемесячно не отражал картину, то поквартально. Ибо если была одна огромная важная фича, скорее всего, она выходила не за один релиз. А то и не за два. Так что рассматривали и оценивали все в рамках того, как работает команда.
Вот пример расчета.
Например, если было 5 инцидентов, а стало 6, ясное дело, KPI не выполнен. А если стало 4 вместо 6 — выполнили.
То же самое по тренду, если мы ежеквартально увеличиваемся, то у нас не выполняется часть тренда. А если у нас ровное количество (или вообще оно уменьшается), то все выполняется и все молодцы.
Отчетность
Чтобы всем было удобно, без отчетности никуда. Так что мы создали отчет на FineBI, показывающий данные на предыдущий день. Можно посмотреть процентное соотношение по выполнению каждого из пунктов KPI, а также общее количество. Плюс наглядно — сколько было инцидентов в начале года и сколько в конце. Если у какой-то команды в каком-то аспекте перекос — мы сразу подключаемся и помогаем.
Чтобы видеть все в реальном времени, например, если инцидент закрыли и хочется сразу посмотреть текущую ситуацию, мы сделали дашборды в Jira, которые показывали данные на текущий момент. Они были как отдельные для команд, так и общие.
Что в итоге
портфель инцидентов сократился в три раза, это значительное количество
процент соблюдения SLA стал на 50% больше, чем ранее
тренд по созданию инцидентов не повышается, процент решенных инцидентов превышает процент созданных, чем дальше — тем меньше наш портфель
благодаря тому, что процент найденных в тестовых средах ошибок тоже вырос, у нас и стали выполняться предыдущие три пункта
В качестве небольшого резюме — да, штрафы за несоблюдение KPI помогают решать проблемы, можно испугаться того, что будут недовольные, но это правда создает рамки. Если для коллег донести, насколько это важно, и что вся эта история задумана не как повод для наказаний, а для улучшения качества — вы увидите результат.
Главное — придумайте систему исключения, потому что не все инциденты надо учитывать.
Если вести базу знаний о причинах пропуска и мерах предотвращения, то вы сможете заметить у той или иной команды узкое горлышко и вовремя ей помочь.
А ваша команда сопровождения сможет решать инциденты до того, как он уйдут на третью линию.
И не забывайте про регламенты и прозрачность вопросов.
PS
У меня, кстати, есть обратная связь от коллег. Говорят, выполнять SLA сложнее, чем его не выполнять. Но при этом они отметили значительное повышение качества.
Надеюсь, мой рассказ пригодится вам в работе. А если у вас есть какие‑то комментарии по теме или вопросы, буду рада на них ответить.
