Runbooks и support

Runbook описывает конкретное безопасное действие оператора. Архитектурное описание объясняет устройство системы, но не заменяет пошаговую процедуру восстановления.

Обязательные runbooks

• WSO2 unavailable/degraded;
• database connectivity failure;
• Kafka producer/consumer failure и high lag;
• stuck/failed Kestra execution;
• adapter cannot reach target system;
• callback retries/DLT growth;
• certificate expiration/rotation;
• deployment rollback;
• DLQ investigation и controlled replay;
• backup restore;
• credential compromise/rotation.

Шаблон runbook

Название:
Когда применять:
Не применять, если:
Риск и возможное влияние:
Необходимые роли/доступы:

Диагностика:
1.
2.

Процедура:
1.
2.

Проверка результата:
1.
2.

Rollback / recovery:
Escalation:
Evidence to attach:
Owner:
Last tested:

Качество runbook

Runbook должен:

• иметь одного owner;
• использовать точные component/environment names;
• содержать preconditions и stop conditions;
• объяснять риск destructive/replay действий;
• завершаться проверкой результата;
• иметь rollback или escalation;
• регулярно проходить tabletop или практический тест.

Support request

Минимальные данные:

• environment;
• Consumer/application;
• API, version и operation;
• время с timezone;
• impact;
• HTTP/error category;
• External Request ID и trace ID;
• последние изменения;
• безопасные evidence links.

Secrets и чувствительный payload не прикладываются.

Escalation model

Фактические контакты и каналы должны храниться в контролируемом service registry, а не копироваться на множество страниц.

Handover checklist

• architecture и dependencies переданы;
• dashboards/alerts доступны;
• access matrix актуальна;
• runbooks протестированы;
• backup/restore подтверждён;
• support schedule и contacts определены;
• known limitations и open risks зафиксированы.