Отсутствие единых подходов увеличивает количество инцидентов

Есть довольно распространенное заблуждение среди руководителей, склонных воспринимать разнообразие инженерных практик между разными командами компании как относительно безобидную, эстетическую особенность, никак существенно не влияющую на реальную надежность инфраструктуры в целом. Реальная статистика производственных инцидентов, накапливаемая индустрией год за годом, убедительно опровергает подобное благодушное отношение, демонстрируя вполне конкретную, причинно-следственную связь между разнородностью инженерных подходов и реальной частотой серьезных производственных проблем. Разберемся в механизме этой связи детально, потому что понимание конкретных причинно-следственных цепочек значительно убедительнее общих, абстрактных предостережений об опасности подобного разнообразия. Начнем с механизма, проявляющегося наиболее остро именно в момент серьезного, критического инцидента, затрагивающего сразу несколько команд или требующего оперативной помощи специалистов, привычных к совершенно иному набору практик и инструментов. Инженер, привыкший к определенному, знакомому способу диагностики проблем в рамках своей повседневной команды, оказывается вынужден экстренно, в условиях острого стресса разбираться в совершенно ином, незнакомом наборе инструментов другой команды именно тогда, когда скорость и уверенность реагирования имеют решающее значение. Подобная вынужденная переориентация неизбежно замедляет диагностику и устранение проблемы, растягивая продолжительность инцидента и, соответственно, увеличивая реальный, ощутимый бизнесом ущерб от каждого отдельного подобного события, вне зависимости от того, насколько технически компетентны привлеченные специалисты сами по себе. Механизм второй, связанный с разнородными практиками управления доступом и секретными данными, проявляется значительно тише, но не менее разрушительно. Компания, где разные команды применяют совершенно разные подходы к хранению чувствительных учетных данных, некоторые из которых достаточно строги и продуманы, а некоторые значительно менее надежны просто потому, что соответствующая команда никогда не инвестировала должного внимания в эту область, неизбежно создает неравномерную, непредсказуемую картину реальной защищенности своей инфраструктуры в целом. Атакующий, ищущий путь проникновения в подобную неоднородную инфраструктуру, естественным образом находит и эксплуатирует именно самое слабое звено этой цепи, вне зависимости от того, насколько строги практики защиты у остальных, более зрелых команд компании, что означает, что реальная безопасность всей организации в целом определяется не средним, а наименьшим уровнем защищенности среди всех ее разнородных команд. Механизм третий связан с невозможностью эффективного, масштабируемого применения общих, критично важных исправлений безопасности или архитектурных улучшений в масштабе всей компании при наличии значительного разнообразия базовых практик. Обнаруженная критичная уязвимость, требующая немедленного, скоординированного исправления во всех затронутых системах компании, о показательных примерах разрушительных последствий подобных уязвимостей в широко используемых компонентах инфраструктуры я подробно писал в отдельной статье про инцидент с контроллером входящего трафика Kubernetes, значительно сложнее оперативно устранить именно в разнородной инфраструктуре, где каждая команда применяет собственный, независимый способ управления развертыванием и обновлением своих систем, чем в инфраструктуре с единообразными, стандартизированными механизмами применения подобных обновлений сразу ко всей компании. Механизм четвертый связан с накопленной, но неравномерно распределенной зрелостью практик тестирования и проверки изменений перед их развертыванием в production.