Я занимаюсь finops последние 2 года. Наблюдаю за множеством статей, но почти все они, ограничиваются теорией. Это похоже на становление devops. Тогда так же, большинство статей были теоретическими и даже успешные кейсы не имели возможность на масштабирование.

Манифест и длинные опусы о важности finops упираются в простой вопрос: как внедрить в конкретную компанию? От части ответы есть, но все они не имеют пока широкого практического применения, по крайней мере в России.

Если отталкиваться от методологии finops, то первое, что мы должны сделать - это настроить наблюдаемость через тегирование ресурсов и определения ответственных за потребление в Облаке. Кажется это весьма легко, но ровно до момента начала внедрения. Тут появляется масса вопросов. Например, кто является владельцем QA стенда? На первый взгляд - это команда тестирования, однако, по факту им пользуются все. Далее мы натыкаемся на вопрос тегирования внутри k8s, тут есть общий пул ресурсов откуда каждая команда откусывает по кусочку. Но и даже это не главное. Куда важнее вопрос автоматизации. Что делать если есть сотни ресурсов, которые динамически изменяются? Проставлять лейблы руками и постоянно отслеживать их актуальность? Боюсь через месяц это превратится в рутину которой никто не будет заниматься.

Мы обозначили первую проблему - отсутствие автоматизации. Но за ней идёт сложность в реорганизации процессов. Недостаточно просто развесить лейблы и генерировать отчёты по потреблению каждой ресурсной единицы. Далее нужно добиться, чтобы каждая команда несла ответственность за использование ресурсов. Однако, сделав это в лоб мы наживем себе внутренних врагов, которые начнут саботировать этот процесс или же необдуманно сокращать расходы в ущерб основным задачам. Чтобы избежать этого, придётся разработать понятную систему расчёта эффективности потребления. То есть, дать командам точный алгоритм расчёта, чтоб они могли защищать свои траты на уровне бизнеса. На проработку и внедрение может уйти не то что месяцы, а скорее годы.

И что же получается, мы оказываемся в тупике ещё на первом этапе FinOps? Ведь мало кто готов потратить сотни часов на то, что принесёт неопределенную выгоду через годы.

15 лет назад, на заре развития была методология devops. Тогда компании со всех сторон слышали о том, как ускоряет разработку и TimeToMarket внедрение этих практик. Но на деле так же требовалось значительно изменить процессы разработки и управление инфраструктурой. И если крупные компании могли позволить себе выделить целый отдел и вести внедрение, то средний бизнес оказывался в тупике. Решение появилось само собой - главное было выкинуть "якорь". В случае devops это был CI/CD. Добавление в процессы jenkins давало значительный эффект: релиз автоматически уходит на прод по кнопке, процесс сокращался с дней до часов и минут. Однако, такое внедрение нельзя назвать полноценным devops переходом. Это лишь давало возможность взять вектор и вести компанию в нужном направлении, получая положительные изменения почти сразу. Далее куда проще реализовывать более сложные практики и довести трансформацию до логического конца.

Проводя параллель между finops и devops мы так же можем выделить такой "якорь". В начале компании нужно научиться оптимизировать уже имеющиеся ресурсы. Я провел десятки встреч с разными компаниями, и почти каждая неправильно воспринимала процесс оптимизации. Большинство считали, что нужно просто порезать расходы и естественно боялись, что это приведет к деградации производительности их продукта. И тут стоит пояснить, что главная цель на этом этапе научится использовать Облако максимально эффективно. То есть, главная цель не просто уменьшить бюджет, а сделать так, чтобы каждый потраченный рубль был обоснован. К примеру, было выявлено, что тестовый стенд использует только 30% запрошенных ресурсов. В простом случае напрашивается сократить ресурсы, но зачастую будет выгоднее не урезать один стенд, а распределить ресурсы на два стенда. Да, по деньгам мы не выиграем, но расширим возможности команды по разработке, а это даст возможность быстрее тестировать и выводить новые фичи. Еще одним важным моментом является умение использовать сильные стороны Облака. Мало кто задействует тестовые стенды круглосуточно. Куда выгоднее выключать их на ночь, а днем использовать больше ресурсов, чем раньше, но за те же деньги. Главное, получить инструмент, который поможет быстро выявлять, оптимизировать и автоматизировать текущую инфраструктуру. Это первый и самый важный шаг, который к тому же не потребует сильных изменений.

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

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

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