🔥 История, которая перевернула безопасность во всём мире и всё из-за одной «невидимой» ошибки
В 1979 году на АЭС Three Mile Island в США произошла одна из самых известных ядерных аварий.
Но самое страшное было не в поломке.
А в том, как люди её интерпретировали.
Операторы видели данные с приборов и сделали, казалось бы, логичный вывод:
👉 система переполнена водой
👉 нужно её уменьшить
Они действовали «по инструкции».
Но реальность была противоположной.
💥 Реальная проблема:
• реактор терял охлаждение
А действия операторов только усугубили ситуацию
Почему это произошло?
Потому что они опирались только на видимые сигналы, игнорируя то, чего не было видно напрямую.
🧠 Это тот же тип ошибки мышления, что и у Вальда:
**мы доверяем тому, что видим
и игнорируем то, чего не видим**
После аварии провели масштабное расследование.
И выяснилось:
- интерфейсы показывали слишком много лишнего
- ключевые сигналы были «спрятаны»
- операторы не понимали, что действительно важно
⚡️ Что изменилось после этого:
- появилось направление human-centered design в критических системах
- интерфейсы начали проектировать под стрессовые ситуации
- в авиации и энергетике внедрили симуляторы аварий
- появилась концепция:
👉 «если пользователь ошибается — виноват дизайн, а не пользователь»
📊 Интересный факт:
после внедрения новых подходов к интерфейсам и обучению
👉 количество критических ошибок операторов в авиации и энергетике снизилось в разы
💡 Где это встречается сегодня:
- дашборды в аналитике
- мониторинг в DevOps
- алерты в продакшене
- метрики в AI
Ты видишь график — и думаешь, что понимаешь систему.
Но настоящая проблема часто скрыта в том,
чего нет на графике
👉 Главный вывод:
самые опасные ошибки — не в данных
а в том, как ты их интерпретируешь
📌 Параллель с Вальдом:
- там не было данных о погибших самолётах
- здесь не было понимания реального состояния реактора
И в обоих случаях: невидимое оказалось важнее видимого
#thinking#engineering#ai#devops
📋 Disaster Recovery Plan: Как правильно заваривать чай, когда горит серверная.
• В жизни любого проекта наступает катастрофа. Мы не можем заранее знать, что именно это будет - короткое замыкание в серверной, инженер, дропнувший центральную БД или нашествие бобров. Тем не менее, оно обязательно случится, причем по предельно идиотской причине.
• Кстати, насчет бобров - это не шутка. В Канаде они перегрызли кабель и оставили целый район без оптоволоконной связи. А в топе источника проблем для крупной телекоммуникационной компании Level 3 Communications вообще были белки.
• Короче, рано или поздно, кто-то обязательно что-то сломает, уронит, или зальет неверный конфиг в самый неподходящий момент. И вот тут появляется то, что отличает компании, которые успешно переживают фатальную аварию от тех, кто бегает кругами и пытается восстановить рассыпавшуюся инфраструктуру - DRP. Вот о том, как правильно написать Disaster Recovery Plan мы сегодня и поговорим:
➡️Читать статью [10 min].
#DevOps
🗺 DevOps Roadmap
• Держите крутой и актуальный roadmap для DevOps, который включает в себя необходимые ссылки на обучающие материалы для каждого шага на этом пути.
➡️https://github.com/milanm/DevOps-Roadmap
- GIT;
- Learn one programming language;
- Learn Linux & Scripting;
- Learn Networking & Security;
- Learn Server Management;
- Learn Containers;
- Learn Container Orchestration;
- Learn Infrastructure as a code;
- Learn CI/CD;
- Learn Monitoring & Observability;
- Learn one Cloud provider;
- Learn Software Engineering Practices;
- Additional resources;
- Tools;
- Books.
#DevOps