Управление инцидентами для высокоскоростных команд
Изменение ролей при управлении инцидентами и проблемами
За последние десять лет управление инцидентами сильно изменилось.
Рекомендации по ITIL были обновлены. ИТ-специалисты начали делить ответственность с DevOps и SecOps. Усложнение систем привело к появлению более сложных решений для управления инцидентами. Многие компании выбирают ретроспективы без поиска виноватых и новые способы измерения производительности.
По мере изменения и развития подходов к управлению инцидентами изменяются и связанные с ними подходы к управлению проблемами, а также отношения между этими двумя сферами.
Что такое проблема и чем она отличается от инцидента?
ITIL определяет проблему как причину или потенциальную причину одного или нескольких инцидентов.
Инцидент — это одно незапланированное событие, которое приводит к сбою в работе сервиса.
Другими словами, инциденты — это неприятные эпизоды, которые дежурные сотрудники обычно пытаются решить как можно быстрее и полнее. Основной причиной этих разрушительных событий являются проблемы.
Проблема может стать причиной появления как одного, так и множества инцидентов. По инциденту можно отследить и установить одну, а иногда и несколько проблем.
Например, пятичасовой простой, который в 2016 году обошелся авиакомпании Delta Airlines в 150 млн $, был инцидентом. Проблема, вызвавшая этот инцидент, заключалась в сбое энергоснабжения операционного центра и, видимо, в отсутствии запасного плана на случай подобного сбоя.
Аналогичным образом 12-часовой перебой в работе магазина приложений, который обошелся компании Apple примерно в 25 млн $, был инцидентом. Какая проблема стояла за ним? Проблема с DNS.
Если бы мы использовали эти термины за пределами области технологий, то поход к врачу по поводу мигрени тоже назывался бы инцидентом. А причина мигрени — аллергия, проблемы со зрением или стресс — была бы проблемой.
Управление проблемами и управление инцидентами
Очевидно, что проблемы и инциденты неразрывно связаны между собой. Одно приводит к появлению другого, и поэтому команды должны обращать внимание на оба явления.
Согласно последним рекомендациям по ITIL, традиционным ИТ-командам следует управлять как проблемами, так и инцидентами, но делать это по отдельности. Управление проблемами — это практика, направленная на предотвращение инцидентов или уменьшение их воздействия. Управление инцидентами делает упор на устранении инцидентов в режиме реального времени.
Преимущество подхода ITIL заключается в том, что он уделяет первостепенное внимание основным целям управления и проблемами, и инцидентами. Вероятно, разделение их на отдельные и равнозначно важные практики в руководящих принципах — это попытка избежать общей проблемы ИТ-команд: постоянного решения инцидентов без устранения их первопричины.
Если основной целью менеджера инцидентов является быстрое разрешение инцидентов, а основной целью менеджера проблем — их предотвращение, то при объединении этих ролей может оказаться так, что одна из этих жизненно важных для организации целей исключена из числа приоритетных в пользу другой.
Недостатком этого подхода является то, что при разделении этих двух практик, которые так тесно связаны в реальности, могут появиться пробелы в знаниях и нарушение связи между разрешением инцидентов и анализом основных причин, ведущим к первопричине.
DevOps и изменение ролей при управлении проблемами и инцидентами
Основывающееся на сотрудничестве движение DevOps, как обычно, размыло границы традиционного ИТ-мышления. В нем управление проблемами и инцидентами рассматривается не как две различные практики, а как перекрывающие друг друга половинки целого.
Сдвиг обусловлен не только тем фактом, что это две стороны одной монеты — предотвращение и устранение инцидентов. Дело еще и в подходе DevOps, который утверждает, что:
- Обычно существует более одной основной причины инцидента.
- Ретроспективы должны проходить без поиска виноватых и включать все команды, пострадавшие от инцидента.
- Совместная работа является основой постоянного совершенствования.
Наложение управления проблемами и инцидентами также может быть связано с отраслевым сдвигом в сторону подхода «кто разработал, тот и поддерживает». Поскольку команды, создающие системы, становятся ответственными за разрешение инцидентов в этих системах, логично, что одна и та же команда несет ответственность за проведение ретроспектив, выполнение исследовательской работы по обнаружению первопричины инцидента и предоставление рекомендаций для предотвращения или уменьшения последствий будущих инцидентов.
В этом случае мостом между управлением проблемами и инцидентами является ретроспектива без поиска виноватых, где после ухода срочности менеджеры инцидентов превращаются в детективов и обращаются к задаче по управлению проблемами и их предотвращению.
Основная проблема, с которой сталкиваются команды DevOps при размывании границ между этими двумя практиками, заключается в том, чтобы управление проблемами (с его менее срочными, но крайне ценными долгосрочными целями) не было исключено из числа приоритетных в пользу управления инцидентами, требующего принятия оперативных мер.
Конечно, объединить управление инцидентами и управление проблемами на словах куда проще, чем на деле, однако это необходимо для поиска и устранения основной причины. Узнайте, как решение для управления инцидентами Jira Service Management позволяет командам вести гибкую совместную работу — фиксировать контекст и создавать подробную хронологию при разрешении инцидентов и использовать эти данные для более эффективного управления проблемами.
Составление графика дежурств с помощью Opsgenie
С помощью этого руководства вы научитесь настраивать график дежурств, использовать правила переадресации дежурств, настраивать оповещения о начале дежурства, а также изучите другие возможности Opsgenie.
Читать учебное руководствоПлюсы и минусы различных подходов к управлению дежурствами
Дежурные команды быстро развиваются. Узнайте о плюсах и минусах различных подходов к управлению дежурствами.
Читать статью