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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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