# Operational Excellence

> Assess a workload's operational excellence posture by analyzing CI/CD pipelines, observability instrumentation, deployment configs, and incident management patterns in the codebase to produce evidence-backed findings.

- **Type:** Skill
- **Install:** `agentstack add skill-aws-samples-sample-well-architected-skills-and-steering-operational-excellence`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [aws-samples](https://agentstack.voostack.com/s/aws-samples)
- **Installs:** 0
- **Category:** [Cloud & Infrastructure](https://agentstack.voostack.com/c/cloud-infrastructure)
- **Latest version:** 0.1.0
- **License:** MIT-0
- **Upstream author:** [aws-samples](https://github.com/aws-samples)
- **Source:** https://github.com/aws-samples/sample-well-architected-skills-and-steering/tree/main/skills/operational-excellence
- **Website:** https://aws.amazon.com/architecture/well-architected/

## Install

```sh
agentstack add skill-aws-samples-sample-well-architected-skills-and-steering-operational-excellence
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Operational Excellence Assessment

## Step 1: Gather context

Ask the user:

> What workload or environment would you like me to assess for operational excellence? Please share:
> - **Workload name** and brief description
> - **Code packages/directories** to analyze (CI/CD configs, IaC, application code)
> - **Known operational pain points** (optional — alert fatigue, slow deployments, etc.)

If the user has already provided details or you are in a codebase, skip the prompt and proceed with discovery.

## Step 2: CI/CD and Deployment Discovery

Analyze all CI/CD and deployment configurations in the codebase.

You MUST examine:
- Pipeline definitions (CodePipeline, GitHub Actions, Jenkins, GitLab CI, CDK Pipelines)
- Deployment configurations (CodeDeploy, ECS deployment, Lambda aliases, Apollo)
- Build configurations (buildspec.yml, Makefile, package.json scripts)
- Testing configurations (unit, integration, e2e test setups)
- Pre-deployment gates (approval stages, quality gates, security scans)

For each pipeline/deployment, document:
- File path and line numbers
- Stages and their purpose
- Deployment strategy (canary, blue/green, rolling, all-at-once)
- Rollback mechanism (automatic on alarm, manual, none)
- Test coverage gates
- Artifact promotion flow

You MUST flag:
- All-at-once deployments to production without health check gating
- No rollback mechanism configured
- No automated testing in the pipeline
- Manual steps in an otherwise automated pipeline

## Step 3: Observability Discovery

Analyze all monitoring and observability configurations.

You MUST examine:
- CloudWatch alarm definitions (in IaC or config files)
- Dashboard definitions (CloudWatch dashboard JSON, Grafana configs)
- Log configurations (log groups, retention, structured logging libraries)
- Tracing configurations (X-Ray, OpenTelemetry, Jaeger)
- Custom metric publishing (CloudWatch PutMetricData, StatsD, embedded metrics)
- Synthetic canaries (CloudWatch Synthetics)
- Application-level logging (structured logging, correlation IDs, log levels)

For each observability component, document:
- What it monitors and why
- File path and line numbers
- Gaps in coverage (services without alarms, flows without tracing)

You MUST flag:
- Services or Lambda functions with no CloudWatch alarms
- Missing distributed tracing across service boundaries
- Unstructured logging (no JSON, no correlation IDs)
- No custom metrics for business-critical operations
- Log retention set to "never expire" without justification
- No synthetic canaries for critical user journeys

## Step 4: Incident and Event Management Discovery

Analyze incident response and event management configurations.

You MUST examine:
- Alert routing (SNS topics, PagerDuty/OpsGenie integrations, EventBridge rules)
- Automated remediation (Lambda functions triggered by alarms, SSM Automation)
- Runbooks and playbooks (SSM documents, markdown runbooks, Step Functions)
- Escalation configurations
- Health check implementations (ALB health checks, Route 53, custom endpoints)

---STOP---
**Checkpoint**: Discovery complete — ready to evaluate against WA Framework

> Discovered CI/CD pipelines ({X} pipeline definitions), observability configurations ({Y} alarm/dashboard/tracing setups), and incident management patterns across {packages analyzed}. Deployment strategies, rollback mechanisms, and monitoring gaps documented.
>
> **Shall I proceed with evaluating these findings against the WA Operational Excellence pillar questions and assessing risk levels?**

Do NOT proceed past this point until the user explicitly confirms.
---

## Step 5: Evaluate against WA Framework questions

For each question, provide: **Status**, **Evidence** (file:line), **Gaps**, **Risk**.

### OPS 1 — How do you determine what your priorities are?
- Look for: SLO/SLI definitions, business metric dashboards, health check endpoints
- Evidence: alarm thresholds, dashboard panels showing business metrics, README/docs with SLO targets

### OPS 2 — How do you structure your organization to support your business outcomes?
- Look for: CODEOWNERS files, clear package boundaries, ownership documentation
- Evidence: CODEOWNERS, package.json team fields, README ownership sections

### OPS 3 — How does your organizational culture support your business outcomes?
- Look for: test coverage, PR templates, contributing guides, code review configs
- Evidence: test directories, .github/PULL_REQUEST_TEMPLATE, CONTRIBUTING.md

### OPS 4 — How do you implement observability?
- Look for: structured logging with correlation IDs, distributed tracing, custom metrics, dashboards
- Evidence: logger configurations, X-Ray/OTEL SDK usage, PutMetricData calls, dashboard JSON

### OPS 5 — How do you reduce defects, ease remediation, and improve flow into production?
- Look for: automated testing (unit, integration, e2e), linting, security scanning, staged deployments
- Evidence: test files, ESLint/prettier configs, SAST tool configs, pipeline stage definitions

### OPS 6 — How do you mitigate deployment risks?
- Look for: canary/blue-green deployments, feature flags, automated rollback, deployment alarms
- Evidence: CodeDeploy deployment configs, feature flag SDK imports, rollback alarm ARNs

### OPS 7 — How do you know that you are ready to support a workload?
- Look for: runbooks for known failure modes, pre-deployment checklists, load testing, operational readiness reviews
- Evidence: SSM documents, runbook markdown files, load test scripts, readiness configs

### OPS 8 — How do you understand the health of your workload?
- Look for: composite alarms, health dashboards, dependency health tracking, SLI monitoring
- Evidence: CompositeAlarm constructs, dashboard definitions, health check endpoints

### OPS 9 — How do you understand the health of your operations?
- Look for: DORA metrics tracking, deployment success monitoring, pipeline health dashboards
- Evidence: pipeline metrics, deployment monitoring alarms, operational dashboards

### OPS 10 — How do you manage workload and operations events?
- Look for: EventBridge rules for operational events, automated remediation Lambdas, escalation configs
- Evidence: EventBridge rule definitions, remediation Lambda code, SNS topic subscriptions

## Step 6: Risk Assessment

For each finding, assess using Impact × Likelihood:

**Impact**: Minor (inconvenience, manual workaround exists) | Moderate (delayed detection, extended recovery time) | Severe (undetected outage, no rollback, data loss)

**Likelihood**: Low (requires unusual conditions) | Medium (possible under normal operations) | High (likely to occur during next incident or deployment)

| Impact   | Likelihood | Risk Level |
|----------|------------|------------|
| Severe   | High       | Critical   |
| Severe   | Medium     | High       |
| Severe   | Low        | High       |
| Moderate | High       | High       |
| Moderate | Medium     | Medium     |
| Moderate | Low        | Medium     |
| Minor    | High       | Medium     |
| Minor    | Medium     | Low        |
| Minor    | Low        | Low        |

## Step 7: Produce the assessment

```markdown
# Operational Excellence Assessment: {Workload Name}

## Executive Summary
- **Date**: {date}
- **Packages Analyzed**: {list}
- **Findings**: {X} Critical, {Y} High, {Z} Medium, {W} Low
- **Overall Maturity**: {1-5} — {one-line justification}

## Maturity Scorecard
| Domain | Score (1-5) | Key Strength | Key Gap |
|--------|-------------|--------------|---------|
| CI/CD & Deployment | {score} | {strength} | {gap} |
| Observability | {score} | {strength} | {gap} |
| Incident Management | {score} | {strength} | {gap} |
| Change Management | {score} | {strength} | {gap} |
| Continuous Improvement | {score} | {strength} | {gap} |

## Critical and High Risk Findings
{For each: ID, domain, title, description, evidence (file:line), impact, recommendation, effort, AWS services}

## Medium Risk Findings
{Same format, condensed}

## Low Risk Findings
{Summary table: ID | Domain | Title | Recommendation}

## Prioritized Remediation Plan

### Quick Wins ( Would you like me to:
> - Deep-dive into CI/CD, observability, or incident response?
> - Generate CloudWatch alarm and dashboard IaC for gaps identified?
> - Create runbooks for specific failure modes?
> - Design a self-healing architecture for a recurring issue?
> - Implement structured logging with correlation IDs?

## Calibration Guidance

- A workload with CI/CD pipelines, automated rollback, CloudWatch alarms, and structured logging is MATURE — focus on advanced improvements (chaos, SLO-based alerting, operational reviews)
- Every finding MUST have code evidence — no generic "you should have monitoring" without checking what exists
- If something cannot be determined from code (e.g., on-call rotation quality, incident review process), mark "Cannot Determine" and explain what information is needed
- Acknowledge existing operational strengths explicitly before listing gaps
- For workloads transitioning architectures, focus on what the NEW architecture introduces as operational requirements

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [aws-samples](https://github.com/aws-samples)
- **Source:** [aws-samples/sample-well-architected-skills-and-steering](https://github.com/aws-samples/sample-well-architected-skills-and-steering)
- **License:** MIT-0
- **Homepage:** https://aws.amazon.com/architecture/well-architected/

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-aws-samples-sample-well-architected-skills-and-steering-operational-excellence
- Seller: https://agentstack.voostack.com/s/aws-samples
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.