Сервисы
Matvey Kukuy
2807

Как не повторять судьбу Facebook и Cloudflare — не уходить в даунтайм часами

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

В закладки
Аудио
Так горит датацентр в Москве

No nerd alert: текст не написан для тех, кто помнит аргументы kubectl. Вам сразу сюда.

На наших глазах произошла целая череда громких даунтаймов: Facebook потеряла картинки, Cloudflare прилёг и положил половину интернета аж два раза. «Яндекс» потерял данные клиентов, а дым от пожара в датацентре, где размещалась Qiwi, мы с удивлением наблюдали из окна офиса. Мы смогли обсудить увиденное в Slack. Он в тот день работал, что происходит не всегда.

Как же строить надёжные онлайн-сервисы, когда вокруг бушует такая буря?

Я работаю над системой управления ИТ-инцидентами Amixr.IO. Недавно мы с коллегами провели серию консультаций и собрали длинный список мифов о построении онлайн-сервисов, в которые верит не-ИТ-бизнес.

Cloud — не синоним надёжности

2 июня мы заметили странные проблемы на серверах Google Cloud. Мы ринулись запускать резервные мощности на другом облачном провайдере, чтобы в любой момент иметь возможность переключить рубильник и переехать с одного на другой. Примерно через 15 минут мы были готовы, но не решались — нам было абсолютно не понятно, что происходит и в чём проблема — в нас или в Google Cloud.

Только через час мы узнали, что весь регион Google Cloud испытывает проблемы с сетью и мы не развлекаем себя сами. Узнали мы это (внимание) на форуме от инженера Google в отпуске. Он жаловался на то, что у них развалились даже внутренние системы коммуникации на случай неполадок.

Нам тогда повезло — отделались лёгким испугом. Но представьте себе, это не первый инцидент облачного провайдера, который случился с нашей компанией за те пять месяцев, что мы работаем в онлайне. Однажды уже пришлось экстренно мигрировать с DigitalOcean на Google Cloud. Вывод простой: нашем случае надёжный сервис — тот, что развёрнут сразу на нескольких облачных провайдерах.

А теперь немножко теории.

Надёжность облачного сервиса перед клиентами описывается термином Service Level Agreement, или SLA. Я не считаю этот термин исключительно инженерным, потому что он фигурирует в договорах и сильно влияет на стоимость разработки.

Месячный SLA 99,9% условно означает, что провайдер «гарантирует работоспособность» 99,9% времени. Много это или мало?

Верхнюю планку SLA вашего сервиса можно получить, перемножив SLA сервисов, которые для него критичны. Есть табличка, по которой можно вычислить время даунтайма из SLA. Например, SLA Google Cloud Datastore >= 99,95% в месяц переводится как «не более 20 минут даунтайма в месяц». Немного, если у вас интернет-магазин с небольшой посещаемостью, но ужасно много, если у вас IoT или медтех-стартап.

Чтобы добиться большей надёжности, нужно проектировать систему таким образом, чтобы в случае отказа одних подсистем она использовала другие. Обычное веб-приложение опирается как минимум на три столпа — вычислительные мощности, базу данных и бинарное хранилище. Перемножаем SLA, сверяем с требованиями бизнеса — можете ли вы себе позволить даунтайм один день в месяц? А час?

SLA вашего хостинга и партнёрских сервисов может стать сюрпризом.

За надёжность отвечают специальные люди — DevOps или SRE

Не «программисты», не «бэкендеры». Даже не «очень хорошие». Надёжность, отказоустойчивость и танго с облачными провайдерами — это вотчина отдельных людей: DevOps и, если вам повезло, Site Reliability Engineer (SRE).

В штат они очень дорогие. Иногда даже почти как DS. Но можно нанимать как консультантов, что многие мелкие компании и делают.

Ежедневную работу DevOps и SRE не видно, она не отражается на прибыли немедленно, но без них — тяжело, разработка буксует, клиенты испытывают проблемы.

Мониторинг нужен — его ничем не заменить

Распространенно заблуждение, что системы не ломаются, если прошли тестирование. Это не так. В интернете всё против того, чтобы ваш сервис работал, и вселенная регулярно поставляет «чёрных лебедей».

