Перейти к основному содержимому

Observability And Incident Response — Наблюдаемость и реагирование на инциденты

Версия: 1.0
Дата: 24.04.2026
Статус: Готов к обсуждению

Назначение документа​

Этот документ фиксирует execution-level подход к observability, incident response, diagnostics, triage, recovery и operator workflows в платформе vitrip.store.

Его задача — определить:

  • что именно платформа должна уметь наблюдать как industrial system;
  • как telemetry должна отражать реальную доменную жизнь, а не только состояние инфраструктуры;
  • какие классы инцидентов обязательны для платформы;
  • как должны работать detection, triage, escalation, containment, recovery и post-incident analysis;
  • как observability должна быть связана с supplier, ingestion, quote, booking, settlement, governance и surface delivery контурами.

Этот документ не сводится к выбору monitoring stack. Он фиксирует операционную модель наблюдаемости и реагирования, поверх которой уже потом выбираются инструменты.

Технологический baseline для самих инструментов описан отдельно в Observability Tooling Baseline — Технологический baseline наблюдаемости, трассировки и операционной диагностики.

Опорные документы​

Почему Этот Документ Нужен Отдельно​

После фиксации deployment и settlement-and-reconciliation уже нельзя считать observability тонким приложением к infra-stack.

Платформа должна уметь наблюдать не только:

  • CPU;
  • память;
  • latency;
  • error rate;

но и:

  • supplier degradation;
  • ingestion lag and replay pressure;
  • quote validity erosion;
  • repricing surge;
  • booking unknown external state;
  • publication holds;
  • reconciliation queue growth;
  • operator overload and unresolved discrepancy aging.

Без отдельного execution-документа всё это рискует раствориться между:

  • DevOps monitoring;
  • support ручными проверками;
  • случайными логами в сервисах;
  • поздними finance/review сигналами.

Главный Принцип Observability​

Платформа должна быть наблюдаема по доменной цепочке, а не только по инфраструктурным симптомам.

Ключевой принцип:

оператор должен иметь возможность пройти путь от внешнего сигнала или жалобы до точного состояния platform reality без ручной археологии по несвязанным системам.

Из этого следуют обязательные выводы:

  • telemetry должна быть коррелируема across contours;
  • incident triage должен опираться на domain signals, а не только на HTTP 500;
  • logs, metrics, traces and queues должны быть связаны общей operational model;
  • observability должна быть surface-aware, tenant-aware и supplier-aware там, где это допустимо и безопасно.

What Observability Must Answer​

Система наблюдаемости должна отвечать как минимум на следующие вопросы:

  1. Пришёл ли supplier signal и был ли он обработан корректно?
  2. Где в цепочке застрял ingestion case?
  3. Был ли affected offer/quote/bookings path пересчитан или заблокирован?
  4. Произошёл ли repricing и кто его увидел?
  5. Находится ли booking в confirmed, pending, unknown or degraded state?
  6. Возникли ли settlement or reconciliation consequences?
  7. Видит ли агент, партнёр или B2C surface честную реальность, а не stale projection?
  8. Какой operator action сейчас нужен и кто owner?

Observability Layers​

Платформа должна иметь несколько взаимосвязанных уровней наблюдаемости.

1. Infrastructure Observability​

Наблюдает:

  • runtime health;
  • resource saturation;
  • storage pressure;
  • queue backing services;
  • network and dependency failures.

Это необходимо, но недостаточно.

2. Service Execution Observability​

Наблюдает:

  • throughput;
  • latency;
  • retries;
  • idempotency results;
  • internal error classes;
  • async job progress;
  • state-transition success/failure.

3. Domain Observability​

Наблюдает:

  • supplier freshness drift;
  • offer/quote lifecycle;
  • repricing reasons;
  • booking state transitions;
  • unknown external state;
  • publication holds;
  • governance queue pressure;
  • reconciliation and discrepancy state.

4. Surface Observability​

Наблюдает:

  • partner API degradation;
  • agency workflow friction;
  • B2C stale/pending exposures;
  • proposal publication issues;
  • actor-visible mismatch between expected and actual platform state.

5. Operational Queue Observability​

Наблюдает:

  • review queues;
  • exception queues;
  • booking recovery queues;
  • reconciliation queues;
  • aging, ownership and backlog risk.

Correlation Model​

Без корреляции observability превращается в набор красивых, но бесполезных dashboard-ов.

