Англійська для PagerDuty OnCall

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

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

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

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

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

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

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

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

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

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

Підтвердження сторінки у командному каналі:

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

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

Запис нотатки передачі:

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

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

• Використовуйте ** acknowledge ** і ** resolve ** точно і ніколи не взаємозамінно — підтвердження мовчить ескалацію, розв’ язання закриває інцидент, а змішування їх створює плутанину щодо того, чи проблема дійсно виправлена.
• Навмисно встановіть ** терміни** для кожного типу попередження і перевіряйте його після подій — попередження, яке постійно переглядає сторінки, щоб побачити щось нетермінове, навчає людей ігнорувати сторінки, що є небезпечним.
• Визначте ** політику ескалації ** явно, коли пропонуєте зміни структури на виклику — “хтось повинен отримати сторінку в кінці” не є політикою; визначений ланцюг з тайм- аутами є.
• Завжди надайте ** підсумкове повідомлення **, навіть коротке, щодо будь- чого, що залишається невирішеним — мовчання під час передачі — це те, як незначна проблема стає несподіваним інцидентом наступної зміни.

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

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

Навигація Nuance: Обробка відгуків і запитів

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

Одним з поширених сценаріїв є отримання коментаря під час перегляду коду. Уявіть, що ви надіслали запит на збирання нової можливості у вашому проекті. Старший інженер залишив коментар: « Цьому розділу може бути корисно дещо переробити; розгляньте можливість використання більш описових назв змінних для поліпшення читабельності ». Зараз буквальний переклад може зосередитись на технічних аспектах переробки, але * метою * є ясність і можливість підтримки. Відповідь просто «Добре» не вирішує основної проблеми. Краще було б сказати: “Дякую, що на це звернув увагу! Згоден; використання більш описових назв безумовно покращить читабельність. Я оновлю його, щоб дотримуватися цих рекомендацій.” Зверніть увагу, як ми підтвердили відгук, висловили згоду і описали конкретні дії. Це демонструє повагу і співпрацю. Аналогічно, коли ви просите допомоги від іншого члена команди через Slack - можливо, потрібно пояснення щодо інциденту - уважно сформулювати свій запит є ключовим. Замість того, щоб сказати «Видалити це», спробуйте «Чи не могли б ви подивитися на цей інцидент? Я намагаюся зрозуміти кореневу причину і мені потрібні рекомендації щодо того, як найкраще продовжувати»

Інша поширена ситуація виникає при ескалації інциденту в PagerDuty. Початковий опис може бути коротким, але як тільки проблема розвивається, точна мова стає критичною. Використання правильного рівня невідкладності — * Низька *, * Середня * або * Висока * — це не просто технічна класифікація; це сигнал комунікації до вашої команди. Чисто і чітко оновлення, наприклад: “Інцидент 12345 - Системний відключення впливає на автентифікацію користувача. Початкове розслідування вказує на потенційну проблему з’ єднання бази даних. Запит на негайну увагу (високий пріоритет) через значний вплив користувача.” демонструє серйозність ситуації без надмірно драматичної мови.

# Example PagerDuty CLI command for creating an incident update:
`pd incident update 12345 --title "Database Connectivity Issue" --description "Further investigation reveals high latency impacting authentication services.  Escalating to Level 2 support." --severity High`

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