Потихоньку вливаемся в первую рабочую неделю 2026 года!

Слушаем и запоминаем 😁

☁️ Подписаться

💫 Managed Kubernetes в Yandex Cloud: как сократить расходы почти на 50% без деградации сервисов

Kubernetes в managed-облаке удобен в эксплуатации, но при росте нагрузки быстро становится основной статьей расходов. В этом кейсе показано, как снизить стоимость кластера системно, а не за счет ручных оптимизаций и риска для прод-нагрузки.

Что было не так

🟢 managed k8s стал ключевым драйвером облачных расходов
🟢 использование только обычных ВМ для нод
🟢 стандартные прерываемые ноды приводили к массовым сбоям
🟢 отсутствие контроля над временем и порядком выключения нод
🟢 риск появления Pending и Unknown подов при резком падении ресурсов

Что внедрили

Команда отказалась от стандартного поведения instance group и взяла управление жизненным циклом прерываемых нод на себя через собственный k8s-оператор.

🔴 выделили прерываемые ноды через отдельные лейблы
🔴 реализовали оператор для поэтапного вывода нод из кластера
🔴 ввели контроль времени жизни нод, от 12 до 21 часа
🔴 задали ночное окно обслуживания для массового обновления
🔴 автоматизировали cordon и корректный evict подов
🔴 оставили удаление и пересоздание нод за Cluster Autoscaler
🔴 увеличили размер node group с запасом под переходные состояния

Что получили

🟣 сокращение расходов на кластер почти на 50%
🟣 отсутствие одновременного выключения нод
🟣 стабильную работу сервисов без простоев
🟣 более плотное размещение подов и лучшее использование ресурсов
🟣 контролируемое обновление кластера без ручных операций

📌 Экономия в Kubernetes достигается не выбором дешевых инстансов, а управлением их жизненным циклом. Без этого прерываемые ноды превращаются в источник нестабильности.

Источник: внутренний кейс managed Kubernetes в Yandex Cloud

#кейсы_FinOps

☁️ Подписаться

☁️ Подписаться

📌 Рост цен на colocation в российских ЦОДах

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

В Москве средняя стоимость colocation достигла около 160 тыс. рублей за стойку, рост 11% год к году. В Санкт-Петербурге цена выросла до 109 тыс. рублей за стойку, что соответствует плюс 19% за год.

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

Colocation всё меньше продаётся как «место под сервер» и всё чаще как гарантированная мощность, надёжность и доступ к электричеству. Для FinOps это означает пересмотр unit-экономики, базовыми метриками становятся стоимость кВт, цена МВт в год и условия долгосрочных контрактов на энергию. В облачных и гибридных проектах это ускоряет пересборку финмоделей и сравнение совокупной стоимости владения colocation с публичным облаком с учётом плотности размещения, PUE (Power Usage Effectiveness) и роста энерготарифов.

Источник: RUБЕЖ

☁️ Подписаться

Showback или chargeback: почему отчёты сами по себе не экономят ни рубля

Многие думают, что FinOps — это в первую очередь грамотные отчеты. Но на практике всё упирается в ответственность.

Для экономии гораздо важнее, кто видит расходы, кто за них отвечает и что вообще происходит, если команда внезапно вышла за бюджет.

И тут есть два варианта. Можно показать команде цифры — и надеяться на осознанность. А можно выставить счёт — и списывать деньги с их бюджета. Звучит похоже, но работает по-разному. Это и называется таинственными словами showback и chargeback.

👉 Что это за подходы, чем они отличаются друг от друга и что из них подходит именно вам — читайте в нашей новой совместной статье с DevOps FM на Хабр.

☁️ Подписаться

Уже и звезды намекают

Сегодня, 23 января, после 17:00 есть простой повод переключиться. Рабочая неделя подходит к концу, а в небе в это время выстраиваются Луна, Сатурн и Нептун.

Явление видно недолго и только при ясной погоде. В Москве и большинстве регионов России лучше смотреть ближе к вечеру, сразу после захода Солнца. Луну и Сатурн видно невооружённым глазом, Нептун потребует бинокль, телескоп или зум камеры.

P.S. Если увидели улыбку, значит ваши облака достаточно прозрачные. А если, нет… не унывайте, оптимизация не всегда проходит быстро

☁️ Подписаться

💫Аномали детекшн и перерасход

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

Проблема возникает тогда, когда в потреблении появляется отклонение, не связанное с бизнес-ростом или плановыми изменениями. Перерасход начинается с конкретного дня или даже часа, но в итоговом счете за месяц он выглядит как просто «стало дороже».

Если такие отклонения не отслеживаются регулярно, команда узнает о проблеме уже постфактум, когда деньги уже потрачены и остается только разбираться, что именно пошло не так.

☁️ Подписаться

📣 Пингвин, который когда-то решил идти отдельно, вышел на связь

В первый раз он столкнулся с огромным и неожиданным счетом за облако, что его разочаровало, ведь такого никогда не было. Разбираться уже пришлось по факту…

Он нашёл телеграм-канал Практики FinOps и подписался, чтобы понять, где именно утекают деньги и как с этим работать дальше.

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

А остальным советует не тянуть и делиться каналом с коллегами, чтобы держать облачные расходы под контролем сразу, а не постфактум.

☁️ Подписаться

💫 Правильный ответ: конечно же поиск неожиданных отклонений в расходах

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

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

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

💫 Как правильно использовать Kubernetes и не переплачивать

Kubernetes — это как мультитул, только для облака. Функций море, возможностей вагон, но есть нюанс: за каждую фичу надо платить. И если не следить, можно разориться. Потому что ситуации, когда закладывали на кластер 200 тысяч рублей в месяц, а по факту заплатили 500-600, происходят кругом и рядом.

Только куда уходят деньги? Проблема в том, что большинство статей расходов вообще не видны, пока не придёт счёт. А когда он приходит — начинается паника.

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

☁️ Практики FinOps

💫 Клауд билл, Inform и первые проблемы с пониманием расходов

Его обычно открывают уже после закрытия периода, когда видна итоговая сумма, но неясно, какие команды, среды или решения в нее вложились, при том что данные есть, детализация формально доступна, а связать потребление с реальными изменениями в инфраструктуре или продукте не получается.

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

На подумать 💫