Компромиссы по оптимизации затрат

  • Статья

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

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

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

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

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

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

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

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

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

  • Использование номеров SKU бюджета может ограничить максимальную цель уровня обслуживания (SLO), которую может достичь рабочая нагрузка.

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

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

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

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

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

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

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

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

  • Масштабирование на основе событий может быть сложнее настроить и проверить, чем масштабирование на основе ресурсов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Использование шаблона Queue-Based выравнивания нагрузки для сокращения затрат путем внедрения шины сообщений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Уменьшение объема журналов и метрик для экономии затрат на хранение и передачу снижает наблюдаемость системы и может привести к:

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

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

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

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

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

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

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

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

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

  • Снижение затрат за счет сокращения ресурсов может лишить приложения ресурсов. Приложение может не справиться со значительными колебаниями шаблонов использования.

  • Ограничение или задержка масштабирования до ограничения или снижения затрат может привести к нехватке предложения для удовлетворения спроса.

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

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

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

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

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

Изучите компромиссы по другим основным аспектам: