Applies toAny production workload on OCI; OCI Well-Architected Framework, Cloud Advisor, Cloud Guard, Security Zones, OCI Monitoring, Cost Analysis, Full Stack DR
Pillars
The OCI Well-Architected Framework groups best practices into pillars along the lines of security and compliance, reliability and resilience, performance and cost optimization, and operational efficiency (check the current framework for exact naming and content). The method below works with any version.
1. Scope
- One workload, its owner and on-call engineers, critical user flows, availability and RTO/RPO targets.
- Compartments, regions and shared dependencies (network hub, identity domain, Vault) in scope.
- Time-box: 1–2 days preparation, a 2–3 hour session, 1 day write-up.
2. Evidence before the session
| Evidence | Source |
|---|---|
| Resource inventory | OCI Search: query all resources where compartmentId = '<ocid>' |
| Architecture diagram (current) | Owner, validated against inventory |
| Security posture | Cloud Guard problems, Security Zones violations, Vulnerability Scanning findings |
| Recommendations | Cloud Advisor (cost, performance, availability, security) |
| Monitoring and alarms | Alarm definitions, notification topics, last 90 days of alarm history |
| Backups / DR | Backup policies, Data Guard status, last DR drill (Full Stack DR plan executions) |
| Cost | Cost Analysis by compartment and service, 6-month trend |
| Incidents | Postmortems from the last 12 months |
oci search resource structured-search --query-text \
"query all resources where compartmentId = '$C'" --query 'data.items[]."resource-type"' --raw-output | sort | uniq -c
3. Questions that find real risks
| Pillar | Questions |
|---|---|
| Security and compliance | Policies broader than manage all-resources? API keys older than 90 days? Public buckets or public IPs on databases? CMKs where required? |
| Reliability and resilience | Single instances in a single fault domain? Data Guard or backups tested? DR plan executed this year? What happens if an AD/FD fails? |
| Performance and cost | Oversized shapes? Idle resources? Autoscaling configured? Load tested at peak? |
| Operational efficiency | Everything in Terraform/Resource Manager? Runbooks for top alarms? Patching via OS Management Hub? Rollback time? |
Answer with evidence. "We plan to" counts as a no.
4. Rate findings
| Rating | Example |
|---|---|
| High | No backup on a production database; single-instance app with no recovery plan; admin API keys shared by a team |
| Medium | Alarms without owners; manual deployments; no restore tests |
| Low | Old shape generation; inconsistent tags |
Each finding: evidence, risk, recommendation, effort, owner.
5. Act on it
- Backlog items in the owning team's tracker with dates for highs.
- Accepted risks signed by the business owner.
- Follow-up check at 30/60/90 days.
- Platform-level themes (seen across workloads) go to the platform team: landing zone updates, modules, policies.
Tip
Bring the person who gets paged. Asking "what scares you about this system at 3 AM?" usually surfaces the top three findings faster than any checklist.
Checklist
- Scope, owner and targets defined
- Evidence gathered (Search, Cloud Guard, Cloud Advisor, alarms, backups, cost)
- Pillar questions answered with evidence
- Findings rated with owners
- Backlog and accepted risks recorded
- Follow-up review scheduled