diff --git a/editorial/agent-rewrites/125.json b/editorial/agent-rewrites/125.json
index 61f823a..d43fb10 100644
--- a/editorial/agent-rewrites/125.json
+++ b/editorial/agent-rewrites/125.json
@@ -1,7 +1,7 @@
 {
   "index": 125,
   "slug": "editorial-2024-07-mechanism-release-engineering",
-  "title": "Инженерия релиза: как связать артефакт, миграцию и откат",
-  "excerpt": "Один номер версии не доказывает, что команда выпускает нужный код. Разбираем цепочку commit → artifact → migration → rollout и ставим проверяемый стоп перед ошибочным deploy.",
-  "contentHtml": "<p>После выкладки сервис отвечает старым поведением, хотя в CI и карточке релиза стоит одна версия — <code>2024.07.0</code>. Откат возвращает прежний контейнер, но ошибка в данных остаётся. Команда повторяет deploy, меняет таймаут и смотрит на зелёный статус job. Это не исправляет расхождение. Цена ошибки — потерянное время, спор о том, что именно работает, и риск усугубить миграцию данных.</p>\n<p>Тезис простой: релиз нужно проверять как цепочку связей, а не как строку с версией. Commit должен быть источником артефакта. Rollout должен ссылаться на точный digest артефакта. Миграция должна называть целевую версию и границу совместимости. Для возврата нужно заранее назвать версию и digest. Если хотя бы одна связь не сходится, процесс останавливается до deploy.</p>\n<h2>Механизм: четыре связи вместо одного тега</h2>\n<p>Тег отвечает на вопрос «как назвали выпуск». Он не отвечает на вопросы «из какого commit собрали образ», «какой образ запросил rollout» и «для какой схемы написана миграция». Для этих вопросов нужны неизменяемые значения и явные предикаты.</p>\n<ul><li><code>artifact.sourceCommitId === commit.id</code> — артефакт собран из заявленного commit.</li><li><code>rollout.requestedArtifactDigest === artifact.digest</code> — намерение выкладки указывает тот же контент.</li><li><code>migration.targetReleaseVersion === release.version</code> — миграция относится к этому выпуску.</li><li><code>returnPoint.version</code> и <code>returnPoint.digest</code> заполнены — у возврата есть конкретная точка.</li></ul>\n<p>Эти условия проверяют согласованность записей. Они не доказывают, что deploy завершился, что registry доступен или что миграция обратима. Execution result и release evidence — разные вещи. Успешный rollout может работать с неправильным артефактом. Согласованный record может ещё не быть разрешением на выкладку.</p>\n<h2>Учебный пример расхождения</h2>\n<p>Ниже — синтетические записи. Они не получены из production и не описывают реальную доставку.</p>\n<pre><code>const commit = {\n  id: 'synthetic-commit-91',\n  releaseVersion: '2024.07.0'\n};\n\nconst artifact = {\n  digest: 'sha256:synthetic-artifact-42',\n  sourceCommitId: 'synthetic-commit-other-91'\n};\n\nconst migration = {\n  targetReleaseVersion: '2024.07.0',\n  compatibleWith: '2024.06.x'\n};\n\nconst rollout = {\n  requestedArtifactDigest: 'sha256:synthetic-artifact-42'\n};\n\nconst checks = {\n  sourceMatches: artifact.sourceCommitId === commit.id,\n  artifactMatches: rollout.requestedArtifactDigest === artifact.digest,\n  migrationMatches: migration.targetReleaseVersion === commit.releaseVersion\n};\n\nconst canDeploy = Object.values(checks).every(Boolean);\n// false: остановить процесс и сверить записи\n</code></pre>\n<p>Две проверки проходят. Артефакт и rollout называют один digest, миграция нацелена на правильную версию. Но source commit не совпадает. Поэтому <code>canDeploy</code> равен <code>false</code>. Нельзя делать вывод, что контейнер содержит код из <code>synthetic-commit-91</code>. Нельзя лечить это повторным запуском того же deploy. Сначала нужно найти источник расхождения и заново зафиксировать запись.</p>\n<p>Обратный путь важен не меньше. Возврат контейнера к предыдущему digest не отменяет изменение схемы или данных. Если миграция уже прошла, прежний код может не поддерживать новую схему. В карточке возврата нужно разделить два действия: вернуть code artifact и решить, что делать с data effect. Если второго решения нет, честный статус — «возврат артефакта подготовлен, откат данных не определён».</p>\n<figure><img src=\"/assets/editorial/2024/release-engineering-2024-rollback-table.svg\" alt=\"Связи между артефактом, миграцией, rollout и точкой возврата\" /><figcaption>Учебная схема показывает границу: code rollback возвращает названный артефакт, но не обещает отмену миграции.</figcaption></figure>\n<h2>Симптом → причина → проверка → действие</h2>\n<table><caption>Диагностика рассогласованного релиза</caption><thead><tr><th>Симптом</th><th>Причина</th><th>Проверка</th><th>Действие</th></tr></thead><tbody><tr><td>Везде одна версия, но поведение разное</td><td>Тег используют как единственный идентификатор</td><td>Сравнить exact commit id и artifact sourceCommitId</td><td>Остановить выпуск и пересобрать evidence chain</td></tr><tr><td>Rollout зелёный, но загружен не тот образ</td><td>Карточка хранит tag вместо digest</td><td>Сравнить requestedArtifactDigest с digest артефакта</td><td>Исправить intent record, не повторять deploy</td></tr><tr><td>После возврата код падает на данных</td><td>Rollback контейнера приняли за rollback данных</td><td>Проверить target schema, compatibility и migration status</td><td>Передать data effect отдельному владельцу и остановить автоматический возврат</td></tr><tr><td>Миграция прошла для другой версии</td><td>План миграции следует ветке или последнему main</td><td>Сравнить targetReleaseVersion с release.version</td><td>Закрыть gate и выпустить новый migration review</td></tr><tr><td>Невозможно объяснить, что вернётся</td><td>Return point описана словом «предыдущий»</td><td>Проверить конкретные version и digest</td><td>Не давать approval, пока точка возврата не названа</td></tr></tbody></table>\n<p>Таблица полезна только тогда, когда каждая проверка имеет владельца и stop action. Строка «все jobs зелёные» недостаточна: она не связывает job с содержимым артефакта и контрактом данных. Строка «digest совпал» тоже недостаточна: она не подтверждает доступность сервиса после выкладки. Не смешивайте semantic consistency с результатом исполнения.</p>\n<h2>Почему миграция меняет смысл отката</h2>\n<p>У релиза есть как минимум два состояния: code state и data state. Deployment обычно управляет шаблоном Pod или другим runtime artifact. Миграция меняет схему, записи или внешний контракт. Эти операции могут иметь разные владельцы, журналы и способы возврата.</p>\n<p>Безопасный порядок требует compatibility window. Новый код сначала должен работать со старой и новой формой данных, если это возможно. Затем миграция меняет данные. После проверки трафика команда может удалить старую ветку совместимости. В такой схеме возврат на старый код возможен только до закрытия окна. После него нужен отдельный план: обратная миграция, восстановление из backup или сохранение нового кода с исправлением.</p>\n<p>Это не универсальная стратегия миграций. Некоторые изменения нельзя отменить. Некоторые системы разрешают только forward migration. Статья не утверждает, что любой Kubernetes Deployment или любой image digest можно безопасно вернуть. Она требует назвать границу действия и не приписывать rollback то, чего он не делает.</p>\n<h2>Порядок действий перед deploy</h2>\n<ol><li><strong>Зафиксируйте release version и owner проверки.</strong> Owner отвечает за сравнение записей, но это не делает его автоматически исполнителем deploy.</li><li><strong>Проверьте связь commit → artifact.</strong> Сравните exact id. Название ветки, последний merge и номер задачи не заменяют идентификатор commit.</li><li><strong>Проверьте artifact → rollout.</strong> Сравните immutable digest. Не подставляйте digest по тегу и не считайте совпадение имён доказательством.</li><li><strong>Опишите migration target и compatibility.</strong> Назовите версию, допустимый предыдущий контракт и отдельный data effect.</li><li><strong>Проверьте все предикаты.</strong> При первом <code>false</code> верните статус <code>stop-and-reconcile-records</code>. Не запускайте новую попытку ради зелёного job.</li><li><strong>Подготовьте return point.</strong> Запишите version и digest артефакта для возврата. Рядом укажите, что произойдёт с данными.</li><li><strong>Отделите approval от исполнения.</strong> Проверка записи разрешает перейти к авторизованному review, но сама не вызывает registry, cluster или deploy runner.</li></ol>\n<h2>Ограничения</h2>\n<p>Эта модель не проверяет настоящий Git history, подпись, identity builder, provenance, registry, environment configuration, secrets, права доступа, database state, трафик и telemetry. Она не выдаёт уровень SLSA и не доказывает, что конкретный attestation заслуживает доверия. Для этого нужны отдельные политики, хранилища и проверяющие компоненты.</p>\n<p>Учебный код также не является CI-конфигурацией. Синтетические id и digest нужны, чтобы показать рассуждение на закрытом наборе данных. Реальные значения нельзя подменить в этом примере и затем считать результат производственным evidence. Практический перенос начинается с одного разрешённого release record и read-only проверки, а не с подключения fixture к deploy.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Релиз готов к авторизованному review, если второй проверяющий без устных пояснений находит в одной записи:</p>\n<ul><li>точный commit id, из которого заявлен artifact;</li><li>точный artifact digest, который запросил rollout;</li><li>target версии миграции и её compatibility boundary;</li><li>version и digest для возврата;</li><li>отдельное решение по data effect.</li></ul>\n<p>Проверяющий должен назвать результат каждой связи: <code>true</code> или <code>false</code>, stop action при <code>false</code> и владельца следующего вопроса. Если он может только сказать «job зелёный», критерий не выполнен. Это проверяемый предел статьи: согласовать записи до действия, не объявить production success.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://slsa.dev/spec/v1.0/\" target=\"_blank\" rel=\"noopener noreferrer\">SLSA v1.0 specification</a> — термины provenance и verification.</li><li><a href=\"https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/about-artifact-attestations\" target=\"_blank\" rel=\"noopener noreferrer\">GitHub: About artifact attestations</a> — официальное описание attestations и их границ.</li><li><a href=\"https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-back-a-deployment\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: Rolling back a Deployment</a> — что именно возвращает Deployment rollback.</li></ul>"
+  "title": "Инженерия релиза: как доказать связь артефакта, миграции и отката",
+  "excerpt": "Одинаковая версия в CI не доказывает, что будет доставлен нужный код. Разбираем цепочку commit → artifact → migration → rollout и ставим проверяемый stop до deploy.",
+  "contentHtml": "<p>Симптом после выкладки: сервис отвечает старым поведением, хотя в CI и карточке релиза написано <code>2024.07.0</code>. Команда повторяет deploy, увеличивает таймаут и смотрит на зелёный job. Если перед этим миграция изменила данные, откат контейнера может вернуть старый код, но не вернуть прежнее состояние базы. В итоге спорят не о причине сбоя, а о том, какой именно артефакт вообще работает.</p>\n<p>Номер версии удобен человеку, но слаб как единственное доказательство. Надёжнее проверять цепочку: заявленный commit связан с provenance сборки, rollout указывает на неизменяемый digest образа, миграция называет целевую границу совместимости, а для возврата записана конкретная ревизия. Это не разрешение на выкладку и не обещание успешного production deploy. Это stop-проверка, которая не даёт продолжить при расхождении записей.</p>\n<h2>Что должна доказать запись о релизе</h2>\n<p>Сначала разделим четыре разных вопроса. <strong>Источник.</strong> Из какого точного commit получены входы сборки? <strong>Артефакт.</strong> Какой digest соответствует результату сборки? <strong>Изменение данных.</strong> Какую схему или форму записи ожидает новая версия? <strong>Исполнение.</strong> Какой digest запросил rollout и чем подтверждено его завершение?</p>\n<p>Эти вопросы связаны, но не взаимозаменяемы. Provenance — это подписанная или иным образом проверяемая информация о том, как получен артефакт; она не заменяет политику потребителя. Digest идентифицирует содержимое образа, но не подтверждает, что образ запущен в нужном окружении. Успешный статус rollout говорит о состоянии Deployment, а не об обратимости миграции. Поэтому release record должен хранить отдельные поля, а проверка — отдельные результаты.</p>\n<table><caption>Границы доказательств в цепочке релиза</caption><thead><tr><th>Связь</th><th>Проверяемое утверждение</th><th>Что не следует из успеха проверки</th></tr></thead><tbody><tr><td>commit → provenance</td><td>В provenance зафиксирован ожидаемый источник или dependency с точным идентификатором.</td><td>Сборка безопасна от всех атак и полностью воспроизводима.</td></tr><tr><td>provenance → artifact</td><td>Subject attestation относится к конкретному артефакту, а signer и builder входят в доверенную политику.</td><td>Артефакт без уязвимостей и подходит каждому окружению.</td></tr><tr><td>artifact → rollout</td><td>В намерении выкладки указан тот же immutable digest.</td><td>Контейнер уже запущен и прошёл проверки доступности.</td></tr><tr><td>migration → release</td><td>Миграция называет совместимую целевую версию и известный data effect.</td><td>Миграцию можно безопасно отменить одной командой.</td></tr><tr><td>return point → rollback</td><td>Названы точные version, digest и действие для данных.</td><td>Старый код поддерживает новую схему после закрытия окна совместимости.</td></tr></tbody></table>\n<h2>Маленький gate на синтетических данных</h2>\n<p>Ниже — самодостаточная проверка для командной строки. Записи вымышлены: значение примера в том, что одна связь намеренно сломана. Файл не вызывает registry, cluster или deploy runner; он только вычисляет логический результат из локального release record.</p>\n<pre><code>cat &gt; release-record.json &lt;&lt;'JSON'\n{\n  \"releaseVersion\": \"2024.07.0\",\n  \"commit\": { \"id\": \"commit-91\" },\n  \"provenance\": {\n    \"sourceCommitId\": \"commit-91\",\n    \"artifactDigest\": \"sha256:artifact-42\",\n    \"builderId\": \"ci.example/build\"\n  },\n  \"rollout\": { \"requestedDigest\": \"sha256:artifact-other\" },\n  \"migration\": {\n    \"targetVersion\": \"2024.07.0\",\n    \"compatibleWith\": [\"2024.06.x\"],\n    \"dataEffect\": \"adds nullable profile.locale\"\n  },\n  \"returnPoint\": {\n    \"version\": \"2024.06.4\",\n    \"digest\": \"sha256:previous-17\",\n    \"dataAction\": \"keep forward-compatible column\"\n  }\n}\nJSON\n\njq -e '\n  .provenance.sourceCommitId == .commit.id\n  and .provenance.artifactDigest == .rollout.requestedDigest\n  and .migration.targetVersion == .releaseVersion\n  and (.returnPoint.version != \"\" and .returnPoint.digest != \"\")\n' release-record.json\n# jq: false, exit code 1 — rollout digest не совпал\n</code></pre>\n<p>Команда завершится с кодом <code>1</code>, потому что <code>sha256:artifact-other</code> не равен digest, записанному в provenance. Три прочие части примера согласованы, но этого недостаточно: gate должен остановить действие при одном <code>false</code>. После исправления записи полезно повторить ту же команду и отдельно проверить, что исполнение rollout действительно завершилось. Логический <code>true</code> не подменяет runtime evidence.</p>\n<figure><img src=\"/assets/editorial/2024/release-engineering-2024-rollback-table.svg\" alt=\"Схема проверки релиза: commit и provenance связаны с digest артефакта, rollout сверяется с ним, а migration и точка возврата проверяются отдельно\" /><figcaption>Схема разделяет проверку кода и проверку данных: возврат Deployment касается шаблона Pod, но не обещает отменить уже выполненную миграцию.</figcaption></figure>\n<h2>Как читать расхождение</h2>\n<p>Если в карточке и в CI одна версия, а поведение разное, первым делом не запускайте новый deploy. Получите фактический digest запущенного образа и сравните его с digest в намерении выкладки. Затем сопоставьте provenance с ожидаемым commit и доверенным builder. Здесь важно не восстановить «примерно ту же сборку», а найти конкретную точку, где цепочка перестала быть доказуемой.</p>\n<p>Если rollout указывает на правильный digest, но сервис всё ещё ведёт себя иначе, это уже другой класс проверки: конфигурация окружения, feature flag, кеш, трафик, версия зависимого сервиса и само состояние приложения. Цепочка артефакта не доказывает идентичность всех этих входов. Она лишь не позволяет списать любой эффект на слово «релиз».</p>\n<p>При расхождении миграции с release version нужно остановить и повторно согласовать план данных. Подмена значения в карточке задним числом стирает след ошибки. Зафиксируйте, какая миграция уже запущена, какие записи она изменила и с какой версией остаётся совместимой. Если этих сведений нет, статус должен быть «данные не классифицированы», а не «rollback готов».</p>\n<h2>Почему откат образа не откатывает данные</h2>\n<p>У приложения есть минимум два состояния: кодовый артефакт и состояние данных. Kubernetes Deployment хранит историю ревизий и позволяет вернуть Pod template к предыдущей ревизии, если она ещё доступна. Это полезно при проблеме с образом или параметрами запуска. Но команда <code>kubectl rollout undo</code> не отменяет SQL-миграцию, изменение документа или уже отправленное внешнему сервису событие.</p>\n<p>Поэтому миграцию стоит проектировать с окном совместимости, когда новый код умеет читать старую и новую форму данных. Сначала выкладывается код, способный работать в этом окне, затем выполняется изменение данных, после наблюдения удаляется старая ветка. Конкретный порядок зависит от хранилища и миграционного инструмента; это не универсальная лицензия на обратную миграцию.</p>\n<p>До закрытия окна точка возврата может быть обычным предыдущим артефактом. После закрытия нужно отдельное решение: forward fix, обратная миграция, восстановление резервной копии или сохранение нового кода с исправлением. В release record это должен быть явный <code>dataAction</code>, а не слово «откат» без объекта действия.</p>\n<h2>Порядок проверки перед approval</h2>\n<ol><li><strong>Снимите исходные идентификаторы.</strong> Запишите release version, точный commit SHA, digest артефакта, builder и окружение. Ветка, номер задачи и tag остаются удобными ссылками, но не заменяют SHA и digest.</li><li><strong>Проверьте provenance.</strong> Сверьте subject артефакта, source или dependency, signer и builder с политикой команды. Если используется attestation, проверяйте её криптографически, а не только открывайте страницу с метаданными.</li><li><strong>Сверьте намерение и исполнение.</strong> В manifest или release record должен быть тот же digest, который был разрешён. После deploy сохраните отдельное подтверждение состояния и времени rollout.</li><li><strong>Опишите data effect.</strong> Назовите таблицу, поля, документы или события, которые изменятся, а также допустимую старую форму. Не ставьте approval, если миграция существует только как название job.</li><li><strong>Назовите return point.</strong> Укажите конкретные version и digest для кода и отдельное решение для данных. Проверьте, что требуемая ревизия не удалена политикой хранения истории.</li><li><strong>Остановитесь при первом false.</strong> Верните запись на reconcile, не запускайте повторную попытку ради зелёного CI. Approval относится к проверенной записи; он не является доказательством фактического успеха выкладки.</li></ol>\n<h2>Границы применимости</h2>\n<p>Этот маршрут подходит как минимальный контроль согласованности для релиза, где команда может получить commit, provenance, digest, план миграции и запись rollout. Он не заменяет сканирование уязвимостей, review кода, проверку секретов, контроль прав, тесты совместимости, резервное копирование, мониторинг или процедуру incident response.</p>\n<p>SLSA описывает модель provenance и требования к её проверке, но не объявляет конкретный артефакт безопасным. GitHub отдельно предупреждает, что artifact attestation связывает артефакт с источником и инструкциями сборки, а решение о доверии требует собственной политики. В частном registry, другой CI-системе или без доверенного корня проверки команды и поля будут другими.</p>\n<p>Синтетический <code>release-record.json</code> нельзя подключать к настоящему deploy без адаптации схемы, прав и источников фактов. Kubernetes-команды требуют доступа к конкретному кластеру и работают с историей, которую можно ограничить настройкой <code>revisionHistoryLimit</code>. Если миграция необратима или внешний эффект уже ушёл, честный результат может быть «код возвращён, data effect остаётся».</p>\n<h2>Проверяемый результат</h2>\n<p>Перед авторизованной выкладкой второй инженер должен без устных пояснений найти в записи пять вещей: точный источник сборки, digest артефакта, digest в rollout, границу совместимости миграции и раздельный план возврата кода и данных. Для каждой связи должен быть результат <code>true</code> или <code>false</code>, а для <code>false</code> — владелец сверки и стоп-действие.</p>\n<p>После выкладки добавьте к этим записям фактический результат rollout и наблюдаемый сигнал приложения. Только тогда можно обсуждать поведение окружения. Такая последовательность возвращает разговор к исходному симптому: мы проверяем не красивую строку версии, а то, что именно собрано, что именно запрошено, что изменилось в данных и что реально можно вернуть.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://slsa.dev/spec/v1.2/provenance\" target=\"_blank\" rel=\"noopener noreferrer\">SLSA v1.2: Provenance</a> — модель provenance, subject, build definition и требования к проверке.</li><li><a href=\"https://docs.github.com/en/actions/concepts/security/artifact-attestations\" target=\"_blank\" rel=\"noopener noreferrer\">GitHub Docs: Artifact attestations</a> — назначение attestations и ограничение: они не являются гарантией безопасности артефакта.</li><li><a href=\"https://kubernetes.io/docs/tasks/run-application/update-deployment-rolling/#rolling-back-to-a-previous-revision\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes Docs: Rolling back to a previous revision</a> — команды просмотра истории и возврата Deployment к ревизии.</li><li><a href=\"https://kubernetes.io/docs/concepts/workloads/controllers/deployment/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes Docs: Deployments</a> — граница rollback: возвращается Pod template, а не произвольное состояние данных.</li></ul>"
 }
