Спостережуваність: від сигналу до пояснення

У главі 11 ми вже побачили, що якість продукту треба описувати через досвід людини: чи виконала вона потрібну дію, скільки це тривало, наскільки свіжі дані вона побачила. Глави 56–59 показали, як зміни проходять перевірки й потрапляють у середовище, а глава 60 — чому повернення коду не завжди повертає дані та зовнішні ефекти. Тепер розглянемо, як після випуску відрізнити звичайну зміну навантаження від погіршення, знайти ділянку шляху запиту, побачити застарілі дані й дати відповідальній людині сигнал, на який можна діяти.

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

Тут спостережуваність потрібна для розуміння стану послуги й рішень щодо її роботи. Метрики ефективності розробки, швидкості випуску й використання агентів належать до глави 71. Координація людей під час реального інциденту буде темою глави 62; готові процедури й навчання після події — глав 63–64.

61.1. Зелений сигнал — ще не доказ успіху

Моніторинг перевіряє наперед визначені ознаки: наприклад, чи відповідає вебсервер, чи не перевищила черга відомий поріг, чи завершився запланований імпорт. Спостережуваність допомагає досліджувати стан системи, коли причина проблеми заздалегідь невідома: інженер може зіставити події, виміри й шлях окремого запиту, щоб перевірити, що відбувалося всередині компонентів. Це корисне робоче розрізнення, а не твердження, що інструмент належить лише до однієї категорії: одна система може збирати телеметрію і для регулярного моніторингу, і для діагностики нових ситуацій. Таке розрізнення узгоджується з описом DORA, DevOps Research and Assessment (дослідження та оцінювання DevOps): моніторинг спирається на наперед заданий набір метрик або журналів, а спостережуваність — на дослідження невідомих заздалегідь властивостей і закономірностей. DORA: Monitoring and observability

Система може віддавати сторінку входу зі статусом 200 за протоколом передавання гіпертексту (Hypertext Transfer Protocol, HTTP), хоча жоден новий імпорт не надходив годинами. Така успішна відповідь описує обмін між клієнтом і сервером, а не повноту чи актуальність даних на сторінці. Перевірка доступності адреси маршруту відповідає на вузьке запитання: «Чи відкривається ця сторінка?». Вона не відповідає на запитання власника продукту: «Чи бачить читач актуальний склад команди?».

Тому починайте не з переліку графіків, а з наслідку. Наприклад:

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

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

61.2. Три види сигналів, три різні запитання

Траса — пов’язаний запис шляху однієї операції крізь компоненти; далі її складники розглянуто докладніше. OpenTelemetry (назву часто скорочують до OTel) — відкритий набір специфікацій та інструментів для збирання й передавання телеметрії. У цій главі розглянемо три поширені сигнали — журнали, метрики й траси. OpenTelemetry також описує baggage для передавання контексту; окремий сигнал Profiles перебуває на ранньому етапі розвитку й має статус Alpha. Ці сигнали можуть бути пов’язані між собою, але не є взаємозамінними. OpenTelemetry: Signals, Profiles: статус Alpha

Сигнал	На яке запитання відповідає	Приклад
Журнал (log)	Яка подія сталася в конкретному контексті?	Імпорт завершився частково й відхилив 18 записів.
Метрика (metric)	Як часто або наскільки сильно змінюється властивість системи?	За останні 5 хвилин успішні 92% імпортів; вік даних — 74 хвилини.
Траса (trace)	Яким шляхом пройшла конкретна операція і де минув час?	Запит до звіту чекав 1,1 секунди на сервіс політики доступу.

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

61.3. Журнали: короткий контекст замість купи тексту

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

Зазвичай структурований запис містить час, рівень важливості, назву сервісу, назву події, версію або ревізію, ідентифікатор запиту чи фонового завдання та кілька безпечних вимірів. Позначення DEBUG (налагодження), INFO (інформаційне повідомлення), WARN (попередження) та ERROR (помилка) — це домовленість команди про важливість запису, а не універсальний стандарт, що автоматично визначає реакцію. Час краще зберігати в єдиній часовій шкалі; у прикладах нижче використовуємо координований всесвітній час (Coordinated Universal Time, UTC).

Нижче — вигадані скорочені рядки у JSON (JavaScript Object Notation — текстовий формат представлення структурованих даних). Ідентифікатор, або ID (identifier — ідентифікатор), допомагає пов’язати записи без розкриття вмісту запиту:

