Як комунікувати інфраструктурні зміни англійською мовою

Зміни в інфраструктурі несуть ризик. Погано опублікована міграція бази даних або зміна мережі може залишити користувачів збентеженими, інженерів на гарячому, і команди підтримки, переповнені квитками. Ясне, професійне спілкування до, під час і після зміни інфраструктури так само важливо, як і технічне виконання. У цьому повідомленні наведено англійські фрази і структуру, які вам потрібні для ефективного повідомлення про зміни в інфраструктурі.

Ключові фрази

** Планування змін: **

• Ми плануємо вікно обслуговування на четвер, 2 березня, з 02:00 до 04:00 UTC
• Ця зміна проходить через CAB (Change Advisory Board) процес для схвалення
• «Обсяг зміни — це перебудова індексу бази даних на таблиці користувачів.»
• «Ми оцінили 30-хвилинне вікно деградації послуги»

Опис радіусу вибуху:

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

Передача плану відновлення:

• “У нас есть проверенный план возврата. Якщо міграція зазнає невдачі, ми можемо повернутись через 10 хвилин»
• Процедура відновлення задокументована в runbook, посилання на який наведено нижче
• «Ми зробили знімок бази даних за 30 хвилин до початку вікна змін»

** Встановлення очікувань користувача: **

• «Прошу очікувати підвищеної затримки під час вікна обслуговування»
• Деякі користувачі можуть відчувати перервані помилки між 02:00 і 02:30 UTC
• «Сервіс буде недоступний приблизно на п’ять хвилин.»

** Під час і після зміни: **

• Ми будемо публікувати оновлення кожні 15 хвилин в #incidents
• Зміна завершена і всі системи здорові
• Ми бачимо несподівану поведінку і розглядаємо можливість повернення назад»
• “Всі показники номінальні. Ми закриваємо вікно змін»

Як це використовувати на практиці

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

** Дозвільне повідомлення про зміну ** має включати: що змінюється, коли, на який час, хто буде зачеплено, який радіус дії зміни, і який план відновлення. Якщо у вашій організації є CAB (Консультативна рада з питань змін), вам слід надіслати запит на зміни з урахуванням цих відомостей. CAB переглядає ризиковані зміни, щоб переконатися, що вони добре сплановані перед затвердженням.

** Розгортання з нульовим часом простою ** мають свій власний словник. Ви можете сказати: «Ми використовуємо синьо-зелене розгортання, щоб уникнути перерв» або «Ми робимо канарський випуск — ми будемо маршрутизувати 5% трафіку до нової версії і моніторити рівень помилок перед повним розгортанням»

** Під час зміни ** надсилайте структуровані оновлення на ваш канал інциденту або операцій: « 14: 05 UTC — триває зміна, виконується міграція. Не спостерігалося помилок. 14: 23 UTC — Перенесення завершено, виконуються перевірки на надійність. » Це надає інженерам та іншим учасникам проекту чітку картину, не вимагаючи від них запитувати оновлення.

** Після зміни **, завжди надсилати повідомлення про завершення зміни: « Зміна завершена. Всі служби працюють нормально. Затримка повернулася до базового рівня. Відновлення не потрібне. » Якщо щось пішло не так, скажіть це прямо: « Ми зіткнулися з проблемою і виконали відновлення. Служба повністю відновлена. Після смерті буде пост-мортем»

Приклад розмови

** Інженер з платформи (Богдан): ** « Я хотів повідомити про майбутнє обслуговування бази даних. Ми плануємо вікно технічного обслуговування на неділю, 6 липня, з 01:00 до 03:00 UTC. Ми будемо відновлювати індекси в таблиці замовлень, щоб вирішити проблему зниження продуктивності запиту, яку ми бачили»

Подразнитель: “Який радіус дії вибуху, якщо щось не так?”