diff --git a/editorial/agent-rewrites/126.json b/editorial/agent-rewrites/126.json
index 5d8fd6f..243e578 100644
--- a/editorial/agent-rewrites/126.json
+++ b/editorial/agent-rewrites/126.json
@@ -1,7 +1,7 @@
 {
   "index": 126,
   "slug": "editorial-2024-07-practice-release-engineering",
-  "title": "Релиз без догадок: как проверить связь между commit, artifact и rollback",
+  "title": "Релиз без догадок: как связать commit, artifact и rollback",
   "excerpt": "Одинаковый tag не доказывает, что команда собирается доставить нужный код. Разбираем проверяемую цепочку от commit до rollout, отрицательный путь и границу rollback для данных.",
-  "contentHtml": "<p>После выкладки сервис отвечает кодом старой версии, хотя в заявке указан новый релиз. В карточке сборки, образе и rollout стоит один tag. Команда повторяет запуск, но не может быстро ответить на три вопроса: из какого commit собран artifact, какой digest отправили и совместима ли migration с данными. Цена ошибки растёт с каждой попыткой: увеличивается окно сбоя, меняется состояние базы, а точку возврата приходится восстанавливать по разным журналам.</p>\n<p>Одинаковая версия не связывает объекты сама по себе. Релиз готов к следующему действию только тогда, когда можно сравнить exact commit id, immutable digest, migration target и return point. Если одна связь неизвестна или ложна, проверка должна остановить выпуск. Новый retry не исправляет расхождение записей.</p>\n<h2>Механизм цепочки</h2>\n<p>У релиза есть несколько разных объектов. <code>commit</code> фиксирует исходный revision. <code>artifact</code> содержит собранное содержимое и digest. <code>migration</code> меняет схему или данные и должна назвать целевую версию и совместимость. <code>rollout</code> описывает намерение отправить конкретный digest. <code>return point</code> указывает версию и digest, к которым можно вернуться.</p>\n<p>Эти записи не заменяют друг друга. Artifact должен ссылаться на exact commit, а не только на имя ветки. Rollout должен содержать digest artifact, а не mutable tag. Migration должна отвечать на вопрос о совместимости. Return point должен быть известен до разрешения операции. Такая цепочка не доказывает, что deploy уже состоялся. Она делает расхождение видимым до действия.</p>\n<figure><img src=\"/assets/editorial/2024/release-engineering-2024-delivery-chain.svg\" alt=\"Схема сверки commit, artifact, migration, rollout и точки возврата перед релизом\" loading=\"lazy\" /><figcaption>Учебная схема показывает связи между записями релиза. Она не является журналом CI, registry, кластером или результатом production-выкладки.</figcaption></figure>\n<h2>Минимальный пример</h2>\n<p>Ниже приведён учебный пример с вымышленными значениями. Код не обращается к Git, registry, CI, Kubernetes API или базе данных. Он только сравнивает записи. Положительный результат означает согласованность этих записей, а не готовность реальной среды.</p>\n<pre><code>const release = { version: '2024.07.0' };\nconst commit = { id: 'commit-7f4a0c1' };\nconst artifact = {\n  digest: 'sha256:release-070-a1',\n  sourceCommitId: 'commit-7f4a0c1',\n};\nconst migration = {\n  targetReleaseVersion: '2024.07.0',\n  compatibleWith: '2024.06.3',\n};\nconst rollout = {\n  requestedArtifactDigest: 'sha256:release-070-a1',\n  migrationVersion: '2024.07.0',\n};\n\nconst checks = {\n  source: artifact.sourceCommitId === commit.id,\n  migration: migration.targetReleaseVersion === release.version,\n  artifact: rollout.requestedArtifactDigest === artifact.digest,\n  rollout: rollout.migrationVersion === migration.targetReleaseVersion,\n};\n\nconst readyForReview = Object.values(checks).every(Boolean);\nif (!readyForReview) throw new Error('stop: reconcile release records');</code></pre>\n<p>Каждая проверка отвечает только на один вопрос. Если заменить <code>sourceCommitId</code> на другой id, результат станет отрицательным. Если изменить digest в rollout, tag всё ещё будет выглядеть правильно, но содержимое уже не совпадёт. Отрицательный путь важнее зелёной строки: система не выбирает за инженера «примерно подходящую» запись.</p>\n<p>Название <code>readyForReview</code> намеренно не означает <code>readyForDeploy</code>. Код не проверяет подпись, права, конфигурацию среды, состояние базы, доступность сервиса или факт доставки. Он лишь открывает следующий этап проверки, если четыре связи согласованы.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Диагностика расхождений до запуска</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Tag совпадает, но artifact ссылается на другой commit.</td><td>Tag используют вместо точной связи с исходным revision.</td><td>Сравнить <code>artifact.sourceCommitId</code> и commit id.</td><td>Остановить выпуск. Исправить запись или пересобрать artifact после решения владельца.</td></tr><tr><td>Старый код не читает новую схему.</td><td>Rollback образа ошибочно считают rollback данных.</td><td>Проверить target migration, совместимость и обратную процедуру.</td><td>Вернуть только разрешённый artifact. Изменение данных рассмотреть отдельно.</td></tr><tr><td>Rollout прошёл с тем же tag, но другим digest.</td><td>Намерение ссылается на изменяемую метку.</td><td>Сравнить requested digest с digest artifact.</td><td>Не запускать rollout. Пересоздать запись после сверки.</td></tr><tr><td>После остановки предлагают повторить deploy.</td><td>Retry используют вместо объяснения mismatch.</td><td>Найти первую ложную связь и её источник.</td><td>Сначала исправить записи, затем повторить только проверки.</td></tr><tr><td>Точку возврата называют «предыдущим релизом».</td><td>У return point нет конкретного содержимого.</td><td>Проверить version и immutable digest.</td><td>Не обещать возврат, пока обе величины не записаны.</td></tr></tbody></table></div>\n<p>Таблица разделяет разные классы риска. Ошибка commit относится к происхождению artifact. Ошибка digest относится к содержимому, выбранному для rollout. Ошибка migration относится к совместимости данных и кода. Неопределённый return point относится к возможности безопасно назвать действие после сбоя. Одно поле <code>release=green</code> не заменяет эти проверки.</p>\n<h2>Порядок действий перед выпуском</h2>\n<ol><li><strong>Назовите границу проверки.</strong> Зафиксируйте release version, owner и источник каждой записи. Укажите, что сейчас выполняется сверка, а не deploy.</li><li><strong>Свяжите artifact с commit.</strong> Проверьте exact source commit и digest. Имя ветки, последний merge и короткий tag не заменяют идентификатор.</li><li><strong>Опишите migration отдельно.</strong> Назовите target version, совместимость с текущим contract и действие по данным. Не прячьте migration в комментарии к образу.</li><li><strong>Сверьте rollout.</strong> Он должен содержать immutable digest artifact и migration version. Любое расхождение переводит процесс в stop.</li><li><strong>Назовите return point.</strong> Запишите предыдущую версию и digest. Отдельно укажите, что произойдёт с данными и кто проверит этот путь.</li><li><strong>Повторите проверки после исправления.</strong> Передайте дальше только записи без ложных связей. Положительный результат открывает авторизованную проверку, но не выдаёт разрешение на deploy.</li></ol>\n<h2>Почему rollback не возвращает данные</h2>\n<p>Rollback Deployment возвращает прежнюю ревизию Pod template. Это помогает вернуть код и настройки, которые входят в этот template. Но такой rollback не отменяет произвольный SQL, удалённую запись, заполненное поле или изменение внешнего contract. Если migration уже изменила данные, старый artifact может не уметь с ними работать.</p>\n<p>Поэтому return point должен содержать две границы. Первая говорит, какой artifact можно запустить. Вторая говорит, что разрешено делать с данными. Возможны обратная migration, совместимый промежуточный код, восстановление из резервной копии или запрет автоматического возврата. Пока выбранный путь не проверен, честная формулировка звучит так: «возврат artifact определён; откат данных не доказан».</p>\n<p>Та же граница действует для provenance и attestation. Provenance описывает происхождение сборки. Attestation может подтверждать утверждение об этом происхождении. Ни одно из них само по себе не доказывает совместимость migration, approval rollout или здоровье сервиса. Эти вопросы требуют собственных источников и проверок.</p>\n<h2>Ограничения и отрицательный путь</h2>\n<p>Схема ловит расхождения между названными записями. Она не доказывает правдивость каждого значения. Она не проверяет историю Git, содержимое образа, подпись, policy CI, права на кластер, runtime configuration, состояние базы, трафик, метрики или факт доставки.</p>\n<p>Если commit неизвестен, digest отсутствует, migration не содержит compatibility statement или return point не назван, результат должен быть отрицательным. Не подставляйте «последний main». Не ищите образ по tag. Не объявляйте rollback данных по факту возврата Pod template. Остановитесь на первой неизвестной границе и назначьте источник, который может её подтвердить.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Запись готова к передаче на авторизованную проверку, если второй инженер без устных пояснений может показать exact commit id, artifact digest, связь artifact с commit, migration target и compatibility, rollout digest, migration version и return point. Для каждой строки есть источник, владелец и действие при mismatch. Проверка даёт либо все утверждения <code>true</code>, либо конкретный stop с названием ложной связи.</p>\n<p>В учебном примере все значения вымышлены и не описывают production-результат. В реальном выпуске критерий нужно применять к доступным и разрешённым записям. Если одна строка не имеет источника или действия, выпуск не готов: сначала уточните contract, затем повторите сверку.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://slsa.dev/spec/v1.0/terminology\" target=\"_blank\" rel=\"noopener noreferrer\">SLSA v1.0: Terminology</a> — официально описывает provenance и два способа её проверки.</li><li><a href=\"https://docs.github.com/en/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations\" target=\"_blank\" rel=\"noopener noreferrer\">GitHub Docs: Using artifact attestations to establish provenance for builds</a> — описывает создание и проверку attestation для binary и container image.</li><li><a href=\"https://kubernetes.io/docs/concepts/workloads/controllers/deployment/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes Docs: Deployments</a> — описывает ревизии Deployment, rollout history и rollback Pod template.</li></ul>"
+  "contentHtml": "<p>После выкладки сервис отвечает кодом старой версии, хотя в заявке указан новый релиз. В карточке сборки, образе и rollout стоит один tag. Команда повторяет запуск, но не может быстро ответить на три вопроса: из какого commit собран artifact, какой digest отправили и совместима ли migration с данными. Цена ошибки растёт с каждой попыткой: увеличивается окно сбоя, меняется состояние базы, а точку возврата приходится восстанавливать по разным журналам.</p>\n<p>Одинаковая версия не связывает объекты сама по себе. Релиз готов к следующему действию только тогда, когда можно сравнить exact commit id, immutable digest, migration target и return point. Если одна связь неизвестна или ложна, проверка должна остановить выпуск. Новый retry не исправляет расхождение записей.</p>\n<h2>Что именно связывает релиз</h2>\n<p>У релиза есть несколько разных объектов. <code>commit</code> фиксирует исходный revision. <code>artifact</code> содержит собранное содержимое и digest. <code>migration</code> меняет схему или данные и должна назвать целевую версию и совместимость. <code>rollout</code> описывает намерение отправить конкретный digest. <code>return point</code> указывает версию и digest, к которым можно вернуться.</p>\n<p>В Git tag является ссылкой в пространстве имён <code>refs/tags/</code>. Он удобен для имени релиза, но запись с одним tag не заменяет зафиксированный commit: ссылку нужно разрешить и сохранить полный идентификатор. Для контейнерного образа digest — content identifier: OCI описывает его как хеш содержимого, который можно независимо проверить.</p>\n<p>Поэтому rollout должен ссылаться на digest, а не только на имя, которое может разрешиться иначе. Эти связи проверяют согласованность записей, но не являются разрешением на выкладку: они не проверяют права, политики CI, состояние registry или здоровье сервиса.</p>\n<figure><img src=\"/assets/editorial/2024/release-engineering-2024-delivery-chain.svg\" alt=\"Схема сверки commit, artifact, migration, rollout и точки возврата перед релизом\" loading=\"lazy\" /><figcaption>Учебная схема показывает связи между записями релиза. Она не является журналом CI, registry, кластером или результатом production-выкладки.</figcaption></figure>\n<h2>Минимальный пример</h2>\n<p>Ниже приведён учебный пример с вымышленными значениями. Код не обращается к Git, registry, CI, Kubernetes API или базе данных. Он только сравнивает записи. Положительный результат означает согласованность этих записей, а не готовность реальной среды.</p>\n<pre><code>const release = { version: '2024.07.0' };\nconst commit = { id: 'commit-7f4a0c1' };\nconst artifact = {\n  digest: 'sha256:release-070-a1',\n  sourceCommitId: 'commit-7f4a0c1',\n};\nconst migration = {\n  targetReleaseVersion: '2024.07.0',\n  compatibleWith: '2024.06.3',\n};\nconst rollout = {\n  requestedArtifactDigest: 'sha256:release-070-a1',\n  migrationVersion: '2024.07.0',\n};\nconst returnPoint = {\n  version: '2024.06.3',\n  digest: 'sha256:release-063-b7',\n};\n\nfunction inspect(candidateRollout) {\n  const checks = {\n    source: artifact.sourceCommitId === commit.id,\n    migration: migration.targetReleaseVersion === release.version,\n    artifact: candidateRollout.requestedArtifactDigest === artifact.digest,\n    rollout: candidateRollout.migrationVersion === migration.targetReleaseVersion,\n    returnPoint: Boolean(returnPoint.version &amp;&amp; returnPoint.digest),\n  };\n  return { checks, ok: Object.values(checks).every(Boolean) };\n}\n\nconst aligned = inspect(rollout);\nconst broken = inspect({\n  ...rollout,\n  requestedArtifactDigest: 'sha256:release-070-b2',\n});\n\nconsole.log(JSON.stringify({ aligned, broken }, null, 2));\nif (aligned.ok !== true || broken.ok !== false) {\n  throw new Error('unexpected validator result');\n}</code></pre>\n<p>Каждая проверка отвечает только на один вопрос. Если заменить <code>sourceCommitId</code> на другой id, результат станет отрицательным. Если изменить digest в rollout, tag всё ещё будет выглядеть правильно, но содержимое уже не совпадёт. Отрицательный путь важнее зелёной строки: система не выбирает за инженера «примерно подходящую» запись.</p>\n<p>Название <code>readyForReview</code> намеренно не означает <code>readyForDeploy</code>. Код не проверяет подпись, права, конфигурацию среды, состояние базы, доступность сервиса или факт доставки. Он лишь открывает следующий этап проверки, если четыре связи согласованы.</p>\n<h2>Как получить точные значения</h2>\n<p>Сначала соберите evidence в режиме чтения. Команды ниже используют примерные имена и не изменяют удалённый Git или Kubernetes. Выполняйте их только в репозитории и namespace, к которым у вас есть разрешение. Git разрешает tag до полного commit; Kubernetes показывает image reference в Pod template, историю ревизий и состояние rollout.</p>\n<pre><code>tag=v2024.07.0\ngit rev-parse \"$tag^{commit}\"\ngit show -s --format='%H %s' \"$tag^{commit}\"\n\nkubectl -n production get deployment/app   -o jsonpath='{.spec.template.spec.containers[?(@.name==\"app\")].image}{\"\\n\"}'\nkubectl -n production rollout history deployment/app\nkubectl -n production rollout status deployment/app --timeout=60s</code></pre>\n<p>Сохраните вывод рядом с release record и сравните его с заявленными значениями. Для контейнера ожидайте ссылку вида <code>registry.example/app@sha256:...</code>; если в Pod template остался только <code>registry.example/app:v2024.07.0</code>, имя ещё не доказывает выбранный digest. Последняя команда подтверждает состояние контроллера, но не происхождение образа, совместимость данных или пользовательский результат.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Диагностика расхождений до запуска</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Tag совпадает, но artifact ссылается на другой commit.</td><td>Tag используют вместо точной связи с исходным revision.</td><td>Сравнить <code>artifact.sourceCommitId</code> и commit id.</td><td>Остановить выпуск. Исправить запись или пересобрать artifact после решения владельца.</td></tr><tr><td>Старый код не читает новую схему.</td><td>Rollback образа ошибочно считают rollback данных.</td><td>Проверить target migration, совместимость и обратную процедуру.</td><td>Вернуть только разрешённый artifact. Изменение данных рассмотреть отдельно.</td></tr><tr><td>Rollout прошёл с тем же tag, но другим digest.</td><td>Намерение ссылается на изменяемую метку.</td><td>Сравнить requested digest с digest artifact.</td><td>Не запускать rollout. Пересоздать запись после сверки.</td></tr><tr><td>После остановки предлагают повторить deploy.</td><td>Retry используют вместо объяснения mismatch.</td><td>Найти первую ложную связь и её источник.</td><td>Сначала исправить записи, затем повторить только проверки.</td></tr><tr><td>Точку возврата называют «предыдущим релизом».</td><td>У return point нет конкретного содержимого.</td><td>Проверить version и immutable digest.</td><td>Не обещать возврат, пока обе величины не записаны.</td></tr></tbody></table></div>\n<p>Таблица разделяет разные классы риска. Ошибка commit относится к происхождению artifact. Ошибка digest относится к содержимому, выбранному для rollout. Ошибка migration относится к совместимости данных и кода. Неопределённый return point относится к возможности безопасно назвать действие после сбоя. Одно поле <code>release=green</code> не заменяет эти проверки.</p>\n<h2>Порядок действий перед выпуском</h2>\n<ol><li><strong>Назовите границу проверки.</strong> Зафиксируйте release version, owner и источник каждой записи. Укажите, что сейчас выполняется сверка, а не deploy.</li><li><strong>Свяжите artifact с commit.</strong> Проверьте exact source commit и digest. Имя ветки, последний merge и короткий tag не заменяют идентификатор.</li><li><strong>Опишите migration отдельно.</strong> Назовите target version, совместимость с текущим contract и действие по данным. Не прячьте migration в комментарии к образу.</li><li><strong>Сверьте rollout.</strong> Он должен содержать immutable digest artifact и migration version. Любое расхождение переводит процесс в stop.</li><li><strong>Назовите return point.</strong> Запишите предыдущую версию и digest. Отдельно укажите, что произойдёт с данными и кто проверит этот путь.</li><li><strong>Повторите проверки после исправления.</strong> Передайте дальше только записи без ложных связей. Положительный результат открывает авторизованную проверку, но не выдаёт разрешение на deploy.</li></ol>\n<h2>Почему rollback не возвращает данные</h2>\n<p>В Kubernetes новая ревизия Deployment создаётся при изменении Pod template, например image или label. Rollback возвращает часть template к предыдущей ревизии. Он не отменяет произвольный SQL, удалённую запись, заполненное поле, отправленное событие или изменение во внешней системе. Поэтому успех <code>kubectl rollout undo</code> нельзя называть откатом данных.</p>\n<p>Поэтому return point должен содержать две границы. Первая говорит, какой artifact можно запустить. Вторая говорит, что разрешено делать с данными. Возможны обратная migration, совместимый промежуточный код, восстановление из резервной копии или запрет автоматического возврата. Пока выбранный путь не проверен, честная формулировка звучит так: «возврат artifact определён; откат данных не доказан».</p>\n<p>Та же граница действует для provenance и attestation. Provenance описывает происхождение сборки. Attestation может подтверждать утверждение об этом происхождении. Ни одно из них само по себе не доказывает совместимость migration, approval rollout или здоровье сервиса. Эти вопросы требуют собственных источников и проверок.</p>\n<h2>Ограничения и отрицательный путь</h2>\n<p>Схема ловит расхождения между названными записями. Она не доказывает правдивость каждого значения. Она не проверяет историю Git, содержимое образа, подпись, policy CI, права на кластер, runtime configuration, состояние базы, трафик, метрики или факт доставки.</p>\n<p>Если commit неизвестен, digest отсутствует, migration не содержит compatibility statement или return point не назван, результат должен быть отрицательным. Не подставляйте «последний main». Не ищите образ по tag. Не объявляйте rollback данных по факту возврата Pod template. Остановитесь на первой неизвестной границе и назначьте источник, который может её подтвердить.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Запись готова к передаче на авторизованную проверку, если второй инженер без устных пояснений может показать exact commit id, artifact digest, связь artifact с commit, migration target и compatibility, rollout digest, migration version и return point. Для каждой строки есть источник, владелец и действие при mismatch. Проверка даёт либо все утверждения <code>true</code>, либо конкретный stop с названием ложной связи.</p>\n<p>В учебном примере все значения вымышлены и не описывают production-результат. В реальном выпуске критерий нужно применять к доступным и разрешённым записям. Если одна строка не имеет источника или действия, выпуск не готов: сначала уточните contract, затем повторите сверку.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://git-scm.com/docs/git-tag\" target=\"_blank\" rel=\"noopener noreferrer\">Git documentation: git-tag</a> — устройство tag reference, lightweight и annotated tags, команды разрешения и проверки тегов.</li><li><a href=\"https://github.com/opencontainers/image-spec/blob/main/descriptor.md\" target=\"_blank\" rel=\"noopener noreferrer\">OCI Image Specification: Content Descriptors</a> — digest как content identifier и независимая проверка содержимого descriptor.</li><li><a href=\"https://kubernetes.io/docs/concepts/workloads/controllers/deployment/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes Documentation: Deployments</a> — ревизии Deployment и граница rollback Pod template.</li><li><a href=\"https://slsa.dev/spec/v1.0/terminology\" target=\"_blank\" rel=\"noopener noreferrer\">SLSA v1.0: Terminology</a> — provenance, роли build platform и проверка provenance относительно ожиданий.</li></ul>"
 }
diff --git a/editorial/agent-rewrites/127.json b/editorial/agent-rewrites/127.json
index 747b267..87636d1 100644
--- a/editorial/agent-rewrites/127.json
+++ b/editorial/agent-rewrites/127.json
@@ -1,7 +1,7 @@
 {
   "index": 127,
   "slug": "editorial-2024-06-field-container-orchestration",
-  "title": "Kubernetes без ложных сигналов: как связать ресурсы, readiness и HPA",
-  "excerpt": "После релиза Pod может быть Unready, CPU — высоким, а HPA — не менять число реплик. Разбираем, какой контур породил симптом, чем его проверить и когда изменение манифеста действительно готово.",
-  "contentHtml": "<p>После обновления образа часть Pod-ов долго остаётся <code>Unready</code>. В графике растёт CPU. Команда предлагает увеличить <code>maxReplicas</code> и CPU limit. Это может не изменить ни одного симптома. Readiness управляет допуском Pod к трафику Service. HPA рассчитывает реплики по метрике. Scheduler размещает Pod по requests. Runtime применяет limits. Один Pod, четыре контура.</p>\n<p>Цена ошибки — не только лишние ресурсы. Новый Pod может не пройти readiness из-за зависимости. HPA может не считать CPU, если у контейнера нет request. Увеличенный limit может скрыть рост памяти до следующего отказа. Если изменить все поля сразу, команда потеряет причинную связь. Она не узнает, что именно сработало и какой риск остался.</p>\n<p><strong>Тезис.</strong> Сначала нужно назвать контракт сигнала, затем проверить его источником того же типа. Не называйте <code>Ready</code> доказательством capacity. Не называйте CPU percentage самостоятельным числом. Не называйте значение из учебной модели показанием кластера.</p>\n<h2>Механизм: четыре контура вместо одной «нагрузки»</h2>\n<p><strong>Request</strong> задаёт reservation contract. Scheduler учитывает requests контейнеров при выборе Node. Для одного ресурса request Pod складывается из requests его контейнеров. Это не прогноз постоянного потребления. Это условие размещения.</p>\n<p><strong>Limit</strong> задаёт границу ресурса для контейнера. CPU и memory ведут себя по-разному. CPU limit может ограничивать выполнение. Memory limit не превращается в прогноз пикового потребления и не объясняет lifetime cache или batch buffer. Нельзя вывести безопасные значения из одного универсального коэффициента.</p>\n<p><strong>Readiness</strong> отвечает на другой вопрос: можно ли отправлять трафик этому Pod сейчас. Когда Pod не готов, Service не должен использовать его как backend. Readiness probe не обязана объяснять причину. Readiness gate добавляет named condition, но не задаёт ей смысл. Владелец приложения должен определить producer, переход в <code>True</code> и путь восстановления.</p>\n<p><strong>HPA</strong> формирует предложение по числу реплик из метрики и target. CPU utilization — процент относительно CPU request контейнеров, которые попали в выборку. Если relevant request отсутствует, controller не может получить такой utilization для контейнера. Значит, строка <code>target: 65</code> без request не является рабочим scaling contract.</p>\n<pre><code>apiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: api\nspec:\n  replicas: 2\n  template:\n    spec:\n      containers:\n        - name: api\n          image: registry.example/api@sha256:...\n          resources:\n            requests:\n              cpu: 500m\n              memory: 256Mi\n            limits:\n              cpu: \"1\"\n              memory: 512Mi\n          startupProbe:\n            httpGet:\n              path: /startup\n              port: 8080\n          readinessProbe:\n            httpGet:\n              path: /ready\n              port: 8080\n          readinessGates:\n            - conditionType: example.com/SchemaReady\n---\napiVersion: autoscaling/v2\nkind: HorizontalPodAutoscaler\nmetadata:\n  name: api\nspec:\n  scaleTargetRef:\n    apiVersion: apps/v1\n    kind: Deployment\n    name: api\n  minReplicas: 2\n  maxReplicas: 10\n  metrics:\n    - type: Resource\n      resource:\n        name: cpu\n        target:\n          type: Utilization\n          averageUtilization: 70</code></pre>\n<p>Фрагмент учебный. Образ, пути probes, custom condition и значения ресурсов нельзя переносить в production без profile приложения и проверки среды. В манифесте видно главное: HPA percentage имеет denominator <code>requests.cpu: 500m</code>. Readiness gate не становится HPA metric. Limit <code>1</code> не меняет denominator HPA.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Диагностическая матрица для одного workload</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Возможная причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Pod Unready после релиза</td><td>Probe или gate не выполняет контракт; зависимость ещё не готова</td><td>Сопоставить condition, probe event и смысл Ready</td><td>Исправить owner и recovery path; не увеличивать replicas автоматически</td></tr><tr><td>CPU высокий, HPA не меняет реплики</td><td>Нет CPU request, нет metrics API или выбран другой target type</td><td>Проверить effective request, HPA status и источник метрики</td><td>Сначала восстановить denominator или метрику; не рисовать scale policy по одному графику</td></tr><tr><td>Memory близка к limit</td><td>Рост cache, batch, retained object или неверный limit</td><td>Определить lifetime памяти и проверить runtime evidence</td><td>Ограничить владельца роста; отделить memory action от CPU HPA</td></tr><tr><td>Новые Pod запускаются, но трафик не растёт</td><td>Readiness false, gate не становится True или Service не видит endpoint</td><td>Проверить Pod condition и endpoints разрешённым способом</td><td>Проверить traffic contract; не считать создание Pod доказательством capacity</td></tr><tr><td>Процент выглядит убедительно только в fixture</td><td>Синтетическое число приняли за telemetry</td><td>Проверить источник и marker данных</td><td>Ограничить вывод учебной моделью и запросить реальное evidence отдельно</td></tr></tbody></table></div>\n<h2>Конкретный пример: почему request меняет смысл процента</h2>\n<p>Пусть CPU request равен <code>500m</code>, а HPA target — 70%. В модели controller это означает usage около 350m на Pod для целевой точки. Это 70% request, а не 70% Node и не 70% CPU limit. Если request изменить на <code>1000m</code>, тот же target будет означать другую рабочую точку. Одновременно Scheduler начнёт резервировать больше CPU. Одно изменение затронет placement и interpretation метрики.</p>\n<p>Теперь уберём request. Значение synthetic CPU <code>600m</code> всё ещё выглядит конкретно, но процент больше не имеет объявленного denominator. Корректный verdict — «нельзя интерпретировать utilization», а не «нужно больше Pod». В этом отрицательном пути отсутствие действия HPA — ожидаемый результат проверки контракта. Сначала нужно определить serving unit, для которой request имеет смысл, и подтвердить состояние metrics API в разрешённой среде.</p>\n<p>Другой пример — memory. Если synthetic observation показывает 470Mi при limit 512Mi, это не доказывает OOM, eviction, restart или throttling. Без runtime event это только учебное значение рядом с границей. Следующий вопрос относится к владельцу памяти: cache, batch buffer, response aggregation или connection pool. Readiness false при этом остаётся отдельным сигналом traffic, а не именем причины memory pressure.</p>\n<figure><img src=\"/assets/editorial/2024/container-orchestration-2024-readiness-gate.svg\" alt=\"Схема readiness gate: готовность контейнеров и custom condition вместе формируют Ready и допуск к Service traffic; HPA CPU сравнивает метрику с request отдельно\" loading=\"lazy\" /><figcaption>Учебная схема показывает две границы. Readiness определяет traffic eligibility. HPA использует свою метрику и свой denominator. Asset не описывает состояние реального кластера.</figcaption></figure>\n<h2>Как проверять безопасно</h2>\n<p>Проверка должна отвечать на один вопрос и использовать один тип evidence. Условие Pod, HPA status, metrics API, controlled request и runtime event не взаимозаменяемы. Если источник не разрешён, его отсутствие фиксируют как blocker. Не подменяйте его значением из fixture, screenshot или случайным графиком.</p>\n<ol><li><strong>Ограничьте scope.</strong> Выберите один Deployment, owner, среду, период и разрешённые источники. Не начинайте с массового изменения Pod.</li><li><strong>Снимите декларацию.</strong> Выпишите requests и limits для каждого контейнера. Отдельно зафиксируйте startup, readiness, gates, HPA metric, target и min/max.</li><li><strong>Опишите profile.</strong> Назовите serving unit, startup work, concurrency, dominant resource, dependency policy и точный смысл Ready.</li><li><strong>Проверьте denominator.</strong> Для utilization найдите relevant request и effective values после admission. Если request отсутствует, остановите процентный вывод.</li><li><strong>Разделите сигналы.</strong> Сопоставьте readiness с traffic, metric с replica proposal, limit с runtime boundary, request с placement. Запишите, чего каждый сигнал не доказывает.</li><li><strong>Выберите одну гипотезу.</strong> Назначьте один evidence source, ожидаемый результат и stop condition. Не меняйте request, probe и HPA в одном эксперименте.</li><li><strong>Проверьте отрицательный путь.</strong> Зафиксируйте, что произойдёт при missing request, false gate, stale metric или memory growth. Отсутствие решения иногда и есть корректный результат.</li><li><strong>Закройте изменение.</strong> Сохраните observed result, owner, ограничение и rollback snapshot. Повторите исходный вопрос тем же типом evidence.</li></ol>\n<h2>Что не должна делать учебная fixture</h2>\n<p>Учебный код может держать три фиксированные карточки в памяти: steady serving с request, memory growth с false readiness и warmup без request. Он может проверять, что synthetic value не получила ярлык telemetry и что внешний field отклоняется. Он не должен читать kubeconfig, namespace, файл манифеста, CI, HTTP, trace или production. Комментарий <code>syntheticObservedPodBehavior</code> должен прямо говорить, что это не <code>kubectl</code> и не metrics API.</p>\n<pre><code>const card = {\n  id: 'fixed-warmup-request-missing-v1',\n  declared: { cpuRequest: null, cpuTarget: 65 },\n  observed: {\n    kind: 'embedded-fixed-js-object-not-telemetry',\n    ready: false,\n    cpu: '600m'\n  }\n};\n\nconst verdict = card.declared.cpuRequest === null\n  ? 'block-utilization-conclusion'\n  : 'compare-with-request';\n\nconsole.log(verdict);\n// Учебная модель. Нет cluster, file, CI, HTTP или production data.</code></pre>\n<p>Для этой карточки корректен verdict <code>block-utilization-conclusion</code>. Код не говорит, сколько реплик нужно реальному сервису. Он проверяет только отрицательную ветку: процент без request нельзя честно объяснить. Production-инструмент требует отдельной авторизации, источника данных и правил изменения. Учебный пример эти полномочия не получает.</p>\n<h2>Ограничения и rollback</h2>\n<p>Материал не выбирает размер Node, ratio CPU и memory, значения probes, тип custom metric или безопасный maxReplicas. Он не видит admission webhooks, quotas, EndpointSlice, runtime cgroups, Metrics Server, custom adapter, logs, traces и downstream dependencies. Официальная семантика Kubernetes не заменяет проверку конкретного кластера.</p>\n<p>Rollback должен возвращать snapshot декларации и проверять side effects. Откат HPA не исправляет неверный readiness contract. Возврат limit не объясняет рост памяти. Изменение probe не восстанавливает потерянные evidence. Для каждого изменения укажите owner, условие остановки, временную границу и наблюдаемый критерий отката.</p>\n<p><strong>Критерий готовности.</strong> Изменение готово, если profile назван, у каждого сигнала есть источник и owner, CPU utilization имеет declared request, Ready имеет отдельный traffic contract, synthetic данные не выданы за production, а отрицательная ветка приводит к остановке или явному blocker. Кроме того, команда может повторить исходную проверку тем же типом evidence и получить объяснимый результат. Если хотя бы одна строка отвечает «кажется», манифест не готов.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: Resource Management for Pods and Containers</a> — requests используются при размещении, а request и limit имеют разные роли.</li><li><a href=\"https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: Configure Liveness, Readiness and Startup Probes</a> — Ready зависит от состояния контейнеров и readiness gates; readiness определяет доступность Pod для трафика.</li><li><a href=\"https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: Horizontal Pod Autoscaling</a> — CPU utilization рассчитывается относительно requests, а отсутствие request ограничивает обработку этой метрики.</li></ul>"
+  "title": "Kubernetes без ложных сигналов: как связать rollout, readiness и HPA",
+  "excerpt": "После обновления образа новые Pod могут запускаться, но не получать трафик, а HPA — не менять число реплик. Разбираем четыре разных контура, команды проверки и безопасный критерий готовности.",
+  "contentHtml": "<p>После обновления образа часть Pod остаётся на старой версии, новые Pod долго имеют статус <code>NotReady</code>, а CPU на графике растёт. Первая реакция обычно сводится к увеличению <code>maxReplicas</code> или CPU limit. Но эти поля принадлежат разным контроллерам. Можно добавить реплики и не получить ни одного нового backend в Service, а можно поднять limit и изменить поведение throttling, не исправив причину задержки.</p>\n<p>Цена смешения сигналов — потеря причинной связи. Deployment может продолжать rollout, пока новая ReplicaSet не набирает доступные Pod. Readiness probe может исключить Pod из Service, хотя процесс жив. HPA может не рассчитать CPU utilization из-за отсутствующего request или недоступного metrics API. Сначала назовём владельца каждого сигнала, затем проверим ровно тот контур, который породил симптом.</p>\n<p><strong>Главный принцип.</strong> <code>Ready</code> означает допуск к трафику, а не доказанную производительность. CPU utilization в HPA — отношение потребления к объявленному request, а не процент CPU Node и не процент limit. Rolling update отвечает за замену ReplicaSet, но не исправляет плохую readiness-проверку.</p>\n<h2>Четыре контура одной рабочей нагрузки</h2>\n<p><strong>Deployment и ReplicaSet.</strong> Deployment хранит желаемый шаблон Pod и управляет ReplicaSet. При стратегии <code>RollingUpdate</code> новая ReplicaSet создаёт Pod, а старая постепенно уменьшается. Поля <code>maxSurge</code> и <code>maxUnavailable</code> ограничивают число дополнительных и недоступных Pod. Поэтому во время rollout нормально временно видеть старую и новую версии одновременно. Ненормально — считать сам факт создания нового Pod доказательством его готовности.</p>\n<p><strong>Readiness.</strong> Kubelet выполняет readiness probe на протяжении жизни контейнера. Если она не проходит, Pod получает состояние unready и Kubernetes Services не должны отправлять ему трафик. Такая probe отвечает только на вопрос «можно ли обслуживать запросы сейчас». Она не обязана доказывать отсутствие утечки памяти, правильность миграции или запас CPU. Для долгого старта применяют <code>startupProbe</code>, чтобы не превращать штатную инициализацию в перезапуски.</p>\n<p><strong>Service и EndpointSlice.</strong> Service выбирает Pod по label selector, а control plane формирует связанные EndpointSlice. В EndpointSlice условие <code>ready</code> отражает готовность endpoint; это полезная проверка фактического набора backend, а не только списка Pod. Сетевой mesh, балансировщик и настройка <code>publishNotReadyAddresses</code> могут добавить собственное поведение, поэтому команда должна проверить реальный путь трафика. Для обычного Service нельзя переносить вывод «Pod Running» на «Pod получает запросы».</p>\n<p><strong>Ресурсы и HPA.</strong> Scheduler использует requests контейнеров для выбора Node. Limits задают границу выполнения: CPU ограничивается throttling, а превышение memory limit может привести к OOM kill. HPA с ресурсной метрикой <code>averageUtilization</code> сравнивает usage с request. Если у релевантного контейнера нет request, utilization для этой метрики не определён, и HPA не обязан масштабировать по ней.</p>\n<figure><img src='/assets/editorial/2024/container-orchestration-2024-readiness-gate.svg' alt='Схема связи readiness probe и custom readiness gate: только совместное состояние формирует Ready и допуск к Service traffic, тогда как HPA CPU считает usage относительно request отдельно' loading='lazy' /><figcaption>Схема показывает границу между traffic eligibility и autoscaling. Подпись <code>synthetic.example/contract</code> на рисунке — условное имя custom condition; рисунок не представляет состояние конкретного кластера.</figcaption></figure>\n<h2>Почему старый Pod может оставаться в системе</h2>\n<p>Рассмотрим последовательность без привязки к конкретному облаку. У Deployment две реплики, стратегия — <code>RollingUpdate</code>. После смены образа контроллер создаёт новую ReplicaSet. Новый контейнер запускается, но readiness endpoint отвечает ошибкой, потому что приложение ещё загружает конфигурацию. Pod остаётся живым, однако Service не получает его в качестве готового endpoint. Старый Pod продолжает обслуживать запросы, пока контроллер не может безопасно уменьшить старую ReplicaSet.</p>\n<p>В такой ситуации фраза «релиз завис» слишком общая. Нужно разделить пять наблюдений: какой image digest реально запущен; какую condition получил новый Pod; что написано в событиях probe; какие endpoints видит Service; какое решение показывает Deployment controller. Одного вывода <code>kubectl get pods</code> недостаточно.</p>\n<div class='table-scroll'><table><caption>Симптом, источник доказательства и допустимое действие</caption><thead><tr><th scope='col'>Симптом</th><th scope='col'>Что могло произойти</th><th scope='col'>Чем проверить</th><th scope='col'>Что делать первым</th></tr></thead><tbody><tr><td>Новые Pod <code>Running</code>, но <code>READY 0/1</code></td><td>Readiness probe не проходит или custom gate остаётся false</td><td><code>kubectl describe pod</code>, conditions и Events</td><td>Проверить контракт endpoint/gate и зависимость; не увеличивать replicas вслепую</td></tr><tr><td>Старая ReplicaSet не уменьшается</td><td>Новая версия не набрала доступные Pod или достигнут лимит rollout</td><td><code>kubectl rollout status</code>, Deployment conditions, ReplicaSets</td><td>Сопоставить <code>maxUnavailable</code> с доступными Pod и найти причину Unready</td></tr><tr><td>CPU высок, HPA не меняет replicas</td><td>Нет request, нет resource metrics или выбран другой target type</td><td><code>kubectl describe hpa</code>, HPA conditions, metrics API</td><td>Восстановить источник и знаменатель; не считать отсутствующий scale доказательством низкой нагрузки</td></tr><tr><td>Pod <code>Ready</code>, но запросов нет</td><td>Selector/port не совпадает, EndpointSlice устарел или трафик идёт через другой слой</td><td>Service selector, EndpointSlice и путь data plane</td><td>Сверить label, порт и фактический backend; не менять probe без этого сравнения</td></tr><tr><td>Memory близка к limit</td><td>Растёт cache, buffer, retained object или слишком тесен лимит</td><td>Runtime metrics, restart reason, events и профиль приложения</td><td>Отделить memory investigation от CPU HPA и назвать владельца роста</td></tr></tbody></table></div>\n<h2>Минимальный манифест для проверки контракта</h2>\n<p>Ниже — учебный фрагмент. Он намеренно содержит requests, limits, startup/readiness probes, custom readiness gate и HPA. Образ, путь endpoint, имя condition и числа ресурсов нужно заменить на значения конкретного приложения. Custom readiness gate не станет <code>True</code> сам по себе: внешний контроллер или другой владелец состояния должен установить condition, иначе Pod останется неготовым.</p>\n<pre><code>apiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: api\nspec:\n  # Если Deployment управляется HPA, не дублируйте replicas\n  # в постоянно применяемом manifest без отдельной политики.\n  replicas: 2\n  strategy:\n    type: RollingUpdate\n    rollingUpdate:\n      maxSurge: 1\n      maxUnavailable: 0\n  selector:\n    matchLabels:\n      app: api\n  template:\n    metadata:\n      labels:\n        app: api\n    spec:\n      readinessGates:\n        - conditionType: synthetic.example/contract\n      containers:\n        - name: api\n          image: registry.example/api:v3.4.1\n          ports:\n            - name: http\n              containerPort: 8080\n          resources:\n            requests:\n              cpu: 500m\n              memory: 256Mi\n            limits:\n              cpu: '1'\n              memory: 512Mi\n          startupProbe:\n            httpGet:\n              path: /startup\n              port: http\n            periodSeconds: 5\n            failureThreshold: 24\n          readinessProbe:\n            httpGet:\n              path: /ready\n              port: http\n            periodSeconds: 5\n            failureThreshold: 2\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: api\nspec:\n  selector:\n    app: api\n  ports:\n    - name: http\n      port: 80\n      targetPort: http\n---\napiVersion: autoscaling/v2\nkind: HorizontalPodAutoscaler\nmetadata:\n  name: api\nspec:\n  scaleTargetRef:\n    apiVersion: apps/v1\n    kind: Deployment\n    name: api\n  minReplicas: 2\n  maxReplicas: 10\n  metrics:\n    - type: Resource\n      resource:\n        name: cpu\n        target:\n          type: Utilization\n          averageUtilization: 70</code></pre>\n<p>В этом примере CPU target равен 70% от request, то есть 350m на Pod при request 500m. Это рабочая точка алгоритма, а не обещание, что сервис выдержит нужную нагрузку. <code>maxUnavailable: 0</code> увеличивает потребность в свободной ёмкости: новая версия должна стать доступной до удаления старой. На маленьком кластере rollout может остановиться из-за нехватки ресурсов, даже если probe исправна.</p>\n<h2>Воспроизводимая проверка в разрешённом кластере</h2>\n<p>Команды ниже только читают состояние и подходят для namespace, к которому у вас есть доступ. Сначала запишите имя Deployment, namespace и новый image digest. Затем повторяйте команды с тем же объектом; так временная картина не смешивается с другой нагрузкой.</p>\n<pre><code>NS=demo\nDEPLOY=api\n\nkubectl -n \\\"$NS\\\" get deployment \\\"$DEPLOY\\\" -o wide\nkubectl -n \\\"$NS\\\" rollout status deployment/\\\"$DEPLOY\\\" --timeout=120s\nkubectl -n \\\"$NS\\\" get rs,pods -l app=api \\\n  -o custom-columns='KIND:kind,NAME:metadata.name,IMAGE:spec.template.spec.containers[0].image,READY:status.containerStatuses[0].ready'\nkubectl -n \\\"$NS\\\" describe deployment \\\"$DEPLOY\\\"\nkubectl -n \\\"$NS\\\" describe pod -l app=api\nkubectl -n \\\"$NS\\\" get endpointslice \\\n  -l kubernetes.io/service-name=api -o yaml\nkubectl -n \\\"$NS\\\" describe hpa \\\"$DEPLOY\\\"\nkubectl -n \\\"$NS\\\" top pod -l app=api</code></pre>\n<p>Команда <code>rollout status</code> сообщает, завершился ли rollout, но не объясняет каждую причину. <code>describe pod</code> даёт condition и Events, однако не заменяет логи приложения. <code>get endpointslice</code> показывает объект control plane; если между Service и клиентом есть mesh или внешний балансировщик, его состояние нужно проверять отдельно. <code>top</code> требует работающего resource metrics API и показывает текущий срез, а не историю.</p>\n<p>Для безопасного чтения образа сравните digest, а не только короткий tag. Для проверки именно нового ReplicaSet выберите его label из вывода Deployment и повторите <code>describe pod</code> по этому selector. Если в cluster policy запрещён доступ к EndpointSlice или metrics API, это не повод подставлять число из fixture: результат проверки должен быть «источник недоступен».</p>\n<h2>Разбираем HPA без иллюзии о процентах</h2>\n<p>При <code>requests.cpu: 500m</code> и среднем потреблении 350m utilization равен 70%. При том же потреблении, но request 1000m, utilization равен 35%. CPU workload не изменился, а решение HPA стало другим. Одновременно Scheduler увидит другой reservation contract. Поэтому изменение request нельзя считать только настройкой autoscaling: оно меняет и размещение, и интерпретацию процента.</p>\n<p>Limit — другой знаменатель и другая граница. Если limit равен 1 CPU, контейнер может упереться в throttling на этой границе; HPA с <code>averageUtilization</code> всё равно сравнивает usage с request. Если memory приближается к 512Mi, это не объясняет само по себе высокий CPU и не доказывает OOM. Для memory нужно проверить restart reason, события и профиль приложения.</p>\n<p>Есть ещё одна конфликтующая настройка. Kubernetes предупреждает: когда HPA активен, применение Deployment manifest с фиксированным <code>spec.replicas</code> может снова записать число реплик и вызвать колебания. Перед тем как удалить <code>replicas</code> из manifest, проверьте способ применения и разовый эффект: API по умолчанию может трактовать отсутствие поля как одну реплику. Это изменение нужно выполнять отдельным контролируемым шагом, а не попутно с исправлением probe.</p>\n<h2>Порядок изменения и отрицательные пути</h2>\n<ol><li><strong>Зафиксируйте объект.</strong> Запишите namespace, Deployment, image digest, label selector, Service, период наблюдения и владельца изменения.</li><li><strong>Снимите декларацию.</strong> Сохраните requests/limits каждого контейнера, probes, gates, стратегию rollout, HPA metric, target, min/max и способ применения manifest.</li><li><strong>Проверьте новую версию.</strong> Убедитесь, что Pod действительно использует ожидаемый digest. Сопоставьте его condition, Events и логи с readiness-контрактом.</li><li><strong>Проверьте путь трафика.</strong> Сверьте Service selector, port/targetPort и EndpointSlice. При наличии mesh или внешнего балансировщика добавьте его собственный источник.</li><li><strong>Проверьте rollout.</strong> Сравните доступные и желаемые Pod, maxSurge/maxUnavailable, условия Deployment и время остановки. Не меняйте сразу стратегию и probe.</li><li><strong>Проверьте HPA.</strong> Убедитесь, что metrics API отвечает, request присутствует у релевантных контейнеров, target type соответствует задаче, а status содержит текущую метрику и conditions.</li><li><strong>Выберите одну гипотезу.</strong> На один эксперимент меняйте один контракт: endpoint readiness, request, limit, rollout policy или metric. Заранее задайте ожидаемое наблюдение и stop condition.</li><li><strong>Проверьте отрицательный путь.</strong> Зафиксируйте поведение при false readiness, missing request, недоступной метрике, несовпадающем selector и нехватке Node capacity. Если источник неизвестен, остановите вывод.</li><li><strong>Закройте результат.</strong> Сравните исходный симптом теми же командами, сохраните observed result, owner и rollback snapshot. Не объявляйте rollout готовым по одному зелёному статусу.</li></ol>\n<h2>Ограничения применимости и откат</h2>\n<p>Этот разбор не выбирает универсальные значения CPU, memory, probe timeout, maxReplicas или maxUnavailable. Их определяют профиль приложения, SLA, стоимость Node, размер ответа, время старта и downstream-зависимости. Статус <code>Ready</code> не проверяет бизнес-корректность ответа. HPA не заменяет очередь, rate limit, вертикальное масштабирование или capacity planning. Resource metrics не дают трассировку причины задержки.</p>\n<p>Манифест не учитывает admission webhook, LimitRange, ResourceQuota, PodDisruptionBudget, topology spread, NetworkPolicy и правила конкретного service mesh. Эти механизмы могут изменить effective configuration или доступность. <code>publishNotReadyAddresses: true</code> меняет обычную семантику готовых endpoints, поэтому вывод о трафике нужно сверять с фактическим Service contract.</p>\n<p>Откат делайте после сохранения ревизии и проверки зависимости. Для Deployment можно посмотреть историю и вернуть предыдущую ревизию командами ниже. Откат не исправляет неверный readiness endpoint и не освобождает уже занятый Node; после него снова проверьте conditions, endpoints и rollout status.</p>\n<pre><code>kubectl -n demo rollout history deployment/api\nkubectl -n demo rollout undo deployment/api --to-revision=3\nkubectl -n demo rollout status deployment/api --timeout=120s</code></pre>\n<p><strong>Критерий готовности.</strong> Изменение готово, если известны image digest и владелец состояния, новый Pod проходит startup/readiness по смыслу приложения, Service видит ожидаемые endpoints, rollout достигает доступного состояния, а HPA получает метрику с объявленным request или явно использует другой документированный target type. Для каждого отрицательного пути есть наблюдаемое действие: остановка, откат или передача конкретному владельцу. Если команда видит только <code>Running</code>, но не может показать condition, endpoint и источник метрики, причина ещё не доказана.</p>\n<h2>Проверяемые источники</h2><ul><li><a href='https://kubernetes.io/docs/tasks/run-application/update-deployment-rolling/' target='_blank' rel='noopener noreferrer'>Kubernetes: Update a Deployment Without Downtime</a> — описывает RollingUpdate, <code>maxSurge</code>, <code>maxUnavailable</code>, stalled rollout и rollback.</li><li><a href='https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/' target='_blank' rel='noopener noreferrer'>Kubernetes: Configure Liveness, Readiness and Startup Probes</a> — фиксирует поведение readiness для Service traffic и роль startup probe.</li><li><a href='https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/' target='_blank' rel='noopener noreferrer'>Kubernetes: EndpointSlices</a> — описывает условия <code>ready</code>, <code>serving</code>, <code>terminating</code> и роль EndpointSlice в маршрутизации.</li><li><a href='https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/' target='_blank' rel='noopener noreferrer'>Kubernetes: Resource Management for Pods and Containers</a> — объясняет requests, limits, scheduling, CPU throttling и memory limit.</li><li><a href='https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/' target='_blank' rel='noopener noreferrer'>Kubernetes: Horizontal Pod Autoscaling</a> — определяет utilization относительно request, отсутствие действия при missing request и конфликт фиксированного <code>spec.replicas</code> с HPA.</li></ul>"
 }
