Практики повышения надежности сервисов и Chaos Engineering (инженерии хаоса) в ШСМ

Всем привет! Сегодня поговорим про то, как мы обеспечиваем стабильность работы ИТ-сервисов ШСМ.

В статье "Школа как платформа сервисов" мы рассказывали о том, какие сервисы оказывает и планирует оказывать наша Школа на базе ИТ-платформы Aisystant, но стоит дополнительно отметить, что частью этих сервисов уже регулярно пользуются сотни студентов, а дальше число студентов будет только расти (например, с середины сентября по онлайн-курсу "Системное мышление 2020" практически одномоментно пойдут 200+ сотрудников одного ВУЗа России). Поэтому вопросы обеспечения стабильности работы и масштабируемости ИТ-сервисов - это приоритетное направление ИТ-команды ШСМ.

В начале августа у хостинг-провайдера, где расположен наш сервер с онлайн-курсами и блогом случилась авария (пропало с питание на серверной стойке), в результате которой наши студенты около пяти часов не могли получить доступ ни к онлайн-курсам, ни к блогу ШСМ (и это случилось днем, в период высокой активности студентов!). Провайдер устранил проблему, сервисы восстановились. Техподдержка нас уверила, что инженеры сделали всё, чтобы эта проблема больше не появилась. А через день ситуация повторилась (но недоступность сервисов была уже "всего" 2 часа). Всё как в старой поговорке: раз в год даже палка стреляет (а в контексте современных сложных распределенных систем, я бы добавил, что стрелять она может дважды или даже трижды - и этим никого не удивишь, просто надо быть к этому готовым и заранее принимать меры).

Чтобы больше не допускать подобные ситуации, мы приняли решение об очередном шаге развития: в ЖЦ Aisystant в стадию эксплуатации будем интегрировать новые практики повышения надежности (Reliability) сервисов. Начали с практик резервирования и Chaos Engineering. Отмечу, что тема повышения надежности очень обширная (достаточно посмотреть на практики из SRE), поэтому мы делим слона на части и за один раз, по потребности, осваиваем те, которые наиболее актуальны для нас в текущий момент.

Резервирование

Принцип простой: добавляется резервный сервер, который физически расположен в другом дата-центре и у другого провайдера. Этот сервер полностью дублирует (функционально и по информационному наполнению) основной сервер. В случае сбоя основного сервера все сервисы начинает оказывать резервный.

Схема с резервным сервером получилась такая: 

  • добавили сервис мониторинга состояния работы серверов (на отдельном внешнем сервере)
  • добавили резервный сервер, на котором настроена репликация и все изменения в данных (такие как ответы на кейсы, отметки о прочитанных разделах в онлайн-курсах, новые комментарии или посты в блоге и пр) в считанные секунды поступают от основного к резервному
  • подключили динамический DNS, чтобы можно было быстро заменять IP-адрес сервера, который обслуживает работу сервисов Школы на доменах aisystant.system-school.ru (Онлайн-курсы) и blog.system-school.ru (Блог ШСМ)

В ситуациях, когда происходит сбой основного сервера:

  • сервис мониторинга обнаруживает проблему с доступностью онлайн-курсов или блога и отправляет оператору техподдержки тревожное оповещение (через телеграм-бота)
  • оператор совместно с системным администратором принимают меры по восстановлению работоспособности основного сервера
  • если восстановить основной сервер не удается в течение 5-10 минут, то оператор инициирует переключение на резервный сервер (дает команду телеграм-боту)  
  • происходит переключение на резервный сервер и он начинает оказывать все те сервисы, которые оказывал основной. Переключение происходит абсолютно прозрачно для студентов
  • системный администратор в спокойном режиме проводит работы по восстановлению основного сервера и выясняет причины сбоя. После чего возвращает работу всех сервисов на него (с восстановлением всех данных, которые поменялись за время, пока его подменял резервный сервер).

Переключение на резервный сервер мы пока сознательно сделали в полуавтоматическом режиме (без команды чат-боту сервер не переключится), но технически нет никаких проблем делать это полностью автоматически - что мы и сделаем, после нескольких циклов проверки и получения уверенности, что не будет ложных переключений.

Chaos Engineering

Тут все еще проще: периодически дергаем рубильник у основного сервера и смотрим что происходит :)

А если без шуток, то:

  • по определенному регламенту (примерно раз в месяц) инициируем остановку основного сервера
  • строго отрабатываем все процедуры переключения
  • по выявленным проблемам проводим разбор и устраняем причины

Последнее такое контролируемое отключение было в это воскресенье, 30 августа. Процедура прошла почти штатно (сервисы продолжали поставляться с резервного сервера, суммарное время недоступности было около 15 минут). В результате нашли пару проблемных мест и уже работаем на их исправлением. В частности - планируем сократить время недоступности до 5-7 минут и исправить проблему, которая приводила к неполной синхронизации данных на резервном сервере (UPD: уже исправили).


"Девятки" в Uptime

За 7 месяцев работы онлайн-курса на Платформе ШСМ его Uptime составляет 99,663 - это с учетом всех сбоев у провайдеров и регламентных работ. Как освоение новых практик помогает в борьбе за "девятки" в Uptime наших сервисов -  расскажем позже. Stay tuned)

Что почитать по теме: