Текстовый курс по DevOps

Как развёртывать код в рабочей среде с низким риском?

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

В вашей команде DevOps встроены механизмы контроля и снижения риска

В обычной ИТ-организации разработчики создают ПО, а специалисты эксплуатации развёртывают его. DevOps переносит контроль и снижение рисков из других подразделений в вашу компетентную и самодостаточную команду. Она использует автоматическое развёртывание и коллегиальную проверку внутри команды.

Рабочие и остальные среды так же важны, как ПО, которое создаёт команда DevOps. Поэтому команда следует трём принципам:

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

Встроенный механизм самостоятельного развёртывания

Автоматический механизм самостоятельного развёртывания работает следующим образом.

1. Напишите код и внесите его в основную ветку.
2. Соберите пакеты для развёртывания.
3. Проверьте пакеты, зависимости и готовность конфигурации.
4. Проверьте готовность среды.
5. Запустите автоматизированные тесты.
6. Запишите все результаты проверок и автоматизированных тестов для аудита и соблюдения требований.
7. Разверните пакеты в целевой среде.
8. Запустите автоматизированные тесты в целевой среде, чтобы проверить развёртывание.
9. Отслеживайте показатели системы, производительности и активности целевой среды.
10. Дайте быструю обратную связь. Если что-то пошло не так, исправьте или откатите развёртывание.

Развёртывание и выпуск — разные действия

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

Сине-зелёное развёртывание

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

Канареечное развёртывание
(также известное как скрытый запуск)

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

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

Facebook, Google и многие другие ведущие технологические компании используют канареечное развёртывание в форме скрытого запуска (Dark Launch). Они постепенно открывают новые функции небольшим группам пользователей и тестируют их, прежде чем сделать доступными всем. Так они узнают, нравится ли вам функция и как она влияет на производительность системы. Facebook называет свой инструмент скрытого запуска Gatekeeper, поскольку он управляет доступом пользователей к каждой новой функции.

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

Схема выпуска «иммунная система кластера»

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

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

Если автоматизированные тесты на оранжевом сервере и данные мониторинга показывают хорошие результаты, команда DevOps может гораздо увереннее развёртывать код на остальных синих кластерах серверов. Схема выпуска «иммунная система кластера» даёт команде DevOps:

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

Переключатели функций

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

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

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

Проектируйте архитектуру для более безопасных выпусков

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

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

Шаблон постепенного замещения приложения для перехода на микросервисы с низким риском

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

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

Ebay одной из первых применила шаблон постепенного замещения приложения для перехода с унаследованного монолита на микросервисы. Компания начала с того, что скрыла приложения за чётко определёнными универсальными API в своей экосистеме, чтобы не переписывать весь существующий код за один раз. Инженеров распределили по небольшим командам от 6 до 10 человек. Теперь команда численностью до 10 человек может поддерживать универсальный API аукционной платформы — самый востребованный аукционный API в мире.

ВЫВОДЫ

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

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