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

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

  • Статья

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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