Что, если бизнес компании заключается в приеме и обработке платежей во множестве стран в режиме 365/24/7? В этом случае одной из ключевых целей ее сотрудников является доступность сервисов 99,999%. А к CI/CD в таких условиях предъявляются особые требования.
Заместитель директора департамента эксплуатации и разработки сервисных систем ECOMMPAY IT Федор Васильев на конференции HighLoad++ Весна 2021 рассказал об эволюции подходов его компании к деплою нового кода. А мы сделали на основе его доклада полезную статью, которую вы найдете под катом.
Мы работаем с финансовыми транзакциями, и мы параноики, потому что любой даунтайм для нас — это прямые финансовые потери.
Сервисы у нас деплоятся последовательно, и это принципиальная позиция. Конечно, технически можно деплоить хоть все сразу. Но если деплой идет параллельно, энтропия, которая вносится в продакшен, очень большая. И потом очень сложно разобраться, что пошло не так. Тяжело смотреть логи, потому что их много. Кроме того, компоненты связаны друг с другом очень тесно и хитрым образом. Деплоить все сразу в финтехе, по нашему опыту, опасно.
Деплой каждого сервиса тщательно проверяется в режиме реального времени.
Раньше, до конца 2019 года, процесс выглядел так: куча людей (деплой-инженеры, системные администраторы, инженеры мониторинга) в течение многих часов напряженно деплоят и проверяют сервисы по заранее составленному расписанию. И как-то, под новогодний фриз, мы поняли, что надо что-то менять (деплой в тот день длился 12 часов!).
О том, что мы поменяли и как углубили автоматизацию я расскажу ниже.
Какой CI/CD нам нужен?
Обычно всем нужен быстрый, надежный и дешевый CI/CD. Для нас, конечно, это тоже все актуально. Но гораздо важнее:
чтобы все работало (понятно — кому нужен деплой, который не работает);
не было финансовых потерь во время и после деплоя;
если потери все-таки есть, они должны быть минимальными и происходить в короткий промежуток времени.
Если вдруг что-то пойдет не так во время деплоя или после, нас ждут прямые финансовые потери: мы недосчитаемся денег и/или можем попасть на штрафные санкции. А этого очень не хочется. Нежелание попадать на деньги и определило эволюционный вектор наших деплоев.
Blue\Green Deployment
Естественно, для нас это α, ω, θ, γ и т.д. — в общем, весь греческий алфавит. Blue\Green Deployment у нас используется практически на всех сервисах.
Кроме того, у нас используется и канареечный релиз, и обычно это происходит одновременно с Blue\Green.
Выглядит это так: трафик на офлайн-линию с новым кодом мы запускаем маленькими порциями — 2%, 5%, 20%, потом доходит до 100%. Это делается для того, чтобы финансовые потери, в случае чего, были меньше. Обычно мы начинаем с 2%, и, если что-то случится, потеряем только их.
Как проверять?
Это индивидуальная история. Сервисы очень разные, и их много (от 20 до 100, смотря как считать).
Подробный письменный регламент проверки каждого сервиса при деплое должен быть обязательно. По этому регламенту опытный инженер отдела мониторинга проверяет сервис по пунктам. В качестве инструментов мониторинга и проверки мы используем Kibana, Grafana, Zabbix. Но есть вещи, которые нужно проверять руками: заходить в интерфейсы, учитывать функциональность. Помимо пунктов из регламента, разумеется, рассматриваются аномалии в графиках/мониторах/дашбордах.
В регламенте проверки сервиса всегда есть бизнес-проверки и бизнес-метрики. Бизнес-проверка — это проверка основного функционала (она осуществляется на каждом шаге деплоя). При малейших подозрениях на проблемы происходит максимально быстрый откат. В случае с blue/green — это секунды. Трафик скачком переводится обратно на стабильную линию.
Инструменты деплоя
Что же у нас было в тот момент когда мы поняли, что необходима более глубокая автоматизация?
А были у нас три замечательных богатыря:
AWX (Ansible) -> 49 jobs templates;
Jenkins (Groovy) -> 41 jobs;
Fabric (Python) -> 5 scripts.
В центре — Jenkins, он же Илья Муромец — основа основ деплоя кода. Инфраструктурные вещи, например, переливания трафика, реализованы в AWX (Добрыня). А в некоторых компонентах есть и Fabric (Алеша Попович), выполняющий вспомогательные функции по развертыванию ENV для приложений.
Что еще автоматизировать?
Если посмотреть на картину внимательно, то на заднем фоне виден пароход. В век, когда уже есть паровая тяга, бурлаки тащат против течения корабль. Это не кажется вам странн��м? Илья Репин специально нарисовал пароход, чтобы подчеркнуть, что несмотря на наличие паровой тяги, бурлаки еще при деле.
Бурлаки деплоя для меня — это две категории людей. Первые — деплой-инженеры, которые переливают трафик, и нажимают кнопки в Jenkins/AWX, чтобы деплой начался. Вторые — инженеры мониторинга, которые по сигналу деплой-инженера проверяют такой-то сервис на новой линии в таком-то ДЦ.
Когда мы начали создавать систему, о которой я буду говорить ниже, мы хотели автоматизировать прежде всего работу деплой-инженера и инженера мониторинга.
Как автоматизировать?
Наверное, все знают эти инструменты. Как я уже упоминал, три из них у нас уже использовались. Мы решили, что хватит.
Принципиально у нас выходило следующее:
Но что же должно быть в центре? Что будет оркестровать?
До разработки новой системы в центре был человек. Я полагаю, если бы на моем месте был бы инженер, который по призванию админ, то оркестратором бы стал Jenkins. Но я-то программист, поэтому у меня получился велосипед :)
Когда очертания и функциональность будущей системы в целом понятны, я считаю, что очень важно правильно выбрать ее название. Поэтому задумался, как мне назвать этот велосипед?
И мне пришел в голову образ Lurker-а:
Это Близзардовское творение — зерговский юнит из игры StarCraft, в переводе соглядатай, тайный наблюдатель. В игре он закапывается под землю и атакует оттуда своими страшными щупальцами.
Смысл будущей системы был именно в том, что она, с одной стороны, будет невидимой. А с другой сможет вовремя дергать своими щупальцами: Jenkins, AWX и Fabric. Поэтому образ Lurker-а мне показался удачным.
Что у нас получилось:
Отдельная система (оркестратор).
PHP 7.4, MySQL 5.7, Bootstrap.
Jenkins API — для деплоев (включает fabric).
AWX API — для манипуляций с трафиком.
Мониторит состояние сервисов по логам в ELK (Elasticsearch API).
Grafana API (считывает триггеры).
Zabbix API (считывает триггеры).
Запускает бизнесовые проверки сервисов (кастомные, PHP).
Запускает Lurker-Smoke-тесты (Codeception, Selenium WebDriver).
Web-интерфейс, Telegram-bot.
Бизнесовых проверок сервисов много. Большинство из них кастомные, написаны на PHP в самом Lurker, как модули. Это server-to-server взаимодействия, которые необходимо проверить (дергаем «ручки» API сервисов).
Кроме того, если речь идет об интерфейсном проекте, у которого есть фронт, бот заходит, кликает по кнопкам по определенному алгоритму и проверяет, все ли там нормально: отображаются ли новые транзакции, обновляется ли таблица, можно ли выгрузить файл. Для этого у нас есть тесты на Codeception и Selenium WebDriver — это интерфейсные бизнес проверки.
Это та часть, которую пишут профессиональные QA-шники. Они занимаются автотестами, и для Lurker они пишут специальные тесты, которые мы называем Lurker-Smoke-тестами. Это не регресс и не обычный QA-шный Smoke на стейдже, а именно специально написанные тесты, проверяющие только самый критичный бизнес функционал. К ним предъявляются определенные требования, основное из которых — скорость исполнения.
Lurker выглядит так:
Это точка входа в расписание. Она общедоступна — любой работник компании может зайти и посмотреть актуальное расписание деплоев компонентов.
Очень важный момент: QA сами подают заявку на продовый деплой. У них есть специальные права для своих компонентов, и они лично указывают теги, артефакты, выбирают время из свободных слотов.
Расписание ведется прямо в Lurker. Деплои запускаются автоматически и последовательно.
Несколько примеров интерфейсов:
*Фотки со стейджа, но на проде то же самое.
Здесь ничего особенного: мониторинги, HeartBeat сервисов (трафик. ошибки).
Так выглядит лог джобы, когда она запускается:
Здесь подробно логируются проверки, этапы переливание трафика, и т.д.
Пример управляющего интерфейса. Если вдруг бездушная машина что-то не так делает, можно это поправить прямо на лету:
Что еще важно? Или некоторые выводы
Пропагандируйте и поддерживайте «Zero Tolerance» к ошибкам уровней ERROR+ (перманентный процесс) — очень помогает мониторить деплои.
Постоянно тестируйте совместимость разных версий сервисов друг с другом силами QA.
Не используйте линии для DBMS. База для обеих линий компонента в blue/green должна быть единой, а 2-3 последних версии апликейшена должны уметь работать с новой структурой базы, так как она никогда не откатывается.
Не бойтесь велосипедов. Иногда они неплохо работают :)
Ну и, конечно, не доверяйте программистам (я сам программист потому знаю, о чем говорю :)
Все надо тестировать силами QA!
Видео доклада можно посмотреть здесь.
В этом году нас ждёт ещё два HighLoad++: 20-21 сентября в Санкт-Петербурге и 25-26 ноября в Москве. Питерское расписание уже готово, и вы уже сегодня можете выбрать себе доклады по душе.
Не забудьте купить билеты на конференции: в Питере, в Москве.