Платформа Должна Уметь Коррелировать​

  • supplier identity;
  • ingest run / payload / trace id;
  • canonical entity ids;
  • offer id;
  • quote id;
  • booking id;
  • settlement event id;
  • actor / tenant / workspace context where allowed;
  • surface identity;
  • incident / case / queue item id.

Минимальная Практическая Цепочка​

supplier signal
  → ingestion trace
  → canonical update
  → offer / quote impact
  → booking consequence
  → settlement consequence
  → operator action

Если хотя бы одна из этих связей невидима, incident response резко деградирует.

Telemetry Classes​

Metrics​

Нужны для:

  • volume;
  • latency;
  • rates;
  • backlog;
  • saturation;
  • threshold-based detection.

Structured Logs​

Нужны для:

  • exact execution narrative;
  • error context;
  • retry and idempotency explanation;
  • state-transition detail.

Distributed Traces​

Нужны для:

  • cross-service flow visibility;
  • latency breakdown;
  • async/sync boundary analysis;
  • booking and quote path investigation.

Operational Events​

Нужны для:

  • domain-significant transitions;
  • audit-grade state changes;
  • operator-relevant lifecycle milestones.

Queue State​

Нужна как first-class telemetry, а не как hidden implementation detail.

Потому что для этой платформы queue growth often is the incident.

Core Domain Signals​

Supplier And Ingestion Signals​

  • supplier sync lag;
  • intake success/failure rate;
  • normalization error rate;
  • replay volume;
  • quarantine rate;
  • mapping ambiguity rate;
  • publication gating count;
  • supplier degradation classification.

Offer / Quote / Commercial Signals​

  • offer freshness erosion;
  • quote creation volume;
  • quote expiry rate;
  • revalidation-required rate;
  • repricing rate;
  • repricing reason distribution;
  • blocked publication due to commercial inconsistency;
  • surface-specific price-view divergence where expected.

Booking Signals​

  • booking submission rate;
  • confirmation latency;
  • pending_supplier_confirmation volume;
  • unknown_external_state count;
  • cancellation failure rate;
  • amendment in-progress aging;
  • duplicate submission handling outcomes.

Settlement And Reconciliation Signals​

  • unreconciled booking count;
  • quote-to-booking mismatch rate;
  • supplier payable mismatch rate;
  • refund queue aging;
  • amendment delta discrepancy rate;
  • settlement event generation lag;
  • reconciliation closure time.

Governance And Review Signals​

  • review queue growth;
  • anomaly severity distribution;
  • manual lock count;
  • unresolved conflict age;
  • governance-induced publication holds.

Incident Classes​

Платформа должна различать incident classes по domain impact, а не только по severity badge.

1. Supplier Degradation Incident​

Примеры:

  • supplier timeouts;
  • stale pricing feed;
  • broken webhook stream;
  • malformed payload wave.

2. Ingestion Integrity Incident​

Примеры:

  • replay storm;
  • matching regression;
  • canonical update block;
  • abnormal publication gating surge.

3. Offer / Quote Incident​

Примеры:

  • quote creation failure;
  • repricing spike;
  • quote invalidation wave;
  • stale but published offer slice.

4. Booking Lifecycle Incident​

Примеры:

  • pending confirmations surge;
  • unknown external state accumulation;
  • cancellation path breakage;
  • amendment deadlock.

5. Surface Contract Incident​

Примеры:

  • partner API semantic break;
  • agency-visible stale quote state;
  • B2C false finality;
  • proposal publication inconsistency.

6. Settlement / Reconciliation Incident​

Примеры:

  • settlement event lag;
  • mismatch burst;
  • refund reversal failure;
  • reconciliation backlog beyond threshold.

7. Cross-Contour Incident​

Самые опасные инциденты, когда проблема проходит сразу через несколько слоёв:

  • supplier drift → repricing wave → agency disruption;
  • booking confirmation delay → settlement lag → support overload;
  • governance hold → publication gap → partner-facing inconsistency.

Incident Severity Model​

Severity должна учитывать не только technical availability, но и business impact.

Severity Drivers​

  • affected truth class;
  • affected surface;
  • affected actor type;
  • affected financial risk;
  • recoverability complexity;
  • blast radius;
  • presence of false finality or wrong promise to external actor.

Example Severity Interpretation​

Sev 1​

  • booking confirmations corrupted;
  • external false confirmations;
  • severe settlement corruption;
  • large-scale partner-visible wrong price promise.

Sev 2​

  • major quote/repricing disruption;
  • supplier degradation affecting booking viability;
  • reconciliation queue explosion with business impact.

