Як пояснити Schema Migration Rollback в англійській мові

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

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

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

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

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

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

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

Звичайні фрази

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

Приклади висловлювань

Пояснення щодо відновлення у оновленні події:

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

Позначати втрату даних чесно:

• “Щоб бути прозорими: є 20-хвилинне вікно втрати даних. Замови створені в цьому вікні з використанням нового поля tax_region покажуть це поле як нульове в майбутньому — ми перехрещуємо журнали, щоб вручну відновити його, де це можливо. ”*

Пояснення, чому відновлення було безпечним: “Це відновлення було низькоризичним, особливо тому, що ми розробили міграцію з вікном сумісності — обидві версії схеми були чинними одночасно, отже жодна служба не залежала виключно від нової колонки.”

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

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

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

1. Написати пояснення щодо відновлення, яке відрізняє чистий перенесення від перенесення з вікном втрати даних.
2. Описати, що робить відновлення під час перенесення складнішим за стандартне відновлення.
3. Пояснити, що таке вікно сумісності і чому воно робить повернення безпечнішим.

Наприклад, англійська мова має особливі слова для не-індіанців

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

Розглянемо типовий сценарій: ви реалізували нове поле для профілів користувачів, але під час тестування ви усвідомили, що це поле вводить невідповідності з існуючими запитами на звіти. Ви вирішили скасувати зміну. Замість того, щоб просто сказати «Я повернув назад поле профілю», більш ефективним підходом було б використовувати такі фрази, як: «Після ретельного тестування ми виявили несумісність між нововведеним полем user_profile.date_of_birth і нашою основною системою звітів. Щоб зменшити потенційне пошкодження даних і забезпечити послідовну точність звітів, я відновив зміну схеми. Це означає, що стовпчик date_of_birth тепер повертається до свого початкового визначення. ” Зауважте, як це пояснення включає * чому * дію було вжито – несумісність – і підкреслює наслідки – зменшення пошкодження даних. Це демонструє активний підхід, який створює довіру з вашою командою.

Іншою корисною фразою під час обговорення сценаріїв відновлення є « зберегти цілісність даних ». Цей термін, зазвичай використовується в контексті баз даних, сигналізує про прихильність до точності і надійності. Ви також можете використовувати такі фрази, як «як застережний захід» або «щоб уникнути потенційних проблем на нижньому рівні», які підкреслюють серйозність ситуації, не звучачи надто тривожно. Під час написання опису PR, чітко зазначте «Це відновлення вирішує критичну проблему, виявлену під час тестування» демонструє відповідальність і професіоналізм. Пам’ятайте, що чіткість є найважливішою; краще перебільшувати пояснення, ніж ризикувати нерозумінням.

Наконец, не бойся признать, что это был неожиданный исход. Фрази на кшталт « Ми зіткнулися з непередбачуваним викликом під час процесу міграції » або « Це вимагало реактивної корекції нашої схеми » можуть побудувати прозорість і показати, що ви знаєте про потенційні проблеми. Це цілком прийнятно - і часто цінується - демонструвати навчання на помилках. Спробуйте чітко описати, * що * було скасовано, * чому * це було необхідно скасувати, і які кроки зараз робляться, щоб запобігти подібним випадкам у майбутньому. Це демонструє не тільки технічну компетентність, але також прихильність до спільного вирішення проблем у вашій команді.