авария

ФБ начал возвращаться в строй. Сетевая связность восстановлена, заработал DNS. Приложения, скорее всего, тоже скоро очухаются.

Вот хороший обзор ситуации и объяснение механизма падения от Cloudflare https://blog.cloudflare.com/october-2021-facebook-outage/

Теперь ждём технического пост-мортема от фб.

Пойду спать, спокойной ночи, друзья.

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

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

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

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

5/5

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

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

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

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

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

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

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

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

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

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

В облаке Amazon AWS опять проблемы и это задело Slack — популярный рабочий мессенджер, так что если он у вас глючит — «дело не в офисном интернете».

У всех крупных онлайн платформ есть так называемый Status page, в котором инженеры отражают «здоровье сервиса». Ходят слухи, что в Amazon инженеров наказывают за то, что их сервис отметился на этой странице. К чему это приводит — довольно очевидно. Вот ребята сделали юмористический и чуть более удобный «правдивый статус Амазона».

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

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

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

Очередной шедевр от Cloudflare — подробный отчет об аварии 2 июля.

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

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

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

Вчерашний студент удаляет продакшен базу данных в первый день работы, во время настройки рабочей среды. CTO винит студента и угрожает юристами. https://www.reddit.com/r/cscareerquestions/comments/6ez8ag/accidentally_destroyed_production_database_on/
Too good to be true, я так и вижу жирного 40-летнего тролля за клавиатурой.

Помните, в августе в Японии ломался интернет из-за утекших роутов?

Вчера была похожая история, на этот раз в Штатах у Level3 https://www.wired.com/story/how-a-tiny-error-shut-off-the-internet-for-parts-of-the-us/

Компания Atlassian 4 апреля что-то капитально сломала, так что 400 компаний-клиентов потеряли доступ к системе управления проектами Жира и базе знаний Конфлюенс. На 10 день (!) аварии, доступ восстановлен только для 35% клиентов, для некоторых восстановление доступа может занять ещё 2 недели (!).

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

Вот хороший обзор истории и смешной слух о реальных причинах. Удивляет очень плохая внешняя коммуникация, уж у миллиардного Атлассиана-то ведь должен быть вменяемый PR-директор?

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

Фейсбук, Инстаграм и вацап упали. Судя по всему — что-то с сетью.

Ожидаемо, все последние крупные падения: что у гугла/ютуба, что у Яндекса — именно про сеть. Ее сложнее всего дублировать, разделять и тестировать, в ней больше всего ручного труда инженеров и возможностей для ошибок.

На картинке — твит техдира Cloudflare https://mobile.twitter.com/jgrahamc/status/1445068309288951820