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

Від інженера до менеджера

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

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

** Бюджет помилок ** є прийнятною кількістю ненадійності в системі, отриманою з SLO. Якщо система має 99,9% доступності SLO, бюджет помилок становить 0,1% від періоду — приблизно 43 хвилини на місяць.

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

** Стандартні положення політики: **

• Якщо бюджет помилок використано на більше ніж 50% за певний період, випуск нових функцій буде призупинено, а команда виділить наступний спринт для роботи над надійністю
• Якщо бюджет помилки повністю вичерпаний, пост-морт є обов’язковим і всі заплановані роботи заморожуються до тих пір, поки не буде вирішена коренева причина і запобігти повторенню
• «Бюджет помилок буде переглянутий на щомісячній зустрічі SLO з продуктом і інженерним керівництвом»

** Мова переговорів з командами продукту: **

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

Бюджетні витрати

** Бюджет праці ** команди SRE є узгодженим максимальним відсотком інженерних можливостей, які можуть бути витрачені на працю. Книга Google SRE рекомендує 50% - хоча більшість команд прагнуть до нижчого рівня.

“Наше поточне вимірювання праці показує, що 38% годин на гарячій лінії витрачається на вручну сортування квитків. Це вище нашого погодженого бюджету праці в 30%, і я б хотів обговорити, які інвестиції в автоматизацію повернуть нас назад в межах»

** Мова зменшення витрат: **

• «Ми визначили три високооб’ємні, повністю автоматизовані категорії праці, які разом становлять 60% наших робочих годин»
• «Бизнес-причинами для цих інструментальних інвестицій є скорочення приблизно 12 інженерних годин на тиждень — приблизно 25 000 фунтів стерлінгів потужності на квартал при повній завантаженості вартості»

Програма «Віртуальна мова»

** Хартія на виїзд ** — документ, який визначає очікування, компенсацію, відповідальність і процедури ескалації для чергування на виїзд. Менеджер SRE зазвичай володіє і підтримує цей документ.

Ключові елементи для опису:

• ** Основний і допоміжний інженер на гарячій лінії ** — перший і другий інженер, які будуть викликані для інциденту. « Допоміжний інженер на гарячій лінії забезпечує резервування, якщо основний інженер не доступний або інциденту потрібні додаткові руки. »
• ** Вікно чергування ** — години, протягом яких інженер активно перебуває на черзі. « Наш час чергування — це 24- годинна зміна; ми змінюємося щотижня. »
• ** Правила ескалації ** — визначена послідовність для ескалації нерозв’ язаного інциденту до старших працівників або керівництва. « Якщо інцидент не буде розв’ язано протягом 30 хвилин, правила ескалації запускають сторінку для керівника SRE. »
• ** Handoff ** — передача наприкінці зміни під час чергування, передавання права власності і контексту. « Кожна зміна закінчується письмовою запискою про передачу, у якій резюмуються відкриті проблеми і їх поточний стан. »

Мова служби здоров’я:

• «Обсяг попереджень на службі бази даних створює нестійке навантаження переривання для інженера на виклику»
• «Ми зобов’язалися зменшити обсяг дій на 40% в наступному кварталі, щоб захистити якість життя під час дзвінків»
• «Втрата працездатності та тривога є провідними показниками вигорання програми на виклик»

Надійність дорожньої карти мови

** План надійності ** це інженерний план для пересування системи з її поточного стану надійності до її цільового SLO. Він представлений лідерам продукту, інженерним директорам, а іноді і головним клієнтам.

** Структура: **

1. Поточний стан — досягнення SLO, рівень споживання бюджету помилок, режими найвищих помилок.
2. Цільовий стан — цілі надійності на наступні 6-12 місяців.
3. Ключові ініціативи — інженерні проекти, які заповнять прогалини.
4. Залежності — ресурси, команди або рішення, які вимагаються поза командою SRE.

** Корисні фрази: **

