Клиент поделился, что у них в дата-центре выбило электричество, а дизель-генератор выключился из-за жары. Результат — серьезный простой продакшена. Всё бы ничего, но это клиент, у которого я только что закончил аудит и на то, что у них свой ДЦ я достаточного внимания не обратил 🙈
ОК, добавляем пункт «аудит ДЦ, если он не дай бог не Tier 3» в чеклист.
Чеклист аудита написан деньгами, прямо как техника безопасности — кровью.
Половина сайтов в интернете не работают, потому что сломался один из крупнейших CDN — fastly.
Задело Амазон, Нетфликс, Бибиси, сайты правительств и многих других.
Через этот сервис сайты отдают статические картинки, файлы стилей и жаваскрипты.
Удивительная на самом деле ситуация: основные сервера всех сайтов кроме fastly работают отлично, но без картинок, стилей и скриптов, подгружаемых через fastly, пользоваться сайтами невозможно.
Отдаём мы эти файлы через fastly для того, чтобы они загружались у пользователей максимально быстро. У фастли тысячи серверов по всему миру, так что обычно, картинки через них отдавать в разы быстрее, чем самому.
В Fastly работают настоящие профи, так что будет очень интересно почитать, почему они так капитально сломались.
3 минуты назад написали, что нашли причину и чинят. Ждём.
Текущий статус тут https://status.fastly.com/incidents/vpk0ssybt3bj
Как не уронить свой сервис под нагрузкой, на примере Signal.
Люди массово переходят из вацапа в Signal. Серверы Signal не выдержали и совсем лежали почти 14 часов, а испытывали серьезные трудности больше суток. Не лучшее время, чтобы падать :( Официальный твиттер сигнала при этом хранил молчание, будто это не модный стартап, а какая-то древняя корпорация. Жаль. Надеюсь, позже они опубликуют подробный разбор, что случилось.
Пока поделюсь, как мы однажды сами положили свои серверы и как от этого защищаемся теперь. Почти все мобильные приложения отправляют запросы на сервер, например, для оформления заказа или отправки сообщения. Важно, как себя ведут мобильные приложения, если сервер ответил с ошибкой. Очевидное решение — просто повторить запрос ещё раз, как только получил ошибку, незаметно для пользователя.
В одном проекте именно так мы и сделали. Всё было хорошо, пока серверу не стало плохо на пару минут. Если обычно на сервер приходили 100 запросов в минуту (полтора запроса в секунду), то за три минуты скопились 300 запросов и теперь, стоило серверу очухаться, как ему насыпали все 300 запросов в одну секунду. То есть для сервера это выглядело как рост нагрузки в 200 раз и он опять ложился под нагрузкой. Очень неприятная ситуация. Мы сами себя задидосили, своими же собственными мобильными приложениями. 🙈
Есть две компоненты решения этой проблемы:
🛑 Первая: сервер должен уметь ответить «довольно!», и клиенты должны перестать повторять запрос, если получили такой ответ. Интересно, что именно этой функции в Android-клиенте Signal не было и они добавили её во время аварии.
⏱ Вторая, более сложная и интересная, но тоже классическая: exponential backoff (экспоненциальная задержка). Идея очень простая: если сервер не ответил в первый раз — ждем 1 секунду и повторяем запрос. Во второй раз — ждем 2 секунды, в третий — 4, в четвертый — 8. То есть с каждой неуспешной попыткой, даем серверу больше времени прийти в себя. У Signal эта функция реализована, но во время аварии они добавили jitter — небольшую случайную задержку, чтобы клиенты не набегали на серверу толпой, через одинаковые интервалы времени после его падения, а нагрузка была более плавной. Обычно, в этом же коде реализуют ещё паттерн circuit breaker, когда после определённого числа ошибок «выбивает пробки» и запросы прекращаются совсем.
Используйте оба приема и будьте здоровы!
💭 Есть твит и телеграм-пост в популярном канале, в которых утверждается, что причина падения сигнала — в само-дидосе (мол, анекдот). Это маловероятно. Во первых, exponential Backoff в сигнал внедрили больше 2 лет назад и он здорово распределяет нагрузку; во вторых, изменения коснулись только Android клиента. Не верьте советским газетам, читайте первоисточники.
Фейсбук удалил все посты, опубликованные с помощью сервиса Amplifr. Сервис позволяет делать отложенные посты, смотреть аналитику и управлять многими соцсетями из единой админки.
Этим инструментом для управления своими соцсетями пользовалась Ведомости, Коммерсант, да добрая половина русских медиа. Все эти медиа потеряли и посты, и комментарии под ними! Вот показательный пост Мити Алешковского, создателя «Таких дел».
Сделал это фейсбук в рамках борьбы с ботами и «фейк-ньюз». Не удивлюсь, если какая-то фабрика троллей на самом деле пользовалась Amplifr. Да и сервис русский, подозрительно это всё (его делает одна из лучших аутсорс-студий россии, злые марсиане).
Судя по всему, русские медиа в глазах фейсбука — папуасы, с которым можно вообще не считаться. Было бы дело в америке — журналисты бы уже строчили статьи о том, что фейбсук нужно зарегулировать и вообще сделать чем-то типа муниципального водопровода. А скорее сами сотрудники фб осознали бы, что творят фигню и разобрались бы в ситуации детальнее.
А нашим медиа предлагаю присмотреться к западному buffer — делает то же самое, что и amplifr, только им пользуются крупные западные медиа, так что именно такой фигни я бы не опасался.
P.S. В комментариях у Мити пишут, что посты скрыты до окончания проверки и после американских рождественских каникул они скорее всего будут восстановлены. Странно, что нормальные вроде ребята нигде про это не пишут публично.
Подробная и полезная статья, как один стартап боролся с мощной DDoS атакой.
История очень хорошо написана. Например, число одновременных соединений они измеряют в подписчиках твиттера Джастина Бибера. Почитайте, оно того стоит.
Практическое: они жили на AWS и подключили услугу AWS Shield Advanced — это когда anti-DDoS специалисты амазона помогают разобраться с вашей конкретной атакой. Стоит 3k$ в месяц, договор на год. Чувакам очень понравилось, и я возьму на заметку.
Чего делать точно не стоит — это пытаться выдать аварию за штатную профилактику.
Так, на прошлой господрядчик пытался скрыть аварию в государственной системе, на которую завязана вся фарм отрасль России.
Зрелость инженерной организации проявляется не только в том, как редко случаются аварии — они бывают у всех. Зрелость в том, КАК компания реагирует на аварии. Но не буду повторятся, про это я уже писал подробно ранее: жемчужина от cloudflare и пример stackoverflow.
Мы в 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-системах неизбежны. Важно, что они вызваны не вопиющей некомпетентностью и как компания на них реагирует, учится ли она на ошибках. Побольше бы таких текстов и таких компаний.
Слек сегодня глючил весь день - это у них проблемы, а не с вайфаем в офисе. Уже 6 час не могут починить.
Классная формулировка на странице статуса: «Though we saw signs of improvement earlier, unfortunately the fix we had in mind didn't do the trick.»
«Казалось, дело идёт на поправку и мы нашли решение, но оно не сработало. Работаем дальше.»
Спасибо Александру Арбузову за наводку в чате.
