Як написати звіт про кореневу причину аналізу англійською мовою

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

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

** Корінь причини ** - основна умова, яка, якби не була присутня, запобігла б інциденту, на відміну від безпосереднього спускового механізму або симптому, який був помічений вперше.

• “Симптомом був пік у 500 помилок, тригером було розгортання, але кореневою причиною була відсутня нульова перевірка, яка була в коді місяцями і була використана тільки в шаблоні трафіку того дня.” *

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

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

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

• “Кожна корекційна дія у цьому звіті має власника і дату закінчення — « будьте обережнішими » — це не корекційна дія, це бажання.” *

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

Структурування звітності

• ** Резюме **: “У двох або трьох реченнях описайте, що сталося, як довго це тривало, і хто був вражений - пишіть цей розділ останнім, але покладіть його першим.”
• ** Часова шкала **: « Список подій у хронологічному порядку з часовими штампами, відрізняючи дії, які система виконує автоматично, від тих, які людина виконує вручну. »
• ** Корінь причини і фактори, що сприяють **: “Відокремте одну корінну причину від умов, які зробили її гіршою або важче вловити - не змішуйте їх в один абзац.”
• ** Вплив **: “Оцініть це, де це можливо - кількість невдалих запитів, зачеплені клієнти, або хвилини погіршеного обслуговування, а не просто “деякі користувачі були зачеплені""
• ** Виправлення помилок **: « Список кожної дії з власником і терміном виконання, а також відрізняти негайні виправлення, які вже було надіслано, від подальших дій »

Видання охоплює різні аудиторії

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

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

1. ** Напишіть основну причину у вигляді речення, яке починається з « тому що ». ** Якщо ви не можете завершити « подія сталася тому що ___ » з конкретною, фальсифікованою умовою, ймовірно, у вас все ще є опис симптому, а не основна причина.
2. ** Не слід плутати фактори, що спричинили проблему, з її корінною причиною. ** Об’ єднання їх (« корінною причиною була вада, плюс повільне попередження, плюс нечітке керування ») розбавляє зміст звіту і робить неясним, що саме слід виправити першим.
3. ** Зробіть кожну виправлену дію незалежно зрозумілою. ** Читач через шість місяців, не пам’ ятаючи про інцидент, повинен мати змогу прочитати одну виправлену дію і знати точно, що змінилося і чому, без перечитування всього звіту.

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

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

Наприклад, мова опису: описує мовлення з використанням опису мови

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

Розглянемо такий сценарій: Ви переглядаєте запит на збирання, у якому молодший розробник повідомив про проблему з швидкодією. Замість того, щоб реагувати оборонно («Це нормально», або «Це не моя провина»), ви можете відповісти такими фразами, як: «Це цінне спостереження — давайте розглянемо потенційне вузьке місце», або «Я дякую вам за те, що ви вказали на цю затримку; чи можемо ми перевірити потік даних, щоб зрозуміти, чому це відбувається?» Зауважте зміну від потенційно обвинувачуючих заяв до співпраці. Використання таких термінів, як « вузьке місце », « затримка » і « потік даних », демонструє ваше розуміння технічної проблеми, тоді як такі фрази, як « цінне спостереження » або « Я дякую вам за те, що ви вказали на…» створюють більш позитивну і сприймальну атмосферу.

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

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