Как метрика Time-to-Optimize реально экономит деньги на облаке

Time-to-Optimize – ключевая метрика для FinOps

Метрики, KPI и дашборды – это основа деятельности любой компании, претендующей на отлаженность процессов. Особенно в разработке. Там все буквально помешаны на time-to-market и делают ради его достижения все, что только можно, лишь бы вывести продукт на рынок побыстрее. Разве что к бабке-шептунье не ходят. В связи с этим спрашивается: а почему, собственно, точно так же нельзя в облаке, где перерасходы – обычное дело и никто не стремится их устранять? Оказывается, можно.

Что такое Time-to-Optimize

Time-to-Optimize – это временной промежуток между выявлением перерасходов в облаке и их оптимизацией. Она необязательно должна быть полной. Частичная тоже подойдет: уменьшение счетов, высвобождение ресурсов под новые задачи или рост производительности при тех же расходах. Главное, чтобы эти результаты были реальными, а не сводились просто к планам.

Казалось бы, чего тут вообще считать?

Дело в том, что перерасход не фиксируется в тот момент, когда его обнаружили. Он не останавливается на месте, а продолжает нарастать как снежный ком. То есть чем выше ваш TTO, тем больше денег утекает в никуда.

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

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

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

Формула расчета Time-to-Optimize

Для расчета Time-to-Optimize есть специальная формула:

TTO = сбор данных + нормализация + аллокация + анализ + внедрение + фиксация результата

А вот что значат эти слагаемые:

• Сбор данных — получение сырых биллинговых отчетов от всех провайдеров. 
• Нормализация — приведение данных к единому формату. 
• Аллокация — распределение расходов по командам, проектам, cost-центрам (кто сколько потратил и на что).
• Анализ — принятие решений о том, что оптимизировать. 
• Внедрение — реализация изменений: выключение VM, смена тарифов, резервирование ресурсов.
• Фиксация результата — подтверждение первых измеримых эффектов. 

Опять-таки, на бумаге все выглядит просто. Складываем временные отрезки – получаем итоговое число. Вот только на практике возможны нюансы:

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

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

Поэтому полезно разделить TTO на уровни:

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

Так будет проще выявить проблемные места.

TTO как показатель зрелости

Time-to-Optimize – штука универсальная. Он показывает не только скорость оптимизации, но и общий уровень зрелости FinOps в компании. Про сами уровни мы уже рассказывали, а вот как они коррелируют со временем оптимизации:

• Crawl (начальный уровень) – когда все делается руками, а на проблемы реагируем постфактум. TTO измеряется 3-6 неделями.
• Walk (средний уровень) – когда уже есть некая системность, частичная автоматизация и FinOps-команда, пусть даже работающая по совместительству. TTO сокращается до 3-7 дней.
• Run (высший уровень) – когда автоматизировано вообще все, используются специализированные FinOps-платформы, а аллокация достигает 100%. TTO – от нескольких часов до пары дней.

Примеры расчета Time-to-Optimize

Теория теорией, но давайте посмотрим на разницу в результатах в зависимости от уровня зрелости FinOps у одной и той же компании, скажем, с 5 облаками и 10 командами разработки.

Ручной процесс:

• Сбор данных: 5 дней (походы по консолям, скачивание файлов)
• Нормализация: 3 дня (сведение в Excel)
• Распределение: 4 дня (выяснение владельцев, согласования)
• Анализ и решения: 5 дней (встречи, споры, утверждения)
• Внедрение: 2 дня (технические изменения)
• Результаты: 1 день (новый биллинг)

Итого: 20 дней

За это время перерасход продолжает накапливаться, люди отвлекаются от основной работы, и показатели компании падают.

Автоматизированный процесс:

• Сбор данных: минуты (API все подтягивает сам)
• Нормализация: мгновенно (правила уже настроены)
• Распределение: автоматически (теги работают)
• Анализ и решения: 1 день (система выдает готовые рекомендации)
• Внедрение: 1-2 дня (часть изменений применяется сама)
• Результаты: в реальном времени (дашборды показывают изменения)

