Повний посібник з англійської для DevOps- та SRE-інженерів

Англійська мова для інженерів і вчених

DevOps і Site Reliability Engineering є дисциплінами, де якість комунікації безпосередньо впливає на надійність системи. Неоднозначне оновлення інциденту може призвести до дублювання спроб зменшення, що робить відключення гіршим. Погано написаний постмортальний висновок, який передбачає звинувачення, а не визначає системні причини, може отруїти командну культуру. Керівництво з роботи з неясними кроками змушує чергового інженера втрачати дорогоцінні хвилини під час виробничого інциденту о 3 годині ранку.

Мова DevOps і SRE є високо спеціалізованою. Вона включає в себе коротку, точну мову інциденту Slack мостів, структуровану розповідь пост-смертних документів, формальний словник SLA і SLO контрактів, процедурну мову runbooks, і переконливу мову, що використовується при аргументуванні інвестицій надійності в бізнес-термінах. Кожен з цих регістрів вимагає іншого словника і різних норм.

Крім того, ролі DevOps і SRE є одними з найбільш глобально поширених в технологіях. Постійні ротаційні рейси по континентах. Інциденти мостів об'єднують інженерів з багатьох країн. Сховище інфраструктури як коду переглядається розподіленими командами. Рішення платформи документуються в RFC, які читаються інженерними організаціями в багатьох часових поясах. У всіх цих контекстах англійська мова є операційною мовою.

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

Розділ 1: Мова відповіді на інциденти

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

Зв'язок з мостом інциденту

Міст інциденту (канал Slack, дзвінки Zoom або War Room, де керується інцидентом) має певні норми спілкування. Визначайте факти, а не гіпотези — якщо ви не позначили щось як гіпотезу: « Процесор бази даних працює на 97% — ми досліджуємо кореневу причину » проти « Я думаю, що у базі даних є проблеми ». Звіт змінюється негайно: « Гіпотеза: розгортання о 14: 32 призвело до регресії » / « Підтверджено: відновлення розв’ язує проблему »

Ролі інциденту мають певні англійські назви: Командир інциденту (IC) координує відповідь і має остаточну владу щодо прийняття рішень; Лідер зв’ язку пише зовнішні оновлення стану; Лідер технічного обслуговування досліджує і впроваджує виправлення; Співробітник з документації документує часову шкалу. Коли ви приймаєте роль, оголошуйте про це: « Я приймаю роль IC ». Коли ви отримуєте результат: « Визначення: рівень помилок у службі оплати піднявся до 4% о 14: 35 — збігається з розгортанням 14: 32 ». Під час ескалації: « Ескалація до команди з баз даних — мені потрібен адміністратор бази даних на цьому мосту зараз »

Оновлення стану під час інциденту виконуються за шаблоном: поточний стан (погіршено / не працює / досліджується / зменшено / вирішено), вплив (на яких користувачів/ служби впливає інцидент, які симптоми можна спостерігати), поточна дія (що робити зараз), і ETA, якщо відомий. « Оновлення: служби частково погіршені. Клієнти, які намагаються оформити замовлення, бачать помилку 502 приблизно 15% часу. Ми відклали розгортання на 14:32 і здійснюємо моніторинг. ETA до повної роздільної здатності: ~10 хвилин»

Розвиток мови і мовлення

Інциденти класифікуються за тяжкістю (часто SEV1-SEV4 або P1-P4). Мова змінюється з тяжкістю: мова SEV1/P1 є короткою і невідкладною; мова SEV4/P4 більш виміряна. Поширені шаблони: «Заявка SEV1 — всі руки на палубі.» / «Зниження до SEV2 — підтверджено, що вплив на клієнта відсутній.» / «Ескаляція до SEV1 на основі впливу клієнта, що перевищує 5%.» / «Пейджинг на виклик для [назва команди] — потрібно уважно вивчити метрику бази даних»

2-е видання: «Невідома історія та культура»

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

Невідома мова

