#отказоустойчивость

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

С одной стороны, хочется поржать над 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, если на их запрос не отвечают, а не добивают лежачего, и, наконец, в-третьих, что даже глобальные добавления правил должны прилетать во все регионы не сразу, а с некоторыми задержками. Ещё обещают добавить эти проверки в свои статические анализаторы кода, завидую!

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

ФБ рассказал, почему они упали в понедельник.

Началось все с человеческой ошибки. В ходе обычной работы, кто-то дал системе команду, которая отключила все дата-центры Фейсбука от ее скоростной внутренней сети, которая связывает дата-центры Фейсбук друг-с-другом и со внешним интернетом.

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

В этот момент все сервера Фейсбука пропали с радаров интернета, Фейсбук для внешнего мира сломался.

Все было бы ничего, инженеры могли бы быстро включить все обратно, но у фейсбука есть специальная автоматизированная система, которая проверяет связность DNS серверов с дата-центрами компании и в случае проблем — отключает эти серверы от интернета. В понедельник, эта система отключила все DNS-серверы компании от интернета.

DNS — адресная книга интернета. Эта система переводит человеческий адрес Facebook.com в машинный айпи-адрес 157.240.224.35. Формально, интернет может работать и без DNS, в реальности на работе DNS завязано почти ВСЁ. Например, внутренние сервисы — инструменты, которыми пользуются инженеры фейсбука для решения проблем. Да что там сервисы, сотрудники фб в офисы не могли попасть, потому что автоматической системе контроля дверей тоже нужна DNS.

Дополнительная вишенка на торте — сломалась не только основная сеть фейсбука, но и запасная, которая построена специально для доступа к управлению сетевым железом в случае аварии основной сети. В общем, инженерам пришлось ножками топать в дата-центр и подключаться к сетевому оборудованию напрямую, буквально проводочком. Это непросто, потому что современные дата-центры — это крепости, попасть в них кому-то сверх обычного персонала — то ещё приключение. А теперь попробуйте это сделать, когда все корпоративные IT-системы недоступны. Подозреваю, что высшему руководству буквально по телефону приходилось подтверждать личность инженеров. Да и современное железо в ДЦ построено так, чтобы даже наличие физического доступа не дает контроля над ним — придется доказать, что ты не верблюд.

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

Конкретно от этой проблемы фб вряд ли пострадает во второй раз — программу проверки команд теперь будут тестировать на порядок лучше, да и DNS в будущем, вряд ли будет отключаться так легко. При этом, мы говорим об очень сложных системах и в них рано или поздно что-то пойдет не так. Такие крупные аварии, «идеальные штормы» происходят каждые несколько лет. Этот — не последний.

Нам же, простым смертным, это очередное напоминание, что стоит подстелить соломки и сделать так, чтобы наши сервисы, наши бизнесы продолжали работать, не теряли клиентов, даже если сломался такой гранд, как вацап или фейсбук. Когда все твои конкуренты вне доступа из-за крупной аварии — это шанс получить много новых клиентов, если ты продолжаешь работать. Хоть и баян, но: кризис — время возможностей.

Клиент поделился, что у них в дата-центре выбило электричество, а дизель-генератор выключился из-за жары. Результат — серьезный простой продакшена. Всё бы ничего, но это клиент, у которого я только что закончил аудит и на то, что у них свой ДЦ я достаточного внимания не обратил 🙈

ОК, добавляем пункт «аудит ДЦ, если он не дай бог не Tier 3» в чеклист.

Чеклист аудита написан деньгами, прямо как техника безопасности — кровью.

Как не уронить свой сервис под нагрузкой, на примере Signal.

