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

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

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

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

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

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

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

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

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

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

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

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

Відрізняти тригер від кореневої причини в пост-мортем:

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

Назва багатьох факторів, що сприяють розвитку, без розмивання кореневої причини:

• “Корінь проблеми зрозумілий: необмежений запит, який сканував всю таблицю під час завантаження. Але два фактори зробили це гірше, ніж це повинно було бути — наш моніторинг не вловив його протягом одинадцяти хвилин, а підручник для цього попередження був застарілим. ”*

Пояснюючи, чому розслідування не зупинилося на першій відповіді:

• “Нашим першим інстинктом було назвати це проблемою бази даних і продовжити. Але застосувавши п’ять причин за цю точку, ми виявили, що база даних насправді поводилася правильно - справжня коренева причина була в тому, як ми записували пакети.”*

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

• Розрізняти ** кореневу причину ** від ** події, що спричинила подію ** явно у кожному постмортемі — об’ єднання їх призводить команди до виправлення тригера (який буде просто замінено наступним) замість основного стану, який зробив тригер небезпечним.
• Список кожного ** фактора, що сприяє ** окремо, замість складання їх у одну надто спрощену кореневу причину — кожен фактор, що сприяє, зазвичай має власне незалежне виправлення, і захоронення їх втрачає ці виправлення зі списку елементів дій.
• Використовуйте п’ять причин або подібну структуровану техніку явно, і згадуйте про це в записі - це сигналізує, що розслідування не зупинилося на першій правдоподібній відповіді, яка є найпоширенішим способом неправильної ідентифікації кореневої причини після смерті.
• Стримуйте тиск, щоб назвати одну, просту кореневу причину, коли чесна відповідь складніша — постмортний аналіз, який надмірно спрощує заради чистої розповіді, створює коротший документ, але гірший набір виправлень.
• Приоритетно виправляйте справжню ** корінну причину **, але не пропускайте розв’ язання факторів, що сприяють виникненню проблеми — виправлення лише корінної причини все одно може залишити систему вразливою до іншого тригера, що використовує ті ж самі слабкі місця.

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

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

Назва походить від фр. phrase «фраза» (фр. phrase «фраза»). Внесок

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

Поширена пастка полягає в тому, щоб розглядати кожну проблему просто як «серію факторів, що сприяли». Хоча це правда, що багато речей причинили затримку, це може розбавити відповідальність і затемнити єдину, основну проблему. Уявіть гілочку Slack під час постмортему: « Гаразд, отже, збірка зазнала невдачі через високе використання ЦП, затримку мережі, застарілі залежності і помилковий сервер ». Це список співробітників, але він не прояснює * чому * процесор був високим у першу чергу. Більш цілеспрямованим підходом було б сказати щось на зразок: « Основною причиною є недостатнє моніторинг поріг попередження, який маскує зростання навантаження на ЦП, поки це не вплине на продуктивність збирання. » Це негайно зосереджує увагу на певній області для поліпшення — сама система моніторингу — замість простого розсіювання звинувачення по кількох системах і процесах.

Аналогічно, у описі запитів на завантаження, що стосуються вади, формулювання має величезне значення. Замість « Виправлено декілька незначних проблем з кодовою базою », що є нечітким і може свідчити про поверхневе виправлення, розгляньте: « Виправлено основну причину переривчастих тайм- аутів підключення до бази даних за допомогою реалізації логіки повторних спроб і налаштування параметрів пулів з’ єднань. » Фактори, що сприяють цьому, такі як недостатнє тестування для одночасних запитів, були розглянуті за допомогою цілей покращень нашого тестового пакету.” Зауважте, як останній приклад чітко визначає основну проблему (“логіка повторних спроб”) і визнає вторинні впливи, не втрачаючи фокус на первинному рішенні. Ця точність є важливою не тільки для ясності, але і для відстеження прогресу і демонстрації відчутного впливу під час переглядів.

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