Модель зрелости операционного превосходства

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

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

Купить: готовые решения GenAI

У готовых средств GenAI есть встроенные возможности ИИ. Они могут быть широко классифицированы по намерению. Один из них — это универсальные интерактивные средства помощи, такие как GitHub Copilot, которые зависят от контекста и могут использоваться для различных задач. Эти средства не требуют установки и предоставления поддержки с учетом контекста, внедренной непосредственно в существующие рабочие процессы разработчика. Другая категория — это специально созданные средства и агенты, такие как агенты развертывания, агенты SRE, предназначенные для конкретных функций. Их можно интегрировать для повышения производительности разработчиков с помощью помощников по интегрированной среде разработки и интерфейса командной строки.

Существуют также службы Azure с интегрированными функциями ИИ, которые могут сопровождаться дополнительными затратами.

Сборка: GenAI с пользовательской реализацией

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

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

Функциональные шаблоны ИИ

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

✓ Агенты суммирования

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

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

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

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

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

Примеры

• Культура DevOps OE:01. Извлеките структурированные элементы, такие как действия, ответственные, крайние сроки и оценки рисков из неструктурированных документов.
• Ответ на инцидент OE:08. Сводите инциденты, посмертные отчеты, выявленные проблемы безопасности и отчеты аудита, чтобы быстро получить представление об области, влиянии и результатах.

✓ Агенты рекомендаций

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

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

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

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

Рассматривайте подсистемы рекомендаций как системы поддержки принятия решений, а не черные ящики. Объяснение является центральным для создания доверия и надежности эксплуатации. Системы должны предоставлять четкие обоснование рекомендаций, выделение ключевых сигналов и вклад источников данных. Рассмотрите возможность включения индикаторов достоверности (например, 0–100%), чтобы помочь нижестоящим системам или пользователям оценить надежность.

Примеры

• OE:06 Проектирование цепочки поставок рабочей нагрузки. Найдите клиентские предельные случаи и сценарии, которые трудно обнаружить и которые часто остаются незамеченными, чтобы включить их в ваш набор тестов.
• Управление инцидентами OE:08. Проверьте правильность планов перехода поставщиков, используя ИИ для имитации группы поддержки поставщиков с помощью только предоставленной документации, планов действий, моделей работоспособности и путей эскалации. Имитация выделяет пробелы и скрытые зависимости перед передачей.
• Проектирование автоматизации OE:10. Оцените код автоматизации, данные телеметрии и инциденты, чтобы рекомендовать, какие службы автоматизации следует улучшить, снять с учета или развернуть.

✓ Агенты создания артефактов

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

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

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

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

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

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

Примеры

• OE:02 Стандартизировать операции. Генерируйте артефакты кода и документов, соответствующие стандартам организации, и обновляйте документацию по стандартам по мере развития активов.
• OE:07 Проектирование системы мониторинга. Создайте конфигурации интегрированных панелей мониторинга, которые выравнивают метрики проектирования с бизнес-результатами, автоматически выбирая нужные метрики в разных источниках.
• Проектирование автоматизации OE:10. Автономно отслеживайте рабочие среды на отклонения конфигурации, определяйте предполагаемое состояние и обновляйте настройки начальной загрузки для поддержания согласованности систем со временем.

✓ Агенты проверки политики

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

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

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

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

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

Примеры

• OE:03 Формализация методик разработки. Проверьте описания задач и критерии принятия в соответствии с шаблонами организации, чтобы обеспечить согласованный уровень качества.
• OE:04 Стандартизировать инструменты и процессы. Просмотрите кодовую базу, чтобы применить стандарты качества и организации и записать пробелы как техническую задолженность.
• OE:05 Используйте инфраструктуру в качестве кода. Применение стандартов безопасности путем просмотра кода, шаблонов IaC и проектов для обнаружения небезопасных шаблонов, нарушений политики и слабых конфигураций.

✓ Агенты оптимизации действий

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

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

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

