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 can support accountability; neither reporting nor internal billing guarantees better behavior. 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 recovery points alone are inadequate. Consistent backups, transaction-log recovery or replication can be evaluated against the target; continuous cross-region replication is not the only possible design. The RTO of four hours sets the recovery design: a tested recovery path within four hours. A cold rebuild taking two days fails, but a sufficiently fast cold or warm design could meet the requirement. 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; check your own contract and exclusions rather than assuming that the provider’s outage automatically excuses the commitment.