Рекомендации по разработке стратегии устранения сбоев при развертывании
Применяется к следующей рекомендации контрольного списка по достижению операционной эффективности Power Platform Well-Architected:
OE:11 | Внедряйте стратегию устранения сбоев при развертывании, которая позволит устранить непредвиденные проблемы в процессе развертывания и обеспечить быстрое восстановление. Комбинируйте несколько подходов, таких как откат, отключение функций или использование собственных возможностей вашего шаблона развертывания. |
---|
В этом руководстве описаны рекомендации по разработке стандартизированной стратегии для эффективного устранения сбоев развертывания. Как и другие проблемы, связанные с рабочей нагрузкой, сбои развертывания являются неизбежной частью жизненного цикла рабочей нагрузки. При таком подходе вы можете действовать на опережение, имея хорошо продуманную и целенаправленную стратегию реагирования на сбои при развертывании. Такая стратегия позволяет команде по рабочим нагрузкам эффективно устранять сбои с минимальным влиянием на пользователей.
Отсутствие такого плана может привести к хаотичным и потенциально пагубным реакциям на проблемы, что может существенно повлиять на сплоченность команды и организации, доверие клиентов и финансы.
Ключевые стратегии проектирования
Иногда, несмотря на зрелость вашей практики разработки, возникают проблемы с развертыванием. Использование методов безопасного развертывания и надежная цепочка поставок рабочих нагрузок помогут свести к минимуму частоту неудачных развертываний. Кроме того, необходимо разработать стандартизированную стратегию для обработки неудачных развертываний в случае их возникновения.
Стратегия устранения сбоев при развертывании состоит из пяти широких этапов:
- Обнаружение: чтобы отреагировать на неудачное развертывание, необходимо сначала обнаружить сбой. Обнаружение может принимать различные формы, такие как неудачные тесты дыма, пользовательские отчеты или оповещения, которые генерирует ваша платформа мониторинга.
- Решение: вы должны решить, какая стратегия смягчения последствий является наилучшей для конкретного типа сбоя.
- Устранение: необходимо выполнить указанное действие по устранению рисков. Смягчение может принимать форму переключения на резервную систему, отката или наката новой версии.
- Коммуникация: заинтересованные лица и затронутые пользователи должны быть осведомлены о состоянии проблемы по мере ее обнаружения и устранения в соответствии с планом реагирования на чрезвычайные ситуации.
- Анализ после события: последующий анализ без обвинительного уклона дает возможность команде рабочей нагрузки определить области, требующие улучшения, и разработать планы по применению полученных знаний.
В следующих разделах приведены подробные рекомендации для этих этапов.
Обнаружение
Чтобы быстро выявлять проблемы с развертываниями, необходимы надежные методики тестирования и мониторинга, относящиеся к развертываниям. Чтобы быстро обнаруживать аномалии, вы можете дополнить мониторинг рабочих нагрузок и оповещение с помощью средства управления производительностью приложений и ведения журнала с помощью инструментария.
Тестирование состояния и другие проверки качества должны проводиться на каждом этапе развертывания. Успешные тесты в одной группе развертывания не должны влиять на решения о тестировании в последующих группах.
Вы можете реализовать телеметрию, которая сопоставляет проблемы пользователей с этапом развертывания. Затем вы сможете быстро определить, с какой группой развертывания связан конкретный пользователь. Этот подход особенно важен для развертываний с прогрессивным раскрытием, поскольку в любой момент развертывания в вашей пользовательской базе может использоваться несколько конфигураций.
Вы должны быть готовы немедленно реагировать на проблемы, о которых сообщают пользователи. Если это возможно, развертывайте этап развертывания в рабочее время, когда у вас есть полная группа поддержки. Убедитесь, что сотрудники службы поддержки обучены тому, как эскалировать проблемы развертывания для правильной маршрутизации. Эскалация должна соответствовать вашему плану реагирования на чрезвычайные ситуации в рабочей нагрузке.
Решение
При выборе подходящей стратегии устранения проблем развертывания необходимо учитывать следующие факторы:
Тип модели прогрессивной экспозиции, которую вы используете. Например, вы можете использовать сине-зеленую модель или модель канарейки. Если вы используете сине-зеленую модель, переключение на резервную систему более практичен, чем откат. Вы можете легко переместить трафик обратно в стек, в котором выполняется необновленная конфигурация. Затем вы сможете устранить проблему в проблемной среде и повторить попытку развертывания в подходящее время.
Методы, которыми вы располагаете для обхода проблемы. Примеры включают использование флагов функций, переменных среды или любые другие типы свойства конфигурации среды выполнения, которые вы можете включать и выключать. Иногда вы можете легко обойти проблему, отключив флаг функции или переключив настройку. В этом случае вы, возможно, можете:
- Продолжить развертывание.
- Избежать переключения на резервную систему.
- Откатитесь назад, пока исправляете проблемный код.
Уровень усилий, необходимых для внесения исправления в код. Если уровень трудозатрат на исправление кода низкий, для определенных сценариев правильным выбором будет продвижение вперед путем реализации исправления.
Уровень критичности затронутой рабочей нагрузки. Критически важные для бизнеса рабочие нагрузки всегда следует развертывать параллельно, как в сине-зеленой модели, чтобы обеспечить нулевое время простоя. В результате переключение на резервную систему является предпочтительной стратегией смягчения последствий для таких типов рабочих нагрузок.
Устранение
Ниже приведены некоторые распространенные стратегии смягчения последствий:
Откат: в сценарии отката вы возвращаете обновленные системы к состоянию последней удачной конфигурации.
Важно, чтобы вся рабочая нагрузка пришла к согласию относительно значения термина «последнее известное рабочее состояние». Это выражение относится к последнему состоянию рабочей нагрузки, которое было работоспособным до начала развертывания, что не обязательно соответствует предыдущей версии приложения.
Откат может быть сложным, особенно если он связан с изменениями данных. Изменения схемы могут сделать откат рискованным. Их безопасная реализация может потребовать тщательного планирования. В качестве общей рекомендации обновления схемы должны быть аддитивными. Записи не следует заменять новыми. Вместо этого старые записи должны быть признаны устаревшими и должны сосуществовать с новыми записями до тех пор, пока не будет безопасно удалить устаревшие записи.
Резервный вариант: в резервном сценарии обновленные системы удаляются из маршрутизации рабочего трафика. Весь трафик направляется в стек, который не обновляется. Эта стратегия с низким уровнем риска дает вам возможность решать проблемы в вашем коде, не создавая дальнейших сбоев.
При канареечном развертывании откат может быть непростым или даже невозможным, в зависимости от вашей инфраструктуры и дизайна приложения. Если вам необходимо выполнить масштабирование для обработки нагрузки на необновленных системах, выполните это масштабирование, прежде чем выполнить переключение на резервную систему.
Обход вызывающей ошибку функции: если вы можете обойти проблему с помощью флагов функций или другого типа свойства конфигурации среды выполнения, вы можете решить, что продолжение развертывания является правильной стратегией для решения проблемы.
Вы должны четко понимать компромисс, связанный с обходом функции, и иметь возможность сообщить об этом компромиссе заинтересованным сторонам. Заинтересованные стороны должны одобрить план дальнейших действий. Заинтересованным сторонам необходимо определить период времени, в течение которого допустима работа в деградированном состоянии. Им также необходимо сопоставить это решение с вашей оценкой времени, необходимого для исправления проблемного кода и его развертывания.
Экстренное развертывание (исправление): если вы можете решить проблему в середине развертывания, исправление может быть наиболее практичной стратегией устранения.
Как и любой другой код, исправления должны проходить процедуру безопасного развертывания. Но с появлением исправления сроки значительно ускоряются. Вам необходимо использовать стратегию продвижения кода во всех ваших средах. Вам также необходимо проверять код исправления на всех шлюзах качества. Но вам может потребоваться значительно сократить время моделирования и модифицировать тесты, чтобы ускорить их. Убедитесь, что вы можете запустить полные тесты обновленного кода как можно скорее после развертывания. Высокая степень автоматизации тестирования для обеспечения качества помогает сделать тестирование эффективным в таких сценариях.
Коммуникация
Важно четко определить обязанности по обмену информацией, чтобы минимизировать хаос во время инцидентов. Эти обязанности должны определять, как группа рабочей нагрузки взаимодействует с группами поддержки, заинтересованными сторонами и персоналом группы реагирования на чрезвычайные ситуации, например, менеджером по реагированию на чрезвычайные ситуации.
Стандартизируйте периодичность, которой следует группа рабочей нагрузки для предоставления обновлений статуса. Убедитесь, что заинтересованные стороны знают об этом стандарте, чтобы они знали, когда ожидать обновлений.
Если рабочей группе необходимо напрямую общаться с пользователями, уточните тип информации и уровень детализации, которые подходят для совместного использования. Также сообщите группе рабочей нагрузки о любых других требованиях, применимых к этим случаям.
Анализ после события
Анализ после события должен проводиться после всех без исключения неудачных развертываний. Каждое неудачное развертывание — это возможность для обучения. Разбор инцидентов помогает выявить слабые места в процессах развертывания и разработки, а также неправильные конфигурации инфраструктуры.
Анализ после события всегда должен проводиться без обвинительного уклона, чтобы люди, вовлеченные в инцидент, чувствовали себя в безопасности, когда они делятся своими взглядами на то, что можно улучшить. Руководители, ответственные за разбор инцидентов, должны разработать планы по внедрению выявленных улучшений и добавить эти планы в список невыполненных работ по рабочей нагрузке.
Соображения и общие рекомендации
Убедитесь, что ваш конвейер развертывания может принимать разные версии в качестве параметров, чтобы вы могли легко развертывать последние удачные конфигурации.
Поддерживайте согласованность с плоскостями управления и данных при откате назад или вперед. Ключи, секреты, данные о состоянии базы данных и конфигурации, специфичные для ресурсов и политик, — все это должно находиться в области действия и учитываться. Например, обратите внимание на структуру масштабирования вашей инфраструктуры в последнем заведомо удачном развертывании. Определите, нужно ли вам корректировать эту конфигурацию при повторном развертывании кода.
Отдавайте предпочтение небольшим, частым изменениям, а не редким, но большим, чтобы разница между новыми и последними заведомо работоспособными развертываниями была небольшой.
Выполните анализ режима сбоя в своих конвейерах непрерывной интеграции и непрерывной доставки (CI/CD), чтобы выявить проблемы, которые могут усложнить усилия по устранению последствий. Как и в случае с рабочей нагрузкой в целом, конвейеры можно проанализировать, чтобы выявить области, в которых могут возникнуть проблемы при попытке применить тот или иной тип устранения рисков.
Используйте функцию автоматического отката разумно:
- Некоторые инструменты CI/CD, такие как Azure DevOps, имеют встроенную функцию автоматического отката. Рассмотрите возможность использования этой функции, если она представляет для вас реальную ценность.
- Вам следует использовать функцию автоматического отката только после тщательного и регулярного тестирования вашего конвейера. Убедитесь, что ваш конвейер достаточно развит, чтобы вызвать дополнительные проблемы в случае запуска автоматического отката.
- Вам нужно быть уверенным, что автоматизация развертывает только необходимые изменения и срабатывает только при необходимости. Тщательно создавайте триггеры, чтобы они соответствовали этим требованиям.
Используйте возможности платформы во время откатов. Например, резервное копирование и восстановление на определенный момент времени могут помочь с хранением и откатами данных. Или, если вы используете виртуальные машины для размещения приложения, может быть полезно восстановить среду до контрольной точки, существовавшей непосредственно перед инцидентом.
Регулярно тестируйте всю стратегию устранения сбоев при развертывании. Подобно планам реагирования на чрезвычайные ситуации и планам аварийного восстановления, ваш план развертывания при отказе будет успешным только в том случае, если ваша команда обучена ему и регулярно применяет его. Хаос-инжиниринг и тестирование с внесением ошибок могут быть эффективными методами тестирования вашей стратегии смягчения последствий развертывания.
Возможности в Power Platform
Конвейеры в Power Platform направлены на демократизацию управления жизненным циклом приложений (ALM) для клиентов Power Platform и Dynamics 365 за счет внедрения в службу возможностей автоматизации ALM, а также непрерывной интеграции и непрерывной доставки (CI/CD).
Инструменты Microsoft Power Platform Build Tools для Azure DevOps можно использовать для автоматизации общих задач сборки и развертывания, связанных с приложениями, созданными на основе Power Platform.
GitHub Actions для Power Platform позволяют разработчикам создавать автоматизированные рабочие процессы жизненного цикла разработки программного обеспечения. С помощью GitHub Actions для Microsoft Power Platform вы можете создавать бизнес-процессы в своем репозитории для создания, тестирования, упаковки, выпуска и развертывания приложений; выполнять автоматизацию; и управлять ботами и другими компонентами на базе Microsoft Power Platform.
Ускоритель ALM представляет собой инструмент с открытым исходным кодом, который состоит из набора приложений, сценариев и конвейеров, предназначенных для автоматизации процесса непрерывной интеграции/непрерывной поставки.
Автоматизация тестов с помощью Azure Pipelines.
Используйте комплект Power CAT Copilot Studio для настройки агентов и тестов. Путем выполнения отдельных тестов для API-интерфейсов Copilot Studio (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. Эти данные телеметрии можно использовать для отслеживания зарегистрированных сообщений и событий, отправляемых в агент и из него, тем, которые будут запускаться во время разговоров с пользователями, и пользовательских событий телеметрии, которые могут быть отправлены из ваших тем.
Контрольный список операционной эффективности
Обратитесь к полному набору рекомендаций.