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

Компромиссы в области операционного совершенства для Power Platform рабочих нагрузок

  • Статья

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

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

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

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

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

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

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

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

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

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

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

Компромиссы операционного совершенства и безопасности

Компромисс: Увеличенная площадь поверхности. Компонент «Безопасность» рекомендуется уменьшить площадь поверхности рабочей нагрузки с точки зрения компонентов и воздействия операций. Такое сокращение сводит к минимуму уязвимости и сокращает объем контроля и тестирования безопасности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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