#постмортем

Подъехал пост-мортем от Амазона.

С одной стороны, хочется поржать над DNS Enactor, DropletWorkflow Manager (DWFM), Network Manager и прочими — это Galactic от Krazam, только в реальном мире и на очень серьезных щщах.

Если без шуток, то цепочка такая:

1. сначала сломался доступ к dynamodb из-за рейс-кондишена системы управления DNS — два таска начали писать в DNS одновременно, первый старую версию записей, второй — более новую новую, в результате часть записей в DNS оказалась новая, часть старая, второй процесс запустил cleanup, который удалил все старые записи и из такого разломанного состояния система сама восстановиться не могла. Сломалось в полночью, за 50 минут поняли в чем дело и ещё за 40 минут починили руками.

2. из-за сломанного dynamodb, система управления железом не могла обновить статус физических серверов и начала отмечать их как «недоступные», поэтому не могла запустить новые виртуальные машины; после восстановления dynamodb, по-идее всё должно было встать само, но из-за большого объема железа, стоящего в очереди, обновление статуса занимало дольше, чем таймаут — и очередь не разгребалась, а только росла. Коллапс. Стандартной процедуры восстановления для такого случая прописано не было, через 2 часа попыток что-то разрулить, инженеры ограничили число входящих запросов и начали перезапускать тачки с системой управления; это помогло, теперь можно было создать новые виртуальные машины;

3. но ещё какое-то время эти новые виртуалки не делали никакой полезной работы, потому что из-за взрывной нагрузки не справлялась система управления разлива конфигурации сети и сеть на новые тачки приходила с задержкой;

4. из-за этой задержки появления сети на машинах, моргали статусы серверов в лоад-балансерах, отмечая живые инстансы как мертвые и триггерились дополнительные переключения нагрузки (привет, DNS!) и перегрузилась система проверки здоровья серверов,
пришлось её на время выключить.

Ну а когда у вас не доступны базы данных и виртуальные машины, то все остальное уже валится по цепочке (и список десятков облачных сервисов, которые пострадали).

Раздел «что мы поменяем» удивительно короткий и очень технический: починят рейс кодишен в DNS, ограничат объем серверов, который может выключить лоад-балансер и т. д. Ну и заканчивают «извините, в будущем будем более лучше стараться».

Интересно, что они не делают никаких философских выводов из ситуации. Видимо, считают, что идейно всё верно. Я сам такими огромными системами (и командами) не управлял и поэтому осторожно предположу, что, наверное, технически, можно сделать систему проще, но учитывая, что над ней работают десятки независимых команд — это, наверное, минимальный доступный объем сложности и допустимый объем ошибок. Было бы интересно услышать мнение «настоящих сварщиков».

—

Коллеги советуют замечательную статью на тему безопасности сложных систем. Она не дает ответов, но предостерегает от попытки найти «root cause», «причину аварии» и предлагает посмотреть на безопасность систем по-новому, через другие линзы, чем я привык. Очень рекомендую.

Гугл опубликовал пост-мортем по позавчерашнему падению. Обычные ошибки, только на инфраструктуре планетарного масштаба.

У них есть внутренний сервис, который проверяет доступы (бабки, квоты и т. д.) перед тем, как API запрос доходит до любого продукта.

Эта программа берет из специальной глобальной базы данных правила, по которым проверяет каждый запрос и отвечает, пропускать его или нет.

В эту программу добавили поддержку нового типа квот. Программист допустил небрежность в новом коде и не проверял, насколько корректно записано это правило в базе, перед тем, как пытаться положить его в память. Обращение к несуществующей памяти — смертный грех, за такое программа мгновенно завершается (если программист не предусмотрел, что такое может случиться, а это не наш случай). При этом я бы не назвал это ошибкой, все мы люди, мы не идеальны и поэтому придумываем механизмы защиты от своей природы. В этом суть инженерного подхода.

Экземпляр этой программы работает в каждом регионе Гугла. Так как это серьезный, ключевой сервис, его выкатывают не во все регионы сразу, а по одному, внимательно отслеживая, не внесли ли программисты новые ошибки.

