# Выпуск и эксплуатация Версия источника: 4880e8b4372c96001c2e052be28b68a95d31252b Синхронизировано: 2026-11-09T11:15:07.649Z Источник: https://github.com/sergey-from-riders/vibecoding-base/tree/4880e8b4372c96001c2e052be28b68a95d31252b ## Оглавление - [Correlation ID](#operations-correlation) - [HTTP spans](#operations-http-spans) - [Observability](#operations-signals) - [SLO и error budget](#operations-slo) - [Неизменяемый артефакт](#operations-immutable-release) - [Rollback](#operations-rollback) - [Backup и restore](#operations-restore) - [Конфигурация окружения](#operations-config) - [Incident runbook](#operations-incident) # Correlation ID ## Коротко Используйте идентификатор запроса и трассы, чтобы найти связанные события. ## Плохо ```text Ошибка есть в логах, но непонятно, к какому запросу относится. ``` ## Хорошо ```text Ответ и логи связаны request_id. Вызовы сервисов связаны trace_id. ``` ## Почему Поддержке легче восстановить последовательность без сбора лишних персональных данных. ## Когда применять Входящий request_id проверяйте по размеру и формату. Трассировка и ID запроса имеют разные назначения. ## Как проверить - По ID из ответа можно найти путь запроса? ## Человек Определяет границы операции и доступ поддержки к диагностике. ## Агент Готовит воспроизводимые команды, проверяет состояние сервисов и прикладывает фактический результат. Контроль результата: - По ID из ответа можно найти путь запроса? ## Источники - [Context propagation](https://opentelemetry.io/docs/concepts/context-propagation/) Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/observability/three-signals/rules/correlation.md) --- # HTTP spans ## Коротко В OpenTelemetry успешный HTTP-ответ обычно оставляет статус span неустановленным. ## Плохо ```text HTTP 200 → span OK Любой HTTP 404 → span OK ``` ## Хорошо ```text HTTP 200 → Unset HTTP 404, server → Unset HTTP 404, client → Error по общему правилу HTTP 500 → Error ``` ## Почему Клиент и сервер интерпретируют часть ошибок по-разному; сам HTTP-код сохраняется отдельно. ## Когда применять Для стандартной HTTP-инструментации без дополнительного контекста. Сетевой сбой и явно ожидаемый результат могут уточнять классификацию. ## Как проверить - Сверьте 2xx, 4xx, 5xx и сетевой сбой с semconv используемой версии. ## Человек Определяет, какие сбои требуют внимания и как они отражаются в метриках. ## Агент Готовит воспроизводимые команды, проверяет состояние сервисов и прикладывает фактический результат. Контроль результата: - Сверьте 2xx, 4xx, 5xx и сетевой сбой с semconv используемой версии. ## Источники - [Semantic conventions for HTTP spans](https://opentelemetry.io/docs/specs/semconv/http/http-spans/) Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/observability/three-signals/rules/http-spans.md) --- # Observability ## Коротко Каждый сигнал должен помогать обнаружить или объяснить проблему. ## Плохо ```text Много логов, но неизвестно, сколько запросов падает. ``` ## Хорошо ```text Метрика показывает рост ошибок. Трасса находит медленный вызов. Лог объясняет событие. ``` ## Почему Сигналы дополняют друг друга, но их объём и стоимость нужно ограничивать. ## Когда применять Набор сигналов соразмерен системе. Не используйте user_id или полный URL как неограниченные метки метрик. ## Как проверить - Есть ли контроль числа ошибок, задержек и потерь телеметрии? ## Человек Выбирает вопросы, на которые должны отвечать логи, метрики и трассы. ## Агент Готовит воспроизводимые команды, проверяет состояние сервисов и прикладывает фактический результат. Контроль результата: - Есть ли контроль числа ошибок, задержек и потерь телеметрии? ## Источники - [Signals](https://opentelemetry.io/docs/concepts/signals/) - [Metric and label naming](https://prometheus.io/docs/practices/naming/) Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/observability/three-signals/rules/signals.md) --- # SLO и error budget ## Коротко Определите, что считается успешным обслуживанием пользователя и за какой период. ## Плохо ```text API должен быть быстрым всегда. ``` ## Хорошо ```text 99.9% чтений успешны за 30 дней. Порог задержки задан для выбранного сценария. ``` ## Почему Без показателя невозможно определить ухудшение и приоритет работы. ## Когда применять Числа — пример. Цель выбирается по потребностям продукта; p95 300ms не универсальное требование. ## Как проверить - Есть ли источник измерений, окно и действия при нарушении? ## Человек Определяет ожидаемую надёжность и правила расходования бюджета ошибок. ## Агент Готовит воспроизводимые команды, проверяет состояние сервисов и прикладывает фактический результат. Контроль результата: - Есть ли источник измерений, окно и действия при нарушении? ## Источники - [Google SRE - Defining slo: service level objective meaning](https://sre.google/sre-book/service-level-objectives/) Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/observability/three-signals/rules/slo.md) --- # Неизменяемый артефакт ## Коротко Одна версия должна связывать исходники, сборку и работающий сервис. ## Плохо ```text Редактировать файлы прямо в текущем production-каталоге. ``` ## Хорошо ```text Собрать commit → проверить → установить новый релиз → переключить после health check. ``` ## Почему Изменяемый каталог затрудняет воспроизведение и возврат. ## Когда применять Для небольшого приложения процедура может быть простой, но версия и проверка результата остаются явными. ## Как проверить - Работающий релиз соответствует проверенному коммиту? ## Человек Согласует версию и окружение выпуска. ## Агент Готовит воспроизводимые команды, проверяет состояние сервисов и прикладывает фактический результат. Контроль результата: - Работающий релиз соответствует проверенному коммиту? ## Источники - [SLSA • SLSA specification](https://slsa.dev/spec/v1.2/) Уровень: Обязательно. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/delivery/release/rules/immutable-release.md) --- # Rollback ## Коротко До переключения определите, как вернуть сервис и что произойдёт с данными. ## Плохо ```text Ошибка после выпуска → ищем старую сборку. ``` ## Хорошо ```text Старый релиз сохранён. Новая схема совместима. Возврат проверен заранее. ``` ## Почему Быстрый откат кода бесполезен, если старая версия не понимает новую схему. ## Когда применять Не откатывайте миграцию с потерей данных автоматически. Иногда нужен исправляющий релиз. ## Как проверить - Старый код запускается на новой схеме? ## Человек Определяет признаки неудачного выпуска и допустимый способ возврата. ## Агент Готовит воспроизводимые команды, проверяет состояние сервисов и прикладывает фактический результат. Контроль результата: - Старый код запускается на новой схеме? ## Источники - [Google SRE - Canary Release: Deployment Safety and Efficiency](https://sre.google/workbook/canarying-releases/) Уровень: Обязательно. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/delivery/release/rules/rollback.md) --- # Backup и restore ## Коротко Резервная копия полезна, если из неё можно восстановить нужные данные за допустимое время. ## Плохо ```text Файл backup существует — значит всё защищено. ``` ## Хорошо ```text Копия восстановлена в отдельной среде. Проверены данные и время восстановления. ``` ## Почему Наличие файла не доказывает целостность копии, доступность ключа и полноту данных. Проверка целостности полезна, а учебное восстановление дополнительно проверяет всю процедуру. ## Когда применять Выберите допустимую потерю данных и время простоя. Для PITR нужны рабочая цепочка WAL и проверенная процедура. ## Как проверить - Когда последний раз успешно восстанавливали копию? ## Человек Задаёт RPO/RTO и принимает результат учебного восстановления. ## Агент Готовит воспроизводимые команды, проверяет состояние сервисов и прикладывает фактический результат. Контроль результата: - Когда последний раз успешно восстанавливали копию? ## Источники - [PostgreSQL: Documentation: 18: Chapter 25. Backup and Restore](https://www.postgresql.org/docs/18/backup.html) Уровень: Обязательно. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/delivery/release/rules/restore.md) --- # Конфигурация окружения ## Коротко Один модуль конфигурации должен проверять обязательные значения до приёма запросов. ## Плохо ```text Нет ключа → приложение молча использует тестовый. ``` ## Хорошо ```text Отсутствует обязательная настройка → понятная ошибка запуска без раскрытия секрета. ``` ## Почему Тихая подмена настройки создаёт труднообнаружимые ошибки и риск доступа. ## Когда применять Для необязательной функции допустимо явное отключение. Секреты и окружения разделяются. ## Как проверить - Проверьте запуск без ключа и с недопустимым значением. ## Человек Определяет обязательные параметры и владельцев секретов. ## Агент Готовит воспроизводимые команды, проверяет состояние сервисов и прикладывает фактический результат. Контроль результата: - Проверьте запуск без ключа и с недопустимым значением. ## Источники - [The Twelve-Factor App](https://12factor.net/config) - [Secrets Management - OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) Уровень: Обязательно. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/delivery/release/rules/config.md) --- # Incident runbook ## Коротко Дежурный должен знать, как оценить проблему, ограничить последствия и восстановить сервис. ## Плохо ```text Сработал алерт; никто не знает владельца и порядок действий. ``` ## Хорошо ```text Алерт → ответственный → проверка → восстановление. После инцидента — причины и предотвращение. ``` ## Почему Инструкция снижает время поиска решения в стрессовой ситуации. ## Когда применять Ссылки и команды должны быть проверены; в публичной инструкции не размещают секреты. ## Как проверить - Другой участник может выполнить процедуру в тестовой среде? ## Человек Назначает ответственного, порядок связи и приоритет восстановления. ## Агент Готовит воспроизводимые команды, проверяет состояние сервисов и прикладывает фактический результат. Контроль результата: - Другой участник может выполнить процедуру в тестовой среде? ## Источники - [Google SRE - Incident Management: Key to Restore Operations](https://sre.google/sre-book/managing-incidents/) Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/delivery/release/rules/incident.md)