Автономное тройное ревью П34 · декабрь 2020 · «Разбор инцидента»

Статус: принят независимым редактором в выпусковой набор. Пакет содержит ровно три revision для стабильных slug:

editorial-2020-12-practice-incident-review;
editorial-2020-12-mechanism-incident-review;
editorial-2020-12-field-incident-review.

Созданы только пять разрешённых файлов П34:

web/scripts/upgrade-2020-12.mjs;
web/public/assets/editorial/2020/incident-timeline-2020.svg;
web/public/assets/editorial/2020/incident-decision-record-2020.svg;
web/public/assets/editorial/2020/incident-learning-loop-2020.svg;
этот документ.

Revision-модуль экспортирует только изменяемые редакционные поля и не содержит date или author. Он не подключает registry. articles.json, registry, README, очередь, package config и Git этой партией не менялись. Команда --print-revisions печатает только JSON, а --verify-fixture запускает отдельную детерминированную проверку в памяти.

Проход 1. Факты и техническая рамка — пройдено

Утверждение	Первичный или официальный источник	Проверенная граница
Управление инцидентом выигрывает от живой записи состояния, разделения работы и явного восстановления	Google SRE Book: Managing Incidents	В текст перенесён только малый каркас «наблюдение → гипотеза → действие → проверка», без утверждения, что у автора есть сложный процесс управления инцидентами
Postmortem документирует влияние, действия, contributing causes и follow-up; разбор без обвинения ищет условия системы, а не персональную вину	Google SRE Book: Postmortem Culture	Статьи говорят о component, поле, контракте и проверке; fixture не содержит имён или ролей людей
Диагностика строится на наблюдениях, проверяемых гипотезах и полезном отрицательном результате	Google SRE Book: Effective Troubleshooting	H1 отделена от E2; непрохождение V1 описано как новый факт, а не как повод переписать историю
Для security-инцидентов NIST описывает цикл подготовки, обнаружения, анализа, сдерживания и post-incident activity	NIST SP 800-61 Rev. 2	Источник используется только как общий ориентир жизненного цикла; статья не называет учебный случай security-инцидентом и не выдаёт его за нормативную процедуру

Весь технический случай создан в runIncidentFixture(). В нём пять синтетических событий с последовательностью E1, E2, H1, A1, V1; один decision record D1 и два профилактических пункта P1/P2 в состоянии planned. Значения не взяты из журнала, сетевого запроса, пользовательской истории или production-системы:

E1 фиксирует только учебное состояние blocked на границе preview-order;
E2 фиксирует отсутствие currency после mapper;
H1 — явно изменяемая гипотеза, основанная на E2;
A1 — ограниченный выбор прежнего mapper в памяти fixture;
V1 — отдельная проверка A1, а не заявление о здоровье системы;
P1/P2 остаются planned и имеют будущие checks.

В fixture запрещены непустые или переставленные ссылки: hypothesis требует раннее observation, action — раннюю hypothesis, verification — раннее action. Также проверяются decision trigger/expected check, конкретность профилактики и отсутствие атрибуции людям. Она намеренно не моделирует HTTP, proxy, базу, очередь, browser, мониторинг, deployment, реальный трафик или логи. В статьях нет claim о реальном инциденте, числовой норме доступности, времени восстановления или зрелой платформе надёжности.

Вердикт прохода: пройден. Источники отделены от учебной модели, а учебная модель — от настоящей операционной среды.

Проход 2. Редактура, глубина и голос М3 — пройдено

Revision	Симптом и цена в первых двух абзацах	Главный вопрос	Объём основного текста
Практика	Видимый симптом исправляют до фиксации фактов; цена — возвращающийся случай и запись «починили» без следующей проверки	Как собрать минимальную временную шкалу до первой правки	9 214 знаков body
Механизм	Один абзац смешивает факт, гипотезу, обход и профилактику; цена — потерянная граница и временное действие вместо вывода	Как связать observation, hypothesis, action, verification и prevention	10 362 знака body
Полевой разбор	После восстановления обход принимают за завершённый разбор; цена — повторение старого действия вне исходной границы	Как прочитать синтетический случай без выдуманного production-отчёта	9 752 знака body

Все три материала начинают с «симптом → цена → ограниченная учебная граница», затем сохраняют последовательность «причина → проверка → действие».
У каждого revision больше пяти смысловых разделов, самостоятельный figure с содержательным alt и figcaption, таблица с caption/thead, два технических примера, нумерованный маршрут и три или четыре официальные ссылки.
Практическая статья учит сначала сохранить E1/E2 и только потом менять код. Механическая статья объясняет границы состояний. Полевой материал показывает их на одном контролируемом входе, не расширяя вывод до всех путей.
Речь короткая и предметная: «факт → гипотеза → проверка → действие». Она называет mapper, currency, pricing-adapter, expected check и planned follow-up вместо общего рассуждения о важности надёжности.
Голос соответствует М3 конца 2020 года: автор уже видит границы модулей и повторяемый порядок работы, но не приписывает себе опыт построения платформы, числовых целей доступности, командного центра или большого production-инцидента.

