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

В мире IT тоже периодически происходят «катастрофы»: от перегоревшего жёсткого диска на личном ноутбуке до пожара в ЦОДе, хранящем данные миллионов пользователей. Проводя параллель, можно сказать, что IT-компании во многом схожи с городами, они тоже активно занимаются снижением рисков, оценкой, реагированием и ликвидацией последствий так называемых инцидентов — «катастроф» на языке IT.

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

Понятно, что в реальном мире это невозможно и вообще звучит абсурдно, но не в виртуальном мире IT! Чтобы убедиться, что сервис отвечает всем требованиям неубиваемости и безопасности, кроме прогонов бесконечного количества тестов можно его «поджечь»: смоделировать проблемы сетевой доступности, выход из строя дисков или даже целого ЦОДа.

Такую практику «поджогов» мы называем учениями. Их проводят для проверки того, как продукт справится с возможными проблемами, для обнаружения его слабых мест, если таковые имеются, и внесения соответствующих изменений. И всё это нужно для того, чтобы возникновение реальных перебоев не стало новым инцидентом.

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

Как понять, что произошла катастрофа?

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

Мы хотим знать о появившихся проблемах максимально быстро. Для этого используют так называемый мониторинг — непрерывное отслеживание критически важных показателей системы и их последующий анализ. Проводя аналогии с реальной жизнью, мы можем вспомнить множество устройств для мониторинга — датчики дыма, извещатели пламени, датчики движения, камеры, сейсмические датчики. Мы измеряем давление, влажность воздуха, скорость и направление ветра, температуру и многое другое. Зачем? Чтобы оперативно узнать о проблеме и соответствующе отреагировать на неё.

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

Но как понять, что является нормой, а что — отклонением от неё? На это нет однозначного ответа. Всё зависит от договоренностей между заказчиком и исполнителем, которые обычно представляются в виде специальных измерений надежности системы — service level agreements (SLA), service level objectives (SLO), service level indicators (SLI). В совокупности они формируют единую систему определения качества продукта:

1. На уровне SLA сервис обязуется предоставлять услуги надлежащего качества 24/7 с вероятностью близкой к 100 %. Например, что письма пользователя будут доходить быстро и его вложения не будут никуда пропадать;

2. На уровне SLI выделяют понятные индикаторы, за которыми будут наблюдать. Например, время доставки письма или количество работающих дисков;

3. На уровне SLO определяют цели по выделенным индикаторам, которые должны быть достигнуты, чтобы соответствовать договорённостям из SLA. Например, скорость работы определенных http хендлеров не должна превышать 50 мс, а количество успешных запросов не менее 99% от всех обработанных.

Хаос против хаоса

Ключевые метрики выделили, настроили на них мониторинги, и теперь знаем, как определить, что нагрянула беда. Но можно ли как-то избежать катастрофических последствий и нарушений SLA? Чтобы ответить на этот вопрос, давайте снова вернёмся к природным катаклизмам. В жизни существуют специальные практики готовности и реагирования на чрезвычайные ситуации (ЧС). Они включают в себя:

• Настройку систем раннего предупреждения;

• Подготовку — планирование, повышение устойчивости систем;

• Реагирование — ответную реакцию на случившийся инцидент по заранее составленному плану;

• Восстановление — действия по устранению последствий катастрофы.

Подходы в IT во многом берут пример с реальной жизни. Как мы уже видели, на этапе «подготовки» к ЧС планируют и придумывают, как можно уменьшить риски в системе. Так и в компьютерных системах существует методология ITSM (IT Service Management), которая включает в себя планирование непрерывности предоставления IT-услуг. В рамках непрерывности рассматривают время восстановления, а также надёжность работы окружения. С точки зрения бизнеса это очень важная характеристика, которая должна обеспечиваться в качественных продуктах. Именно на этапе подготовки предполагается, что система будет надёжной и сможет пережить сбой, а значит пользователи не будут испытывать проблем. Поэтому повышение устойчивости продукта — невероятно важный критерий любой структуры.

Но как понять, что система действительно устойчива? Очень просто: начать всё крушить и ломать. У такого подхода даже есть название — Chaos engineering (Amazon, Jesse Robbins).

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

Как закалялась сталь. Повышение отказоустойчивости