Примеры

• Управление инцидентами OE:08. Как только оповещение срабатывает, автоматически собирать контекст, сопоставлять данные и выполнять первоначальную оценку. Инженеры начинают с четкой картины инцидента вместо ручной сбора данных.
• Проектирование автоматизации OE:10. Непрерывно оптимизируйте параметры рабочей среды с низким риском, такие как размеры кэша и значения времени ожидания, в пределах определенных человеком границ, используя значения, полученные из анализа данных мониторинга.
• Методы безопасного развертывания OE:11. Автоматизируйте прогрессивную стратегию развертывания, при самостоятельном определении оптимального времени выпуска, а также правильного целевого сегмента и процентов для канареечного развертывания.

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

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

Ключевые стратегии

✓ Поощрять совместную работу и способствовать безвинной культуре

Выравнивайте усилия команды с бизнес-потребностями при содействии культуры совместной работы.

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

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

✓ Внедрение стандартных методик совместной работы и инструментов

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

Популярные варианты включают в себя Agile, Scrum и канбан-доски. Большинство опытных разработчиков, инженеров DevOps и владельцев продуктов знакомы с этими инструментами, что сводит к минимуму кривую обучения для новых сотрудников.

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

✓ Настройка процессов управления версиями

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

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

✓ Использование инфраструктуры в качестве кода (IaC) в качестве основного подхода к развертыванию

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

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

Начните с хорошей основы с помощью средств, которые Azure изначально поддерживает, например Bicep и Terraform. Оцените инструменты, чтобы обеспечить упрощение будущего пути. Убедитесь, что поставщик технологий имеет хорошую документацию и программу поддержки надежных служб.

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

Чтобы устранить этот риск, изучите современные технологии и обновите локальные процессы.

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

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

✓ Приоритет безопасности с начала

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

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

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

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

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

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

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

Ключевые стратегии

✓ Определение ролей команды и обязанностей по принятию решений

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

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

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

Обеспечьте хорошо структурированный процесс принятия решений с помощью следующих принципов:

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

  Документируйте, кто является лицами, принимающими решения, и включите эти сведения в материалы по подключению для новых сотрудников.

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

✓ Стремитесь к улучшениям, даже если они небольшие

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

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

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

✓ Стандартизация базовых процессов

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

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

Для следующих вариантов использования рекомендуется стандартизация:

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

✓ Приобретение инструментов вместо создания пользовательских инструментов

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

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

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

✓ Внедрение автоматизации в рабочей нагрузке

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

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

Следующие области могут воспользоваться автоматизацией:

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

• Задачи жизненного цикла разработки программного обеспечения, такие как развертывания и тестирование

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

• Механизмы безопасности и управления, такие как проверки и применение политик

• Действия резервного копирования и восстановления

• Оптимизация затрат, например размещение ресурсов и завершение работы

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

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

Расширьте свой опыт использования инфраструктуры как кода для настройки инфраструктуры и управления приложениями

На уровне 1 основное внимание уделяется внедрению средств инфраструктуры как кода (IaC) для развертывания инфраструктуры и конвейеров для кода приложения. На уровне 2 эта практика расширяется, чтобы включить конфигурацию и управление этой развернутой инфраструктурой и приложениями.

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

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

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

✓ Определение стратегии развертывания рабочей нагрузки

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

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

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

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

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

✓ Разработка стека мониторинга рабочей нагрузки

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

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

Риск: Избегайте сбора чрезмерных данных, так как это может создавать шум и увеличивать затраты. Начните с базовых метрик, таких как ЦП, использование памяти и использование хранилища. С течением времени добавьте полезные метрики работоспособности приложений.

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

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

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

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

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

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

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

Ключевые стратегии

✓ Использование отдельных сред для продвижения выпусков

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

