Как выкатить обновление, если оно затрагивает все ваши сервисы

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

Что такое выкатка

Любой айтишник легко ответит, что такое выкатка: ставишь CI/CD, и автоматом все доставляется на прод.

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

А вся картинка такова. Выкатка состоит из четырех больших аспектов:

1. Доставка кода, включая изменение данных. Например, их миграцию.
2. Откат кода — возможность вернуться, если что-то пойдёт не так. Например, через создание бэкапов.
3. Время каждой операции выкатки/отката. Надо понимать тайминг любой операции из первых двух пунктов.
4. Затронутый функционал. Нужно обязательно оценить как ожидаемый позитивный, так и возможный негативный эффект.

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

Но третий и четвертый даже более важны. Какому пользователю понравится, если выкатка займет три часа вместо минуты? Или если на выкатке зааффектится что-то лишнее? Или даунтайм одного сервиса приведет к непредсказуемым последствиям?

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

<a href="/wp-content/oldblog/uploads/2-08-19_1.png" target="_blank" rel="noopener noreferrer">

Пример диаграммы Ганта выкатки: из статьи о том, как команда платформы VK Cloud  (бывш. MCS) выкатывала IAM (Identity and Access Management)

Хорошие практики для хорошей выкатки

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

Влияние выкатки на пользователей. Это первое, что надо понять: как выкатка может повлиять или повлияет на пользователей. Будет ли даунтайм? Если будет, то даунтайм чего? Как это отразится на пользователях? Какие возможны наилучшие и наихудшие сценарии? И закрывать риски. Например, заранее подготовить все, что можно подготовить прозрачно для пользователей. Или выкатывать фичу в то время, когда большинство пользователей не активны.

Четкий план. На каждом этапе нужно понимать все аспекты выкатки:

• доставка кода;
• откат кода;
• время каждой операции;
• затронутый функционал.

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

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

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

Автоматизация. Все, что может быть автоматизировано, должно быть автоматизировано. Все, что не может быть автоматизировано, должно быть заранее написано на шпаргалке.

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

Действия команды. Самое главное — люди. Каждый должен быть в курсе, что делает, для чего и что от его действий зависит в процессе выкатки.

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