09 Сентября 2022 12:33 09 Сен 2022 12:33 |

Поделиться

Секреты инцидент-менеджмента: как компании могут повысить свою эффективность

Как правило, процесс управления инцидентами включает в себя от 4 до 6 этапов, в зависимости от конкретной методологии или стандарта. Для простоты внедрения я представлю модель, состоящую из четырех фаз: Обнаружение (Detect) → Реагирование (Respond) → Решение (Resolve) → Обучение (Learn), и дам практические советы для каждой.

Обнаружение (Detect)

Первый этап включает в себя идентификацию и документирование непредвиденных событий или проблем. Вот несколько советов, чтобы сделать данный этап эффективнее:

1. Определите базовые метрики (см. ниже) и выберите средства мониторинга и автоматизации, связанные с ними. Выбор инструментария зависит от возможностей и потребностей компании: для стартапов это могут быть такие решения, как Elastic/Logstash/Kibana или Grafana, для крупных предприятий — DataDog, Sentry или Splunk.
2. Настройте пороги (thresholds), при достижении которых on-call/on-duty инженеры будут получать уведомления для реагирования. Можно взять за основу следующие показатели:
   • Количество ошибок в системе. Это могут быть логи уровня fatal, error или необработанных исключения в коде. Выберите приемлемый уровень шума и поставьте, например, +20% от него как “желтый" уровень, а +40% как критический.
   • Количество 4хх и 5хх кодов ответов для публичных HTTP-серверов. 5хх ошибок, как и fatal ошибок, всегда должно быть около нуля.
   • Тайминги (RPS, Response Time) как для внутренних, так и внешних эндпойнтов. Если время ответов начинает резко увеличиваться, это может быть признаком того, что ваша система испытывает непредвиденную нагрузку, и это может перерасти в инцидент.
     Для установки “нормальной” скорости сервисов можно отталкиваться, например, от стандартов Google: ответы более 200 мс считаем “долгими”.
   • Отслеживание CPU (например, не более 80%), Memory и Load Average (LA, который не должен превышать число ядер сервера) показателей для инстансов серверов поможет вам определить, нет ли исключительной нагрузки на ваши сервера.
   • KPI или бизнесовые метрики: например, если среднее количество ежедневно активных пользователей (DAU) вашего продукта заметно снизилось, это может говорить о проблемах.
3. Внедрите единый канал коммуникации, доступный всем командам, для оповещений об инцидентах, например канал в Slack или корпоративным мессенджере с названием “#emergency”.
4. Убедитесь, что все члены вашей команды умеют обнаруживать инциденты и заявлять о них. Они должны знать, на что обращать внимание, как использовать инструменты мониторинга и куда обращаться в случае обнаружения проблемы. Особенно это касается передачи ценной информации, получаемой от клиентов, которая зачастую имеет решающее значение для расследования инцидента.

Реагирование (Respond)

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

Порядок действий:

1. Выбрать или назначить ответственного за решение текущего инцидента. Его задача — первичный анализ ситуации, определение приоритета инцидента и людей, способных помочь в его разрешении, работа над быстрым снижением критичности инцидента, последующая координация действий всех задействованных сторон и регулярное информирование.
   Инциденты классифицируются по степени их воздействия на клиентов и бизнес-процессы:
   • P1 [Критический]. Сервис полностью недоступен или его основная функциональность нарушена для более чем 50% пользователей. Например, невозможность разместить заказ в интернет-магазине или сервисе доставки.
   • P2 [Высокий]. Сбой в работе некритичного компонента системы, но основная функциональность сервиса продолжает работать. Например, возникает невозможность регистрации новых пользователей в сервисе.
   • P3 [Средний]. Незначительные проблемы, которые не влияют на основную работу сервиса, но могут причинять неудобства. Например, не доставляется 20% сообщений от пользователей в службу поддержки.
2. Организовать канал для обсуждения инцидента, например в корпоративном мессенджере или видеоконференции Zoom.
3. Регулярно сообщать о статусе решения инцидента, устанавливая четкие интервалы времени для обновления информации в зависимости от критичности ситуации.
4. Уведомлять третьи стороны и партнеров в случае, если инцидент касается их интересов. Это не означает, что нужно рассказывать всю “внутреннюю кухню”. Достаточно регулярного информирования о пострадавших сервисах, прогрессе работ и примерном времени восстановления.

Решение (Resolve)

