Як обговорювати міграції баз даних на зустрічі

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

Ключовий словник

** Зміна схеми ** — зміна структури бази даних, наприклад, додавання стовпчика, зміна типу даних або створення нової таблиці. “Це зміна схеми, а не просто зміна даних — ми додаємо новий обов’ язковий стовпчик до таблиці замовлень.”

** Обратно сумісна міграція ** — міграція, яка не порушує існуючий код або клієнтів, які ще не були оновлені. “Ми розробили це як зворотньо сумісну міграцію — старий код програми продовжить працювати навіть до того, як його оновлять для використання нової колонки.”

** Міграція без перерв ** — міграція, яку виконують без переведення програми у автономний режим, зазвичай, за допомогою багатокрокових, поступових змін. “Ми робимо це як нульовий перехід в три фази, а не одну велику зміну, яка вимагає вікна обслуговування.”

** Заповнення ** — процес заповнення нового або зміненого стовпчика даними для існуючих рядків, який часто виконується як завдання у фоновому режимі.

• “Після додавання стовпчика ми запустимо завдання заповнення на ніч, щоб заповнити рядки історії, перш ніж зробити стовпчик обов’ язковим.” *

** План відновлення ** — документовані кроки, які слід виконати для скасування перенесення, якщо щось не так, зокрема, наскільки далеко назад можна повернути зміну.

• “Наша схема відновлення дозволяє повернути зміни у схемі протягом першої години, але не після початку завдання відновлення, яке вилучає стару колонку.” *

** Вікно обслуговування ** — запланований період, ідеально, з низьким рівнем навантаження, під час якого буде виконано більш ризиковану зміну з меншими наслідками, якщо щось не спрацює. “Ми запланували вікно технічного обслуговування на 2 години ночі в суботу, коли трафік найменший.”

** Цілісність даних ** — коректність і послідовність даних, основна проблема під час виконання перенесення, яке торкається існуючих записів.

• “Наша найбільша проблема з цією міграцією — це цілісність даних — нам потрібно правильно перетворити всі існуючі рядки, а не лише нові.” *

** Блокування (блокування таблиці) ** — механізм бази даних, який може блокувати читання або запис під час певних операцій зі схемою, що є поширеною причиною відключень, пов’ язаних з перенесенням.

• “Цей тип додавання стовпчиків вимагає блокування таблиці у нашому рушії бази даних, отже, нам слід запускати його під час низького рівня навантаження, щоб уникнути помітного уповільнення.” *

Пояснення плану команді

• “Ми розділяємо це на три розгортання: додаємо нульовий стовпець, заповнюємо існуючі рядки, а потім робимо його обов’язковим. Кожен крок незалежно безпечний для повернення назад»
• Сама міграція повинна тривати менше двох хвилин, але завдання заповнення буде працювати у фоновому режимі протягом декількох годин
• «Ми вибрали онлайн-інструмент зміни схеми, щоб уникнути блокування таблиці, оскільки ця таблиця отримує постійний трафік»

Відповідає на запитання учасників

• «Що станеться, якщо щось не так під час міграції?» — «У нас є план відновлення на першу годину. Після початку заповнення, відновлення стає складнішим, тому ми зробимо паузу і переоцінимо перед цим кроком»
• «Чи це призведе до перерви?» — «Ні, це розроблено як міграція з нульовим часом перерви — програма продовжує працювати протягом усього»
• «Наскільки впевнені ми в часовій шкалі?» — «Ми перевірили цей точний шлях міграції проти копії виробничих даних, тому оцінка повинна бути правильною, але ми побудували буфер для заповнення»

Збільшення ризику

• «Я хочу попередити, що ця міграція торкається нашого найбільшого столу — я б хотів, щоб другий інженер переглянув план відновлення, перш ніж ми продовжимо»
• «Враховуючи розмір заповнення, я б скоріше розділив його на менші партії, ніж запустив його як одне довге завдання, яке могло б закінчитися»
• «Я не можу запустити це без вікна обслуговування, навіть якщо це технічно нульовий час простою — радіус вибуху, якщо щось не так, занадто великий»

Професійні поради

