Методики безопасного развертывания

Иногда выпуск не соответствует ожиданиям. Несмотря на использование рекомендаций и передачу всех шлюзов качества, иногда возникают проблемы, которые приводят к возникновению непредвиденных проблем для пользователей. Чтобы свести к минимуму и уменьшить влияние этих проблем, командам DevOps рекомендуется принять прогрессивную стратегию воздействия , которая балансирует воздействие данного выпуска с его проверенной производительностью. Как выпуск доказывает себя в рабочей среде, он становится доступным для уровней более широкой аудитории, пока все не используют его. Teams может использовать безопасные методики развертывания, чтобы максимально повысить качество и скорость выпусков в рабочей среде.

Управление воздействием на клиентов

Команды DevOps могут использовать различные методики для контроля воздействия обновлений для клиентов. Исторически тестирование A/B было популярным выбором для команд, желающих увидеть, как разные версии службы или пользовательского интерфейса выполняются в целевых целях. Тестирование A/B также относительно легко использовать, так как изменения обычно являются незначительными и часто сравниваются только разные выпуски на клиентском крае службы.

Сейф развертывание с помощью кругов

По мере роста платформ, масштабирования инфраструктуры и аудитории, как правило, растет. Это создает спрос на модель развертывания, которая балансирует риски, связанные с новым развертыванием, с преимуществами обновлений, которые она обещает. Общая идея заключается в том, что данный выпуск должен быть сначала предоставлен только небольшой группе пользователей с наивысшей терпимостью к риску. Затем, если выпуск работает должным образом, он может быть предоставлен более широкой группе пользователей. Если проблем нет, процесс может продолжаться через более широкие группы пользователей или кольца, пока все не будут использовать новый выпуск. С помощью современных платформ непрерывной доставки , таких как GitHub Actions и Azure Pipelines, создание процесса развертывания с кольцами доступно для команд DevOps любого размера.

Флаги функций

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

Согласие пользователя

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

Несколько методик обычно используются одновременно. Например, команда может иметь экспериментальную функцию, предназначенную для очень конкретного варианта использования. Так как это рискованно, они развернут его в первом кольце для внутренних пользователей, чтобы попробовать. Однако, несмотря на то, что функции находятся в коде, кому-то потребуется задать флаг компонента для определенного развертывания в кольце, чтобы эта функция была предоставлена через пользовательский интерфейс. Даже тогда флаг функции может предоставить пользователю возможность использовать новую функцию только для пользователя. Любой, кто не в круге, в этом развертывании или не принял участие, не будет предоставляться функции. Хотя это довольно убедительный пример, он служит для иллюстрации гибкости и практическисти прогрессивного воздействия.

Распространенные проблемы, с которыми сталкиваются команды на ранних этапах

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

Полезные данные слишком большие

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

Изоляция службы отсутствует

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

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

Действия вручную приводят к ошибкам

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

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

Только ops может выполнять развертывания

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

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

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

Основные принципы

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

Быть согласованным

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

Забота о качествах сигналов

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

Для развертываний требуется нулевое время простоя

Хотя это не важно для каждой службы всегда быть доступным, команды должны подходить к их этапам доставки и операций DevOps с учетом того, что они могут и должны развертывать новые версии без необходимости их отключать в любое время. Современные средства инфраструктуры и конвейера достаточно расширены сейчас, когда это возможно для практически любой команды, чтобы обеспечить 100 % времени простоя.

Развертывание должно происходить в рабочее время

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

Развертывание на основе круга

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

Пример модели кольца

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

Ring	Характер использования	Пользователи	Центр обработки данных
0	Находит большую часть ошибок, влияющих на пользователя при развертывании	Только внутренние, высокий уровень терпимости к рискам и ошибкам	Центрально-западная часть США
1	Области, которые команда не тестирует подробно	Клиенты, использующие широкий набор продуктов	Небольшой центр обработки данных
2	Проблемы, связанные с масштабированием	Общедоступные учетные записи, в идеале бесплатные, используя разнообразный набор функций	Средний или большой центр обработки данных
3	Масштабирование проблем во внутренних учетных записях и международных связанных проблемах	Крупные внутренние учетные записи и европейские клиенты	Внутренний центр обработки данных и европейский центр обработки данных
4	Оставшиеся единицы масштабирования	Все остальные	Все целевые объекты развертывания

Разрешить время выпечки

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

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

Ускорение исправлений

Инцидент динамического сайта (LSI) возникает, когда ошибка оказывает серьезное влияние на рабочую среду. LSIs требует создания исправления, которое является внеполнимым обновлением, предназначенным для решения проблем с высоким приоритетом.

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

Ошибки, оцененные как Sev 1 , должны быть развернуты через кольцо 0, но затем их можно развернуть в затронутых единицах масштабирования сразу после утверждения.

Исправления для ошибок с более низкой серьезностью должны быть развернуты через все кольца, как планируется.

Основные итоги

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

• Часто развертывать.
• Оставайтесь зеленым на спринте.
• Используйте согласованные средства развертывания в разработке, тестировании и рабочей среде.
• Используйте платформу непрерывной доставки, которая обеспечивает автоматизацию и авторизацию.
• Следуйте рекомендациям по безопасному развертыванию.

Следующие шаги

Узнайте, как флаги функций помогают управлять воздействием новых функций пользователями.