Вопросы на собеседовании: FinOps-инженер

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

• Compute Savings Plans покрывают EC2 для разных семейств и регионов, а также подходящее использование Fargate и Lambda, поэтому ими я бы закрыл переносимый базовый уровень.
• EC2 Instance Savings Plans дают более глубокую скидку, но привязывают обязательство к семейству инстансов в одном регионе, поэтому подходят стабильному региональному парку.
• Reserved Instances подходят под конкретные требования EC2, особенно когда важны резервирование мощности у zonal RI или экономика Standard RI, но не покрывают Fargate и Lambda.

Я бы разместил переносимый базовый уровень на payer-аккаунте через Compute Savings Plan и не привязывал мигрирующий продукт к одному региону.

• Я бы оценил минимальные повторяющиеся подходящие расходы организации и закоммитил только часть, которая остаётся выше $40 в час в негативных сценариях.
• Выгоды Savings Plans могут распределяться между linked accounts при включённом sharing, поэтому атрибуцию расходов нельзя путать с применением скидки.
• Часть расходов, чувствительную к миграции, я бы оставил on-demand, пока новое размещение и стабильная почасовая нагрузка не подтвердятся несколькими платёжными циклами.

Я бы зарезервировал стабильные конфигурации VM, а savings plan использовал для базовой compute-нагрузки, меняющей серии или регионы.

• Reservations на один или три года подходят предсказуемым семействам ресурсов и могут иметь shared, subscription, resource-group или management-group scope в зависимости от ownership.
• Azure Savings Plan for Compute фиксирует почасовую сумму и применяется к подходящему compute в поддерживаемых сервисах и регионах, сохраняя гибкость меняющегося парка.
• Я бы моделировал utilization после действующих скидок и оставил всплески незакрытыми, потому что пересекающиеся обязательства не дают двойную скидку.

Я бы оценил resource-based CUD для стабильной конфигурации Compute Engine и spend-based CUD для подходящих переменных сервисов.

• Resource-based CUD фиксируют указанные ресурсы, например vCPU и память в регионе, поэтому базовые $55 нужно перевести в устойчивый профиль машин.
• Spend-based CUD фиксируют почасовые расходы по подходящим сервисам и лучше подходят Cloud Run или меняющемуся compute-миксу.
• Я бы сравнил сроки на один и три года с негативным прогнозом и проверил eligibility, потому что on-demand и committed расходы не взаимозаменяемы для каждого SKU.

Я бы добавил effective savings rate, потому что coverage и utilization сами по себе не показывают чистую скидку на все подходящие расходы.

• Coverage равен подходящему использованию со скидкой, делённому на всё подходящее использование, а utilization равен использованному обязательству, делённому на купленное.
• Effective savings rate равен разнице on-demand-эквивалента и чистой амортизированной стоимости, делённой на on-demand-эквивалент того же использования.
• Я бы сверил комиссии, неиспользованный коммит, кредиты и shared benefits, ведь 96 процентов utilization всё равно могут дать слабую экономию при небольшой разнице ставок.

Я бы покупал подтверждённый минимум ступенями и пересматривал незакрытый рост по мере появления фактов.

• Например, я бы закоммитил $70 в час сейчас, $25 через три месяца и последние $25 через шесть месяцев, если utilization держится выше 95 процентов.
• Разнесённые даты начала и окончания не дают всем $120 в час продлеваться на основании одного прогноза и создают регулярные точки пересмотра цены.
• Прогнозируемый рост остался бы on-demand до фактического появления, потому что предварительная покупка ожидаемых 25 процентов превращает позитивное предположение в фиксированный риск.

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

• Скидка 28 процентов означает ставку обязательства $72 в час, поэтому break-even utilization равен 72 процентам от базовых $100 в час.
• Если половина нагрузки исчезнет через шесть месяцев, годовое использование составит 75 процентов: $657 000 стоимости по on-demand минус $630 720 стоимости обязательства дают $26 280 экономии.
• Ожидаемая экономия равна 80 процентам от $245 280 плюс 20 процентам от $26 280, то есть $201 480; наличие подходящей нагрузки нужно проверить в каждом часу, потому что среднее за год может скрыть незакрытые или неиспользованные часы.

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

• Convertible RI можно обменять на другие Convertible RI по правилам AWS по стоимости и сроку, но нельзя продать на RI Marketplace.
• Подходящие Standard RI можно выставить на Marketplace с учётом ограничений аккаунта, платежей, оставшегося срока и типа предложения, но покупатель не гарантирован.
• Savings Plans нельзя обменять или перепродать, поэтому варианты для RI нельзя представлять универсальным выходом из любых обязательств.

Я бы разрешил ограниченную автоматизацию только с лимитами покупок, немедленным kill switch и планом восстановления по реальным правилам Savings Plans.

• Политика должна ограничивать новый чистый commitment в неделю, исключать области с миграциями или отключениями, отделять разрешение покупки и создавать alert на каждое существенное изменение портфеля.
• Для плана на $75 в час автоматизация сразу проверяет ограниченный возврат: покупка не старше 7 дней, тот же календарный месяц, commitment не выше $100 в час и доступный возврат для аккаунта.
• Вне этого окна план нельзя обменять или перепродать, поэтому я остановлю новые покупки и направлю оставшийся eligible demand туда, где это допускают sharing и архитектура.

Я бы ранжировал нагрузки по устойчивости к прерываниям и начал со stateless и retryable мощности, а не применял цель 50 процентов ко всем одинаково.

• CI workers, queue consumers и batch jobs с checkpoint подходят первыми, потому что прерывание теряет минуты работы, а не пользовательские сессии.
• Stateful-базы, singleton controllers и нагрузки с 30-минутным запуском остаются on-demand, пока не изменится их архитектура.
• Я бы отслеживал Spot share, interruption rate, время завершения и чистую экономию после повторов, чтобы цель 50 процентов не скрывала стоимость надёжности.

