Runbook

Internal operations guide for BANA - for developers, ops/SRE, and support staff. The deep mechanics live under Infrastructure; this runbook is the "what to do now" layer on top.

Internal use only

Operational procedures, incident playbooks, and support workflows. Do not share outside the NEXPANDO team.

Sections

Section	Purpose	Primary audience
Deployment	Deploy, roll back, run migrations	Dev, Ops
Operations	Day-to-day checks: services, queues, DB, cache, logs	Ops, On-call
Incidents	Triage + playbooks for outages	On-call, Ops
Support	Customer triage and common fixes	Support

Severity & on-call

Severity	Meaning	Response target	Path
S0	Full outage - API down, DB lost, payments failing globally	acknowledge ≤ 15 min, all-hands	On-call → Incident Commander → Eng lead
S1	Major degradation - one service down, high error rate	ack ≤ 30 min	On-call → service owner
S2	Minor - one feature degraded, no money impact	next business day	service owner
S3	Cosmetic	backlog	-

Escalation: On-call engineer → Incident Commander (rotating) → Engineering lead → CTO.

The on-call rotation, pager and IC roster are owned by the team and tracked outside the wiki (no contacts in the repo). Link the tool here once chosen.

Service levels (proposed - to ratify)

Proposed, not committed

BANA has no ratified internal SLOs yet. The targets below are a starting proposal for the team to agree - not commitments.

Target	Proposed	Notes
API availability	99.5% / month	excludes planned maintenance
Latency (p95)	< 500 ms	core read/write paths
RTO (recovery time)	≤ 1 hour	restore service after S0
RPO (data loss)	≤ 15 min	DB backup cadence must meet this

Conventions

• Severity - S0/S1/S2/S3 (above). Commands are copy-pasteable; placeholders use <angle-brackets>.
• Keep entries short and recipe-style; link to Infrastructure for depth.