Cloudflare опять упал, Zoom поэтому не работает (и половина интернета вместе с ним), не удивляйтесь.
Upd: поднялись в течении 20 минут.
Cloudflare опять упал, Zoom поэтому не работает (и половина интернета вместе с ним), не удивляйтесь.
Upd: поднялись в течении 20 минут.
Доброе утро! А вот у южнокорейских государственных айтишников — не очень доброе, потому что они не делали бэкапы до сих пор восстанавливают инфраструктуру после пожара в серверной.
У большинства систем были бэкапы, но удаленное хранилище файлов, которым пользовались 17% всех госслужащих страны — не имело бэкапов. Безвозвратно потеряны терабайты документов. Делайте бэкапы!
Кстати, у этой истории есть ещё и шпионское измерение: в июне 2025го двое хакеров взломали северокорейского (китайского?) хакера, который взломал LG и кучу южнокорейских государственных систем. Дали об этом знать южнокорейским правоохранителям, которые в августе перестали выходить на связь. А дальше уже совсем мистика: кто-то пишет им с одноразового номера в сигнале «Proton небезопасен», после чего Proton блокирует почтовый ящик, с которого они вели коммуникацию только с южнокорейскими властями, но разблокирует после публикации.
24 сентября южнокорейский парламент начинает расследование взлома, 25го анонсирует физический аудит дата-центра, 26го — пожар. Подробности и ссылки на дампы с компьютера хакера — в легендарном журнале phrack.
Помните, на прошлой неделе Cloudflare упал и уронил половину интернета?
Они пишут одни из лучших post-mortem’ов в индустрии. Последний — не исключение.
Круто, что они опубликовали его прямо в день падения. Обычно, одни согласования с юристами занимают дни.
Но самое впечатляющее для меня в этой истории — вот этот комментарий пользователя eastdakota на форуме hacker news.
Это Мэтью Принс, основатель и генеральный директор компании, которая обслуживает 20% всего интернет-трафика, рассказывает, как он сначала сидел на созвоне по починке аварии, а потом пригласил к себе домой бывшего техдира (тот захватил сына, показать, какая у папы работа) и главного юриста компании и они на троих сообразили текст в гугл-доке. Задали в нем вопросы технарям компании. Заказали еды. Включили ответы на вопросы в текст. Дали вычитать технарям. И опубликовали. И получился пост-мортем. ❤️
Подъехал пост-мортем от Амазона.
С одной стороны, хочется поржать над 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», «причину аварии» и предлагает посмотреть на безопасность систем по-новому, через другие линзы, чем я привык. Очень рекомендую.
Все заметили, что в последние недели Клод отупел и жрет токены как не в себя.
Ходили слухи, что это потому что у Антропика не хватает видеокарт.
Теперь они утверждают, что дело в ошибке в их обвязке Claude Code и что «они никогда не отупляют модели специально». Выпустили исправление и сбросили лимиты токенов в этом месяце. Подробное объяснение тут
Большая часть облачных сервисов 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-инженеров!
Вот целый список подобных падений, с оценкой, сколько пользователей они задели.
С одной стороны, нужны нормальные процессы, чтобы слоп не лез в продакшен и были хотя бы пара живых людей, которые понимают, что там происходит под капотом в сложной системе.
С другой стороны, мы сейчас во временном переходном периоде, когда ещё есть программисты, которые не умеют ставить задачи (хотя и умеют писать код самостоятельно) и с этим нужно что-то делать.
В общем, быть техдиром опять становится интересно.
Гитхаб в последнее время сильно сбоит.
В дополнение к инциденту с merge queue, за последние дни успели сломаться поиск и показ пул-реквестов.
Техдир сервиса Владимир Федоров в своем покаянном посте пишет, что причина — во взрывном росте активности на платформе из-за нейросетей (см картинку).
Обещает, что теперь они будут работать над стабильностью, масштабируемость и перестанут гнаться за фичами.
Внешние наблюдатели подозревают две причины: 1) плохой вайбкодинг в Microsoft 2) сложный переезд с собственной инфраструктуры на Azure.
И вот уже знаменитый Митчел Хашимото пишет длинный эмоциональный пост, что уносит репозиторий своего проекта ghostty с гитхаба.
❧
Создать git репозиторий можно без всяких сервисов — это просто файлы на диске. Гитхаб выигрывает за счет удобного контроля доступа, интеграции с ci/cd инструментами, удобного веб-интерфейса для комментирования и тысячи мелочей.
Есть десятки конкурентов, но ни один не дотягивает до качества github. Раньше это был «лучший инструмент, который можно купить за деньги», а теперь он становится одним из многих, со своими плюсами и минусами. Прямо падение гиганта.
Конечно, у таких сервисов огромная инерция, но очень интересно, куда побегут «модные ребята», которые задают тренды. Будет ли это новый классический конкурент со взрывным ростом или что-то распределенное и децентрализованное, соответствующее базовой философии гита?
В Германии уже третий час не ходят поезда, упала специальная сотовая сеть GSM-R, которая поддерживает связь между машинистами и диспетчерами и обмен технической информацией между поездами. Чтобы не было столкновений, все поезда встали.
На немецком ЖД-реддите ходят слухи, что причина в кривом обновлении софта.
Я и не знал, что у поездов есть своя сотовая сеть из 90-х. У нас уже 5G, а поезда на 2G.
Вообще, в этом вся суть инфраструктуры: пока всё работает — никто не замечает. Я восхищаюсь инфраструктурой, и чем более базовая — тем круче. Надеюсь, когда-нибудь возьму интервью у инженера, который занимается водопроводом и канализацией.
P. S. Недавно узнал, как работали римские акведуки. Там, оказывается, вода становилась чистая за счет точно рассчитанного наклона трубы; вода течет медленно и вся грязь оседает, но и не слишком медленно, чтобы не застаивалась. 🪄