Comments 5
Здравствуйте.
Rollback — это ручной откат до предыдущей версии сервиса.
Можно и не на предыдущую. После того, как в моей практике был случай, что решили править хотфиксом, а он не помог/сломал сильнее, а откатиться можно было только на предыдущую версию, то там для нас роллбэк готовил два стула, а точнее один, но с эффектами обоих.
После этого я переписал пайплайны выкатки так, чтобы количество ревизий было 10(на всякий случай, но можно и 5). Есть/пить они не просят, а вот откатиться после неудачных хотфиксов можно было далеко назад.
Ну и переписал пайплайны на роллбэк так, чтобы можно было выбрать на сколько ревизий откатиться. По умолчанию можно жать на кнопку, и он стандартно откатит на предыдущую ревизию.
По окружениям: если со stage все понятно (крутятся e2e, интеграционные тесты), то на этапе чтения про
beta, stable и foreign
Возник вопрос, а, может, canary закроет потребности? Так и canary на месте. Не выходит ли это слишком дорого? Почему canary в данном случае не может закрыть вопрос 3х предыдущих окружений?
Здравствуйте и спасибо за вопросы!
По поводу роллбэка - вы всё верно написали! Сломать хотфиксом и получить два стула - легко :) Возможность откатиться на более поздние релизы у нас имеется, причём тоже на 10 последних.
Про canary и дороговизну множества окружений. Чтобы ответить, надо рассказать немного про архитектуру, в том числе.
Для нашего самого крупного сервиса (монолит) разворачивается отдельный инстанс пер клиента (мы B2B, у нас их под тысячу). В каждом инстансе крутятся десятки подов (в зависимости от нагруженности клиента) в разных деплоймент группах.
Таким образом, canary становится достаточно дорогим удовольствием, надо всё это ещё и дублировать при выкладке. Более того, на порядок замедляется время деплоя. При таких вводных ни о каких двух-трёх релизах в рабочие сутки на stable речи быть не может.
Мы регулярно отщипляем микросервисы от монолита и так же движемся в сторону мультитенантного единого процесса монолита, в следующем году планируем некоторые деплоймент группы сделать едиными. Перевести весь монолит на единый процесс - долгий путь, который нам предстоит.
Второй причиной является необходимость наличия единой метрики, на которую будет смотреть canary во время деплоя. В ситуации, когда сервис большой и про несколько доменов сразу - обеспечить такую метрику сложно. Да и не всё поведение системы можно покрыть метриками.
Третьей причиной вижу то, что staging окружение не способно отловить проблемы больших нагруженных проектов и мы рискуем угодить в ситуацию, когда на стейдже всё ок, а при деплое на прод canary частенько будет откатываться, блокировать деплой - и все вытекающие последствия.
Что касается десятка других микросервисов, там действительно в критических сервисах применяем canary - например, публичный API Gate, сервис триггерных механик.
Таким образом, canary становится достаточно дорогим удовольствием
Это потому что, если я верно понял, речь не о кенари, как таковом, а о "дублях" по сути реплик прода, если я верно понял аспекты вашей архитектуры, то используется что-то вроде липких сессий, которые гоняют трафик на нужный инстанс.
Возможно, существуют решения, которые в этом способны помочь. Например, у нас схожая архитектура, и я приглядел полноценный кенари вариант с Argo Rollouts (не смотрел, можно ли ссылки, поэтому без них). Но его только собираемся внедрять.
staging окружение не способно отловить проблемы больших нагруженных проектов
Здесь подразумевается, что на больших данных непредсказуемо поведение, потому что стейдж != прод по количеству и качеству данных, или что именно сам фактор нагрузки может повлиять (например, лавинообразный рост трафика)?
Спасибо за ответ!
Очень интересно было прочитать, спасибо! Я бы сказал, что это хороший задел для выступления на конференции. Был на конфе в Альфа месяц назад, ваш материал бы зашёл.
Релизный цикл без компромиссов: надежно для клиентов, удобно для разработки