{"timestamp":"2026-09-24T13:04:10Z","level":"INFO","service":"feed-worker","event":"import.started","release":"2026.09.24.3","job_id":"job-42"}
{"timestamp":"2026-09-24T13:04:18Z","level":"WARN","service":"feed-worker","event":"source.timeout","release":"2026.09.24.3","job_id":"job-42","attempt":2,"duration_ms":8000}
{"timestamp":"2026-09-24T13:04:19Z","level":"ERROR","service":"feed-worker","event":"import.failed","release":"2026.09.24.3","job_id":"job-42","reason":"source_timeout"}

Ці записи читаються як короткий ланцюжок: завдання почалося, другий виклик джерела перевищив тайм-аут у 8 секунд, завдання завершилося невдачею. Якщо додати точну адресу клієнта, повну адресу вебресурсу (Uniform Resource Locator, URL) з параметрами, весь JSON запиту, заголовки авторизації й десятки повторів того самого тексту, розуміння може не поліпшитися, а приватний ризик і вартість зростуть.

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

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

61.4. Метрики: вимірюйте розподіл і називайте вікно

Метрика — числовий вимір поведінки системи в часі. Інструментація — код або бібліотека, що додає до програми створення таких вимірів і сигналів. OpenTelemetry надає програмний інтерфейс застосунку (Application Programming Interface, API) та набори засобів розробки (Software Development Kit, SDK); ступінь зрілості окремих сигналів відрізняється залежно від мови програмування, тому перед використанням перевіряйте статус і документацію потрібного сигналу для своєї версії набору засобів. OpenTelemetry: Language APIs & SDKs. Коли назва метрики не пояснює, що саме вона рахує, звідки береться значення та за який період його агреговано, графік легко прочитати хибно.

• Лічильник (counter) збільшується зі спостереженнями: наприклад, кількість завершених імпортів або помилок. Щоб отримати швидкість подій (rate), рахують приріст лічильника за вікно часу, наприклад кількість подій за хвилину. Сам абсолютний накопичений лічильник не показує поточний рівень помилок.
• Поточне значення (gauge) може зростати й спадати: довжина черги, кількість активних з’єднань, вік найстарішого завдання.
• Гістограма (histogram) зберігає агреговану картину спостережень: кількість, суму й лічильники вимірів у визначених інтервалах. Вона дозволяє оцінити форму розподілу, наприклад часу відповіді, не записуючи кожен вимір окремим рядком.

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

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

Інженерія надійності сервісів (Site Reliability Engineering, SRE) — галузь практик для підтримання надійної роботи сервісів; назва також використовується в серії навчальних матеріалів Google. Перцентиль описує значення, нижче якого лежить певна частка вимірів у вибраному наборі. 95-й перцентиль (p95) — значення, якого не перевищують 95% вимірів; 99-й перцентиль (p99) — таке значення для 99%. Вони не кажуть, що кожен запит тривав саме стільки. Середнє арифметичне відповідає на інше запитання і може приховати довгий хвіст: багато швидких запитів зменшать його, навіть якщо невелика частка людей чекає значно довше. Google SRE: Service Level Objectives

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

Гістограма також не дає безмежної точності. Якщо перцентиль оцінюється за інтервалами, результат залежить від їхньої ширини й розміщення. Гістограми з однаковими межами можна об’єднувати, але зміна меж у часі може зробити порівняння некоректним; за попередньо порахованими перцентилями часто не можна правильно відновити перцентиль об’єднаної групи. Тож формулюйте межі точності й перевіряйте тип агрегації в конкретному засобі. Prometheus: Histograms and summaries, OpenTelemetry: Metrics data model

Як розпізнати запитання за метрикою

Запитання	Приклад метрики	Що ще треба знати
Чи завершуються запити?	частка успішних допустимих дій	які дії входять у знаменник; чи враховано відмови й тайм-аути
Чи встигає система відповісти?	p95 або частка запитів до заданого часу	тип маршруту, клієнтський чи серверний час, вікно й кількість запитів
Чи відстає фонова обробка?	вік найстарішої події або затримка від надходження до обробки	що означає «оброблено»; чи дані вже зафіксовано
Чи зростає ризик перевантаження?	черга, активні з’єднання або використання ресурсу	скільки ресурсу система реально має; чи є запас і обмежувачі

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

61.5. Траси: один шлях через кілька компонентів

