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