Люди массово переходят из вацапа в Signal. Серверы Signal не выдержали и совсем лежали почти 14 часов, а испытывали серьезные трудности больше суток. Не лучшее время, чтобы падать :( Официальный твиттер сигнала при этом хранил молчание, будто это не модный стартап, а какая-то древняя корпорация. Жаль. Надеюсь, позже они опубликуют подробный разбор, что случилось.

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

В одном проекте именно так мы и сделали. Всё было хорошо, пока серверу не стало плохо на пару минут. Если обычно на сервер приходили 100 запросов в минуту (полтора запроса в секунду), то за три минуты скопились 300 запросов и теперь, стоило серверу очухаться, как ему насыпали все 300 запросов в одну секунду. То есть для сервера это выглядело как рост нагрузки в 200 раз и он опять ложился под нагрузкой. Очень неприятная ситуация. Мы сами себя задидосили, своими же собственными мобильными приложениями. 🙈

Есть две компоненты решения этой проблемы:

🛑 Первая: сервер должен уметь ответить «довольно!», и клиенты должны перестать повторять запрос, если получили такой ответ. Интересно, что именно этой функции в Android-клиенте Signal не было и они добавили её во время аварии.

⏱ Вторая, более сложная и интересная, но тоже классическая: exponential backoff (экспоненциальная задержка). Идея очень простая: если сервер не ответил в первый раз — ждем 1 секунду и повторяем запрос. Во второй раз — ждем 2 секунды, в третий — 4, в четвертый — 8. То есть с каждой неуспешной попыткой, даем серверу больше времени прийти в себя. У Signal эта функция реализована, но во время аварии они добавили jitter — небольшую случайную задержку, чтобы клиенты не набегали на серверу толпой, через одинаковые интервалы времени после его падения, а нагрузка была более плавной. Обычно, в этом же коде реализуют ещё паттерн circuit breaker, когда после определённого числа ошибок «выбивает пробки» и запросы прекращаются совсем.

Используйте оба приема и будьте здоровы!

💭 Есть твит и телеграм-пост в популярном канале, в которых утверждается, что причина падения сигнала — в само-дидосе (мол, анекдот). Это маловероятно. Во первых, exponential Backoff в сигнал внедрили больше 2 лет назад и он здорово распределяет нагрузку; во вторых, изменения коснулись только Android клиента. Не верьте советским газетам, читайте первоисточники.

Амазон анонсировал сервис для «chaos engineering» в своем облаке AWS. Система выключает случайные части инфраструктуры для того, чтобы проверить, как ваш сервис умеет противостоять реальным авариям.

В яндексе эта штука называется «учения», когда могут, например, выключить целиком какой-то датацентр и проверить, как разные сервисы продолжают работать в такой ситуации. Или выключить какой-то кабель, который соединяет два разных ДЦ, чтобы симулировать обрыв кабеля.

Этот подход сильно популизировал Нетфликс. В 2011 году они переехали в облако и тогда же анонсировали «chaos monkey» — «обезьяну хаоса», которая выключала (убивала) случайные продакшен серверы компании. Идея в том, что на определенном объеме серверов подобные проблемы неизбежны. Это не вопрос «сломается ли», а вопрос «когда сломается» и «сколько сломается». И лучше подготовиться и протестировать свои подходы и инструменты заранее.

Амазон предлагает и вариант с «днями учений» и автоматическую проверку системы при деплоях. Тот случай, когда придуманные гигантами технологии потихоньку просачиваются в повседневность.

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

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

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

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

❧

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

Github на прошлой неделе опубликовал postmortem, почему они лежали сутки. Язык тяжелый и перегружен жаргоном, executive summary отсутствует как класс, куча воды про «вы для нас очень важны». Текст — 3/5. Были бы на самом деле важны — сделали бы учения нормальные. Тоже мне engineering excellence.

Обрыв двух независимых 20kV линии питания и всей оптики до основных площадок обмена трафиком в Европе — не очень частая ситуация. Тем более хороший повод повторить основные правила.

Идеальная схема — когда запросы идут параллельно на две площадки у двух не-аффилированных провайдеров (не два ДЦ у одного и того же провайдера, а прямо разные компании). Админ в Букмейте был из старой гвардии Яндекса и поддерживал такое. В таком сетапе падение одного провайдера проходит незаметно для читателей. Это обычно сложно технически и стоит денег по ресурсам.

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

Уровень пониже – иметь систему, позволяющую быстро развернуть сетап у другого провайдера. Договор или аккаунт с нормальными лимитами, система управления конфигами типа ansible и тд и тп. Ну и свежие бэкапы, конечно же. В этом случае ожидаемый простой — часы.

В противном случае – молимся, постимся и слушаем радио Радонеж при каждом падении.

А у вас есть запасной канал интернета на такие вот случаи?
anonymous poll

Есть, не работаю в медиа – 301
👍👍👍👍👍👍👍 44%

Нету, не работаю в медиа – 288
👍👍👍👍👍👍👍 42%

Есть, я работаю в медиа – 45
👍 7%

Не знаю – 32
👍 5%

Нету, работаю в медиа – 23
👍 3%

👥 689 people voted so far.