Траса (trace) — послідовність пов’язаних операцій, які утворюють шлях однієї дії. Окремий проміжок у цій послідовності називається span: це робота одного компонента, наприклад обробка запиту шлюзом, читання бази або виклик зовнішнього сервісу. Дочірній проміжок показує дію, яку почав батьківський проміжок. Їхні часові межі дають змогу побачити, де очікування було найдовшим і які роботи перекривалися.

Умовна траса завантаження звіту може мати такий вигляд:

клієнт → API шлюзу (1 310 мс)
                └─ застосунок звітів (1 274 мс)
                     ├─ сховище (27 мс)
                     └─ сервіс прав доступу (1 120 мс)

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

Щоб бачити одну операцію в кількох сервісах, системи передають контекст трасування між межами. OpenTelemetry описує контекст, який містить ідентифікатор траси та ідентифікатор батьківського проміжку; типовий механізм передає його через заголовки. Журнал може зберегти ідентифікатори траси та проміжку, щоб відкрити відповідні записи поруч із трасою. Пропагація контексту — передавання цих зв’язків між процесами й сервісами — корисна лише настільки, наскільки всі ланки її зберігають; межа на зовнішньому постачальнику або в черзі може розірвати причинний ланцюг. OpenTelemetry: Context propagation

Траса не має ставати копією запиту користувача. Для пошуку затримки зазвичай потрібні маршрут, тип операції, результат, ревізія, залежність і кілька безпечних атрибутів. Повне тіло запиту, пароль чи платіжні дані не додають цінності до часу span і можуть потрапити до більшої кількості систем та людей. Контекст, що передається між сервісами, також не місце для секретів: одержувач наступного переходу може бути менш довіреним, а службові атрибути можуть зберегтися в журналах. OpenTelemetry: Context propagation security, OpenTelemetry: Handling sensitive data

Не кожен запит матиме збережену трасу. Вибіркове збереження (sampling) лишає лише частину трас, щоб керувати обсягом даних і вартістю. Рішення на початку шляху економне, але ще не знає, чи завершиться запит помилкою або великою затримкою; вибір після завершення може зберегти такі трасування, але потребує буферизації та стану в системі обробки. Вибіркова політика має відповідати задачі: зберігати достатньо звичайних запитів для базової лінії й мати продуманий спосіб не загубити рідкісні повільні чи невдалі випадки. Саме вибір усіх помилок неможливо гарантувати, якщо рішення приймається до того, як стала відома помилка. OpenTelemetry: Sampling

61.6. Як поєднати сигнали, не переплутавши збіг із причиною

Практичний ланцюжок пошуку такий:

1. Метрика показує симптом. Визначте тип операцій, у яких зросли помилки чи затримка, і період, коли це сталося.
2. Звузьте групу запитів. Виберіть кілька репрезентативних операцій за часом, маршрутом, середовищем чи ревізією; не намагайтеся відкрити кожен журнал.
3. Прочитайте короткий ланцюжок журналів і трасу. Зіставте ідентифікатор запиту, трасу, події й тривалість дочірніх проміжків.
4. Сформулюйте гіпотезу. Наприклад: «затримку створює сервіс перевірки прав».
5. Шукайте, що могло б її спростувати. Чи повільні запити до сервісу прав у всіх ревізіях? Чи відрізняються регіон, тип звіту, дані або час очікування? Чи зросли повтори або черга саме до цієї залежності?
6. Змініть лише один фактор або перевірте незалежний доказ. Часовий збіг релізу, помилки й перезапуску — привід для дослідження, а не доказ причинності.

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

Повний приклад: затримка після випуску

У навчальному клієнтському кабінеті після випуску ревізії 2026.09.24.3 команда бачить повільне відкриття щомісячного звіту. Усі числа нижче вигадані. Показники за п’ятихвилинні вікна показують таку зміну:

Період	Кількість запитів	Частка помилок	p95 повної відповіді	p95 читання зі сховища
До випуску	10 000	0,2%	240 мс	31 мс
Після випуску	10 000	2,4%	1 360 мс	33 мс

Кожне п’ятихвилинне вікно містить 10 000 допустимих запитів: частка помилок означає 20 і 240 невдач відповідно. p95 обчислено за завершеними відповідями, а тайм-аути входять до частки помилок окремо. Середня затримка змінилася лише з 170 до 215 мс, бо більшість звітів і далі відкривається швидко. Перцентиль і частка помилок показують, що проблема сконцентрована в меншості операцій. Але самі метрики ще не кажуть, чи причина — новий код, інше навантаження, зовнішня залежність або частковий збій.

