From DevOps to MLOps and AIOps: What Actually Changes

Two of the most confusing job titles in infrastructure sound almost identical and describe completely different work.

MLOps is running machine learning systems in production. You are shipping someone else's model the way you already ship someone else's application.

AIOps is pointing machine learning at your own operational data. Nobody ships the model. It reads your alerts.

If you do DevOps today, you are much closer to both than the job adverts suggest. This post is about the specific things that are genuinely different, with examples, and about the one assumption you have to give up.

The short version

Most of what you know still applies

This is the part the career-change content usually undersells. The ML industry spent years discovering that the hard part of machine learning in production is not the machine learning.

Here is what you already have that still does the job:

• Containers. A training job is a container. A model server is a container.
• CI/CD. Still a pipeline. It just has more stages and slower ones.
• Infrastructure as code. Unchanged.
• Observability. You will need more of it, not less.
• Artefact registries. A model registry is a registry with metadata that matters.
• Rollback. Still the most valuable thing you own.
• Secrets, identity, least privilege. Identical, and now guarding training data.

Google's MLOps architecture guide frames the whole discipline as an extension of CI/CD rather than a replacement for it, which matches the experience of most people who make this move.

The assumption you have to give up

Here is the real dividing line, and everything else follows from it.

Ordinary software is deterministic. Same input, same output. If it worked in staging, it works in production, and if it doesn't, something changed — the config, the version, the data shape. You go and find what changed.

A machine learning system is not. It produces a probability. It can be completely healthy, fully deployed, throwing no errors, passing every test — and quietly getting worse, because the world it learned about has moved.

Nothing in a DevOps toolkit detects that. There is no exception. There is no non-zero exit code. The service is up. The dashboards are green. The predictions are getting worse.

That is the actual job change. Not the tools — the failure mode.

DevOps to MLOps

1. You version three things now, not one

In DevOps, a release is a commit. You can point at it.

In MLOps, "which version is in production" has three answers, and you need all three to reproduce anything:

code     →  the training script, feature logic, serving code
data     →  the exact rows the model learned from
model    →  the weights that came out

Here is why it matters. A model starts performing badly. You want to roll back. You redeploy last month's model artefact — and it behaves differently than it did last month, because the feature it reads is computed by serving code you have since changed.

You rolled back one of the three things.

What to do about it: treat the dataset as a build input, not as a place. Snapshot it, give it an identifier, and record that identifier alongside the model. If you can answer "which exact data produced this model" in one command, you have solved most of this.

2. "The tests passed" stops meaning "it works"

Google's guide is blunt about this:

"Testing an ML system is more involved than testing other software systems. In addition to typical unit and integration tests, you need data validation, trained model quality evaluation, and model validation."

Unit tests still check your code. They cannot check whether the model is any good. So a pipeline gains stages that have no DevOps equivalent:

• Data validation — is the incoming data the shape and distribution we expect? A column that silently became all-nulls is a far more common outage than a bug.
• Model evaluation — is this new model better than the one in production, on data neither of them has seen?
• Model validation — is it better enough, and not worse for any group in particular?

A useful mental shift: in DevOps, the pipeline gate asks did this break anything? In MLOps it asks is this an improvement? — which is a question with a number, and the number has to come from somewhere you trust.

3. Training-serving skew, the one that really bites

This is the failure mode worth learning before you need it, because it is invisible and it is common.

Your model was trained on features computed one way. In production, those features are computed a different way. The model receives inputs that are subtly not what it learned on.

A concrete version:

Training   (offline, Python, batch)
  avg_order_value = orders.groupby("user").amount.mean()
  # includes refunded orders, computed over all history

Serving    (online, Java, per request)
  avgOrderValue = sumRecentOrders / countRecentOrders
  // excludes refunds, last 90 days only

Both are reasonable. Both are called avg_order_value. They are not the same number. The model was trained on the first and is being asked about the second, every single request.

Nothing errors. Accuracy just quietly sits lower than it did in the evaluation, and everyone concludes the model "didn't generalise".

Google's guide names this directly as a consequence of the handoff between the people who train and the people who deploy.

What to do about it: compute the feature once, in one place, and let both training and serving read that. This is the entire reason feature stores exist. You do not need to buy one to get the benefit — you need one definition, not two.

4. Drift: the model is fine, the world moved

A fraud model trained on eleven months of ordinary spending meets December. People buy unusual things, at unusual times, in unusual places. The model was right about the world it learned; the world changed.

Google's guide puts it plainly: models "can have reduced performance not only due to suboptimal coding, but also due to constantly evolving data profiles."

Two things drift, and it is worth keeping them apart:

• Data drift — the inputs change shape. You can detect this without knowing the right answer, by comparing live input distributions against training ones. Cheap. Do it first.
• Concept drift — the relationship between input and answer changes. Detecting this needs ground truth, which often arrives late (was that transaction actually fraud? you find out in six weeks).

What to do about it: monitor input distributions from day one, because it needs no labels and catches a real class of problem. Decide deliberately whether retraining is scheduled, triggered by a drift threshold, or manual — and write down which, because "we retrain when someone notices" is the default nobody chooses on purpose.

5. A map you can actually use

Google's guide defines three levels, and they are genuinely useful for locating yourself:

• Level 0 — manual. Someone trains in a notebook and hands over a model file. Releases are infrequent. Nothing watches performance afterwards.
• Level 1 — pipeline automation. The training pipeline runs itself on fresh data. The same pipeline runs in development and production. Models are validated automatically before serving.
• Level 2 — CI/CD for the pipeline. Committing a change to the pipeline builds, tests and deploys the pipeline. Experimentation becomes fast because shipping an experiment is cheap.