diff --git a/editorial/agent-rewrites/128.json b/editorial/agent-rewrites/128.json
index dac0ff4..f770001 100644
--- a/editorial/agent-rewrites/128.json
+++ b/editorial/agent-rewrites/128.json
@@ -3,5 +3,5 @@
   "slug": "editorial-2024-06-mechanism-container-orchestration",
   "title": "Контейнерная нагрузка без догадок: как связать requests, readiness и HPA",
   "excerpt": "После обновления образа Pod может стать Unready, а HPA — не изменить число реплик. Разбираем, какой механизм отвечает за placement, traffic и масштабирование, как проверить гипотезу и когда изменение манифеста действительно готово.",
-  "contentHtml": "<p>После обновления образа часть Pod долго остаётся на старой версии. Другие Pod переходят в <code>Ready</code>, но сразу теряют готовность. В ответ команда увеличивает <code>maxReplicas</code>, поднимает CPU limit и запускает rollout ещё раз. Симптомы меняются, а причина остаётся. Цена ошибки — лишние реплики, неуправляемая нагрузка на Node и более длинный путь отката. В худшем случае Service получает Pod, который ещё не готов обслуживать запросы.</p>\n<p>Тезис простой: Kubernetes не управляет контейнерной нагрузкой одной ручкой. Scheduler учитывает requests. Runtime ограничивает container по limits. Readiness решает, можно ли отправлять Pod трафик. HPA предлагает число реплик по своей метрике. Эти контуры связаны, но не заменяют друг друга. Пока у каждого значения нет явного смысла, процент CPU и статус <code>Ready</code> легко принять за доказательство capacity.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Четыре частых подмены в разборе контейнерной нагрузки</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>HPA показывает процент, но реплики не растут</td><td>У container нет CPU request или метрика не имеет нужного знаменателя</td><td>Проверить request каждого container, тип metric и источник metrics API</td><td>Сначала исправить контракт метрики; не увеличивать replicas вслепую</td></tr><tr><td>Pod Unready после старта</td><td>Readiness проверяет недоступную зависимость, либо probe срабатывает раньше прогрева</td><td>Сопоставить probe, startup path, condition и Service endpoints</td><td>Изменить семантику readiness или порядок старта, затем повторить проверку</td></tr><tr><td>Pod Pending после изменения ресурсов</td><td>Сумма requests не помещается на доступные Node</td><td>Сравнить requests с allocatable, quota и правилами admission</td><td>Пересмотреть профиль workload или размещение</td></tr><tr><td>CPU limit увеличен, но задержка не исчезла</td><td>Причина находится в памяти, очереди или внешней зависимости</td><td>Разделить CPU, memory, queue, latency и dependency signals</td><td>Проверять один доминирующий ресурс, а не менять все поля сразу</td></tr></tbody></table></div>\n<h2>Как работают четыре контура</h2>\n<p><strong>Requests отвечают за размещение.</strong> Scheduler использует CPU и memory requests при выборе Node. Для Pod учитывается сумма requests контейнеров. Request не обещает постоянное потребление и не задаёт верхнюю границу. Это объявленная потребность, по которой система решает, может ли Pod быть размещён.</p>\n<p><strong>Limits задают границу ресурса.</strong> CPU и memory limit принадлежат container. Они не являются целью HPA. Memory limit не описывает безопасный размер cache, а CPU limit не обещает throughput. При изменении limit нужно знать, какое поведение ожидается после достижения границы: ограничение CPU, ошибка выделения памяти или другой runtime effect. Без этого число в YAML не объясняет проблему.</p>\n<p><strong>Readiness управляет допуском к трафику.</strong> Когда readiness probe возвращает failure, Kubernetes не считает Pod готовым backend для Service. Это полезный сигнал маршрутизации. Он не говорит, почему приложение не готово, насколько высока latency и хватит ли ему CPU при пике. Probe должна проверять короткий факт, которым владеет приложение или его платформа. Проверка десятка внешних зависимостей превращает краткий сбой одной зависимости в удаление Pod из трафика.</p>\n<p><strong>HPA предлагает desired replicas.</strong> Для CPU utilization процент рассчитывается относительно CPU request целевых Pod. Поэтому target в 70 процентов — не 70 процентов Node и не 70 процентов limit. При request 500m такой target имеет другой смысл, чем при request 1000m. Изменение request одновременно влияет на placement и на интерпретацию HPA. Это одна причина, чтобы менять оба решения в одной проверяемой гипотезе.</p>\n<figure><img src=\"/assets/editorial/2024/container-orchestration-2024-capacity-curve.svg\" alt=\"Учебная кривая связывает CPU utilization с declared request и отделяет target HPA от CPU limit\" loading=\"lazy\" /><figcaption>Кривая показывает отношения между величинами, а не состояние конкретного кластера. Target HPA имеет знаменателем request; limit — отдельная граница container.</figcaption></figure>\n<h2>Конкретный пример</h2>\n<p>Пусть приложение обслуживает HTTP-запросы. Для одного container объявлены <code>cpu request: 500m</code> и <code>cpu limit: 1000m</code>. HPA использует <code>targetAverageUtilization: 70</code>. В учебном примере значение 70 процентов относится к 500m request. Условная точка сравнения равна 350m usage на Pod. Это арифметика для объяснения знаменателя, а не наблюдение из кластера и не рекомендация для реального сервиса.</p>\n<pre><code>apiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: orders\nspec:\n  replicas: 2\n  template:\n    spec:\n      containers:\n        - name: app\n          image: registry.example/orders:sha256-example\n          resources:\n            requests:\n              cpu: 500m\n              memory: 384Mi\n            limits:\n              cpu: 1000m\n              memory: 768Mi\n          readinessProbe:\n            httpGet:\n              path: /ready\n              port: 8080\n            periodSeconds: 5\n---\napiVersion: autoscaling/v2\nkind: HorizontalPodAutoscaler\nmetadata:\n  name: orders\nspec:\n  scaleTargetRef:\n    apiVersion: apps/v1\n    kind: Deployment\n    name: orders\n  minReplicas: 2\n  maxReplicas: 8\n  metrics:\n    - type: Resource\n      resource:\n        name: cpu\n        target:\n          type: Utilization\n          averageUtilization: 70</code></pre>\n<p>Этот фрагмент показывает форму контракта. Он не доказывает, что 500m достаточно, что endpoint отвечает быстро или что HPA получит метрики. В реальной системе нужно отдельно проверить effective manifest после admission, состояние metrics API, readiness transitions и фактический workload. Если CPU request убрать, процентный target теряет ожидаемый знаменатель. Если readiness отвечает <code>200</code> до завершения прогрева, Service направит трафик слишком рано. Если readiness зависит от внешней базы, краткий сбой базы может убрать все backend.</p>\n<h2>Отрицательный путь: почему масштабирование не лечит готовность</h2>\n<p>Рассмотрим запуск новой версии. Приложение мигрирует локальный cache 20 секунд, но readiness endpoint начинает отвечать успехом через две секунды. HPA видит CPU прогрева и предлагает больше реплик. Новые Pod повторяют тот же тяжёлый startup. Число реплик растёт, а полезная ёмкость не появляется. Это не доказательство, что HPA сломан. Сначала нужно отделить startup work от serving work.</p>\n<p>Обратная ошибка тоже опасна. Readiness проверяет внешний сервис, который не нужен каждому запросу. При коротком отказе зависимости все Pod становятся Unready, хотя основная функция могла бы продолжать работу. Увеличение replicas не помогает: новые Pod проходят ту же проверку и исключаются из Service. Действие находится в контракте readiness и failure policy, а не в capacity curve.</p>\n<h2>Упорядоченный маршрут проверки</h2>\n<ol><li><strong>Ограничьте workload.</strong> Назовите Deployment, owner, serving path, startup path, единицу работы и период наблюдения. Не смешивайте два сервиса в одну гипотезу.</li><li><strong>Зафиксируйте декларацию.</strong> Выпишите requests и limits каждого container, probe, startup settings, HPA metric, minReplicas и maxReplicas. Отделите написанное в manifest от effective values после admission.</li><li><strong>Назовите смысл Ready.</strong> Запишите короткое условие, после которого Pod действительно может принимать Service traffic. Отдельно запишите, что readiness не доказывает: например, throughput, latency или здоровье всех зависимостей.</li><li><strong>Проверьте знаменатель метрики.</strong> Для CPU utilization свяжите target с CPU request. Для raw, custom и external metrics укажите target type, selector и источник. При missing data остановите вывод, а не подставляйте число.</li><li><strong>Соберите одно evidence.</strong> Выберите разрешённый condition, metric или controlled test. У evidence должны быть источник, время, workload и ограничение интерпретации. Учебные значения не заменяют этот шаг.</li><li><strong>Измените одну гипотезу.</strong> Выберите request, limit, probe или HPA policy. Запишите ожидаемый сигнал, stop condition и rollback. Не меняйте четыре контура одним commit.</li><li><strong>Повторите ту же проверку.</strong> Сравните результат с первоначальной гипотезой. Если изменился тип evidence или workload, результат нельзя считать подтверждением.</li></ol>\n<h2>Ограничения</h2>\n<p>Эта модель не выбирает универсальные значения CPU и memory. Она не учитывает автоматически admission webhooks, ResourceQuota, PodDisruptionBudget, Node allocatable, runtime, Metrics Server, custom adapter, queueing, cache retention и downstream saturation. Официальная документация описывает общий механизм Kubernetes, но не сообщает конфигурацию конкретного кластера. Нельзя переносить учебную арифметику в production profile без измерения.</p>\n<p>Readiness не заменяет liveness и startup probes. HPA не устраняет утечку памяти и не гарантирует доступность внешней зависимости. Limit не превращается в SLO. Если причина не разделяется одним evidence, правильное действие — остановить изменение и уточнить контракт. Это отрицательный результат, но он дешевле массового rollout без объяснимого эффекта.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Изменение готово, когда для одного workload выполнены все условия: владелец назван; effective requests и limits зафиксированы по container; смысл readiness записан одной фразой; HPA metric имеет объявленный знаменатель и источник; выбранное evidence получено в указанном периоде; ожидаемый эффект измерим; stop condition и rollback проверяемы. Если после изменения команда всё ещё говорит только «Pod стал лучше» или «процент выглядит нормально», контракт не закрыт.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: Resource Management for Pods and Containers</a> — роли requests и limits при размещении и ограничении ресурсов.</li><li><a href=\"https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: Horizontal Pod Autoscaling</a> — расчёт resource utilization относительно request и условия работы HPA.</li><li><a href=\"https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: Pod Lifecycle and probes</a> — смысл readiness и её влияние на допуск Pod к Service traffic.</li></ul>"
+  "contentHtml": "<p>После обновления образа часть Pod может долго оставаться на старой версии, а новая версия — перейти в <code>Unready</code>. Команда увеличивает <code>maxReplicas</code>, поднимает CPU limit и запускает rollout повторно. Симптомы меняются, но причина не становится яснее. Цена такой подмены — лишние реплики, перегруженные Node и откат, который трудно объяснить.</p>\n<p>У Kubernetes здесь не одна «ручка нагрузки», а несколько независимых контуров. Scheduler размещает Pod по requests. Runtime применяет limits. Readiness определяет, можно ли отправлять Pod трафик Service. HPA рассчитывает желаемое число реплик по выбранной метрике. Эти контуры встречаются в одном манифесте, но не доказывают друг друга.</p>\n<h2>Сначала разделите симптом и механизм</h2>\n<div class=\"table-scroll\"><table><caption>Диагностическая матрица для четырёх похожих симптомов</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Вероятный контур</th><th scope=\"col\">Проверка</th><th scope=\"col\">Следующее действие</th></tr></thead><tbody><tr><td>HPA показывает <code>&lt;unknown&gt;</code> или не меняет реплики</td><td>Метрика недоступна либо для Pod нет нужного resource request</td><td>Проверить HPA conditions, <code>metrics.k8s.io</code> и request каждого container</td><td>Восстановить контракт метрики; не поднимать <code>maxReplicas</code> вслепую</td></tr><tr><td>Pod запущен, но <code>Unready</code></td><td>Readiness не проходит или приложение ещё прогревается</td><td>Сопоставить probe, Pod conditions, события и endpoint</td><td>Исправить условие готовности или добавить startup-защиту</td></tr><tr><td>Pod остаётся <code>Pending</code></td><td>Сумма requests не помещается на доступные Node</td><td>Сравнить requests с allocatable, quota и admission-правилами</td><td>Пересмотреть профиль ресурсов или размещение</td></tr><tr><td>CPU limit увеличили, но задержка не исчезла</td><td>Доминирует память, очередь или внешняя зависимость</td><td>Разделить CPU, memory, latency, queue и dependency signals</td><td>Изменить один подтверждённый фактор и повторить замер</td></tr></tbody></table></div>\n<h2>Четыре контура и их границы</h2>\n<p><strong>Request отвечает за планирование.</strong> Scheduler учитывает requests контейнеров при выборе Node. Для одного ресурса Pod получает сумму requests своих контейнеров. Поэтому изменение request может перевести Pod из «размещается» в «не помещается», даже если текущее потребление на Node пока невелико. Request — заявленная потребность для планирования, а не обещание постоянной скорости.</p>\n<p><strong>Limit задаёт потолок контейнера.</strong> CPU limit может ограничивать долю CPU-времени, а превышение memory limit может привести к срабатыванию механизма out-of-memory. Limit не сообщает, сколько запросов выдержит приложение, и не является автоматически целью HPA. Между «контейнер не превысил лимит» и «у сервиса есть запас по latency» нет логического равенства.</p>\n<p><strong>Readiness управляет маршрутизацией.</strong> При неуспешной readiness probe Kubernetes помечает контейнер неготовым, а адрес Pod перестаёт быть готовым endpoint для соответствующих Service. Это сигнал «можно ли принимать этот трафик сейчас», а не проверка всех зависимостей системы. Если endpoint опрашивает необязательную базу или внешний API, краткий сбой этой зависимости может убрать из трафика исправное приложение.</p>\n<p><strong>HPA меняет желаемое число реплик.</strong> Для resource metric с <code>averageUtilization</code> процент считается относительно соответствующего request. Target 70 процентов — это 70 процентов request, не Node и не limit. Для CPU request 500m учебная точка 70 процентов равна 350m на Pod. Это объяснение знаменателя, а не рекомендация профиля.</p>\n<figure><img src=\"/assets/editorial/2024/container-orchestration-2024-capacity-curve.svg\" alt=\"Учебная диаграмма показывает CPU usage как процент request, target HPA 70 процентов и отдельный CPU limit\" loading=\"lazy\" /><figcaption>Схема разделяет target HPA и CPU limit. Точки синтетические: они объясняют арифметику и не являются telemetry или прогнозом capacity конкретного кластера.</figcaption></figure>\n<h2>Контролируемая замена версии</h2>\n<p>Deployment отвечает ещё за один отдельный вопрос: как заменить Pod старой версии на Pod новой. При RollingUpdate параметры <code>maxUnavailable</code> и <code>maxSurge</code> ограничивают число временно недоступных и дополнительных Pod. Readiness влияет на то, когда новая реплика считается пригодной для трафика, но сама по себе не гарантирует, что rollout завершится: новый образ может не стартовать, не пройти probe или не поместиться по requests.</p>\n<p>Поэтому «новые Pod появились» и «новая версия обслуживает нагрузку» — разные проверки. Для отката нужно заранее знать имя Deployment, границу времени и состояние, которое считается безопасным. Команда <code>kubectl rollout status</code> подтверждает наблюдаемое состояние rollout, но не заменяет проверку ошибок приложения и latency.</p>\n<h2>Полный учебный манифест</h2>\n<p>Ниже один минимальный пример для HTTP-сервиса. В нём добавлены обязательные для Deployment selector и labels, startup probe для долгого старта и readiness probe для допуска к трафику. Значения ресурсов, пути и образ проектные: их нельзя переносить в production без измерения.</p>\n<pre><code>apiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: orders\nspec:\n  replicas: 2\n  strategy:\n    type: RollingUpdate\n    rollingUpdate:\n      maxUnavailable: 0\n      maxSurge: 1\n  selector:\n    matchLabels:\n      app: orders\n  template:\n    metadata:\n      labels:\n        app: orders\n    spec:\n      containers:\n        - name: app\n          image: registry.example/orders:2024-06-01\n          ports:\n            - name: http\n              containerPort: 8080\n          resources:\n            requests:\n              cpu: 500m\n              memory: 384Mi\n            limits:\n              cpu: 1000m\n              memory: 768Mi\n          startupProbe:\n            httpGet:\n              path: /healthz\n              port: http\n            periodSeconds: 10\n            failureThreshold: 30\n          readinessProbe:\n            httpGet:\n              path: /ready\n              port: http\n            periodSeconds: 5\n            failureThreshold: 3\n---\napiVersion: autoscaling/v2\nkind: HorizontalPodAutoscaler\nmetadata:\n  name: orders\nspec:\n  scaleTargetRef:\n    apiVersion: apps/v1\n    kind: Deployment\n    name: orders\n  minReplicas: 2\n  maxReplicas: 8\n  metrics:\n    - type: Resource\n      resource:\n        name: cpu\n        target:\n          type: Utilization\n          averageUtilization: 70</code></pre>\n<p>При таком request target 70 процентов означает условные 350m среднего CPU на Pod. Но манифест не доказывает, что 500m достаточно, endpoint действительно отделяет startup от serving, а metrics API доступен. Если у контейнера, который участвует в CPU utilization, нет CPU request, HPA не сможет определить эту utilization для метрики. Это повод проверить конфигурацию и condition HPA, а не подставить процент вручную.</p>\n<h2>Команды для воспроизводимой проверки</h2>\n<p>Эти команды предполагают доступ к namespace и установленный <code>kubectl</code>. Первая команда проверяет манифест сервером без изменения объекта; остальные читают состояние или запускают обычный rollout после явного применения. В тестовом кластере замените namespace и имя образа на свои.</p>\n<pre><code>kubectl apply --dry-run=server -f deployment.yaml\nkubectl apply -f deployment.yaml\nkubectl rollout status deployment/orders --timeout=10m\nkubectl get deployment/orders\nkubectl get pods -l app=orders -o wide\nkubectl describe deployment/orders\nkubectl describe pod -l app=orders\nkubectl get hpa orders\nkubectl top pods -l app=orders</code></pre>\n<p>Ожидаемый результат нужно формулировать заранее: например, rollout завершается за 10 минут, две минимальные реплики находятся в состоянии Ready, а HPA получает числовую CPU-метрику. Если <code>kubectl top</code> или HPA показывают отсутствие метрик, это ограничение наблюдаемости. Оно не подтверждает ни низкую нагрузку, ни исправность autoscaling. Для остановившегося rollout дополнительно смотрите Events и condition Deployment; для <code>Pending</code> — причины планировщика и effective requests.</p>\n<h2>Почему HPA не лечит неготовность</h2>\n<p>Представим новую версию, которая прогревает локальный cache 20 секунд. Readiness endpoint начинает отвечать через две секунды, а CPU во время старта высок. Если metrics API отдаёт данные и контроллер учитывает их, HPA может принять решение о масштабировании, но новые Pod повторят тот же startup. Реплик станет больше, а serving capacity не обязательно вырастет. Это не доказательство неисправности HPA: сначала нужно отделить startup work от serving work.</p>\n<p>Обратная ошибка симметрична. Readiness проверяет внешний сервис, который нужен только части запросов. При кратком отказе все Pod становятся Unready, хотя основной маршрут ещё может работать. Дополнительные реплики проходят ту же проверку и тоже исключаются из Service. Действие находится в контракте readiness и политике деградации, а не в увеличении <code>maxReplicas</code>.</p>\n<h2>Порядок расследования</h2>\n<ol><li><strong>Ограничьте объект.</strong> Запишите namespace, Deployment, owner, serving path, startup path, единицу работы и окно наблюдения. Один вывод — один workload.</li><li><strong>Снимите effective-конфигурацию.</strong> Зафиксируйте requests и limits каждого container, probes, selector, rollout strategy и HPA metric. Отделяйте YAML в репозитории от объекта после admission.</li><li><strong>Сформулируйте смысл Ready.</strong> Одной фразой опишите, после какого условия Pod может принимать Service traffic. Отдельно перечислите, чего Ready не доказывает: throughput, latency и здоровье необязательных зависимостей.</li><li><strong>Проверьте источник метрики.</strong> Для CPU utilization свяжите target с request и проверьте resource metrics API. Для custom или external metric укажите target type, selector и владельца pipeline. При отсутствии данных остановите вывод.</li><li><strong>Соберите одно evidence.</strong> Выберите condition, метрику или контролируемый тест. Сохраните источник, время, workload и ограничение интерпретации. Учебный манифест не заменяет наблюдение.</li><li><strong>Измените одну гипотезу.</strong> Выберите request, limit, probe, rollout policy или HPA policy. Запишите ожидаемый сигнал, stop condition и команду отката.</li><li><strong>Повторите ту же проверку.</strong> Сравните одинаковое окно, workload и тип evidence. Если изменились сразу несколько контуров, эффект нельзя приписать одному решению.</li></ol>\n<h2>Ограничения применимости</h2>\n<p>Эта модель не выбирает универсальные CPU и memory values. На результат влияют admission webhooks, ResourceQuota, PodDisruptionBudget, Node allocatable, планировщик, runtime, Metrics Server, custom adapter, очередь, cache и downstream saturation. Официальная документация описывает механизм Kubernetes, но не конфигурацию вашего кластера.</p>\n<p>Readiness не заменяет liveness и startup probes. HPA не устраняет утечку памяти и не гарантирует доступность внешней зависимости. CPU utilization не равен throughput, а отсутствие роста реплик не всегда означает ошибку autoscaling: контроллер может упереться в min/max, не получить метрику или увидеть, что целевой workload уже соответствует target. Учебную арифметику нельзя объявлять production-результатом без профиля на реальной нагрузке.</p>\n<h2>Критерий готовности изменения</h2>\n<p>Изменение можно считать объяснимым, когда для одного workload названы владелец и окно наблюдения; effective requests и limits зафиксированы по container; смысл readiness записан одной фразой; HPA metric имеет источник и знаменатель; rollout имеет timeout и rollback; а выбранный эффект измерен тем же evidence до и после. Формулировки «Pod стал лучше» и «процент выглядит нормально» этого критерия не закрывают.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: Resource Management for Pods and Containers</a> — requests при планировании, limits и поведение контейнера при ограничении ресурсов.</li><li><a href=\"https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: Horizontal Pod Autoscaling</a> — resource metrics, расчёт utilization относительно request и ограничения HPA.</li><li><a href=\"https://kubernetes.io/docs/concepts/workloads/pods/probes/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: Liveness, Readiness, and Startup Probes</a> — назначение probes и удаление неготового Pod из Service traffic.</li><li><a href=\"https://kubernetes.io/docs/concepts/workloads/controllers/deployment/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: Deployments</a> — rolling update, selector и параметры maxUnavailable/maxSurge.</li></ul>"
 }
