Адміністратори баз даних (DBA) відіграють важливу роль у наших організаціях. Вони керують базами даних, відстежують їхню продуктивність і вирішують проблеми, що виникають. Однак варто розглянути можливість того, що їхня нинішня роль може бути проблемною і що нам потрібно переосмислити, як вони працюють і інтегруються в наші організації. Успішні компанії не мають адміністраторів баз даних. Продовжуйте читати, щоб дізнатися чому.
DBAs ускладнюють командну роботу
Однією з проблем наявності окремої команди DBAs є те, що вона може ненавмисно розділяти інші команди на ізольовані групи, що унеможливлює співпрацю. Давайте розглянемо, чому це трапляється.
DBAs повинні бути в курсі всіх дій у базах даних. Вони повинні знати про кожну зміну, модифікацію та перезавантаження системи. Це вимога суперечить тому, як розробники зазвичай хочуть розгортати своє програмне забезпечення. Розробники зазвичай хочуть просто закачати свій код до репозиторію та йти далі, покладаючись на CI/CD (Continuous Integration/Continuous Delivery) пайплайни для тестів, міграцій, деплойментів та перевірок. Ці пайплайни можуть займати кілька годин, і розробники не хочуть бути ними обтяжені.
Проте цей підхід не дуже добре співвідноситься з тим, як DBAs звикли працювати. DBAs повинні бути в курсі змін і знати, коли вони відбуваються в системі. Це потребує синхронізації між командами, адже DBAs повинні бути залучені до процесу деплойменту. Як тільки DBAs залучаються, вони часто беруть контроль на себе, що може змусити розробників почуватися менш відповідальними.
Ця динаміка призводить до того, що команди стають ізольованими. Розробники відчувають меншу відповідальність, поки DBAs беруть на себе більше контролю. З часом розробники починають перекладати на DBAs відповідальність за зміни в базах даних. Знаючи, що їм потрібно узгоджувати будь-які зміни з DBAs, розробники очікують, що саме DBAs займуться цим. Це створює порочне коло, де розробники стають менш залученими, а DBAs беруть на себе більше відповідальності, що врешті-решт призводить до статусу-кво, де розробники роблять ще менше.
Ця ситуація шкодить всім. Розробники відчувають меншу відповідальність, що призводить до зменшення їх залученості та активності. DBAs стають розчарованими через збільшення навантаження. В кінцевому результаті вся організація витрачає час та ресурси. Успішні компанії намагаються сприяти більшій командній роботі та швидкому розвитку, тому обмежують роль DBAs і дозволяють їм зосередитись на архітектурних проблемах.
Команди не розвивають свої навички
Іншою наслідковою проблемою наявності окремих DBAs є те, що розробники припиняють вчитися. Найефективніший спосіб навчатися — це через практичний досвід, що дозволяє командам досягати значних результатів дуже швидко.
З присутністю DBAs, розробники часто покладаються на їх допомогу. Хоча це корисно, якщо вони навчаються через таку взаємодію, насправді розробники часто перекладають на DBAs свої обов’язки. Як результат, вони перестають вчитися, а робота з базами даних стає для них все більш незнайомою.
Замість цього, нам слід заохочувати розробників до глибшого розуміння і практичного досвіду з базами даних. Для цього розробникам потрібно взяти на себе відповідальність за підтримку і експлуатацію баз даних. Це важко досягти, якщо є окрема команда DBAs, яка несе відповідальність за управління системами баз даних.
Команди надмірно комунікують
Коли DBAs несуть відповідальність, а розробники беруть на себе менше обов’язків, організації починають витрачати більше часу. Кожен процес потребує залучення обох команд. Оскільки командну співпрацю не можна автоматизувати через CI/CD, стає необхідним проведення додаткових зустрічей і формальних комунікацій через квитки чи запити.
Це значно знижує продуктивність. Кожен раз, коли команди повинні коментувати питання, вони витрачають час на пояснення роботи замість того, щоб робити її. Ще гірше, вони змушені чекати відповіді від іншої команди, що призводить до затримок на кілька годин. Коли залучені різні часові зони, цілі дні роботи можуть бути втрачені.
Успішні компанії мають інший підхід
Найкращі компанії обирають інший підхід.
Усі ці проблеми можна легко вирішити за допомогою обмежень для баз даних (database guardrails). Ці інструменти інтегруються в середовище розробників і оцінюють продуктивність бази даних, поки розробники пишуть код. Це значно знижує ризик погіршення продуктивності, втрати даних або інших проблем з продуктивною базою даних після деплойменту.
Крім того, обмеження для баз даних можуть автоматизувати більшість завдань DBAs. Вони можуть налаштовувати індекси, аналізувати схеми, виявляти аномалії і навіть використовувати AI для автоматичного виправлення коду. Це дозволяє DBAs звільнитися від рутинних завдань з обслуговування. Без необхідності контролювати кожен аспект бази даних, DBAs більше не потрібно залучати до процесу CI/CD, що дозволяє розробникам знову автоматизувати свої деплойменти. Більше того, розробники не повинні звертатися до DBAs з кожною проблемою, оскільки обмеження для баз даних можуть самостійно виконувати оцінку продуктивності. Це зменшує навантаження на комунікацію та спрощує робочі процеси команди.
Яке майбутнє у DBAs?
DBAs мають величезні знання та практичний досвід, що дозволяє їм вирішувати найскладніші проблеми. Завдяки обмеженням для баз даних, DBAs можуть зосередитися на архітектурі, загальній картині та довгостроковій стратегії організації.
Обмеження для баз даних не зроблять DBAs застарілими; натомість вони дозволять DBAs досягти більш високого рівня і підняти організацію на нові висоти. Це означає, що не буде більше нудного щоденного обслуговування, і DBAs зможуть брати участь у більш стратегічних ініціативах.
Резюме
Традиційний підхід до використання DBAs призводить до неефективності в організаціях. Команди стають ізольованими, надмірно комунікують і витрачають час на очікування відповідей. Розробники втрачають почуття відповідальності і пропускають можливості для навчання, в той час як DBAs перевантажені щоденними завданнями. Успішні організації дозволяють DBAs працювати над більш важливими проектами і звільняють їх від щоденних завдань.
Перекладено з: Why Successful Companies Don’t Have DBAs