Проблема performance review появляется, когда короткий интервал объявляют эффектом изменения. Цена — принятие решения, которое невозможно воспроизвести: исчезла ли задержка, изменилась ли нагрузка, или сравнили разные пути? Полевая дисциплина здесь скромнее: собрать evidence, потребовать контрпример и передать решение только как synthetic hand-off.
В этой статье нет real benchmark и нет обещания улучшения. Есть один положительный исход — корректно оформленная запись для review. Она показывает, что наблюдали, какую границу контролировали, что могло опровергнуть вывод и почему production effect остаётся no-system-change.
Цикл evidence → контрпример → решение
Evidence — complete timed tree с отдельным queue-wait. Контрпример — литерал, нарушающий одно из условий: отсутствующий parent, другая нагрузка, неразмеченное ожидание или готовая фраза «стало быстрее». Решение — либо принять наблюдение к review, либо назвать конкретную stop reason. Важная деталь: решение не выбирает оптимизацию; оно выбирает, достаточно ли материала для следующего вопроса.
| Поле | Содержимое в accepted input | Пример отказа | Следующее действие |
|---|---|---|---|
| След trace | fixed-trace-01, complete tree | parent отсутствует | восстановить named span |
| Контрольная граница | fixed-load-a; 12; 3; fixed-read-shape-a | 24; 6; fixed-read-shape-b | не сравнивать |
| Кандидатный сегмент | fixed-admission-queue, 520 units | unclassified-delay | назвать очередь или оставить unknown |
| Эффект | not-made | faster-after-change | снять claim и записать наблюдение |
Как формулировать запись
Хорошая запись коротка: «В fixed-trace-01 при fixed-load-a queue-wait — 520 из 1 000 units и длиннее двух других названных сегментов. Сравнение и effect claim не выполнялись. Handoff: synthetic-performance-review». Она не обещает latency, не приписывает причину и не маскирует пробел словом «вероятно».
Плохая запись звучит убедительнее: «после уменьшения DB path система стала быстрее». В unsupported-effect-v1 ей соответствует смена root interval и faster-after-change, но отсутствует допустимый контрольный результат. Функция обязана вернуть stop; иначе review легализует вывод по одному наблюдению.
Буквально исполнимый отказ
import { createFixedPerformanceReviewInput, reviewFixedPerformanceInput } from './upgrade-2026-05.mjs';
const result = reviewFixedPerformanceInput(
createFixedPerformanceReviewInput('unsupported-effect-v1'),
);
console.log({
accepted: result.accepted,
status: result.status,
nextAction: result.nextAction,
effect: result.effect,
});Роли на review
Автор материала отвечает за именованные literals и отсутствие скрытой сети. Рецензент trace проверяет связность и классификацию ожидания. Рецензент решения проверяет, что baseline имеет ту же нагрузочную границу и что заголовок не сильнее evidence. Эти роли не делают текст тяжёлым: они отсекают три дешёвые ошибки до обсуждения архитектуры.
Шаблон решения без ложной уверенности
Запись review удобно разбить на четыре строки. Evidence: какой fixed input прочитан и какие интервалы в нём названы. Boundary: cohort, requests, concurrency и shape, с которыми разрешено сравнение. Counterexample: какой named fixture отменит текущий вывод. Decision: hand-off или stop reason. В такой форме автор не может незаметно заменить факт на план, а рецензент может указать конкретное отсутствующее звено.
Для accepted input решение будет: evidence — complete fixed-trace-01; boundary — fixed-load-a/12/3/shape-a; counterexample — unknown-delay или иной load; decision — synthetic-performance-review. Здесь нет строки «оптимизировать очередь». Если участник review хочет добавить её, он должен принести отдельное evidence и явно сформулировать новый вопрос. Это удерживает текущую заметку в роли проверки, а не скрытого технического решения.
Как рецензировать заголовок и вывод
Заголовок может обещать только то, что читатель найдёт в evidence. В P99 допустимы «как не оптимизировать до границы» и «performance review без обещаний», потому что текст описывает стоп-условия. Недопустимы «как ускорить систему» или «найти bottleneck за минуту»: у них сильнее модальность, чем у fixture. Эта проверка особенно важна для field article, где уверенная редакционная фраза легко воспринимается как production guidance.
Проверка вывода ещё проще: заменить все технические слова на поля литерала. Если остаётся предложение, которого нельзя указать пальцем в input или в явном status, его нужно ослабить либо удалить. «Queue-wait — длиннейший named segment» выживает. «Очередь является корнем проблемы» — нет. «Изменение БД ускорит путь» — нет. Такой self-review занимает минуты и часто обнаруживает главный дефект до публикации.
Пределы безопасной эскалации
Handoff передаёт вопрос, а не право менять систему. Получатель может решить, что для следующего synthetic exercise нужно добавить литерал со строго одинаковым load boundary и одной изменённой характеристикой. Он также может отклонить задачу, если классификация ожидания недостаточна. Обе реакции корректны. Некорректно превратить accepted fixture в реальный benchmark, включить клиент или читать метрики: эти действия явно вне boundary пакета.
Именно поэтому в каждом результате присутствует effect: no-system-change. Это не декоративное поле. Оно делает ограничение машинно видимым в примере и редакционно видимым в статье. Даже если future reader согласен с гипотезой, он не получит из этого кода разрешение на rollout, гарантию latency или утверждение о фактическом пользователе.
Хороший field review завершает спор там, где заканчиваются данные. Он не требует искусственного консенсуса о причине и не записывает отсутствие информации как риск «на потом». Вместо этого он оставляет проверяемый след: вход, проверенные условия, точную стоп-причину или узкий hand-off. Такой след можно перечитать через месяц без доступа к окружению, потому что он не опирается на память автора, скрытые панели или состояние реального сервиса.
Итоговый критерий прост: другой рецензент должен получить тот же status, запустив public export с тем же named literal. Если для понимания нужны устные пояснения, внешний дашборд или догадка о том, что автор имел в виду, пакет не готов. P99 оставляет ровно тот объём информации, который можно проверить локально и передать без расширения утверждения.
Это ограничение сохраняется и после публикации: текст объясняет процедуру, но не меняет природу evidence и не создаёт дополнительного доказательства.
Чек перед hand-off
- Есть один root и complete parent tree; длительности — условные значения фиксированного input.
- Очередь отделена от БД и внешней зависимости или явно помечена unknown.
- Baseline и candidate имеют одинаковые cohort, logicalRequests, concurrency и input shape.
- В тексте нет «ускорили», «bottleneck устранён», «готово к rollout» или другого effect claim.
- Выход функции — synthetic review hand-off либо именованный stop, никогда не production recommendation.
Как использовать контрпример в разговоре
Контрпример не обязан опровергать всю систему. Достаточно разрушить одно звено конкретного вывода. Для incomplete-trace-v1 отсутствующий parent не позволяет говорить о critical path. Для hidden-queue-v1 неизвестная задержка не позволяет говорить «очередь». Для incomparable-load-v1 смена cohort отменяет сравнение. Эти отказы точнее, чем общий комментарий «нужно больше данных».
Рецензенту полезно возвращать именно статус и следующее действие. Например, stop-unsupported-effect просит снять claim и оставить observation; он не доказывает обратное и не спорит с автором о реализации. Так контрпример становится частью рабочего протокола, а не риторическим препятствием. Когда условия восстановлены, тот же формат допускает повторный review.
Почему hand-off остаётся узким
Даже accepted результат не назначает команду и не меняет конфигурацию. Он разрешает сохранить одну проверяемую мысль: где в фиксированном литерале расположен самый длинный названный сегмент. Всё остальное — причина, стоимость исправления, влияние на пользовательский путь — требует отдельной границы и отдельного материала. Узость результата делает его переносимым между рецензентами.
| Результат | Что означает | Чего не означает |
|---|---|---|
| observation-ready | структура input пригодна для review | оптимизация доказана |
| synthetic-performance-review | запись можно обсуждать | есть rollout |
| stop reason | известен недостающий факт | система медленна |
| no-system-change | production effect не рассматривался | эффекта нет в реальности |
Ограничения и следующий шаг
Такая карточка не измеряет throughput, не отражает queue discipline, не оценивает хвост распределения и не заменяет эксплуатационную проверку. RFC 9110 описывает семантику HTTP, а не latency contract; стандарты trace описывают связь контекста, а не полноту наблюдений. Следующий безопасный шаг — расширить только fixed fixture новым контрпримером и снова проверить, что outcome остаётся review, не guarantee.
Проверяемые источники
- W3C Trace Context — версия: Recommendation, 23.11.2021, immutable publication. Фиксирует формат traceparent и смысл trace-id/parent-id для связности распределённой trace. Граница: Опираемся только на идентификацию и связь; не выводим производительность из стандарта.
- OpenTelemetry Specification Trace API — версия: v1.29.0, commit c6520a7, 11.01.2024. Задаёт различение CLIENT, SERVER, PRODUCER и CONSUMER span как описательных ролей. Граница: Роль span не доказывает причину задержки и не является метрикой.
- RFC 9110: HTTP Semantics — версия: RFC 9110, June 2022. Определяет HTTP как stateless application-level protocol и отделяет протокольную семантику от измерения времени. Граница: Не используем RFC для обещаний latency, capacity или реального поведения системы.