1. ** Розрізняйте зміни схеми від змін даних чітко. ** Зацікавлені сторони часто об’ єднують ці дві зміни, але вони мають дуже різні профілі ризику.
2. ** Завжди вкажіть план відновлення, навіть коротко. ** “Ми можемо відновити за годину” заспокоює кімнату набагато більше, ніж чисто оптимістичний опис щасливого шляху.
3. **Оцініть ризик за радіусом вибуху і оборотністю, а не лише ймовірністю. ** “Нізкий ризик, але важко скасувати” - це зовсім інше твердження, ніж “низький ризик, легко оборотний”

Практичні вправи

1. Поясніть менеджеру продукту у 3- 4 реченнях різницю між зміною схеми і заповненням даних.
2. Напишіть коротке резюме плану відновлення (4- 5 речень) для перенесення, яке додасть потрібний стовпчик до великої таблиці.
3. Написати відповідь на запитання « Чи призведе це до перерви у роботі? » для перенесення, яке ви виконуєте за допомогою онлайнового інструменту зміни схеми.

Навигація нюансів: фрази для ясності при міграції баз даних

Міграції баз даних часто є складними проектами, повними потенційних проблем. Успішне повідомлення про обсяг роботи, пов’ язані ризики і запропоновані вами рішення вимагає ретельної фрази - особливо при співпраці між командами або презентації нетехнічним зацікавленим сторонам. Це не просто про те, що ви робите; це про те, як ви це говорите. Розглянемо деякі типові сценарії, де точна мова може зробити різницю між плавним переходом і значною головною болем.

Одна з найчастіших ситуацій виникає під час перегляду коду. Уявіть, що ви отримали такий коментар на запит на витягування: «Ця міграція здається ризикованою. Чи можете ви розкрити вашу стратегію відновлення? » Хороша відповідь не просто « У мене є ». Замість цього, намагайтеся дати щось на зразок « Звичайно. Ми реалізували багатоетапний розгортання з детальним моніторингом на кожному кроці. Спочатку ми застосуємо зміни до невеликої підмножини користувачів — приблизно 5 % — і уважно спостерігатимемо за такими показниками продуктивності, як затримка запиту і частота помилок. Якщо все виглядає стабільно, ми поступово збільшимо масштаб до повного розгортання. Процедура відновлення полягає у поверненні до попередньої версії схеми за допомогою нашої системи керування базами даних (pg_restore у цьому випадку), про що йдеться у документації [посилання на документацію]. Також ми налаштували попередження про будь- які значні відхилення від базової продуктивності. Зауважте, що використання таких термінів, як « багатоетапне розгортання », « докладне спостереження », і посилання на певні інструменти (наприклад, pg_restore ) демонструє ретельний підхід.

Інша ситуація може включати пояснення міграції менеджеру продукту в каналі Slack. Отримавши терміново необхідний запит на оновлення критичної функції — скажімо, сторінки профілю користувача — ви можете відповісти: « Добре, ми можемо безумовно включити це до наступної міграції бази даних. Однак, враховуючи масштаб даних профілю і його вплив на продуктивність, нам потрібно буде діяти обережно. Ми пропонуємо поетапний підхід — спочатку перенесення основних полів, а потім менше доступних атрибутів. Це мінімізує перерви і дозволяє нам ретельно перевірити інтеграцію перед повним її розгортанням. Ми також будемо активно спілкуватися з вами протягом усього процесу, регулярно надаючи оновлення про прогрес і будь-які потенційні перешкоди. » Використання таких фраз, як «проводьте обережно» і «поетапний підхід» передають відповідальний підхід.

Нарешті, розгляньте можливість створення опису PR для завдання перенесення. Краткий і інформаційний опис є обов’ язковим. Замість простого вказівки « Міграція бази даних — профілі користувачів », спробуйте: « Ця PR реалізує міграцію даних профілю користувача до нової версії схеми. Міграція використовує поетапну стратегію розгортання, починаючи з 1% вибірки і розширюючи на основі успішної перевірки продуктивності. Ми задокументували процедуру відновлення в [посилання] і налаштували панелі моніторингу для відстеження ключових показників у реальному часі. Ця зміна призначена для поліпшення швидкодії і масштабованості запиту. » Включення певних деталей — відсоток розгортання, документація щодо відновлення і налаштування моніторингу — створює довіру і демонструє прихильність до стабільності. Пам’ятайте, чітке спілкування не тільки про точність; це про будівництво довіри і забезпечення того, щоб кожен розумів * чому * ви робите те, що робите.