Sev 3​

  • degraded internal tooling;
  • localized ingestion issues;
  • bounded surface-specific inconsistency.

Sev 4​

  • non-critical observability defect;
  • low-impact dashboard gap;
  • contained noise without active business harm.

Detection Model​

Automatic Detection​

Подходит для:

  • infra saturation;
  • latency spikes;
  • queue thresholds;
  • error-rate anomalies;
  • supplier lag thresholds;
  • settlement lag thresholds.

Rule-Based Domain Detection​

Подходит для:

  • quote expiry spikes;
  • repricing waves;
  • unknown booking state growth;
  • refund backlog aging;
  • publication hold surges.

Human Detection​

Подходит для:

  • support-reported semantic mismatch;
  • partner complaint;
  • agency-visible commercial inconsistency;
  • finance-reported reconciliation anomaly.

Практический Вывод​

Платформа должна уметь превращать human-detected incidents в fully traceable operational cases, а не только в чат-сообщения и ручные расспросы.

Triage Model​

При любом инциденте должны быть быстро определены:

  • affected contour;
  • affected truth class;
  • affected surface;
  • current blast radius;
  • whether publication hold is needed;
  • whether reconciliation hold is needed;
  • primary owner;
  • next safe action.

First Triage Questions​

  1. Это supplier, ingestion, quote, booking, settlement или surface issue?
  2. Есть ли ложное внешнее обещание?
  3. Можно ли безопасно продолжать create / confirm / publish actions?
  4. Нужно ли остановить publication or booking flow?
  5. Есть ли recovery by replay, or manual action required?

Containment Strategies​

Платформа должна иметь ограничительные действия, которые уменьшают blast radius.

Возможные Containment Actions​

  • hold supplier source;
  • hold publication for affected offers/quotes;
  • force revalidation requirement;
  • disable risky surface action;
  • pause partner-facing mutation path;
  • route bookings into manual review;
  • hold settlement finalization for affected cohort.

Recovery Strategies​

Replay​

Подходит для:

  • ingestion errors;
  • missed supplier events;
  • derived projection rebuild.

Revalidation / Repricing​

Подходит для:

  • stale quote path;
  • supplier drift;
  • invalid visible price state.

Manual Operational Resolution​

Подходит для:

  • unknown external state;
  • supplier dispute;
  • financial discrepancy;
  • policy override decision.

Correction Event​

Подходит для:

  • settlement adjustments;
  • reversal posting;
  • late reconciliation correction.

Incident Playbook Structure​

Для каждого серьёзного incident class должен существовать playbook с одинаковой структурой:

  1. signal sources
  2. likely contours involved
  3. blast radius assessment
  4. safe immediate actions
  5. telemetry and traces to inspect
  6. containment options
  7. recovery paths
  8. communication obligations
  9. closure criteria
  10. post-incident follow-up

Operator Surfaces​

Observability не должна жить только в dashboards.

Платформе нужны operator-facing surfaces для:

  • booking investigation;
  • quote and repricing investigation;
  • supplier degradation view;
  • ingestion replay and quarantine view;
  • settlement discrepancy triage;
  • publication hold management;
  • case ownership and aging.

Communication Model​

Incident response должен учитывать разные аудиенции.

Internal Engineering Communication​

Нужна для:

  • root cause investigation;
  • rollback or fix coordination;
  • telemetry interpretation.

Operations Communication​

Нужна для:

  • queue ownership;
  • manual action coordination;
  • supplier escalation.

Surface Communication​

Нужна, когда incident affects:

  • agency users;
  • partners;
  • end customers.

Finance / Reconciliation Communication​

Нужна, когда incident affects:

  • payable/receivable assumptions;
  • refund timing;
  • discrepancy closure.

Post-Incident Analysis​

Каждый серьёзный инцидент должен заканчиваться не только closed status, но и architecture feedback.

Post-Incident Review Должен Ответить​

  • где detection была слишком поздней;
  • где correlation chain была недостаточной;
  • какой truth class оказался незащищён;
  • какие surface promises были unsafe;
  • какие new metrics, alerts or playbooks нужны;
  • требует ли проблема updates в reference or operations docs.

Relationship To Other Operations Documents​

Этот документ дополняет:

Вместе они образуют execution-baseline:

  • deployment отвечает за runtime and rollout discipline;
  • settlement-and-reconciliation отвечает за finance-grade operational truth;
  • observability-and-incident-response отвечает за detection, triage, recovery and operator control.

What This Document Requires Next​