Более того, весь новый функционал специально помечают и сначала запускают только для внутреннего пользования, чтобы, даже при наличии ошибки, она не задела внешних клиентов. Этот механизм называется фича-флагами.

К сожалению, программист забыл настроить фича-флаги для этого кода. Кусочек программы с ошибкой запустился на всех пользователей сразу. Удивительно, что это не заметили на этапе code review!

Итак, проходит время, и вот программа с ошибкой запущена во всех регионах для всех пользователей. Кто-то добавляет в базу данных новое правило с новым типом квот, с пустым полем. Эта запись в течение десятков миллисекунд копируется во все регионы, и в каждом регионе программа проверки считывает новое правило, пытается обратиться к несуществующей памяти, падает, перезапускается и снова падает.

Тут в дело вступает, на мой взгляд, первая ошибка (а не просто человеческая небрежность) инженеров — система контроля доступа настроена так, что при отсутствии ответа от программы проверок она отклоняет запрос. Так называемый fail closed. Хорошо для замков на банковских сейфах, плохо для пожарных выходов.
В нашем случае система не пропускает ни один запрос.

Дежурные инженеры замечают проблему в течение 2 минут, за 10 минут находят причину (дежурная система и дежурные инженеры у Гугла достойны восхищения) и нажимают большую красную кнопку, которая должна выключить эту часть программы (ее программисты сделали). Ее включение занимает еще 30 минут. (Не понятно, почему этот механизм занимает 30 минут, а не 20 миллисекунд, но движемся дальше).

Система заработала, но из-за того, что она лежала 40 минут, накопилось много желающих отправить запрос еще раз, и они создали эффект толпы, которая набежала и перегрузила остальные соседние сервисы через наш сервис проверок. Оказалось, что он не ждет какое-то время, если нужный сервис отказывается ответить на запрос (для этого есть красивая схема exponential back off), а долбит до упаду, тем самым не давая системе возможности восстановиться. Пришлось руками ограничивать число запросов. На постепенную, ручную разгрузку очередей ушло еще 2 часа.

Ко всему прочему, Гугл час не мог опубликовать уведомление о проблеме, потому что сервис публикации статус-страниц зависит от системы, которая упала.

Как вывод, Гугл обещает пройтись по всем сервисам и убедиться, что они, во-первых, fail open, то есть пропускают запросы, когда падают, во-вторых, реализуют exponential back off, если на их запрос не отвечают, а не добивают лежачего, и, наконец, в-третьих, что даже глобальные добавления правил должны прилетать во все регионы не сразу, а с некоторыми задержками. Ещё обещают добавить эти проверки в свои статические анализаторы кода, завидую!

Первые два пункта можно и нужно использовать в каждом проекте, даже если ты не Гугл.

В 21:46 мск отказала большая часть гугловского облака GCP. Ходят слухи, что всё из-за одного ключевого технического внутреннего сервиса, но в результате в разной степени поломались гугловские продукты, вроде Cloud, Drive, Meet, Gmail.

Предположительно, из-за этого начал глючить Cloudflare, один из самых популярных CDN-провайдеров.

Дальше по цепочке легла половина интернета — Spotify, Discord, Snapchat и тысячи других. Особенно тревожно, что для многих людей сломался RCS — это протокол, продвигаемый Гуглом, который должен заменить смски.

Предвкушаю увлекательные постмортемы от Гугла и Cloudflare, последние уж точно не упустят шанса рассказать, что это было.

В тысячах инженерных команд по всему мира сейчас была жара — все тушили пожары. А завтра все сядут составлять списки, что нужно поменять, чтобы в следующий раз было не так больно. Так и живем.

P. S. Про одновременное падение Amazon Web Services — кажется дезинформация.

Мы в 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-системах неизбежны. Важно, что они вызваны не вопиющей некомпетентностью и как компания на них реагирует, учится ли она на ошибках. Побольше бы таких текстов и таких компаний.

