Чи буде ваша база даних готова, якщо швидкість розробки збільшиться в рази?

Інструменти, що використовують допомогу штучного інтелекту, збільшили швидкість і зменшили вартість виробництва коду. Однак керівники бізнесу ставлять під сумнів, чому ця ефективність не перетворюється на вищу інновацію і швидшу час до виходу на ринок. Натомість того, щоб прискорити весь цикл поставки, цей сплеск швидкості просто виявив крихкість існуючих процесів зміни бази даних.

За останні десять років відповідь на питання “Як ми можемо рухатися швидше?” полягала в тому, щоб створити кращі конвеєри, інвестувати в CI/CD і змістити ліворуч тестування. Ці інвестиції окупилися – код програми рухається зі швидкістю, яку можна порівняти з швидкістю руху коду в зрілих інженерних організаціях. Однак ці здобутки не були відчутні однаково по всьому технологічному стеку. База даних часто розглядалася як особливий випадок; захищений актив, який вимагає іншого стандарту догляду, повільніших процесів і ручного нагляду. Були хороші причини для того, щоб така схема розвинулася, оскільки бази даних містять дані, на яких працює бізнес, і помилки можуть бути катастрофічними. Хоча обережність колись здавалася розумною, вартість цієї обережності змінилася. При збільшенні тиску на адміністраторів баз даних і операційних команд для внесення змін до бази даних з такою ж швидкістю, з якою розробники тепер можуть писати код, розбіжність у стеку стала зобов’язанням. Ці команди не можуть впоратися, і зміни бази даних тепер вбивають швидкісну перевагу, надану інструментами, що використовують допомогу штучного інтелекту. Вирішення однієї обмеження – часу, необхідного для написання коду, – просто підкреслило наступну瓶頸 у процесі. Це система мислення, яку було привнесено до життя, і результатом є все більш болюча тертя для підприємства.

Швидкість і контроль не є протилежностями. Однак спосіб, яким більшість організацій керують зміною бази даних, поводиться так, як якщо б вони були.

Традиційна модель керування базою даних була розроблена для світу квартальних випусків. Запити на зміну, комітети з затвердження, ручні цикли перевірки, плани скасування, написані до розгортування, яке відбувалося чотири рази на рік. Ніщо з цього не є внутрішньо неправильним. Це був ризик-менеджмент, який розвинувся, щоб відповідати часу, доступному в час між розгортуваннями. Проблема полягає в тому, що темп розгортування змінився, і для більшості організацій підхід до керування не змінився. Команди очікують безперервної поставки, але все ще направляють зміни бази даних через процеси, створені для іншої епохи. Результатом не є безпека. Результатом є тертя, обхідні шляхи, і зростаючий клас “малих” змін бази даних, які обходять керування повністю, оскільки формальний процес надто повільний, щоб бути практичним.

Це місце, де живе справжній ризик.

Коли керування надто повільне, щоб його використовувати, люди перестають його використовувати. Зміни схеми застосовуються безпосередньо у виробництві. Гарячі виправлення виходять без контролю версій, і з добрими намірами провести їх через офіційне розгортування наступного разу, але це не відбувається, оскільки люди зайняті. Ручні кроки, які мали бути безпечним засобом, стають тим, навколо чого люди обходять, коли вони перебувають під тиском. І тиск у поставці програмного забезпечення є станом за замовчуванням.

Відповідь не полягає в тому, щоб сповільнити конвеєр. Це полягає в тому, щоб перемістити керування всередину нього.

Організації, які вирішили цю проблему, не зробили цього, знизивши свої стандарти. Вони зробили більш важку роботу, щоб зробити керування достатньо швидким, щоб бути шляхом найменшого опору. Зміни схеми, що контролюються версіями, автоматичне виявлення дрейфу, детерміновані перевірки політики, вбудовані в конвеєр CI/CD, а не застосовані як ворота в кінці. Хоча інструменти, що використовують допомогу штучного інтелекту, є ймовірнісними – пропонуючи пропозиції на основі моделей – керування повинно залишатися детермінованим, щоб бути ефективним. Використовуючи передбачувані і повторювані перевірки, ви забезпечуєте, що кожна зміна є аудитованою і відповідає стандартам безпеки до того, як вона коли-небудь досягне виробництва. Затвердження все ще відбувається. Історія аудиту все ще існує. Але це відбувається в тому ж потоці, що і все інше, а не як окремий, повільніший процес, який знаходиться поза ним.

