51-минутный доклад инженера Meta Кайла Лексмонда на QCon San Francisco посвящен теме, которую в IT обычно вспоминают слишком поздно: реагирование на инциденты ломает не только сервисы, но и людей. Для русскоязычных команд это особенно знакомо: чем сложнее прод, тем дороже ошибки в момент аварии, когда нужно быстро вернуть систему в рабочее состояние, а не устраивать следствие в прямом эфире.
Как пишет InfoQ, Лексмонд разбирает тяжелые production-аварии не со стороны красивых постмортемов, а изнутри инцидентной комнаты, где у команды сужается внимание, растет давление и резко дорожает любая лишняя минута. Его главный тезис звучит почти банально, но на практике о него регулярно спотыкаются даже зрелые команды: во время серьезного сбоя нужно различать mitigation и полное устранение причины. Иначе говоря, сначала остановить ущерб и вернуть пользователей в нормальный сценарий, а уже потом докапываться до корня проблемы.
Лексмонд не пытается продать универсальную схему управления авариями. Он говорит как инженер, прошедший через Twitter, Amazon, Facebook, CBSA и Kik, то есть через очень разные масштабы и уровни организационного хаоса. В его определении инцидент складывается из трех признаков: событие бьет по бизнесу, требует немедленной реакции и нуждается в смягчении последствий так, чтобы влияние на клиентов прекратилось. Это важная поправка для команд, которые путают инцидент-менеджмент с техническим расследованием. Когда метрики падают, пользователям не становится легче от того, что у вас в чате уже родилась изящная гипотеза о корневой причине.
Отдельно Лексмонд проводит границу между «инцидентом для компании» и «инцидентом для меня лично». На бумаге все просто: есть бизнес-ущерб, SLA, дежурные и процессы. В реальности поверх этого ложится человеческое давление. Сервис упал, на него завязаны другие команды, кто-то ждет обновления статуса, кто-то уже эскалировал наверх, а у инженера в голове одновременно борются профессиональная ответственность, гордость и страх ошибиться еще сильнее. По словам Лексмонда, в начале карьеры он сильнее воспринимал такие ситуации как личный провал, и это прямой путь к выгоранию. С ростом опыта этот эмоциональный перекос уменьшается, но сам по себе не исчезает.
Почему аварии так быстро бьют по людям
В этом и состоит практическая ценность доклада: он описывает не абстрактный «стресс», а вполне рабочую механику когнитивной перегрузки. Во время крупного сбоя человек начинает хуже фильтровать сигналы, цепляется за первую правдоподобную версию, перескакивает между задачами и теряет способность держать в голове систему целиком. Любой, кто бывал на созвоне по P1-инциденту, узнает картину без дополнительных пояснений. Проблема в том, что большинство инженерных процессов спроектированы как будто люди в этот момент остаются рациональными и спокойными. На деле же реагирование на инциденты почти всегда происходит в режиме ограниченного внимания, дефицита времени и высокого социального давления.
Лексмонд напоминает еще одну неприятную вещь: внешне одинаковые аварии переживаются по-разному в зависимости от того, насколько команда чувствует себя «на крючке». Если это сбой у облачного вендора, часть компаний может позволить себе ждать, часть переключается на DR-сценарии, а команда самого вендора в этот момент, очевидно, работает в совсем другой температуре. Отсюда практический вывод для внутренних платформенных и инфраструктурных команд: чем больше зависимостей замкнуто на ваш сервис, тем сильнее нужно инвестировать не только в отказоустойчивость, но и в предсказуемость самого процесса инцидентного ответа. Иначе технический долг быстро превращается в организационный.
Среди способов снизить этот ущерб Лексмонд делает ставку не на героизм дежурных, а на дисциплину. Во-первых, нужно сознательно отделять фазу нейтрализации инцидента от фазы анализа причин. Во-вторых, команде нужна культура без поиска виноватых, потому что в режиме страха люди не ускоряются, а начинают скрывать неопределенность и защищать собственные решения. В-третьих, системы и процедуры стоит строить так, чтобы они помогали принимать простые и проверяемые шаги под нагрузкой: меньше импровизации, больше заранее понятных действий, ролей и маршрутов эскалации. Это звучит не так эффектно, как история про инженера, который в одиночку спас прод в 3:47 утра, но для бизнеса обычно полезнее именно скучная операционная подготовка.
Что это значит для команд разработки и бизнеса
Для разработчиков здесь есть довольно жесткий, но полезный вывод: мастерство в проде измеряется не только тем, как быстро вы находите корень сбоя, а тем, насколько быстро умеете ограничить радиус поражения. Для тимлидов и IT-руководителей сигнал еще прямее. Если ваши ретро после инцидентов сводятся к поиску неправильной кнопки или конкретного виноватого, вы чините репутационную картинку, а не сам процесс. Если же команда не различает mitigation и root cause resolution, каждая серьезная авария будет дольше, дороже и эмоционально токсичнее, чем могла бы быть. И это уже вопрос не только reliability, но и удержания людей на рынке, где хорошие инженеры давно умеют выбирать себе не самый героический, а самый вменяемый прод.
На фоне усложняющихся стеков, облачных зависимостей и растущего числа межсервисных связей разговор о человеческой цене инцидентов перестает быть мягкой темой для HR и становится инженерной необходимостью. Следующий уровень зрелости для многих команд, похоже, будет измеряться не количеством громких постмортемов, а тем, насколько спокойно и структурно они умеют проходить через сбой, пока все вокруг требуют немедленного ответа.