Я бы диверсифицировал мощности и сделал задачи возобновляемыми, чтобы ни один Spot-пул не определял их завершение.

• Karpenter получил бы широкие требования по семействам, размерам и Availability Zones вместо одного предпочтительного типа с малой доступностью.
• Задачи делали бы checkpoint каждые пять минут, обрабатывали уведомления о прерывании и повторялись через очередь с идемпотентной записью результата.
• Я бы сохранил 20 процентов on-demand или fallback NodePool и сравнивал нарушения дедлайнов с экономией до увеличения Spot share.

Я бы выбирал размер по устойчивым высоким перцентилям и требуемому запасу, а не по средним 20 процентам.

• На p99 сервис использует около 5,9 vCPU, поэтому цель 6 vCPU не оставляет рабочего запаса, а 4 vCPU небезопасны.
• Сначала я бы протестировал более дешёвое поколение с 8 vCPU или scale-out конфигурацию, затем целился примерно в 20 процентов запаса над p99 после нагрузочного теста.
• До уменьшения инстанса ту же проверку должны пройти p99 памяти, throttling, latency, задержка autoscaling и сезонность.

Я бы сравнил полную стоимость burstable-инстансов с семействами фиксированной производительности и убрал устойчивые нагрузки с unlimited bursting.

• Расходы на CPU credits показывают, что базовое право парка ниже устойчивого спроса, даже если среднее за месяц выглядит низким.
• Я бы отделил действительно пиковые сервисы от постоянных workers и протестировал семейства M или C для постоянного сегмента.
• Для оставшихся T-инстансов я бы настроил алерты на credit balance и surplus charges и проверил, что Standard mode не создаст throttling для чувствительного к latency сервиса.

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

• Lifecycle rules могут перевести 180-дневную группу объектов в холодный класс, но в модель входят retrieval fees, минимальный срок и задержка восстановления.
• Для block storage я бы удалил неподключённые тома и старые snapshots, затем отдельно подобрал provisioned IOPS и throughput независимо от ёмкости.
• Я бы провёл пилот на одном классе данных и 60 дней измерял стоимость хранения, запросов, извлечения и эксплуатации до широкого запуска.

Я бы разложил transfer по источнику, назначению, пути и тарифному классу до изменения архитектуры.

• Billing и flow data должны разделить cross-AZ, cross-Region, internet egress, NAT processing, CDN origin и transfer управляемых сервисов.
• Если chatty-сервисы теперь пересекают Availability Zones, объединение запросов или topology-aware placement могут сэкономить деньги без отказа от нужной избыточности.
• Я бы посчитал устранённые байты и влияние на latency или устойчивость, ведь перенос всего в одну зону снижает стоимость, но увеличивает риск отказа.

Я бы разделил инфраструктуру базы, редакцию и лицензионные права, потому что rightsizing compute затрагивает меньше половины счёта.

• Я бы проверил число ядер, функции редакции, права passive failover и возможность применить имеющиеся лицензии через Azure Hybrid Benefit или AWS License Mobility там, где это разрешено.
• Профилирование запросов и памяти может позволить сократить лицензируемые ядра, а переход с Enterprise на Standard требует доказать, что нужные функции не потеряются.
• Миграция на управляемую open-source СУБД может сократить лицензии, но business case должен включать работу инженеров, риск простоя и стоимость параллельного запуска.

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

• Практический score может умножать проверенную месячную экономию на уверенность и ожидаемый срок действия, затем вычитать стоимость внедрения и перехода.
• Я бы повысил приоритет idle-ресурсов с владельцем и путём отката и снизил его для production-rightsizing по данным только за семь дней.
• Очередь показывала бы owner, dependency, due date, принятый риск и realized savings, превращая рекомендации в ответственную работу, а не инвентарь дашборда.

Я бы определил одну стабильную иерархию от юридического плательщика к бизнес-юниту, продукту, команде, окружению и ресурсу.

• Ownership аккаунта, subscription или project даёт первую детерминированную границу, после которой теги и Kubernetes-метаданные заполняют нижние уровни.
• Каждому продукту и команде нужен версионируемый идентификатор, а не display name, чтобы реорганизации не переписывали историческую стоимость.
• Нераспределённые расходы остаются видимыми в отдельной группе с owner и целевым уровнем, а не незаметно размазываются по продуктам.

Я бы разделил платформу на cost pools и назначил каждому драйвер, лучше всего отражающий потребление.

• Build workers можно распределять по runner minutes, observability по ingested GB, а API gateway по числу запросов или обработанным байтам.
• Фиксированный базовый уровень платформы можно делить по согласованной мощности или выручке продукта, только если отчёт отмечает это как policy allocation, а не измеренное использование.
• Для каждого pool allocated cost dollars плюс явный unallocated residual должны равняться стоимости этого исходного pool; все pools вместе должны давать $420 000, а единицы драйвера отдельно сверяются со своим источником измерений, не с долларами счёта.

Я бы распределял переменные сетевые расходы по измеренным байтам, а фиксированные attachment charges оставил в отдельном shared pool.

• NAT processing относится к байтам исходного аккаунта или нагрузки, transit processing к attachment и направлению, а inter-Region transfer к обеим конечным точкам.
• Фиксированную почасовую стоимость gateway можно делить по подключённым аккаунтам или зарезервированной мощности, потому что byte-only модель сделает idle attachments бесплатными.
• Flow logs нужно сэмплировать и сверять с billed GB, сохраняя неизвестный трафик явной строкой network-unallocated.