Files
huncode 0f4693007e
Build and deploy / deploy (push) Successful in 17s
revise December 2024 maintenance retro articles
2026-07-31 17:07:07 +03:00

134 lines
11 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# P82 — декабрь 2024: maintenance retro
## Scope и граница выпуска
Пакет заменяет только три декабрьские overlay-ревизии:
- editorial-2024-12-practice-maintenance-retro
- editorial-2024-12-mechanism-maintenance-retro
- editorial-2024-12-field-maintenance-retro
Все owners, evidence, cases, scores, costs, timelines и outcomes в материале
являются versioned fixed synthetic in-memory literals из
synthetic-maintenance-retro/2024-12-v1. Скрипт не читает filesystem, Git, CI,
network, telemetry, incident archive, clock, team history или production state.
Он не выполняет deployment, deletion, rollback или любой внешний change.
## Досье источников
Все URL ниже проверены обычным HTTPS GET 2026-07-31: HTTP 200, без
аутентификации и TLS bypass. Это источники, существовавшие до декабря 2024.
| Источник, дата или версия | Точная поддерживаемая мысль | Ограничение источника |
| --- | --- | --- |
| [Google SRE Book, Chapter 15: Postmortem Culture: Learning from Failure](https://sre.google/sre-book/postmortem-culture/), первое издание 2016 | Postmortem фиксирует воздействие, причины, response и follow-up; триггеры и owner action item должны быть определены, а обучение не равно поиску виноватого. | Не задаёт maintenance backlog score, не подтверждает историю читателя и не санкционирует change. |
| [Google SRE Book, Chapter 5: Eliminating Toil](https://sre.google/sre-book/eliminating-toil/), первое издание 2016 | Повторяемую ручную операционную работу полезно отличать от устойчивой инженерной ценности; источник toil стоит устранять осознанно. | Не говорит, что любая ручная проверка является долгом, и не даёт универсальную оценку времени или денег. |
| [NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments](https://csrc.nist.gov/pubs/sp/800/30/r1/final), final September 2012 | Risk assessment служит информацией для выбора курса действий; контекст и uncertainty нельзя подменять одним числом. | Не утверждает, что формула из этой статьи — вероятность, стандартная шкала или финансовый прогноз. |
| [NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning](https://csrc.nist.gov/pubs/sp/800/40/r4/final), final April 2022 | Preventive maintenance различает identification, prioritization, implementation и verification. | Не заменяет локальные ownership rules, approval, tests, change window или проверку конкретной системы. |
Покрытие на статью:
- Practice использует минимум Google postmortem и Google toil; NIST SP 800-30
и SP 800-40 уточняют границу оценки и preventive maintenance.
- Mechanism использует минимум NIST SP 800-30 и SP 800-40; Google toil
объясняет, почему повторяемость не равна любой ручной работе.
- Field использует минимум Google postmortem и NIST SP 800-40; Google toil и
NIST SP 800-30 ограничивают выводы из повторяемости и score.
## Проход 1 — факты и техника
Проверено вручную:
- Во всех трёх текстах первые два абзаца называют ситуацию и цену ошибки.
Нет утверждения о реальном incident, team history, customer, metric, saving
или production outcome.
- Practice отделяет symptom, risk, cost class, owner role, evidence boundary и
one next experiment. Ценой названы только учебные классы: interrupt, delay
review и recheck, а не деньги.
- Mechanism прямо называет formula
impact * repeatability + uncertainty * 2 - evidenceStrength учебной.
Heatmap задаёт только review order; score не назван вероятностью, бюджетом,
прогнозом или разрешением на change.
- Field имеет три fixed synthetic case, T0–T3 timeline, recheck loop,
stop rule, restore question и next-quarter plan. Stop path отбрасывает
draft; это не production rollback.
- Контракт модели требует exact keys и canonical fixed report/draft. Fixture
покрывает unknown keys, missing fields, forged score, dense arrays, sparse
nested array, cyclic report, cyclic draft, mutated actions и safe stop path.
- Техническая проверка не нашла imports, fetch, filesystem, child process или
HTTP client в overlay script. Внешние URL находятся только в опубликованном
source list и не являются I/O модели.
После этого прохода уточнена формулировка «явная граница доказательств» и
убраны неясные смешанные фразы, чтобы reader не принимал synthetic artefact за
наблюдение реальной системы.
## Проход 2 — редактура и голос
Прочитаны полные тела статей до списка источников:
| Статья | Объём основного текста | Редакторский вывод |
| --- | ---: | --- |
| Practice | 10 020 знаков | Уплотнена вокруг review-card: symptom → причина → проверка → один experiment. Есть таблицы, code example, figure, ограничения и следующий шаг. |
| Mechanism | 10 259 знаков | Score сначала ограничен evidence types и priority boundary. Из текста убраны обещания точной стоимости и «математического» решения. |
| Field | 11 665 знаков | Три case не превращены в выдуманное ретро. Timeline отделяет draft, recheck и отдельный human-approved change. |
Голос соответствует декабрю 2024: системный практик показывает наблюдаемый
артефакт, цену решения, ownership и путь проверки, но не пишет от лица
универсальной платформенной стратегии 2027 года. Термины раскрываются рядом с
сценарием, а абзацы следуют цепочке symptom → причина → проверка → действие.
## Проход 3 — визуал и выпуск
Проверено вручную:
- SVG открыты и просмотрены после Sharp-render на ширине 375 px:
heatmap — 375×271, change timeline — 375×240, review loop — 375×260.
Основные заголовки, карточки, направления и boundary остаются читаемыми;
HTML-подписи дополняют схему без скрытого смысла.
- У каждой статьи есть meaningful alt, figcaption, минимум одна HTML table,
compact reproducible code example, numbered action sequence, source section,
limitations и concrete next step.
- XML проходит xmllint. Safety scan не нашёл script, foreignObject,
javascript URI, data:image или event handler.
- node --check проходит.
- node scripts/upgrade-2024-12.mjs --verify-fixture проходит:
PASS fixture: 31/31 assertions.
- npm run audit:draft -- scripts/upgrade-2024-12.mjs проходит для всех трёх
slug.
До интеграции registry, README, очередь, articles.json, staging, commit и push
намеренно не выполнялись: они были вне разрешённого scope P82.
## Вердикт
P82 готов как самостоятельный draft-пакет. Он может быть интегрирован отдельным
выпускным шагом после review общего registry; текущий пакет сам ничего не
публикует и не изменяет внешний state.
## Выпуск после независимой приёмки
Основной редактор провёл отдельные три прохода уже после интеграции:
1. **Факты и техника.** Официальная глава Google о postmortem подтверждает
запись воздействия, причин, действий и follow-up, а также необходимость
заранее определить triggers. Глава о toil отделяет повторяемую ручную работу
от работы с устойчивой ценностью. Официальные страницы NIST подтверждают
final-статус SP 800-30 Rev. 1 (сентябрь 2012) и SP 800-40 Rev. 4 (апрель
2022); вторая явно различает identifying, prioritizing, installing и
verifying. Эти источники не расширены до утверждений о реальной системе.
`node --check` и fixture повторно прошли: **31/31**.
2. **Редактура и голос.** Полные тексты перечитаны после интеграции. В ранних
абзацах раскрыты рабочие англоязычные термины: `review`, `card`,
`evidence boundary`, `score`, `timeline`, `recheck` и `stop`. Это оставляет
язык коротким для инженера 2024 года, но не заставляет читателя угадывать
смысл терминов. `audit:draft` и целевой `audit:articles` подтвердили объём,
по рисунку, коду и минимум две таблицы в каждой статье.
3. **Визуал и выпуск.** Все три SVG снова отрисованы Sharp на 375 px и
просмотрены: heatmap — 375×271, timeline — 375×240, loop — 375×260;
подписи, карточки и стрелки остаются читаемыми. XML и safety scan чисты.
Реестр содержит **241 уникальную** ревизию. `git diff --check` чист, а
`npm run build` успешно собрал **374** статические страницы.
Вердикт: три декабрьские статьи готовы к отдельному публикационному коммиту.