Це має значення з причини, що виходить за рамки продуктивності розробників. Вимоги до відповідності не стають легшими. Комбінація GDPR, DORA (Акт ЄС про цифрову оперативну стійкість) і зростаючого ряду галузевих регуляцій означає, що керування базою даних все частіше стає юридичним і регуляторним питанням, а не лише оперативним. Організації, які не можуть продемонструвати слідову, аудитовану історію зміни бази даних, вразливі способами, які стають матеріальними. Аргумент про те, щоб вбудувати керування в конвеєр, не полягає в тому, що це робить поставку швидшою. Це те, що робить відповідність слідовою у масштабі.

Штучний інтелект посилює терміновість.

Поточна хвиля інструментів, що використовують допомогу штучного інтелекту, робить цю проблему більш гострою, а не менш. Коли розробники можуть генерувати і ітерувати)application-логіку швидше, ніж раніше, база даних стає більш очевидною瓶頸ом відносно всього, що її оточує. Однак існує другий порядок ефекту, який менше обговорюється. Інструменти, що використовують допомогу штучного інтелекту, дуже хороші в генерації application-логіки. Вони менш хороші в розумінні довгострокових наслідків змін схеми в складній, живій базі даних. Комбінація швидкості розробки додатків і пропозицій змін схеми, згенерованих штучним інтелектом, без зрілого керування є саме тим тиском, який створює інциденти. Швидкість без структурних поручнів створює умови для помилок, які відбуваються швидше.

Організації, які будуть успішно орієнтуватися в цьому, будуть тими, які вважають керування базою даних першочерговим інженерним питанням, а не післядумом про відповідність. Це означає, що контроль версій для схеми бази даних є непоговорним замовчуванням, і автоматичне тестування обробляє звичайні перевірки, щоб ручний нагляд міг зосередитися на високоризикованих, високосудових змінах, а не ставати пізнім瓶頸ом. Нарешті, це означає виявлення дрейфу, яке ідентифікує розходження до того, як воно спричинить інцидент.

Більшість корпоративних володінь робить це складніше, ніж повинно бути.

Є складна реальність, яка існує поряд з більшою частиною цих спостережень. Більшість корпоративних володінь баз даних не є зеленими полями. Вони представляють десятиліття накопичених змін схеми, що працюють на多численних платформах СУБД, деякі з яких знаходяться на місці, а деякі – в хмарі, з різними ступенями документації і племінних знань, розподілених по командах, які змінилися багато разів. Розмова про модернізацію часто припускає чисту початкову точку, якої більшість організацій не мають. Це місце, де виклик фактично є найбільш гострим і часто перешкоджає прогресу. Чи то мета полягає в тому, щоб підтримувати інновації, очистити і перенести дані для штучного інтелекту або покращити оперативну стійкість; це повертається до тих самих речей. Питання не полягає в тому, як побудувати ідеальну практику DevOps для бази даних на новій системі. Питання полягає в тому, як ввести значуще керування на складному, спадковому володінні без зупинки бізнесу під час цього процесу.

Поступове, вбудоване в конвеєр керування є єдиною практичною відповіддю на це питання. Вам не потрібно переплатформувати все володіння, перш ніж ви зможете покращити свої практики керування змінами. Сучасні інструменти, такі як Redgate Flyway, існують для того, щоб полегшити базу даних як瓶頸 і почати з змін, які робляться сьогодні, в конвеєрах, які вже існують, і побудувати все з цього.

Організації, які переможуть у зростанні протягом наступних п’яти років, не будуть тими, які мають найчистіші володіння. Вони будуть тими, які виправили, як зробити зміну довірчою, з темпом, який вимагає бізнес, по володінню, яке вони фактично мають.

Це проблема, яку варто вирішити. І це можна вирішити.