Как говорилось ранее, очень важно, чтобы сервис был отказоустойчивым, но что это значит? В книге «Высоконагруженные приложения» Мартин Клеппман описывает это понятие как способность продолжения работы программы в случае сбоя (выхода какого-либо компонента системы из строя). В реальном мире сбои происходят постоянно, и предугадать, что и когда выйдет из строя практически невозможно. С каждым годом системы становятся только сложнее, а вместе с этим растёт количество компонентов, а как следствие и вероятность отказа хотя бы одного из них.

Такой сложный проект как mail.ru невозможно представить без практик отказоустойчивости. Мы регулярно ставим новые цели и ищем новые способы повышения отказоустойчивости. Более 6 лет назад была проведена очередная итерация улучшения надёжности наших сервисов. Мы выделили два основных направления на которых сконцентрировали наш фокус по обеспечению отказоустойчивости: облачное решение для stateless-приложений и специализированное хранилище для mail.ru.

В первом случае решили перенести все сервисы с железных машин (bare metal) в «облако», потому что из коробки оно позволяет гибко настроить различные подходы к отказоустойчивости, включающие в себя автоматическое масштабирование, проверки работоспособности (health checks), балансировку и т. п. Это гораздо удобнее и быстрее, чем вручную администрировать сотни физических серверов. В случае выхода машины из строя приходится оперативно выводить её из нагрузки или перезапускать. В качестве «облака» выбрали готовое решение — Kubernetes.

В рамках направления специализированного хранилища запланировали ряд изменений. Решили изменить архитектуру сервиса (Хранилище для Почты), чтобы повысить степень его высокой доступности. В результате продолжительных и интенсивных работ удалось сделать сервис более отказоустойчивым, а хранилище более экономичным, сократив количество серверов с 2,5 тыс. до 600.

Глаза боятся, а руки делают. Запуск учений

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

В облаке целью первых учений стала проверка отказоустойчивости его внутренних компонентов. Для начала мы хотели убедиться в стабильности выбранного нами инструмента (Kubernetes). Для этого вывели из строя несколько ключевых компонентов облака и проверили, способно ли оно это выдержать. Основная часть учений началась в час ночи, когда большая часть пользователей уже сладко спит и нагрузка на сервисы значительно снижена. Без учёта подготовки учения продлились целый час, и система без проблем пережила подготовленное для неё испытание. Этот успех позволил нам со спокойной душой продолжить издеваться над нашими сервисами в облаке.

Следом учения начали проводить над отдельными сервисами по мере их переноса в облако с железа. Такие небольшие учения проходили уже не в час ночи, а в восемь-девять вечера, их небольшой масштаб позволял сделать такое послабление. Длились они тоже около часа. Сначала осторожно пробовали отключать по одной машине, обслуживающей сервис, а когда убеждались, что всё в порядке, то отключали уже четыре разом. И даже такие относительно локальные учения позволяли находить тонкие места и улучшать их, например, неправильно настроенные алерты, необработанные ошибки сети и т. п. Хотя в большинстве своем всё проходило гладко.

А когда наше облако уже достаточно разрослось и проводить учения по отдельности стало нецелесообразно, мы начали устраивать массовые отключения хостов с сервисами, готовыми к учениям. Тогда встала задача выключить уже не четыре машины, обслуживающие один-единственный сервис, а десятки с более чем сотней сервисов. На картинке ниже заметно, что после выключения 113 серверов, количество ошибок не изменилось и система продолжила работать стабильно. Через месяц во второй попытке выключили уже около 130 машин, подготовка системы заняла целый час, а сами учения продлились полтора.

Вместе с этим мы продолжали иногда проводить мини-учения на 1-2 сервиса, когда хотелось проверить что-то конкретное. Но благодаря полученному опыту в ходе предыдущих более масштабных учений такие испытания проходили уже ближе к дневному времени, около 17 часов вместо 21, и длились не больше часа, включая подготовку.

И так мы плавно пришли к тому, что готовы пробовать имитировать выход из строя не просто набора серверов, а целого ЦОДа. Первые такие учения вместе с подготовкой заняли аж четыре часа и начались в 21 час. И если после предшествующих учений в среднем обнаруживалась 1-2 проблемы, то первый опыт симуляции выхода ЦОДа из строя выявил 7 проблем. В следующий раз симуляция отключения уже другого ЦОДа началась в 19 часов и заняла всего два часа вместо четырёх, а проблем было выявлено уже 6.