Команда бере кілька повільних запитів із відповідної часової ділянки й порівнює траси. У трасах повільних звітів читання зі сховища займає близько 30 мс, а дочірній проміжок виклику сервісу прав доступу — від 1,0 до 1,2 секунди. У коротких структурованих журналах є час, маршрут, версія й кінцевий результат, але немає вмісту звіту:

{"timestamp":"2026-09-24T13:05:14Z","level":"WARN","service":"report-api","event":"dependency.slow","dependency":"access-policy","release":"2026.09.24.3","trace_id":"7fa4…","duration_ms":1120}
{"timestamp":"2026-09-24T13:05:14Z","level":"INFO","service":"report-api","event":"report.completed","route":"monthly-summary","release":"2026.09.24.3","trace_id":"7fa4…","duration_ms":1274}

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

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

61.7. Коли сторінка відкрита, а дані застаріли

Для фонової обробки просте питання «чи працює сервер?» часто не має потрібного продукту рівня. Важливо вимірювати:

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

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

Повний приклад: сайт відкривається, синхронізація зупинилася

Розгляньмо вигаданий сайт футбольної статистики, який отримує оновлення про склади й результати з зовнішнього джерела. Сторінки відкриваються, сервер відповідає, загальна частка успішних HTTP-запитів становить 99,8%, а p95 завантаження — 190 мс. Однак ранкові склади команд уже мають бути свіжими, а останнє успішне й зафіксоване оновлення даних відбулося 81 хвилину тому.

У початковому продуктному припущенні власник погодив свіжість до 40 хвилин для даних про заплановані матчі. Ці пороги є умовами навчального прикладу, не універсальною ціллю. Сигнали дають додаткові факти:

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

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

Корисне сповіщення повідомляє про наслідок, а не про випадковий внутрішній симптом:

Дані складів не оновлювалися 81 хвилину; погоджена межа — 40 хвилин. Власник: команда імпорту. Наступна дія: перевірити останній запуск планувальника й підтвердити успішне збереження нової вибірки.

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

Ця різниця між доступністю сервера й станом даних є важливою для систем із реплікацією, чергами, імпортом та похідними наборами. У книзі Designing Data-Intensive Applications, другому виданні, теми розподілених систем і роботи з даними дають ширший контекст для таких компромісів. Числа й конкретний навчальний приклад вище створені для цієї глави; це не переказ конкретного випадку з книги й не цитата. Сторінка автора підтверджує актуальне друге видання (O’Reilly Media, березень 2026). Designing Data-Intensive Applications, 2nd edition, бібліографічна сторінка автора

61.8. Вимір, ціль і зовнішня обіцянка надійності

Для розмови про надійність системи варто розрізняти три ролі:

• SLI — Service Level Indicator (показник рівня сервісу): вимір того, що переживає користувач, наприклад частка успішних експортів.
• SLO — Service Level Objective (ціль рівня сервісу): внутрішня або узгоджена ціль для цього показника протягом періоду.
• SLA — Service Level Agreement (угода про рівень сервісу): зобов’язання перед клієнтом, яке може визначати наслідки чи компенсацію в разі невиконання.

Ці терміни пов’язані, але не тотожні. SLI каже, що було виміряно; SLO — чого продукт хоче досягти; SLA — про що домовилися з клієнтом. Команда може мати внутрішню ціль, суворішу за контрактну, або контракт, у якому конкретні умови й спосіб обчислення не збігаються з внутрішнім показником. Google SRE наголошує, що вибір цілі не суто технічний: він має враховувати очікування й ризики продукту. Google SRE: Service Level Objectives

Навчальний приклад: команда звітує за часткою прийнятих користувачем експортувань, що завершилися не довше ніж за дві секунди. SLI має визначити, які спроби входять у знаменник: усі валідні запити на створення експорту, включно з серверними помилками й тайм-аутами. SLO може звучати як «99,9% таких запитів за 30 днів завершуються правильно до двох секунд». Це числове формулювання є вигаданим прикладом, не рекомендацією. SLA треба звірити з договором: він може використовувати іншу часову межу, період, виключення чи компенсацію.

Якщо SLO дорівнює 99,9% для вибраної сукупності дій за 30 днів, різниця до 100% — 0,1% — є допустимою часткою невідповідності в межах цього визначення. Бюджет помилок (error budget) — спосіб відстежувати накопичену частину цього допуску за визначений період. Він допомагає приймати продуктові й операційні рішення, а не надає дозвіл навмисно погіршувати поведінку для користувача. Рішення про зупинку випусків або інвестицію в надійність ухвалюють відповідальні власники, з урахуванням наслідків і доказів. Google SRE Workbook показує, як швидкість витрачання бюджету (burn rate) може дати корисні сповіщення з кількома часовими вікнами; її значення треба читати разом із кількістю запитів, наслідком і самим періодом SLO. Google SRE Workbook: Alerting on SLOs

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

