Расследование ломается, когда участник передаёт «есть trace, посмотри worker» без границы данных. Следующий инженер не знает, какой пользовательский путь имелся в виду, что было отобрано sampling rule, какие поля уже отфильтрованы и где оборвался context. Цена — не только потерянное время. В hand-off попадает либо слишком мало смысла для проверки, либо лишний payload, который потом начинает жить в чатах и таблицах дольше самой задачи.
На 31.07.2026 это не отчёт из production и не описание августовского инцидента. Ни один пользовательский сценарий не был наблюдён, никакие логи не читались, ничего не измерялось. Ниже — плановый synthetic hand-off: fixed literals, заранее названные stops и один положительный исход, который разрешает лишь обсудить будущую работу, но не даёт доступа, approval, release или deployment.
Evidence начинается с вопроса, который можно передать
Плохой вопрос: «почему checkout медленный?». Он смешивает UI, сеть, API, очередь, worker и продуктовый результат. Плановый вопрос уже: «в fixed scenario есть ли один named context на UI, API и worker, и не содержит ли signal map запрещённое поле?». Он не обещает найти причину. Зато другой reviewer может получить тот же status без внешней панели, устного контекста и доступа к customer data.
В этом сценарии evidence состоит не из скриншота. Это карта трёх signals, fixed context, маленький allow-list полей, запретный список и named sampling rule. Скриншот может быть полезен в authorised investigation, но сам по себе он скрывает query, время, фильтр и доступ. Здесь нет такого артефакта, чтобы не создать ложное ощущение уже проведённого исследования.
| Поле | Что передаётся в сценарии | Чего получатель не получает | Стоп |
|---|---|---|---|
| question | проверка одной UI → API → worker связи | incident narrative | вопрос шире данных |
| context | fixed-trace-7f | реальный trace header | одна граница пуста |
| signal map | 3 named signal classes | payload, URL query, user id | встречается forbidden field |
| sampling | fixed planned rule + reason | coverage, объём, SLA | rule не названо |
| result | synthetic plan hand-off | production permission | positive verb сильнее hand-off |
Retaining context не означает retaining payload
Для передачи полезен минимальный identity-free identifier, если он существует только внутри fixed literal. Он даёт reviewer возможность сравнить три записи модели. Но он не должен открывать путь к реальному профилю, заказу или сообщению. Поэтому никакого raw user id нет даже в log example. Если будущему расследованию понадобится связь с персональными данными, это должен быть отдельный authorised процесс с отдельным purpose, storage и access review. Нельзя добавить поле задним числом, потому что «иначе неудобно дебажить».
Retention тоже нельзя выдавать за техническую мелочь. Срок определяется не возможностью collector, а тем, что именно и зачем хранится. В этом пакете retention не задан намеренно: нет реального data class и владельца. Это не пробел, который надо заполнить произвольным количеством дней. Это stop для будущей работы: пока контур не определил purpose и data boundary, rule хранения не является инженерным фактом.
Исполняемая проверка payload boundary
import { createFixedObservabilityPlan, reviewFixedObservabilityHandOff } from './upgrade-2026-08.mjs';
const unsafe = createFixedObservabilityPlan('personal-field-v1');
const result = reviewFixedObservabilityHandOff(unsafe);
console.log({ status: result.status, fields: result.fields, next: result.nextAction });
// { status: 'stop-forbidden-signal-field', fields: ['email'], next: 'replace-with-named-low-cardinality-class-or-omit' }Snippet не ищет email в системе: он получает заранее названный literal, JSON-cloned и deep-frozen. Поэтому вывод строго локален: этот учебный input не проходит boundary. Он не доказывает утечку, не объявляет набор данных персональным по закону и не сообщает результат третьей стороне. Такая точность нужна, чтобы stop не стал неосторожным security claim.
Как идти по investigation loop
Первый reviewer проверяет связность context. Второй проверяет семантику signals: не пытаются ли metric labels стать журналом, а logs — неструктурированным дампом. Третий читает sampling reason и заголовок hand-off: не обещает ли он того, чего fixed input не может знать. Эти роли не нужны как должности. Это три вопроса, которые нельзя заменить одним «посмотрел дашборд». В сценарии они последовательно либо уменьшают область, либо оставляют именованный stop.
Если worker context пуст, результат stop-broken-correlation-context. Если в безопасных fields появляется email, результат stop-forbidden-signal-field. Если автор меняет hand-off на deploy-observability, validator возвращает stop-disallowed-positive-result. Важно не «починить статус» вручную: у каждого stop есть next action, а положительный результат не пытается выдать себя за решение о системе.
Порядок планового расследования в августе
- Записать, что это сценарий на август 2026 и что источники ограничены 31.07.2026.
- Сузить вопрос до одного named path, без слов «вся задержка» и «все ошибки».
- Проверить один fixed correlation context на UI, API и worker; при разрыве остановиться.
- Проверить allow-list и forbidden-list attributes до разговора о retention или поиске данных.
- Зафиксировать sampling как будущую гипотезу и не приписывать ей coverage, cost или effect.
- Передать synthetic evidence map следующему reviewer либо сохранить stop и его precise next action.
Почему sampling не может быть оправданием для доступа
Иногда sampling формулируют как «сохраним только немного, значит можно собирать подробнее». Это неверная логика. Отбор уменьшает количество выбранных traces, но не изменяет purpose конкретного поля и не превращает payload в outcome-class. В плановом сценарии rule нужна лишь для будущего discussion о границе объёма. Она не создаёт право читать данные, не подтверждает budget и не делает trace с персональным атрибутом приемлемой.
Для errors правило может отличаться от normal path, но это также не доказательство, что error trace безопаснее. Ошибка часто несёт больше случайного контекста, а не меньше. Поэтому план требует сначала назвать classes и запрещённые значения, а уже затем обсуждать вариацию sampling. Если такого порядка нет, team получает не observability design, а произвольное исключение для самого чувствительного набора событий.
Что именно передать следующему reviewer
Хороший hand-off меньше похож на ссылку и больше — на карточку проверки. В нём есть один вопрос, версия schema, named context, список разрешённых полей, список запрещённых полей, sampling reason, дата сценария и source boundary. Этого достаточно, чтобы другой инженер повторил проверку literal и понял, почему результат не сильнее плана. В нём специально нет customer payload, снимка панели, «успешной» длительности и общего вывода о сервисе. Чем больше таких свободных деталей, тем труднее отличить evidence от интерпретации.
Получатель hand-off имеет три законных действия. Он может подтвердить структуру и оставить её synthetic. Он может вернуть конкретный stop: например, потребовать owner у job-kind или найти forbidden field. Он может инициировать отдельный процесс с полномочиями на реальный discovery, но только как новый scope. Чего он не может — переназвать hand-off в approval и включить существующий pipeline. Это ограничение записано не ради формальности: в технической коммуникации именно на переходе между людьми чаще всего модель незаметно получает несуществующий production effect.
Как не спутать retention с архивом расследования
Retention появляется после того, как данные уже признаны нужными для определённой цели; архив расследования возникает после того, как кто-то собрал больше, чем может объяснить. Первый вариант требует schema и политики до записи. Второй обычно оправдывает лишний payload задним числом. Августовский сценарий выбирает первый порядок, но не назначает срок: без реального data class, business purpose и access model число дней было бы произвольным. Полезная техническая работа здесь — подготовить вопросник, а не заполнить retention cell правдоподобной цифрой.
Отдельно надо проверять производные поля. Хеш, сокращённый URL или «обезличенный» идентификатор не становятся автоматически low-cardinality class. Если значение уникально на событие, оно всё ещё дробит series; если его можно связать с субъектом, он всё ещё нуждается в отдельной оценке. Поэтому validator не пытается угадывать безопасность преобразования. Он допускает только заранее named safe classes и останавливает любой literal, где запрещённое поле уже присутствует. Это ограничение делает hand-off скромнее, но честнее.
Граница будущего field work
Сценарий не запускает browser, API client, queue consumer или telemetry SDK. Он не читает headers, files, logs, metrics, secrets, dashes или сеть. Он не фиксирует инцидент, не сравнивает периоды, не подтверждает SLA и не даёт заключение о production privacy. Источники до cutoff описывают vocabulary и standard context, но не авторизуют такую деятельность и не заменяют внутреннюю policy.
Следующий шаг — перед тем как создавать реальный инструментальный план, согласовать один data contract: какие technical identifiers разрешены, где они удаляются, кто владелец schema, какой consumer нуждается в поле и какой stop сработает при неизвестном источнике. Если это нельзя назвать, не переходить к retention table и не рисовать будущий incident graph. Вернуть hand-off как неполный план — честнее, чем задним числом сочинить evidence.
Проверяемые источники
- OpenTelemetry Specification, trace API and metrics data model — версия: immutable commit c6520a73287040ca16499cba62cea1b3508dc4da, Release 1.29.0, 11 January 2024. Pinned OpenTelemetry source используется для различения trace context, signal attributes и metrics vocabulary. Граница: Source не утверждает, что предлагаемый hand-off достаточен для incident response, retention или privacy review.
- W3C Trace Context — версия: W3C Recommendation, dated 23 November 2021. W3C Recommendation фиксирует формат и перенос trace context, а также наличие privacy/security considerations. Граница: Recommendation не даёт доступ к trace data и не определяет организационные полномочия расследования.