Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Надлежащее планирование и управление критически важны для модернизации. На этом этапе вы решите, какой подход модернизации применять и как это сделать. Продуманное планирование снижает вероятность превышения бюджета, увеличения объёма работ или сбоев услуг во время выполнения.
Выбор стратегии модернизации
Модернизация рабочей нагрузки означает, что она лучше соответствует текущим бизнес-целям, техническим стандартам и облачным возможностям. Три основные стратегии (переплатформа, рефакторинг и переархитектуризация) существуют на континууме сложности и ценности. Большинство усилий по модернизации используют сочетание этих подходов.
Ключевым фактором является сопоставление стратегии с конкретными потребностями каждого компонента, учитывая цели, временную шкалу и доступные ресурсы. Избегайте соблазна чрезмерно модернизировать. Хотя новые технологии вызывают интерес, каждое решение должно основываться на бизнес-ценности.
| Стратегия модернизации | Definition | Когда следует использовать | Pros | Cons |
|---|---|---|---|---|
| Перенос на новую платформу | Перемещение приложений на облачные платформы с минимальными изменениями кода (IaaS в PaaS). | Требуются улучшения с минимальными усилиями и нарушениями. Текущий код работает, но нагрузка на операции высока. | Быстрая реализация. Сокращает усилия по обслуживанию. Повышает надежность благодаря лучшей инфраструктуре. | Ограниченные приросты возможностей. Основное приложение остается неизменным. |
| Refactor | Измените существующий код, чтобы улучшить структуру, производительность и облачную оптимизацию при сохранении функциональных возможностей. | Технический долг вызывает проблемы или код не оптимизирован для облака. | Повышает удобство обслуживания, производительность и безопасность. Позволяет упростить будущие улучшения. | Требует значительных усилий разработчика и тестирования. Никаких немедленных новых функций для пользователей. |
| Rearchitect | Перепроектирование архитектуры приложений с помощью облачных шаблонов (микрослужб, бессерверных, управляемых событиями). | Текущая архитектура ограничивает рост или оптимизацию облака. | Устраняет основные проблемы масштабируемости. Включает расширенные облачные службы. Задает основу для долгосрочных инноваций. | Наиболее сложные и трудоемкие. Высокая стоимость и риск. Требуется обширное тестирование и параллельные операции. |
Планирование модернизации на этапах
Попытка модернизировать весь комплекс рабочих нагрузок (или несколько) за один раз рискованно. Разделите усилие на логические этапы. Этапирование позволяет предоставлять добавленную ценность, уменьшать риск путем решения посильных задач и корректировать курс между этапами на основе того, что вы узнаете.
Разделить модернизацию на логические этапы. Определите, как разбить работу. Нет единого "правильного пути". Выберите разбивку, которая имеет смысл для вашей архитектуры и структуры команды. Цель заключается в том, что каждый этап достаточно мал для выполнения и тестирования без подавляющей сложности, но достаточно значимый для предоставления ценности. Распространенные способы разбиения этапов:
Метод деления Description Example По компоненту или уровню Отдельные этапы на основе уровней рабочей нагрузки или границ рабочей нагрузки Этап 1. Миграция базы данных, этап 2. Рефакторинг приложений, этап 3. Модернизация пользовательского интерфейса По приоритету и сложности Организуйте задачи от изменений с низким риском к изменениям с высоким риском. Этап 1. Некритические службы, этап 2. Основная бизнес-логика, этап 3. Функции, доступные для клиентов По бизнес-функциям Этапы структуры вокруг границ приложения или функциональных границ Этап 1. Рабочая нагрузка управления пользователями, этап 2. Обработка платежей, этап 3. Службы отчетов Начните с низких рисков, высокозначных изменений. Для вашего этапа 1 выберите то, что является достижимым и обеспечивает измеримое преимущество, но не угрожает бизнесу, если возникают проблемы. Например, сначала модернизируйте серверную службу или внутренний инструмент, а не веб-сайт с поддержкой клиента. Цель выполнить первый этап быстро (месяц или два) в качестве демонстрации жизнеспособности. Ранний успех создает доверие команды и поддержку заинтересованных лиц для последующих этапов.
Последовательность оставшихся этапов по значению и зависимостям. После первого этапа спланируйте порядок последующих этапов на основе стоимости бизнеса и технических зависимостей. Создайте дорожную карту, в которой каждый этап имеет четко определенную область и гарантирует, что критически важные компоненты уже модернизированы или совместимы с поддерживающими их элементами.
- Решение хрупких областей. Если нагрузка нестабильна в текущем состоянии, может потребоваться предварительный "Этап 0", чтобы стабилизировать её на месте (внедрить срочные исправления в старой среде), чтобы обеспечить безопасное обновление на этапе 1.
- Сначала необходимо рассмотреть первоначальные требования: Если модернизация Нагрузки B зависит от того, модернизирована ли Нагрузка A (или хотя бы стабильна), сначала выполните модернизацию Нагрузки A.
- Рассмотрите бизнес-ценность и риск: Вы можете выбрать вариант, выполняя высокоценный, но рискованный фрагмент на одном этапе, а затем более низкий риск в следующем, чтобы сбалансировать нагрузку на команду и риск для бизнеса.
Определите критерии успешности для каждого этапа. Для каждого этапа определите, когда оно завершено и успешно. Наличие четких критериев выхода предотвращает разрастание объема работы в фазе проекта. Критерии успешности могут включать:
Тип критериев успешности Examples Технические цели • Служба X выполняется в службе приложений Azure и обрабатывает 20% больше нагрузки
• База данных Y переносится в SQL Azure с нулевой потерей данных и производительностью в пределах 10% предыдущих базовых показателей.Качественные ворота • Нет открытых ошибок Sev-1
• Все автоматизированные тесты проходят
• Проверка безопасности показывает ноль критически важных уязвимостейОграничения времени и бюджета • Завершено в течение трех месяцев и в пределах 5% бюджета
• Развертывание во время запланированных периодов обслуживанияАдаптируйте планы на основе результатов. После завершения этапа просмотрите результаты и уроки. Возможно, некоторые предположения оказались неверными, или некоторые задачи были проще или сложнее, чем ожидалось. Измените план на предстоящие этапы соответствующим образом, например добавление, объединение или повторение этапов. Поэтапный подход должен быть гибким. Важно не пытаться одновременно делать все.
Планирование модернизации системы управления
Модернизация часто вносит значительные изменения в критически важные рабочие нагрузки, поэтому для управления рисками требуется строгое управление. Управление модернизацией включает процессы управления изменениями, ограничения и контроль объема.
Создайте рабочий процесс утверждения формального изменения. Определите структурированный процесс утверждения для всех изменений, связанных с модернизацией. Интеграция с существующими советами по изменению (CAB) или создание специального совета по модернизации. Назначьте центр утверждения на основе категории изменений и задокументируйте полный рабочий процесс в плане проекта. Дополнительные сведения см. в разделе "Управление изменениями".
При необходимости можно заморозить изменения. Перед и во время масштабных событий развертывания заморозьте другие изменения в этих рабочих нагрузках. Замораживание изменений означает, что никакие другие изменения, не связанные с этими рабочими нагрузками, не выполняются в преддверии и во время развертывания. Она стабилизирует среду, так что вы не разворачиваете в нестабильной среде. Сообщите о окне замораживания всем соответствующим командам.
Избегайте разрастания целей проекта. Ползучесть целей является основным вызовом при модернизациях. Любое предлагаемое изменение согласованного объёма модернизации должно пройти этап оценки и утверждения. Большинство запросов должно быть отложено, если они не имеют решающего значения. Формируйте "нет, а не сейчас" для дополнительной работы с процессом. Держите список желательных идей, которые появляются и могут войти в будущий проект инноваций после завершения текущей модернизации. Заинтересованные лица должны знать, что их идея не потеряна.
Определение стратегии развертывания
Важное решение о выполнении заключается в том, как развернуть обновленные компоненты в рабочей среде. Существует две основные стратегии. В развертывании на месте выполняется обновление существующей установки (обновление существующей среды напрямую). В параллельном развертывании вы создаете новую систему параллельно (создавая новую среду, а затем переключая управление на неё). Выберите стратегию, которая соответствует уровню устойчивости к изменениям и рискам для каждого этапа или рабочей нагрузки. Часто каждый этап модернизации может использовать другую стратегию. Например, вы можете выбрать на месте этап 1 (если это незначительные изменения) и параллельно для этапа 2 (если он включает основной ремонт базы данных).
Используйте развертывание на месте для низких рисков, обратимых изменений. Развертывание на месте вносит изменения непосредственно в текущую рабочую среду, возможно, во время периода обслуживания. Эта стратегия сводит к минимуму нагрузку на инфраструктуру, но повышает риск простоя. Используйте развертывание на месте, только если изменения являются небольшими, изолированными и легко обратимыми. Примеры включают незначительные обновления кода или изменения схемы, которые можно быстро откатить с помощью системы управления версиями или резервных копий.
Используйте параллельное развертывание для сложных или высокориском изменений. В этой модели вы настроите новую среду для модернизированной рабочей нагрузки, пока старая рабочая нагрузка по-прежнему выполняется. Данные хранятся в синхронизации (с помощью процессов репликации или миграции), чтобы при готовности можно было перейти от старого к новой среде. Используйте эту модель для сложных или высоко рисковых изменений, где время простоя должно быть минимальным. Если вы выполняете основную миграцию базы данных или перепроектирование, включающее новую инфраструктуру, параллельное развертывание обычно лучше. Кроме того, если рабочая нагрузка является жизненно важной и не может иметь более нескольких минут простоя, параллельный процесс (с репликацией и быстрым переключением) необходим.
Strategy Description Когда следует использовать Pros Cons Развертывание на месте Развертывание изменений непосредственно в текущей рабочей среде Небольшие, обратимые изменения с приемлемыми периодами обслуживания Не повторяющаяся инфраструктура, быстрое развертывание Более высокий риск, требует простоя, более медленного отката Параллельное развертывание Запуск новой среды параллельно с существующей нагрузкой в период перехода Сложные изменения, критически важные рабочие нагрузки, требующие минимального простоя Безопасное развертывание, почти нулевое время простоя, немедленное резервное восстановление Повторяющиеся затраты на инфраструктуру, сложная синхронизация данных, усилия по выводу из эксплуатации
Планирование снижения рисков модернизации
Даже с лучшим планированием и тестированием, не все изменения идут идеально. Модернизация часто включает в себя сложные изменения, и всегда существует риск того, что развертывание может привести к проблеме, или что-то ведет себя неожиданно в рабочей среде. Хорошо подготовленная команда имеет подробный план возврата для каждого изменения или этапа.
Используйте прогрессивные методы развертывания. Если платформа разрешает, проведите канарейчные релизы или постепенное перенаправление трафика на модернизированные части приложения. Например, разверните новую версию вместе со старой и первоначально отправьте в нее только 5% пользователей во время мониторинга. Такой подход может выявлять проблемы, в то время как большинство пользователей остаются незатронутыми. Если метрики выглядят хорошо, увеличьте сначала до 50%, а затем до 100%. Если что-то начинается сбой, быстро перенаправляйте на 0% новый (откат).
Создайте процедуры отмены изменений для каждого значительного изменения. Для каждого крупного изменения или результата этапа напишите пошаговую процедуру отката изменений. Четко перечислите каждое действие, чтобы отменить изменение, кто отвечает за каждый шаг и сколько времени потребуется. После отката включите проверки, подтверждающие, что система вернулась в нормальное состояние.
Автоматизируйте откаты по возможности. Автоматические сценарии отката или инфраструктура как код могут обеспечить быстрое и надежное восстановление. Используйте средства инфраструктуры как кода (Terraform, шаблоны ARM и Bicep), чтобы повторно развернуть заранее определённые состояния. При необходимости, сине-зеленое или канареечное развертывание позволяют "вернуться" к предыдущей версии. Проверьте эти механизмы в промежуточном режиме. Цель заключается в сокращении ручных действий (во время инцидента) до действия по сценарию. Документируйте шаги отката вместе с этапами развертывания, чтобы было легко откатить изменения.
Оказывайте поддержку в течение и после развертывания. Планируйте развертывание в периоды низкого трафика (выходные или ночью), по возможности, но при этом убедитесь, что у специалистов есть возможность быть доступными. Избегайте планирования развертываний, когда ключевые члены команды недоступны. После развертывания у вас будет расширенный период поддержки (гиперкеир) с разработчиками и службой эксплуатации, находящимися в режиме ожидания, чтобы оперативно выявлять любые проблемы. Для крупных запусков некоторые организации применяют мониторинг в стиле командного центра в течение 24-48 часов после.
Получение одобрения заинтересованных сторон
До этого момента мы сосредоточились на техническом планировании. В равной степени важно получить одобрение от заинтересованных лиц, как от бизнес-руководства, так и от технического руководства. Модернизация часто требует значительных инвестиций, поэтому вам необходимо представить убедительный случай и держать заинтересованных лиц на протяжении всего.
Настройте ценностное предложение под каждую аудиторию. Различные заинтересованные лица заботятся о различных результатах. Настройка обмена сообщениями:
- Технические команды ориентируются на оперативную эффективность: снижение затрат на обслуживание, увеличение времени бесперебойной работы и сокращение количества эскалаций.
- Бизнес-лидеры сосредоточены на результатах: быстрое продвижение на рынок, улучшение клиентского опыта и снижение затрат.
Задокументируйте структурированный план со вехами. Заинтересованные лица более удобны, если они видят четкий план развития. Представить запланированные этапы, как было принято ранее, и то, что должно достичь каждый из них, с грубой временной шкалой. Подчеркнуть ранние победы, такие как "В течение 6 недель мы стремимся модернизировать компонент X и повысить его производительность на 20%".
Квантифицируйте значение модернизации. Подготовьте некоторые метрики "до и после" и запланируйте целевые улучшения. Ниже приведены примеры метрик и типичных диапазонов улучшений (на основе отраслевых тестов):
Category Примеры метрик Типичный диапазон значений Сокращение затрат Инфраструктура, обслуживание, лицензирование 20-40% годовая экономия Повышение производительности Частота развертывания, время устранения неполадок Улучшение 50-80% Устранение рисков "Избежано простоя, инциденты безопасности предотвращены" $100K-$1M+ снижение затрат Revenue Ускоренный вывод на рынок, удержание клиентов Ускорение выручки от 10 до 25% Устранение рисков проекта. Определите потенциальные проблемы и продемонстрировать готовность с помощью конкретных стратегий устранения рисков. Распространенные риски включают репликацию данных, снижение производительности и проблемы интеграции. Представлены такие решения, как автоматизированные процедуры отката, комплексные протоколы тестирования и доступность экспертных консультаций. Прозрачное обсуждение рисков создает уверенность заинтересованных лиц в руководстве проектом и тщательности планирования.
Поддерживать регулярный ритм общения. Сообщите о ходе выполнения по определенным критериям успешности, выделите завершенные результаты и сообщите о предстоящих вехах. Активно запрашивайте отзывы и устраняйте проблемы, чтобы сохранять поддержку в процессе модернизации.