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

Применимо к этой рекомендации Power Platform контрольного списка хорошо спроектированного операционного совершенства:

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

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

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

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

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

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

1. Обнаружение: Чтобы отреагировать на неудачное развертывание, необходимо сначала обнаружить сбой. Обнаружение может осуществляться различными способами, например, неудачные тесты на дым, пользовательские отчеты или оповещения, которые генерирует ваша платформа мониторинга.
2. Решение: Вы должны решить, какая стратегия смягчения последствий является наилучшей для конкретного типа сбоя.
3. Смягчение: Вы должны выполнить указанные действия по смягчению. Смягчение может принимать форму переключения на резервную систему, отката или наката новой версии.
4. Коммуникация: Заинтересованные стороны и затронутые пользователи должны быть осведомлены о статусе по мере обнаружения и устранения проблемы, как того требует ваш план действий в чрезвычайных ситуациях ответ.
5. Постсмертный анализ: безупречный постсмертный анализ дает рабочей группе возможность определить области для улучшения и разработать планы по применению полученных знаний.

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

Обнаружение

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

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

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

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

Решение

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

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

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

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

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

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

Устранение

Ниже приведены некоторые распространенные стратегии смягчения последствий:

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

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

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

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

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

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

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

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

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

Коммуникация

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

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

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

Анализ после события

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

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

Соображения и общие рекомендации

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

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

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

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

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

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

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

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

Возможности в Power Platform

Pipelines Power Platform направлены на демократизацию управления жизненным циклом приложений (ALM) для Power Platform клиентов Dynamics 365 путем внедрения в сервис возможностей автоматизации ALM, непрерывной интеграции и непрерывной поставки (CI/CD).

Microsoft Power Platform Инструменты сборки для Azure DevOps могут использоваться для автоматизации общих задач сборки и развертывания, связанных с приложениями, созданными на Power Platform.

Действия GitHub для Power Platform позволяют разработчикам создавать автоматизированные рабочие процессы жизненного цикла разработки программного обеспечения. С помощью GitHub Actions для Microsoft Power Platform вы можете создавать бизнес-процессы в своем репозитории для создания, тестирования, упаковки, выпуска и развертывания приложений; выполнять автоматизацию; и управлять ботами и другими компонентами на базе Microsoft Power Platform.

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

Автоматизируйте тесты с помощью Azure Pipelines.

Используйте Мощность CAT Copilot Studio Набор для настройки вторых пилотов и тестов. Проводя индивидуальные тесты против Copilot Studio API (Direct Line), ответы второго пилота оцениваются по отношению к ожидаемым результатам.

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

Power Platform среды предоставляют функциональность восстановления на определенный момент времени, которая может помочь вам выполнить откат.

Power Platform интегрируется с Application Insights, которая является частью экосистемы Azure Monitor. Используйте эту интеграцию для того, чтобы обеспечить следующее:

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

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

• Настройте Power Automate телеметрию для передачи в Application Insights; например, для мониторинга выполнения облачный поток и создания оповещений об ошибках выполнения облачный поток.

• Собирайте данные телеметрии от вашего Microsoft Copilot Studio второго пилота для использования в Azure Application Insights. Вы можете использовать эту телеметрию для мониторинга зарегистрированных сообщений и событий, отправляемых вашему второму пилоту и получаемых от него, тем, которые будут запускаться во время разговоров пользователей, а также пользовательских событий телеметрии, которые могут отправляться из ваших тем.

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

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

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