Беззаперечне постмортне письмо означає зосередження на системах і процесах, а не на окремих помилка. Ключовим методом є використання пасивних конструкцій і системного обрамлення: замість « Джон розгорнув без запуску тестів », напишіть « Розгортання не було заблоковано конвеєром CI, незважаючи на невдалі тести — конвеєр було неправильно налаштовано, щоб дозволити вручну перезаписувати ». Замість « Інженер у черзі пропустив попередження », напишіть « Поріг попередження було встановлено занадто високо, щоб вчасно виявити погіршення — попередження було викликано через 12 хвилин після початку впливу. »

Це не нечесність — це перенаправлення уваги на властивості системи, які зробили можливою помилку. Питання, яке ставить невинний постмортем, це не «хто це зробив?», а «чому це могло статися?» Ключові фрази: «Система дозволила X статися, тому що…» / «Захист, який повинен був запобігти X, не був встановлений, тому що…» / «Фактор, що сприяв: підручник не включав сценарій, де … »

Мова і структура

Стандартна постмортальна записка включає: Резюме (один абзац, проста англійська, без жаргону — написано для нетехнічного читача), Вплив (хто був вражений, на скільки часу, в якому масштабі), Часова шкала (хронологічні події з часовими штампами UTC, пасивний або активний голос, фактичні), Аналіз кореневої причини (системний «чому») і Елементи дії (спеціальні, призначені, з датами закінчення). Записи на часовій шкалі: « 14: 32 UTC — Розгортання v2. 1. 4 перенесено до виробничого режиму ». / « 14: 35 UTC — Частота помилок у / checkout зросла до 4% ». / « 14: 41 UTC — Перший звіт клієнта, отриманий через службу підтримки ». Корінь причини: « Корінь причини: відсутній індекс бази даних спричинив збільшення затримки запиту на 300% під час виробничого навантаження. Індекс не був доданий як частина міграції, тому що середовище тестування продуктивності не мало репрезентативного обсягу даних. "

Розділ 3: CI/CD Pipeline Communication

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

Стан конвейєра і мова помилок

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

Флакі- тести є особливою категорією: тести, які « проходили з перервами », « зазнавали невдач недетерміністично » або були « залежними від середовища ». Стандартне лексичне позначення: «Цей тест є флакі — він зазнає невдачі приблизно 20% часу через умову перегонів у налаштуванні тесту. » / « Я пропускаю цей тест і відкриваю квиток, щоб виправити флакі. » / « Запуск CI зазнав невдачі через проблему з інфраструктурою, а не проблему з кодом — я перезапускаю. »

Повідомлення про розгортання

Оголошення про розгортання (в Slack, електронній пошті або журналі розгортання) слідують стандартному шаблону: що розгортається, в яке середовище, з якої версії до якої версії, в який час, хто розгортає і план відновлення. «  Розгортання v2.3.1 до виробництва о 15:00 UTC. Зміни включають [посилання на нотатки до випуску]. План відновлення: повернення до v2.3.0 — відновлення займає приблизно 3 хвилини. @team, будь ласка, стежте за панеллю помилок протягом 15 хвилин після розгортання."

Розділ 4: SLO, SLA & Error Budget дискусії

SLO (Service Level Objectives), SLA (Service Level Agreements) і бюджети помилок є основними концепціями підходу SRE до надійності. Мова навколо них точна, числова, і часто використовується як в технічному, так і в бізнес-контексті — вам потрібно мати змогу пояснити ці поняття інженерам, а також менеджерам продуктів і керівникам.

Сло і сла словник

SLI (індикатор рівня обслуговування) — це вимірювання: « Наш SLI для доступності — це відсоток запитів, які повертають код стану 2xx ». SLO — це ціль: « Наш SLO — це 99, 9% доступності протягом 30- дібового періоду ». SLA — це договірне зобов’ язання: « Наш SLA гарантує 99, 5% часу роботи — нижче цього часу клієнти отримують кредити за обслуговування ». Ієрархія: SLI (вимірювання) → SLO (внутрішня мета) → SLA (зовнішнє зобов’ язання).

