Это случилось с гигантом онлайн-торговли. Сайт Amazon лёг, причём не на 5-10 минут — на три долгих часа. Основатель — мультимиллиардер Джефф Безос — теряет миллионы каждую секунду. В штабе — хаос. Ему срочно нужны ответы. А виновник уже известен — новоиспечённый системный администратор Кен. Но что именно он сделал?
Неопытность под прикрытием
Историей поделилось издание The Register, сотрудникам которого удалось поговорить с Кеном. Как оказалось, мужчина получил работу, блеснув знанием операционной системы Solaris.
Но беда в том, что его реальной рабочей задачей стало администрирование другой ОС (Red Hat Linux (RHEL)), с которой он был знаком лишь приблизительно. «Я был совершенно не готов», – признался Кен позже.
Руководство, однако, поверило в него и поручило обновить систему резервного копирования.
Мнимый успех
Только сам Кен прекрасно понимал, что его знаний мало для выполнения такой задачи. Не хватало бесценного опыта.
Но делать нечего. Кен решил компенсировать этот недостаток своими усилиями. Начался длительный период планирования и тестирования.
Спустя несколько месяцев наступил День Х. Кнопка нажата. Система работает безупречно! Члены команды облегчённо вздыхают, поздравляют друг друга и расходятся по домам. Кен доволен: сложнейшая миссия выполнена.
Ночной кошмар
И вот вечером того же дня тишину взрывает бешеный треск пейджера (дело было в начале 2000-х). Сообщения обрушиваются лавиной: «Amazon.com упал! ВСЁ!»
Кен в панике подключается к телеконференции. Голос на другом конце леденит кровь: это сам Безос. Вопрос один: «КАК ЭТО ПРОИЗОШЛО?!» Давление невообразимое.
Сбой кажется парадоксальным: серверы целы, но главная база данных мертва. Обновлённое резервное копирование работало идеально, правда? Все это видели. Поэтому сложно представить, что могло пойти не так.
Кен и команда лихорадочно ищут причину. Они проверили скрипты вдоль и поперёк. Всё чисто, но сайт не работает! В чём же роковая ошибка?
Развязка
Лишь спустя часы адского напряжения, когда надежда уже таяла, Кен совершил прорыв. Отбросив все сложные версии, он вернулся к основам — к тем самым файлам конфигурации, которые тщательно создавал вручную. И там, в одной неприметной строке, таился дьявол. Опечатка. Не в команде удаления, а в настройке. Из-за неё система резервного копирования, вместо того чтобы очищать старые логи после успешного бэкапа... попросту никогда их не удаляла.
«В течение многих часов это не было проблемой, — позже объяснил Кен. — Но в конце концов раздел, содержащий журналы, заполнился до отказа. И база данных просто... сдалась. Буквально заявила, что больше никому не нужна».
Роковая мелочь, такая как пропущенный символ, превратила его кропотливую работу в мину замедленного действия. Диски переполнились не мгновенно, а тихо, постепенно, пока БД не переполнилась до отказа журналами.
Спасение пришло мучительно: Кен с командой вручную, под пристальным взглядом всего руководства, удалили гигабайты ненужных логов, освобождая драгоценное пространство. И только тогда Amazon.com, содрогнувшись, вернулся в строй.
Эта история 20-летней давности сейчас могла закончиться иначе: автоматизация и надежная инфраструктура — ключ к предотвращению кошмаров переполненных дисков. Если в решении подобной задачи (резервное копирование данных) полагаться не на вручную написанные скрипты а довериться профессиональным решениям, таким как резервное копирование в облако от Cloud4Y, то это исключит человеческий фактор и обеспечит отсутствие ошибок и стабильную работу сайта.
Одна невидимая глазу помарка в конфиге — три часа простоя гиганта и незабываемый урок о цене высококлассной автоматизации, опыта и пристальной внимательности.