Основной метрикой разработки является time-to-market. На него все молятся как на священную корову: считают дни до релиза, выстраивают CI/CD, внедряют DevOps. А вот про то, как быстро можно начать экономить на инфраструктуре после того, как заметили перерасход, почему-то никто не думает. Будто так и надо. Хотя спустить облачный бюджет можно едва ли не быстрее, чем в кафе на Патриках. Стало быть, если time-to-market для облаков не существует, его надо придумать.
Что такое Time-to-Optimize
И мы-таки придумали.
Time-to-Optimize, или TTO — это время от момента, когда кто-то понял, что с облачными расходами пора что-то делать, до того, как появились первые результаты. То есть до того, как либо счета реально пошли на снижение, либо ресурсы высвободились под новые задачи, либо производительность выросла при тех же деньгах.
Проще говоря, это скорость реакции на перерасход. Если классические FinOps-метрики показывают, сколько сэкономили в итоге, то Time-to-Optimize – как быстро до этой экономии ��обрались. А чем раньше вы добьетесь результата, тем быстрее перестанет расти перерасход.
В целом, TTO применим для любых сред, но особенно актуален для мультиоблака, просто в силу того, что данные о расходах там разбросаны по разным системам.
Каждый провайдер имеет собственный биллинг, свои форматы. Даже названия одних и тех же сервисов чаще всего отличаются. У одного виртуалка – это instance, у другого – VM, у третьего – compute unit. У кого-то трафик входит в стоимость, у кого-то не входит. Кто-то тарифицирует его по секундам, кто-то – по минутам. Плюс, к каждому облаку в довесок обычно идут еще SaaS-подписки, managed-сервисы, CDN, системы мониторинга. В общем, черт ногу сломит.
В гибридной инфраструктуре к этому добавляется амортизация железа, зарплаты и электричество. Без учета всего этого реальную картину затрат не увидеть. А увидеть надо. Иначе ни расчетов, ни тем более оптимизации не получится.
Как считать Time-to-Optimize и почему это не так просто
На первый взгляд, формула расчета Time-to-Optimize выглядит максимально внятно. Математически она записывается так:
TTO = T_сбор_данных + T_нормализация + T_аллокация + T_анализ_и_решение + T_внедрение + T_первые_результаты
T_сбор_данных — время на получение сырых биллинговых данных от всех провайдеров
T_нормализация — приведение данных к единому формату (валюта, метрики, сервисы)
T_аллокация — распределение расходов по cost-центрам, проектам, командам
T_анализ_и_решение — работа FinOps/финансов/ИТ-руководителе�� по принятию решений о том, что оптимизировать
T_внедрение — реализация изменений (выключение VM, изменение тарифов, перераспределение ресурсов)
T_первые_результаты — фиксация первых измеримых эффектов (снижение счета в биллинге, уменьшение потребления)
Глобально все понятно. Знай себе – складывай слагаемые и получай ответ. Но есть нюанс. Вернее два.
Во-первых, сами этапы редко идут строго по порядку. Например, пока нормализуете данные, может выясниться, что от одного провайдера пришли не все файлы. А значит, возвращаемся к сбору. Или при аллокации обнаруживается, что половина ресурсов вообще не размечена тегами. Приходится останавливаться, разбираться с владельцами, проставлять теги. Потом заново собирать данные. Потом опять нормализовать. В общем, ад.
Во-вторых, этапы имеют свойство длиться по-разному. Сбор данных из пяти облаков вручную через CSV может занять неделю. Но с API-интеграциями те же данные подтягиваются за пять минут. Аллокация по cost-центрам в маленькой компании с тремя проектами делается за пару часов, тогда как у корпорации с двадцатью командами и shared-ресурсами может растянуться на неделю. Что касается анализа и принятия решений, то они вообще зависят от того, насколько быстро руководители могут собраться и договориться. И тут, сами понимаете, может уйти и день, и целый месяц.
Практический способ расчета Time-to-Optimize
Расчет начинается с определения точки старта. Это момент, когда появилась задача оптимизировать затраты. Превысили бюджет? Это оно. Плановый аудит? Подходит. Запускаете новый проект и прикидываете стоимость? Принимается.
Дальше отслеживаете этапы:
Когда получены данные
Когда они стали прозрачными (распределены по cost-центрам)
Когда вынесено решение
Когда применили меры оптимизации
Когда зафиксировали первые рубли экономии
Фиксировать каждую дату – строго обязательно. Иначе просто не поймете, на чем теряете больше всего времени.
Точка ставится в день, когда подтвержден первый измеримый результат. Обычно это новый отчет в биллинге, где видно реальное снижение. TTO считается просто: разница между точкой конца и точкой старта.
Чтобы не запутаться, полезно разделить TTO на подуровни:
Макро-TTO — это весь цикл целиком: от осознания, что у вас случился перерасход, до первых ощутимых результатов. Так проще понять, насколько быстро компания реагирует на такого рода процедуры.
Микро-TTO — это длительность отдельных этапов внутри цикла: сбор, нормализация, анализ, внедрение. Она помогает понять, на каком этапе происходят самые ощутимые задержки.
Определяем зрелость FinOps: что реально дает метрика Time-to-Optimize
Метрика Time-to-Optimize является одним из ключевых индикаторов, который показывает, на какой стадии зрелости FinOps вы реально находитесь.
Стадия Crawl: низкая зрелость
Это начальная стадия. Тут ��ы просто реагируете на проблемы после того, как они дали о себе знать, но не обладаете инициативой. На этом этапе данные собираются вручную через CSV-выгрузки и Excel, а анализ проводится когда придется. Оптимизация возможна, но точечно.
TTO на этой стадии измеряется неделями: как правило, от 3 до 6. За это время перерасход может вырасти на 20-30% от первоначального. Это, кстати, важный нюанс: вы не фиксируете перерасход, когда узнаете о нем, а продолжаете его накапливать до завершения оптимизации. Получается как у Кэрролла — чтобы оставаться на месте, надо бежать изо всех сил, а чтобы куда-то попасть, нужно бежать вдвое быстрее.
Звучит не очень многообещающе, спору нет. Но на стадии Crawl от вас многого и не требуется. Будет достаточно устранить только самые очевидные косяки: зомби-ресурсы, которые никто не использует, неиспользуемые IP-адреса, виртуалки в режиме idle. В общем, все, до чего дотянутся руки. Хотя и это будет непросто – процессы-то не налажены. Но лучше так, чем никак.
Стадия Walk: средняя зрелость
Это стадия, когда компании начинают работать более системно:
Появляются регулярные автоматические выгрузки биллинга;
Внедряется частичная аллокация затрат;
Формируется специализированная FinOps-команда.
С таким подходом можно начинать действовать проактивно. Например, нашли неоптимальный тариф – поменяли за один день, сэкономили. Обнаружили, что половина виртуалок работает в нерабочее время без нагрузки – настроили автоотключение, еще сэкономили. В результате оптимизация превращается из катастрофы, к которой никто никогда не готов, в заранее спланированную и – самое-то главное – повторяемую процедуру.
Стадия Run: высокая зрелость
До этой стадии, будем честны, добираются не все. Да, на самом-то деле, не всем сюда и нужно. Все-таки тут игра идет совсем по-взрослому:
Используются специализированные FinOps-платформы с полной автоматизацией процессов;
Аллокация по продуктам и командам достигает 100%;
Применяются автоматизированные решения и действия, когда система сама видит проблему, сама предлагает решение и даже сама его применяет без участия человека.
На этом этапе TTO – самый низкий (то есть быстрый, а значит, хороший). Он измеряется часами или максимум одним-двумя днями.
Нет, это не утопия. Чудес-то не бывает. Поэтому добраться до Run будет дорого, сложно и потребует изменения всей культуры компании: инвестиции в инструментарий, обучение персонала, выстраивание процессов. Но разница в скорости реакции будет колоссальная.
Метрика Time-to-Optimize является одним из ключевых индикаторов, который показывает, на какой стадии зрелости FinOps вы реально находитесь.
Стадия Crawl: низкая зрелость
Это начальная стадия. Тут вы просто реагируете на проблемы после того, как они дали о себе знать, но не обладаете инициативой. На этом этапе данные собираются вручную через CSV-выгрузки и Excel, а анализ проводится когда придется. Оптимизация возможна, но точечно.
TTO на этой стадии измеряется неделями: как правило, от 3 до 6. За это время перерасход может вырасти на 20-30% от первоначального. Это, кстати, важный нюанс: вы не фиксируете перерасх��д, когда узнаете о нем, а продолжаете его накапливать до завершения оптимизации. Получается как у Кэрролла — чтобы оставаться на месте, надо бежать изо всех сил, а чтобы куда-то попасть, нужно бежать вдвое быстрее.
Звучит не очень многообещающе, спору нет. Но на стадии Crawl от вас многого и не требуется. Будет достаточно устранить только самые очевидные косяки: зомби-ресурсы, которые никто не использует, неиспользуемые IP-адреса, виртуалки в режиме idle. В общем, все, до чего дотянутся руки. Хотя и это будет непросто – процессы-то не налажены. Но лучше так, чем никак.
Стадия Walk: средняя зрелость
Это стадия, когда компании начинают работать более системно:
Появляются регулярные автоматические выгрузки биллинга;
Внедряется частичная аллокация затрат;
Формируется специализированная FinOps-команда.
С таким подходом можно начинать действовать проактивно. Например, нашли неоптимальный тариф – поменяли за один день, сэкономили. Обнаружили, что половина виртуалок работает в нерабочее время без нагрузки – настроили автоотключение, еще сэкономили. В результате оптимизация превращается из катастрофы, к которой никто никогда не готов, в заранее спланированную и – самое-то главное – повторяемую процедуру.
Стадия Run: высокая зрелость
До этой стадии, будем честны, добираются не все. Да, на самом-то деле, не всем сюда и нужно. Все-таки тут игра идет совсем по-взрослому:
Используются специализированные FinOps-платформы с полной автоматизацией процессов;
Аллокация по продуктам и командам достигает 100%;
Применяются автоматизированные решения и действия, когда система сама видит проблему, сама предлагает решение и даже сама его применяет без участия человека.
На этом этапе TTO – самый низкий (то есть быстрый, а значит, хороший). Он измеряется часами или максимум одним-двумя днями.
Нет, это не утопия. Чудес-то не бывает. Поэтому добраться до Run будет дорого, сложно и потребует изменения всей культуры компании: инвестиции в инструментарий, обучение персонала, выстраивание процессов. Но разница в скорости реакции будет колоссальная.
Чем хорош короткий Time-to-Optimize
Что самое главное в FinOps? Сейчас скажу крамольную вещь, только не бейте: важна не столько экономия, сколько время выхода на результат. Допустим, потратили вы на инфраструктуру на 25-30% меньше. А как быстро к этому пришли? Это и есть ключевой параметр.
Смотрите сами.
Если TTO меньше недели, сэкономленные средства можно использовать для развития продукта уже в текущем месяце. А это новые фичи, эксперименты, масштабирование на новые рынки, да мало ли что еще. А вот при TTO в 3-4 недели экономия проявится только в следующем периоде, и польза от финансов для развития, которые пришлись бы очень кстати здесь и сейчас, де-факто теряется.
Короткий TTO – это в первую очередь переход от реактивности к предиктивности. Вы банально лучше адаптируетесь к изменениям в бизнесе, эффективнее масштабируете ресурсы под новые проекты, да и просто принимаете технологические решения на основе реальных данных, а не предположений.
Получается интересный парадокс: оптимизация ускоряет time-to-market. Вы не просто тратите меньше денег, вы перестаете тратить драгоценное время на разного рода рутину, которая с быстрым TTO по большей части исполняется в автоматическом режиме.
А в довесок ко всему короткий TTO улучшает отношения между отделами. Когда обе стороны видят быстрые и измеримые результаты от финопс-инициатив, найти общий язык сотрудникам становится проще. CFO понимает, что технари не просто транжирят деньги, а CTO видит, что финансисты не просто жадничают, а помогают.
От чего зависит скорость Time-to-Optimize
TTO напрямую зависит от 3 параметров: архитектуры, инструментов и культуры. Все остальное — вторично.
Начнем с архитектуры. Чем она сложнее, тем больше времени уйдет на оптимизацию. Мультиоблако — это ни разу не про гибкость. Она требует железной дисциплины, иначе рискуете завязнуть в этом надолго.
Затем – инструменты. Именно они являются основным ускорителем TTO. Лучше всего на разгон оптимизации работают FinOps-платформы. Они сами собирают данные через API, нормализуют форматы, распределяют расходы по тегам и командам, а главное — выдают готовые рекомендации: где перерасход, что можно отключить, и сколько денег это даст.
Но все это не имеет никакого смысла, если у вас в компании не выстроена культура быстрых решений. Тут вам никакая платформа не поможет. Если на согласование одного выключенного инстанса уходит неделя и десять писем в копии, TTO будет расти, как на дрожжах. Для FinOps это не приемлемо.
И, как говорил Стив Джобс, one more thing, а именно тегирование. Да, это не очень веселая штука, но без тегов вы не узнаете, кто тратит, сколько и на что. А с тегами — знаете. И благодаря ему сможете рассчитать TTO так, как оно есть на самом деле.
Подводные камни TTO и как их избежать
В теории и на чужих примерах все звучит очень даже хорошо и правильно, но у TTO есть свои сложности. Не критичные, но знать о них стоит:
TTO требует отслеживания. Даты, этапы, события. Вроде ничего особенного, но это оказывает дополнительную нагрузку на команду, особенно если у вас параллельно идет несколько инициатив по оптимизации. Как понять, где одна закончилась, другая началась? Приходится разбир��ться. И вот парадокс: чем выше ваш уровень, тем проще становится.
Команды могут начать оптимизировать саму метрику, а не реальные процессы. Гонка за коротким TTO приводит к поспешным решениям. Отключили что-то важное ради быстрого результата, а через неделю половина функционала легла. Так что скорость без анализа может навредить едва ли не больше, чем медленный, но продуманный подход.
Контекст, в котором вы рассчитываете TTO, тоже имеет значение. Аварийная оптимизация после того, как счет вдруг взлетел в два раза — это одно. А плановая работа в рамках квартального ревью — совсем другое. Или возьмем тип изменений: простые действия не требуют много времени: выключил забытые виртуалки – и вот ваш TTO занимает всего пару дней. То ли дело архитектурные перестройки. Они вообще могут занять месяцы даже при хорошей автоматизации. Сравнивать эти TTO между собой некорректно.
Все эти проблемы решаемы, если помнить про контекст и не превращать TTO в самоцель. Метрика должна помогать, а не усложнять жизнь.
TTO: а в итоге что?
Time-to-Optimize можно применять по-разному:
Использовать в качестве KPI для FinOps-команды. Получается очень удобно и точно. Только с поправкой на то, что измеряем мы не количество закрытых задач, а скорость получения реальной экономии.
Сравнение сценариев. В полностью ручном режиме TTO достигает 20 дней, а в автоматизированном – 2 дня. Это наглядные цифры, которые можно смело показать руководству и обосновать бюджет на платформу или инструменты. Разница в десять раз все скажет сама за себя.
Аргументация для руководства. Общаться с начальством надо по-особому, правильно выбирая слова. А обещание начать экономить бюджет в 10 раз быстрее, сократив TTO с трех недель до двух дней, сработает безотказно.
Интеграция в модель зрелости FinOps. На уровне Crawl TTO измеряется неделями. На Walk — днями. На Run — часами. Получается простая и понятная градация, которая показывает, где вы находитесь и куда двигаться дальше. Это уже не абстрактная "низкая зрелость" из методички, а конкретные "три недели до результата".
Очевидно, что в ближайшие годы TTO может стать стандартом для оценки зрелости FinOps наравне с моделью Crawl-Walk-Run, и почти наверняка ей станет. Только помните одну простую вещь. Метрика — это инструмент, а не самоцель.