61.9. Сповіщення, на яке є наступна дія

Сповіщення (alert) має відповідати на питання: що сталося, кого це зачепило, який поріг або вікно порушено, хто відповідає та що перевірити першою дією. Кількість сповіщень не є показником якості моніторингу. Якщо на кожний запис ERROR приходить окреме повідомлення, один збій може перекрити оператору сигнал, який справді потребує уваги. Google SRE прямо застерігає, що шумні сторінки втомлюють людей і можуть затримати відновлення; рекомендації Prometheus радять сигналізувати про користувацький симптом і не створювати сторінку, на яку нема що робити. Google SRE: Monitoring Distributed Systems, Prometheus: Alerting

Залежно від тяжкості, повідомлення може йти на чергування, у робочу чергу або лише в журнал. Для кожного важливого сповіщення визначте:

• Умову: показник, допустимий поріг, вимірювальне вікно та час очікування до сигналу. Короткий одиничний стрибок може бути очікуваним, а для фонового завдання поріг часто залежить від його розкладу.
• Наслідок: яка дія користувача не працює або які дані стають неповними.
• Власника: команда чи конкретна чергова роль, що може виконати перший крок.
• Дедуплікацію й групування: які повтори є проявом тієї самої проблеми й за який інтервал вони об’єднуються.
• Ескалацію: кому передати проблему, якщо немає відповіді в узгоджений час.
• Підказку до перевірки: лінк або коротку інструкцію, де знайти метрики, свіжі журнали й репрезентативну трасу.

Повний приклад: тисячі повідомлень про один збій

У вигаданому імпорті зовнішнє джерело перестало відповідати. За дві хвилини сервіс записав 4 800 однакових тайм-аутів і почав повторювати запит із затримкою між спробами. Якщо кожна подія породить сторінку черговому, людина побачить сотні копій замість масштабу й наступного кроку. Вона може витратити час на закриття сповіщень, а не на перевірку стану джерела, повторів і свіжості даних.

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

Для навчального прикладу сторінка про рівень невдач надходить, якщо за ковзні 10 хвилин неуспішні допустимі оновлення перевищили 5% від усіх оновлень, які мали бути виконані в цьому вікні; прострочене або взагалі не створене завдання також рахується невдачею. Правило діє лише за наявності щонайменше 20 очікуваних оновлень і має тривати дві хвилини, перш ніж надійде сторінка. Окреме сповіщення про свіжість надходить, коли вік останнього успішно зафіксованого імпорту перевищує продуктову межу 40 хвилин; воно працює навіть тоді, коли планувальник не створив жодного завдання. Повтори групуються протягом десяти хвилин за сервісом, залежністю та середовищем. Якщо черговий не підтвердив сторінку за п’ять хвилин, її отримує керівник зміни. Усі ці числа вигадані й не є універсальною конфігурацією.

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

61.10. Вартість, приватність, кардинальність і строк зберігання

Телеметрія також є даними продукту: її потрібно збирати, передавати, індексувати, захищати й видаляти за зрозумілими правилами. OpenTelemetry не може самостійно визначити, що є чутливим у конкретному продукті; відповідальність за мінімізацію, доступ і перевірку інструментації лежить на команді. OpenTelemetry: Handling sensitive data

Кардинальність — кількість різних значень певного поля чи комбінації полів. У метриках кожна унікальна комбінація міток може створити окремий часовий ряд. Мітка з невеликою множиною значень, як середовище або тип маршруту, може бути корисною; мітка з ідентифікатором запиту, адресою електронної пошти чи користувацьким ID швидко розростається й дорого індексується. Документація Prometheus прямо застерігає від міток із необмеженими наборами значень на кшталт user ID та email. Для пошуку конкретної операції використовуйте контекст журналу чи траси з політикою доступу й зберігання, а не перетворюйте кожен запит на новий ряд метрик. Prometheus: Metric and label naming

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

Практичні правила мінімізації:

