What is MLOps? A Beginner's Guide to Machine Learning Operations

Picture a cloud kitchen near 56 Dukan that prints a "ready in 20 minutes" slip for every order. In winter the promise holds. Then the monsoon arrives, riders crawl through flooded lanes near Palasia, and the same slip now says 20 when the truth is 32.

The slip did not break. The world it was written for changed. Someone has to notice, rewrite the rule, test it, and print new slips without stopping the kitchen.

That "someone plus a system" is what MLOps provides for machine learning models.

What is MLOps?

Map the kitchen to ML. The slip rule is your model, the orders are live data, the monsoon is drift, and the person who watches, fixes and reprints is the MLOps process.

MLOps is the engineering discipline that makes machine learning models reproducible, deployable, observable and continuously improvable in production, by applying DevOps ideas such as version control, automation and monitoring to data and models as well as code.

The name joins "machine learning" and "operations". DevOps already taught software teams to ship code safely. MLOps extends that to two extra moving parts that ordinary software does not have: the training data and the trained model.

The running example for this course

Every lesson in this series uses the same fictional company, Chappan Express, a food-delivery startup in Indore. Its data team owns one model, eta-model, which predicts how many minutes an order will take to reach the customer.

The inputs are simple: distance in kilometres, kitchen preparation time, hour of day, whether it is raining and how many orders the rider already carries. The output is a number like 27.4 minutes that the app shows as "arriving in about 27 minutes".

That one model is enough to show every MLOps problem you will meet at work.

Why do ML models fail after deployment?

Ordinary code fails loudly. A wrong formula throws an error or returns nonsense on day one. A model fails quietly: it keeps returning plausible numbers while the gap between prediction and reality widens.

The code below trains Chappan Express's first model on dry January orders and then scores it on monsoon orders in July. Nothing in the code changes. Only the data does.

import numpy as np
from sklearn.linear_model import LinearRegression
from sklearn.metrics import mean_absolute_error

rng = np.random.default_rng(7)

def make_orders(n, rain_share):
    distance = rng.uniform(0.5, 9, n)        # km from restaurant
    prep = rng.integers(8, 25, n)             # kitchen minutes
    rain = rng.random(n) < rain_share         # True on rainy orders
    minutes = 6 + 3.2 * distance + prep + rain * (4 + 1.5 * distance)
    minutes = minutes + rng.normal(0, 3, n)
    X = np.column_stack([distance, prep])     # the model never sees rain
    return X, minutes

X_jan, y_jan = make_orders(2000, rain_share=0.02)   # dry winter
X_jul, y_jul = make_orders(2000, rain_share=0.60)   # monsoon

model = LinearRegression().fit(X_jan, y_jan)
mae_jan = mean_absolute_error(y_jan, model.predict(X_jan))
mae_jul = mean_absolute_error(y_jul, model.predict(X_jul))
late = (y_jul - model.predict(X_jul)) > 10
print(f"MAE in January: {mae_jan:.2f} min")
print(f"MAE in July   : {mae_jul:.2f} min")
print(f"July orders more than 10 min later than promised: {late.mean():.0%}")

The January error is around 2.5 minutes, which looks excellent in a notebook. In July the error roughly triples and a large share of customers wait more than ten minutes longer than the app promised.

No exception was raised. No dashboard turned red. Without monitoring, the first alarm is angry customer reviews. MLOps is the set of habits that catches this in hours, not weeks.

What does an MLOps system include?

A model in production is a small box inside a much bigger machine. The training code is perhaps a tenth of it. The rest is plumbing that moves data, records experiments, packages the model, serves predictions and watches them.

Left: a notebook model ends as a file someone emails. Right: an MLOps loop where monitoring feeds new data back into training.

Here are the building blocks, with the lesson in this course that covers each one.

MLOps vs DevOps

MLOps borrows almost everything from DevOps, then adds the parts that only exist because a model learns from data.

The minimum MLOps habit: record every run

You do not need a platform to start. The single most useful habit is writing down, for every training run, what went in and what came out. If you cannot answer "which data made the model that is live right now?", you cannot debug it.

The block below builds that record by hand: a fingerprint of the training data, the settings, the score and a simple promote-or-reject decision.

import hashlib, json
import numpy as np
from sklearn.linear_model import Ridge
from sklearn.metrics import mean_absolute_error

rng = np.random.default_rng(11)
X = np.column_stack([rng.uniform(0.5, 9, 600), rng.integers(8, 25, 600)])
y = 6 + 3.2 * X[:, 0] + X[:, 1] + rng.normal(0, 3, 600)
X_train, X_test, y_train, y_test = X[:450], X[450:], y[:450], y[450:]

params = {"alpha": 1.0}
model = Ridge(**params).fit(X_train, y_train)
mae = mean_absolute_error(y_test, model.predict(X_test))

run = {
    "model": "eta-model",
    "data_sha256": hashlib.sha256(X_train.tobytes() + y_train.tobytes()).hexdigest()[:12],
    "params": params,
    "test_mae_min": round(float(mae), 2),
    "promote": bool(mae < 4.0),   # the team's agreed quality bar
}
print(json.dumps(run, indent=2))

Tools such as MLflow store exactly this kind of record, plus the model file, in a searchable database. You will see that in the reproducibility and versioning lesson. The idea comes first; the tool is a convenience.

How mature is your MLOps? Three levels

Teams usually grow through three stages. Knowing where you stand tells you what to build next.

Most teams start at level 0. The jump to level 1, automated retraining with checks, gives the biggest payoff.

1. Level 0, manual. A data scientist trains in a notebook, saves model.pkl and hands it to a developer. Retraining happens when someone remembers. This is fine for a first proof of concept.
2. Level 1, automated training. A scheduled pipeline pulls fresh data, retrains, compares against the live model and registers the winner. Chappan Express would retrain eta-model every night with yesterday's deliveries.
3. Level 2, automated delivery of the pipeline. Changes to the pipeline code itself are tested and deployed by CI/CD. Many teams can work on it safely at once.

Do not jump straight to level 2. A small team with one model gains more from a nightly retrain script and a monitoring alert than from a cluster it cannot maintain.

Who does MLOps work?

In a large company there is often a dedicated ML engineer or MLOps engineer role. In a startup like Chappan Express the same two or three people do everything.

• Data scientists frame the problem, build features and train models.
• Data engineers build the pipelines that deliver clean data on time.
• ML engineers package, deploy, scale and monitor the models.
• Platform or DevOps engineers run the cloud, containers and CI systems underneath.

If you come from data science, MLOps is the skill that makes your models useful. If you come from software, it is the skill that lets you work on AI systems. Both paths are covered in our GenAI career roadmap, and if you prefer learning with mentors, there is a classroom route into GenAI engineering at Debugshala.

Common mistakes when starting MLOps

• Buying a platform before having a process. Tools do not fix the lack of a quality bar or an owner for the live model.
• Measuring only offline accuracy. A great test score says nothing about next month. Plan monitoring before the first release.
• Not saving the training data snapshot. Without it you can never reproduce or explain a model.
• Treating the model as the product. The product is the prediction service: the model plus features, API, logs and alerts.
• Retraining blindly on a timer. Retraining on broken data ships a broken model faster. Always gate it.

Key takeaways

• MLOps applies DevOps discipline to data and models so ML systems stay reproducible and reliable.
• Models fail quietly when data changes, so monitoring is not optional.
• Start by recording every run: data fingerprint, settings, metrics and a promote decision.
• Grow from manual (level 0) to automated retraining (level 1) before automating everything.
• The next lesson, the ML system lifecycle, walks through each stage in order.