Создавайте различные среды для различных этапов, таких как разработка и тестирование качества, проверка принятия пользователей (UAT) и рабочая среда. Этот подход обеспечивает тщательную проверку перед переходом на следующий этап. Идея заключается в управлении рисками в более низких средах, так как ошибки должны быть пойманы рано, чтобы свести к минимуму радиус взрыва.

✓ Выполнение достаточного тестирования

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

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

• Проводите различные типы тестов. Выполнение различных типов тестов в каждой среде. Начните тестирование изменений с высоким риском в средах с низким риском. Постепенно перемещайте изменения высокого риска в среды с более высоким риском по мере роста достоверности.

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

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

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

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

Настройте среды в соответствии с тестовым случаем. Модульное тестирование может требовать только сопоставления библиотек и версий ОС в меньшей установке. Для тестирования устойчивости может потребоваться тестовая предварительная среда с идентичными SKU услуг. Для тестирования производительности может потребоваться развертывание в рабочей среде.

✓ Автоматизация тестирования и других проверок качества по возможности

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

Различные средства тестирования доступны для автоматизации и оптимизации различных типов тестирования, таких как Azure Load Testing и Azure Pipelines для оркестрации автоматизированного тестирования.

✓ Настройка процессов утверждения

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

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

• Укажите отдельный процесс для исправлений: Для критических ситуаций, таких как развертывание исправлений безопасности, может потребоваться импровизированный процесс развертывания. Создайте экстренный процесс для ускорения выполнения этих высокоприоритетных исправлений. Этот процесс может включать утверждение только ключевых заинтересованных лиц и технических членов. Кроме того, можно разработать pipeline, который обходит некоторые утверждения для более быстрого развертывания.

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

✓ Реализация автоматизированных развертываний

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

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

✓ Разработка модели здоровья

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

• Укажите контекст данных, наблюдаемый системой. Настройка пороговых значений является важной частью моделирования работоспособности. Чтобы пороговые значения были значимыми для вашей рабочей нагрузки, предоставьте числовые значения с учетом контекста. Например, в то время как высокая загрузка ЦП от 70% до 90% обычно может указывать на неработоспособное состояние в одной рабочей нагрузке, она может быть работоспособной для другой рабочей нагрузки, которая эффективно использует доступные ресурсы.

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

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

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

✓ Настройка процесса управления инцидентами

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

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

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

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

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

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

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

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

Ключевые стратегии

✓ Использование методов безопасного развертывания

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

Интегрируйте следующие стратегии в процесс управления изменениями:

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

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

  На этом уровне можно внедрить расширенные операционные модели, такие как региональное резервирование. Цель состоит в том, чтобы полностью автоматизировать эти процессы, с акцентом на самовосстановление в большинстве сценариев. Эти процессы также должны быть тщательно проверены.

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

• Постепенный выпуск обновлений. На уровне 3 процессы развертывания стандартизированы с помощью автоматизированных конвейеров во всех средах. На уровне 4 зрелости рабочая нагрузка находится в продакшне. Фокус переключится на уточнение добавочных обновлений, включая управление циклами выпуска.

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

  Замечание

  Шаблоны безопасного развертывания, такие как канареечные и синие-зеленые развертывания, обеспечивают гибкость и надежность при их одновременном использовании. Например, в сине-зеленых развертываниях создается новая среда, трафик перемещается, а старая среда удаляется. Другие методы развертывания включают флажки функций и скрытые запуски. Эти подходы позволяют тестировать в рабочей среде перед развертыванием изменений для всех пользователей. Эта возможность доступна в определенных службах Azure, таких как Служба приложений Azure, где можно развертывать обновления путем постепенного переключения между слотами развертывания.

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

✓ Оптимизация операций сборки

На уровне 3 необходимо иметь отдельные циклы развертывания для разных слоев архитектуры на основе их скорости изменения. Как минимум, сохраняйте инфраструктуру и конвейеры кода.

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

✓ Проверка процессов реагирования на инциденты

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

