Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Выполнение — это этап реализации плана модернизации. Этот шаг включает подготовку всех пользователей к изменению, выполняя разработку в непроизводственных средах. Тщательно протестируйте и развертываете в рабочей среде контролируемым образом. Основное внимание уделяется строгому тестированию и безопасному развертыванию, чтобы свести к минимуму нарушения бизнес-процессов, учитывая, что изменения могут быть значительными.
Подготовка заинтересованных лиц к модернизации
Перед началом развертывания важно подготовить всех заинтересованных лиц и пользователей к предстоящим действиям. Сюрпризы могут привести к путанице или даже операционным проблемам. Ключевые шаги подготовки включают обмен данными, замораживание изменений (упомянутых ранее) и планы поддержки:
Сообщите о расписании развертывания всем заинтересованным лицам. Заранее сообщите всем пострадавшим сторонам, когда должно произойти развертывание модернизации и что ожидать. Включите ключевые даты, такие как замораживание изменений и окно запуска, чтобы помочь заинтересованным лицам подготовиться соответствующим образом. Задав ожидания, пользователи могут планировать время простоя, а внутренние команды могут быть готовы.
Реализуйте замораживание изменений для исходных и зависимых рабочих нагрузок. Как и планировалось ранее в системе управления, сейчас пришло время на самом деле применить замораживание. Убедитесь, что изменения кода, изменения конфигурации или другие развертывания не выполняются в рабочей нагрузке (и зависимых рабочих нагрузок) в течение некоторого периода до и во время развертывания. Это обеспечивает стабильную среду. Убедитесь, что все члены команды и все интегрированные сторонние стороны осведомлены. Четко определите окно заморозки с определенным временем начала и окончания, чтобы избежать путаницы.
Обмен данными о конечных действиях пользователя и изменениях после развертывания. Пользователям требуется заранеее уведомление о необходимых действиях до и после развертывания, чтобы предотвратить нарушение рабочего процесса. Укажите пользователям, чтобы они вышли из системы или сохранили работу перед началом процедуры переключения. Распространите новые URL-адреса доступа, изменения в проверке подлинности, такие как требования к входу Microsoft Entra ID, и обновленные рабочие процессы, которые влияют на ежедневные операции. Предоставьте документацию по поддержке и краткие руководства по началу работы, чтобы снизить путаницу в первый день.
Координация поддержки персонала для развертывания. ИТ-операции и команды разработки должны быть доступны для мониторинга и реагирования на проблемы во время критически важных этапов развертывания. Запланируйте расширенные часы поддержки и задействуйте дополнительных сотрудников для первого рабочего дня после внедрения, когда проблемы наиболее вероятны. Сообщите бизнес-подразделениям о планах поддержки после развертывания и процедурах эскалации, чтобы обеспечить быстрое разрешение проблем.
Определите резервные процедуры для критически важных рабочих нагрузок. Критически важные рабочие нагрузки требуют ручных обходных решений и планов на непредвиденные случаи для поддержания бизнес-операций во время окон развертывания. Документируйте определенные процедуры, такие как обработка заказов вручную во время периодов, доступных только для чтения рабочей нагрузки. Поделитесь этими процедурами заранее и подтвердите готовность к работе с затронутыми командами, чтобы обеспечить простое выполнение по мере необходимости.
Разработка модернизаций в непроизводственных средах
Все изменения в разработке и интеграции модернизации должны происходить вне рабочей среды (в средах разработки, тестирования, промежуточной среды). Руководящий принцип: сначала сборка и тестирование в средах, аналогичных прод, чтобы при развертывании в prod, конфигурация уже будет проверенной.
Следуйте принципам Well-Architected Framework во время реализации. При коде и настройке новых изменений постоянно применяются рекомендации из Azure Well-Architected Framework (WAF). Используйте Помощник по Azure рекомендации и процессы проверки архитектуры для проверки решений по проектированию. Этот подход гарантирует, что модернизованные компоненты соответствуют Azure рекомендациям и операционным стандартам.
Создайте непроизводственные среды, которые отражают рабочую среду. Развертывание сред разработки и тестирования в Azure, которые максимально близки к рабочей настройке. Если в рабочей среде используются определенные службы Azure, используйте то же самое в тестовом режиме, меньший масштаб или более низкий уровень производительности (SKU) для экономии затрат. Чем ближе среда тестирования к рабочей среде, тем более уверенно вы можете быть, что результаты теста должны переноситься в рабочее поведение.
Реализуйте изменения постепенно с помощью системы управления версиями и CI/CD. Относитесь к усилиям по модернизации, как и к любому другому проекту программного обеспечения. Используйте Git или другую систему управления версиями для всех изменений кода и скриптов инфраструктурного кода. Он предоставляет историю изменений и возможность отката кода при необходимости. Разделить работу на небольшие приращения (возможно, для каждой функции или исправления) и использовать фичевые ветки. Чаще объединяйте изменения после проверки кода. Настройте сборки непрерывной интеграции для запуска наборов тестов при каждой фиксации, чтобы выявлять проблемы на ранней стадии.
Проверка изменений модернизации с помощью тестирования
Тестирование является критически важным. Так как модернизация не добавляет новые функции, основное внимание уделяется тестированию регрессии (ничего не сломалось), тестированию производительности (производительность соответствует предыдущим уровням или превышает предыдущие уровни) и тестированию безопасности (средства управления безопасностью остаются эффективными или усилены). Перед внесением изменений в рабочую нагрузку в продуктивной среде необходимо проверить каждый ее аспект в тестовой среде.
Выполнение модульных и интеграции тестов для всех измененных компонентов. Разработчики должны создавать или обновлять модульные тесты для любого кода, который был рефакторингован. Даже если это устаревший код, написание модульных тестов для критически важных функций может помочь поймать, если рефакторинг изменил поведение непреднамеренно. Непрерывно выполняйте модульные тесты в конвейере CI. Кроме того, выполните тесты интеграции, чтобы обеспечить правильность взаимодействия компонентов друг с другом. После устранения ошибок повторно выполните соответствующие тесты, чтобы убедиться, что ошибка действительно устранена, и ничего другого не сломалось (избегайте регрессий).
Проводите сквозное функциональное тестирование. В промежуточной или тестовой среде выполните полные тесты рабочего процесса, как если бы вы являетесь конечным пользователем. Это может быть ручное тестирование по QA или автоматическим тестам пользовательского интерфейса. Войдите в приложение, выполняйте основные задачи. Убедитесь, что без изменений функциональность остается неизменной. Основной целью является моделирование реального использования, чтобы выявить то, что может быть упущено при модульных тестах.
Выполните тестирование принятия пользователей (UAT) с заинтересованными лицами. Для тестирования модернизированной рабочей нагрузки перед переходом в режим реального времени необходимо привлечь некоторых конечных пользователей или заинтересованных лиц бизнеса. Они могут поймать нюансы, которые разработчики упускают из виду. Запишите отзывы об удобстве использования, производительности и недостатках функциональности. Устраните критически важные проблемы, связанные с приемочным тестированием пользователей (UAT) перед развертыванием и получение официального утверждения от заинтересованных лиц для подтверждения готовности бизнеса.
Проверьте производительность с помощью нагрузочного тестирования в реалистичных условиях. Модернизация должна в идеале улучшить или поддерживать производительность. Используйте средства нагрузочного тестирования, такие как Нагрузочное тестирование Azure, для имитации реалистичных шаблонов использования. Сравните результаты с базовыми показателями производительности из исходной среды, чтобы определить любое снижение производительности. Проводите стресс-тесты на 150% ожидаемой нагрузки, чтобы определить ограничения рабочей нагрузки и проверить устойчивость под давлением.
Выполнение проверок безопасности и проверок соответствия требованиям. Запуск проверок уязвимостей на новых образах кода и контейнеров для обнаружения рисков безопасности. Выполните проверку соответствия для регулируемых рабочих нагрузок с помощью отраслевых средств. Используйте Microsoft Defender для облака для проверки неправильной конфигурации инфраструктуры и проверки соответствия требованиям элементов управления безопасностью.
Устраните все критические проблемы перед развертыванием в рабочей среде. Исправлены функциональные, производительность и проблемы безопасности, выявленные на этапах тестирования. Убедитесь, что все тесты проходят и производительность соответствует соглашениям об уровне обслуживания (SLA). Задокументируйте все оставшиеся проблемы с низким приоритетом и создайте планы исправления для решения после развертывания.
Создание повторно используемых инфраструктур
После успешного прохождения всех тестов вашим модернизированным решением в непроизводственной среде, необходимо записать настройки инфраструктуры и конфигурации в виде кода, чтобы их можно было легко реплицировать в производственной и будущих средах. Повторно используемая инфраструктура означает использование шаблонов инфраструктуры как кода (IaC) и автоматизации для согласованности и скорости.
Создайте шаблоны IaC для проверенных конфигураций. Выполните окончательную архитектуру тестовой среды (которая отражает то, что требуется в prod) и кодифицируйте ее. Используйте Bicep, Terraform или Azure Resource Manager шаблоны для определения инфраструктуры. Параметризуйте эти шаблоны, чтобы их можно было повторно использовать для различных этапов, таких как разработка, тестирование, с небольшими настройками, такими как имена или размеры. Эта настройка гарантирует, что созданная рабочая среда соответствует тестируемой среде. Это позволяет избежать человеческих ошибок при ручной навигации по порталу Azure для создания ресурсов. Это также означает, что если вы когда-либо хотите повторно создать среду, например для аварийного восстановления или развертывания в новых регионах, у вас будет готово развертывание инфраструктуры. Дополнительные сведения см. в разделе CAF Manage - Manage code-based deployments.
Храните шаблоны в элементе управления версиями. Проверьте код инфраструктуры в репозитории Git (наряду с кодом приложения или в отдельном репозитории). Используйте GitHub или Azure DevOps для управления ресурсами IaC с соответствующим управлением версиями. Управление версиями включает проверки кода, поддерживает совместную работу команды и поощряет повторное использование шаблона в проектах. Этот подход обеспечивает полную отслеживаемость изменений в инфраструктуре и поддерживает возможность отката при возникновении проблем.
Автоматизация установки и настройки зависимостей. Создайте скрипты или задачи конвейера для развертывания этих шаблонов, а также обработайте все необходимые задачи конфигурации или заполнения. Используйте Azure Pipelines, GitHub Actions для выполнения заданий развертывания, которые принимают шаблон IaC и развертывают в целевой подписке или группе ресурсов. Автоматизация установки зависимостей приложений, настройки параметров и управления секретами. Цель — это настройка среды в один щелчок (или однокомандный процесс): с нуля до полностью работающей среды, которая соответствует ранее протестированной.
Протестируйте IaC и автоматизацию от начала до конца. Используйте отдельную Azure подписку или группу ресурсов в качестве песочницы и практики развертывания всей среды с нуля с помощью шаблонов и сценариев. Проверьте, что шаблоны, конвейеры и скрипты IaC могут создавать полный стек инфраструктуры из ничего. Проверьте различные сценарии развертывания, включая начальное развертывание, обновления конфигурации и процедуры отката, чтобы убедиться, что автоматизация работает правильно.
Дополнительные сведения см. в разделах «Проектирование цепочки поставок для разработки рабочих нагрузок» и «Инфраструктура как код» в WAF.
Создание документации по развертыванию
Несмотря на автоматизацию, наличие хорошей документации по развертываниям имеет решающее значение для аудита, для подключения новых участников команды и для дальнейшего обслуживания. Документация по развертыванию должна охватывать конфигурации, процедуры и шаги отката в форме, доступной для чтения человеком.
Параметры и шаги конфигурации документов. Запишите все параметры среды, строки подключения, конечные точки службы и конфигурации безопасности в доступной документации. Включите пошаговые инструкции по развертыванию, требования к предварительным требованиям и этапы проверки после развертывания. Эта документация включает согласованные развертывания и поддерживает устранение неполадок при возникновении проблем. Если новому инженеру пришлось бы развернуть систему, они могли бы прочитать этот документ, чтобы следовать инструкциям или понять выходные данные конвейера сборки.
Обновите процедуры отката и восстановления. После завершения тестов задокументируйте шаги для отмены изменений в случае возникновения проблем с развертыванием. Включите триггеры отката, процедуры резервного копирования и восстановления данных и шаги проверки восстановления. Регулярно тестируйте процедуры отката и восстановления, чтобы убедиться в их исправной работе в случае необходимости. Эта подготовка снижает время простоя.
Соберите всю эту документацию в централизованном месте. Используйте SharePoint, GitHub или вики-сайт для хранения этих сведений. Убедитесь, что команда и сотрудники службы поддержки знают, где его найти. Во время стрессового инцидента наличие четких документов под рукой является спасением.
Развертывание модернизации
Развертывание в рабочей среде является последним этапом усилий по модернизации. В зависимости от выбранной стратегии (на месте и параллельно), шаги отличаются. Перед выполнением убедитесь, что все этапы подготовки выполнены: заинтересованные лица информированы, заморозка в действии, резервные копии созданы, мониторинг в режиме ожидания.
Развертывание модернизации на месте
Запланируйте период обслуживания. Если изменения требуют простоя или запуска скриптов, которые блокируют ресурсы, например миграцию схемы базы данных, сделайте это в заранее объявленное окно обслуживания. Убедитесь, что все пользователи отключаются от рабочей нагрузки в то время. Наличие четкого временного интервала также дает цель для завершения развертывания или принятия решения о возврате, если время заканчивается.
Используйте конвейер CI/CD для развертывания. Производственное развертывание должно использовать тот же автоматизированный конвейер, который вы использовали для тестирования, но указывает в рабочую среду. Эта настройка обеспечивает согласованность, поэтому инфраструктура и код развертываются так же. Перед запуском выполните окончательные резервные копии всех критически важных данных (баз данных). Даже если вы можете выполнить откат, наличие резервной копии обеспечивает дополнительную защиту в случае сбоя. Запустите конвейер для развертывания новых изменений кода и инфраструктуры. Есть журналы и мониторинг, видимые в режиме реального времени. Если какой-либо шаг завершается ошибкой, остановитесь и оцените, можно ли применить исправление или следует выполнить откат.
При возможности реализуйте прогрессивную маршрутизацию трафика (canary). Многие службы Azure позволяют переключать слоты или постепенно менять трафик, даже в сценарии на месте. Azure поддерживает canary-развертывания через слоты развертывания Служба приложений Azure, разделение трафика Контейнеры приложений Azure и Служба Azure Kubernetes с использованием Azure Pipelines. Если у вас несколько виртуальных машин за подсистемой балансировки нагрузки, обновите один экземпляр за раз (последовательное обновление), чтобы другие несут трафик, а затем вращаются.
Постепенно увеличивайте трафик до полного объема, следя за процессом. После трансляции новой версии внимательно отслеживайте ее. Проверьте журналы приложений, метрики производительности и частоту ошибок. Начните с небольшой части пользователей (или начните с рабочей нагрузки в режиме проверки, если это возможно). Если через несколько минут все выглядит хорошо, увеличьте трафик до 25%. Проверьте метрики снова (нет всплеска 500 ошибок, время отклика в норме). Увеличьте сначала до 50%, а затем до 100% в течение запланированного срока. Это может занять более часа, если вы хотите проявить осторожность. Если любая серьезная проблема наблюдается на любом шаге, инициируйте откат, прежде чем он влияет на всех пользователей.
Поддержание согласованности данных во время развертывания. Развертывания на месте сохраняют существующие конечные точки данных при потенциальном изменении схем данных. Примените изменения схемы базы данных с обратной совместимостью для поддержки старых и новых версий приложений во время тестовой версии. Используйте скрипты миграции баз данных, которые добавляют новые столбцы или таблицы без удаления существующих структур, пока развертывание не завершится успешно.
Развертывание модернизации в параллельной среде
Создайте параллельную рабочую среду. Используя шаблоны IaC, создайте новую рабочую среду в Azure, которая отражает тестируемые действия. Эта среда включает все вычислительные ресурсы, сети и хранилище. Он должен быть в рабочем состоянии, но в настоящее время без пользовательского трафика. Убедитесь, что такие элементы, как группы безопасности сети, брандмауэры, удостоверение (управляемые удостоверения или учетные записи для обслуживания) и мониторинг настроены в соответствии с требованиями (в рабочей подписке повторите настройки тестовой среды).
Установите репликацию базы данных. Настройте собственную функцию репликации платформы базы данных, чтобы установить непрерывную репликацию данных между источником и Azure целевой рабочей нагрузкой. Убедитесь, что начальная синхронизация данных успешно завершена и что репликация работоспособна. Вы можете выполнить начальную массовую копию базы данных из резервного копирования или моментального снимка, а затем включить репликацию для новых транзакций. Отслеживайте задержку репликации с помощью средств мониторинга платформы базы данных. Высокая задержка увеличивает риск и длительность переключения. Не переходите к следующему шагу, пока задержка репликации не равна нулю.
Копирование неструктурированных данных и файлов. Скопируйте неструктурированные данные и файлы в Azure до окончательного перехода. Используйте Tools для переноса объектов и файлов с функциями для передачи файлов в соответствующие службы хранилища Azure. Эта подготовка уменьшает объем данных, которые необходимо скопировать во время окончательного переключения.
Завершите окончательную синхронизацию данных. В момент переключения вы хотите добиться нулевой или минимальной потери данных. Для баз данных убедитесь, что нет оставшихся ожидающих транзакций в исходных рабочих процессах, а репликация баз данных завершена. В некоторых случаях может потребоваться кратко приостановить запись в исходной базе данных, чтобы очистить окончательные изменения (особенно для таких вещей, как согласованность транзакций). Вы можете использовать такие методы, как доставка журналов транзакций или короткое время простоя, чтобы выполнить последнее добавочное восстановление резервного копирования. Скопируйте все измененные неструктурированные данные с помощью AzCopy или аналогичного средства.
Постепенно сокращать трафик пользователей в новую среду. Обновите записи DNS и конфигурации подсистемы балансировки нагрузки, чтобы направлять трафик пользователей в среду Azure. Мониторинг состояния и эффективности рабочей нагрузки. Начните с 1% динамического трафика, направленного на модернизацию рабочей нагрузки с использованием взвешенной маршрутизации с помощью подсистемы балансировки нагрузки Azure. Отслеживайте метрики в режиме реального времени, включая время отклика, частоту ошибок и работоспособности подключения к базе данных. Увеличивайте трафик быстрыми скачками (5%, 15%, 50%) за минуты, а не часы, с автоматическими триггерами отката, если пороговые значения превышаются.
Выполните последнее переключение на 100%. После того как вы уверены, перенаправите всех пользователей в новую среду. Переключение может быть изменением DNS, что может занять от нескольких секунд до нескольких минут, если значение времени жизни (TTL) было низким, или изменением конфигурации балансировщика нагрузки. На этом этапе пользователи живут на модернизированной рабочей нагрузке.
Немедленно проверьте и отслеживайте после переключения. Выполните проверки после переключения. Выполните комплексное функциональное тестирование всех критически важных бизнес-процессов с помощью автоматизированных наборов тестов. Проверьте точность данных с помощью проверки контрольной суммы и сравнения хэш-функций между исходными и целевыми рабочими нагрузками. Запросите у владельцев рабочих нагрузок подтверждение того, что все основные функции работают правильно. Отслеживайте производительность рабочей нагрузки, частоту ошибок и шаблоны доступа пользователей за первые 24–48 часов после переключения, чтобы определить проблемы с снижением производительности или функциональными возможностями.
Продолжайте работу старой среды (горячий режим) в течение некоторого времени. Пока ничего не ломайте. Сохраняйте старую систему как горячий резерв в течение не менее 24–72 часов, если возможно, синхронизация данных должна выполняться постоянно (или будьте готовы к быстрой синхронизации). Если в производственной среде возникает непредвиденная серьезная проблема, вы все равно можете принять решение об откате, направив трафик обратно. Вы можете потерять лишь минимальные данные, поскольку можете восстановить их из журналов или другими способами.
Проверка успешности модернизации
Теперь, когда новая рабочая нагрузка введена в эксплуатацию, необходимо проверить в рабочей среде, что все работает как задумано и соответствует критериям приемки.
Подтвердите успешный доступ пользователей и производительность рабочей нагрузки. Проверка доступа пользователей гарантирует, что модернизация является прозрачной и что производительность соответствует ожиданиям. Это подтверждение проверяет, что пользователи могут получить доступ к рабочей нагрузке без нарушений. Отслеживайте шаблоны доступа пользователей, метрики производительности рабочей нагрузки и частоту ошибок в течение начального периода после миграции.
Объявите успешное выполнение миграции только после тщательной проверки. Полная проверка гарантирует, что все заинтересованные лица подтвердили, что рабочая нагрузка стабильна и функциональна. Это подтверждение предотвращает преждевременное объявление успеха, которое может привести к проблемам позже. Получите подтверждение от владельцев рабочих нагрузок, тестировщиков и заинтересованных лиц бизнеса, что рабочая нагрузка соответствует всем требованиям и работает правильно.
Поддержка рабочей нагрузки во время стабилизации
Даже после успешного запуска планируйте период стабилизации, где вы внимательно отслеживаете рабочую нагрузку. Недавно модернизированные рабочие нагрузки могут иметь неизвестные проблемы, которые проявляются только в реальных шаблонах использования по истечении некоторого времени.
Создание расширенного охвата поддержки в течение периода стабилизации. В течение первых нескольких дней или недель (в зависимости от сложности) после запуска проекта используйте протокол повышенной поддержки. Назначьте опытным ИТ-сотрудникам или партнерам по миграции, чтобы внимательно отслеживать рабочую нагрузку и предоставлять более короткие соглашения об уровне обслуживания, чем обычные операции.
Обновите операционную документацию и средства. Убедитесь, что все модули Runbook, документация по поддержке и конфигурации мониторинга обновляются, чтобы отразить новую реальность. Обучить группу операций в любых новых процедурах, таких как новые процессы резервного копирования, новые процедуры перезапуска микрослужб. Передайте обновленную рабочую нагрузку в операционные и поддерживающие команды с полной передачей знаний. Убедитесь, что инвентаризация активов и CMDB записывает новые серверы, IP-адреса, службы и удаляет или помечает устаревшие.