HOW THE WORK
ACTUALLY RUNS.
Delivery, support, escalation, change management
and recovery — documented before they're needed.
THE OPERATING MODEL
Understand the problem, constraints and desired outcome.
↓Define the architecture, delivery approach and responsibilities.
↓Build, test and release against the agreed scope.
↓Monitor, support and continuously improve.
↓Measure outcomes, risks and required changes.
SERVICE OPERATIONS
What happens when the system
is already in production?
SERVICE COMMITMENTS
| SERVICE TIER | RESPONSE | AVAILABILITY |
|---|---|---|
| STANDARD | [DEFINED] | [DEFINED] |
| PRIORITY | [DEFINED] | [DEFINED] |
| CRITICAL | [DEFINED] | [DEFINED] |
WHEN SOMETHING BREAKS
The escalation path should not depend on
finding the right person at the right moment.
RECOVERY
RTO
RECOVERY TIME OBJECTIVEHow quickly the service is expected
to be restored.
RPO
RECOVERY POINT OBJECTIVEHow much data loss is acceptable
within the defined recovery model.
CHANGE MANAGEMENT
NOT EVERY CHANGE IS A
TECHNICAL DECISION.
Some changes affect:
- cost
- risk
- reliability
- delivery timelines
- client commitments
So changes are evaluated as business decisions,
not simply implementation tasks.
RUNBOOK LIBRARY
HEALTH MONITORING
WE WATCH THE SYSTEMS
THAT MATTER.
Operational monitoring provides visibility
into system health, service degradation
and incidents.
OPERATIONAL DOCUMENTS
OPERATIONS SHOULD NOT DEPEND
ON HEROICS.
If the process only works when the right person
happens to be online, the process isn't finished.