TGViewer
Практики FinOps Практики FinOps @finops_ru · 569 subscribers
Post #444 195
🟢 Как хаотичные проверки ломают продакшен и почему разовая очистка не работает? Часть 1

Опытом делится Александр Либкинд, руководитель направления развития сервисов управления затратами и эксперт Практики FinOps.


Казнить «server-01» нельзя помиловать — стандартная проблема при инвентаризации ИТ-инфраструктуры. Инициатива по очистке облака от неиспользуемых мощностей редко проходит безболезненно. Обычно процесс выглядит так: руководство назначает ответственного, тот неделями собирает данные по разным отделам и системам, а затем пытается разобраться, нужен ли конкретный актив бизнесу или перед ним пустая трата бюджета.

Следующий шаг — запросы по компании в попытке найти владельцев ресурсов. В ответ обычно тишина, так как никто внутри команды не знает, чьи это мощности. Тогда включается режим крайних мер: «Раз не ответили, значит, мусор. Останавливаем (удаляем, если действовать радикально)».

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

Когда инцидент исчерпан, а руководство требует снизить суммы в счетах от провайдеров, начинается новая волна проверок. Удаляются давно не запускаемые виртуальные машины, свободные IP-адреса и неиспользуемые диски. В следующем месяце счет действительно становится меньше. Все выдыхают и хлопают друг друга по плечу.

На первый взгляд, это результат. Но давайте смотреть на вещи честно: к FinOps это не имеет отношения. Это временный эффект чистой комнаты перед приходом гостей, когда весь хлам просто прячут в шкаф, главное не открывать его. Без системных изменений через пару месяцев инфраструктура снова превратится в свалку. Разовая зачистка временно латает дыры, но не меняет культуру потребления ресурсов.

🌸 Почему так происходит?
Потому что поиск владельцев опирается на человеческую память, а удаление — на ручной анализ сырых данных. Инженер по-прежнему может в два клика арендовать мощный сервер, забыть про него и уволиться. А сервер будет тихо сжигать бюджет до следующей генеральной уборки. Чтобы проблема ушла навсегда, отказываться нужно не от очистки, а от ручного контроля за ресурсами.

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


😏 — жду продолжения
👾 — ставлю реакцию, чтобы мой прод не удалили

#finops_эксперты

💬 Чат | 💬 Практики FinOps
  • 👾 4
More from @finops_ru
  1. Jul 16, 2026⚡️ FinOps по фасттреку: как снизить облачные расходы и не сломать сервис В идеальном мире…
  2. Jul 14, 2026🟩«Раз, два, три, четыре, пять — вышел зайчик посчитать» А как посчитал косты — прослезилс…
  3. Jul 13, 2026🟢 Какая часть облачного счета уже управляется? Разбираем метрику, которая показывает, как…
  4. Jul 9, 2026🟥 FOCUS: когда AI-затраты перестают быть набором несвязанных счетов Классические облачные…
  5. Jul 6, 2026🟢У Максима Качинского вышла большая техническая статья на Хабре про KEDA, Kubernetes и Fi…
  6. Jul 6, 2026⚡️ Как считать инфраструктуру, если у компании есть и свои ЦОДы, и публичные облака? В тео…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →