Компромиссы в области операционного совершенства для Power Platform рабочих нагрузок
Операционная эффективность поддерживает качество рабочей нагрузки за счет внедрения четких командных стандартов, понимания ответственности и подотчетности, внимания к результатам работы клиентов и сплоченности команды. Реализация этих целей основана на DevOps, который рекомендует минимизировать вариативность процессов, уменьшить количество человеческих ошибок и, в конечном итоге, повысить отдачу от рабочей нагрузки. Эта ценность измеряется не только с учетом функциональных требований, предъявляемых к компонентам рабочей нагрузки. Это также измеряется ценностью, которую рабочая группа обеспечивает, стремясь к улучшению.
На этапе проектирования рабочей нагрузки и в течение ее жизненного цикла по мере принятия мер по непрерывному совершенствованию важно учитывать, как решения, основанные на принципах проектирования операционного совершенства и рекомендациях в контрольном списке обзора проектирования для операционного совершенства , могут повлиять на цели и оптимизацию других столпов. Определенные решения могут принести пользу некоторым компонентам, но при этом быть компромиссом для других. В этой статье описаны примеры компромиссов, с которыми может столкнуться группа рабочих нагрузок при проектировании архитектуры и операций рабочей нагрузки.
Компромиссы операционного совершенства с надежностью
Компромисс: повышенная сложность. Надежность отдает приоритет простоте, поскольку простая конструкция сводит к минимуму ошибки в настройке и снижает вероятность непредвиденных взаимодействий.
Стратегии безопасного развертывания часто требуют некоторой прямой и обратной совместимости между логикой приложения и данными в рабочей нагрузке. Эта дополнительная сложность увеличивает нагрузку на тестирование и может привести к усложнению или проблемам целостности данных рабочей нагрузки.
Многоуровневые, модульные или параметризованные структуры могут увеличить вероятность случайной неправильной конфигурации из-за сложности взаимодействия между компонентами рабочей нагрузки.
Шаблоны проектирования облака, которые улучшают работу, иногда требуют внедрения дополнительных компонентов, например, использования секретного хранилища или принятия зависимости Application Insights. Дополнительные компоненты увеличивают количество точек взаимодействия в системе, увеличивая вероятность возникновения неисправностей или неправильной конфигурации.
Компромисс: усиление потенциально дестабилизирующей деятельности. Компонент «Надежность» поощряет избегать действий или конструктивных решений, которые могут дестабилизировать систему и привести к сбоям, простоям или неполадкам.
Внедрение небольших, постепенных изменений — это метод снижения риска, но пользователи ожидают, что эти небольшие изменения будут поставляться в производство чаще. Развертывания могут дестабилизировать систему, поэтому по мере увеличения частоты развертывания увеличивается и этот риск.
Культура, которая измеряет себя такими метриками скорости, как развертывания в неделю, и использует автоматизацию, которая может способствовать более быстрому внесению изменений, также, вероятно, будет выполнять больше развертываний за более короткий период.
Увеличение плотности для упрощения операций за счет сокращения количества точек контроля и наблюдения также может привести к повышению риска доступности, поскольку неисправность или неправильная конфигурация усиливают эффект дестабилизирующего события.
Компромиссы операционного совершенства и безопасности
Компромисс: Увеличенная площадь поверхности. Компонент «Безопасность» рекомендуется уменьшить площадь поверхности рабочей нагрузки с точки зрения компонентов и воздействия операций. Такое сокращение сводит к минимуму уязвимости и сокращает объем контроля и тестирования безопасности.
Компоненты, окружающие рабочую нагрузку и поддерживающие ее операции, такие как автоматизация или настраиваемая плоскость управления, также должны подвергаться регулярному усилению безопасности и тестированию.
Плановые, внеплановые и экстренные операции увеличивают количество точек соприкосновения с рабочей нагрузкой. Подход с нулевым доверием требует, чтобы эти процессы считались уязвимостями и были включены в средства контроля безопасности и проверки рабочей нагрузки.
Платформа наблюдения системы собирает журналы и метрики рабочей нагрузки, которые могут быть ценным источником раскрытия информации. Таким образом, необходимо расширить безопасность рабочей нагрузки, чтобы защитить приемники данных от внутренних и внешних угроз.
Агенты сборки, внешняя конфигурация и хранилища переключателей функций — все это увеличивает площадь поверхности приложений, требующих безопасности.
Более высокая частота развертывания, вызванная небольшими, постепенными изменениями или усилиями по принципу «получить актуальность, оставаться в курсе событий», приводит к большему количеству испытаний безопасности в жизненном цикле разработки программного обеспечения (SDLC).
Компромисс: возросшее стремление к прозрачности. Безопасная рабочая нагрузка основана на конструкциях, которые защищают конфиденциальность данных, проходящих через компоненты системы.
Платформы наблюдения собирают данные всех типов, чтобы получить представление о состоянии и поведении рабочей нагрузки. Поскольку рабочие группы пытаются добиться более высокой точности данных наблюдения, возрастает риск того, что меры классификации данных, такие как маскирование данных, исходных систем не распространяются на журналы и приемники журналов платформы наблюдения.
Компромисс: снижение сегментации. Ключевым подходом к обеспечению безопасности для изоляции доступа и функций является разработка сильной стратегии сегментации. Эта конструкция реализуется посредством изоляции ресурсов и контроля удостоверений.
Совместное размещение разрозненных компонентов приложения в общих средах и ресурсах данных для упрощения управления приводит к обращению сегментации или усложняет достижение сегментации на основе ролей. Совместно расположенным компонентам также может потребоваться совместное использование удостоверения рабочей нагрузки, что может привести к чрезмерному назначению разрешений или отсутствию возможности отслеживания.
Сбор всех журналов со всей системы в едином приемнике журналов может упростить запросы и создание оповещений. Однако это также может затруднить или сделать невозможным обеспечение безопасности на уровне строк для обработки конфиденциальных данных с использованием необходимых средств контроля аудита.
Упрощение управления безопасностью на основе атрибутов или ролей за счет уменьшения детализации ролей и их назначений может привести к недопустимо широким разрешениям.
Компромиссы между операционной эффективностью и оптимизацией взаимодействия
Компромисс: конкурирующие приоритеты. Компонент «Оптимизация взаимодействия» рекомендует подход, ориентированный на пользователя.
Разработка пользовательского опыта, требующая значительных ресурсов, может быть лишена приоритета, что может привести к отсутствию удобства использования, интерактивности и визуального дизайна, необходимых пользователям рабочей нагрузки.
Разработка пользовательского интерфейса часто выполняется в более быстрых итерациях и циклах поставки, что может нагружать процессы SDLC команды.
Компромисс между операционным совершенством и эффективностью работы
Компромисс: более эффективное использование ресурсов. В соответствии с принципом «Эффективность производительности» рекомендуется выделять как можно больше доступных вычислительных и сетевых ресурсов в соответствии с требованиями рабочей нагрузки.
- Структура мониторинга рабочей нагрузки требует, чтобы компоненты архитектуры выделяли время и ресурсы для создания, сбора и потоковой передачи журналов и показателей. Эти точки данных помогают гарантировать возможность эффективного оповещения и мониторинга для обеспечения надежности, безопасности и производительности. По мере повышения уровня оснащенности может также возрасти нагрузка на системные ресурсы.
Компромисс: увеличение задержки. Чтобы создать производительные рабочие нагрузки, команды ищут способы сократить время и ресурсы, которые рабочие нагрузки потребляют для выполнения своих задач.
- Некоторые шаблоны проектирования облаков, поддерживающие подходы «независимых изменений с течением времени» для поддержки идеалов постепенного улучшения, могут приводить к задержкам из-за обхода дополнительных компонентов.