Well-Architected Framework: Operational Excellence

This is the final post in the Well-Architected Framework Series I’ve covered over the last 5 weeks, today we focus on the Operational Excellence Pillar.

Delivered on Time. Then the Phone Started Ringing.

A few years ago, I was involved in the delivery of an Azure Virtual Desktop solution. The project hit its milestones, came in on budget, and the business was delighted. Desktops were provisioned, users were onboarded, and the project was signed off as a success.

Then the support calls started coming in.

Users couldn’t connect. Sessions were hanging. Print redirection wasn’t working. The service desk were lost. There were no runbooks, no monitoring dashboards, no alert policies, no documentation of how the solution was actually supposed to behave. Nobody had defined what “healthy” looked like, so nobody knew when it wasn’t. The platform team had delivered a product. They hadn’t delivered an operational service.

This is one of the most common failure modes I see in cloud delivery, and it’s exactly what the Operational Excellence pillar of the Microsoft Well-Architected Framework is designed to prevent.

What Operational Excellence Actually Means

The Well-Architected Framework defines Operational Excellence as the discipline of running and monitoring systems to deliver business value and continuously improve supporting processes and procedures. That’s a reasonable definition, but it doesn’t capture the practical reality.

In plain terms, Operational Excellence is the difference between deploying something and actually running it. It’s the discipline of asking, before you ship: who supports this, how will they know when something is wrong, how do we fix it when it breaks, and how do we make it better over time?

Operational Excellence is designing for the day after go-live.

It covers four broad areas: understanding your operations, building a solid deployment practice, managing workloads with the right observability in place, and continuously improving based on what you learn.

None of those things happen automatically. They have to be designed in.

Understanding Your Operations Before You Build

One of the most valuable things you can do before deploying anything into production is define what “good” looks like. This sounds obvious. In practice, it rarely happens.

For every workload, you should be able to answer a small set of baseline questions: What does normal performance look like? What are the expected usage patterns? What are the failure modes, and how severe is each one? Who owns the solution at 2am if it goes down? What’s the escalation path?

These aren’t just operational questions, they shape how you build the solution. If you know a workload is business-critical and used by 500 people first thing in the morning, you design monitoring and alerting differently than you would for a batch process that runs overnight. If you know the service desk will be fielding calls, you need to build the tooling and documentation that gives them a fighting chance.

In the AVD example, none of this had been done. The platform team understood the solution deeply. Nobody else did. Operational knowledge was locked in the heads of the engineers who built it, with no mechanism to transfer it to the people responsible for day-to-day support.

This is a design failure, not a support failure.

Deployment Practices Are Part of Operational Excellence

If you’ve followed this series, you’ll know I’ve talked at length about Infrastructure as Code and pipeline-driven deployments. Both of those are central to Operational Excellence, not just for the technical benefits, but for what they enable operationally.

When infrastructure is defined in code and deployed through a pipeline, you get several things almost for free: an accurate record of what’s deployed, a documented deployment process that doesn’t live in someone’s head, and the ability to reproduce or modify an environment consistently. If something goes wrong, you can trace exactly what changed and when. If you need to rebuild, you can.

Contrast this with the portal-click approach. Environments drift. Documentation becomes stale, if it existed at all. Troubleshooting relies on whoever built the thing being available. Reproducing an issue in a test environment becomes a guessing game.

IaC and pipelines aren’t just about automation efficiency. They’re about building systems that can be operated by people who weren’t involved in the original delivery. That matters enormously in any organisation where teams change, projects hand over, and the person who built something isn’t always the person who has to fix it.

Observability: You Can’t Fix What You Can’t See

Once you’ve deployed something, you need to know how it’s behaving. This is where observability comes in, and it’s an area that gets left until last far too often.

Observability isn’t just about having monitoring enabled. It’s about having the right signals, in the right place, surfaced to the right people. There’s a meaningful difference between “we have Azure Monitor configured” and “we have a health model for this workload that tells us whether the service is operating normally.”

A good observability model starts with defining what you actually need to measure. For most workloads this breaks down into three layers: infrastructure health (are the VMs running, are disks healthy, are there resource constraints), platform health (are the services responding, are connection counts within expected ranges, are error rates normal), and business health (are users able to complete the workflows they need to complete).

Each layer tells you something different, and the signals you care about at each layer will vary by workload. A batch processing job has very different health indicators than an interactive desktop environment. The point is that you define this upfront, not retroactively when things start failing.

Alerting deserves a specific mention here, because it’s the thing that most commonly goes wrong. Teams either configure too little, discovering problems only when users complain, or too much, generating so much noise that alerts get ignored. Both are failure modes. Alert fatigue is real, and an inbox full of warnings that fire constantly is functionally identical to no monitoring at all.

