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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Last updated on