1. Не записуйте токени, паролі, секрети інтеграцій, повні платіжні реквізити чи приватний вміст запитів.
2. Замість повного тіла події зберігайте тип, розмір, результат перевірки, контрольовані атрибути й посилання на джерело з обмеженим доступом.
3. Для особистих даних використовуйте найменш чутливий формат, потрібний для розслідування; псевдонімний ідентифікатор також може залишатися персональними даними.
4. Розділіть ролі доступу: не кожен, хто може переглянути графік, має отримати право прочитати приватні журнали чи сирий вміст переданих даних.
5. Визначте строки зберігання за користю й ризиком. Короткоживучий діагностичний запис і агрегована історія продуктивності можуть мати різні строки, якщо це дозволяють потреби продукту й правила організації.
6. Перевіряйте не лише власний код, а й бібліотеки інструментації: автоматичний збирач може додати атрибути, які команда не планувала зберігати.

Вибіркове збереження допомагає втримувати вартість, але має ціну. Якщо зберігається лише мала частка випадкових трас, рідкісну помилку можна не побачити; якщо рішення про збереження приймається на початку запиту, ще невідомо, чи буде він повільним. Вибір після завершення траси може зберегти повільні й невдалі приклади, проте потребує буфера й окремої уваги до самого збирача. Умови регулювання, низький обсяг сигналу або потреба в повному обліку можуть зробити вибіркове збереження невідповідним. Не застосовуйте відсікання до базових лічильників якості так, ніби вони й надалі рахують кожну допустиму дію: якщо вибірка впливає на SLI, метод оцінювання має враховувати це й бути перевіреним. OpenTelemetry: Sampling

61.11. Спостерігайте за засобом спостереження

Збір телеметрії може запізнюватися, відкидати записи, втрачати доступ до сховища або не мати контексту для певного компонента. Тому корисно стежити і за шляхом сигналу: час останнього успішного експорту, обсяг черги телеметрії, лічильник відкинутих записів, доступність збирача та помилки приймання. Інакше тиша на графіку може означати як «нічого не відбулося», так і «ми не бачимо, що відбувається». Додаткове зовнішнє перевіряння доступності моніторингу допомагає виявити ситуацію, коли внутрішня система вже не може повідомити про власну несправність. Prometheus: Alerting — metamonitoring

Реальний приклад межі телеметрії — відмова центру обробки даних Cloudflare в листопаді 2023 року. Cloudflare описує, що їхні засоби не виявили перехід на живлення від генераторів; першим повідомленням про проблему для Cloudflare стало зникнення двох маршрутизаторів о 11:44 за UTC. Компанія очікувала, що під час повної втрати майданчика журнали будуть накопичуватися на периферії й надійдуть пізніше, але системи оброблення журналів і аналітики теж залежали від сервісів у цьому майданчику. Повністю вимкнути весь майданчик у попередніх перевірках не пробували, тому приховані залежності не проявилися. У звіті немає числового графіка віку черги чи універсального порогу тривоги; їх не слід домислювати. Кейс показує дві конкретні прогалини: зміна джерела електроживлення не породжувала потрібного сигналу, а частина запланованої телеметрії залежала від тієї самої відмови. Частину пояснення електричної причини сама компанія позначила як непідтверджене припущення. Cloudflare: Post mortem on the Control Plane and Analytics Outage, 4 листопада 2023 року

Реальні кейси підказують питання для власної системи, але не дають готової конфігурації для чужого сервісу. Визначте, який незалежний сигнал повідомить про втрату важливого каналу спостереження й де він зберігатиметься, якщо основний майданчик чи система телеметрії недоступні.

61.12. Що може й чого не може агент, який читає сигнали

Агент може зіставити ревізію, журнали, показники й кілька трас, підготувати коротку хронологію та запропонувати перевірювані пояснення. Наприклад: «Після версії 2026.09.24.3 зросли затримки маршруту місячного звіту; у вибраних повільних трасах більшість очікування припала на сервіс прав; попередня ревізія в той самий час також має повільні виклики. Це послаблює гіпотезу про регресію всієї версії. Наступна перевірка — порівняти число викликів залежності за маршрутом». Такий результат відокремлює спостережене від висновку й називає доказ, який може спростувати гіпотезу.

Доступ агента визначається середовищем, інструментами, дозволами й політикою організації; сама модель не отримує телеметрію автоматично. Публічний опис власного розгортання Codex в OpenAI показує, як організація може дозволити читальні команди на кшталт перегляду журналів Kubernetes, обмежити мережеві напрямки й зберігати події агента для аудиту. Це опис конкретної внутрішньої практики, а не загальне твердження, що кожна інсталяція Codex має такі дозволи чи вже підключена до журналів сервісу. Налаштування Codex відрізняються за інтерфейсом, середовищем і керованими політиками. OpenAI: Running Codex safely at OpenAI