If your monitoring only tells you something is broken after a user reports it, you don’t have observability – you have hindsight.

The goal is meaningful alerts: notifications that fire when something genuinely needs attention, with enough context for the recipient to understand what’s wrong and what to do about it. That means tuning thresholds carefully, suppressing noise during known maintenance windows, and routing alerts to the people who can actually act on them.

Runbooks and Documentation: The Operational Handover

Returning to the AVD scenario: one of the quickest wins after the fact was producing a set of runbooks for the service desk. Not detailed technical architecture documents, but practical guides: what does the service desk see when a user can’t connect, what are the first three things to check, when do you escalate and to whom.

This is the kind of documentation that operational excellence demands, and it’s almost always deprioritised during delivery because it doesn’t feel like building anything. It doesn’t get demoed to the business. It doesn’t appear on the project milestone chart. But without it, the people responsible for supporting a solution are left to reverse-engineer how it works from first principles, under pressure, while users are waiting.

Runbooks don’t have to be exhaustive. They have to be accurate and actionable. A one-page guide that covers the five most likely failure scenarios and the resolution steps for each is worth more than a 30-page architecture document that nobody reads.

The other documentation that matters, and which IaC largely handles, is the infrastructure specification itself. When your infrastructure is code, the code is the documentation. You can look at a Terraform module and understand exactly what’s deployed, how it’s configured, and what dependencies exist. This is one of the practical advantages of IaC that doesn’t get talked about enough outside of the automation and consistency benefits.

Continuous Improvement: Closing the Loop

Operational Excellence isn’t a state you reach, it’s a practice you maintain. The final component of the pillar is the discipline of learning from what happens and using that learning to improve.

In practical terms, this means a few things. After incidents, doing some form of post-incident review, not to assign blame, but to understand what broke, why it wasn’t caught sooner, and what change would prevent a recurrence. This doesn’t need to be a formal process; even a brief conversation and a note in the team wiki counts. The important thing is that the learning gets captured and acted on.

It also means reviewing your operational posture periodically. Are your alerts still calibrated correctly, or have usage patterns changed? Are your runbooks still accurate, or has the solution evolved since they were written? Are there manual operational tasks that have become frequent enough to warrant automation?

This connects directly to the people and culture themes from the Azure Migration and Transformation post, specifically the idea that teams need to embrace continuous learning and be willing to iterate on how they work. The technical discipline of Operational Excellence only delivers value if the team culture supports it. Retrospectives, knowledge sharing, and an honest willingness to look at what isn’t working are the cultural counterparts to the technical practices.

Teams that do this well get better over time. Teams that don’t tend to accumulate operational debt: workarounds that never get fixed, manual processes that never get automated, alert thresholds that nobody has reviewed in two years. Eventually that debt becomes a serious liability.

The Operational Readiness Checklist

Before any solution goes into production, it’s worth running through a short set of operational readiness questions. This won’t catch everything, but it will surface the most common gaps.

Observability

• Have you defined what a healthy state looks like for this workload?
• Are the right metrics and logs being collected?
• Are alerts configured, meaningful, and routed to the right people?
  

Supportability

• Does the service desk know this solution exists and understand what it does?
• Are there runbooks covering the most likely failure scenarios?
• Is there a documented escalation path?
  

Deployment and change

• Is infrastructure defined as code?
• Are deployments running through pipelines with appropriate approvals?
• Can the environment be reproduced from the codebase if needed?
  

Ownership and accountability

• Is there a named owner for this workload?
• Is there an out-of-hours contact if something breaks?
• Is there a plan for how the solution is maintained and evolved over time?
  

These aren’t complex questions. But not having the answers is how you end up in the situation where a project gets signed off as a success and then quietly becomes a support nightmare.

Summary

Operational Excellence is the pillar that determines whether a solution actually works in the real world, after the project team has moved on. It’s not glamorous. It doesn’t generate the kind of architecture diagrams that look good in slide decks. But it’s the difference between a platform that runs reliably and one that generates a steady stream of support calls.

The principles are straightforward: understand your workloads before you deploy them, build in observability from the start rather than bolting it on after, make your deployments reproducible and auditable, give the people who support your solutions the tools and documentation they need, and create a feedback loop that means you get better over time.

The AVD example I opened with wasn’t a failure of technical skill. The solution worked. It was a failure to think beyond the delivery milestone and ask the harder question: when this is in production and something goes wrong, what happens next?

That question should be answered before you deploy, not at 9am on a Monday when the service desk phones start lighting up.

This post is part of the Well-Architected Framework series. The previous posts cover Reliability, Security, Cost Optimisation, and Performance Efficiency.