FinOps - один із тих термінів, що означає геть різні речі залежно від розміру компанії. Для компанії зі списку Fortune 500 це практика на 30 людей зі спонсором-CFO, бюджетом на інструменти, більшим за вашу зарплатну відомість, і щоквартальними steering-комітетами. Для вашого SaaS на 30 людей це радше: «чому рахунок за AWS на 27% вищий, ніж минулого кварталу, і чиє це завдання - з'ясувати?» Цей пост - для другої групи.
Спершу заспокійлива новина: cloud waste - нудний. Переважна більшість його походить із тих самих п'яти патернів, у кожній компанії, на кожному масштабі. Простоюючий compute, який ніхто не вимкнув. Завеликі інстанси, підняті під пік навантаження, який більше не повторився. Ресурси без тегів, які ніхто не може атрибутувати, тож ніхто не відчуває відповідальності. Забуті dev- та staging-середовища, що працюють цілодобово заради софту, який виходить двічі на місяць. І storage на преміум-рівнях роками після того, як його востаннє хтось читав. Жоден із цих патернів не вимагає сертифікації FinOps Foundation, щоб його виправити. Усі вони вимагають лише того, щоб хтось справді подивився.
Патерн, який ми бачимо найчастіше, заслуговує на окремий абзац. Розробник піднімає c5.4xlarge для навантажувального тесту в четвер. Тест завершується о 16:00 в п'ятницю. Інстанс продовжує працювати всі вихідні, бо вимкнути його - це ручний крок у консолі, яку ніхто не відкриває в суботу. До ранкового standup'у в понеділок команда спалила €180 на простоюючій машині - не через некомпетентність, а тому що дефолт системи - «продовжуй виставляти рахунок». Помножте це на кожну команду, кожні вихідні, кожен забутий експеримент - і ви отримаєте суттєвий відсоток вашого інфраструктурного бюджету, що не робить рівно нічого.
Чому dashboard'и цього не виправляють? Бо видимість ніколи не була вузьким місцем - у вашого cloud-провайдера вже є cost explorer, і ви вже його не відкриваєте. Dashboard повідомляє про те, що сталося, вже після того, як гроші витрачено, у місці, яке треба пам'ятати відвідати, у форматі, що вимагає двадцяти хвилин фільтрування, перш ніж скаже щось, на що можна діяти. Між «дані існують» і «хтось на них подіяв» лежить уся справжня дисципліна FinOps - і це саме та частина, на яку в маленької команди немає вільного ресурсу.
Є ще й структурна проблема, яку dashboard'и не вирішать: multi-cloud фрагментація. У той момент, коли ви запускаєте AWS для продукту, Hetzner для batch-навантажень і випадковий DigitalOcean-проєкт, який хтось почав у 2024 році, питання «скільки ми витрачаємо» перестає мати одну відповідь. Кожен провайдер експортує витрати у власному форматі, за власним розкладом, із власним уявленням про те, що таке проєкт. Більшість малих команд реагують тим, що ретельно відстежують великий рахунок і дають малим рахункам дрейфувати - саме так витік на €400/міс. виживає протягом двох років.
То як насправді виглядає FinOps для команди без команди FinOps? За нашим досвідом, чотири звички покривають більшість цінності. Перше: єдине джерело правди про витрати для кожного провайдера, розбите за сервісом, проєктом та середовищем - не тому, що dashboard'и щось виправляють, а тому що суперечки про атрибуцію вщухають, коли всі бачать одні й ті самі цифри. Друге: детекція аномалій, розумніша за поріг - рахунки за хмару за природою шумні, і статичне «попереди мене, якщо понад €X» або спрацьовує постійно, або ніколи; позначати справжні відхилення від власного базового рівня - це робота для ML, а не для cron-завдання й надії. Третє: рекомендації з right-sizing за розкладом - щомісячний список «ці дванадцять інстансів завеликі, ось безпечний менший розмір, ось економія», який хтось переглядає за п'ятнадцять хвилин. Четверте: бюджетні сповіщення з ескалацією - тихе попередження інженеру на 80%, гучніше - тімліду на 100%, бо бюджет, за який ніхто не відповідає, - це просто побажання.
Зверніть увагу, що об'єднує всі чотири звички: вони скорочують цикл від інсайту до дії. У цьому вся гра. Не більше даних - менша відстань між «система помітила» і «людина вирішила». Маленькій команді не потрібна практика FinOps; їй потрібні двадцять хвилин на тиждень, коли рішення про витрати вже добре підготовлені, пріоритизовані заздалегідь і зібрані в одному місці.
Саме це ми й вбудували в Sencai: витрати за сервісом, проєктом та середовищем для кожного підключеного провайдера; аномалії вартості, позначені ML; заплановані рекомендації з right-sizing; бюджетні сповіщення з ескалацією. Цикл від інсайту до дії, стиснутий так, щоб вміститися в standup. А наступний крок у наших планах розвитку - Autopilot - про те, щоб повністю замкнути цей цикл для нудних випадків: автоматичну зупинку позначених dev-ресурсів за розкладом, виконання схваленого right-sizing у вікна технічного обслуговування. Судження залишається за вами; натискання кнопок - не повинне.
Якщо хочете дізнатися, де ви стоїте сьогодні, ось вправа на п'ятнадцять хвилин: витягніть рахунок за минулий місяць від кожного провайдера, яким користуєтесь - включно з тими, про які ви забули. Відсортуйте за сервісом. Обведіть усе, що не можете за десять секунд атрибутувати до функції продукту, яка реально працює. У більшості компаній це коло становить 25-35% від загальної суми. Це не проблема бюджетування. Це просто ентропія - а ентропія дуже, дуже виправна.