У Claude Code (агентному інтерфейсі Anthropic для роботи з репозиторієм і командними інструментами) офіційна документація описує правила дозволів для окремих інструментів і шляхів: наприклад, дозволити читання певних файлів або обмежити команду Bash. Це не робить усі команди командного рядка безпечними й не означає, що правило для однієї команди охопить інші способи її виклику. Так само конфігурація прав і доступних інструментів залежить від інсталяції та параметрів організації. Anthropic: Configure permissions for Claude Code

Для безпечного аналізу корисні такі межі:

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

Телеметрія самого агента відповідає на додаткове запитання: що він прочитав, які інструменти викликав, які дозволи отримав або не отримав і на чому ґрунтував висновок. Це не замінює журнали та метрики продукту. В описаному OpenAI прикладі журналювання Codex може містити запити користувачів, рішення про дозволи, результати інструментів і використання підключень; такі записи самі можуть мати чутливий вміст. Їх треба проєктувати, зберігати й надавати з таким самим принципом мінімізації доступу, як і іншу телеметрію. Для актуальної поведінки OpenAI та Anthropic перевіряйте саме той продукт, версію, інтерфейс і конфігурацію, які реально використовуються; документацію в цій главі для цих тверджень повторно звірено 10 жовтня 2026 року. OpenAI: Agent-native telemetry and audit trails, Anthropic: Permissions

61.13. Короткий зворотний зв’язок для продукту

Спостережуваність має скорочувати час між зміною, появою наслідку та дією відповідального, а також допомагати перевірити, чи відновився потрібний користувацький сценарій. Це сумісно з ідеями Accelerate про поліпшення доставки програмного забезпечення й із настановою DORA вимірювати поведінку, яка допомагає приймати рішення; жоден графік сам по собі не створює короткого циклу зворотного зв’язку. Потрібні зрозуміле питання, надійний вимір і призначена дія. Сторінка видавця описує Accelerate як книгу про результати дослідження способів вимірювання ефективності доставки й практик, які її підтримують. Accelerate, IT Revolution Press, DORA: Monitoring and observability

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

Короткий підсумок

1. Моніторинг перевіряє відомі ознаки, а спостережуваність допомагає досліджувати те, для чого ще немає готового пояснення. Обидва починаються з користувацького наслідку.
2. Журнал пояснює окремі події, метрика показує зміну в часі, траса описує шлях операції між компонентами. Разом вони дають масштаб, приклади й ділянки очікування.
3. Для метрики називайте вимір, знаменник, одиницю, версію та часове вікно. Середнє не замінює перцентиль, а оцінений перцентиль залежить від обсягу вибірки й способу агрегації.
4. Успішна відповідь сервера, запущений фоновий обробник чи порожня черга не доводять, що фонова обробка завершилася, записи повні, а репліка актуальна.
5. SLI — вимір, SLO — ціль, SLA — зовнішнє зобов’язання. Бюджет помилок допомагає обговорювати невідповідність, а не виправдовує навмисну шкоду.
6. Сповіщення має сигналізувати про користувацький симптом і вести до дії власника; повторні журнали можна групувати, зберігаючи обсяг, контекст та окремі прояви іншого впливу.
7. Доступ, строк зберігання, вибіркове збереження й кардинальність — частина проєктування, а не післямова до збору даних.
8. Агент може зібрати факти й підготувати гіпотезу на дозволених доказах. Неповний лог і кореляція самі по собі не виправдовують виробничу зміну.

Джерела та подальше читання