Итого: 2-3 дня

Разница в десять раз. При этом команды делают то, ради чего их наняли, а не возятся с таблицами.

Что замедляет процесс Time-to-Optimize

Основные факторы замедления TTO

Ну, вообще-то факторов, влияющих на TTO, довольно много. Но вот самые основные:

• Архитектурная сложность: мультиоблако – это в первую очередь многоформатность, с которой нужно уметь грамотно работать.
• Отсутствие автоматизации: когда вся аналитика делается руками в Excel, удивляться большому TTO не приходится. 
• Бюрократия: если вы неделю тратите на то, чтобы согласовать отключение одной забытой виртуалки, вас никакие FinOps-платформы не спасут. 
• Плохое тегирование ресурсов: от такой базовой вещи зависит очень многое. А с правильно настроенной системой тегов вся информация о владельцах, проектах и окружениях доступна мгновенно.

Польза быстрой оптимизации в FinOps

Зачем торопиться, спросите?

Во-первых, скорость оптимизации напрямую влияет на то, в какую сумму вам обойдется ваша облачная инфраструктура. Если команда тратит лишние 500 тысяч рублей в месяц, при TTO в три недели дополнительный перерасход составит еще 375 тысяч. При TTO в три дня — всего 50 тысяч.

Во-вторых, большой TTO реально ухудшает рабочий климат. Финдир не может сразу понять, что техническая команда работает, а не просто жжет бюджет, а техлид – не верит, что финансисты помогают развитию, а не тормозят его.

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

Вывод: в FinOps медленно = плохо.

Что тормозит Time-to-Optimize

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

Кроме того, важно понимать контекст своих действий. Авральная оптимизация из-за двукратного увеличения месячного счета и плановая работа в рамках квартального ревью бюджетов – вообще не одно и то же. Они требуют разной скорости и подхода. Поэтому сравнивать их TTO напрямую некорректно.

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

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

Как использовать TTO на практике

Time-to-Optimize можно использовать несколькими способами:

1. Как основной KPI FinOps-команды. Забудьте про закрытые тикеты в Jira. Сократили TTO с 20 дней до 5? Значит, эффективность работы выросла в 4 раза. И это ясно всем – от CFO до уборщицы тети Маши.
2. Как обоснованиеч бюджетов. Руководство любит цифры, и, если показать ему десятикратную разницу между ручным подходом и автоматизацией. 20 дней против 2 – шутка ли. Вот вам и повод для использования FinOps-платформы. Причем не абстрактное, а с конкретными числами по вашей инфраструктуре.
3. Диагностика узких мест. Если разбить TTO на отдельные блоки, то можно сразу увидеть, где все тормозит. Может неожиданно выясниться, что техническая часть работает как часы, а вот согласования тянутся три недели. Тогда уже ясно, с кем надо разговаривать и какие процессы чинить.
4. Оценка зрелости процессов. Crawl – это недели, Walk – это дни, Run – это часы. Получается простой и понятный индикатор того, где вы сейчас и куда двигаться дальше.

В ближайшие годы TTO наверняка станет такой же привычной метрикой, как когда-то стал time-to-market в разработке. Так что компании, которые освоят быстрое реагирование на перерасходы, получат реальное преимущество перед конкурентами.

Главное — помнить, что TTO это просто инструмент, а не священная корова для поклонения. Его задача помочь выстроить толковую систему управления облачными тратами, где скорость не противоречит здравому смыслу. Потому что лучше потратить лишний день на анализ рисков, чем потом неделю восстанавливать систему и объяснять начальству, что вообще произошло и кто за это ответит.

Быстрая оптимизация — штука безусловно полезная и прибыльная. Но это метрика должна работать на вас, а не вы на нее.