Ключові фрази: «Ми зараз на 99,85% проти 99,9% SLO — ми споживали 70% нашого бюджету помилок цього місяця.» / «SLO для цієї кінцевої точки визначається як p99 затримка нижче 200 мс.» / «Ми повинні вирішити, чи затягнути SLO або інвестувати в поліпшення надійності, щоб захистити поточний». / «Цей інцидент спалив 3 дні бюджету помилок»

Помилка бюджетної мови

Бюджети помилок перетворюють цілі надійності на допустимі перерви: « 99, 9% SLO протягом 30 днів дає нам місячний бюджет помилок у 43, 8 хвилин ». Ви « витрачаєте », « спалюєте » або « споживаєте » бюджет помилок: « Збої розгортання минулого тижня споживали 40% нашого місячного бюджету ». Коли бюджет буде вичерпано, ви « заморожуєте розгортання можливостей » і зосереджуєтеся на роботі над надійністю: « Ми споживаємо 100% бюджету помилок — інженерні і виробничі відділи погодилися заморожувати неважливі розгортання на решту місяця »

Розділ 5: Kubernetes & Cloud Operations (англійською)

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

Мова і мова держави

Об’ єкти Kubernetes мають певний словник станів: підсистеми мають стани « Очікується », « Виконується », « Успішно », « Не вдалося » або « Невідомо ». Вони « перезапускаються » (CrashLoopBackOff — це стан, у якому підсистема продовжує перезапускатися після аварії). Розгортання « розгортається », « відновлюється » або « призупинено ». Служби « виявляють » розгортання. Ви « збільшуєте » або « зменшуєте » масштаб. Вузол має стан « Готові », « Не готові », « Розкладання вимкнено » або « Заблоковано ». Ви « витягуєте » вузол перед обслуговуванням.

Практичне спілкування: «Сервіси платежів застрягли в CrashLoopBackOff — я перевіряю журнали зараз.» / «Я кордоную вузол-3 для обслуговування і витягну його, як тільки піддони будуть переплановані.» / «HPA масштабує API-поди до 8 реплік через збільшення трафіку — використання ЦП становить 78 %.» / «Відновлення розгортання — новий образ має неправильно налаштований зонд живості»

Мова і мова мовлення

Операції з хмарою включають « забезпечення », « зняття забезпечення », « масштабування », « визначення правильного розміру », « оптимізацію витрат » і « резервування об’ єму ». Ресурси « надмірно забезпечені » (занадто великі для навантаження) або « недостатньо забезпечені » (занадто малі). Ви можете « правильно розрахувати » екземпляри на основі спостереженого використання. « Екземпляри на місці » і « екземпляри, які можна використовувати раніше » пропонують нижчу вартість з ризиком припинення. « Зарезервовані екземпляри » або « знижки за використання » зменшують вартість у обмін на зобов’ язання щодо обсягу.

Розділ 6: Моніторинг і попередження лексики

Моніторинг і спостережливість мають свій власний багатий словник, який постійно з'являється в DevOps і SRE комунікації - в runbooks, хронології подій, описи попереджень, документації панелі управління і обговорення архітектури.

Спостережливість: журнали, метрики, сліди

Три стовпці спостережливості мають кожен свій специфічний словник. Журнали «випускаються», «структуровані» або «неструктуровані», «агреговані» і «відправляються» на платформу управління журналами. Ви можете « стежити » за журналами у реальному часі або « запитувати » їх у минулому. Метрики « збираються », « знищуються » (у стилі Prometheus), « об’ єднуються » і « візуалізуються ». Ви вказуєте « пороги » і визначаєте правила « виявлення аномалій ». Розподілені сліди «розповсюджуються» по службах через «контекстні заголовки слідів» і виявляють «вузли затримки» по межах служб.

Ключові шаблони комунікації: «Я бачу підвищений рівень помилок у журналах — фільтрування відповідей 5xx показує пік, починаючи з 14:35.» / «Метрика затримки p99 має тенденцію до зростання протягом останньої години — вона перетнула наш поріг попередження 500 мкс о 14:42.» / «Трасування показує, що затримка походить від запиту бази даних в службі користувача, а не від API-шлюзу.»

Мова дизайну Alert