Например, через месяц после запуска Curler мы обнаружили, что товарищи из Китая соорудили полную копию на нашем непубличном API, используя наши же серверные мощности. Разумеется, мы к такому повороту были не готовы, и пришлось срочно разворачивать новые мощности, параллельно отрубая незваных гостей.

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

«Мониторинг» — автоматизированная система, которая детектирует отклонения от нормы или ошибки в подсистемах. На рынке их много, мы насчитали более 300 популярных. SaaS, Self-Hosted, Paid, Free, в каждой большой компании есть несколько самодельных. Мы используем пять различных систем мониторинга, которые могут определить разные типы проблем в нашей системе.

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

Мониторинг — регулярная работа и бюджет

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

Нельзя настроить мониторинг навсегда. Через месяц изменится поток данных, поменяется код приложения, и мониторинг начнёт засыпать ваших инженеров ложными сообщениями, либо (ещё хуже) — замолчит навеки. Чем-то похоже на гитару, которая со временем расстраивается.

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

Начинать можно с малого — uptime-мониторинг будет проверять ваш сайт раз в десять минут и писать на почту, если сайт не работает. Потом можно подвезти Sentry на бэкенд и фронтенд, потом Prometheus и Alertmanager, Elastalert.

Без постоянных инвестиций в мониторинг не бывает стабильного сервиса.

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

Сообщение на почту — не оперативное реагирование

Да, так действительно бывает, когда качественно настроенный мониторинг скидывает сообщения в email.

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

Вы не поверите, сколько критичных систем полагаются на то, что инженер проверит почту в нужный момент.

Следующий по популярности канал доставки — постинг в Slack. На первый взгляд, решение выглядит как удачный «единый дашборд». Скорость высокая, все рады. Увы, почти всегда такие каналы превращаются в бесконечный поток системных сообщений, через пару дней оказываются на mute у команды и теряют смысл.

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

Если вы задались целью обеспечить адекватное время реакции на инцидент и у вас нет возможности нанять выделенных инженеров на 24-часовое дежурство, ваш путь лежит в Incident Management Tools, или системы управления ИТ-инцидентами.

Эти инструменты позволят настроить хитрый роутинг по инженерам в зависимости от типа инцидента и определить ответственного. Условно, если в день приходит 12 инцидентов, а у вас три инженера — каждый получит не все 12, а только те 4, которые относятся именно к его сфере.

Главная магия систем управления инцидентами происходит в «эскалациях». Если инцидент прилетел условному Пете, а он не берёт его в работу за отведённые 10 минут, инцидент эскалируется условному Васе. Сцена приобретает некий драматизм, если на часах три утра, а Вася — начальник Пети. Это позволяет оправданно балансировать нагрузку по членам команды и снизить скорость реакции до считанных минут.

Даже новые проекты должны работать

И последнее, о чём я хотел сказать. Очень часто в жертву скорости разработки приносится стабильность.

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

Если вы создаёте сервис, а он регулярно и заметно лежит — это сигнал о том, что вы что-то упустили.

Настройте базовый мониторинг, определите SLA и введите систему управления инцидентами. Увы, не так весело просыпаться по звонку среди ночи, как пилить фичи. Это сложно, больно, но работает.