If you are coming from DevOps, level 1 is where your existing skills convert almost directly, and it is where most of the value is. Level 2 is a platform engineering problem, which you have also seen before.

DevOps to AIOps

This is a different job with a confusingly similar name.

What it actually is

AIOps applies machine learning to operational telemetry — logs, metrics, traces and events. You are not deploying a model as a product. You are pointing one at the data your systems already emit, to answer questions a human cannot answer fast enough at 3am.

What it genuinely does well

Alert correlation. One failing database produces two hundred alerts across forty services. Correlation groups them into one incident with a probable origin, using timing, topology and dependency information.

Dynamic baselining. Instead of "alert if CPU > 80%", the system learns what normal looks like for this service, at this hour, on this day. A traffic spike every Monday at 02:00 that matches the backup window is expected and stays quiet. The identical spike on Thursday afternoon is not, and it fires.

That example is the clearest illustration of the difference. A static threshold cannot tell those two apart. It either pages you every Monday until you stop reading the pages, or it is set high enough to miss the Thursday one.

Anomaly detection without thresholds. Useful where you have too many signals to hand-tune, which is most places past a certain size.

What it does not do

Being honest about this matters more than the capability list, because unrealistic expectation is the most common way these projects fail.

• It is weak on genuinely novel failures. It predicts from patterns in history. A failure with no precedent is precisely the case it has nothing to say about — and that is often your worst incident.
• It inherits your data quality. If logs, metrics and traces live in disconnected tools with inconsistent service names, correlation has nothing to correlate. The unglamorous prerequisite is consistent naming and joinable telemetry. That work is pure DevOps and you already know how to do it.
• It usually gets noisier before it gets quieter. There is a learning period where baselines are still forming, and teams already drowning in alerts are the least able to sit through it.
• It does not remove the need to understand your system. It shortens triage. Someone still has to decide.

Where a DevOps engineer adds value immediately

The bottleneck in most AIOps efforts is not modelling. It is that the telemetry cannot be joined: three services call the same thing by three names, traces stop at a queue boundary, and half the logs are unstructured strings.

Fixing that is work you can do on day one, it improves your on-call life whether or not any ML arrives, and it is the thing that determines whether the ML is worth anything.

What has actually changed recently

Some of this is verifiable and dated. Some is direction of travel. It is worth keeping those apart, so here they are separately.

Verifiable, with dates:

• Keyless CI identity has become the normal posture. Pipelines authenticate to cloud providers with short-lived OIDC tokens instead of stored access keys. GitHub changed the subject claim format for repositories created after 15 July 2026 to an immutable form carrying numeric IDs — which broke a lot of existing AWS trust policies, and is a good illustration of identity now being a moving part you have to maintain.
• Signature verification moved from optional to gate. Signing container images with Sigstore and verifying them at admission is increasingly a policy rather than a nice-to-have. Cosign 2.0 made the identity flags mandatory for keyless verification, so commands written for older versions now fail — deliberately.
• Secret scanning blocks pushes rather than reporting them afterwards. The block happens before the credential lands.

Direction of travel, stated as opinion:

• The MLOps and DevOps toolchains keep converging. Model deployment increasingly looks like application deployment with extra validation stages, rather than a parallel universe with its own tools.
• Platform engineering is absorbing both. The pattern that keeps recurring is a paved path — an opinionated internal route to production that most teams take because it is easier than not taking it.
• "Can you reproduce it" is becoming the question that separates teams that ship ML reliably from teams that ship it once.

A 90-day path that is not a career change

You do not need to stop being a DevOps engineer to do any of this.

Weeks 1–4 — make something reproducible. Take one model your organisation already has, and get it so that one command produces it from a recorded dataset version. If nobody has one, do this with any public dataset. The skill is the pipeline, not the model.

Weeks 5–8 — put it behind an API and watch it. Containerise the model, serve it, and instrument it. Log inputs and outputs. Then plot the input distributions over time. You now have data drift detection, built from monitoring you already know how to do.

Weeks 9–12 — close the loop. Add a validation stage that refuses to promote a model that is not better than the one in production. This single gate is the difference between level 0 and level 1, and it is mostly pipeline logic — your existing skill.

For AIOps, the equivalent first step is smaller and more useful than it sounds: pick your noisiest alert and replace its static threshold with something that knows about time of day. You will learn more from that than from any platform evaluation.

Five things not to do

1. Do not start by choosing a platform. Almost every failed effort in either direction starts with a tool selection and works backwards to a problem.
2. Do not let "the model is deployed" count as done. In MLOps deployment is the start of the part that can go wrong silently.
3. Do not compute a feature twice. One definition, read by both training and serving. This one rule prevents the most expensive bug in the field.
4. Do not switch off a check because it failed. This applies to signature verification, drift alerts and model validation gates equally. Find out what was wrong, then put it back.
5. Do not believe an MTTR improvement you cannot reproduce. Vendor figures for AIOps are marketing numbers from unstated baselines. Measure your own, before and after, on your own incidents.

Jargon, translated

Where to go next

The single most useful document on the MLOps side is Google's MLOps: Continuous delivery and automation pipelines in machine learning, which is where the maturity levels and the quotations in this post come from.

For the supply-chain and identity changes mentioned above, the primary sources are GitHub's OpenID Connect documentation and Sigstore's verification guide.

If you take one thing from this: the skills transfer, and the thing that does not is an assumption. Ordinary software tells you when it is broken. A model does not. Everything else in MLOps is scaffolding built around that single inconvenient fact.