Добрий опис попередження дає змогу зрозуміти, що означає попередження і що слід зробити. Заголовки попереджень повинні бути фразами з іменниками: « Висока частота помилок — Служба оплати », а не « ПОПЕРЕДЖЕННЯ ПОПЕРЕДЖЕННЯ ПОПЕРЕДЖЕННЯ ». У описи попереджень слід включати: що відбувається, поточне значення порівняно з порогом, користувачів, на яких це впливає, і посилання на книгу виконання. « Частота помилок служби платежу перевищила 1% (поточне значення: 2, 3%). Це може вказувати на проблему з залежністю від нижнього рівня або на помилку розгортання. Розслідування: [посилання на панель керування]. Runbook: [link]. (англійською)

Розділ 7: On-Call & Runbook мова

Спілкування за викликом і написання runbook представляють два кінці спектру: runbooks написані ретельно і заздалегідь, щоб використовуватися під тиском; спілкування за викликом відбувається в реальному часі, часто коли втомилися і під стресом. Обидві вимагають ясності, але по-різному.

Мова написання Runbook

Runbooks слід писати для версії вас, яка прокидається о 3 годині ранку і не працювала з цією системою протягом шести місяців. Використовуйте нумеровані кроки з наказовим настроєм: "1. Перевірте панель керування: [посилання]. 2. Якщо рівень помилок перевищує 5%, зверніться до інженера сервера. 3. Якщо процесор бази даних працює на рівні вище 90%, виконати: kubectl exec..." Кожен крок має мати одну дійсну дію. Уникайте «ви можете хотіти розглянути» — пишіть «зробити X». Включайте гілки рішення: «Якщо X є істинним, перейдіть до кроку 5. Якщо X невірно, перейти до кроку 8."

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

Мова мовлення — англійська

Повідомлення про перенесення між чергами роботи за викликом повинні містити: поточний стан всіх активних інцидентів або підвищених проблем, всі відомі несправні системи, за якими слід стежити, недавні розгортання, які можуть бути важливими, і всі наступні елементи. « Перенесення: Немає активних інцидентів. Обережно: платіжна служба іноді повертає підвищену затримку (p99 близько 350 мс, SLO становить 200 мс) — розслідування, квиток. Недавні розгортання: user- service v1. 4. 2 було розгорнуто о 09: 00 UTC, проблем не спостерігалося. Елементи дій: [посилання на Jira]."

Найбільш корисні слова і фрази для DevOps і SRE

Рекомендований шлях навчання для DevOps і SRE інженерів

1. 1-й

   Мова відповіді на інциденти

   Починайте з найважливішого контексту комунікації в DevOps/SRE — комунікації з інциденту, оновлення стану і ескалації тяжкості.

2. 2-й

   Інженерно-технічна мова

   SLO, SLA, бюджети помилок і лексика цілей надійності - необхідні для будь-якої ролі SRE.

3. 3-й

   Мова CI/CD Pipeline

   Обмін даними про стан конвеєра, оголошення про розгортання і словник керування випусками.

4. 4-й

   Мова операцій Kubernetes

   Словник стану ресурсів, операційного спілкування та мови усунення неполадок для середовищ Kubernetes.

5. П'ять

   Інженерно-технічна мова

   Журнали, метрики, сліди і словник попереджень — мова систем моніторингу в масштабі.

6. 6-й

   Операції Terraform & IaC (англ.)

   Словник інфраструктури як коду для Terraform, Ansible та пов'язаних інструментів.

7. Сім

   Підтримка пост-інциденту

   Бездоганний постмортний письменник, мова для сприяння, і словник для відстеження предметів.

8. 8-й

   Інженер-конструктор АТ «Укрбуд»

   Практика для DevOps і SRE технічних інтерв'ю, що охоплюють як технічні, так і поведінкові питання.

9. Дев'ять

   Запитання для інтерв'ю

   Підготовка інтерв'ю, що стосується SRE, що включає принципи інженерії надійності і сценарії на вимогу.

Набір вправ для DevOps і SRE інженерів

Вправляйтеся у словниковому запасі і моделях спілкування, які описано у цьому підручнику, за допомогою таких груп вправ: