Небольшая опечатка в конфигурационном файле системы резервного копирования привела к трехчасовому простою сайта Amazon. Эта ситуация произошла около 20 лет назад, но если бы инцидент случился сейчас, финансовые убытки могли бы измеряться миллионами долларов.
Об этом сообщает ProIT
Как одна ошибка привела к масштабному сбою
В основе этой истории — системный администратор по имени Кен, который в начале 2000-х годов устроился на работу в Amazon. Хотя на тот момент он не имел достаточной квалификации для администрирования Linux, его опыт с Solaris позволил ему получить должность. После быстрого изучения основ Linux Кен столкнулся с существенными отличиями между Red Hat Enterprise Linux и Solaris. Несмотря на пробелы в знаниях, руководитель поручил ему обновить систему резервного копирования на ленточных накопителях.
«Я потратил месяцы на планирование и тестирование, потому что с этим обновлением файлы конфигурации изменились, и нам пришлось создавать новые и выпускать их вместе с обновлением», — рассказывает Кен. «Я создал эти файлы и провел все необходимые тесты. Казалось, что все в порядке, и настал день, когда мы нажали кнопку».
После запуска обновления в течение нескольких часов все работало без сбоев, так что Кен был доволен результатом. Однако вечером его пейджер неожиданно активировался, и вскоре он присоединился к срочному конференц-звонку, в котором участвовали топ-менеджеры Amazon, включая Джеффа Безоса. Основной вопрос — почему сайт полностью перестал работать?
Во время проверки удалось выяснить, что база данных Amazon отказалась функционировать, хотя основная вычислительная инфраструктура оставалась стабильной. Кен вспомнил, что его программа резервного копирования переносила журналы базы данных на ленту, а затем должна была удалять их с серверов. Оказалось, что из-за опечатки в конфигурационном файле процесс удаления не завершался. Это привело к переполнению раздела с журналами, и база данных остановилась.
Восстановление работы и реакция руководства
Убедившись, что все журнальные файлы сохранены, Кен удалил их вручную из кластера. После этого база данных и сайт Amazon вернулись к нормальной работе. Сисадмин исправил ошибку в конфигурации и провел неспокойную ночь, готовясь к возможным последствиям для своей карьеры.
На следующее утро Кена встретил его менеджер у парковочного места, что не предвещало ничего хорошего. Однако, после нескольких секунд молчания, руководитель улыбнулся и пошутил, что Кен «потерял девственность» как настоящий системный администратор. В офисе над ним еще долго шутили, но для молодого специалиста это стало ценным опытом.
Эта история еще раз подтверждает: даже незначительная ошибка в настройках может привести к серьезным последствиям для крупных компаний, особенно если речь идет о IT-инфраструктуре глобального онлайн-гиганта.