- Cloud
- Perspectives
- Run
Run
Run is about operating cloud with measurable reliability: clear signals, disciplined response, proven recovery, and governance that prevents surprises.
SLO/SLI programme
Incident discipline (MOIR)
Database health
Lifecycle & performance operations
Tested backup/restore
DR drills
Guardrails
IAM/policy/standards
KPI cadence
Continuous improvement (CSI)
Operating cloud with confidence
Measurable reliability through disciplined operations and proven recovery capabilities
Lower MTTR and fewer repeat incidents
Less alert noise, higher operator efficiency
Proven recovery (not 'backup exists')
Reduced database risk and performance regression
Governance that stabilises cost and risk
Clear KPIs and an operating rhythm
What you get
Comprehensive deliverables that make reliability measurable and repeatable
Run deliverables pack
- SLO/SLI definitions + dashboards (where applicable)
- Alert quality improvements (routing, severity, deduplication)
- Incident playbooks + runbook library
- Database health checks + lifecycle plan
- DR plan + drill cadence + evidence outputs
- KPI pack: MTTR/MTTD, incident rate, recovery time, backup success
- CSI backlog for ongoing improvements
Run operating model
Integrated service framework for reliable cloud operations
Run service catalogue
Comprehensive operational services for reliable cloud environments
SRV-005
Cloud Environment Management
Guardrails, standards and governance that prevent configuration drift, control costs, and maintain security posture
IAM policy enforcement + least privilege
Resource tagging + cost allocation
Compliance framework alignment
SRV-006
DevOps Management
Controlled change and operational discipline through automation, quality gates, and deployment best practices
CI/CD pipeline management
Change approval workflows
Progressive delivery strategies
SRV-007
Database Management
Database health, performance and lifecycle operations that prevent regression and ensure optimal data layer performance
Health checks + performance monitoring
Query optimisation + indexing
Capacity planning + scaling
SRV-008
Observability & Incident Response (MOIR)
SLOs, alert quality and incident response with comprehensive monitoring, structured response, and continuous improvement
SLO/SLI definition + dashboards
Alert routing + on-call management
Incident playbooks + postmortems
SRV-009
Backup & DR Management
Tested recovery and RTO/RPO assurance through regular drills, documented procedures, and validated restore capabilities
Automated backup verification
Regular DR drill execution
RTO/RPO validation + reporting
Run excellence pathways
Strategic service combinations for comprehensive operational excellence
Run Excellence Pack
SRV-008 Monitoring & Observability & Incident Response (MOIR)
SRV-007 Database Management
SRV-009 Backup & Disaster Recovery Management
Governance + Cost Control
SRV-005 Cloud Environment Management
SRV-012 FinOps Assessment
Release → Reliability loop
SRV-015 CI/CD DevOps & Software Delivery Modernisation
SRV-008 Monitoring & Observability & Incident Response (MOIR)
Run resources & templates
Download operational playbooks, templates, and checklists
Incident playbook + postmortem templates
DR runbook + drill plan templates
Database health check checklist
Run FAQ
Common questions about operational reliability and cloud run practices
How do we choose the first SLOs?
Start with customer-facing services and focus on availability and latency as foundational metrics. Choose 2-3 critical user journeys and define SLOs based on actual user experience rather than infrastructure metrics. Use the 99.9% availability baseline as starting point and adjust based on business requirements and current performance. Our SLO/SLI starter kit provides templates for common service types including web applications, APIs, and batch processes with recommended thresholds and error budget policies.
What does a practical on-call model look like?
Effective on-call requires clear escalation paths, reasonable rotation schedules (typically 1 week), and protection against alert fatigue. Implement primary/secondary on-call with defined handoff procedures. Ensure runbooks exist for common incidents and escalation to subject matter experts is documented. Measure on-call health through metrics like pages per shift, time to acknowledge, and incidents requiring escalation. Our incident playbook includes on-call rotation templates, escalation matrices, and alert fatigue reduction strategies.
How should DR drills be structured?
DR drills should be scheduled quarterly with progressive complexity. Start with component-level recovery (single database restore), progress to service-level failover, and culminate in full environment recovery. Document actual RTO/RPO achieved, identify gaps, and update runbooks based on findings. Include communication protocols, stakeholder notifications, and success criteria validation. Treat drills as learning opportunities not pass/fail tests. Our DR drill plan template provides scheduling frameworks, execution checklists, and evidence documentation formats.
How often should we test database restores?
Critical databases require monthly restore testing while less critical systems can be tested quarterly. Automated validation should verify backup completion daily. Restore tests should include data integrity verification, performance validation, and application connectivity checks. Document restore times to validate RTO commitments. For large databases, implement point-in-time recovery testing and transaction log restore validation. Our database health check includes restore testing procedures, validation scripts, and documentation templates.
What's the first step in governance?
Begin with IAM policy audit and least privilege enforcement. Identify over-permissioned accounts, implement role-based access control, and enable MFA across all privileged accounts. Establish resource tagging standards for cost allocation and compliance tracking. Implement policy-as-code using cloud-native tools (AWS SCPs, Azure Policy, GCP Organisation Policies) to prevent drift. Our cloud guardrails checklist provides prioritised governance controls with implementation guides and validation procedures for immediate value.
Which KPIs matter most for reliability?
Focus on four golden signals: MTTR (mean time to resolution), MTTD (mean time to detection), incident rate per service, and SLO attainment percentage. Secondary metrics include change failure rate, deployment frequency, and recovery time actual vs target. Track alert quality through actionable alert percentage and false positive rate. For databases, monitor query performance trends and capacity utilisation. Our KPI pack includes dashboard templates, collection procedures, and trend analysis frameworks for comprehensive reliability visibility.
Make reliability measurable
In 15 minutes, we’ll define the best Run path for your environment.