Проблема У Частині 1 ми зібрали FinOps-пайплайн на Azure Databricks, який зводить рахунки за інфраструктуру Azure та DBU Databricks в один cost lakehouse у форматі FOCUS. Це працює. Але якщо середовище, в якому він працює, зібрали вручну через Azure portal, ви отримуєте платформу, яку ніхто не може перевірити, відтворити або відкотити. Платформи, зібрані через portal, ламаються тихо. Мережева політика, яку хтось додав під час інциденту, не задокументована. Другий workspace відрізняється від першого в деталях, які ніхто не може назвати.

Проблема Щомісяця ваша платформа Databricks генерує два рахунки. Azure виставляє рахунок за віртуальні машини, локальні SSD, преміум-сховище та мережевий трафік, на яких працюють ваші кластери, тоді як Databricks обліковує споживання DBU у власних системних таблицях. Числа, яке всім насправді потрібне, справжньої вартості окремого робочого навантаження, немає в жодному з них. Тож команди роблять те, що роблять завжди: експортують обидва набори даних в Excel і звіряють їх вручну. Це повільно, це схильне до помилок, і це доводиться повторювати щомісяця, бо гіперскейлери заднім числом коригують білінгові дані.

Проблема Базові дозволи Keycloak надаються за допомогою ролей, присутніх в системних клієнтах. У більшості випадків використовується клієнт realm-management. Однак, наявні дозволи є негнучкими та надають забагато доступу. Ви можете надати користувачу право керувати усіма користувачами в realm або не керувати ніким. У цьому випадку є два можливі сценарії роботи. У першому, лише обмежена кількість розробників має доступ до realm, що робить їх відповідальними за його управління. Або надати доступ кожному розробнику, дозволяючи їм бачити дані ваших клієнтів.