Close

Путь к успешному управлению инцидентами начинается здесь

Изменение ролей при управлении инцидентами и проблемами

За последние десять лет управление инцидентами сильно изменилось.

Рекомендации по ITIL были обновлены. ИТ-специалисты начали делить ответственность с DevOps и SecOps. Усложнение систем привело к появлению более сложных решений для управления инцидентами. Многие компании выбирают ретроспективы без поиска виноватых и новые способы измерения производительности.

По мере изменения и развития управления инцидентами изменяется и связанное с ним управление проблемами, а также отношения между этими двумя сферами.

Что такое проблема и чем она отличается от инцидента?

ITIL определяет проблему как причину или потенциальную причину одного или нескольких инцидентов.

Инцидент — это одно незапланированное событие, которое приводит к сбою в работе сервиса.

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

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

Колонна серверов с одним опрокидывающимся и вызывающим проблемы сервером

Например, пятичасовой простой, который в 2016 году обошелся авиакомпании Delta Airlines в 150 млн $, был инцидентом. Проблема, вызвавшая этот инцидент, заключалась в сбое энергоснабжения операционного центра и, видимо, в отсутствии запасного плана на случай подобного сбоя.

Аналогичным образом 12-часовой перебой в работе магазина приложений, который обошелся компании Apple примерно в 25 млн $, был инцидентом. Какая проблема стояла за ним? Проблема с DNS.

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

Управление проблемами и управление инцидентами

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

Согласно последним рекомендациям по ITIL, традиционным ИТ-командам следует управлять как проблемами, так и инцидентами, но делать это по отдельности. Управление проблемами — это практика, направленная на предотвращение инцидентов или уменьшение их воздействия. Управление инцидентами делает упор на устранении инцидентов в режиме реального времени.

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

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

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

DevOps и изменение ролей при управлении проблемами и инцидентами

Основывающееся на сотрудничестве движение DevOps, как обычно, размыло границы традиционного ИТ-мышления. В нем управление проблемами и инцидентами рассматривается не как две различные практики, а как перекрывающие друг друга половинки целого.

Изображение ITIL с отдельными кругами для управления проблемами и инцидентами и изображение DevOps с диаграммой Венна для управления проблемами и инцидентами

Сдвиг обусловлен не только тем фактом, что это две стороны одной монеты — предотвращение и устранение инцидентов. Дело еще и в подходе DevOps, который утверждает, что:

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

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

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

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

продолжение темы
SRE