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

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

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

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

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

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

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 и, если вам повезло, 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 и введите систему управления инцидентами. Увы, не так весело просыпаться по звонку среди ночи, как пилить фичи. Это сложно, больно, но работает.

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