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

  • Статья

Применяется к этой контрольной рекомендации по операционному превосходству в 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 — это решение для управления тестами на основе браузера, которое легко использовать. Это решение предлагает возможности, необходимые для планового ручного тестирования, проверки приемки пользователей и исследования. Планы тестирования Azure также предоставляют способ получения отзывов от заинтересованных лиц.

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

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

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

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

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

Контрольный список операционных знаний

Ознакомьтесь с полным набором рекомендаций.

Контрольный список операционных знаний