В выступлении разбирают конкретные решения, которые дают измеримый эффект в счёте, от постановки цели и нормализации расходов до технических изменений в инфраструктуре.
Среди примеров, переход на ARM-инстансы, то есть использование более энергоэффективных процессоров вместо x86, что снижает стоимость вычислений при той же нагрузке, оптимизация непроизводственных сред, работа с сетевым трафиком и использование автоскейлинга и спота в контейнерных нагрузках.
Карточки выше, это выжимка практических приёмов, которые применяются на практике и дают экономию без пересборки продукта.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Kubernetes — это как мультитул, только для облака. Функций море, возможностей вагон, но есть нюанс: за каждую фичу надо платить. И если не следить, можно разориться. Потому что ситуации, когда закладывали на кластер 200 тысяч рублей в месяц, а по факту заплатили 500-600, происходят кругом и рядом.
Только куда уходят деньги? Проблема в том, что большинство статей расходов вообще не видны, пока не придёт счёт. А когда он приходит — начинается паника.
В нашей новой статье на Хабр разбираемся, куда именно уходят деньги в Kubernetes и как заткнуть все дыры без ущерба для работы. Пошагово, с конкретными цифрами и без воды. Бонусом — чек-лист, по которому можно пройтись и понять, сколько вы переплачиваете прямо сейчас.
Please open Telegram to view this post
VIEW IN TELEGRAM
😁7 5☃3😱1👀1👾1
Его обычно открывают уже после закрытия периода, когда видна итоговая сумма, но неясно, какие команды, среды или решения в нее вложились, при том что данные есть, детализация формально доступна, а связать потребление с реальными изменениями в инфраструктуре или продукте не получается.
Это типичная ситуация уровня Inform. Расходы зафиксированы, биллинг корректный, но информация не собрана в форму, по которой можно понять структуру потребления и динамику роста
На подумать
Please open Telegram to view this post
VIEW IN TELEGRAM
Почему клауд билл становится «сюрпризом», даже если доступ к биллингу есть у всех?
Anonymous Poll
31%
Агрегация данных в биллинге скрывает изменения в структуре потребления
25%
Данные биллинга обновляются с задержкой относительно изменений в инфре
13%
Расходы распределены между несколькими аккаунтами и проектами
31%
Изменения в инфраструктуре не синхронизированы с финансовой отчетностью
Please open Telegram to view this post
VIEW IN TELEGRAM
😁8👍6🤩5👀2
Бабки! Бабки! Где бабки?!
Продакшн стабилен, метрики зеленые, архитектура не менялась, а финансовый отдел присылает очередное письмо с вопросом «Где деньги, Зин?». Знакомая картина? И самое обидное — ответить толком нечего, ведь каждый компонент по отдельности работает нормально, а вместе они почему-то дают +40% к счёту.
Одно дело, когда ты в публичном облаке — там хоть биллинг есть, видно, что и сколько стоит. Совсем другое, когда финансы просят «посчитать онпрем как облако», а ты не знаешь, брать остаточную стоимость железа или рыночную цену аналогов. И ещё хуже, когда у тебя несколько команд, несколько систем учета, а общей картины нет вообще.
Добавим сюда вечный спор с DevOps про запас ресурсов с противопоставлением мнений: «нам надо 60% запаса для надёжности» vs «у вас утилизация CPU 40%, давайте экономить». Приправим требованием CFO дать прогноз на год для инфраструктуры, которая масштабируется динамически и получим одни и те же вопросы о том, кто должен принимать решения, где граница между инженерией и экономикой и можно ли вообще управлять этим системно?
Мы собрали пять реальных историй от SRE, DevOps-инженеров и руководителей инфраструктуры, которые каждый месяц объясняют рост счетов и доказывают обоснованность каждого решения. Пока без готовых ответов — но с правильными вопросами.
👉 Читайте новую статью на Хабр и делитесь, с чем вам ещё приходится жить в суровой реальности разбираться по ходу дела.
@finops_ru
Продакшн стабилен, метрики зеленые, архитектура не менялась, а финансовый отдел присылает очередное письмо с вопросом «Где деньги, Зин?». Знакомая картина? И самое обидное — ответить толком нечего, ведь каждый компонент по отдельности работает нормально, а вместе они почему-то дают +40% к счёту.
Одно дело, когда ты в публичном облаке — там хоть биллинг есть, видно, что и сколько стоит. Совсем другое, когда финансы просят «посчитать онпрем как облако», а ты не знаешь, брать остаточную стоимость железа или рыночную цену аналогов. И ещё хуже, когда у тебя несколько команд, несколько систем учета, а общей картины нет вообще.
Добавим сюда вечный спор с DevOps про запас ресурсов с противопоставлением мнений: «нам надо 60% запаса для надёжности» vs «у вас утилизация CPU 40%, давайте экономить». Приправим требованием CFO дать прогноз на год для инфраструктуры, которая масштабируется динамически и получим одни и те же вопросы о том, кто должен принимать решения, где граница между инженерией и экономикой и можно ли вообще управлять этим системно?
Мы собрали пять реальных историй от SRE, DevOps-инженеров и руководителей инфраструктуры, которые каждый месяц объясняют рост счетов и доказывают обоснованность каждого решения. Пока без готовых ответов — но с правильными вопросами.
@finops_ru
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9😁6 4
The True Cost of Moving Fast & Breaking Things
В вебинаре разбирают инженерную сторону скорости и её цену для инфраструктуры и бюджета. Речь идёт о том, как быстрые решения со временем превращаются в техдолг, инциденты и рост расходов.
Спикеры показывают, как потеря видимости отражается на счёте, почему косвенные затраты не видны в биллинге и какие инженерные метрики начинают деградировать первыми, когда команда бежит быстрее, чем может поддерживать систему.
Отдельный фокус сделан на практических инструментах контроля, от инженерных KPI и реакции на cost-спайки как на прод-инциденты, до работы с Kubernetes, автоскейлингом и ограничениями ресурсов.
По сути, это разбор границы, где скорость перестаёт быть преимуществом и начинает напрямую влиять на экономику продукта.
Запись вебинара по ссылке
🥹 — подтянем английский
🥹 — предпочитаю читать карточки
@finops_ru
В вебинаре разбирают инженерную сторону скорости и её цену для инфраструктуры и бюджета. Речь идёт о том, как быстрые решения со временем превращаются в техдолг, инциденты и рост расходов.
Спикеры показывают, как потеря видимости отражается на счёте, почему косвенные затраты не видны в биллинге и какие инженерные метрики начинают деградировать первыми, когда команда бежит быстрее, чем может поддерживать систему.
Отдельный фокус сделан на практических инструментах контроля, от инженерных KPI и реакции на cost-спайки как на прод-инциденты, до работы с Kubernetes, автоскейлингом и ограничениями ресурсов.
По сути, это разбор границы, где скорость перестаёт быть преимуществом и начинает напрямую влиять на экономику продукта.
Запись вебинара по ссылке
@finops_ru
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Облачные расходы растут, аллокация по тегам не даёт полной картины, онпрем и облако считаются в разных системах, а прогноз по инфраструктуре требуется регулярно
ФинОпс Радар уже используют команды, но теперь у инструмента есть отдельный сайт.
Он подключается к облаку в режиме только для чтения через API, собирает данные по расходам и показывает конкретные точки перерасхода:
Отчёт даёт целостный срез расходов и помогает оценить потенциал оптимизации без ручной сборки данных.
ФинОпс Радар полезен:
Если вы ещё не подключали ФинОпс Радар, зайдите на сайт и проведите диагностику своего облака. Инструмент бесплатный, подключение занимает несколько минут, первые результаты видны сразу после синхронизации.
Посмотреть инструкцию для быстрого подключения
@finops_ru
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6 3👏2 1
Вот уже и февраль наступил. Как быстро идет время…
Мы будем очень признательны, если вы уделите пару минут своего времени, и поможете нам сделать бесплатный finops инструмент лучше.
Опрос доступен по ссылкам:
@finops_ru
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5 3✍1👾1 1
Если вы каждый месяц смотрите на счет за облако, выдергиваете волосы на ногах и не понимаете, почему там стабильно +30–40% к плану, вы не одни. Инфраструктура та же, релизов немного, метрики зеленые — а финдир уже бежит к вам по коридору, с вопросами про бюджеты и «кто за это отвечает».
FinOps родился ровно из этой боли: когда недостаточно просто «жать расходы», нужно связать инфраструктуру с бизнес-результатами и научиться управлять затратами как инвестициями, а не как стихийным бедствием. Но это не волшебная кнопка «сделать хорошо» и не один дашборд, а цикл из четырех этапов — от банальной видимости до инвестиционных решений, который по новой запускается при каждом новом сервисе, облаке или гибридной схеме.
А вот и давайте в нашей новой статье разбираем, почему видимость счетов почти всегда приходит раньше, чем реальная ответственность и оптимизация, зачем распределять бюджеты до уровня конкретных сервисов и тимлидов и как считать TCO гибрида так, чтобы сравнивать онпрем и публичку честно, а не «по ощущениям». Заодно проведем практический разбор, с чего начать FinOps хоть завтра утром без дорогих платформ и консультантов.
@finops_ru
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🤣6👏3👾2 2