После фиксации этого документа следующий логичный operations layer:

  • operations/release-engineering-and-migrations.md

если проекту понадобится отдельная жёсткая фиксация rollout and migration execution discipline.

Текущий Практический Вывод​

Платформа vitrip.store должна быть наблюдаема не как “набор сервисов в кластере”, а как сквозная operational system, где можно:

  • увидеть supplier change;
  • понять его canonical and operational consequence;
  • проследить impact на quote, booking and settlement;
  • быстро определить owner, containment and recovery path;
  • не допустить ложной внешней финальности.

Именно это отделяет industrial platform operations от просто “есть логи, графики и алерты”.

Уточнение под Фазы 5–6 (28.04.2026) — углубление через runbooks, SLA, DR/capacity​

Документ опубликован 24.04.2026 в Фазе 3 как baseline observability и incident response. После Фаз 5–6 (25–27.04.2026) опубликованы специализированные документы, которые углубляют этот baseline до production-capable уровня. Эта секция фиксирует обязательные связи.

Углубление через каноничные runbooks (Фаза 6)​

operations/runbooks-incident-playbooks.md — каноничные 8 incident classes с детальными процедурами:

  1. Supplier degradation;
  2. Stale offer state;
  3. Quote repricing surge;
  4. Booking timeout / unknown_external_state;
  5. Cache invalidation failure;
  6. Governance queue overload;
  7. Delayed settlement event generation;
  8. Broken publication pipeline.

Этот документ описывает общие принципы incident management; runbooks-incident-playbooks — конкретные процедуры per incident class. При работе с инцидентом — использовать каноничные runbooks как авторитетный источник; этот документ остаётся как philosophical baseline.

Углубление через SLA-модель и on-call structure (Фаза 6)​

operations/sla-and-on-call-model.md — каноничная модель:

  • 5-уровневая on-call структура (Primary → Secondary → Engineering Manager → Director/VP → CTO/CISO);
  • 10 каноничных SLI metrics (availability, latency p95, webhook delivery, search freshness, booking confirmation, unknown_external_state ratio, payment success, restoration success, MTTR, support response time);
  • 4 SLA tier (Free best-effort / Starter 95% / Professional 99% / Enterprise 99.9%);
  • Service credits при breach (5%/10%/25%/50% от месячной подписки);
  • Burnout protection — не более 1 недели on-call per engineer per 4-8 weeks.

Severity levels этого документа (Critical / High / Medium / Low) — согласуются с tier-зависимыми SLA в sla-and-on-call-model. Каноничный source-of-truth для SLA — sla-and-on-call-model.

Углубление через DR и capacity (Фаза 6)​

operations/disaster-recovery-and-capacity.md — каноничные:

  • 4 recovery tiers (Tier 1: RTO 60м/RPO 5м для платежей и бронирований; Tier 2: RTO 4ч/RPO 30м; Tier 3: RTO 24ч/RPO 1ч; Tier 4: RTO 7д для archived);
  • 5-шаговая процедура восстановления (declared → point selected → restored to staging → smoke tests → promoted to production);
  • 5 типов DR-учений (backup_verify / partial_restore / full_restore / region_failover / chaos_drill);
  • Capacity planning процесс с peak load forecasting и auto-scaling integration.

DR runbooks — отдельный класс runbook'ов, координируется через runbooks-incident-playbooks.

Связь с booking state machine​

reference/booking-state-machine.md (Фаза 5) — каноничные 14 состояний. Особо важно для observability:

  • unknown_external_state — отдельная metric, target SLI менее 1% (см. sla-and-on-call-model.md SLI 6);
  • state transition latency — measured per state (например, pending_supplier_confirmation → supplier_confirmed p95 latency);
  • state distribution dashboard — для on-call visibility;
  • alert rules per state (например, alert при увеличении unknown_external_state > 1%).

Связь с tenant isolation и security audit​

reference/multi-tenant-isolation-strength.md (Фаза 5) — IsolationBoundaryCheck continuous events требуют:

  • отдельный alert channel при breach detection;
  • escalation в CISO / Compliance officer (фаза 4+);
  • security incident runbook (см. security-architecture.md).

reference/security-architecture.md — caнoничный audit log как отдельный observability stream:

  • correlation observability traces с audit events;
  • separate retention (7 лет для security audit vs operational metrics);
  • access controls для audit log queries.

Каноничный итог уточнения​

Этот документ остаётся философским baseline observability и incident management. Конкретные реализации:

Уточнение выполнено через no-destruction.