1. OpenTelemetry, Signals. Офіційне пояснення журналів, метрик і трас як різних типів телеметрії. Profiles — четвертий сигнал зі статусом Alpha. Перевірено 10 жовтня 2026 року. https://opentelemetry.io/docs/concepts/signals/ ; https://opentelemetry.io/docs/concepts/signals/profiles/
2. OpenTelemetry, Context propagation. Контекст між компонентами, зв’язування ідентифікаторів трас і журналів, безпека передавання контексту. Перевірено 24 вересня 2026 року; сторінку оновлено 10 серпня 2026 року. https://opentelemetry.io/docs/concepts/context-propagation/
3. OpenTelemetry, Metrics data model. Модель точок метрик, лічильників і гістограм; агрегування й обмеження інтервалів. Версія специфікації актуальна на дату перевірки. https://opentelemetry.io/docs/specs/otel/metrics/data-model/
4. OpenTelemetry, Sampling. Вибіркове збереження трас, різниця між рішенням на початку та після завершення шляху, компроміси вартості й втрачених доказів. Перевірено 24 вересня 2026 року. https://opentelemetry.io/docs/concepts/sampling/
5. OpenTelemetry, Handling sensitive data. Обов’язки команди щодо мінімізації й чутливих атрибутів телеметрії. Перевірено 24 вересня 2026 року. https://opentelemetry.io/docs/security/handling-sensitive-data/
6. Google Site Reliability Engineering, Monitoring Distributed Systems. Користь і межі моніторингу, сповіщення, шум і втома від надмірних сторінок. Перевірено 24 вересня 2026 року. https://sre.google/sre-book/monitoring-distributed-systems/
7. Google Site Reliability Engineering, Service Level Objectives. Визначення SLI/SLO, перцентилі та роль продуктового рішення у виборі цілі. Перевірено 24 вересня 2026 року. https://sre.google/sre-book/service-level-objectives/
8. Google Site Reliability Workbook, Alerting on SLOs. Швидкість витрачання бюджету, часові вікна, компроміс швидкості й точності сповіщення. Перевірено 24 вересня 2026 року. https://sre.google/workbook/alerting-on-slos/
9. Prometheus, Histograms and summaries. Різниця між гістограмами й підсумками, оцінювання перцентилів, агрегація та похибка інтервалів. Офіційна документація, перевірено 24 вересня 2026 року. https://prometheus.io/docs/practices/histograms/
10. Prometheus, Metric and label naming. Найменування метрик та застереження щодо високої кардинальності міток. Перевірено 24 вересня 2026 року. https://prometheus.io/docs/practices/naming/
11. Prometheus, Alerting. Сповіщення про користувацькі симптоми, фонові завдання та перевірка самої системи моніторингу. Перевірено 24 вересня 2026 року. https://prometheus.io/docs/practices/alerting/
12. Cloudflare, Post mortem on the Cloudflare Control Plane and Analytics Outage, 4 листопада 2023 року. Першоджерело про незареєстровану зміну живлення, запізніле виявлення та залежності журналів/аналітики від недоступного майданчика. Перевірено 24 вересня 2026 року. https://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/
13. Cloudflare, Cloudflare incident on June 20, 2024, 20 червня 2024 року. Першоджерело про виявлення за навантаженням процесора, показники HTTP-помилок і затримки, а також про те, як паралельний мережевий інцидент вплинув на початкову гіпотезу. Перевірено 24 вересня 2026 року. https://blog.cloudflare.com/cloudflare-incident-on-june-20-2024/
14. OpenAI, Running Codex safely at OpenAI. Опис конкретного внутрішнього розгортання Codex: межі виконання, правила схвалення, читальні команди й журнали агента. Це приклад організаційної практики, а не універсальні значення за замовчуванням для кожного користувача Codex. Перевірено 10 жовтня 2026 року. https://openai.com/index/running-codex-safely/
15. Anthropic, Configure permissions for Claude Code. Офіційні правила дозволів інструментам і шляхам у Claude Code; поведінка залежить від конкретного продукту й конфігурації. Перевірено 10 жовтня 2026 року. https://code.claude.com/docs/en/permissions
16. Martin Kleppmann та Chris Riccomini, Designing Data-Intensive Applications, 2nd edition, O’Reilly Media, березень 2026 року. Актуальне видання й авторство підтверджені сторінкою автора та сайтом книги; повний текст у цьому дослідженні не переглядався, тому глава не приписує йому сторінкових цитат чи конкретного навчального прикладу. https://martin.kleppmann.com/ ; https://dataintensive.net/
17. Nicole Forsgren, Jez Humble та Gene Kim, Accelerate: The Science of Lean Software and DevOps, IT Revolution Press, 27 березня 2018 року. Сторінка видавця підтверджує назву, авторів і дату; використовується як джерело про вимірювання та поліпшення доставки, а не як доказ, що одинична кореляція спричинила покращення. https://itrevolution.com/product/accelerate/
18. OpenTelemetry, Language APIs & SDKs. Статус зрілості окремих сигналів за мовами програмування. Перевірено 10 жовтня 2026 року. https://opentelemetry.io/docs/languages/
19. DORA, Monitoring and observability. Відмінність між перевіркою наперед визначених умов і пошуком невідомих заздалегідь властивостей. Перевірено 24 вересня 2026 року. https://dora.dev/capabilities/monitoring-and-observability/