Компромиссы в операционном превосходстве

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

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

Компромиссы операционного превосходства с надежностью

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

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

  • Высокоуровневая, модульная или параметризованная инфраструктура в виде кода может увеличить вероятность случайной неправильной настройки из-за сложности взаимодействия между компонентами кода.

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

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

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

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

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

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

Компромиссы операционного превосходства с безопасностью

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

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

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

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

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

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

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

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

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

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

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

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

Компромиссы по операционному превосходству с оптимизацией затрат

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

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

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

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

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

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

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

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

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

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

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

Компромисс: повышенные требования к инструментам и их разнообразие. В руководстве по оптимизации затрат рекомендуется сокращение разрозненности инструментов, консолидация поставщиков и оптимизированный подход ко всем покупкам инструментов.

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

  • Требования и управление невыполненной работой
  • Средства разработки архитектуры
  • Средства разработки пользовательского интерфейса и пользовательского опыта
  • Размещение кода и ресурсов
  • Среды разработки кода и низкокодовой среды
  • Средства автоматизации
  • Рабочие станции разработки и обеспечения качества
  • Конвейеры разработки и развертывания
  • Запуск и отслеживание тестов
  • Средства наблюдения

Компромиссы операционного превосходства с эффективностью производительности

Компромисс. Увеличение использования ресурсов. Компонент "Эффективность производительности" рекомендует максимальное количество доступных вычислительных ресурсов и сети в соответствии с требованиями рабочей нагрузки.

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

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

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

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

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

Изучите компромиссы для других столпов:

  • Last updated on