Cloud Operations and Management
The Cloud Operations and Management domain tests running cloud services day to day: monitoring against service levels, managing capacity and cost, handling incidents and changes, and proving recoverability. It assumes the service is already live and asks how you keep it healthy and affordable.
Service levels and monitoring
Define service level objectives from the business need, monitor from the user's perspective as well as the infrastructure's, and review performance against the SLA in service reviews. Monitoring must cover availability, latency, error rates, saturation and spend, because elasticity can turn a code defect into a large bill within hours.
Capacity and cost governance
Cloud capacity management means matching committed capacity and autoscaling rules to demand, and forecasting growth. Cost governance uses tagging, budgets and alerts, plus showback (reporting consumption to teams) or chargeback (billing them), which is what actually changes behaviour. Automation and orchestration, and practices such as DevOps, keep configuration consistent at scale; frameworks such as ITIL supply the process structure around incidents, problems and changes.
Incidents, changes and recovery
Separate incident management (restore service) from problem management (remove the cause) and change management (control risk). For continuity, define RTO, the maximum acceptable outage, and RPO, the maximum acceptable data loss measured in time. Backup frequency is driven by RPO; standby architecture and failover automation by RTO.
Worked example
A finance system must lose no more than 15 minutes of transactions and be back within four hours. Reasoning: the RPO of 15 minutes sets the backup or replication interval, so hourly snapshots are inadequate and continuous replication to a second region is required. The RTO of four hours sets the recovery design: warm standby with automated failover, not a cold rebuild that takes two days. Cheaper options must be tested against both numbers, and restore must be rehearsed - an untested backup is an assumption.
Traps that cost marks
- Swapping RTO and RPO, which reverses the whole design conclusion.
- Monitoring only servers and never the end-to-end service or the bill.
- Leaving autoscaling uncapped, so a fault becomes a financial incident.
- Assuming a provider outage excuses your own SLA to your customers; your commitment to them stands.