Психология надежности: почему мы ошибаемся в оценке рисков

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

Представьте, что вы руководитель продукта. Ваша команда только что запустила новую функцию, и пользователи в восторге. Разработчики предлагают потратить следующий спринт не на новую фичу, а на "скучные" улучшения надежности: переписать старый код, добавить резервные контуры, протестировать сценарии восстановления. Данные показывают, что сбои случаются редко, а выгорание команды незаметно со стороны. Что вы выберете? Инновации или профилактику?

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

1. Иллюзия контроля и нормальность аварий

"Система работала без сбоев 300 дней подряд. Значит, она надежна, и можно сфокусироваться на новых возможностях".

Здесь самая показательная психологическая ловушка: - Иллюзия контроля: мы переоцениваем свою способность влиять на события, особенно в сложных системах. Успешные дни создают ложное чувство мастерства ("Мы все предусмотрели"). - Нормальность аварий: социолог Чарльз Перроу ввел термин "нормальные аварии" для сложных систем с плотными связями ("Независимо от того, насколько эффективны предохранительные устройства, есть форма несчастного случая, которая неизбежна" - "Normal_Accidents" by Charles Perrow). В них сбои это не исключение, а неизбежное следствие сложности. Чем дольше система работает без видимых проблем, тем сильнее мы верим, что она безупречна, и тем опаснее становится следующее изменение.

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

Что делать SRE? Внедрять проактивное нарушение стабильности. Chaos Engineering и геймдэйз - прививку против иллюзии контроля. Системы сложна, и в них всегда есть скрытые дефекты.

2. Слепота к отсутствию отказов

Работа SRE, которая предотвратила сбой, невидима. Никто не празднует катастрофу, которая не случилась. Бюджет и похвалу получает тот, кто запустил новую фичу.

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

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

Что делать SRE? Измерять и визуализировать предотвращенные инциденты. - Вести учет сценариев, которые были нивелированы благодаря резервированию, автоматическому восстановлению или улучшенному мониторингу. - Использовать Error Budget как наглядный, измеримый отчет о проделанной работе по предотвращению рисков. Потраченный бюджет это доказательство того, что команда балансировала между инновациями и стабильностью.

3. Смещение в сторону известного и недооценка "черных лебедей"

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

  • Смещение в сторону известного (Availability Heuristic): мы оцениваем вероятность события по тому, насколько легко можем его вспомнить. Яркие, недавние сбои кажутся более вероятными.
  • Концепция "Черного лебедя" "Черный лебедь. Под знаком непредсказуемости" Нассима Талеба: Это события, которые: 1) непредсказуемы, 2) имеют колоссальные последствия, 3) после наступления кажутся объяснимыми. Мы строим планы, исходя из прошлого, а черные лебеди приходят из будущего.

После землетрясения люди массово покупают страховку от землетрясений. Через год, когда память притупляется, они ее отменяют, хотя риск объективно не изменился.

Что делать SRE? Проектировать для непредсказуемого. - Проводить сценарное планирование ("What-if / Что, если" analysis) для маловероятных, но катастрофических событий. - Строить системы по принципу "Надежных систем не бывает, бывает готовность к сбоям". Фокус смещается с предотвращения всех сбоев на обеспечение быстрого и предсказуемого восстановления (Resilience Engineering).

4. Прокрастинация надежности

"Мы сделаем рефакторинг этого старого модуля и наладим тесты… но в третьем квартале следующего года. Сейчас нужно выпустить фичу для отрыва от конкурентов".

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

Это, как выбор между "съесть пирожное сейчас" (удовольствие) или "заняться спортом" (здоровье в будущем). Понятно, что выберет большинство читателей :)

Что делать SRE? Делать будущие выгоды осязаемыми, а отсрочку дорогой. - Связать работу по надежности с конкретными, измеримыми бизнес-метриками уже сейчас: "Этот рефакторинг снизит время разработки новых фич на 20% в следующем квартале". - Использовать Error budget Policy как формальный механизм, который не позволяет бесконечно откладывать работу над надежностью. Если бюджет исчерпан - отсрочка становится невозможной по определению, как бы и кому бы этого не хотелось.

5. Культура обвинения

После аварии первым вопросом звучит: "Кто виноват?" Мы ищем "некомпетентного инженера" или "небрежного разработчика".

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

Что делать SRE? Внедрять и защищать Blameless postmortem культуру. - Сместить фокус с "Кто?" на "Почему?" и "Как система позволила этому случиться?". - Рассматривать человеческие ошибки как симптом, а не как причину. Симптом того, что процессы, инструменты или интерфейсы не были рассчитаны на реальные условия работы, что-то в них не так и что-то там нужно поправить.

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

Философия SRE — это, по сути, набор инструментов для борьбы с нашей же иррациональностью: - Данные (SLO/SLI) побеждают иллюзию контроля и слепоту к отсутствию сбоев. - Процессы (Error budget, postmortems) побеждают прокрастинацию и культуру обвинения. - Проактивные практики (Chaos Engineering, сценарное планирование) побеждают смещение в сторону известного.

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