Рекомендации по разработке стратегии устранения сбоев развертывания

  • Статья

Применяется к этой рекомендации по контрольным спискам операционной эффективности Azure Well-Architected Framework:

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

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

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

Ключевые стратегии проектирования

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

При использовании модели развертывания с прогрессивной экспозицией в качестве стандартной практики:

  • У вас есть правильная основа для минимизации влияния на клиентов или внутренних пользователей при сбое развертывания.
  • Вы можете эффективно устранять проблемы.

Стратегия устранения сбоев развертывания состоит из пяти основных этапов:

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

  2. Решение. Вы должны решить, какая стратегия устранения рисков лучше подходит для конкретного типа сбоя.

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

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

  5. Postmortem. Без вины посмертные операции предоставляют команде рабочей нагрузки возможности для определения областей для улучшения и создания планов применения обучения.

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

Обнаружение

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

  • Используйте средство управления производительностью приложений.
  • Включите ведение журнала с помощью инструментирования.

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

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

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

Решение

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

  • Тип используемой модели прогрессивной экспозиции. Например, можно использовать сине-зеленую модель или канарееевидную модель.

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

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

    Иногда проблему можно легко обойти, отключив флаг функции или переключив параметр. В этом случае вы можете:

    • Продолжайте развертывание.
    • Избегайте падения назад.
    • Откат, пока вы исправляете код, который обижает ошибку.

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

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

  • Уровень важности для затронутой рабочей нагрузки.

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

  • Тип инфраструктуры, используемой рабочей нагрузкой— изменяемой или неизменяемой.

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

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

Меры по снижению риска

  • Откат. В сценарии отката вы отменить изменения обновленные системы до последнего известного состояния конфигурации.

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

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

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

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

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

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

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

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

Компромиссы:

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

Связь

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

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

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

безобвинительное рассмотрение аварийной ситуации;

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

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

Рекомендации и рекомендации

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

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

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

Выполните анализ режима сбоя (FMA) в конвейерах непрерывной интеграции и непрерывной поставки (CI/CD), чтобы выявить проблемы, которые могут усложнить устранение рисков. Как и рабочая нагрузка в целом, конвейеры можно проанализировать, чтобы определить области, которые могут быть проблемными при попытке определенного типа устранения рисков.

Используйте функцию автоматического отката с осторожностью:

  • Некоторые средства CI/CD, такие как Azure DevOps, имеют встроенную функцию автоматического отката. Рассмотрите возможность использования этой функции, если она обеспечивает ощутимую ценность для вас.
  • Функцию автоматического отката следует применять только после тщательного и регулярного тестирования конвейера. Убедитесь, что конвейер достаточно зрелый, чтобы создать дополнительные проблемы при активации автоматического отката.
  • Необходимо верить, что служба автоматизации развертывает только необходимые изменения и что она активируется только при необходимости. Тщательно разрабатывайте триггеры в соответствии с этими требованиями.

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

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

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

Упрощение поддержки Azure

  • Azure Pipelines предоставляет службы сборки и выпуска для поддержки CI/CD приложений.

  • Azure Test Plans — это простое в использовании решение для управления тестами на основе браузера. Это решение предлагает возможности, необходимые для планового ручного тестирования, пользовательского приемочного тестирования и исследовательского тестирования. Azure Test Plans также предоставляет способ сбора отзывов от заинтересованных лиц.

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

  • Application Insights — это расширение Monitor, которое предоставляет функции мониторинга производительности приложений (APM).

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

  • Многие службы баз данных Azure предоставляют функции восстановления на определенный момент времени, которые могут помочь вам в откате:

  • Azure Chaos Studio (предварительная версия ) — это управляемая служба, которая использует хаос-инженерию для измерения, понимания и повышения устойчивости облачных приложений и служб.

Контрольный список эффективности операций

См. полный набор рекомендаций.

Контрольный список эффективности операций