Ground stations make spaceflight look effortless. A satellite sweeps over the horizon, a dish swings to meet it, telemetry scrolls across a console, and the spacecraft carries on as though nothing dramatic is happening. What the picture hides is the roster behind it: somebody wrote the pass schedule, somebody watches the battery curves overnight, and somebody gets a phone call when the numbers drift out of family. The spacecraft does not fly itself. It flies because a chain of people and procedures holds it up.
NoOps is the information-technology version of the claim that the spacecraft can now fly itself. The word describes running IT with no dedicated operations team, on the theory that cloud providers and automation have absorbed the work. It began as a provocation more than a decade ago and it refuses to die, because every new generation of managed services makes the provocation sound a little more plausible. Before anyone signs off on it, though, it helps to know which parts are physics and which parts are marketing. These eight ground rules are the practical version, written for teams who prefer their promises checked before launch rather than after.
What NoOps Promises, and What It Quietly Keeps
The term carries two meanings, and mixing them up causes most of the disappointment. Only one of them is a live option for a real organisation:
- The organisational meaning: operations is bought and automated so thoroughly that a separate ops group stops being necessary. This is the version vendors mean, and it is achievable in pockets.
- The absolute meaning: a fully automated estate with zero human involvement in operations. This is the version critics tie to AIOps, and it functions as a direction of travel, not a destination any company occupies.
The honest summary — the Ops Atlas entry on NoOps states it plainly — is that operations work gets displaced rather than deleted. The rules below all follow from that one sentence.
The Eight Ground Rules
Rule 1: Somebody always owns the ground segment
When an ops team dissolves, its duties scatter instead of vanishing. They land on the cloud provider, on a platform group, on product developers who now carry pagers, inside automation code, and in vendor management that nobody wrote a job description for. Count the destinations before you celebrate the departure. If you cannot name who holds each duty, you have not removed operations; you have made it anonymous.
Rule 2: The provider does the tasks, not the accountability
Managed services genuinely remove work such as patching, capacity planning, and hardware replacement. What they never remove is responsibility for your own account settings. Consider the wave of data thefts that hit Snowflake customers: the provider’s platform itself was not breached, yet the affected accounts had left sign-ins without a second factor, credentials unrotated for months, and no network allow lists in place — all customer-side controls. The service model moved the machinery. It never moved the duty of switching those controls on. Reading the provider’s responsibility matrix line by line, before migration rather than after the first scare, is the cheapest insurance available in this arrangement.
Rule 3: Automation code is staff, whether HR admits it or not
Every pipeline, autoscaling policy, and self-healing script you deploy behaves like a silent employee. It needs onboarding, review, and correction when it misbehaves, exactly like a new hire with production access. Teams that forget this end up with automation nobody dares modify, which is just operations with worse documentation. For a look at where machine-assisted operations is heading, there is a simpler walkthrough of AIOps and modern IT operations that pairs well with this rule.
Rule 4: Pagers change hands; they do not retire
Someone still answers when the service stops responding. Researchers who study on-call health at Google cap alert load at roughly two pages per twelve-hour shift, because beyond that a human stops learning from incidents and starts merely surviving them. Teams that fold on-call into product roles need to respect limits like that, or the arrangement burns out the very engineers it was meant to empower. Alert quality matters as much as alert quantity: a page that a responder cannot act on is noise wearing an urgent costume, and it erodes trust in the whole rotation.
Rule 5: Your ceiling is set by your weakest link
A service can never promise more availability than the combination of everything it depends on. If the identity provider, the DNS vendor, and the database each carry their own downtime, those outages overlap into your service whether or not you employ a single operator. Orbital mechanics offers a neat parallel: a satellite in low earth orbit communicates only while a ground station is within view, so its usable availability is set by the handoff chain, not by how healthy the spacecraft itself feels. Multiply the availability of each link and you get the number you can honestly put in front of customers.
Rule 6: Zero unowned work is the only passing grade
Reliability teams track a figure called unowned duty share: the fraction of operational chores with no named owner. Anything above zero is an incident with a delay timer attached. A genuine NoOps transition drives this number down to zero and keeps it there. If it creeps back up after a reorganisation, duties are pooling somewhere nobody planned for, and the org chart is lying to you.
Rule 7: Buy the boring parts, keep the risky parts
Standard workloads with spiky or light traffic are the natural fit for fully managed platforms. High, steady load often makes reserved, self-run capacity cheaper than renting by the hour. Exotic hardware or tight latency requirements push you back toward hands-on control no matter what the sales deck says. And since any provider can eventually retire a product, ask early what happens to your workload if they do — cloud history already contains managed services whose owners switched them off and left customers holding a migration nobody had budgeted for.
Rule 8: The honest destination is “low ops”
Maturity models for this idea run from Level 0, where a team simply declares itself free of operations, up to Level 4, described as low-ops by design: the remaining duties are counted, each has an owner, and failure has been rehearsed on purpose. Nobody credible claims the ladder ends at zero. The organisations that succeed treat the climb as a reduction in toil with full accounting, not an act of deletion — every eliminated task gets a named successor before it is marked done.
NoOps, With the Verdict Attached
Whether a spacecraft sits in geostationary orbit, parked overhead and always in view, or dips through low passes every ninety minutes, someone still schedules the contacts and reads the telemetry. Information systems behave the same way. Operations moves up the stack and into new hands — providers, platform groups, product engineers, and the code they write — but it does not evaporate.
That is the practical takeaway for any team weighing this path: skip the discipline and you still get the operations, except it arrives during your worst outage, unowned and unplanned. Do the work properly and you get something better than a slogan. You get a smaller, counted, owned set of duties that nobody has to apologise for at 3 a.m.
The spacecraft still needs a ground segment. The only real question is whether anyone planned it before launch.