Англійська мова для Datadog Observability

Datadog об’єднує метрики, журнали, сліди і синтетичні перевірки під однією платформою, а терміни, які команди використовують, щоб говорити про це - монітори, теги, SLO - мають певне значення, яке варто правильно, особливо коли попередження спалахує о 3 годині ранку і точність знижує час.

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

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

• “Ми встановили монітор на затримці p99, що сторінки на виклик, якщо він залишається вище 500 мс п’ять хвилин поспіль.” *

** Мітка ** — це мітка з ключем і значенням (наприклад, env:production або service:checkout ), яку можна додати до метрик, журналів і слідів, за допомогою якої ви зможете фільтрувати, групувати і корелювати дані усіх трьох типів сигналів. “Кожна служба тепер має мітку team, тому ми можемо відфільтрувати всю панель управління, щоб побачити лише служби нашої команди, замість того, щоб прокручувати всі інші.”

** SLO (Service Level Objective) ** — поріг надійності цілі (наприклад, 99, 9% успішних запитів протягом 30 днів) відстежується за визначеним SLI, з бюджетом помилок, який показує, скільки ненадійності залишається до порушення цілі. “Наша SLO замовлення становить 99,9% успіху протягом 30 днів — ми зараз спалюємо бюджет помилок швидше, ніж дозволяє темп місяця, тому ми заморозилися некритичні розгортання.”

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

** Фацетований пошук (фацети журналу) ** — структуровані атрибути, витягнуті з журналів (код стану, кінцева точка, ІД користувача), які надають вам змогу фільтрувати і переглядати дані журналу без написання запиту пошуку повного тексту. “Замість того, щоб брати необроблене повідомлення журналу, ми фільтрували його за фасетом http.status_code безпосередньо — це індексовано і набагато швидше, ніж текстовий пошук у мільйонах рядків журналу.”

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

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

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

Звітування про тригер події: “Сторінка прийшла з монітора з кількістю помилок більше 5% протягом п’ятихвилинного вікна — вона правильно виявила регресію приблизно через дев’яносто секунд після того, як вийшло погане розгортання.”

Пояснення звичаїв мітки у процесі впровадження: “Кожна служба потребує як мінімум env, team і service міток — без них ця служба не буде відображатися правильно на спільних панелях або в крос-командних запитах.”

Обговорення стану SLO у перегляді: “Ми вже спалили шістдесят відсотків бюджету на помилки цього місяця, в основному від інциденту 15-го - якщо ми не сповільнимо ризиковані розгортання, ми порушимо SLO до кінця місяця.”

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

• Назва конкретного ** монітора **, який запустив сторінку у звітах про події — « попередження було викликано » без назви монітора змушує читача шукати контекст, який вже повинен бути у звіті.
• Примусити ** теґ ** послідовність на ранньому етапі і згадати про це в onboarding — непослідовне теґування є єдиною найпоширенішою причиною, що приладова панель тихо виключає службу.
• Посилання ** error budget ** залишається, а не тільки ціль SLO, при обговоренні ризику випуску — команда з бюджетом залишається може взяти на себе більше ризику, ніж команда, яка вже закінчилася.
• Відрізняти кураторську ** панель приладів ** від ad- hoc дослідження, коли вказуєте комусь на перегляд — « перевірити панель приладів » корисніше, коли ясно, який і чому це правильний перегляд для питання.

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

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

Переклади: «Переклади з англійської мови» (англ

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

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

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

Ось приклад використання мови запитів Datadog ( pql ) для визначення певної проблеми, що показує, як можна обговорити цей словник:

// This query identifies services with high latency exceeding 500ms within the last minute.
{
  "services": {
    "query": "sum(rate(http_request_duration_seconds[1m])) > 0.5",
    "fields": ["service.name", "system.cpu.usage"]
  }
}

Цей запит, створений і пояснений за допомогою відповідної термінології - latency, rate, query - є набагато більш точним і дієвим описом проблеми, ніж просто заява “Щось повільно”. Використання pql само по собі демонструє розуміння основних можливостей моніторингу.