О том, как правильно работать с рисками в IT, чтобы минимизировать их, мы уже рассказали. А что делать, если авария всё-таки произошла?
Делимся, как правильно действовать в случае аварии, что такое инцидент-репорт и какой инструмент поможет расти на своих ошибках.
Что такое аварии в IT
Аварией в IT можно считать любое значительное ухудшение сервиса для клиентов, и которое влечёт потерю денег. В IT-компании Evercode Lab под аварией мы подразумеваем не downtime, когда сервис лежит уже долгое время, а, например, если сайт грузится, но медленно. Аргумент “сервис же работает, просто плохо” — это не аргумент, потому что это также нарушает качество пользования для клиентов. Именно поэтому весь ключевой функционал покрыт мониторингами.
Как узнать, что произошла авария
Есть 2 способа узнать об аварии:
- Узнать об этом со стороны: от пользователей, клиентов, коммьюнити и т.д.
- Заметить неладное на мониторинге
Каждый менеджер должен быть готов к тому, что что-то пойдёт не так, и быстро реагировать в случае аварии. Во время аварии страдают наши клиенты, а значит, IT-компания теряет деньги и репутацию. Важно иметь точный алгоритм действий в случае аварии. Он может отличаться в зависимости от проекта, но глобально все такие алгоритмы состоят из следующих шагов 👇
Что делать, когда произошла авария в IT-компании
I. Сообщить об аварии руководителю проекта или другому ответственному человеку
Мониторингом занимается команда поддержки. В Evercode Lab, когда саппорт видит, что что-то не работает, он быстро перепроверяет это и одновременно информирует следующего по званию, например, работников поддержки Л2 или руководителя напрямую. Мы информируем команду в любое время о проблеме. Даже если авария происходит ночью.
II. Сообщить об аварии в рабочий канал, например в Slack или Telegram, чтобы команда была в курсе, и начать решать проблему
Если авария технического характера, саппортер, обнаруживший проблему, собирает тред (в Slack, Telegram и т.п.), описывает ситуацию и связывается со всеми ответственными.
Если проблема критичная, все текущие задачи откладываются, и внимание переключается на её решение. Организуется звонок или встреча между саппортером, разработчиком или девопсом и руководителем. Живое общение позволяет значительно сократить время.
Во время встречи саппортер продолжает мониторить ситуацию и отслеживать, что происходит. А ещё параллельно со встречей кто-то из участников должен всегда отписываться в тред о том, что было сделано и помогло ли это или не помогло.
III. Уведомить пользователей / партнеров и обновлять тред
Как только проблема идентифицирована, необходимо уведомить пользователей и партнёров. В том числе, чтобы биздевы, аккаунт-менеджеры, команда поддержки и маркетологи могли своевременно проинформировать клиентов и партнёров, в треде ведётся обязательная запись.
Очень важно информировать клиентов/пользователей о ходе аварии. Недостаточно написать: “У нас техническая ошибка, ждите”. Нужно предоставлять информацию порционно и качественно. Если происходит серьёзная авария, в Evercode Lab мы лично пишем клиентам и подробно объясняем, почему она случилась и что мы сделали, чтобы подобное не повторилось. Это повышает доверие, так как мы показываем, что работаем над собой и учимся на своих ошибках.
IV. Составить Инцидент репорт
По окончании треда пишется Инцидент репорт (ИР). ИР необходимо составлять сразу, чтобы понять, что произошло и какие действия предпринимались в процессе.
ИР не предполагает, что проблема решается сразу во время встречи. Обычно в нём разбирается, что пошло не так и что нужно сделать в будущем, чтобы исправить ситуацию должным образом.
Инцидент репорт (ИР)
Инцидент-репорт (ИР) — это документ, который ответственный сотрудник пишет после происшествия. Цель ИР — не допустить повторения ситуации. Обычно он содержит описание проблемы, таймлайн и список мер с исполнителями и ссылками на задачи. В Evercode Lab Инцидент репорт пишется всегда в течение 24 часов после происшествия.
Как писать Инцидент репорт (ИР):
В Evercode Lab отственного за написание Инцидент репорта всегда назначает руководитель.
В ИР всегда указывается:
- Суть инцидента: что произошло и почему
- Тяжесть аварии: высокая / средняя / низкая
- Дата начала: dd.mm.yyyy hh:mm
- Дата окончания: dd.mm.yyyy hh:mm
- Влияние (на бизнес): например, потери
- Что было сделано, чтобы решить проблему в моменте)
- Корень проблемы
- Превентивные меры: что нужно сделать, чтобы проблема не повторилась
- Кто ответственный за какую задачу и дедлайн
После этого руководитель просматривает Инцидент репорт, а ответственный дополняет или исправляет репорт.
Когда Инцидент репорт готов, ответственные приступают к выполнению задач.
Рефлексия – инструмент роста в IT-компании Evercode Lab
Часто аварии происходят по внешним причинам, реже по невнимательности. В таких случаях мы решаем проблему и пишем инцидент-репорт, чтобы ситуация больше не повторялась.
Если авария связана с ошибкой из-за установок, проблем с приоритетами или личных решений, сотруднику необходимо написать рефлексию. Это инструмент, который помогает нам разбираться, что было сделано неправильно, почему это произошло, и учиться на своих ошибках.
Рефлексия — это не наказание. Мы стараемся подходить к работе сознательно: спрашивать себя “Зачем я это делаю?” и оценивать риски. Рефлексия — это не просто извинения за ошибку, а глубокий анализ того, почему она произошла и почему было принято именно такое решение. Это очень полезно для роста.
Рефлексия гораздо эффективнее, чем разборки в духе “Я начальник — ты дурак”, так как она направлена на развитие сотрудника, а не на его наказание. В компании даже были случаи, когда сотрудника повышали после рефлексии, потому что она демонстрировала его способ мышления и способность к развитию, что оказалось важнее самой ошибки.
Этот процесс рефлексии можно инициировать самостоятельно или по запросу руководителя.
Как правильно писать Рефлексию
- Выделить время для рефлексии в спокойной обстановке
- Принять свою ответственность. Проанализировать проблемную ситуацию с точки зрения того, в какой момент ты принял неправильное решение.
- Сосредоточиться на своей мотивации: “Почему я поступил именно так?” “Какая установка/мысль в моей голове привела к такому решению?”
- После поиска причины/мотивации к ошибке — сформулировать необходимые действия, чтобы больше подобную ошибку не совершать.
Рефлексировать над ошибками нужно максимально предметно, докапываясь до истинной причины, а не в формате “Буду делать хорошо и не буду плохо”. Полезный вывод — это понять, какой процесс можно внедрить или скорректировать и что изменить в своём восприятии.
После того как рефлексия написана, руководитель просматривает её и даёт обратную связь. Он также может задать уточняющие вопросы, помочь глубже разобраться и заметить что-то со стороны.
Если ты тоже хочешь непрерывно расти и развиваться, прокачивая свои навыки, ищи открытые вакансии в Evercode Lab на нашем сайте.
А ещё подписывайся на наш Telegram-канал и группу в ВК. Там мы каждую неделю публикуем горячие вакансии, анонсируем бесплатные обучения и рассказываем о наших проектах.
