Як пояснити фальшиво позитивне попередження англійською мовою

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

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

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

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

** Неправильне калібрування порогових значень ** — поширена причина хибних позитивних результатів, коли умова створення попередження (наприклад, відсоток помилок або обмеження часу відповіді) встановлено занадто чутливо до звичайних, очікуваних змін поведінки системи.

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

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

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

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

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

Закриття попередження як підтвердженого хибно позитивного: “Я розслідував сигнал тривоги, який був виданий о 2:14 ранку. Не було впливу на службу — це було викликано запланованим завданням резервного копіювання, яке короткочасно підвищує дисковий вхід/вихід, що є очікуваною поведінкою, а не проблемою.”

Проактивне підняття попередження про втому:

• « Я хочу позначити щось, перш ніж це стане більшою проблемою: це попередження було хибно позитивним п’ ять разів цього місяця. Я хвилююся про втому від тривоги, якщо ми не настроїмо її, оскільки люди вже починають припускати, що це шум, перш ніж перевірити.»*

Запропонувати конкретний виправлення, а не просто вимкнути шумне попередження:

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

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

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

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

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

Наприклад, мова опису: мова опису для мови опису

Погляньмо правді в очі - пояснення хибно позитивного результату не завжди просте. Легко впасти в нечіткі описи або просто заявити, що «це була помилка». Однак, в професійному спілкуванні, особливо в технічних командах, ясність і точність є абсолютно вирішальними. Це особливо важливо, коли справа доходить до сповіщень про моніторинг; повторювані пояснення не-проблем значно сприяють втомі від попереджень - психічному виснаженню, викликаному постійним отриманням повідомлень про речі, які насправді не є проблемами. Метою є не просто сказати, що щось пішло не так; це продемонструвати ретельне розуміння * чому * і, що важливіше, які кроки ви робите, щоб запобігти повторенню. Ключовим елементом є перенесення фокусу з негайної попередження на основну причину і подальші заходи з її зменшення.

Розглянемо такі сценарії: уявіть, що ви отримуєте сповіщення Slack з повідомленням « Виявлено надмірне використання процесора на сервері X ». Спочатку це може призвести до паніки. Однак, добре спроектована відповідь негайно уникає звинувачення кого-небудь або вибачення. Замість цього, ви починаєте з фактичної інформації. « Добре, я дослідив попередження про високе використання процесора на Сервері X. Це було викликано запланованим пакетним завданням, яке виконувалося вночі — а саме, нашим нічних скрипт перевірки даних. Цей скрипт, хоча і є обов’ язковим для підтримки цілісності даних, потребує значної обчислювальної потужності протягом цього періоду. « Бачите конкретну деталь? Це ключ. Потім продовжуйте з конкретними діями: « Я змінив розклад виконання цього скрипту на часи, коли немає пікової напруги, і додав більш деталізовані метричні дані до нашої системи моніторингу, щоб краще відрізняти нормальну діяльність від потенційних проблем. Ми також переглядаємо споживання ресурсів скриптом, щоб визначити будь-які потенційні оптимізації. “Фразування уникає звинувачення і зосереджується на рішеннях.

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

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