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

Стандарт Управления Инцидентами

Назначение

Стандарт задает единый процесс detection, triage, mitigation, evidence, communication, postmortem и follow-up для production-инцидентов Pin. Он применяется к backend, frontend, integrations, data pipelines, security, finance и operational flows.

Detection

Инцидент может быть найден через alerts, synthetic checks, operator escalation, reconciliation issue, security signal, report discrepancy или manual audit finding. Любой high-impact сигнал получает IncidentId, severity, commander и evidence trail.

Severity

SeverityКритерииПримеры
SEV1Потеря доступности critical path, security breach, нарушение финансовой корректности, риск массовой порчи данныхНеверные проводки, активный exploit, массовая недоступность ключевого API
SEV2Существенная деградация core flow или важной зависимостиНедоступность критичной интеграции, очередь обработки не двигается
SEV3Частичная деградация с workaroundОдин отчет формируется с задержкой, неработает второстепенный batch job
SEV4Low-impact defect или informational incidentНеверный label, minor UI issue, noisy alert

Роли

РольОтветственность
Incident CommanderКоординация, severity, timeline, decisions
Tech LeadДиагностика и mitigation owner
Communications LeadОбновления для заинтересованных сторон
Evidence OwnerСбор immutable evidence, logs, traces, screenshots, refs
Domain OwnerПодтверждение impact и business correctness по своему контуру

Процесс

  1. Открыть incident record с IncidentId, временем, impact и initial severity.
  2. Назначить commander и рабочий канал.
  3. Зафиксировать change freeze для затронутого контура.
  4. Подтвердить customer/business impact без предположений.
  5. Выполнить mitigation: feature flag, circuit breaker, queue pause, fail closed, rollback или forward-fix.
  6. Сохранить evidence до необратимых действий.
  7. Давать регулярные updates по severity cadence.
  8. Закрыть incident только после verification, monitoring window и owner sign-off.

Communication Cadence

SeverityInternal updateStakeholder update
SEV1Каждые 15 минутКаждые 30 минут или при изменении impact
SEV2Каждые 30 минутКаждый час
SEV3Каждый часПо необходимости
SEV4По change logОбычно не требуется

Типовые Классы Инцидентов

ClassОсобые действия
Financial mismatchFreeze affected commands, открыть reconciliation, привлечь domain owner
External integration outageПеревести обработку в degraded mode, включить fallback или manual queue
Queue backlogПроверить consumer lag, throughput, poison messages, retry storm
Permission breachОграничить доступ, сохранить audit, инициировать security review
Data freshness breachПометить affected reports, остановить sensitive exports, восстановить watermarks
Failed deploymentОстановить rollout, оценить rollback/forward-fix plan

Evidence

Evidence package включает timeline, alerts, dashboards, traces, deployment refs, config diffs, affected ids, decisions, approvals и verification results. Для high-risk инцидентов evidence хранится immutable и по least privilege.

Mitigation Rules

  • Не изменять критичные учетные записи и финансовые итоги напрямую.
  • Не скрывать incident путем удаления evidence, logs или audit trail.
  • Не выполнять cross-tenant fix без явного scope и review.
  • Не возвращать зависимость в production path без health check и monitoring window.

Postmortem

Postmortem обязателен для SEV1/SEV2 и для повторяющихся SEV3. Он содержит summary, impact, root cause, contributing factors, detection gaps, timeline, corrective actions, owners, due dates и verification plan.

Follow-Up

Follow-up закрывается только после:

  • merged fix или documented control;
  • обновленных runbooks/dashboards/alerts;
  • выполненной reconciliation или evidence verification;
  • regression/integration test для воспроизводимого дефекта;
  • обновления документации, если изменился contract, policy или boundary.

Обратные ссылки

Автоссылки: где используется этот документ.