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