Компромиссы операционной эффективности

  • Статья

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

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

Компромиссы операционной эффективности с надежностью

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

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

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

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

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

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

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

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

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

Компромиссы операционной эффективности с безопасностью

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

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

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

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

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

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

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

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

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

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

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

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

Компромиссы операционной эффективности с оптимизацией затрат

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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