** Богдан: ** “Радіус вибуху обмежений операціями читання за замовчуванням. Запис продовжить працювати. У нас є перевірений план відновлення — ми можемо відновити з доміграційного знімку менше ніж за 10 хвилин. Ми будемо публікувати оновлення в #platform-ops кожні 30 хвилин під час вікна»

Подразнитель: “Это прошло через CAB?”

Богдан: “Так, це було схвалено на вчорашньому засіданні CAB. Посилання на запит зміни знаходиться в гілки.”

Практичні поради

1. ** Написати імітаційне сповіщення про зміну: ** Виберіть реальну або вигадану зміну інфраструктури (перезапуск служби, перенесення бази даних, оновлення сертифіката TLS) і напишіть повідомлення про передбачувану зміну за допомогою фраз з цього повідомлення. Включити: що змінюється, коли, радіус вибуху і план відновлення.

2. ** Прочитайте справжнє пост-мортем: ** Багато компаній публікують пост-мортем публічно (GitLab, Cloudflare і Stripe є помітними прикладами). Читайте один і визначте, як вони повідомляють радіус вибуху, дії відновлення і часову шкалу. Зверніть увагу на мову, яку вони використовують, щоб бути прозорими, не будучи паніками.

3. ** Вправлятися у оновленні кількості оновлень: ** Під час вікна змін (навіть якщо йдеться про невелике розгортання особистого проекту) вправляйтеся у написанні оновлень стану з часовими рамками, так само, як і у випадку, якщо ви надсилаєте їх на канал команди Slack: « 14: 00 — Почато зміну. 14: 12 — Крок 1 завершено, перехід до кроку 2. 14: 25 — Зміна завершено, всі перевірки пройдено ». Таким чином ви створюєте звичку структурованого спілкування з часом.

Навигація Nuance: Специфічний словник для оновлення інфраструктури

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

Однією з областей, де часто виникає плутанина, є такі терміни, як « радіус вибуху ». Просто сказати « Ця зміна впливає на сервери A- C » недостатньо. Вам нужно сформулировать масштаб потенциального нарушения. Замість цього, розгляньте формулювання: ”* радіус вибуху * цього розгортання поширюється на програми, залежні від цих серверів - конкретно [список вражених служб]. Ми визначили потенційне 15-хвилинне вікно відключення для тестування і активно моніторимо. “Зауважте наголос на “потенціал” і кількісне вираження впливу з часовими рамками. Аналогічно, при обговоренні планів відновлення, уникайте нечітких тверджень на кшталт « Ми відновлюємо, якщо щось не так ». Професійнішим підходом є: « Наш план відновлення передбачає повернення до попередньої версії [назва служби] протягом 10 хвилин після виявлення проблеми, використовуючи наш автоматизований конвеєр розгортання канарій. Ми підтвердили цей процес з CAB і задокументували кроки для ручного втручання, якщо автоматизація зазнає невдачі. ”

Повідомлення про розслаблення і описи PR вимагають однаково точної мови. Простих « Оновлених серверів » недостатньо. Замість цього, корисне повідомлення може бути таким: « Розгортання нової схеми бази даних v2. 3. Це оновлення включає в себе оптимізацію швидкодії і вирішення виявлених проблем з масштабуванням. Сьогодні ми запланували вікно технічного обслуговування з 22:00 до опівночі за ПСТ, щоб зменшити вплив на користувачів. Будь ласка, перегляньте повні деталі в PR #1234. “Включення номера PR забезпечує негайний контекст і відстежуваність. Зверніть увагу на активний голос — він робить дії яснішими (« Ми розгорнули », а не « Розгортання було виконано »). Нарешті, пам’ятайте, що “CAB” (Command, Control, and Communications) - це не просто позначка; це процес. Описуючи вашу взаємодію з CAB, слід вказати: «Отримано схвалення від CAB для розгортання після нашої оцінки ризиків - підтвердження надіслано через канал Slack #infra-updates»