Гугл опубликовал публичный постмортем про воскресную аварию. Текст длинный, но суть простая: у них ломается сеть, если специальная программа не подвозит правильную конфигурацию сети (BGP) каждые пару минут. Несколько копий этой программы запущены на отдельных серверах в каждом дата-центре (отказоустойчивость!). Эти серверы включает-выключает другая программа управления конфигурацией. Во второй программе была ошибка, из-за которой она выключила все копии первой программы. Через пару минут после этого протухли BGP-анонсы и развалилась сеть.

Из-за сломанной сети были недоступны внутренние инструменты, которыми пользуются сисадмины при исправлении проблем. Гугл говорит, что у них есть специальные бункеры с какими-то особыми доступами, но пока админы туда доехали — прошло дополнительное время. Самое главное, что система конфигурации потеряла своё внутреннее состояние и админам пришлось заново настраивать всё руками — это заняло очень много времени.

Чинят тем, что 1) запретят подсистеме выключения задач тушить сразу несколько серваков 2) система не будут терять состояние при потушенных серверах (не придется настраивать её заново руками) 3) сеть будет дольше работать без внешней поддержки программой управления (самое очевидное решение).

❧

Не постесняюсь ещё раз напомнить, что бэкапы нужно держать у второго провайдера и регулярно тестировать восстановление.

Поведение при факапе - отдельное искусство.

Сильно упрощая: хостер Digitalocean заблокировал аккаунт клиента и потушил продакшен-серверы стартапа без предупреждения, не дал даже данные выгрузить (автоматический антифрод, да).

Твит про это капитально бомбанул, на ситуацию обратил внимание основатель компании и вот Digitalocean публикует образцовый постмортем.

В нем есть все: и честная фактология произошедшего, и признание ошибок и четкий, полный план что они делают для того, чтобы не допустить эту ошибку в будущем.

5/5

P.S. Ещё одно напоминание об опасности держать все яйца в одной корзине. Как минимум бэкапы должны быть у второго провайдера.

Прошлой ночью по Москве у гугла прилегла сеть в Штатах. 4 с половиной часа, с 12 до 17 PT. Проблемы затронули как собственные сервисы Gmail, YouTube и прочие так и клиентов облака: Snapchat и другие.

Гугл потерял «три девятки» (99.99% доступности сервисов) в этом квартале.

С нетерпением ждём постмортем. Ожидаемо, что надёжность сети - последняя нерешенная проблема облаков. Интересно, как они её в результате решат и решат ли в принципе.

Мои сочувствия ребятам из России, у которых пользователи/клиенты в штатах (обычно я им завидую:). У вас была горячая ночь.

Ну и это хорошее напоминание нам всем, что для критических сервисов имеет смысл посчитать стоимость резервирования хостингов.

StackOverflow продолжает рассказывать, как их поломали и что они делают для того, чтобы защититься в будущем.

Не забывают по пути объяснять, какие они молодцы и как у них все правильно устроено. Качественный PR.

Яндекс выкатил пресс-релиз на Роеме. В таймлайне не указано, когда они уведомили пользователей о проишествии, а ведь поддержка — один из параметров, по которому мы выбираем хостинг.

«Мы уже работаем над формированием мер для предотвращения повторения подобного инцидента в будущем и в ближайшее время проинформируем о дальнейших шагах всех пользователей.»

Интересно, будет ли более подробный post mortem в этом информировании?

P.S. А ведь было время, когда Яндекс говорил отличным русским языком; помню, студентом мечтал там работать в том числе из-за языка на сайте (древнегреческое «красивый не может быть плохим»). Эх.

Upd: ну наконец-то приличный текст от руководителя Яндекс.Облака. Был бы я журналистом — продолжил бы долбить про «считаете ли вы нормальным писать пользователям об удалении их сервера через 6 часа, а не сразу же», но думаю, что эта история и так заняла слишком много внимания и нечего так напрыгивать на национальное достояние. ❤️ спокойной ночи