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

Люди, не работающие в ИТ, назовут эти ситуации проблемами, трудностями, обстоятельствами, поломками или катастрофами. ITIL предлагает использовать понятие “инцидент” – как незапланированное прерывание услуги или снижение ее качества. В зависимости от степени тяжести и последствий таких инцидентов выделяется особый вид инцидентов – “значительные инциденты”. В любом случае, главная цель в управлении инцидентами – минимизировать негативное влияние инцидентов путем быстрого восстановления нормальной работы услуги или конфигурационной единицы.  

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

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

Большинство организаций имеет несколько линий поддержки (уровней) для обработки инцидентов:

• 1-я линия — это Сервис деск;
• 2-я линия – специалисты по программным, аппаратным, или инфраструктурным системам;
• 3-я линия — это, как правило, системные эксперты и разработчики.

Если инцидент не может быть решен быстро силами Сервис деска, он может быть эскалирован.

Функциональная эскалация передает инцидент соответствующей команде технической поддержки с соответствующей квалификацией (2-я или 3-я линии), а также может быть эскалирован иерархически, уведомляя соответствующие уровни управления. Любая эскалация увеличивает время обработки инцидента, что критично для разрешения значительных инцидентов. Именно поэтому значительные инциденты должны иметь совершенно иную модель и подход для обработки инцидентов с высоким уровнем влияния, а значит, более короткие сроки.

Руководство по практике управления инцидентами описывает детали, которые должны быть включены в модели для обработки значительных инцидентов:

• критерии отличающие значительные инциденты от катастроф и других инцидентов;
• координатора (MIM), ответственного за выполнение работ по восстановлению;
• специальные команды для расследования и восстановления значительных инцидентов;
• специальные методы исследования, порядок выделения дополнительных ресурсов, модели коммуникаций с заинтересованными сторонами;

Существует еще одна концепция решения инцидентов без эскалаций – это Роение (sworming). Концепция не нова, т.к. еще в 2008 г. компания Cisco написала об этом в своем официальном документе “Цифровое роение”.

Идея роения заключается в том, что вместо эскалации привлекаются и собираются вместе множество людей, имеющих знания и опыт в разных областях, подобно рою пчел или колонии муравьев, чтобы, предоставить свои коллективные знания для разрешения инцидента, пока не станет ясно, какие компетенции будут наиболее востребованными и необходимыми. В Роении проводят мозговые штурмы и обмениваются идеями друг с другом, и в целом используют групповую динамику, чтобы находить свежие и инновационные решения. В результате работы такого “улья”, дело передается лицу, или лицам, способным его решить.  Swarming стал новым термином для Управления инцидентами в ITIL 4.

А ведь этот подход применяется в Agile- и DevOps командах. Растет сложность и взаимное влияние между системами, и разрушение бункеров между теми, кто разрабатывает и теми, кто поддерживает продукты и услуги на этапе эксплуатации, требует изменения подходов к решению инцидентов.

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

Применение роения требует изменения культуры. В среде конкурентности или изолированности трудно сотрудничать или делиться своими знаниями. Культура сотрудничества подразумевает доверие и открытость, она сосредотачивается на поиске решения проблем и возможностей, но никак не на обвинении или “назначении” виновных.

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

А как в ваших компаниях реализуются данные подходы и какие инновационные идеи испытываются на жизнеспособность?