С тех пор учения по облаку стали регулярными и проводятся во всех наших ЦОДах. С каждым разом время их проведения сдвигалось и продолжает сдвигаться в прайм-тайм — к 9 утра в понедельник, в пик пользовательской активности. Если в начале нашего пути учения проводились в час ночи, то последние испытания начинались уже в час дня. Также растёт количество сервисов, задействованных в учениях: от одного мы выросли до нескольких сотен. Время подготовки и проведения учений при этом сильно уменьшилось — с четырёх часов до всего одного, а иногда и меньше. 

Тем временем команда хранилища почты тоже не сидела на месте. По мере готовности, компоненты новой отказоустойчивой архитектуры также подвергались испытаниям. Первые учения проводили над элементами системы, от которых не было внешних зависимостей, то есть такие испытания не имели большого влияния на сервисы других команд. Поэтому в них участвовали только админы и разработчики хранилища. Такие учения проходили не дольше часа и начинались стабильно около 20 часов. Они помогали находить и исправлять проблемы отказоустойчивости новых компонентов по мере их разработки.

И когда всё стало готово к полномасштабным испытаниям, во время учений начали «поджигать» уже всё разом. Первые такие учения сразу по всем компонентам хранилища прошли всё так же в 20 часов, но участвовало в них уже гораздо больше людей чем обычно. В общем звонке собралось более 20 ответственных специалистов из разных команд, так как на этот раз учения могли значительно повлиять на работу сервисов-клиентов хранилища. Несколько админов занимались подготовкой и поломкой системы в заранее выбранных местах, в то время как остальные участники учений наблюдали за состоянием своих сервисов и были в полной боевой готовности на случай, если что-то пойдёт не так. При испытаниях выявили несколько проблем, но благодаря тщательной подготовке их временное возникновение никак не повлияло на пользователей. Впоследствии все найденные изъяны были исправлены.

Спустя четыре месяца испытания повторились. На этот раз людей участвовало уже сильно меньше, и учения продлились всего 30 минут вместо полутора часов. Уже тогда хранилище показало себя значительно лучше благодаря изменениям, внесённым после первых испытаний.

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

Учения в почте сегодня

Наши сервисы продолжают активно развиваться, а вместе с ними и процесс проведения учений. На сегодняшний день в них участвует сотни сервисов с частотой раз в месяц. Момент выключения мониторят несколько человек, и все это под реальным highload’ом. В этом разделе мы расскажем, как именно проходят учения в mail.ru. Весь процесс можно разделить на несколько этапов:

1. Подготовка приложения и окружения;

2. Постановка гипотезы;

3. Составление плана;

4. Проведение;

5. Выводы.

Как выглядит подготовка приложения и окружения? Каждый сервис, готовый к учениям, получает специальный статус. Он должен соответствовать принципам chaos engineering и быть высокодоступным сервисом. Тут выделяют три главных критерия: 

1. Отказоустойчивость — сюда входят такие практики как повторные попытки, деградация функциональности, репликация, шардирование и т. п;

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

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

Само окружение должно быть также настроено и готово к каким-либо возможным непредвиденным ситуациям. Под окружением можно рассматривать облако, которое должно в случае отказа какого-либо компонента продолжать работу.

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

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

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

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

Выводы

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

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

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

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

В светлом будущем мы рассматриваем возможность автоматизации поломок. Среди готовых решений можно выделить chaos monkey, но стоит проблема оценки результатов. Когда есть конкретный план и ожидания от учений, оценить всё достаточно просто, но вопрос, как это сделать при случайных сбоях, пока не решён. 

Спасибо за внимание!

Статью для вас подготовили Андрей Киселев (@andrei-m-kiselev) и Ксения Рощина (@opsxolc), разработчики в backend-направлении Почты.

Андрей занимается поддержкой и разработкой нового функционала высоконагруженных сервисов, которые реализуют различные практики отказоустойчивости. Среди них: внутренние решения прокси серверов, сервис push-уведомлений, CDC решение для базы данных Tarantool.

Ксения участвует в разработке сервиса «Сборщики почты», занимается поддержкой и внедрением нового функционала для существующих компонент, а также разработкой новых внутренних сервисов, спроектированных под высокую нагрузку.