Гораздо хуже — узнать, что ваш сайт не работал всю ночь.

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Matvey Kukuy", "author_type": "self", "tags": [], "comments": 32, "likes": 27, "favorites": 54, "is_advertisement": false, "subsite_label": "services", "id": 74230, "is_wide": false, "is_ugc": true, "date": "Mon, 08 Jul 2019 11:59:58 +0300", "is_special": false }
0
{ "id": 74230, "author_id": 48399, "diff_limit": 1000, "urls": {"diff":"\/comments\/74230\/get","add":"\/comments\/74230\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/74230"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 200396, "last_count_and_date": null }
32 комментария
Популярные
По порядку
Написать комментарий...
–6

Нужно БОЛЬШЕ ССЫЛОК в тексте.

Ответить
11

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

Ответить
0

Согласен.

Ответить
5

Вы считаете, что много ссылок — это плохо? Почему?

Ответить
–3

слишком долго читать и изучать.

Ответить
0

Айда в Твитер, чо.

Ответить
0

Фото с MSK-IX на Бакулева? Судя по расположению домов - да.
Не "программисты", не "бекендеры". Даже не "очень хорошие". Надежность, отказоустойчивость и танго с облачными провайдерами — это вотчина отдельных людей: DevOps и, если вам повезло, Site Reliability Engineer'ов (SRE).

Вина в падениях часто программеров.

Ответить
8

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

Бодрые команды практикуют blameless postmortems. Это митинг, на котором задача не найти виноватого, кто получит люлей за криворукость, а создать action plan, чтобы этого не повторилось. Внести системное изменение в процесс. Классические решения: повысить покрытие тестами, канареечный деплой, разбить продукт на beta/prod...

Ответить
0

Я не говорю, что надо нещадно драть программистов. Говорю лишь о том, что зачастую это является виной программиста (-ов). Соответственно, прод должен дорабатываться, а пока serivce <service.name> restart

Ответить
1

Как только вы определяете, что косяк — вина не рабочего процесса, а вина определенных людей, вы "нещадно дерете" этих людей.

Ответить
0

Просто заставляю их работать и исправлять косяк. А вообще тесты надо проводить до заливки в прод, но это совсем другой процесс.

Ответить
0

И почему вы его не внедрили?

Ответить
0

Простите, кого мы не внедрили?

Ответить
0

"Другой процесс", когда тесты до заливки в прод.

Ответить
0

Почему не внедрили? У нас разве что-то падает?

Ответить
0

А иначе они не работают?

Ответить
0

Neo Geo на Калужской)

Ответить
0

Окна помойте

Ответить
3

Простите

Ответить
2

А я бы не был против повторить судьбу fb и Cloudflare (
Что со мной не так...

Ответить
0

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

Ответить
1

Крутая статья! Спасибо

Ответить
0

Полностью бесплатный мониторинг проверки доступности веб-сайтов с интервалом от 1 минуты с уведомлениями по почте (СМС за деньги) - https://zilore.com/ru/monitoring . Бесплатный в данном контексте не значит урезанный или плохой, по качеству/скорости проверок и отсутствию ложных срабатываний посоперничает с любым коммерческим. Просто ребята сделали его в дополнении к своему основному сервису DNS-хостинга. Рекомендую.

Ответить
0

Создаете на свой сайт контекстную рекламу в Яндекс с минимальной ставкой и указываете в настройках -
+ Останавливать объявления при неработающем сайте
+ Уведомлять по СМС
Быстро и бесплатно.)

Ответить
0

Этих сервисов вагон и платных, и бесплатных ;) Мы сделали curler.amixr.io — тоже бесплатно, и, поверьте, очень-очень надежно.

К сожалению, это реактивный мониторинг. Он расскажет вам о том, что сайт упал... Когда он уже упал. Можно построить мониторинг, который расскажет вам, что на сайте что вот-вот произойдет до того, как это реально случится. Но это тема отдельной статьи :)

Ответить
0

Проценты доступности в SLA чаще всего маркетинговая фикция, надо смотреть на ответственность за нарушение SLA. Если предлагается пропорциональное снижение абонентской платы то это фикция, что такое 2% ежемесечного платежа по сравнению с 12 часами недостпности сервиса?
А вот если SLA предполагает 20-30% штрафы за каждые 0.1% превышения недоступности тогда да. Но публичных облаков с такими условиями не бывает.

Ответить
0

У Cloudflare есть SLA 100% на тарифе за 200$ и 2500% на тарифе Enterprise. Возможно, у меня плохо с математикой, но по моим подсчётам, исходя из их волшебной формулы, получается что-то вроде 5-25 центов за минуту простоя (в зависимости от количества посетителей) и, соответственно, в 5 раз больше на Enterprise. Интересно какую компенсацию сделали в рамках конкретно данного случая по тарифу за 200$

Ответить
0

60$ в час отличная компенсация для энтерпрайса за доунтайм)

Ответить
0

Парадоксальность их формулы заключается в том, что чем дольше лежит сервис, тем им выгоднее, так как посетители зашли, увидели лежащий сайт и ушли => Affected customers уменьшается, а с ним и материальная ответственность

Ответить
0

Аминь.

Ответить
0

Спасибо, сделал бэкапы сайтов на комп

Ответить
0

Осталось сделать их регулярными и проводить учения — иногда восстанавливать сайты из бекапов и проверять как работают ;)

Ответить
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "Article Branding", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cfovx", "p2": "glug" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Баннер в ленте на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "disable": true, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ] { "page_type": "default" }