Як написати оголошення про заморожування вікна міграції даних англійською мовою

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

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

** Заморозка змін (або замороження запису) ** — визначений період часу, протягом якого певні зміни, розгортання або операції запису буде призупинено, щоб зменшити ризик під час чутливої операції.

• “Ми вводимо заморожування змін з п’ятниці 18:00 до неділі 9:00, поки триває перенесення.” *

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

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

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

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

• “У нас є перевірений план відновлення, який відновлює попередню схему протягом п’ятнадцяти хвилин, якщо щось не так під час переходу.” *

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

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

Проголошується заморожування вікна

• «Ми будемо запускати міграцію даних на базі даних замовлень, і ми вводимо заморожування змін з п’ятниці о 6 вечора до неділі о 9 ранку UTC»
• «Під час цього вікна, будь ласка, не розгортайте ніяких змін, що записують до таблиць orders або order_items, включаючи міграції, заповнення або вручну виправлення даних.»
• «Всі інші служби не постраждали і можуть розгортатися як звичайно — це заморожування застосовується спеціально до бази даних замовлень і будь-якої служби, яка записує в неї»

Що можна і чого не можна робити

• «Читання повністю підтримуються протягом заморожування — панелі управління, звіти і API читання продовжать працювати нормально»
• Якщо у вас є критичний оновлення, яке має вийти в цьому вікні, будь ласка, спочатку зв’яжіться з #incident-response, щоб ми могли оцінити ризик перед його схваленням
• «Заплановані завдання, що записують до зачеплених таблиць, включаючи нічні пакетні завдання, будуть автоматично призупинені і відновлені, як тільки заморожування підніметься»

Розробка та реалізація графічного інтерфейсу

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

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

1. ** Вказуйте точні межі, а не загальні рекомендації. ** « Немає записів до orders або order_items » набагато ясніше, ніж « будь ласка, будьте обережні з базою даних », і запобігає вгадуванням людей, що знаходиться в обсязі.
2. ** Явно відокремити те, що все ще дозволено, від того, що не дозволено. ** Підтвердження того, що читання і не пов’ язані служби не будуть змінені, не дозволяє людям заморожувати роботу, яку не потрібно було призупиняти.
3. ** Назва контакту для виняткових випадків. ** Вказання певного каналу або особи для надзвичайних запитів на латки зберігає заморожування неушкодженим, залишаючи безпечний шлях для справжніх надзвичайних ситуацій.

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

1. Написати повідомлення про заморожування вікна для двогодинного перенесення бази даних, яке відбудеться у вівторок вночі, з вказанням точних часів початку і завершення.
2. Сформулюйте речення, у якому буде пояснено, що під час заморожування доступні лише дії з читання, а не запису.
3. Напишіть одне речення, у якому поясните, що команда повинна робити, якщо їй потрібно розгорнути термінову латку під час заморожування.

Навигація Nuance: Phrasing for International Teams (англійською)

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

Однією з поширених пасток є припущення, що всі розуміють поняття «заморожування», що означає абсолютний застой. Використання більш описової мови може значно поліпшити розуміння. Замість того, щоб просто сказати: « База даних буде заморожено з 9 ранку до 12 вечора », розгляньте можливість написання цього повідомлення у вигляді: « Під час цього періоду * всі безпосередні зміни до таблиць бази даних буде призупинено * ». Таким чином, ви зможете розібратися у змісті повідомлення і уникнути будь- якого враження, що користувачі все ще можуть отримати доступ до системи або взаємодіяти з нею. Крім того, визнання того, що різні культури підходять до комунікації по-різному, є життєво важливим. Деякі команди можуть віддати перевагу більш детальні пояснення причин заморожування - коротка записка про перевірки цілісності даних або обслуговування системи, що виконується - в той час як інші цінують короткі інструкції.

Розглянемо деякі практичні приклади. У коментарі перегляду коду, замість того, щоб сказати « Заморозити цю функцію під час перенесення », що може звучати різко, ви можете написати: « Щоб забезпечити послідовність даних під час процесу перенесення, будь ласка, * призупиніть будь- які прямі зміни функцій * до 10: 30 ранку за часом Північної Америки ». Або, у повідомленні Slack, у якому повідомляється про вікно для команди розробників, не вказуйте просто « Заморозка перенесення — 21: 00- 24: 00 ». Більш уважнішим підходом було б: “Привіт всім! Ми плануємо заморожувати вікно міграції даних з 9: 00 ранку до 12: 00 вечора за Північноамериканським часом. * Під час цього часу ми будемо виконувати критичні оновлення бази даних, які потребують виключного доступу.* Будь ласка, заплануйте свою роботу відповідно до цього і повідомте мене, якщо ви очікуєте конфліктів. » Нарешті, коли ви пишете опис запитів на захоплення для самої міграції, чітко вкажіть наслідки: « Ця PR вводить зміни до скрипту міграції даних. * Тимчасове заморожування записів бази даних буде діяти з 9: 00 ранку до 12: 00 вечора за Північноамериканським часом, щоб забезпечити цілісність даних. * »

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