авария

Cloudflare опять упал, Zoom поэтому не работает (и половина интернета вместе с ним), не удивляйтесь.

Upd: поднялись в течении 20 минут.

Доброе утро! А вот у южнокорейских государственных айтишников — не очень доброе, потому что они не делали бэкапы до сих пор восстанавливают инфраструктуру после пожара в серверной.

У большинства систем были бэкапы, но удаленное хранилище файлов, которым пользовались 17% всех госслужащих страны — не имело бэкапов. Безвозвратно потеряны терабайты документов. Делайте бэкапы!

Кстати, у этой истории есть ещё и шпионское измерение: в июне 2025го двое хакеров взломали северокорейского (китайского?) хакера, который взломал LG и кучу южнокорейских государственных систем. Дали об этом знать южнокорейским правоохранителям, которые в августе перестали выходить на связь. А дальше уже совсем мистика: кто-то пишет им с одноразового номера в сигнале «Proton небезопасен», после чего Proton блокирует почтовый ящик, с которого они вели коммуникацию только с южнокорейскими властями, но разблокирует после публикации.

24 сентября южнокорейский парламент начинает расследование взлома, 25го анонсирует физический аудит дата-центра, 26го — пожар. Подробности и ссылки на дампы с компьютера хакера — в легендарном журнале phrack.

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

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

Помните, на прошлой неделе Cloudflare упал и уронил половину интернета?

Они пишут одни из лучших post-mortem’ов в индустрии. Последний — не исключение.

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

Но самое впечатляющее для меня в этой истории — вот этот комментарий пользователя eastdakota на форуме hacker news.

Это Мэтью Принс, основатель и генеральный директор компании, которая обслуживает 20% всего интернет-трафика, рассказывает, как он сначала сидел на созвоне по починке аварии, а потом пригласил к себе домой бывшего техдира (тот захватил сына, показать, какая у папы работа) и главного юриста компании и они на троих сообразили текст в гугл-доке. Задали в нем вопросы технарям компании. Заказали еды. Включили ответы на вопросы в текст. Дали вычитать технарям. И опубликовали. И получился пост-мортем. ❤️

Все заметили, что в последние недели Клод отупел и жрет токены как не в себя.

Ходили слухи, что это потому что у Антропика не хватает видеокарт.

Теперь они утверждают, что дело в ошибке в их обвязке Claude Code и что «они никогда не отупляют модели специально». Выпустили исправление и сбросили лимиты токенов в этом месяце. Подробное объяснение тут

В Германии уже третий час не ходят поезда, упала специальная сотовая сеть GSM-R, которая поддерживает связь между машинистами и диспетчерами и обмен технической информацией между поездами. Чтобы не было столкновений, все поезда встали.

На немецком ЖД-реддите ходят слухи, что причина в кривом обновлении софта.

Я и не знал, что у поездов есть своя сотовая сеть из 90-х. У нас уже 5G, а поезда на 2G.

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

P. S. Недавно узнал, как работали римские акведуки. Там, оказывается, вода становилась чистая за счет точно рассчитанного наклона трубы; вода течет медленно и вся грязь оседает, но и не слишком медленно, чтобы не застаивалась. 🪄

Гитхаб в последнее время сильно сбоит.

В дополнение к инциденту с merge queue, за последние дни успели сломаться поиск и показ пул-реквестов.

Техдир сервиса Владимир Федоров в своем покаянном посте пишет, что причина — во взрывном росте активности на платформе из-за нейросетей (см картинку).

Обещает, что теперь они будут работать над стабильностью, масштабируемость и перестанут гнаться за фичами.

Внешние наблюдатели подозревают две причины: 1) плохой вайбкодинг в Microsoft 2) сложный переезд с собственной инфраструктуры на Azure.

И вот уже знаменитый Митчел Хашимото пишет длинный эмоциональный пост, что уносит репозиторий своего проекта ghostty с гитхаба.

❧

Создать git репозиторий можно без всяких сервисов — это просто файлы на диске. Гитхаб выигрывает за счет удобного контроля доступа, интеграции с ci/cd инструментами, удобного веб-интерфейса для комментирования и тысячи мелочей.

Есть десятки конкурентов, но ни один не дотягивает до качества github. Раньше это был «лучший инструмент, который можно купить за деньги», а теперь он становится одним из многих, со своими плюсами и минусами. Прямо падение гиганта.

Конечно, у таких сервисов огромная инерция, но очень интересно, куда побегут «модные ребята», которые задают тренды. Будет ли это новый классический конкурент со взрывным ростом или что-то распределенное и децентрализованное, соответствующее базовой философии гита?

Большая часть облачных сервисов AWS лежала почти 3 часа. Если у вас глючили Слек, Зум, Сигнал и прочие — это всё от этого. Уже поднимаются. Официальный статус тут.

Как обычно, система поддержки AWS тоже легла. Говорят, что из-за проблем с DNS отвалилась база данных DynamoDB на восточном побережье США, ну а дальше эффект домино. Ждем официального post mortem.

Время шутки, что один сервак в hetzner может дать больший аптайм, чем вся современная облачная инфраструктура.

Очень неприятная история с потерей данных на гитхабе.

Если у вас активная разработка и пул-реквесты конкурируют между собой при мерже в main, то гитхаб предлагает решить это через merge queue, который мержит PR-ы по очереди.

Так вот из-за бага в коде, часть ранее замерженных коммитов пропадала из main в течение четырех с половиной часов начиная с 2026-04-23 16:05 UTC.

Страшно представить, как такое дебагать.

И как вообще вести разработку, если не можешь доверять системе контроля версий, что она не потеряет коммиты? 🤷‍♂️

Уверен, что по всему миру инженеры думали, что сходят с ума.

Ну а дальше github предлагает исправлять это руками... Sic transit gloria mundi

Удивительно наблюдать, как гиганты (не)справляются с вайб-кодингом:

Github потерял последнюю девятку в своем SLA. Отдельно замечу, что status page вендоров уже давно нельзя верить и вот люди собрали собственный, народный.

Амазон был вынужден сильно замедлить выкатку фич после падений и теперь требует сениор-ревью перед релизами.

Хотя казалось бы, уж у них-то должны быть и автоматизированные тесты и легион ручных QA-инженеров!

Вот целый список подобных падений, с оценкой, сколько пользователей они задели.

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

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

В общем, быть техдиром опять становится интересно.