Deploy Туретта: Как жить с непредвиденными деплоями от CEO

Короче, есть у нас разработчик, который любит время от времени нажать \"Merge\" в продакшен, никому ничего не сказав... в 4 утра... и не дожидаясь завершения идти спать...

Как вы понимаете в 4:45 я и дев-опс просыпались и с горящей жопой накатывали фиксы и поднимали прод

Вы скажете: \"увольте его\"? А он наш CEO

Вы скажете: \"переучите его\"? А он считает что лучше деплоить, чем не деплоить (и я с ним согласен, но это в другой статье)

Вы скажете: \"отнимите право мерджа\"? А он часто залетает и правит кучу важных багов и ждать подтверждения тоже не вариант

В итоге, мы решили не бороться с этим, а принять и использовать во благо:

– CI ждет прохождения миграций перед деплоем новых образов
– Создание индексов только с локальной машины и только с CONCURRENTLY
– В кубере стоит тактика \"не убивай старые сервисы, пока не live чекнулись новые\"
– Сервисы при старте проверяют корректность накатанных миграций
– В каждом сервисе прописан graceful shutdown, который очень аккуратно дождется завершения бизнес-логики и убьет процесс
– Ручные трейсы в самых важных местах кодовой базы
– Метрики на приложениях, БД, сети и железе (+ дашборды для дебага)
– ArgoCD постоянно переподнимет сервисы, поэтому, если они успевают поработать всего пару минут, они будут переподняты и еще поработают пару минут

Из дальнейших улучшений:

– Редеплой только при реальном изменении образа (у нас монорепозиторий, поэтому мы сверяем хэш предыдущего образа и нового и только при отличии редеплоим)
– Сейчас автоматом бэкапим БД при каждом деплое, но дальше будем подрубать реплику, ждать пока она синхронизируется и отрубать ее. Если БД развалилась переключаем мастер на эту реплику.

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

А, ну соственно суть Deploy Туретта в том, что чтобы научить разработчиков создавать инструменты и процессы для НЕжопоразрывающих деплоев, вам просто стоит сделать скрипт, который время от времени в рандомное время (в основном, ночью) деплоит в прод...

Да, вас возненавидят, но это во благо самих ребят

А как при таком флоу, без ревью и тестовых инстансов, уберечься от ошибок в самой бизнесс логике?

Тестовые инстансы есть, ревью по желанию разработчика (каждый несет сам ответственность за свой код)

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

В целом, придерживаемся некоторых best practice:

– Обратная несовместимость? Пили новые ручки, а не меняй старые

– Не знаешь допустил ли ошибку в SQL / коде? Используй интеграционные тесты (у нас развернута очень быстрая и удобная система интеграционных тестов, поэтому для создания нового ты просто копируешь файлик, меняешь названия вызываемых функций, немного входных аргументов и все работает)

– Боишься что изменение сущностей разломает консистентность? Используй Event log, то есть строй так, чтобы делать INSERT каждой новой версии, а не UPDATE, тогда можно откатиться до нужной версии или поправить на лету, увидев где пошло не так (еще лучше EventSourcing, но это сложнее)

– Многоступенчатый процесс на каждом этапе которого все может пойти по пизде? Делаешь на такие процессы джобу, все изменения состояния и результаты которой храниш в БД. У нас есть джобы по 10 этапов, на каждом создается по сотне сущностей, все связи этих сущностей храняться на джобе, поэтому если произошла ошибка на каком-то этапе, всегда можно запустить скрипт, который удалит все эти сущности и перезапустит джобу

И еще много таких правил

Основная философия: не избегать баги, а делать так, чтобы их появление (а они появятся) не рушило всю систему, их можно было легко обнаружить и поправить