An owner rings the shop with a complaint we hear all the time: “I replaced every wear item on the annual list and she still runs rough.” Nobody who turns wrenches for a living is surprised. New parts in the wrong places, a torque value nobody checked, a filter that looks right and flows wrong — the symptom points at the engine while the fault lives somewhere else entirely. NoOps setups fail the same way, which is why this piece reads like a troubleshooting session rather than a lecture.
The pitch behind NoOps is simple and seductive: rent managed services, automate the routine, and the whole operations department becomes someone else’s problem. The symptom that brings teams to us is usually money or downtime. The fault, when we trace it, is almost never the technology. It is one of three classic failures, and each has a fix you can apply before the next flight — or the next invoice.
NoOps Symptoms We Keep Seeing
Before the diagnosis, a quick identification guide. If your team sounds like any of the following, keep reading:
- “We moved everything to managed services, so why does the bill keep climbing?”
- “The provider says data is safe, but nobody here can actually restore anything.”
- “We have no ops staff, and somehow the accounts just got compromised.”
Three different complaints. Three different roots. One shared habit: the team treated the management console as if it were a signed-off certificate of airworthiness for the whole operation. It is not, and never was.
Fault One: The Wrong Part for the Job
The first failure is a mismatch between workload and building block, and the best-documented case comes from an unexpected hangar: Amazon’s own Prime Video team. They built a stream-monitoring service on serverless components — Step Functions orchestrating Lambda functions — and watched it strain at roughly five percent of the load they expected it to carry. The fix was not more tuning. They rebuilt the service on containers running on EC2 and cut the running cost by ninety percent.
Any aircraft owner recognises this story instantly. It is the equivalent of chasing a vibration by installing progressively fancier spark plugs when the real issue is a propeller that needed dynamic balancing. Money spent on the wrong component does not just fail to fix the problem; it postpones the diagnosis while the invoice grows. The component was not defective; it was simply the wrong component for that role. Serverless excels at spiky, short, event-driven work. Feed it a steady, high-volume, always-on job and it will do the work — at a price that reads like a prank.
The diagnosis tool here is embarrassingly simple: before choosing a service, write down the workload’s shape. Steady or spiky? Constant or occasional? Long-running or millisecond? If the honest answers contradict the service’s sweet spot, you have found your rough-running cylinder before it scorches a valve.
Fault Two: Assuming Managed Means Backed Up
The second failure hides inside a comforting sentence: “It’s managed, so my data is safe.” Providers do keep their platforms running and they protect the infrastructure itself. What they do not do is own your backup strategy. AWS says this in as many words — the responsibility for protecting what you store stays with you, no matter how managed the surrounding service is.
The reliability engineers who track this stuff measure it with a number they call restore readiness: can the team actually prove a working restore has been rehearsed within the last ninety days? Not “a backup job exists.” Not “we pay for snapshots.” An actual rehearsal, dated, with the result written down. In hangar terms, it is the difference between owning a jack and having recently lifted the aircraft on it.
Here is the friendly diagnostic: pick one managed service that matters, and ask the person closest to it to walk you through a restore from start to finish — right now, without preparation. If the walk-through stalls somewhere around “well, we’d open a support ticket,” you have located fault two, and you found it in the friendliest possible way: on a calm day, with no emergency in progress. The cure costs an afternoon: run the restore for real, write down how long it took, and put the next rehearsal on the calendar ninety days out.
Fault Three: Identity Left on the Flight Line
The third failure is the quietest, and it is the one that turns into a headline. When attackers hit customers of Snowflake, a very large data platform, the investigation found something instructive: the provider’s own systems had not been breached. The compromised accounts simply lacked multi-factor authentication, lacked credential rotation, and lacked allow lists restricting where sign-ins could come from. The platform was sound. The front doors had simply never been locked.
Every managed service runs on a shared-responsibility model, and identity sits squarely on the customer’s half of that ledger. The provider locks its hangar; you still have to lock yours. And here is the trap within the trap: teams that embrace NoOps often have no operations staff left to notice that forty service accounts still carry passwords from two years ago. The automation quietly provisions. Nobody quietly audits. Mechanics have a saying for this pattern: what gets inspected gets maintained, and what gets ignored gets creative. A credentials list nobody reads is exactly that kind of creative.
The diagnostic takes one line: list every human and machine identity that can touch the service, and confirm each one has a second factor, a rotation date, and a restriction on where it may sign in from. Any blank on that list is fault three, confirmed.
Running the NoOps Diagnosis on Your Own Setup
Put the three faults together and you get a compact inspection routine — the kind we prefer over vague advice, because it produces a pass or a finding, never a shrug:
- Shape check: does each workload’s traffic pattern actually match the service it runs on? Mismatches cost money monthly.
- Restore check: one rehearsed restore per critical service, dated within the last ninety days, result written down.
- Identity check: every account has MFA, rotation, and sign-in restrictions — verified, not assumed.
Notice that none of these checks requires hiring an operations department. They require a half-day per quarter and the honesty to write down what fails. That is the deal NoOps actually offers: not fewer responsibilities, but different ones — chosen deliberately instead of inherited by accident. If you want the full picture of the idea, its history, and the maturity ladder reliability folks use to grade it, the field guide to NoOps over at the Ops Atlas is the source we keep bookmarked.
And if the maintenance mindset behind this piece is your thing, we have written it before from the hardware side. Our explainer on why engine parts quality matters in aviation safety covers the same cost-of-a-cheap-part arithmetic, the engine parts checklist for maintenance planning shows what a real register looks like, and this piece on how replacement parts improve aircraft reliability is, at heart, a restore-rehearsal argument for crankshafts.
Run the three checks. Fix what the findings show. Write the results down where the next person can find them, because a finding that lives only in someone’s memory fails the same way an uninspected part does. Do that much, and the airplane — and the platform — will feel the difference long before the next inspection comes due.
