Customer Reliability Engineering English: SLAs, SLOs, and Customer-Facing Reliability Vocabulary (англійською)
Освоєння англійської лексики, яку використовують команди SRE, щоб говорити про зобов'язання щодо надійності, повідомлення про інциденти і оновлення стану, спрямовані на клієнтів.
Коли о 2 годині ночі виникає відключення, а клієнти задають питання, ваша англійська повинна бути швидкою, чіткою і точною. Надійність роботи з клієнтами вимагає специфічного словника - того, який з’єднує технічну реальність і бізнес-комунікацію. Цей пост описує основні терміни, які використовують команди SRE і платформи, коли розмовляють з клієнтами, пишуть сторінки стану і проводять постмортем.
Основні положення договору про надійність
SLA (Service Level Agreement) — формальне, часто юридично обов’ язкове угода між постачальником послуг і клієнтом, яка визначає очікуваний рівень обслуговування, включаючи гарантії безперебійної роботи і штрафи за їх відсутність.
«Наше корпоративне SLA гарантує 99,9% щомісячного часу роботи. Якщо ми його порушимо, клієнти автоматично отримують кредити на обслуговування»
** SLO (Service Level Objective) ** — внутрішнє завдання для певної метрики надійності, зазвичай суворіше, ніж SLA. Команди використовують SLO, щоб вловити проблеми, перш ніж вони стануть порушеннями SLA.
«Ми встановлюємо наш SLO на 99,95%, тому у нас є буфер, перш ніж ми досягнемо 99,9% порогу SLA»
**SLI (Service Level Indicator) ** — фактично виміряна метрика, що використовується для оцінки того, чи досягнуто SLO. Поширені SLI включають затримку запитів, частоту помилок і доступність.
«Наша основна SLI для послуги оплати — це відсоток запитів, які завершуються за менше ніж 500 мс.»
** Бюджет помилок ** — кількість ненадійності, яку службі дозволено мати протягом вказаного періоду часу, при цьому вона все ще відповідає своїм SLO. Коли бюджет на помилки вичерпаний, команди зазвичай заморожують нові випуски функцій.
«Ми використали 80% нашого щомісячного бюджету на помилки в перші два тижні — без нових розгортань до 1-го»
** MTTR (середній час відновлення) ** — середній час, який знадобиться для відновлення служби після початку інциденту. Нижчий MTTR вказує на більш стійку і оперативно зрілу команду.
Після того, як ми автоматизували наш процес відновлення, наш MTTR впав з 45 хвилин до менше ніж 8 хвилин
** MTTA (середній час підтвердження) ** — середній час між викликом попередження і підтвердженням членом команди, що він розслідує його.
PagerDuty показує наш MTTA spiked last week — we need to review our on-call rotation. — 2011. — 11 серпня
Терміни інциденту комунікації
** Інциденти комунікації ** - практика підтримання зацікавлених сторін і клієнтів інформованими під час активного відключення, використовуючи ясну, нетехнічну мову і регулярну частоту стану.
«Під час інциденту ми надсилали оновлення, спрямовані на клієнтів, кожні 30 хвилин, навіть коли у нас не було нічого нового, щоб повідомити — мовчання робить клієнтів тривожними»
Сторінка стану, що звернена до клієнта — публічна веб- сторінка (часто у окремому домені), на якій показано стан роботи служб та оновлення інциденту у реальному часі. Statuspage.io і Atlassian Status є звичайними інструментами.
«Обновіть сторінку стану перед тим, як ви опублікуєте в Slack — клієнти перевіряють її, перш ніж вони надсилають електронну пошту підтримки»
** Business impact statement ** — короткий, простий опис англійською мовою того, як інцидент впливає на клієнтів і їх робочі потоки, використовується у зовнішніх комунікаціях і на брифингах керівників.
«Уникайте технічного жаргону в заяві про вплив на бізнес. Замість «pod eviction storm», пишіть «деякі користувачі не могли увійти приблизно 12 хвилин»
** RCA (Аналіз кореневої причини) ** - структуроване дослідження того, чому стався інцидент, зосереджене на визначенні основних системних або процесних збоїв, а не на приписуванні окремої провини.
RCA виявила, що інцидент був викликаний зміною конфігурації, яка обійшла наш перегляд середовища стажування
** Postmortem ** — письмовий документ, створений після інциденту, що поєднує хронологію, RCA, бізнес- вплив і елементи дій. Безупречные пост-мёртвые - это индустриальный стандарт.
«Післясмертний розгляд відбудеться у п’ятницю — переконайтеся, що елементи дії мають власників і терміни, а не просто нечіткі описи»
Контекстно-орієнтовані мови
Ці фрази регулярно з’являються в роботі з надійністю клієнтів. Вивчайте їх як повні одиниці:
- ** « Ми зараз розслідуємо проблему, яка впливає на… » ** — стандартний початок для оновлення сторінки стану про інцидент
- ** “Цю проблему було вирішено. Ми вибачаємося за будь-які незручності.»** — закінчення повідомлення після відновлення
- “В ході цього інциденту не було втрачено даних клієнта.” — критична фраза запевнення в інцидентах, пов’язаних з безпекою
- “Ми опублікуємо повний постмортем впродовж 5 робочих днів.” - фраза зобов’язання, використовувана в закритті інциденту на підприємстві
- ** « Основною причиною було неправильно налаштоване правило балансування навантаження, введене під час вікна обслуговування ». ** — приклад точної, не звинувачувальної структури речення RCA
Ключові слова
Вивчайте ці фрази як фіксовану фразу — їх використовують майже так само, як і у професійному написанні SRE:
| Collocation | Usage |
|---|---|
| burn the error budget | ”We burned the error budget with that botched migration.” |
| breach an SLA | ”Three incidents in one week — we’re at risk of breaching the SLA.” |
| declare an incident | ”The on-call engineer declared an incident at 03:47 UTC.” |
| publish a postmortem | ”We always publish postmortems publicly to build customer trust.” |
| restore service | ”Service was fully restored by 14:22 UTC.” |
| customer-facing impact | ”Quantify the customer-facing impact before the exec briefing.” |
| miss the SLO | ”We missed the SLO in March due to the CDN provider outage.” |
Запис оновлень Clear Customer
Однією з найскладніших навичок англійської мови в роботі SRE є переклад технічних знань на мову клієнта. Виконати цей шаблон:
- ** Що відбувається ** (простими словами, без жаргону)
- ** Кому це стосується ** (всі користувачі / користувачі у регіоні X / користувачі, які використовують функцію Y)
- ** Що ви робите ** (дослідження / впровадження виправлення / моніторинг)
- ** Коли ви оновите наступним разом ** (вказано час, а не « скоро »)
Погана: * “Підвищена затримка p99 через під час розкладання під тиском на вузловому пулі eu-west-2c.” *
Добре: * “Деякі користувачі можуть відчувати повільне завантаження. Наша команда активно розслідує і надасть оновлення до 15:00 UTC.”*
Practice
Візьміть останній інцидент або майже-інцидент у вашій компанії і напишіть пост-мртове резюме з трьох абзаців англійською. Включіть: опис впливу на бізнес (одне речення), основну причину (одне речення) і три пункти дій з власниками. Намагайтеся не вживати технічних абревіатур у першому абзаці — аудиторія не технічний віце-президент. Поділитися ним з колегою, щоб отримати відгук щодо ясності.
Використання мови програмування Сі — понад базові поняття
Команди SRE не просто влаштовують речі; вони активно управляють ризиками, чітко комунікують і демонструють прихильність до рівнів обслуговування. Але перекладати це на ефективну англійську може бути складно, особливо коли справа доходить до складних технічних концепцій і очікувань клієнтів. Цей розділ присвячено удосконаленню вашого словника, що виходить за рамки простих описів, допомагаючи вам сформулювати нюанси практики SRE, що є ключовим для створення довіри і демонстрації відповідальності. Це про перехід від простого зауваження * що * сталося до пояснення * чому *, описуючи * як * це вплинуло на клієнтів, і проактивно встановлюючи реалістичні очікування. Подумайте не просто про «зрив сервера», а про «тривалу подію затримки мережі, що погіршила досвід користувача, вплинув на ключові потоки роботи». Ця зміна у формулюванні є життєво важливою для спільного вирішення проблем і прозорого спілкування.
Поширеною перешкодою є розуміння різниці між SLA (Service Level Agreements) і SLO (Service Level Objectives). SLA це контракт, зазвичай юридично обов’ язковий, який описує те, що ви обіцяєте надати. Вона часто широка і зосереджена на конкретних показниках, часто вимірюваних проти фіксованого порогу. І навпаки, SLO є * метою * - внутрішньою метою, заснованою на аналізі даних, що керує розробкою і оперативними рішеннями. Це більш гнучке і динамічне, що дозволяє регулювати на основі продуктивності в реальному часі. Використання правильної термінології демонструє складне розуміння управління ризиками: «Ми працюємо за нашим 99,9% SLO для часу відповіді API, що дозволяє невеликий буфер, щоб враховувати очікувані пікові навантаження»
Іншою ключовою областю є комунікація з клієнтами. Замість нечітких тверджень на кшталт «ми працюємо над цим», SRE використовують точну мову, яка передає як проблему, так і її вплив. Хорошим прикладом може бути повідомлення Slack: «@customer, переживає періодичні високі затримки на панелі звіту через завдання оптимізації запиту бази даних. Ми визначили основну причину — неефективне індексування — і розгортаємо оновлення, яке очікується через 30 хвилин. Це безпосередньо підвищить швидкість створення вашого звіту. Зауважте конкретні відомості — область, на яку впливає проблема, визначену причину, і очікуваний час розв’ язання проблеми.
Нарешті, пам’ятайте, що вимірювання є ключем до ефективного спілкування. Обмін даними прозорою демонструє прихильність до постійного вдосконалення. Розглянемо простий приклад CLI з використанням kubectl — який ілюструє, як спостереження за метрикою дає інформацію для створення звітів:
kubectl top nodes --sort=-cpu # Retrieve CPU usage for all nodes and sort descending by CPUЦя команда, у поєднанні з даними, які вона надає, надає вам змогу сказати щось на зразок: « У вузлі « titan » зараз спостерігається високе використання процесора (85%), що впливає на його здатність обслуговувати запити. Ми досліджуємо потенційні причини і впроваджуємо масштабування коригувань. “CLI - це не просто інструмент; це доказ проактивного моніторингу і прийняття рішень на основі даних - потужний елемент в комунікації надійності.