diff --git a/editorial/agent-rewrites/129.json b/editorial/agent-rewrites/129.json
index 243120e..06c1137 100644
--- a/editorial/agent-rewrites/129.json
+++ b/editorial/agent-rewrites/129.json
@@ -3,5 +3,6 @@
   "slug": "editorial-2024-06-practice-container-orchestration",
   "title": "Контейнерная нагрузка: как связать ресурсы, готовность и автомасштабирование",
   "excerpt": "Почему Pod может успешно разместиться, но не выдержать трафик: разбираем requests и limits, readiness и HPA на одном учебном примере.",
-  "contentHtml": "<p>После выкладки Pod получает статус Running, но запросы к сервису ждут дольше обычного. Иногда HPA увеличивает число реплик, а доступных backend не становится больше: новые Pod остаются неготовыми. В другой версии проблемы readiness отвечает успешно ещё до прогрева, и Service отправляет трафик в приложение, которое не держит рабочую нагрузку. Цена ошибки — задержки для клиентов, лишние реплики и трудный откат. Команда видит зелёный rollout и ищет причину уже под нагрузкой.</p>\n<p>Тезис простой: requests, limits, readiness и HPA описывают разные границы. Их нельзя настраивать как четыре независимые строки в манифесте. Сначала нужно назвать профиль приложения и единицу работы. Затем связать каждую границу с проверяемым сигналом. Тогда Kubernetes размещает Pod по одному правилу, допускает его к трафику по другому, а autoscaler меняет replicas по третьему. Это не даёт готовых чисел для любого сервиса. Зато не позволяет принять один сигнал за другой.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Как отделить похожие симптомы</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Pod долго остаётся Pending</td><td>Request не помещается на доступный Node или не учтены requests всех containers.</td><td>Сверить request каждого container с событиями scheduler и allocatable Node.</td><td>Исправить размер или размещение только после проверки профиля.</td></tr><tr><td>Pod Running, но сервис медленный</td><td>Running означает процесс, а не готовность и не capacity.</td><td>Сравнить Ready, readiness probe, latency и очередь за один период.</td><td>Разделить контракт готовности и гипотезу о ресурсе.</td></tr><tr><td>HPA меняет replicas без эффекта</td><td>Новые Pod не готовы, либо CPU target считается от неверного request.</td><td>Проверить effective request, metric source, Ready и время прогрева.</td><td>Не повышать maxReplicas, пока не исправлен сигнал.</td></tr><tr><td>Container получает OOMKilled</td><td>Memory limit ограничивает container, но не описывает жизненный цикл cache или объектов.</td><td>Сопоставить предел, рост working set и действие приложения при нехватке памяти.</td><td>Изменять limit вместе с политикой роста и восстановления.</td></tr></tbody></table></div>\n<h2>Как устроена связка</h2>\n<p><strong>Request</strong> — заявка на ресурс для размещения. Scheduler использует её, когда выбирает Node. Для Pod ресурсная заявка складывается из заявок его containers. Request не равен фактическому потреблению. Container может использовать больше request, если на Node есть свободный ресурс и limit это позволяет. Поэтому фраза «у Pod есть 500m CPU» неполна: нужно сказать, это request, limit или наблюдаемое usage.</p>\n<p><strong>Limit</strong> — верхняя граница исполнения для container. Он не обещает пропускную способность и не является знаменателем CPU utilization HPA. Для CPU превышение limit ограничивает доступ к CPU. Для memory превышение может закончиться убийством container. Применение зависит от ресурса и среды, поэтому нельзя переносить правило для CPU на memory. Если limit задан без request, конкретная admission-политика может использовать limit как request. Effective значения нужно увидеть в разрешённой проверке, а не угадывать по шаблону.</p>\n<p><strong>Readiness</strong> отвечает на узкий вопрос: можно ли сейчас отправлять трафик в этот container. При failed readiness Kubernetes убирает Pod из EndpointSlice соответствующего Service. Probe не измеряет запас capacity, throughput и качество каждого ответа. Не стоит включать в неё все внешние зависимости без явной политики отказа: краткий сбой одной зависимости способен вывести из трафика все реплики. Обратная ошибка не менее опасна: слишком ранний success пускает запросы до окончания прогрева.</p>\n<p><strong>HPA</strong> периодически меняет desired replicas по наблюдаемой метрике. Для CPU utilization в процентах важен request, к которому относится usage. Target 70 процентов — это не 70 процентов Node и не 70 процентов limit. Если request отсутствует там, где он нужен для расчёта, вывод по такой метрике нельзя считать осмысленным. При этом новый Pod ещё должен пройти startup и readiness. Автомасштабирование не может исправить неверный healthcheck и не сокращает время загрузки большого cache.</p>\n<h2>Учебный манифест</h2>\n<p>Ниже — ограниченный пример для HTTP-сервиса с устойчивой CPU-нагрузкой после прогрева. Значения не описывают реальный production workload. Они нужны, чтобы увидеть отношения между полями. Здесь request равен 500m, limit — 1000m, а target HPA относится к request. Startup probe отделяет запуск от liveness и readiness. Readiness проверяет локальный признак готовности приложения, а не весь внешний мир.</p>\n<pre><code>apiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: app\nspec:\n  replicas: 2\n  selector:\n    matchLabels:\n      app: app\n  template:\n    metadata:\n      labels:\n        app: app\n    spec:\n      containers:\n        - name: app\n          image: registry.example/app:1.4.0\n          resources:\n            requests:\n              cpu: \"500m\"\n              memory: \"384Mi\"\n            limits:\n              cpu: \"1000m\"\n              memory: \"768Mi\"\n          startupProbe:\n            httpGet: { path: /startup, port: 8080 }\n            failureThreshold: 30\n            periodSeconds: 2\n          readinessProbe:\n            httpGet: { path: /ready, port: 8080 }\n            periodSeconds: 5\n          livenessProbe:\n            httpGet: { path: /live, port: 8080 }\n            periodSeconds: 10\n---\napiVersion: autoscaling/v2\nkind: HorizontalPodAutoscaler\nmetadata:\n  name: app\nspec:\n  scaleTargetRef:\n    apiVersion: apps/v1\n    kind: Deployment\n    name: app\n  minReplicas: 2\n  maxReplicas: 6\n  metrics:\n    - type: Resource\n      resource:\n        name: cpu\n        target:\n          type: Utilization\n          averageUtilization: 70</code></pre>\n<p>Этот манифест не доказывает, что 500m достаточно. Он задаёт гипотезу: после прогрева одна реплика выдерживает согласованную steady-нагрузку, а CPU — её главный ограничитель. Если в реальности первым растёт memory или очередь, HPA по CPU не решает проблему. Если /ready отвечает до открытия рабочих пулов, реплики формально Ready, но фактически бесполезны. Отрицательный путь важен: когда гипотеза не подтверждается, нужно остановить изменение чисел и пересмотреть профиль, а не автоматически добавлять replicas.</p>\n<h2>Иллюстрация границ Pod</h2>\n<figure><img src=\"/assets/editorial/2024/container-orchestration-2024-pod-lifecycle.svg\" alt=\"Связь профиля приложения, ресурсов и состояний Pod\" loading=\"lazy\" /><figcaption>Схема отделяет состояния Pending, Running, Ready и Unready от границ ресурсов. Она иллюстрирует порядок рассуждения и не показывает данные живого кластера.</figcaption></figure>\n<p>Схему полезно читать слева направо. Профиль задаёт вопрос к manifest: что является единицей работы и какой ресурс ограничивает её первым. Request влияет на размещение. Limit ограничивает исполнение. Только затем readiness отвечает на вопрос о допуске к Service traffic. HPA использует свою метрику и свой знаменатель. Перепрыгнуть через профиль нельзя: иначе одинаковый target будет означать разные вещи для CPU-bound HTTP, memory-retaining cache и batch-задачи.</p>\n<h2>Проверка на конкретном workload</h2>\n<ol><li><strong>Назовите workload.</strong> Запишите owner, режим serving или batch, обычный startup, рабочую единицу и dominant resource. Фраза «сервис нагружен» для этого слишком расплывчата.</li><li><strong>Разберите каждый container.</strong> Выпишите CPU и memory request и limit отдельно. Укажите, складываются ли значения нескольких containers. Разрешённым способом проверьте admission defaults и effective manifest.</li><li><strong>Зафиксируйте readiness contract.</strong> Одним предложением опишите, что значит «можно принять запрос». Отдельно назовите случаи, когда Pod должен стать Unready, и случаи, которые не должны выводить его из трафика.</li><li><strong>Проверьте startup и liveness.</strong> Убедитесь, что долгая инициализация не выглядит как зависший процесс. Liveness должна обнаруживать неисправимое состояние, а не временную очередь или медленную внешнюю зависимость.</li><li><strong>Опишите метрику HPA.</strong> Запишите тип метрики, источник, request-знаменатель для utilization, minReplicas, maxReplicas и поведение при missing или not-yet-ready Pod. Не подменяйте эту проверку значением из учебного примера.</li><li><strong>Соберите ограниченное evidence.</strong> Выберите среду, владельца, временное окно и разрешённые источники. Сопоставьте Ready, usage, restart, latency и queue с одной гипотезой. Не объединяйте их в безымянное «состояние Pod».</li><li><strong>Измените одну границу.</strong> Задайте stop condition и rollback для request, limit, probe или HPA. После изменения повторите ту же проверку. Если сигнал не изменился, вернитесь к причине, а не к следующему коэффициенту.</li></ol>\n<h2>Ограничения и отрицательный путь</h2>\n<p>Эта схема не назначает ресурсы настоящему сервису и не подтверждает состояние кластера. Она не читает Metrics API, события Node, EndpointSlice, controller flags, feature gates, логи или trace. Официальные документы описывают механизм Kubernetes, но не знают версию, admission-политику и настройки конкретной среды. Поэтому учебные 500m, 384Mi, 70 процентов и два Pod нельзя выдавать за результат измерения.</p>\n<p>Есть и граница применимости. HPA по CPU подходит не каждому workload. Для memory-heavy приложения нужно отдельно описать рост рабочего набора и способ его ограничить. Для batch часто важнее размер очереди и время обработки. Для сервиса с дорогим warmup нужно учитывать startup и скорость появления Ready backend. Если исходный сигнал не объясняет цену ошибки, корректное действие — не менять manifest. Сначала нужно получить недостающее разрешённое наблюдение или признать задачу неготовой к настройке.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Конфигурация готова к обсуждению, когда для одного workload существует короткая карточка: request и limit каждого container, смысл readiness, условие startup, назначение liveness, metric HPA и её знаменатель, источник evidence, stop condition и rollback. Проверка должна связать каждое поле с одним наблюдаемым вопросом. После учебного прогона готовность не означает «Pod зелёный». Она означает, что команда может объяснить, какой сигнал изменился, почему это подтверждает или опровергает гипотезу и что произойдёт при отрицательном результате.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: Resource Management for Pods and Containers</a> — requests используются scheduler, limits применяются к работающему container.</li><li><a href=\"https://kubernetes.io/docs/concepts/workloads/pods/probes/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: Liveness, Readiness, and Startup Probes</a> — readiness управляет допуском к трафику, startup отделяет инициализацию от других probe.</li><li><a href=\"https://kubernetes.io/docs/concepts/workloads/autoscaling/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: Autoscaling Workloads</a> — HPA меняет число реплик по наблюдаемой у workload метрике.</li></ul>"
+  "contentHtml": "<p>После выкладки Pod получает статус <code>Running</code>, но запросы к сервису ждут дольше обычного. Иногда HorizontalPodAutoscaler (HPA) увеличивает число реплик, а доступных backend не становится больше: новые Pod не проходят readiness. В другой версии проблемы endpoint отвечает успешно ещё до прогрева, и Service отправляет трафик в приложение, которое не готово к рабочей нагрузке. Команда видит зелёный rollout и ищет причину уже под трафиком.</p>\n<p>У этих симптомов общий источник: в манифесте смешивают четыре разные границы. <code>requests</code> нужны планировщику для размещения, <code>limits</code> ограничивают выполнение container, readiness управляет допуском к трафику, а HPA меняет число реплик по метрике. Ни одно поле не обещает пропускную способность сервиса само по себе. Поэтому разберём не «правильные числа», а последовательность, в которой каждое число связывается с наблюдаемым результатом.</p>\n<h2>Сначала разделите симптомы</h2>\n<div class=\"table-scroll\"><table><caption>Один симптом не заменяет проверку соседних границ</caption><thead><tr><th scope=\"col\">Наблюдение</th><th scope=\"col\">Что оно подтверждает</th><th scope=\"col\">Что проверить дальше</th></tr></thead><tbody><tr><td>Pod остаётся <code>Pending</code></td><td>Pod не назначен на Node; request может не помещаться в доступный ресурс.</td><td>События Pod, requests всех containers, allocatable Node, taints и affinity.</td></tr><tr><td>Pod <code>Running</code>, но не <code>Ready</code></td><td>Процесс запущен, но probe не разрешает отправлять ему трафик.</td><td>Смысл endpoint, результаты probe, время прогрева и состояние Service.</td></tr><tr><td>Pod <code>Ready</code>, latency растёт</td><td>Текущая probe пропускает трафик; она не доказывает запас capacity.</td><td>CPU, memory, очередь, внешние вызовы и лимиты приложения.</td></tr><tr><td>HPA поднял replicas без эффекта</td><td>Решение о масштабировании было принято, но новые реплики могут не стать Ready или метрика не описывает bottleneck.</td><td>Метрику HPA, request-знаменатель, события, readiness и время появления backend.</td></tr><tr><td>Container перезапускается с <code>OOMKilled</code></td><td>Память пересекла ограничение или приложение получило другую фатальную ошибку.</td><td>Причину завершения, working set, limit, рост cache и политику восстановления.</td></tr></tbody></table></div>\n<p>Начинайте с колонки «наблюдение», а не с изменения манифеста. <code>Running</code> описывает состояние процесса, не готовность к запросам. Значение CPU в HPA не означает процент от Node или от <code>limit</code>: для ресурсной метрики utilization это отношение usage к request. Эти различия и есть рабочая карта диагностики.</p>\n<h2>Четыре границы одного Pod</h2>\n<p><strong>Request</strong> — заявка на ресурс. Scheduler учитывает requests контейнеров, когда выбирает Node; для обычного Pod суммарная заявка контейнеров определяет, сколько ресурса нужно зарезервировать при размещении. Request не равен фактическому usage: container может потреблять больше заявки, если это разрешают limit и свободный ресурс. Без request нельзя осмысленно интерпретировать CPU utilization HPA для такого контейнера.</p>\n<p><strong>Limit</strong> — ограничение выполнения контейнера. Для CPU превышение limit может привести к throttling, а для memory превышение может завершить процесс с <code>OOMKilled</code>. Limit не является обещанием throughput и не заменяет нагрузочное измерение. Если request или limit добавляет admission-политика namespace, смотрите итоговый объект в кластере, а не только исходный файл.</p>\n<p><strong>Readiness probe</strong> отвечает на узкий вопрос: можно ли сейчас отправить запрос этому контейнеру. При неуспешной readiness Kubernetes перестаёт считать Pod готовым endpoint для Service. Probe не измеряет запас capacity и не должна бездумно превращаться в проверку всех внешних зависимостей. Иначе краткий сбой партнёра способен убрать из трафика все реплики. Слишком ранний успешный ответ создаёт обратную проблему: приложение принимает запросы до открытия пулов, миграций или cache.</p>\n<p><strong>HPA</strong> периодически вычисляет желаемое число реплик по метрике. Для CPU с <code>averageUtilization: 70</code> контроллер сравнивает среднее потребление с CPU request, а не с limit. Pod без нужного request не даёт корректного CPU utilization; Pod, который ещё не готов или не имеет метрики, может учитываться консервативно в расчёте. Поэтому HPA нельзя читать без <code>describe</code>, состояния реплик и понимания того, откуда пришла метрика.</p>\n<h2>Учебный манифест с явной гипотезой</h2>\n<p>Ниже — минимальный serving-workload для HTTP-приложения. Предположим, что после прогрева CPU — главный ограничитель, endpoint <code>/startup</code> появляется один раз, <code>/ready</code> проверяет локальную готовность пулов, а <code>/live</code> отвечает только при неисправимом состоянии процесса. Значения <code>500m</code>, <code>384Mi</code>, две реплики и target 70% — не рекомендация и не результат измерения. Это числа для воспроизводимого учебного прогона.</p>\n<pre><code>apiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: app\nspec:\n  replicas: 2\n  selector:\n    matchLabels:\n      app: app\n  template:\n    metadata:\n      labels:\n        app: app\n    spec:\n      containers:\n        - name: app\n          image: registry.example/app:1.4.0\n          ports:\n            - name: http\n              containerPort: 8080\n          resources:\n            requests:\n              cpu: \"500m\"\n              memory: \"384Mi\"\n            limits:\n              cpu: \"1000m\"\n              memory: \"768Mi\"\n          startupProbe:\n            httpGet:\n              path: /startup\n              port: http\n            periodSeconds: 2\n            failureThreshold: 30\n          readinessProbe:\n            httpGet:\n              path: /ready\n              port: http\n            periodSeconds: 5\n            timeoutSeconds: 2\n          livenessProbe:\n            httpGet:\n              path: /live\n              port: http\n            periodSeconds: 10\n            timeoutSeconds: 2\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: app\nspec:\n  selector:\n    app: app\n  ports:\n    - name: http\n      port: 80\n      targetPort: http\n---\napiVersion: autoscaling/v2\nkind: HorizontalPodAutoscaler\nmetadata:\n  name: app\nspec:\n  scaleTargetRef:\n    apiVersion: apps/v1\n    kind: Deployment\n    name: app\n  minReplicas: 2\n  maxReplicas: 6\n  metrics:\n    - type: Resource\n      resource:\n        name: cpu\n        target:\n          type: Utilization\n          averageUtilization: 70</code></pre>\n<p><code>startupProbe</code> отделяет медленный запуск от последующих проверок: пока она не завершилась успешно, liveness и readiness не начинают обычную работу. Это защищает процесс от преждевременного перезапуска, но не ускоряет прогрев. После прогрева readiness должна означать «этот Pod может принять обычный запрос», а не «процесс слушает порт». У HPA есть верхняя граница шесть реплик, но она не гарантирует, что шесть Pod поместятся в кластер или выдержат запросы.</p>\n<h2>Иллюстрация пути запроса</h2>\n<figure><img src=\"/assets/editorial/2024/container-orchestration-2024-pod-lifecycle.svg\" alt=\"Путь от request и запуска контейнера к readiness, Service и решению HPA\" loading=\"lazy\" /><figcaption>Учебная схема разделяет размещение Pod, допуск к Service и масштабирование по метрике. Она показывает порядок вопросов, а не состояние конкретного кластера.</figcaption></figure>\n<p>Читать схему нужно слева направо. Сначала scheduler решает, где Pod может быть размещён по requests. Затем kubelet запускает контейнер и выполняет startup, readiness и liveness в своих ролях. Service направляет запросы только к готовым backend. Параллельно HPA получает свою метрику и меняет desired replicas. При таком порядке увеличение replicas не исправляет неверный readiness, а поднятие memory limit не исправляет очередь запросов.</p>\n<h2>Воспроизводимый прогон</h2>\n<p>Сохраните манифест в файл <code>app.yaml</code> в тестовом namespace и сначала проверьте его сервером. Эта команда обращается к API и может требовать прав; локальный кластер, версия Kubernetes, policy admission и наличие Metrics API должны быть известны заранее.</p>\n<pre><code>kubectl config current-context\nkubectl auth can-i create deployment -n demo\nkubectl describe pod -n demo -l app=app --show-events\nkubectl apply --dry-run=server -n demo -f app.yaml\nkubectl diff -n demo -f app.yaml\nkubectl apply -n demo -f app.yaml\nkubectl rollout status deployment/app -n demo --timeout=120s\nkubectl get pods -n demo -l app=app -o wide\nkubectl get endpointslice -n demo -l kubernetes.io/service-name=app\nkubectl describe hpa app -n demo\nkubectl top pods -n demo -l app=app</code></pre>\n<p>Последняя команда требует работающего Metrics API, часто его предоставляет Metrics Server. Если она возвращает ошибку, это не доказательство нулевой нагрузки и не повод подставить число вручную. Зафиксируйте ошибку как ограничение прогона. <code>kubectl diff</code> и <code>--dry-run=server</code> также не заменяют rollout: первая сравнивает объект, вторая проверяет запрос к API, а третья показывает, что Deployment действительно продвигается. Команда <code>describe pod -l</code> удобна как быстрый запрос, но при нескольких Pod для детального анализа выберите конкретное имя из <code>get pods</code>.</p>\n<h2>Как читать результат и отрицательный путь</h2>\n<ol><li><strong>Проверьте контекст.</strong> Убедитесь, что команды обращаются к ожидаемому кластеру и namespace. Не применяйте учебный файл в production только потому, что текущий context называется коротко.</li><li><strong>Отделите размещение от запуска.</strong> Для <code>Pending</code> прочитайте <code>kubectl describe pod</code> и события. Сопоставьте requests с allocatable, а не с общей памятью Node. Если Pod размещён, переходите к probes.</li><li><strong>Проверьте время.</strong> Сравните длительность startup с <code>failureThreshold × periodSeconds</code>. Для этого примера окно startup — до 60 секунд при последовательных неуспехах, но реальное время зависит от результата probe и приложения.</li><li><strong>Сверьте Ready и endpoint.</strong> Сопоставьте поле Ready у Pod с EndpointSlice и фактическим ответом <code>/ready</code>. Если Pod Ready, а latency растёт, probe выполняет свой узкий контракт; ищите bottleneck в CPU, memory, очереди или внешнем вызове.</li><li><strong>Разберите HPA.</strong> В <code>describe hpa</code> найдите текущую и целевую метрики, desired replicas, события и ошибки. Сопоставьте их с request. Отсутствие данных Metrics API нельзя трактовать как отсутствие нагрузки.</li><li><strong>Проверьте отрицательный путь.</strong> Если новые Pod не становятся Ready, не увеличивайте <code>maxReplicas</code>. Сначала исправьте контракт готовности или startup, затем повторите тот же прогон. Если HPA масштабируется, но latency не улучшается, проверьте, является ли CPU главным ограничителем.</li><li><strong>Изменяйте одну границу.</strong> Зафиксируйте гипотезу, одно изменение, окно наблюдения, критерий остановки и rollback. Иначе после одновременного изменения limit, probe и HPA нельзя понять, что именно изменило результат.</li></ol>\n<h2>Какие числа можно считать доказанными</h2>\n<p>В учебном файле доказан только синтаксический и объектный контракт, если его принял API. Значение <code>500m</code> становится обоснованным request лишь после повторяемого измерения representative-нагрузки с согласованным latency budget и запасом на пики. Target 70% становится рабочей гипотезой только вместе с наблюдаемым временем масштабирования, размером очереди и готовностью новых реплик. Значение <code>768Mi</code> нельзя оправдать одной строкой <code>OOMKilled</code>: нужно понять, растёт ли cache, есть ли утечка и сколько памяти нужно процессу при штатном пике.</p>\n<p>После каждого изменения сохраняйте минимум: версию образа, итоговый Deployment, временное окно, входную нагрузку, latency/error rate, состояние Pod и HPA, а также решение об откате. Это превращает настройку из перебора коэффициентов в проверяемый эксперимент. Если не хватает разрешённого наблюдения, корректное действие — остановить эксперимент, а не додумывать результат.</p>\n<h2>Ограничения применимости</h2>\n<p>Схема рассчитана на stateless HTTP-сервис, который можно безопасно масштабировать горизонтально. Она не решает координацию StatefulSet, порядок миграций базы, работу с локальным диском, очередями, GPU или внешним rate limit. HPA по CPU может быть плохим сигналом для memory-heavy приложения, batch-задачи или сервиса, где bottleneck — очередь и время ответа партнёра. Для таких случаев нужна другая метрика и отдельная проверка её источника.</p>\n<p>Точный результат зависит от версии Kubernetes, API и controller flags, Metrics API, admission defaults, политики namespace, сетевого маршрута и реализации приложения. Схема также не проверяет PDB, topology spread, node autoscaling и безопасность образа. Наличие статуса <code>Available</code> или зелёного rollout не является доказательством производительности. Граница вывода простая: эта статья даёт порядок проверки, а не готовый production-манифест.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: Resource Management for Pods and Containers</a> — назначение requests и limits, их связь с размещением и поведением контейнеров.</li><li><a href=\"https://kubernetes.io/docs/concepts/workloads/pods/probes/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: Liveness, Readiness, and Startup Probes</a> — роли probe, порядок startup и влияние readiness на доступность Pod.</li><li><a href=\"https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: Horizontal Pod Autoscaling</a> — вычисление desired replicas, CPU utilization относительно request и обработка неполных метрик.</li><li><a href=\"https://kubernetes.io/docs/concepts/workloads/controllers/deployment/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: Deployments</a> — rollout Deployment и связь желаемого состояния с ReplicaSet.</li><li><a href=\"https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: EndpointSlices</a> — представление backend Service и условий готовности endpoint.</li><li><a href=\"https://kubernetes.io/docs/reference/kubectl/generated/kubectl_top/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes: kubectl top</a> — назначение команды и требование Metrics API.</li></ul>",
+  "readingMinutes": 9
 }
