Ходят слухи, что да, налили ошибочную конфигурацию на роутеры. Починить трудно, потому что люди, имеющие физический доступ к железу (сотрудники дата-центров) не имеют ключей доступа, а те, у кого есть ключи — находятся далеко от дата-центров.
Жуткая ситуация, когда сам себе отключаешь доступ к удалённому серверу. Каждый сисадмин хоть раз в ней был.
Представляю, какой ад там сейчас творится.
Фейсбук, Инстаграм и вацап упали. Судя по всему — что-то с сетью.
Ожидаемо, все последние крупные падения: что у гугла/ютуба, что у Яндекса — именно про сеть. Ее сложнее всего дублировать, разделять и тестировать, в ней больше всего ручного труда инженеров и возможностей для ошибок.
На картинке — твит техдира Cloudflare https://mobile.twitter.com/jgrahamc/status/1445068309288951820
Чего делать точно не стоит — это пытаться выдать аварию за штатную профилактику.
Так, на прошлой господрядчик пытался скрыть аварию в государственной системе, на которую завязана вся фарм отрасль России.
Зрелость инженерной организации проявляется не только в том, как редко случаются аварии — они бывают у всех. Зрелость в том, КАК компания реагирует на аварии. Но не буду повторятся, про это я уже писал подробно ранее: жемчужина от cloudflare и пример stackoverflow.
Мы в iGooods лежали почти полдня. Стыдно! Зря я угорал вчера над утконосом, что они упали. Поделюсь честно, от чего мы лежали. Это подробный постмортем аварии с техническими подробностями, мама, извини.
—
Из-за коронавируса к нам начали приходить в 2-3 раза больше клиентов, чем обычно. Плюс у нас на днях запускается два новых партнерства — с Joom и с магазинами Лента. Серверы работали на 40-60 процентах емкости и мы решили «добавить железа». В 6 вечера мы налили пару новых машин в кластер приложений, в час ночи по Москве — перетащили базу на новую, ультра мощную тачку. Обе операции — необычные для iGooods, множество вещей делалось руками. Ошибка №0 — мы сделали 2 крупных изменения близко друг с другом
В 7 утра по Москве, сервер базы данных начал плавиться от нагрузки в процессор. Это компьютер с 70 ядрами, но базе нужно было минимум 300. Запросов было вроде бы не сильно больше, чем обычно, но занимали они всё больше времени. Люди просыпались у себя дома и начинали делать заказы — сервера умирали, сайт не открывался, приложения выдавали ошибки. Самое опасное — курьеры и сборщики заказов выходили на работу и не могли работать.
Мы, конечно, думали, что сможем быстро починить проблему. Через час стало понятно, что нужно хотя бы временное решение. Мы выключили все пользовательские интерфейсы iGooods, оставив рабочей только админку и внутренние приложения курьеров и пикеров (сборщиков заказов). Ошибка №1 — в случае аварии не нужно пытаться «сделать хорошо», нужно определить критичные сервисы и восстановить их первым делом.
Мы решили, что проблема в новой базе данных. Мало ли, конфигурация, железо, да хоть драйверы. Попытались вернуться на старый сервер. Мы не сохранили WAL логи между переездами, так что вместо 3 минут эта операция заняла 40 минут — пришлось перегнать всю базу данных между серверами. Мы планировали откат для приложений, но не для переноса базы — он нам казался довольно безопасной операцией. Ошибка №2 — мы решили, что «уж тут-то не взорвется», на самом деле вместе с любым изменением нужно продумывать пути отката.
Возвращение на старый сервер базы данных не помогло. Каждый раз, когда мы включали пользовательские приложения — база данных мгновенно уходила в несознанку и работа бэкофиса парализовалась. Сайт и мобильные приложения к тому моменту лежали уже больше нескольких часов. Самое страшное — мы всё ещё не были уверены, что проблема не в базе данных.
В конце концов, Женя случайно заметили ошибку, что наше rails приложение не может записать в redis-кеш. BINGO! Вот тут всё наконец-то встало на свои места. В нашем приложении есть много страниц, которые собираются очень долго. Все они кешируются rails'ами в redis. И вот этот редис кеш у нас отвалился на запись на части серверов приложений из-за кривых настроек окружения (душераздирающие подробности приложены картинкой). Кеш протухал постепенно и с каждой потерянной записью все больше тяжелых запросов грузили Postgres. Ошибки №3, 4 и 5: настройка тачек производится руками, не кодом; логи переполнены, так что сложно заметить новую ошибку; не все важные сервисы (redis, rails cache) включены в мониторинг.
Как вы можете видеть, всё довольно банально. Будь у нас настроена нормальная рабочая среда — не было бы такой аварии.
Итак, чего нам не хватило и что мы приведем в порядок:
- инфраструктура в коде (полный ansible вместо хождения руками на серверы);
- хороший, чистый мониторинг всех ключевых метрик приложения, APM — за день до аварии мы включили Datadog, но ещё не было нормальных дэшбордов и исторических данных;
- сообщения об ошибках (у нас bugsnag) засраны нерелевантными сообщеними — их нужно почистить.
Мы с Федей обозначили проблемы в первые же дни, но не успели решить их — были вещи поважнее. Знал бы прикуп — жил бы в Сочи.
Если у вас похожая ситуация — рекомендую навести порядок заранее, не ждать форс-мажора.
Ну и делать много сложных правок вместе — чревато. Стоило разнести перенос базы и деплой новых машин на день — тогда бы мы не потратили так много времени на ложный след тормозной базы.
Fin.
Очередной шедевр от Cloudflare — подробный отчет об аварии 2 июля.
Рассказ начинается с личной истории. Девять лет назад автор был клиентом, а не сотрудником, и основатель компании Мэтью Принс написал ему детальное письмо в ответ на жалобу о проблеме. Теперь он пишет аналогичный текст нам после падения 2 июля.
Внутри — как у них устроен процесс разработки и деплоя, 11 причин, сочетание которых привело к аварии; что они сделали, чтобы подобная ситуация не повторилась, какие дальнейшие планы и даже разбор, как именно регулярное выражение съело все ресурсы процессора.
После такого ответа я доверяю Cloudflare гораздо больше, чем до аварии. Ошибки и аварии в сложных IT-системах неизбежны. Важно, что они вызваны не вопиющей некомпетентностью и как компания на них реагирует, учится ли она на ошибках. Побольше бы таких текстов и таких компаний.
Слек сегодня глючил весь день - это у них проблемы, а не с вайфаем в офисе. Уже 6 час не могут починить.
Классная формулировка на странице статуса: «Though we saw signs of improvement earlier, unfortunately the fix we had in mind didn't do the trick.»
«Казалось, дело идёт на поправку и мы нашли решение, но оно не сработало. Работаем дальше.»
Спасибо Александру Арбузову за наводку в чате.
Описание вчерашней сетевой аварии опубликовал в своем блоге Cloudflare. Ниже мой перевод первого абзаца на скорую руку, оригинал лучше:
Сегодня в 10:40 UTC у интернета случился сердечный приступ. Небольшая компания в Северной Пенсильвании стала избранным путем (preferred path) многих соединений крупнейшего транзитного провайдера Verizon. Представьте, что Яндекс.Карты завернули весь трафик МКАДа через маленький переулок. Клаудфлер, вместе с многими другими хостингами стал недоступен для больших частей интернета. Всё началось с того, что Verizon анонсировал свои внутренние пути во внешний интернет. Почему так вышло — читайте дальше.
Обожаю, когда объясняют сложные события с самых основ и не упускают важных деталей, раскрывая их суть по мере рассказа. ❤️💪
Один из крупнейших и самый дешевый CDN на свете Cloudflare испытывает проблемы с сетью.
Многие сайты могут быть недоступны. Я лично помогал включить Cloudflare десятку медиа, у RAWG отвалились картинки.
Сохраняйте спокойствие, это не блокировки, скоро все починят. Отвечая на вопрос, который вы задаёте своим программистам: да, от этого можно защититься, но для большинства сайтов польза будет меньше вложенных сил.
Гугл опубликовал публичный постмортем про воскресную аварию. Текст длинный, но суть простая: у них ломается сеть, если специальная программа не подвозит правильную конфигурацию сети (BGP) каждые пару минут. Несколько копий этой программы запущены на отдельных серверах в каждом дата-центре (отказоустойчивость!). Эти серверы включает-выключает другая программа управления конфигурацией. Во второй программе была ошибка, из-за которой она выключила все копии первой программы. Через пару минут после этого протухли BGP-анонсы и развалилась сеть.
Из-за сломанной сети были недоступны внутренние инструменты, которыми пользуются сисадмины при исправлении проблем. Гугл говорит, что у них есть специальные бункеры с какими-то особыми доступами, но пока админы туда доехали — прошло дополнительное время. Самое главное, что система конфигурации потеряла своё внутреннее состояние и админам пришлось заново настраивать всё руками — это заняло очень много времени.
Чинят тем, что 1) запретят подсистеме выключения задач тушить сразу несколько серваков 2) система не будут терять состояние при потушенных серверах (не придется настраивать её заново руками) 3) сеть будет дольше работать без внешней поддержки программой управления (самое очевидное решение).
❧
Не постесняюсь ещё раз напомнить, что бэкапы нужно держать у второго провайдера и регулярно тестировать восстановление.
Ходят слухи (пикабу, хабр), что Яндекс вчера случайно удалил виртуальные серверы клиентов в своем облаке (человеческий фактор).
Это отличное напоминание настроить бекапы (если вдруг их нет) и проверить, как работают процедуры восстановления.
Я не собираюсь шеймить яндекс за потерю данных клиентов — технических проблем в любом сложном проекте не избежать. Разбираться с такими ситуациями и улучшать системы по полученным урокам — часть нормальной работы. Если система построена правильно, то вероятность аналогичной аварии в будущем сильно упала.
Внушают опасение слухи, что клиентам написали письма о проблеме только через несколько часов и никакой публичной реакции Яндекса на ситуацию до сих пор нет.
Интересно, там было затронуто так мало машин, что они не видят видят причин официально комментировать? Классическое «это затронуло 0.004% клиентов и вот что мы сделали, чтобы такого больше не случилось» — тоже часть работы.