Поделиться через


Подготовка к модернизации облака

Модернизация облака — это практика улучшения существующих облачных рабочих нагрузок для улучшения бизнес-потребностей. Он выравнивает рабочие нагрузки с рекомендациями по облачным технологиям без добавления новых функций. Эта платформа предоставляет комплексное руководство для организаций по планированию и выполнению модернизации во всех группах рабочей нагрузки.

Схема, демонстрирующая четырехэтапный процесс модернизации рабочих нагрузок: 1 Подготовка к модернизации, 2 Плана модернизации, 3 Выполнение модернизации и 4 Оптимизации рабочих нагрузок.

Определение модернизации для вашей организации

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

  1. Создайте общее определение модернизации. Модернизация облака улучшает работу существующих рабочих нагрузок без создания новых функций. Типичные действия модернизации включают реплатформирование (перемещение компонентов в новую среду размещения), рефакторинг (оптимизация или код реструктуризации) и перепроектирование (изменение структуры системы) в облаке. Модернизация исключает создание совершенно новых функций или полные перезаписи для новых возможностей.

  2. Передавать определение модернизации. Поделитесь этим определением со всеми соответствующими командами и заинтересованными лицами. Убедитесь, что руководители проектов, инженеры, владельцы продуктов и руководители понимают и согласны. Единое понимание предотвращает несоответствие.

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

Оценка готовности к модернизации и навыков

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

    Область навыка Вопросы о оценке
    Знания об облачных службах Знакомы ли инженеры с соответствующими службами Azure, которые могут использоваться во время модернизации?
    DevOps и CI/CD Есть ли у вас зрелые конвейеры непрерывной интеграции и непрерывной доставки? Можно ли автоматизировать тестирование и развертывание с помощью инфраструктуры в виде кода?
    Современные шаблоны архитектуры Понимает ли команда концепции микросервисов, контейнеризации и другие современные облачные концепции, которые могут быть частью рефакторинга или перепроектирования?
    Мониторинг и автоматизация Достаточно ли средств мониторинга, ведения журнала и автоматизации для поддержки более сложных облачных операций после модернизации?
  2. Определите все пробелы в навыках и создайте план для их заполнения. Вы можете обучить существующих сотрудников (сертификации Azure, семинары по облачной архитектуре) или привлечь новых сотрудников или подрядчиков с определенным опытом. Навыки часто имеют значение больше, чем конкретные технологии. Хорошо обученная команда выполняет модернизацию более эффективно, чем команда, обучающаяся на лету.

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

Определение приоритетов модернизации рабочих нагрузок

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

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

    Категория "Ценность бизнеса" Examples
    Доход или критически важный для миссии Системы, обрабатывающие транзакции по продажам или поддерживающие основные бизнес-функции (простой напрямую означает потерю денег)
    Взаимодействие с клиентами Системы, с которыми клиенты или клиенты напрямую взаимодействуют (производительность и надежность влияют на удовлетворенность)
    Соответствие или нормативные требования Системы, отвечающие строгим нормативным требованиям или требованиям к безопасности (сбой в обновлении может представлять юридические риски)
    Широкая внутренняя зависимость Платформы, широко используемые сотрудниками или другими системами (если это медленно или нестабильно, она снижает производительность в организации)
  2. Оценка технического риска. Независимо оцените техническое состояние каждой системы. По сути, выяснить, сколько он нуждается в модернизации. Ранг технического риска или необходимости в виде высокого, среднего или низкого уровня для каждой рабочей нагрузки. Признаки высокого технического риска или задолженности включают:

    Категория технических рисков Examples
    Технический долг Устаревший код с обходными решениями, устаревшими фреймворками, трудно изменяемой архитектурой
    Устаревшая технология Операционные системы или базы данных, близкие к концу поддержки, устаревшие языки программирования
    Высокая трудозатратность на обслуживание Частое вмешательство вручную, повышение затрат на поддержку, сложные процессы устранения неполадок
    Проблемы с производительностью и надежностью Хроническое время простоя, медленное время отклика, неспособность обрабатывать пики нагрузки
    Ограниченная масштабируемость Архитектура, требующая существенной переработки для роста, ручных процессов масштабирования
  3. Определите срочные триггеры модернизации. Некоторые события могут внезапно изменить приоритет рабочей нагрузки, даже если изначально он не был в верхней части списка. Следите за этими триггерами, которые делают модернизацию срочной:

    Категория триггеров Examples
    уязвимые места системы безопасности. Недавно обнаруженные дыры безопасности в устаревших компонентах, устаревших протоколах шифрования или нарушениях соответствия требованиям
    Сроки завершения поддержки Платформа или программное обеспечение, теряющие поддержку поставщика в течение 12 месяцев, устаревшие исправления безопасности
    Требования к росту бизнеса Быстрый рост клиентов, превышающий емкость системы, новые требования к входу на рынок или потребности интеграции
    Проблемы с надежностью системы Повторяющиеся сбои, хронические проблемы с производительностью или эскалация затрат на обслуживание
  4. Приоритизируйте рабочие нагрузки. Объедините бизнес-ценности и технические оценки рисков в простую матрицу приоритетов.

    Ценность для бизнеса Технический риск Приоритет модернизации Action
    High High Главный приоритет Начните модернизацию. Высокая рентабельность инвестиций
    High Low Monitor Задержка модернизации, если конкретные бизнес-преимущества не существуют
    Low High Case-by-case Не модернизируйте немедленно, если нет четкого преимущества
    Low Low Бездействовать Стараться модернизировать здесь было бы нецелесообразным использованием ресурсов.

Узнайте, как модернизировать

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

  1. Используйте Azure Well-Architected Framework для выявления возможностей улучшения. ПлатформаWell-Architected (WAF) — это набор рекомендаций в пяти основных принципах: надежность, безопасность, оптимизация затрат, эффективность работы и эффективность производительности. Проведение Well-Architected обзора ваших рабочих нагрузок может показать, где они не следуют передовому опыту. Эти пробелы фактически создают список задач для модернизации. Чем больше или многочисленнее пробелы, тем острее необходимость модернизировать эту рабочую нагрузку. Таким образом WAF предоставляет дорожную карту на основе данных о том, что нужно исправить.

  2. Предоставьте командам по управлению рабочими нагрузками возможность принимать решения о модернизации. Команды, которые управляют каждым приложением на ежедневной основе, часто имеют самые глубокие знания о его проблемных аспектах и о том, какие изменения могут помочь. Это разумно, чтобы включить эти команды в решение о модернизации своих систем. Предоставьте им бизнес-контекст ("нам нужна эта система для обработки трафика 2x" или "нам нужно сократить расходы на обслуживание на 30%") и позволить им предлагать решения. Возможно, они знают, что определенная служба может быть заменена или какие части кода являются худшими. Предоставьте этим командам полномочия принятия решений для технических вариантов, в пределах бюджета, временной шкалы и общих архитектурных стандартов. Установите регулярные проверки, чтобы обеспечить соответствие их планов более широким целям организации.

Следующий шаг