diff --git a/editorial/agent-rewrites/130.json b/editorial/agent-rewrites/130.json
index ea88bb3..2774225 100644
--- a/editorial/agent-rewrites/130.json
+++ b/editorial/agent-rewrites/130.json
@@ -2,6 +2,6 @@
   "index": 130,
   "slug": "editorial-2024-05-field-platform-templates",
   "title": "Платформенный шаблон без ловушки fork: как провести границу решения",
-  "excerpt": "Шаблон ускоряет повторяемый путь, но не заменяет архитектурное решение. Разбираем симптомы слишком широкой формы, проверяем golden path, узкое расширение и корректный отказ.",
-  "contentHtml": "<p>Новая команда просит создать сервис, а платформа предлагает одну форму: имя, владелец, runtime, репозиторий и несколько флагов. Сначала это выглядит удобно. Через месяц появляются локальные правки, особые healthcheck, другой retention и ручные исключения в CI. Два сервиса уже не похожи на исходный шаблон, но команда всё ещё считает их его вариантами. Цена ошибки — не только лишняя работа. Теряется владелец контракта, обновления перестают доходить до копий, а рискованный выбор прячется за кнопкой Create.</p>\n<p>Тезис простой: шаблон должен принимать только повторяемый класс задач. Совпадение с базовым контрактом ведёт в golden path. Одно заранее описанное отличие ведёт на review расширения. Несовместимый или одноразовый запрос нужно остановить. Отказ дешевле fork-а, который создаёт ложное ощущение поддержки.</p>\n<h2>Симптомы широкой формы</h2>\n<p>Первый симптом — просьба добавить универсальное поле: «если понадобится, разрешим внешний data class», «пусть runtime выбирается позже», «добавим произвольный adapter». Поле кажется небольшим, но меняет инвариант. После него шаблон уже не описывает один тип сервиса. Он принимает несколько архитектурных решений без владельца.</p>\n<p>Второй симптом — локальный patch сразу после создания репозитория. Команда удаляет обязательный шаг, переписывает pipeline или меняет доступы, а потом обещает вернуть полезное изменение в общий шаблон. Если различие не имеет имени, владельца, границы и условия удаления, это не extension. Это отдельный проект, который маскируется под стандартный путь.</p>\n<p>Третий симптом — платформа выдаёт skeleton для задачи, у которой ещё нет data policy, access model или ответственного. Файлы создаются быстро, но структура начинает диктовать решение. Команда подгоняет требования под уже созданный репозиторий. Технический артефакт появляется раньше архитектурного договора.</p>\n<h2>Механизм: три слоя вместо одной кнопки</h2>\n<p>Разделите решение на три слоя. Первый — входные факты: тип компонента, владелец, runtime, класс данных, требования к доставке и срок жизни. Второй — контракт: допустимые значения и обязательные шаги. Третий — результат: применить базовый путь, отправить ограниченное расширение на review или отказать до уточнения требований.</p>\n<p>Backstage описывает шаблон как набор параметров и последовательных шагов. Это полезный механизм, но он не делает любой параметр безопасным. Параметр собирает значение. Решение о том, разрешено ли значение, должно жить в контракте и проверке. GitHub template repository копирует структуру и файлы в новый репозиторий, но создаёт несвязанную историю. Автоматического канала изменений исходного шаблона это не даёт.</p>\n<table><caption>Симптом → причина → проверка → действие</caption><thead><tr><th>Симптом</th><th>Причина</th><th>Проверка</th><th>Действие</th></tr></thead><tbody><tr><td>Просят «универсальный» флаг</td><td>Поле меняет runtime, ownership, data class, access или retention</td><td>Сравнить поле с базовым инвариантом и назвать владельца</td><td>Убрать поле из golden path; оформить отдельный путь</td></tr><tr><td>После создания нужен patch</td><td>Различие не описано как versioned extension</td><td>Проверить identifier, owner, boundary и rollback</td><td>Остановить копирование; вынести различие на review</td></tr><tr><td>Шаблон приняли для миграции</td><td>Нет повторяемого типа и жизненного цикла</td><td>Проверить повторяемость того же контракта</td><td>Отказать шаблону и провести отдельное решение</td></tr><tr><td>Repository считают fork-ом</td><td>Смешаны копирование и наследование изменений</td><td>Проверить историю и канал обновлений</td><td>Зафиксировать самостоятельное владение или другой механизм</td></tr></tbody></table>\n<figure><img src=\"/assets/editorial/2024/platform-templates-2024-adoption-loop.svg\" alt=\"Цикл выбора платформенного шаблона: базовый контракт, golden path, ограниченное расширение или отказ\"><figcaption>Сначала запрос сверяется с контрактом, затем выбирается путь. Схема не обозначает измеренный adoption или production-результат.</figcaption></figure>\n<h2>Пример контракта</h2>\n<p>Ниже — учебный фрагмент. Он не запускает реальную задачу и не доказывает пригодность набора полей для вашей организации. Базовый путь принимает внутренний HTTP-сервис с известным владельцем и утверждённым runtime. Observability adapter разрешён как именованное расширение. Внешние регулируемые данные форму не проходят.</p>\n<pre><code>apiVersion: scaffolder.backstage.io/v1beta3\\nkind: Template\\nmetadata:\\n  name: internal-http-service\\nspec:\\n  owner: group:platform\\n  type: service\\n  parameters:\\n    - title: Service contract\\n      required: [name, owner, runtime, dataClass]\\n      properties:\\n        runtime:\\n          type: string\\n          enum: [node20, go122]\\n        dataClass:\\n          type: string\\n          enum: [internal]\\n        extension:\\n          type: string\\n          enum: [none, observability-adapter]\\n  steps:\\n    - id: write-skeleton\\n      action: fetch:template\\n    - id: publish\\n      action: publish:github</code></pre>\n<p>В примере enum ограничивает форму, но не заменяет проверку прав и политики. Owner должен ссылаться на существующую группу, а публикация требует разрешений и проверки credentials. В рабочем шаблоне эти условия подтверждаются средствами вашей платформы. YAML не доказывает успешный запуск, безопасность или пригодность runtime.</p>\n<p>Первая заявка содержит известный service type, владельца, approved runtime и internal data. Она совпадает с контрактом: golden path. Вторая содержит те же факты и один adapter из закрытого списка. Если у расширения есть owner, граница и способ удаления, это review extension. Третья описывает одноразовую регулируемую миграцию, но не содержит владельца, retention и access model. Ей нужен отказ от шаблона и отдельное решение.</p>\n<h2>Почему fork не исправляет несовпадение</h2>\n<p>Fork отвечает на вопрос «как начать самостоятельный проект на основе текущих файлов». Он не отвечает на вопрос «как поддерживать общий контракт между проектами». Repository, созданный из template, получает несвязанную историю. Pull request между копией и шаблоном не становится штатным каналом синхронизации.</p>\n<p>Fork допустим, когда команда принимает независимый жизненный цикл. Тогда нужно записать владельца, область ответственности и способ получать будущие изменения. Если ожидается обновление всех созданных проектов из базового шаблона, нужен другой механизм доставки или честная граница поддержки.</p>\n<p>Не расширяйте базовый шаблон ради редкого запроса. Новое поле увеличивает число состояний для всех пользователей. Особенно опасны поля, которые откладывают решение: «позже выберем runtime», «потом определим доступ», «retention настроит команда». Отсутствующее решение нельзя превратить в безопасный default названием параметра.</p>\n<h2>Порядок действий</h2>\n<ol><li>Запишите заявку: component type, owner, runtime, data class, access, retention и срок жизни. Не начинайте с копирования файлов.</li><li>Сверьте каждый факт с контрактом. Пометьте значения, для которых нет допустимого варианта или владельца.</li><li>Выберите результат. Полное совпадение даёт golden path. Одно названное отличие с границей и rollback даёт review extension. Остальные запросы получают decline.</li><li>Проверьте отрицательный путь: неизвестный runtime, внешний data class, отсутствие owner и неподдерживаемое расширение должны остановиться до создания артефакта.</li><li>Для расширения зафиксируйте identifier, owner, boundary, version и условие удаления. Если поле нельзя заполнить, расширение не готово.</li><li>После review запускайте реальную публикацию. Проверьте credentials, права, pipeline, healthcheck, наблюдаемость и rollback в вашей среде.</li><li>Пересмотрите расширение через согласованный срок. Повторяемый класс можно включить в новую версию контракта. Одноразовый случай не превращайте в обязательную опцию.</li></ol>\n<h2>Ограничения</h2>\n<p>Шаблон не выбирает владельца, не определяет классификацию данных и не делает action безопасным. Список runtime устаревает. Документация объясняет форму и порядок шагов, но не знает ваших сетевых прав, требований регулятора и правил отката. Эти условия проходят отдельную проверку.</p>\n<p>Учебный YAML не является production-конфигурацией. В нём нет конкретной схемы прав, политики секретов, branch protection, SLO и обязательных проверок поставки. Не переносите его в рабочую систему без адаптации и review. Цифры adoption, скорости и снижения дефектов здесь не заявлены.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Решение готово, когда другая команда берёт ту же заявку и получает тот же вердикт по тем же фактам. Для golden path форма принимает только значения контракта. Для extension документ содержит owner, boundary, version и rollback. Для отказа есть причина и следующий вопрос вне шаблона. Неизвестное или рискованное значение останавливается до создания репозитория и не превращается в локальный patch.</p>\n<p>Проверка состоит из четырёх записей: базовая заявка, узкое расширение, несовместимая заявка и повторный запуск первой. Готовность есть, если базовые записи дают одинаковый результат, расширение не меняет инварианты, отказ не создаёт артефакт, а повторный запуск не дублирует обязательные действия.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://backstage.io/docs/features/software-templates/\" target=\"_blank\" rel=\"noopener noreferrer\">Backstage: Software Templates</a> — параметры, шаги и задачи Scaffolder.</li><li><a href=\"https://backstage.io/docs/next/features/software-catalog/descriptor-format/\" target=\"_blank\" rel=\"noopener noreferrer\">Backstage: Descriptor Format of Catalog Entities</a> — форма сущностей и ответственность владельца Template.</li><li><a href=\"https://docs.github.com/en/repositories/creating-and-managing-repositories/creating-a-repository-from-a-template\" target=\"_blank\" rel=\"noopener noreferrer\">GitHub Docs: Creating a repository from a template</a> — копирование структуры и несвязанные истории.</li></ul>"
+  "excerpt": "Шаблон ускоряет повторяемый путь, но не заменяет архитектурное решение. Разбираем симптомы слишком широкой формы, проверяем контракт, безопасное расширение и корректный отказ до создания репозитория.",
+  "contentHtml": "<p>Новая команда просит создать сервис, а платформа предлагает одну форму: имя, владелец, runtime, репозиторий и несколько флагов. В первый день это похоже на хороший стандарт. Через месяц у сервиса появляется особый healthcheck, другой срок хранения данных, ручное исключение в CI и локальный скрипт для деплоя. Ещё через месяц команда просит добавить в форму «универсальный adapter», чтобы не делать отдельное решение.</p>\n<p>Так шаблон превращается в каталог скрытых архитектурных решений. Кнопка Create всё ещё выглядит простой, но за ней уже нет единого контракта: разные команды получают разные права, жизненные циклы и обязанности поддержки. Тезис статьи простой: автоматизировать стоит повторяемую задачу, а несовпадение нужно увидеть до генерации репозитория. Полное совпадение ведёт в golden path, одно явно ограниченное отличие — на review расширения, изменение инварианта — к отказу от шаблона.</p>\n<h2>Симптомы шаблона, который стал слишком широким</h2>\n<p>Первый симптом — просьба добавить поле без заранее определённого множества значений. «Пусть команда сама укажет runtime», «выберем хранилище позже», «разрешим любой внешний adapter» звучит как небольшая доработка формы. На деле каждое такое поле переносит решение из архитектурного обсуждения в момент генерации. Пользователь заполняет значение, но не получает ответа, кто отвечает за его безопасность, обновление и удаление.</p>\n<p>Второй симптом — patch сразу после создания проекта. Команда выключает обязательную проверку, переписывает pipeline или меняет видимость репозитория, а затем обещает вернуть полезную часть в общий шаблон. Если различие нельзя назвать, назначить ему владельца, очертить границу и описать обратный ход, это не расширение базового пути. Это самостоятельный проект, который временно маскируется под стандартный.</p>\n<p>Третий симптом — шаблон создаёт код раньше, чем зафиксированы класс данных и модель доступа. Skeleton уже содержит Dockerfile, workflow и manifest, поэтому команда начинает подгонять требования под готовую структуру. Платформа помогла быстро получить файлы, но незаметно стала источником политики. Удобная форма не должна принимать решение за владельца данных или службы безопасности.</p>\n<h2>Что именно делает шаблон, а чего он не делает</h2>\n<p>В Backstage Software Templates пользователь вводит параметры, после чего Scaffolder выполняет последовательность шагов. В документации среди таких шагов показаны загрузка skeleton, подстановка значений и публикация результата в GitHub или GitLab. Это механизм автоматизации, а не доказательство того, что любое сочетание параметров разрешено. Допустимые значения, обязательные поля и проверки должны быть частью контракта вашей платформы.</p>\n<p>GitHub template repository решает другую задачу: создаёт новый репозиторий с той же структурой, ветками и файлами. GitHub отдельно предупреждает, что ветки из шаблона имеют несвязанные истории; новый fork, напротив, сохраняет историю родительского репозитория. Поэтому template — удобный старт нового проекта, но не канал доставки обновлений во все уже созданные проекты. Ошибка начинается, когда копию называют fork-ом и обещают ей автоматическое наследование.</p>\n<table><caption>Решение до генерации: симптом, проверка и действие</caption><thead><tr><th>Наблюдение</th><th>Что проверяем</th><th>Вердикт</th><th>Следующий шаг</th></tr></thead><tbody><tr><td>Все входы входят в закрытый контракт</td><td>Тип сервиса, владелец, runtime, класс данных и видимость имеют допустимые значения</td><td>Golden path</td><td>Запустить стандартные шаги и записать версию контракта</td></tr><tr><td>Есть одно отличие от базы</td><td>У отличия есть идентификатор, owner, граница, срок действия и rollback</td><td>Review extension</td><td>Рассмотреть отдельную ветку; не добавлять свободное поле в форму</td></tr><tr><td>Меняется инвариант</td><td>Появляется новый класс данных, модель доступа или жизненный цикл</td><td>Decline template</td><td>Остановить генерацию и провести отдельное архитектурное решение</td></tr><tr><td>Просят синхронизировать копии с базой</td><td>Есть ли реальный канал поставки обновлений и владелец миграций</td><td>Не обещать наследование</td><td>Выбрать upstream-механику или зафиксировать независимое владение</td></tr></tbody></table>\n<figure><img src=\"/assets/editorial/2024/platform-templates-2024-escape-hatch.svg\" alt=\"Схема развилки платформенного шаблона: совпадение ведёт в golden path, ограниченное расширение — на review, изменение инварианта — к остановке\"><figcaption>Развилка должна быть видна до генерации проекта: свободный параметр скрывает отличие, а именованное расширение оставляет его проверяемым.</figcaption></figure>\n<h2>Контракт: входные факты, инварианты и результат</h2>\n<p>Начните не с YAML, а с короткой заявки. Запишите тип компонента, владельца, runtime, класс данных, видимость репозитория, требования к доступу и срок хранения. Затем отделите инварианты от вариантов. Например, для внутреннего HTTP-сервиса инвариантами могут быть подтверждённый владелец, закрытый класс данных и один из поддерживаемых runtime. Название проекта и регион могут быть вариантами, если они не меняют модель риска.</p>\n<p>У контракта должны быть три явных результата. <strong>Golden path</strong> применяет стандарт без ручного решения. <strong>Расширение</strong> добавляет ровно одну заранее названную возможность и проходит review до создания артефакта. <strong>Отказ</strong> не означает «никогда»: он говорит, что текущая форма не является правильным местом для нового инварианта. Следующий вопрос должен вести к отдельному design path — с владельцем и проверками.</p>\n<p>Поле допустимо только тогда, когда его множество значений закрыто или его проверка определена отдельно. Удобное правило: если для значения нельзя сразу назвать owner, policy и способ отката, значение не должно попадать в golden path. Неизвестный runtime нельзя сделать безопасным значением с помощью default, а внешний data class нельзя превратить во внутренний одним текстом подсказки.</p>\n<h2>Учебный шаблон Backstage с закрытыми значениями</h2>\n<p>Ниже приведён минимальный учебный фрагмент для Backstage Scaffolder. Он показывает форму и порядок шагов, но не является готовой конфигурацией вашей инсталляции. В реальном проекте замените URL skeleton, организацию, группу владельца и action публикации на разрешённые вашей платформой значения.</p>\n<pre><code>apiVersion: scaffolder.backstage.io/v1beta3\nkind: Template\nmetadata:\n  name: internal-http-service\nspec:\n  owner: group:platform\n  type: service\n  parameters:\n    - title: Service contract\n      required:\n        - name\n        - owner\n        - runtime\n        - dataClass\n        - repoVisibility\n      properties:\n        name:\n          title: Service name\n          type: string\n          pattern: '^[a-z0-9-]+$'\n        owner:\n          title: Owning group\n          type: string\n        runtime:\n          title: Runtime\n          type: string\n          enum:\n            - node20\n            - go122\n        dataClass:\n          title: Data class\n          type: string\n          enum:\n            - internal\n        repoVisibility:\n          title: Repository visibility\n          type: string\n          enum:\n            - private\n            - internal\n  steps:\n    - id: fetchBase\n      name: Fetch approved skeleton\n      action: fetch:template\n      input:\n        url: ./template\n        values:\n          name: ${{ parameters.name }}\n          runtime: ${{ parameters.runtime }}\n    - id: publish\n      name: Publish repository\n      action: publish:github\n      input:\n        repoUrl: 'github.com?owner=acme&amp;repo=${{ parameters.name }}'\n        repoVisibility: ${{ parameters.repoVisibility }}</code></pre>\n<p>В этом примере enum ограничивает runtime, класс данных и видимость, а pattern отсекает часть случайных имён. Это полезная граница формы, но не полноценная авторизация. Строка owner всё ещё должна разрешаться по каталогу групп, action публикации требует настроенной интеграции и credentials, а закрытый класс данных не отменяет проверку содержимого skeleton. Backstage описывает owner шаблона как ответственную сущность, но прямо отделяет это поле от runtime-авторизации. Проверки прав и секретов остаются обязанностью конфигурации вашей платформы.</p>\n<h2>Воспроизводимая проверка разницы между template и fork</h2>\n<p>Проверить обещание «проект наследует шаблон» можно без спора о терминах. Создайте тестовый репозиторий из шаблона, клонируйте оба репозитория и сравните корневые коммиты. В команде ниже замените <code>acme/service-template</code> и <code>acme/orders-api</code> на доступные вам репозитории. Команда создания изменяет удалённый GitHub и поэтому предназначена только для тестового владельца, у которого есть право создавать репозитории.</p>\n<pre><code>gh repo create acme/orders-api --private --template acme/service-template\ngh repo clone acme/service-template /tmp/service-template\ngh repo clone acme/orders-api /tmp/orders-api\nprintf 'template roots: '\ngit -C /tmp/service-template rev-list --max-parents=0 HEAD\nprintf 'created roots: '\ngit -C /tmp/orders-api rev-list --max-parents=0 HEAD\ngit -C /tmp/orders-api log --oneline --decorate -5</code></pre>\n<p>Ожидаемый результат для GitHub template — новый репозиторий с собственной начальной историей. Это не измерение качества шаблона и не проверка того, что файлы совпадают навсегда. Для проверки содержимого зафиксируйте commit шаблона, сравните нужные файлы и отдельно решите, как доставлять будущие изменения: pull request из upstream, пакет, генератор миграций или ручное владение. Если такого канала нет, в документации проекта нужно прямо написать: после создания репозиторий самостоятельный.</p>\n<h2>Как оформить узкое расширение</h2>\n<p>Расширение — это не поле «custom». Сначала дайте ему имя, например <code>observability-adapter-v1</code>, и опишите, что оно добавляет и чего не меняет. Затем назначьте owner, перечислите затронутые файлы и разрешения, задайте условие включения, срок пересмотра и rollback. Владелец должен быть способен принять инцидент и удалить расширение, а не только согласовать его в каталоге.</p>\n<p>Проверка расширения должна включать положительный и отрицательный случаи. Положительный случай доказывает, что базовый сервис создаётся и получает adapter. Отрицательный — что произвольное значение или другой класс данных останавливают задачу до публикации. Если action уже создал репозиторий, а затем обнаружил несовместимость на deploy, граница стоит слишком поздно: потребуется cleanup, а часть риска уже прошла.</p>\n<p>Не включайте редкое расширение в общий шаблон только потому, что так короче обсуждение. Каждая новая ветка увеличивает число состояний, которые нужно тестировать и поддерживать. Если один и тот же запрос повторяется и сохраняет общий инвариант, соберите доказательства и включите его в следующую версию контракта. Если запрос одноразовый или меняет модель ответственности, оставьте его отдельным проектом.</p>\n<h2>Отрицательный путь: когда шаблон обязан остановиться</h2>\n<ol><li>Зафиксируйте заявку до создания файлов: тип компонента, owner, runtime, data class, видимость, access и retention.</li><li>Сверьте каждое поле с версией контракта. Неизвестное значение пометьте как несовместимое, а не как «временное».</li><li>Проверьте владельца по реальному каталогу групп и убедитесь, что он отвечает и за результат, и за последующие изменения.</li><li>Запустите dry-run или тестовый Scaffolder task, если такая возможность включена в вашей Backstage-инсталляции. Убедитесь, что отказ происходит до publish.</li><li>Для расширения проверьте owner, границу, permissions, rollback и срок пересмотра. Отсутствующий пункт — причина вернуть запрос на review.</li><li>После создания проверьте не только наличие файлов, но и visibility, branch protection, CI, секреты, healthcheck и наблюдаемость в вашей среде.</li><li>Запишите commit шаблона и версию контракта рядом с созданным проектом. Это позволяет понять, от какой исходной формы он стартовал, даже если история репозиториев несвязана.</li></ol>\n<h2>Ограничения применимости</h2>\n<p>Описанный подход не заменяет threat model, классификацию данных, согласование доступа и правила вашей организации. Backstage может проверять схему параметров и выполнять actions, но конкретный набор integrations, permissions, secrets и custom actions зависит от инсталляции. Учебный YAML не доказывает безопасность публикации и не должен переноситься в production без адаптации и review.</p>\n<p>Команда <code>gh repo create</code> требует установленного GitHub CLI, входа в нужный аккаунт и права создания репозитория; выполнение команды изменяет внешний GitHub. Сравнение корневых коммитов доказывает различие историй только для конкретной пары репозиториев. Оно не проверяет актуальность файлов, policy или pipeline. Для GitLab, другой forge или внутреннего шаблонизатора действуют аналогичные вопросы, но точные команды и семантика могут отличаться.</p>\n<h2>Критерий готовности решения</h2>\n<p>Шаблон готов к использованию, когда другая команда может взять ту же заявку и получить тот же вердикт по тем же фактам. Для golden path разрешены только значения закрытого контракта. Для extension есть owner, boundary, version, проверка отрицательного пути и rollback. Для отказа указана причина и следующий владелец отдельного решения. Ни один неизвестный параметр не создаёт репозиторий «на авось».</p>\n<p>Минимальный набор доказательств — четыре записи: стандартная заявка, разрешённое расширение, несовместимая заявка и повтор стандартной заявки. Первая и четвёртая дают один результат, вторая не меняет базовых инвариантов, третья останавливается до publish. После этого отдельно проверяются права, secrets, CI и ручные шаги окружения. Такой результат честнее, чем обещание, что одна форма поддерживает все будущие варианты.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://backstage.io/docs/features/software-templates/\" target=\"_blank\" rel=\"noopener noreferrer\">Backstage: Software Templates</a> — параметры, последовательность шагов, dry-run и поведение задач Scaffolder.</li><li><a href=\"https://backstage.io/docs/features/software-templates/writing-templates/\" target=\"_blank\" rel=\"noopener noreferrer\">Backstage: Writing Templates</a> — структура <code>spec.parameters</code>, <code>spec.steps</code>, actions, условия шагов и обработка ошибок.</li><li><a href=\"https://backstage.io/docs/features/software-catalog/descriptor-format/\" target=\"_blank\" rel=\"noopener noreferrer\">Backstage: Descriptor Format of Catalog Entities</a> — семантика <code>kind: Template</code> и owner сущности.</li><li><a href=\"https://docs.github.com/en/repositories/creating-and-managing-repositories/creating-a-repository-from-a-template\" target=\"_blank\" rel=\"noopener noreferrer\">GitHub Docs: Creating a repository from a template</a> — отличие template от fork и несвязанные истории.</li><li><a href=\"https://cli.github.com/manual/gh_repo_create\" target=\"_blank\" rel=\"noopener noreferrer\">GitHub CLI: gh repo create</a> — флаг <code>--template</code> и требования команды создания репозитория.</li></ul>"
 }