Второй проход отдельно проверил две опасные подмены. Первая: наблюдение currency === undefined не названо причиной. Вторая: A1 и V1 не называются профилактикой; P1/P2 остаются будущими, отдельно проверяемыми изменениями. Разбор без обвинения не убирает техническую ответственность: он требует назвать поле, границу, проверку и следующее изменение, но не приписывает намерение отсутствующим в fixture людям.

Вердикт прохода: пройден. Длина в пределах 5 000–15 000 знаков, заголовки не обещают универсальный процесс, а глубина достигается анализом границ и контрпримеров, а не повтором одной формулы.

Проход 3. Визуал, fixture и выпусковой preflight — пройдено в пределах пакета

incident-timeline-2020.svg показывает вертикальную зависимость «симптом → E1/E2 → H1 → A1 → V1» и отдельную плановую профилактику. Он не соединяет проверку с симптомом напрямую.
incident-decision-record-2020.svg делает видимыми E2, H1, D1/A1, V1 и P1; у решения есть trigger и expected check.
incident-learning-loop-2020.svg показывает, что цикл закрывается следующей проверкой контракта, а не словом «готово».
Каждый SVG имеет title, desc, role="img", вертикальный viewBox 720 px, контрастные карточки и текст не мельче 21 px в исходнике. Во всех трёх отсутствуют JavaScript, foreignObject, внешние URL и raster data URI.
Mobile preflight отрендерил каждый SVG в PNG шириной 375 px через Sharp и просмотрел результат вручную. Заголовки, карточки, стрелки и нижние подписи читаются; clipping, наложение и горизонтальный overflow внутри SVG не обнаружены. Это статическая визуальная проверка, а не browser-run и не проверка screen reader.

Фактически выполненные проверки

Финальное состояние пакета проверено 31 июля 2026 года:

cd web && node --check scripts/upgrade-2020-12.mjs
cd web && npm run audit:draft -- scripts/upgrade-2020-12.mjs
cd web && node scripts/upgrade-2020-12.mjs --verify-fixture
cd web && xmllint --noout \
  public/assets/editorial/2020/incident-timeline-2020.svg \
  public/assets/editorial/2020/incident-decision-record-2020.svg \
  public/assets/editorial/2020/incident-learning-loop-2020.svg

Проверка	Реальный результат
`node --check`	PASS, code 0
Import-safe export и draft gate	PASS: 9 214 / 10 362 / 9 752 знака body; у трёх slug найдены sections, table, figure, code, route, sources и локальные assets
In-memory fixture	PASS: семь assertions истинны — временная шкала упорядочена; H1 основана на E2; A1 следует за H1; V1 проверяет A1; D1 содержит expected check; P1/P2 конкретны и planned; имена людей отсутствуют
`xmllint --noout`	PASS, все три SVG — корректный XML
Sharp mobile preflight	PASS: три PNG шириной 375 px просмотрены; нет clipping, overlap или horizontal overflow внутри схем
Scope/self-review	PASS: в revision нет `date`/`author`; пакет не подключает registry и не редактирует чужие незакоммиченные материалы

npm run audit:draft завершилась с code 0; npm дополнительно вывел предупреждения о старых пользовательских конфигурациях store-dir, cache-dir и public-hoist-pattern. Они не относятся к П34 и не изменялись этим пакетом.

Не запускались: strict audit после подключения к registry, production build, browser, screen reader, реальный HTTP/proxy, база, очередь, клиентские SDK, мониторинг, deployment и публикация. Эти проверки принадлежат отдельной интеграционной и выпусковой операции; данный документ не заявляет их выполненными.

Независимая интеграционная приёмка

Основной редактор 31 июля 2026 года подключил три revision к web/data/editorial-revisions.mjs, не меняя базовый articles.json, даты или автора архивных записей. В registry стало 97 revision. Официальные источники Google SRE и NIST сверены независимо: они поддерживают более общий порядок управления инцидентом и postmortem, но не превращают учебный пример в отчёт о реальном инциденте.

Проверка после интеграции	Реальный результат
Строгий audit трёх slug	PASS: 9 214 / 10 362 / 9 752 знака; у каждой статьи есть figure, table и code examples
Production build	PASS: Next.js собрал 374 статические страницы
Независимый mobile visual review	PASS: основной редактор повторно просмотрел три SVG после Sharp-рендера в 375 px; clipping, overlap и overflow не обнаружены

Ни этот отчёт, ни интеграция не утверждают запуск HTTP, proxy, базы, очереди, monitoring, deployment, browser или assistive technology.

Выпусковой вердикт: ACCEPT. Commit и push выполняются отдельной публикационной операцией; Git остаётся источником её фактической записи.

16 KiB Raw Blame History Unescape Escape