🛠 История одного факапа: аптайм-бомба Cisco
Сейчас будет охуительная история про то, как сомнительные решения бизнеса, помноженные на дерьмовый сервис провайдера и стрёмный баг вендора, приводят к аварии уровня девять с половиной баллов по шкале «ёбаный стыд».
Сомнительные решения бизнеса
На начало 2017 года владение собственными вычислительными мощностями(если вы, конечно, не planet-scale сервис) уже выглядело чем-то… странным: новое железо выпускается каждый год и стремительно дешевеет; старое при этом превращается в пожирающий электричество нагреватель воздуха. Тем не менее, в 2015 году зачем-то было куплено 12 серверов, ставших через два года стопкой бесполезного металлолома. Новая инфраструктура для сайта была собрана из арендованных машинок. Уже лучше, но по каким-то не очень известным мне причинам было решено сделать демилитаризованную зону с доступом в Интернет через два дублирующих друг друга NAT-шлюза Cisco ASA с одинаковыми конфигами. Веб-сервис большой, нагрузки приличные, денег приносит много; подразумевалось, что дорогое оборудование в лизинг и сервис 24/7 могут предотвратить любую катастрофу, надо лишь будет перебросить DNS в непредвиденной ситуации.
Пока всё выглядит просто, да? А вот хуй там плавал. Никто не мог даже в самом кошмарном сне представить, что весь отдел будет печально таращиться друг на друга сраных три часа, в течение которых наша дойная корова лежала копытами кверху и даже не мычала.
Дерьмовый сервис провайдера
Все семнадцать серверов плюс два шлюза Cisco ASA были арендованы у одного британского провайдера, по заверениям одного из крупнейших(если не рассматривать AWS, тогда это было для нас дорого).
Однако, крупнейший не значит лучший. У саппорта этого провайдера были серьезные проблемы с внутренней коммуникацией: заступающие на смену сотрудники ни пизды не понимали что и как до них сделали их предшественники днём ранее, поэтому средний таймлайн пустяковой процедуры мог выглядеть так:
— 15:00, среда, открываю тикет: "Hi folks! Our server reports high temperature ratio. Could you please perform an ACPI shutdown and look if there are any broken CPU fans? Thanks in advance!"
— 16:55 того же дня, приходит ответ: "Dear customer, thank you very much for your request, we really value our partnership. Are you sure you want us to perform this operation?"
— 16:57, с лёгкой ноткой ахуя и раздражения: "Yes, we are sure, please proceed."
— 12:30, четверг, приходит очередной ответ от другого сотрудника поддержки провайдера: "Dear customer, thank you very much for your reply, we really value our partnership. Are you sure you want us to perform this operation? It can cause potential data loss"
— …
Yes, блять, we are pretty kurwa sure we want you to perform this operation.
Каждый милиписечный запрос на поддержку(диск поменять, порт на шлюзе перенаправить) превращался в ёбаный футбол по переписке, который растягивался на два или три дня. В моменты же аварий о наличии службы поддержки можно было только догадываться. Короче, о реальных попытках поднять инфраструктуру, которая лежала кишками наружу, мы узнали только через два с половиной часа.
Стрёмный баг вендора
Все мы знаем и любим Cisco. Для многих этот бренд является синонимом пуленепробиваемого сетевого Энтерпрайза. На поверку оказалось, что этот самый Энтерпрайз нихуя не пуленепробиваемый.
Как было сказано ранее, мы поставили перед нашими серверами два шлюза Cisco ASA с проброшенными портами. Ну, шоб редандэнси, все дела. Если один сдохнет, то всегда можно будет перебросить A-запись на другой IP, и т.п.
В день происшествия выстрелил очень стрёмный баг. Если кратко, то после 213 дней аптайма шлюзы Cisco ASA превращались в тыкву, переставая пропускать через себя абсолютно весь сетевой трафик. При этом херился рантайм конфиг и помогал только хард ресет и последующая перепрошивка.
Ну, думаем, хуйня война, щас перебросим DNS и всё станет заебок.
.
.
.
.
.
.
.
.
Через пять минут мы узнали, что оба Cisco ASA были запущены с разницей в десять секунд.
Mon, 15 Jul 2019 13:48:08 +0200
RSS // Telegram // Статистика