Искусство отличного развертывания
29 июля 2025 г.Мы живем в эпоху высокочастотных развертываний программного обеспечения, где обновляются программные продукты для массовых рыночных продуктов несколько раз в день, иногда доставляя сотни или даже тысячи изменений. Возьмите Facebook, например: он ежедневно продвигает тысячи изменений кода на миллиарды пользователей по всему миру (Непрерывное развертывание в Facebook и Oanda) Тенденция постоянна и, вероятно, ускоряется с развитием ИИ и LLMS.
Почему спешка
Высокочастотные развертывание-это не только скорость ради скорости; Они об обучении быстрее, быстро экспериментируют и адаптируются к постоянно меняющимся потребностям пользователей. Компании могут быстро проверять идеи и оставаться конкурентоспособными на быстро развивающемся рынке.
Однако развертывание кода или конфигурации на этой частоте является серьезным бизнесом. Большинство проблем с производством не вызваны сокращением волокна или штормами ветра - они из -за ошибок, проскользнувших по нашим системам и попаданию конечных пользователей (Как бороться с инцидентами на производство? Эмпирическое исследование крупномасштабного облачного сервиса) И стоимость нарушений надежности высока.
Миф о стабильности
Так что у нас есть? С одной стороны, предприятия хотят развертываться чаще и адаптироваться к быстрорастущим рынкам. С другой стороны, стоимость неисправных изменений, влияющих на надежность/конечных пользователей, высока. Как оптимизировать оба? Это похоже на компромисс: скорость против стабильности.
Быстрая проверка реальности показывает наоборот, хотя исследования Доры неоднократно продемонстрировали, что скорость и стабильностьне компромиссПолем На самом деле, более частые, меньшие изменения, как правило, менее рискованные, чем крупные, редкие.
Как развернуться чаще
Всякий раз, когда возникают темы развертывания программного обеспечения, вы часто услышите такие слова, как «DevOps» и «CI/CD». Спрос на лучшие трубопроводы развертывания настолько высок, что целые предприятия создали эти концепции. Платформы, такие как действия GitHub, Gitlab и Circleci, позволяют миллионам разработчиков автоматизировать сборки и развертывание (см.Что такое CI/CD?)
В этом есть нечто большее, чем просто инструмент. Основной идеей, лежащей в основе толкания чаще, может быть: перестаньте рассматривать развертывание как рискованное событие и начать рассматривать его как повторяемую, автоматизированную рутину с низким риском.
Чтобы добраться туда, как инженерные практики, так и инфраструктура должны развиваться, чтобы расширить возможности инженерных команд для владения сквозными изменениями. Это означает, что инженер, работающий над функцией, часто находится в лучшем положении, чтобы безопасно свернуть его. Эта модель часто принимается компанией по массовым продуктам, например,SpotifyВМета, Netflix и другие.
Двигаться быстрои сломать вещисо стабильной инфраструктурой
«Двигаться быстро и сломать вещи» был девизом Facebook примерно в 2014 году, прежде чем он перешел на«Быстро двигаться со стабильной инфраструктурой»Полем Это отразило глубокий сдвиг в инженерной культуре, признавая, что нарушение вещей на самом деле не ускоряет вас, когда эксплуатационная стоимость высока.
С тех пор отрасль прошла долгий путь и разработала солидный набор практик и моделей. Сегодня безопасные методы развертывания хорошо известны. Давайте пройдемся через ключевые ингредиенты.
Функция владения
Ожидается, что инженеры будут владеть развертыванием. Это практически означает три вещи: тестировать вещи, контролировать вещи и иметь стратегию отката.
Как вы проверяете функции? В отличном плане испытаний должен быть как ручной компонент, объясняющий точные шаги, которые вы предприняли (что новый инженер в вашей команде может легко следовать), так и автоматический компонент.
По мере того, как этот код выпускается, как вы будете следить за его здоровьем? Ссылка на конкретные инструментальные панели, на которые вы будете смотреть во время развертывания. Это должно быть указано в разделе плана испытаний DIFF.
Как узнать, что что -то пойдет не так? Получите метрики, настройки оповещений. Ключ здесь в том, что состояние выбранного вами. Вы решаете, что нормально и ненормальные условия для вашего компонента, и когда условие требует просто открытия задачи или фактического призывания к вызову.
Прогрессивный развертывание / канарейка
Как мы ограничиваем радиус взрыва неудач? Разверните новые изменения в небольшой процент пользователей или серверов (например, 1%), прежде чем постепенно расширяться. Например, типичные обновления мета -продукта включают в себя стадию собак, то есть в Канарском выпуске на сотрудниках сначала, чтобы выявить проблемы, прежде чем они попадут в остальные пользователи.
Особенность помещения / стробирования
Традиционно развертывание и выпуск происходит вместе; Вы отправляете новый код, и эта функция работает сразу. Но по мере увеличения пропускной способности изменения эта связь не очень хорошо масштабируется. Флаги функций решают это путем развертывания развертывания от выпуска. Вы можете безопасно развернуть код, а затем использовать конфигурационные переключатели для управления, кто видит эту функцию (например, сотрудники, бета -пользователи или конкретные регионы).
A/B тестирование
Как мы измеряем воздействие, а не только правильность? A/B -тестирование часто используется для количественной оценки воздействия изменения путем назначения трафика для управления и тестирования групп со статистическими тестами.
Все изменение
Код? Изменять. Конфигурация? Изменять. Обновление ACL? Также изменение. Фактически, изменения конфигурации часто бывают даже более рискованными, чем изменения кода.
Это означает, что все изменения, независимо от типа, должны следовать более или менее одинаковым принципам:
- Канарская первая
- Проверить с помощью метрик
- Автоматическая сбоя при неудаче
Конечная цель
Цель не просто отправить больше. Это нужно более безопасно. С стабильной инфраструктурой, автоматическими проверками и сильной собственности, быстрая итерация становится нормой, а не исключением. Это искусство большого развертывания.
Оригинал