171 lines
16 KiB
Markdown
171 lines
16 KiB
Markdown
# Автономное тройное ревью П34 · декабрь 2020 · «Разбор инцидента»
|
||
|
||
Статус: **принят независимым редактором в выпусковой набор**. Пакет содержит
|
||
ровно три revision для стабильных slug:
|
||
|
||
- <code>editorial-2020-12-practice-incident-review</code>;
|
||
- <code>editorial-2020-12-mechanism-incident-review</code>;
|
||
- <code>editorial-2020-12-field-incident-review</code>.
|
||
|
||
Созданы только пять разрешённых файлов П34:
|
||
|
||
- <code>web/scripts/upgrade-2020-12.mjs</code>;
|
||
- <code>web/public/assets/editorial/2020/incident-timeline-2020.svg</code>;
|
||
- <code>web/public/assets/editorial/2020/incident-decision-record-2020.svg</code>;
|
||
- <code>web/public/assets/editorial/2020/incident-learning-loop-2020.svg</code>;
|
||
- этот документ.
|
||
|
||
Revision-модуль экспортирует только изменяемые редакционные поля и не содержит
|
||
<code>date</code> или <code>author</code>. Он не подключает registry.
|
||
<code>articles.json</code>, registry, README, очередь, package config и Git
|
||
этой партией не менялись. Команда <code>--print-revisions</code> печатает
|
||
только JSON, а <code>--verify-fixture</code> запускает отдельную
|
||
детерминированную проверку в памяти.
|
||
|
||
## Проход 1. Факты и техническая рамка — пройдено
|
||
|
||
| Утверждение | Первичный или официальный источник | Проверенная граница |
|
||
| --- | --- | --- |
|
||
| Управление инцидентом выигрывает от живой записи состояния, разделения работы и явного восстановления | [Google SRE Book: Managing Incidents](https://sre.google/sre-book/managing-incidents/) | В текст перенесён только малый каркас «наблюдение → гипотеза → действие → проверка», без утверждения, что у автора есть сложный процесс управления инцидентами |
|
||
| Postmortem документирует влияние, действия, contributing causes и follow-up; разбор без обвинения ищет условия системы, а не персональную вину | [Google SRE Book: Postmortem Culture](https://sre.google/sre-book/postmortem-culture/) | Статьи говорят о component, поле, контракте и проверке; fixture не содержит имён или ролей людей |
|
||
| Диагностика строится на наблюдениях, проверяемых гипотезах и полезном отрицательном результате | [Google SRE Book: Effective Troubleshooting](https://sre.google/sre-book/effective-troubleshooting/) | H1 отделена от E2; непрохождение V1 описано как новый факт, а не как повод переписать историю |
|
||
| Для security-инцидентов NIST описывает цикл подготовки, обнаружения, анализа, сдерживания и post-incident activity | [NIST SP 800-61 Rev. 2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf) | Источник используется только как общий ориентир жизненного цикла; статья не называет учебный случай security-инцидентом и не выдаёт его за нормативную процедуру |
|
||
|
||
Весь технический случай создан в <code>runIncidentFixture()</code>. В нём пять
|
||
синтетических событий с последовательностью E1, E2, H1, A1, V1; один decision
|
||
record D1 и два профилактических пункта P1/P2 в состоянии
|
||
<code>planned</code>. Значения не взяты из журнала, сетевого запроса,
|
||
пользовательской истории или production-системы:
|
||
|
||
- E1 фиксирует только учебное состояние <code>blocked</code> на границе
|
||
<code>preview-order</code>;
|
||
- E2 фиксирует отсутствие <code>currency</code> после 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 больше пяти смысловых разделов, самостоятельный
|
||
<code>figure</code> с содержательным <code>alt</code> и
|
||
<code>figcaption</code>, таблица с <code>caption</code>/<code>thead</code>,
|
||
два технических примера, нумерованный маршрут и три или четыре официальные
|
||
ссылки.
|
||
- Практическая статья учит сначала сохранить E1/E2 и только потом менять
|
||
код. Механическая статья объясняет границы состояний. Полевой материал
|
||
показывает их на одном контролируемом входе, не расширяя вывод до всех
|
||
путей.
|
||
- Речь короткая и предметная: «факт → гипотеза → проверка → действие».
|
||
Она называет <code>mapper</code>, <code>currency</code>,
|
||
<code>pricing-adapter</code>, expected check и planned follow-up вместо
|
||
общего рассуждения о важности надёжности.
|
||
- Голос соответствует М3 конца 2020 года: автор уже видит границы модулей и
|
||
повторяемый порядок работы, но не приписывает себе опыт построения
|
||
платформы, числовых целей доступности, командного центра или большого
|
||
production-инцидента.
|
||
|
||
Второй проход отдельно проверил две опасные подмены. Первая: наблюдение
|
||
<code>currency === undefined</code> не названо причиной. Вторая: A1 и V1 не
|
||
называются профилактикой; P1/P2 остаются будущими, отдельно проверяемыми
|
||
изменениями. Разбор без обвинения не убирает техническую ответственность:
|
||
он требует назвать поле, границу, проверку и следующее изменение, но не
|
||
приписывает намерение отсутствующим в fixture людям.
|
||
|
||
Вердикт прохода: **пройден**. Длина в пределах 5 000–15 000 знаков, заголовки
|
||
не обещают универсальный процесс, а глубина достигается анализом границ и
|
||
контрпримеров, а не повтором одной формулы.
|
||
|
||
## Проход 3. Визуал, fixture и выпусковой preflight — пройдено в пределах пакета
|
||
|
||
- <code>incident-timeline-2020.svg</code> показывает вертикальную
|
||
зависимость «симптом → E1/E2 → H1 → A1 → V1» и отдельную плановую
|
||
профилактику. Он не соединяет проверку с симптомом напрямую.
|
||
- <code>incident-decision-record-2020.svg</code> делает видимыми E2,
|
||
H1, D1/A1, V1 и P1; у решения есть trigger и expected check.
|
||
- <code>incident-learning-loop-2020.svg</code> показывает, что цикл
|
||
закрывается следующей проверкой контракта, а не словом «готово».
|
||
- Каждый SVG имеет <code>title</code>, <code>desc</code>,
|
||
<code>role="img"</code>, вертикальный viewBox 720 px, контрастные карточки
|
||
и текст не мельче 21 px в исходнике. Во всех трёх отсутствуют JavaScript,
|
||
<code>foreignObject</code>, внешние URL и raster data URI.
|
||
- Mobile preflight отрендерил каждый SVG в PNG шириной 375 px через Sharp и
|
||
просмотрел результат вручную. Заголовки, карточки, стрелки и нижние
|
||
подписи читаются; clipping, наложение и горизонтальный overflow внутри
|
||
SVG не обнаружены. Это статическая визуальная проверка, а не browser-run
|
||
и не проверка screen reader.
|
||
|
||
### Фактически выполненные проверки
|
||
|
||
Финальное состояние пакета проверено 31 июля 2026 года:
|
||
|
||
<pre><code>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</code></pre>
|
||
|
||
| Проверка | Реальный результат |
|
||
| --- | --- |
|
||
| <code>node --check</code> | 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; имена людей отсутствуют |
|
||
| <code>xmllint --noout</code> | PASS, все три SVG — корректный XML |
|
||
| Sharp mobile preflight | PASS: три PNG шириной 375 px просмотрены; нет clipping, overlap или horizontal overflow внутри схем |
|
||
| Scope/self-review | PASS: в revision нет <code>date</code>/<code>author</code>; пакет не подключает registry и не редактирует чужие незакоммиченные материалы |
|
||
|
||
<code>npm run audit:draft</code> завершилась с code 0; npm дополнительно вывел
|
||
предупреждения о старых пользовательских конфигурациях
|
||
<code>store-dir</code>, <code>cache-dir</code> и
|
||
<code>public-hoist-pattern</code>. Они не относятся к П34 и не изменялись
|
||
этим пакетом.
|
||
|
||
Не запускались: strict audit после подключения к registry, production build,
|
||
browser, screen reader, реальный HTTP/proxy, база, очередь, клиентские SDK,
|
||
мониторинг, deployment и публикация. Эти проверки принадлежат отдельной
|
||
интеграционной и выпусковой операции; данный документ не заявляет их
|
||
выполненными.
|
||
|
||
## Независимая интеграционная приёмка
|
||
|
||
Основной редактор 31 июля 2026 года подключил три revision к
|
||
<code>web/data/editorial-revisions.mjs</code>, не меняя базовый
|
||
<code>articles.json</code>, даты или автора архивных записей. В 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 остаётся источником её фактической записи.
|