• «Дорожня карта надійності для H2 визначає три пріоритети: автоматизований відключення, прийняття хаосної інженерії і консолідація платформи спостережливості»
• «Кожна ініціатива на дорозі відображається на конкретному SLO і прогнозованому впливі на бюджет помилок, тому ми можемо обґрунтувати інвестиції в інженерних термінах»
• «Залежність від команди платформи для оновлення Kubernetes знаходиться на критичному шляху для роботи з високою доступністю»

П’ять прикладів висловлювань

1. «Наша політика бюджету помилок стверджує, що як тільки 75% місячного бюджету буде спожиті, робота над функціями наступного спринту буде замінена на надійність»
2. «Я підняв питання про порушення бюджету праці з інженерним директором, тому що ми не можемо підтримувати здорову програму на вимогу, якщо 45% нашого часу витрачається на вручну усунення»
3. “Хартія по телефону була оновлена в минулому кварталі, щоб включити чіткі положення для перегляду втоми від попередження, які тепер є постійним пунктом порядку денного в нашому щомісячному SRE синхронізації.”
4. «Дорожня карта надійності пропонує інвестувати в автоматизований відключення для платіжної служби, який ми плануємо зменшити наш рівень інцидентів P1 приблизно на 60%»
5. «Під час переговорів з командою продукту, я розглядаю бюджет помилок як спільний ресурс — коли вони розуміють, що помилки надійності коштують їм швидкості функції, розмова змінюється»

Комунікаційна підтримка

Менеджери SRE, які найбільш ефективні на рівні керівництва, вчаться перекладати мову надійності на мову бізнесу. « У нас було три інциденти P1 » є менш переконливим, ніж « наші три інциденти P1 за останній квартал призвели до приблизно 8 годин простою, пов’ язаного з роботою з клієнтами, і за оцінками, вплинули на 12 000 активних сеансів ». Дані, вплив на бізнес і чіткі запитання є основою надійного спілкування керівництва SRE будь- якою мовою.

Наприклад, англійська мова має такі значення: англійська мова — мова, що використовується для спілкування між немовлями

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

Однією з найчастіших перешкод є використання таких термінів, як «праця». Хоча це здається простим – мова йде про ручну роботу, яка не пов’язана безпосередньо з основними операціями системи – це може здатися абстрактним. Замість того, щоб просто сказати « зменшити трудомісткість », що може бути неправильно інтерпретовано як зменшення * всіх * зусиль, спробуйте зробити це більш конкретно: « Давайте визначимо три найважливіші завдання, які займають найбільше часу у нашій команді, і автоматизувати їх у першу чергу ». Або, пояснюючи це менеджеру продукту, ви можете сказати: « Ми розглядаємо зменшення трудомісткості за допомогою автоматизації [конкретного завдання], що звільнить 20% часу наших інженерів для проактивної роботи, наприклад, планування потужності ». Зверніть увагу на контекст; « трудомісткість » це не просто зайва робота — це неефективні процеси.

Інша область, яка вимагає обережного формулювання, це обговорення «бюджетів помилок». Сказати: «Ми повинні залишатися в межах нашого бюджету помилок» може звучати обмежуючим і потенційно демотивуючим. Кращий підхід: « Давайте проактивно стежити за нашим поточним рівнем помилок у порівнянні з встановленим бюджетом і визначити будь- які тенденції, які можуть потребувати коригування — можливо, тимчасове збільшення під час великого випуску? » Сфокусуйтеся на * моніторингу * і * проактивній ідентифікації *, а не просто на встановленні обмеження. Аналогічно, коли ви запитуєте зміну бюджету помилок від команди продукту, використовуйте такі слова: « Засновано на нашому поточному спостереженому рівні помилок X%, ми прогнозуємо Y% збільшення ризику, якщо ми продовжимо з функцією Z у її поточному стані. » Чи можемо ми обговорити стратегії зменшення наслідків?»

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