On-Call Handoff English: Фрази для Shift Transitions

Introduction

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

Ключеві слова перед початком

Перед тим, як подивитися на фрази, варто зрозуміти основні слова, які з’ являються у кожному передаванні за викликом.

** Термінологія попереджень та подій: **

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

Термінологія ескалації та процесу:

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

Вербальний переказ

Вербальна передача (особисто, під час дзвінка або за допомогою голосового повідомлення) повинна бути короткою, але повною. Зазвичай він має структурований формат.

** Відкривається — сигнал передачі: **

• «Відправляючи вас о 18:00 UTC — дозвольте мені дати вам швидкий огляд поточного стану.»
• “Я зараз підпишуся. Ось що вам потрібно знати, перш ніж я піду»
• «Швидкий перехід: ми мали тиху зміну, але є одна річ, на яку варто звернути увагу»

** Резюме поточного стану: **

• «Все зараз зелене на панелях управління — немає активних попереджень»
• «Є один відкритий інцидент: підвищений рівень помилок в API платежів, приблизно 0,3% запитів. Він піддається моніторингу, але ще не блокується»
• «Ми отримали попередження раніше цього дня про використання диска на кластері журналювання — це було підтверджено і команда працює над цим, але це ще не було вирішено»

** Активні або відомі проблеми: **

• “Обережно з використанням пам’яті на вузлі-03 - він піднімається з вчорашнього розгортання. Обхідним рішенням є перезапуск робочого процесу, якщо він перевищує 90%. ”
• “Існує відома проблема з чергою повторних спроб webhook — повідомлення доставляються пізно, але не відкидаються. Команда розслідує завтра вранці»
• «Тест відключення бази даних заплановано на 22:00 UTC сьогодні ввечері — очікуйте короткий період підвищеної затримки близько цього часу, але він повинен бути автоматизованим і самовиправним»

Направление эскалации:

• Якщо рівень помилок у платіжках перевищує 1%, ескалуйте до лідера платформи — це Priya сьогодні ввечері»
• “Записник для сценарію відключення бази даних знаходиться в Confluence в розділі On-Call Runbooks > Database. Він прокладає вам шлях через вручну кроки, якщо автоматичне відключення не вдається»
• Якщо ви отримаєте попередження від стороннього платіжного шлюз, перевірте сторінку стану перш ніж перевірити кого-небудь — вони часто мають свої власні інциденти

Підсумкове письмове повідомлення

Підписана передача (в Slack, електронній пошті або документі передачі) надає можливість вхідному інженеру переглянути контекст у своєму темпі і звернутися до нього під час зміни.

** Стандартна структурна структура: **

** Передача — [Дата] [Час] UTC**

** Поточний стан: ** Всі системи зелені / Один активний інцидент / Дві відомі проблеми

** Відкритий інцидент: **

• «Є один відкритий інцидент: підвищені помилки 5xx на службі аутентифікації (Інцидент #4412, відкритий о 14:32 UTC). Поточне значення: приблизно 0, 5% спроб входу зазнають невдачі. Решено проблему: користувачі можуть успішно повторити спробу. Корінь причини під розслідуванням команди auth

** Відомі проблеми для моніторингу: **

• «Дивись пам’ять на app-server-02 — вона коливається з випуску у вівторок. Не потрібно жодних дій, якщо вона не перевищує 85 %

** Запрошені дії: **

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

Контакти для ескалації:

• Процитовано 2014-04-24.  «Platform on-call tonight: Priya (+44 7xxx xxxxxx)»
• Процитовано 2011-03-14.  Database on-call: Marcus (Slack: @marcus.h)

** Примітки щодо зміни: **

• «Відповідь версії 3.1.4 запланована на 23:00 UTC. Записки про випуск знаходяться в каналі #deployments

Що робити, якщо раптом загорівся флагшток

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

Прапор невідкладно:

• Інциденти з активним впливом на клієнтів: «Це впливає на користувачів зараз — приблизно 200 користувачів не можуть увійти»
• Проблеми, які, ймовірно, ескалуються без дій: « Якщо це не буде вирішено протягом наступних двох годин, диск заповниться і служба ведення журналу припинить запис»
• Надходження високого ризику подій: «Є заплановане вікно обслуговування на 02:00 UTC, що вимагає вручну підтвердження — не пропустіть його»

Прапорець для інформації:

• Розв’язані інциденти без постійного ризику: «Ми мали короткий пік затримки о 11:00 UTC — він розв’язався протягом 8 хвилин, не потрібно жодних дій»
• Відомі проблеми низької тяжкості: «Граф панелі для затримки API показує трохи неправильні дані — це помилка дисплея, основні дані в порядку»

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

Term	Definition
outstanding alert	An alert that has fired and has not yet been resolved or dismissed
pending investigation	An issue that has been identified but is not yet understood or resolved
workaround in place	A temporary measure that keeps the system functioning while a fix is being developed
escalation path	The sequence of contacts to notify if an incident cannot be resolved at the current level
runbook	A documented procedure for handling a specific operational scenario
known issue	A problem the team is aware of and has consciously accepted, usually temporarily
handoff	The act of transferring on-call responsibility from one engineer to another
shift notes	A written record of events and context from the current on-call shift

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

1. ** Використовуйте формулу: стан + контекст + потрібна дія. ** Кожен елемент у вашому передаванні повинен відповідати цій формулі. « Пам’ ять на вузлі- 03 підвищена (стан) — вона зростає з часу розгортання у вівторок (контекст) — перезапустити робочий процес, якщо вона перевищить 90% (потрібна дія) »
2. ** Відрізняйте « спостерігати » від « діяти ». ** Скажіть « це інформаційне » або « не потрібна дія » для елементів з низьким пріоритетом, і « це потребує вашої уваги » або « позначити це, якщо станеться X » для активних питань. Не змушувати вхідного інженера вгадати, до якої категорії належить елемент.
3. ** Завжди включайте шлях ескалації. ** Навіть якщо зміна тиха, прибувший інженер повинен знати, кому дзвонити. Це особливо важливо для інженерів, які недавно почали працювати на ротації.
4. ** Встановити час для всіх подій. ** Під час написання резюме передачі включайте час UTC для кожної події. Инженеры в разных часовых поясах будут вам благодарны, и это сделает реконструкцию хронологии после инцидента намного проще.

Conclusion

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