• Тестирование ответов на инциденты. Интеграция ответов из технологий, людей и процессов. Чтобы внедрить реалистичность в усилия по проверке, рекомендуется запустить дни игры. Дни игры — это запланированные события, в которых вводятся ошибки для проверки способности команды обнаруживать и устранять проблемы. Такой подход гарантирует, что команда имеет правильные инструменты, ресурсы и процедуры. Инженерия хаоса является еще одним ценным методом, который вводит контролируемые нарушения для наблюдения за результатами. Кроме того, для проверки ответа можно использовать ручные методы, такие как отключение серверной части в глобальном балансировщике нагрузки или переключение на резервную базу данных.

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

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

✓ Оптимизация операций с помощью данных мониторинга из производственной среды

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

• Основное внимание на уровне 3 уделяется разработке модели работоспособности для рабочей нагрузки. На уровне 4 настройте систему оповещений и задайте реалистичные цели и индикаторы уровня обслуживания.

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

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

Оптимизируйте стек мониторинга на основе данных и паттернов наблюдаемости в рабочей среде. Рассмотрим следующие методики.

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

• Расширение важных оповещений при подавлении неуместных.

✓ Автоматизация обслуживания

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

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

Рассмотрим примеры автоматизации второго этапа.

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

✓ Повышение эффективности путем выравнивания средств и процессов с организационными стандартами

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

Для этих ресурсов рассмотрим следующие моменты:

• Используйте общие инструменты, уже доступные в вашей организации.

• Рассмотрим программное обеспечение, отличное от Майкрософт, для определенных задач, таких как преобразование данных.

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

Изучите следующие области рабочей нагрузки:

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

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

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

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

  Замечание

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

✓ Управление техническим долгом на регулярном уровне

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

Рассмотрим следующие тактические рекомендации по обработке технического долга:

• Отслеживание технического долга наряду с разработкой новых функций.

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

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

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

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

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

На последнем этапе зрелость означает, что рабочая нагрузка выполняется в масштабе, что обеспечивает надежность и up-to-date. Это также требует умений определять области, где текущий дизайн достиг своих пределов, и готовиться к изменениям бизнес-требований. Предположения о ограничениях могут стать устаревшими по мере развития экосистемы. Оставаясь статическим, может привести к регрессии, так как среды, практики и инструменты продолжают развиваться. Без инвестиций в подходы уровня 5 ваши рабочие нагрузки отстают.

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

Ключевые стратегии

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

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

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

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

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

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

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

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

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

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

    Однако этот подход может привести к увеличению масштаба конкретных служб, что приводит к добавленным затратам.

    Дополнительные сведения см. в разделе "Архитектура единиц масштабирования".

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

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

✓ Использование автоматизации для дальнейшего снижения трения

Переход с уровня 4 на уровень 5 не только о повышении автоматизации. Это также касается использования автоматизации для снижения трения и принятия решений о выполнении этих задач.

Рассмотрим следующие примеры:

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

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

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

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

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

✓ Создание сред разработчика для каждой функции или изменения

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

В отличие от уровней 1–4, которые ориентированы на внутреннюю готовность к работе и управление изменением рабочей нагрузки, уровень 5 — это возможность для группы рабочей нагрузки поделиться своими проектами, успехами, сбоями с другими рабочими нагрузками в организации. Командам, работающим с нагрузкой, не нужно испытывать сбои самостоятельно, чтобы узнать, как избежать этого, если они могут заранее узнать из опыта других, кто прошел этим путем до них.

✓ Совместное использование знаний и участие в зрелости организации

Уровни 1–4 сосредоточены на внутренней готовности и управлении изменением рабочей нагрузки. Уровень 5 отличается, так как он создает возможность для команд по рабочим нагрузкам делиться своими проектами, успехами и неудачами с другими командами по всей организации. Команде не придется столкнуться с неудачей, если она может учиться у других, которые столкнулись с аналогичными проблемами.

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

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

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

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

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

Следуйте подходам и возможностям, описанным в начните свое путешествие по инженерии платформ.