Цель этапа — минимизация воздействия инцидента на бизнес-процессы и клиентов компании, а уже затем восстановление нормального сервиса.

В идеале, к началу инцидента у вас уже должна быть набор инструкций для действий в случае инцидентов (Standard Operating Procedures, SOP), который должен включать шаги по оценке, реагированию и устранению инцидентов, и каждый сотрудник должен уметь ими пользоваться.

Если в вашей компании SOP еще не разработаны, начать документирование можно с описания того, как вы реагировали на недавние или самые частые проблемы.

Можно воспользоваться фрагментами популярных методологий, например ITIL (Information Technology Infrastructure Library) или NIST SP 800-61 (руководство по управлению компьютерными инцидентами от Национального института стандартов и технологий). В двух словах, процесс выглядит так:

1. Идентификация ключевых процессов и сервисов, которые критически важны для функционирования вашего бизнеса: серверов, сетевого оборудования, приложений, внешних сервисов, баз данных и т.д.
2. Определение потенциальных инцидентов, которые могут нарушить их работоспособность или безопасность, например программные ошибки, сбои оборудования, кибератаки, утечки данных.
3. Разработка для каждого типа потенциального инцидента плана действий.

Правила эскалации

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

Когда эскалировать инцидент?

• Если его критичность или влияние в процессе разборки оказывается значительно выше ожидаемого.
• Когда для решения проблемы необходимы дополнительные ресурсы, люди, специализированные знания или решения на более высоком уровне управления.
• Если в течение установленного времени не наблюдается прогресса в решении инцидента.
• Если очевидно, что не удастся восстановить сервис в пределах обещанных или ожидаемых сроков.

Кому эскалировать?

• Техлиду или руководителю отдела, который может предоставить немедленную поддержку.
• Техническому директору для P1-P2 инцидентов, требующих масштабного решения, изменения в инфраструктуре или вовлечении других отделов.
• ИБ и юристам, если инцидент связан с безопасностью или конфиденциальностью данных.
• При потенциале значительного влияния на бизнес, его репутацию или финансовое состояние — высшему руководству, вплоть до CEO.

Завершение инцидента

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

Если причину не удается устранить полностью, но удалось понизить его критичность до незначительной, оригинальный инцидент можно закрыть и создать новый с уровнем P3 или ниже.

Обучение (Learn)

Не позднее недели после завершения инцидента проведите его анализ:

• Зафиксируйте все детали, изучите действия по его устранению и найдите возможности для улучшения процесса реагирования.
• Организуйте совещание со всеми участниками инцидента для обсуждения ключевых моментов и сбора отзывов. Создайте атмосферу доверия, чтобы люди не боялись признаваться в своих ошибках.
• Сформулируйте шаблон для детального анализа случившейся проблемы (post mortem). Рекомендуемый набор вопросов:
  • Как мы узнали об инциденте?
  • В чем заключалась проблема?
  • Почему это произошло?
  • Как долго это продолжалось? (MTTR метрика, см. ниже)
  • Как это повлияло на бизнес?
  • Что мы предприняли для решения проблемы?
  • Что мы будем делать, чтобы предотвратить это в будущем? (Action Points)
• Убедитесь в выполнении всех задач из последнего пункта Post-mortem, чтобы избежать повторения инцидента.
• Запланируйте презентацию анализа последнего инцидента на ближайшем инженерном митапе компании. Каждый инцидент должен быть тщательно проанализирован, но только после выполнения всех Action Points.
• Составьте чек-лист, который будет обязательным для прохождения перед релизом кода/сервиса в production. Он должен удовлетворять требованиям надежности, безопасности и другим критериям.

Основной метрикой, используемой для измерения эффективности процесса инцидент-менеджмента, является MTTR (Mean Time to Resolution) — среднее время на восстановление после инцидента. Чем ниже MTTR, тем более эффективной можно считать систему управления инцидентами. Время последнего этапа Learn здесь не учитывается.

Инциденты неизбежны в бизнесе, и их эффективное разрешение критично для стабильности и безопасности работы организации. Автоматизация процессов инцидент-менеджмента помогает быстро решать проблемы, снижать потери и укреплять доверие клиентов. Эффективное управление инцидентами — это не только рекомендация, но и необходимость для любой компании, стремящейся к надежности и безопасности оперирования своего бизнеса.

Поделиться

Подписаться на новости Короткая ссылка