На 31 июля 2026 года строгий аудит проходит 208 из 358 созданных материалов. Остальные 150 не считаются «почти готовыми»: их нужно заменить, а не косметически удлинить.
На 31 июля 2026 года строгий аудит проходит 211 из 358 созданных материалов. Остальные 147 не считаются «почти готовыми»: их нужно заменить, а не косметически удлинить.
- Голос: М6, ноябрь 2023 года. Автор действует как системный практик: начинает с цены плохого разбора, различает evidence и интерпретацию, связывает решение с доступной в моменте информацией и оставляет один проверяемый следующий шаг. Речь короткая и прикладная: «симптом → причина → проверка → действие».
- Тема разделена без дублей. Practice учит сначала собрать fact timeline; mechanism объясняет контракт `fact` / `decision-at-the-time` / `preventive-experiment`; field даёт маршрут ведущему ретроспективы от unknown к обратимой проверке. Общий fixture — один учебный предмет, а не три повтора одного текста.
- Жёсткая граница: пакет создаёт только fixed synthetic incident records в памяти. Он не читает, не отправляет и не создаёт реальные incident data, logs, traces, alerts, users, CI, сеть или production runtime. Он не делает вывода о виновнике, причине, impact или эффекте настоящего изменения.
- Скоуп sidecar: ровно этот review, `web/scripts/upgrade-2023-11.mjs` и три заданных SVG. `articles.json`, registry, README, очередь, Git, staging, commit и push не менялись.
## Проход 1 — факты, источники и модель
- Историческая граница проверена 31.07.2026 по первичным официальным материалам, существовавшим до конца ноября 2023: [Google SRE Book: Postmortem Culture](https://sre.google/sre-book/postmortem-culture/) и [Example Postmortem](https://sre.google/sre-book/example-postmortem/) (публикация Google 2017); [NIST SP 800-61 Rev. 2](https://doi.org/10.6028/NIST.SP.800-61r2), август 2012; [CISA Federal Government Cybersecurity Incident and Vulnerability Response Playbooks](https://www.cisa.gov/sites/default/files/publications/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C_1.pdf), ноябрь 2021.
- У источников названы пределы вывода. Google описывает практику и форму postmortem в своей SRE-культуре, включая timeline и action items; это не доказательство эффекта для иной команды. NIST и CISA относятся к cybersecurity incident response; из них не выведены обязательства, сроки или универсальный процесс для продуктовой эксплуатации.
-`syntheticIncidentRecords` содержит пять статичных объектов: три `fact`, одно `decision-at-the-time`, один `preventive-experiment`. Каждая факт-карточка имеет fixed timestamp, fixed statement и synthetic evidence reference, но фиксирует `not-a-cause-claim`; решение видит только три предшествующих fact IDs; experiment имеет hypothesis, criterion и rollback, но не обещает effect.
-`assembleSyntheticPostmortem()` не импортирует runtime I/O-модули и не вызывает сетевой, файловый, CI или production API. Граничный scan не нашёл runtime I/O primitive. Функция принимает только complete fixed synthetic contract с точным top-level shape, ставит `synthetic-not-observed`, `not-judged`, `not-evaluated` и отдельно запрещает поля `culprit`, `rootCause`, `realEffect`.
-`runPostmortemFixture()` проверяет 21 assertion: валидный контракт, закрытую форму top-level/fact statement, раздельность facts/decision/experiment, временную границу решения, отсутствие actor в объяснении, предел допустимого вывода, отрицательные ветки и узкий rollback. PASS означает только согласованность учебной формы; он не устанавливает incident, человека, причину, impact, доступность, безопасность или production effect.
- Rollback намеренно неоперационный. `rollbackSyntheticPostmortem()` возвращает frozen snapshot synthetic records, сообщает `externalIO=not-attempted` и `productionEffect=not-attempted`. Он не откатывает release, не меняет конфигурацию, не удаляет данные и не выключает alerting.
## Проход 2 — редактура, голос и различение статей
- Первые два абзаца всех статей называют практическую проблему и цену: practice — поиск виноватого вместо маршрута для следующей смены; mechanism — заднее знание в одной фразе; field — спор о людях вместо проверяемой timeline. Ни один пример не маскируется под настоящий incident report.
- После редакторского сокращения основной текст составил: practice — **9 978** знаков, mechanism — **9 971**, field — **10 000**. Все значения находятся внутри обязательных 5–15 тыс. и целевого 8–10 тыс. знаков. У каждой статьи десять смысловых разделов вместе с источниками, одна доступная таблица, собственный рисунок с осмысленным `alt`/caption, исполнимый пример, ordered route, limits, rollback и next step.
- Practice отвечает на вопрос «как записать facts до объяснения». Здесь главные артефакты — source-backed timeline и отдельная карточка решения. Mechanism отвечает на «почему нельзя соединять прошлый факт и будущую профилактику в одну фразу». Здесь глубина — поля record contract и временная граница knowledge. Field отвечает на «как провести разбор в комнате». Здесь главный артефакт — маршрут ведущего, stop-signal и перевод unknown в experiment.
- Текст соответствует М6: использует incident, evidence, rollback, owner role и review только с конкретным предметом. Автор 2023 года не выдан за владельца глобальной платформы: нет вымышленных команд, SLO, чисел ущерба, access data, production logs или заявлений о внедрённом эффекте. Персональную оценку заменяют источник, доступный факт, граница решения, criterion и следующее действие.
- Автоматический draft audit не нашёл шаблонных фраз, следов генерации, повторяющихся slug, отсутствующих source links, незакрытых visual assets или изменения `date`/`author`. Import-safe CLI и module export согласованы; в архиве существуют все три зафиксированных slug.
## Проход 3 — визуал, выпуск и безопасность
-`postmortem-2023-fact-timeline.svg` показывает порядок трёх fact records, решения и experiment; `postmortem-2023-decision-record.svg` — поток fact IDs в решение и критерий/rollback у experiment; `postmortem-2023-experiment-loop.svg` — путь от unknown к review criterion. Каждая схема явно отмечает, что она synthetic и не доказывает вину, причину или production effect.
- Все SVG содержат `title`, `desc`, `role="img"`, `aria-labelledby`, контрастные блоки, видимые подписи и не используют `<script>`, `foreignObject`, external URL, `javascript:`, `data:image` или event handlers. `xmllint --noout` и safety scan прошли без замечаний.
- Sharp-render всех трёх схем на ширине 375 px просмотрен вручную: timeline читается сверху вниз, карточка решения сохраняет направление fact → decision → experiment, loop не превращается в мелкую таблицу. Уточнение «поиск виновника» визуально перечёркнуто, но не является единственным носителем смысла: текстовые blocks остаются читаемыми.
- Выполнены: `node --check web/scripts/upgrade-2023-11.mjs` — PASS; `node web/scripts/upgrade-2023-11.mjs --verify-fixture` — `PASS fixture: 21/21 assertions` после независимого model review; `cd web && npm run audit:draft -- scripts/upgrade-2023-11.mjs` — PASS для всех трёх статей; import-safe проверка — PASS; XML/SVG safety scan — PASS; Sharp 375 px — PASS.
- Пакет намеренно не интегрирован в registry и не опубликован. Главный агент должен отдельно провести приёмочное ревью перед архивной интеграцией, но этот sidecar не требует и не выполняет Git-действий.
## Интеграционное ревью главного агента
Независимо сверены первичные источники. Google SRE 2017 определяет
postmortem как письменную запись incident, impact, действий и follow-up и
отдельно формулирует blameless подход как проверку системных причин с учётом
информации, доступной в моменте. Example Postmortem действительно содержит
impact, action items и timeline. NIST SP 800-61 Rev. 2 (2012) и CISA playbook
с пометкой publication November 2021 относятся к cybersecurity response;
поэтому они оставлены только как ограниченный контекст, не как шаблон для
продуктовой эксплуатации.
Model review нашёл два пути подменить fixed synthetic предмет: добавить
неизвестное top-level поле или заменить заранее названный fact statement
произвольным текстом. Теперь top-level records и вложенные cards имеют exact
own-key shape, а все три statements фиксированы. Fixture добавил обе
отрицательные ветки и проходит `21/21` assertions.
Повторный draft audit: 10 078 / 9 971 / 10 000 знаков. Все SVG прошли XML и
safety scan, затем вручную просмотрены после Sharp-render на 375 px. Строгий
archive audit прошёл для трёх slug; registry содержит 202 уникальные ревизии.
`npm run build` успешно сгенерировал 374 статические страницы.
<titleid="title">Учебная карточка решения для postmortem</title>
<descid="desc">Три synthetic fact records входят в карточку решения в моменте. Из карточки выходит только профилактический эксперимент с критерием и rollback. Имя человека перечёркнуто как ложное поле объяснения.</desc>
<titleid="title">Учебный цикл postmortem от unknown к обратимой проверке</title>
<descid="desc">Synthetic факты ведут к решению в моменте, неизвестное переводится в профилактический эксперимент с критерием, а rollback возвращает только synthetic snapshot. Поиск виновника отмечен как запрещённая ветка.</desc>
<titleid="title">Учебная timeline для postmortem без поиска виноватого</title>
<descid="desc">Три synthetic fact records расположены до решения в моменте и профилактического эксперимента. Схема разделяет факт, решение и эксперимент и не утверждает причину, вину или эффект реального инцидента.</desc>
note:'официальная публикация Google, доступная до ноября 2023. Она описывает опыт и практику Google: документирование инцидента, разбор contributing causes, review и action items. Это не универсальное доказательство эффекта для другой команды.',
},
googleExample:{
title:'Google SRE Book: Example Postmortem, 2017',
note:'официальный учебный пример с timeline, impact, action items и lessons learned. Он показывает форму артефакта, но не является данными этого fixture или причиной какого-либо чужого сбоя.',
note:'официальное руководство по обработке компьютерных security-инцидентов, включая phase post-incident lessons learned. Его область — incident response в security, а не готовый шаблон для любого продуктового или эксплуатационного разбора.',
},
cisa:{
title:'CISA: Federal Government Cybersecurity Incident and Vulnerability Response Playbooks, ноябрь 2021',
note:'официальный федеральный playbook США, опубликованный до ноября 2023. Он относится к FCEB cybersecurity response; статья не переносит его обязательства, сроки или полномочия в иной контур.',
excerpt:'Как начать ретроспективу с проверяемой timeline, не выдать решение в моменте за ошибку человека и не назвать профилактическую гипотезу уже доказанным исправлением.',
readingMinutes:11,
},[
p('После сбоя команда часто помнит одно: кто нажал кнопку и какой фрагмент лога тревожил. Встреча быстро превращается в поиск автора неверного действия. Цена не только в конфликте. Из документа исчезают условия, при которых решение казалось разумным, и следующий дежурный получает не проверяемый маршрут, а мораль из прошлого случая.'),
p('Практическая проблема не решается заменой слова «виноват» на «бескорыстно». Нужна другая форма записи. Сначала фиксируем факт с источником и временем. Затем отдельно записываем решение, доступные в тот момент факты и обратимость. После этого формулируем профилактический эксперимент с критерием проверки. Такое разложение не доказывает причину и не оправдывает любое действие; оно делает границу неизвестного видимой и оставляет материал для следующей проверки.'),
h2('Что считать фактом, а что — объяснением'),
p('Факт в ретроспективе — узкое утверждение, которое можно связать с артефактом: отметкой времени, снимком состояния, версией конфигурации, сообщением runbook или разрешённой записью наблюдения. «В 10:03 была зафиксирована версия» — факт, если рядом есть ссылка на его источник. «Версия сломала маршрут» — уже объяснение. Вторую фразу нельзя прятать в timeline: у неё могут быть альтернативы, а источника в одной строке обычно недостаточно.'),
table('Три записи, которые нельзя склеивать',['Тип записи','Вопрос','Минимальные поля','Недопустимый вывод'],[
['Факт','что зафиксировано и где?','время, формулировка, evidence reference','кто виноват и почему это произошло'],
['Решение в моменте','какое действие выбрали при известных данных?','время, действие, доступные факты, оценка неизвестна','что решение было ошибкой без контекста'],
['Профилактический эксперимент','что хотим проверить до следующего изменения?','гипотеза, метод, критерий, rollback','что эффект уже получен'],
['Action item','кто и когда доведёт работу?','владелец роли, срок, ссылка на проверку','что задача устраняет все риски'],
]),
figure('/assets/editorial/2023/postmortem-2023-fact-timeline.svg','Учебная timeline: три synthetic факта идут раньше synthetic решения, за ним расположен обратимый профилактический эксперимент. Стрелки показывают порядок records, а не причину, вину или эффект настоящего инцидента.','Timeline отделяет наблюдаемые поля от решения в моменте и будущего эксперимента. Это учебная схема fixed synthetic records, не лог, alert, trace, incident report или выгрузка production-системы.'),
h2('Сначала сужаем карточку факта'),
p('Начните с одной строки: когда и какой артефакт был доступен. Не добавляйте в неё оценку человека, пересказ диалога и гипотезу о механизме. Если источник нельзя назвать из-за доступа или чувствительности, укажите тип источника и статус «не проверено», а не заполняйте пробел правдоподобным текстом. Важна не литературная полнота, а возможность через неделю отличить сохранённое свидетельство от воспоминания участника.'),
p('В учебной модели ниже есть три fixed synthetic fact records. У каждого заранее задан `occurredAt`, `statement` и `evidenceRef`, а поле `inference` жёстко равно `not-a-cause-claim`. Это не способ хранить настоящий инцидент и не пример корректного schema для вашей базы. Он нужен, чтобы на ревью заметить подмену: когда в поле факта появляется причина, фамилия, чужая деталь или обещание эффекта, модель отклоняет запись. Отрицательная ветка полезнее красивой timeline: она показывает, что именно нельзя честно вывести.'),
h2('Решение нужно читать во времени'),
p('Следующая запись отвечает не на вопрос «кто ошибся», а на вопрос «какой выбор был сделан с теми данными, которые уже были». Для решения полезны действие, timestamp и список fact IDs. Этот список не доказывает правильность действия. Он показывает границу информации: какие записи могли повлиять на выбор, а какие появились позже. После инцидента у нас больше контекста, поэтому задним числом легко назвать очевидным то, чего в моменте никто ещё не видел.'),
p('Если решение было необратимым, не смягчайте это словом «оперативное». Напишите, что именно нельзя быстро вернуть, кто владеет точкой возврата и какой сигнал подтверждает остановку. Если действие обратимо, всё равно нужен критерий: «вернуть конфигурацию до версии X» недостаточно без способа проверить, что новая ветка больше не применяется. Google в своём примере postmortem показывает timeline и action items; это хороший ориентир формы, но не разрешение приписывать своей системе чужой результат или срок.'),
h2('Профилактика — это эксперимент, а не приговор'),
p('После разбора хочется написать «добавить проверку, чтобы такого больше не было». Такая задача слишком широка. Она не называет, что проверяем, на каком входе, какой результат будет достаточным и как остановиться, если изменение ухудшит ситуацию. Вместо этого формулируйте эксперимент: гипотеза, минимальный метод, критерий успеха, владелец роли и обратимый rollback. До прогона это намерение проверить, а не доказательство, что инцидент больше не повторится.'),
p('Например, можно проверить только наличие reversible checkpoint в одном runbook. Успехом будет не «система стала надёжнее», а «перед действием перечислены точка возврата, владелец и наблюдаемый критерий остановки». Если checkpoint не помещается в карточку, он ещё не готов к автоматизации. Такое ограничение намеренно скромное: оно не измеряет availability, не читает настоящие alerts и не делает вывод о влиянии на пользователей.'),
h2('Прогоните маленький контракт до встречи'),
p('Код создаёт фиксированный synthetic набор в памяти и проверяет двадцать одну assertion. Он принимает только полный набор известных top-level полей, три exact fact records, одно decision record с полным набором известных фактов и один experiment record с rollback. Отдельные отрицательные ветки отклоняют лишнее поле, неполный evidence reference, чужой текст факта, решение с частью фактов, именованного виновника, утверждение root cause, обещание реального эффекта и experiment без точки возврата. PASS означает только то, что учебный контракт не перепутал типы записей.'),
code(syntheticExample+'\n\nnode web/scripts/upgrade-2023-11.mjs --verify-fixture\n\n# PASS не читает и не отправляет реальные incident data, logs, traces, alerts, users, CI или сеть.\n# Он не устанавливает виновника, причину или эффект настоящего изменения.'),
p('В результате корректная формулировка звучит так: «в fixed synthetic модели три факта были доступны до решения; experiment имеет rollback и критерий». Некорректная: «мы нашли виновника» или «проверка уже предотвратила следующий сбой». Разница важна для редактора документа: первая фраза оставляет следующий шаг, вторая закрывает вопрос без evidence.'),
h2('Маршрут: симптом → причина → проверка → действие'),
ol([
'<strong>Симптом.</strong> Черновик содержит имена людей и оценки, но не показывает, какие записи были доступны до действия.',
'<strong>Причина.</strong> Факт, решение и профилактика лежат в одной хронологической строке, поэтому позднее знание маскируется под знание в моменте.',
'<strong>Проверка.</strong> Для каждого предложения поставьте метку: факт с источником, решение с набором доступных фактов или проверяемый experiment. Строку без метки вынесите в вопрос.',
'<strong>Действие.</strong> Оставьте timeline из фактов; привяжите решение к fact IDs; превратите профилактику в маленькую гипотезу с критерием и rollback.',
'<strong>Проверка вывода.</strong> На ревью спросите, есть ли в документе утверждение о причине, человеке или эффекте, которое не имеет отдельного evidence. Если есть — смените статус на «не проверено».',
'<strong>Следующий шаг.</strong> Выберите один action item и заранее договоритесь, какой артефакт подтвердит его результат в разрешённой среде.',
]),
h2('Когда остановиться и как откатить'),
p('Остановите редактуру, если команда начинает спорить о мотивах, а не о данных в моменте. Это не запрет на ответственность: последствия действия и владелец следующей проверки остаются в документе. Просто мотивацию нельзя подменять evidence. Вернитесь к последнему факту с источником, зафиксируйте открытый вопрос и договоритесь, кто может добавить разрешённый артефакт. Не пытайтесь закрыть пробел реконструкцией из памяти одного участника.'),
p('Rollback этого fixture узкий: `rollbackSyntheticPostmortem()` возвращает snapshot synthetic records и помечает `externalIO=not-attempted`. Он не отменяет rollout, не удаляет реальные данные, не выключает alert, не меняет CI и не исправляет production runtime. В реальном разборе rollback должен быть отдельным операционным планом с системой, владельцем, границей воздействия и наблюдаемым критерием завершения. Учебная функция лишь не позволяет назвать имитацию операционным действием.'),
h2('Ограничения и следующий шаг'),
p('Пакет не содержит настоящего incident data, logs, traces, alerts, users, CI, сетевых запросов или production runtime. Времена, факт-карточки, действие и experiment полностью synthetic. Он не устанавливает виновника, root cause, impact, доступность, пользовательский эффект или результат изменения. Наличие структуры не делает разбор законченным: настоящая команда должна отдельно проверить доступ, privacy, retention, юридические границы, правила disclosure и способ связывать evidence с источником.'),
p('Следующий шаг — взять один завершённый, разрешённый для обучения случай и сначала заполнить только колонки «факт» и «источник». Лишь потом добавить решения в моменте и один обратимый experiment. Если до встречи неизвестно, где лежит evidence, это уже результат: не пишите причину, пока не определите владельца и допустимый способ проверки. Так короткая ретроспектива становится техническим документом, а не стенограммой поиска виноватого.'),
h2('Историческая граница ноября 2023'),
p('К ноябрю 2023 были доступны Google SRE Book с разделом о blameless postmortems и примером timeline/action items, NIST SP 800-61 Rev. 2 с post-incident lessons learned, а также CISA playbooks 2021 для федерального cybersecurity response. Здесь из них взята дисциплина документировать факт, review и follow-up. Материал не утверждает, что подход Google или требования американского security-контура автоматически подходят любой команде, и не называет их доказательством конкретного эффекта.'),
excerpt:'Почему timeline без типов записей подменяет факт объяснением, как связать решение с доступной информацией и превратить профилактику в обратимую проверку.',
readingMinutes:12,
},[
p('Дорогой дефект postmortem — не отсутствие шаблона, а смешение времён. Строка «релиз вызвал ошибку, поэтому инженер откатил его» содержит разные утверждения: был ли релиз, когда появился симптом, что было известно до отката и есть ли доказательство связи. В одной фразе позднее объяснение выглядит как факт, доступный во время решения.'),
p('Цена этой подмены — плохой следующий change. Команда берёт самый заметный элемент из истории, объявляет его причиной и добавляет защиту именно вокруг него. Если связь была случайной, новая проверка создаёт работу, но не улучшает способность заметить похожее состояние. Механизм без поиска виноватого проще: каждое утверждение получает тип, тип задаёт допустимые поля и не разрешает сделать больший вывод, чем дают записи.'),
h2('Контракт из трёх типов records'),
p('Первый тип — факт. Он хранит минимальное описание и evidence reference, но не root cause. Второй — решение в моменте. Оно хранит действие, время и set фактов, доступных перед выбором; поле оценки остаётся `not-judged`, пока команда не проведёт отдельную проверку. Третий — профилактический experiment. Он описывает гипотезу, метод, success criterion и rollback. Его `expectedEffect` остаётся `not-evaluated`, потому что задача ещё не стала результатом.'),
table('Контракт полей и граница вывода',['Record','Граница ответственности','Обязательная связь','Что запрещено в модели'],[
['fact','зафиксировать предмет и источник','timestamp + evidence reference','culprit, root cause, real effect'],
['decision-at-the-time','показать выбор при известной информации','ordered list of fact IDs','имя человека как объяснение, оценка задним числом'],
['preventive-experiment','проверить одну управляемую гипотезу','criterion + rollback','обещание предотвращения реального инцидента'],
['evidence card','назвать разрешённый вывод','ссылки на все три record type','подмена модели production observation'],
]),
figure('/assets/editorial/2023/postmortem-2023-decision-record.svg','Учебная карточка решения: три synthetic fact IDs входят в решение, а выходом становится один профилактический experiment с критерием и rollback. Отдельная перечёркнутая ветка показывает, что имя человека не является полем объяснения.','Схема показывает границы контракта records. Она не реконструирует реальный incident, не отражает чат, alert, лог, trace, роль человека или влияние production-изменения.'),
h2('Факт не обязан объяснять механизм'),
p('Инженеру бывает неудобно оставить в документе фразу «причина не подтверждена». Кажется, будто работа не сделана. Но факт-карточка полезна именно тем, что переживает смену гипотезы. Если позже выяснится другой механизм, timestamp и ссылка на исходный артефакт останутся валидными; ложное объяснение придётся вычёркивать вместе со всеми задачами, которые на нём выросли. Поэтому `fact` в модели имеет поле `inference=not-a-cause-claim`.'),
p('Это не призыв собирать бесконечный архив. Для каждой строки спросите: помогает ли она связать симптом с моментом решения или проверить следующий experiment? Если нет, текст можно вынести в приложение либо удалить. Контракт должен быть небольшим, чтобы review замечал отсутствие источника. В fixture второй fact отклоняется, если `evidenceRef` пуст. Такая проверка не подтверждает существование артефакта, но не разрешает сделать вид, что источник указан.'),
h2('Решение — снимок доступной информации'),
p('У решения есть направление во времени. `availableFactIds` ссылаются только на facts, которые стоят раньше `occurredAt` решения. Это важно технически: полная timeline после разбора может содержать новые логи, комментарии или результаты эксперимента, но они не должны доказывать, что исходный выбор был неразумным. Нельзя изменить прошлую границу знаний добавлением удобного факта в список. Fixture специально отклоняет decision с неполным expected set и вариант с временем до третьего fact.'),
p('Модель не содержит `actor`: это не потому, что действия происходят сами, а потому, что имя человека не объясняет состояние системы. В реальном документе владелец action item нужен, а персональные данные и доступ к ним требуют отдельного правила. Но для вопроса «какие условия сделали решение возможным?» полезнее поля: какая версия была известна, какой сигнал доступен, какая инструкция существовала, какое действие было обратимо. Они дают основу для change в системе, runbook или интерфейсе, а не ярлык для участника.'),
h2('Experiment отделяет профилактику от обещания'),
p('Профилактическая задача часто начинается с глагола «добавить»: alert, тест, лимит, checklist. Этого недостаточно для проверки. В контракте experiment должен отвечать: какую неопределённость мы хотим уменьшить, каким минимальным методом, что будет считаться прохождением и как вернуть предыдущую точку. Например, гипотеза может касаться только явного reversible checkpoint в one runbook. Она не заявляет, что это устранит все outage или изменит реальный metric.'),
p('Критерий стоит сделать бинарным и связанным с артефактом: «у каждого опасного действия есть owner role, stop criterion и rollback reference». Такой критерий можно review-ить без доступа к production. Если он не проходит, результат — не «команда не справилась», а конкретное отсутствие полей. Затем можно выбрать меньший experiment либо перенести работу туда, где доступна настоящая среда. CISA и NIST полезны здесь как дисциплина follow-up в incident response, а не как разрешение объявить любую задачу достаточной защитой.'),
h2('Выполните fixture как проверку формы'),
p('`assembleSyntheticPostmortem()` не получает JSON-файл, API response или вывод CI. Он берёт экспортированный constant из того же модуля. Функция проверяет fixed IDs, порядок пяти synthetic records, полное множество fact IDs, отсутствие полей `culprit`, `rootCause` и `realEffect`, а также rollback у experiment. На valid branch строится immutable card, где permitted conclusion ограничен формой records. Это намеренно не schema validator для вашего формата и не engine root-cause analysis.'),
code(syntheticExample+'\n\nnode web/scripts/upgrade-2023-11.mjs --verify-fixture\n\n# Fixture не запускает сборку, CI, сеть, production runtime или внешние инструменты.\n# Его PASS не является причиной, impact assessment или результатом профилактики.'),
p('Полезный результат fixture — отказ. В нём видна конкретная граница: например, `decision-context-contract-rejected` означает, что у решения нет ожидаемого набора facts, а не что человек сделал неверный выбор. `culprit-cause-or-real-effect-claim-rejected` означает, что в учебную модель добавили вывод, который модель обещала не делать. Это даёт редактору короткую причину вернуть абзац на доработку без психологической оценки участников.'),
h2('Маршрут: симптом → причина → проверка → действие'),
ol([
'<strong>Симптом.</strong> Одна фраза postmortem одновременно называет событие, виновника, причину и профилактику.',
'<strong>Причина.</strong> В документе нет типов records и временной границы знания; поздний факт выглядит доступным в моменте.',
'<strong>Проверка.</strong> Разделите предложение на fact, decision и experiment. Для decision перечислите только предшествующие fact IDs; для experiment назовите criterion и rollback.',
'<strong>Действие.</strong> Сохраните facts в неизменяемой timeline, decision привяжите к доступной информации, а профилактику перепишите как ограниченный эксперимент.',
'<strong>Проверка вывода.</strong> Найдите слова «вызвал», «виноват», «предотвратит» и потребуйте отдельный источник либо смените формулировку на hypothesis или unknown.',
'<strong>Следующий шаг.</strong> Добавьте один review gate: новый action item не появляется в списке, пока не имеет owner role, проверяемый результат и обратимый путь.',
]),
h2('Обратимость относится к изменению, не к тексту'),
p('Иногда rollback описывают так, будто документ сам способен вернуть систему назад. Это опасная метафора. Ретроспектива может зафиксировать, что нужно откатить, и спросить про критерий завершения; она не знает, выполнено ли действие, пока не получит разрешённое evidence. В модели rollback — значение `restore-synthetic-record-snapshot`. Оно возвращает только копию локального набора и явно не создаёт внешнего эффекта.'),
p('В production-решении rollback должен быть точнее: target configuration, безопасная последовательность, владелец роли, stop criterion, способ проверить отсутствие дальнейшего воздействия и границы доступа. Если хотя бы один пункт неизвестен, его лучше оставить открытым. Открытый риск — не поражение postmortem; хуже спрятать его под словом «откат» и обнаружить несогласованность во время следующего инцидента.'),
h2('Ограничения и следующий шаг'),
p('Это не реальная incident database и не спецификация хранения. Fixture не читает, не отправляет и не производит настоящие incident data, logs, traces, alerts, users, CI, сеть или production runtime. Все identifiers, timestamps, sources, decisions и experiments fixed synthetic. Ни одна assertion не говорит о виновнике, причине, impact, пользователе, метрике, доступности, безопасности или эффекте настоящего изменения. Она проверяет только различение типов внутри учебной формы.'),
p('Следующий шаг — провести design review одного будущего postmortem template. Уберите из поля facts интерпретации, добавьте к decision список доступной информации и обязуйте preventive task иметь success criterion plus rollback. Затем на одном разрешённом учебном случае проверьте, хватает ли этих полей читателю, который не был на incident call. Если не хватает, добавляйте не историю о людях, а недостающий артефакт, вопрос или границу ответственности.'),
h2('Историческая граница ноября 2023'),
p('Материал ограничен официальными источниками, доступными до конца ноября 2023: Google SRE Book 2017 описывает postmortem как документ с impact, действиями и follow-up; его example содержит timeline и action items. NIST SP 800-61 Rev. 2 (2012) и CISA playbooks (2021) относятся к cybersecurity incident response и follow-up. Из них не следует универсальный schema, юридическая обязанность или доказанный эффект именно этой модели; contract выше — учебная инженерная декомпозиция.'),
excerpt:'Маршрут ведущего ретроспективы: остановить спор о людях, восстановить доступные факты, привязать решение к моменту и вывести один обратимый профилактический эксперимент.',
readingMinutes:12,
},[
p('На полевой ретроспективе проблема обычно возникает раньше, чем открывают документ. Один участник говорит «надо было сразу откатывать», другой вспоминает иной сигнал, третий объясняет мотивацию коллеги. У команды появляется версия истории, но не способ её проверить. Цена — следующая дежурная смена повторяет выбор без понимания условий и ограничений конкретного момента.'),
p('Не нужно выигрывать спор о версии событий. Нужен маршрут, который уменьшает область утверждений. Ведущий возвращает разговор к наблюдаемому: что зафиксировано, откуда запись, в каком порядке она стала известна. Затем он отделяет решение при этом наборе данных от гипотезы о профилактике. Такой порядок не отменяет ответственность за follow-up: у action item остаются владелец роли, проверка и точка возврата.'),
h2('Первые пятнадцать минут: восстановить границу знания'),
p('Начните с одной цели разбора: не «узнать, кто допустил ошибку», а «понять, какие факты были доступны перед решением и какой риск проверить следующим». Заведите три колонки. В facts попадают timestamped statements с source reference. В decisions — действия и набор facts на тот момент. В experiments — будущие проверки с остановкой. Unknown не маскируйте: строка «источник не найден» полезнее пересказа.'),
table('Маршрут ведущего и ожидаемый артефакт',['Шаг','Вопрос к группе','Артефакт на выходе','Стоп-сигнал'],[
['1. Факты','что именно зафиксировано?','fact card с временем и source reference','в строке появилась причина или имя человека'],
['2. Решение','что было известно до действия?','decision card + ordered fact IDs','добавлен факт, появившийся позже'],
['4. Experiment','что проверим до следующего change?','гипотеза, criterion, rollback','задача обещает устранить все повторения'],
]),
figure('/assets/editorial/2023/postmortem-2023-experiment-loop.svg','Учебный цикл: synthetic факты ведут к decision record, неизвестное превращается в ограниченный preventive experiment, его criterion определяет review, а rollback возвращает synthetic snapshot. Ветка поиска виновника перечёркнута.','Цикл показывает порядок диагностики и review в учебной модели. Он не является реальным incident workflow, alerting process, evidence collection, системой задач или подтверждением эффекта production-изменения.'),
h2('Остановите фразу, которая звучит как причина'),
p('Фразы «это из-за релиза», «дежурный не заметил», «runbook подвёл» могут быть хорошими вопросами, но плохими facts. Ведущий не обязан спорить с ними. Достаточно попросить разделить фразу: какое событие зафиксировано, какой источник это подтверждает, какая часть остаётся hypothesis. Если источника нет, запишите `unknown` и назначьте безопасную проверку. Это снимает давление с человека в комнате и одновременно повышает требовательность к документу.'),
p('Особенно осторожно с chat-историей. Сообщение в канале помогает восстановить порядок, но само по себе не подтверждает технический механизм. У него есть автор, время и контекст, но нет статуса root cause. Для таких материалов отдельно определяют доступ, redaction, retention и круг читателей. В статье нет настоящих сообщений, логов или пользователей; речь только о форме вопроса до публикации выводов.'),
h2('Проверьте решение по доступным фактам'),
p('Когда facts упорядочены, возьмите одно решение. Спросите: какой сигнал был доступен, какое действие выбрали, какие альтернативы были реально обратимы, что стало известно позже. Не спрашивайте «почему человек сделал это», пока не назвали границу его информации и управления. Решение может оказаться плохим даже при хороших намерениях, но это проверяется через условия: отсутствующий dashboard, неоднозначный runbook, слишком долгий deploy, права доступа, неясный owner, неверный stop criterion.'),
p('В fixed synthetic fixture решение `pause-synthetic-change-review` ссылается на три fact IDs. Оно не имеет `actor`, не получает оценку «правильно» или «ошибка» и не знает причин настоящего события. Такая искусственная строгость помогает провести live review: если участники добавляют к карточке человека как объяснение, нужно спросить, какое системное условие мы пытаемся изменить. Если ответа нет, это ещё не preventive action, а наблюдение о процессе, которому требуется отдельный evidence.'),
h2('Сделайте один experiment меньше, чем хочется'),
p('После восстановления timeline у команды часто десяток идей: новый мониторинг, больше тестов, запреты в CI, переписывание сервиса. Не принимайте их единым списком. Выберите один управляемый риск и сформулируйте experiment. Внутри него должны быть гипотеза, минимальный scope, criterion, владелец роли, дата review и rollback. Если criterion звучит как «ничего больше не сломается», задачу надо сузить: он не показывает, когда проверка завершена и что делать при отрицательном результате.'),
p('Хороший первый experiment может быть документальным и всё равно техническим. Например: для одного опасного действия в runbook добавить explicit stop criterion и rollback reference, затем провести review с человеком, который не участвовал в исходном сценарии. Успех — он может назвать границу остановки по документу; неуспех — поля неполны. Это не измерение reliability и не доказательство предотвращения outage. Зато оно даёт короткий feedback loop, который можно повторить до изменения production конфигурации.'),
h2('Используйте fixture как чек-лист против самообмана'),
p('Fixture держит пять fixed synthetic incident records в памяти. Он не читает файл, environment, clock, CI, сеть, incident storage, logs, traces, alerts или users. `runPostmortemFixture()` проверяет девятнадцать условий: полноту facts, порядок, связь decision с facts, явную границу actor, experiment с rollback и отрицательные ветки для culprit, root cause и real effect. Он не автоматизирует встречу, не делает расследование и не знает, что произошло в настоящем контуре.'),
code(syntheticExample+'\n\nnode web/scripts/upgrade-2023-11.mjs --verify-fixture\n\n# PASS означает только согласованность fixed synthetic records in memory.\n# Он не назначает виновника и не подтверждает фактическую причину, impact или production effect.'),
p('После прогона не переносите `PASS` в заголовок postmortem. Корректнее написать: «черновик выдержал проверку формы; источники и выводы требуют отдельного review». Если fixture отклонил `rootCause`, это не значит, что причин не существует. Значит, причина не должна появиться в наборе, который обязан описывать только fact, decision и experiment. Причинная гипотеза может жить отдельно, с уровнем уверенности, evidence и способом опровержения.'),
h2('Маршрут: симптом → причина → проверка → действие'),
ol([
'<strong>Симптом.</strong> Встреча застряла на воспоминаниях, оценках людей и споре о том, что было очевидно.',
'<strong>Причина.</strong> У документа нет границы между source-backed fact, решением в моменте и future experiment; позднее знание смешалось с исходным контекстом.',
'<strong>Проверка.</strong> По очереди маркируйте записи. Для fact потребуйте timestamp и evidence reference; для decision — только предшествующие facts; для experiment — criterion и rollback.',
'<strong>Действие.</strong> Остановите персональную оценку, заведите unknown как отдельную задачу и выберите один обратимый experiment вместо списка обещаний.',
'<strong>Проверка вывода.</strong> Попросите независимого читателя назвать из карточки, что известно, что было решено и что ещё только проверят. Если ответ смешан, переразметьте текст.',
'<strong>Следующий шаг.</strong> На следующем review посмотрите только на артефакт experiment: сделан ли критерий, не изменился ли scope, сохранён ли rollback и какой evidence допустим.',
]),
h2('Что делать при споре и при необходимости rollback'),
p('Если спор продолжается, не голосуйте за самую убедительную версию. Зафиксируйте competing hypotheses отдельно от facts и спросите, какое evidence могло бы различить их. Бывает, что такого evidence уже нет. Тогда честный результат — «не установлено», а следующий шаг — изменить instrument или retention для будущего случая. Это защита от решения, которое строится на уверенности без наблюдения.'),
p('Rollback реального change не выводится из одной ретроспективы. Он требует scope, доступа, операционного владельца, безопасного действия и наблюдаемой проверки. В fixture rollback возвращает лишь frozen synthetic snapshot и сообщает `productionEffect=not-attempted`. Не используйте этот код как operational procedure. Его роль — напомнить: действие нельзя считать обратимым, пока не названы точка возврата и способ увидеть, что обратная операция закончилась.'),
h2('Ограничения и следующий шаг'),
p('Здесь нет реального incident data, logs, traces, alerts, users, CI, network access или production runtime. Timeline и experiment — fixed synthetic records. Статья не делает вывода о людях, причинах, security impact, доступности, финансовом ущербе, пользователях или эффекте настоящего изменения. Она также не заменяет incident command, HR-процесс, legal review, privacy policy и требования к disclosure. Эти границы необходимо определить для своего окружения отдельно.'),
p('Следующий шаг — провести короткий rehearsal на synthetic карточке: ведущий, независимый читатель и reviewer action item. Цель — проверить язык документа: видны ли facts, граница решения, unknown, criterion и rollback. Затем адаптируйте template под допустимые источники и роли команды. Если адаптация требует выдуманных цифр или «идеального» героя, вернитесь к меньшему эксперименту и наблюдаемому артефакту.'),
h2('Историческая граница ноября 2023'),
p('До конца ноября 2023 официально были опубликованы Google SRE Book 2017, включая главу о blameless postmortem и example с timeline, а также NIST SP 800-61 Rev. 2 (2012) и CISA federal playbooks (2021) для cybersecurity incident response. Они поддерживают идею documented follow-up и lessons learned в своих областях. Автор не приписывает им универсальную организационную модель, не заявляет, что этот маршрут проверен на конкретной команде, и не переносит поздние инструменты или требования в 2023 год.'),
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
