Сейчас три часа ночи по калифорнийскому времени, и большинство разработчиков крепко спят. Система аутентификации начала отклонять корректные учётные данные. Ранние пташки с Восточного побережья уже пытаются войти в систему — и безуспешно. Тысячи пользователей в Европе давно махнули рукой и ушли к конкурентам. Через пару часов проснётся и Западное побережье. И тут появляется блестящий инженер, который спасает положение. Легендарные навыки отладки, глубокое знание системы аутентификации — и за сорок минут она собирает патч, на диагностику которого у любого другого ушли бы часы. К утру руководство рассыпается в благодарностях в общем чате. Вице-президент выписывает ей небольшую премию, а менеджер напоминает упомянуть это достижение в следующем цикле оценки результативности.
Чего обычно не происходит — так это вопроса: а что было бы, не окажись её рядом? Потому что этот героический спасительный бросок, при всём искреннем торжестве вокруг него, с системной точки зрения был самым настоящим «почти катастрофой» (near miss).
«Почти катастрофа» выглядит как успех
В авиации и других областях, где цена ошибки критически высока, давно принято считать ситуацию «почти катастрофы» бесценной возможностью для обучения — такой же, как и реальная авария. Логика проста: «почти катастрофа» обнажает те же системные уязвимости, что и настоящий сбой. Единственное различие между ними — в исходе: на этот раз он оказался благополучным, нередко благодаря удаче, стечению обстоятельств или присутствию одного конкретного человека.
Героическое реагирование на инцидент — аналогичная возможность. Система была на волосок от отказа и действительно отказала бы, не окажись тот самый инженер доступен и не знай он в точности, что делать. Её мастерство, экспертиза и самоотдача заслуживают признания. Но её недоступность привела бы к куда более плачевным последствиям — и это тоже стоит исследовать. Слишком многие компании празднуют спасение — и на этом останавливаются.
Стимул, который никто не проектировал
Когда компания чествует героическое спасение, не задаваясь вопросом, зачем вообще понадобился героизм, это посылает определённый сигнал. Сигнал непреднамеренный, но вполне внятный: ценится эффектное спасение, а не скучная подготовительная работа, которая сделала бы его ненужным.
Со временем этот сигнал меняет поведение людей. Инженер, который пишет подробную документацию по runbook’ам, обучает новых членов команды работе с системой аутентификации и улучшает мониторинг, не получает того же признания, что тот, кто ворвался в три часа ночи и спас положение. Работа по подготовке практически невидима в оценках результативности. Героические спасения — запоминаются.
Результат — порочный круг стимулов. Героизм вознаграждается, готовность — нет, и компания остаётся зависимой от героических спасений, потому что никто не инвестирует в альтернативу. Это не чья-то сознательная политика. Просто система вознаграждения тихо поощряет не то, что нужно, — и никто этого не замечает, пока герои продолжают выдавать результат. До тех пор, пока не перестают.
По моему опыту, это один из самых распространённых паттернов в компаниях, которые испытывают трудности с управлением инцидентами. У них есть талантливые, самоотверженные люди, которые раз за разом выдают героические результаты, и именно потому, что результаты продолжают поступать, никто не осознаёт, что под ними зреет структурная проблема.
Герой как единая точка отказа
Порочный круг порождает вторую проблему. Герой постепенно становится узким местом и единой точкой отказа (single point of failure). Когда этот инженер уйдёт в отпуск и случится следующий инцидент с системой аутентификации, команда может потратить часы только на то, чтобы понять, что происходит, — не говоря уже об исправлении. Когда герой в итоге покинет компанию (а это весьма вероятно: герои склонны к выгоранию), окажется, что критически важные знания ушли вместе с ним.
Я регулярно вижу этот паттерн в своей консультационной практике. При самых серьёзных инцидентах компании снова и снова обращаются к одной и той же горстке героических инженеров. Эти люди талантливы и преданны делу, и их участие действительно спасало компании от значительного ущерба. Все, кто имеет дело с инцидентами, знают их в лицо и с облегчением вздыхают, когда видят их в канале инцидента. Но компания так и не задалась серьёзным вопросом: как выглядят её возможности реагирования без этих людей? Слово, которое часто применяют к таким людям, — «незаменимые», — что, по сути, означает: способность компании реагировать на инциденты зависит от того, доступны ли конкретные люди.
Почему проблема остаётся скрытой
Самое коварное в этом паттерне — то, что он невидим для руководства ровно до тех пор, пока герои продолжают справляться. Компании на самых ранних стадиях зрелости управления инцидентами нередко не осознают, что рискуют. Руководство видит стабильно хорошие результаты и делает вывод, что компания обладает сильным реагированием на инциденты, — тогда как на деле у неё есть сильные индивидуумы (и изрядная доля везения).
К тому моменту, когда хрупкость обнаруживает себя, разрыв между тем, где компания думала что находится, и тем, где она находилась на самом деле, может быть ошеломляющим.
«Героический» — это стадия роста, а не комплимент
Когда я оцениваю возможности управления инцидентами у своих клиентов, одно из измерений — зрелость программы: где эта компания находится на пути от ситуативного реагирования к надёжной организационной способности? Первая стадия этого пути называется «Героическая» (Heroic). И это не лестная характеристика. Она означает, что качество реагирования на инциденты является свойством конкретных талантливых людей, а не свойством компании. Когда эти люди доступны — всё идёт хорошо. Когда нет — всё идёт наперекосяк.
Каждая компания начинает именно здесь. Вопрос в том, инвестирует ли она в то, чтобы выйти за пределы этой стадии — превратить индивидуальные возможности в организационные. Именно этот переход описывают остальные уровни модели зрелости, и именно на него ориентированы эффективные программы управления инцидентами.
Что стоит признавать вместо этого
Всё сказанное не означает, что компании должны прекратить отмечать героические вклады. Если кто-то спас положение в три часа ночи — поблагодарите его. Но также разберитесь, почему потребовался героизм, и инвестируйте в ответы на этот вопрос. Это тоже форма признания: она говорит о том, что спасение было достаточно значимым, чтобы на нём учиться.
Чтобы перейти от «Героической» стадии к более высоким уровням организационной зрелости, нужно изменить то, что получает устойчивое признание. Признавайте работу, которая делает героические спасения излишними: runbook’и, обучение, слаженное реагирование на инциденты, в котором никому не пришлось быть героем.
Если инженер провёл значительную часть квартала, составляя runbook’и, обучая новых участников команды реагирования и координируя работу при инцидентах, — признайте эту работу: в оценках результативности, в публичном признании со стороны руководства, в премиях и наградах. Если вы этого не сделаете, вы говорите своей организации: единственная работа по управлению инцидентами, достойная внимания, — это эффектное спасение.
Цель — сделать эффективное реагирование на инциденты тем, что компания умеет делать надёжно, вне зависимости от того, кто дежурит. Герои по-прежнему приветствуются и по-прежнему вызывают восхищение. Просто они не должны быть обязательным условием.