From DevOps to AIOps: CI/CD, Observability, Autoscaling, and AI Model Operations

A pager goes off at 2 a.m. Five hundred alerts say the same outage in five hundred dialects. A human is supposed to be the correlation engine. That is the old DevOps night shift. AIOps is the bet that a model can do the first pass: group the noise, name the likely cause, and sometimes fix it before a human opens a laptop (Gartner, 2025; TechTarget, 2024).

DevOps and AIOps are not rivals. DevOps is how you build and ship. AIOps is how you keep a noisy, multi-cloud estate from drowning the people who ship. One is a culture plus a pipeline. The other is event intelligence on top of telemetry. Teams that skip DevOps and buy an "AIOps platform" get a dashboard on a mess. Teams that stop at DevOps get fast deploys and a pager that never sleeps (Kim et al., 2016; Forsgren et al., 2018).

This post is a long walk through both: what they are, who does what, the tools and cloud services that actually matter now, CI/CD, monitoring and observability, visualization, autoscaling, training and deploying AI models, and the concrete path from a DevOps team to an AIOps practice. It also draws a hard line around MLOps. Training a model is not the same job as using a model to run operations.

Key Abbreviations in This Post

• DevOps: Shared ownership of build, test, release, and run. Culture first, toolchain second.
• AIOps (Artificial Intelligence for IT Operations): Machine learning on events and telemetry to cut noise, find cause, and trigger action. Gartner now files much of this as Event Intelligence Solutions.
• MLOps: The DevOps-shaped practice for training, registering, deploying, and watching machine learning models. Related, not a synonym.
• CI/CD (Continuous Integration / Continuous Delivery or Deployment): Every commit is tested. Every good build can go to production, often through GitOps.
• IaC (Infrastructure as Code): Terraform, Pulumi, Bicep, CloudFormation. The cluster is a file in Git.
• SRE (Site Reliability Engineering): Google's reliability craft: SLIs, SLOs, error budgets, toil reduction.
• OTel (OpenTelemetry): The open standard for metrics, logs, traces, and now more signals. The pipe almost everyone should use.
• MELT: Metrics, Events, Logs, Traces. The raw food of observability and AIOps.
• MTTR (Mean Time to Restore / Repair): How long you stay broken. AIOps is sold on shrinking this.
• HPA / VPA / KEDA: Kubernetes scalers. CPU/memory, vertical size, and event-driven (queues, custom metrics).
• GitOps: Desired state lives in Git. Argo CD or Flux makes the cluster match.
• SLO / SLI: Service level objective and indicator. The contract, not the raw CPU graph.

The One-Minute Version

• DevOps: make change cheap and safe. CI/CD, IaC, containers, shared on-call.
• AIOps: make operations cheap and safe at alert volume humans cannot read. Correlate, predict, remediate.
• They meet on telemetry: if OpenTelemetry is missing, neither story works.
• CI/CD that matters now: GitHub Actions or GitLab CI for build, Argo CD or Flux for deploy, plus a real security scan in the pipe.
• Observe, then visualize: Prometheus + Grafana (or a vendor suite) on an OTel collector. Dashboards are not the product. Questions are.
• Scale on the signal that hurts: HPA for CPU, KEDA for queues, Karpenter or a cloud node pool for GPUs.
• Models have two lives: you train and serve them (MLOps). You also use models to run the shop (AIOps). Do not mix the labels.
• The shift: instrument, one pipe, correlate, suggest, then auto-fix with a human brake.

What DevOps Actually Is

DevOps is not a job title that magically appears when you install Jenkins. It is a working agreement: the people who write the service also ship it and feel the production pain (Kim et al., 2016). The Phoenix Project and the later DevOps Handbook gave the industry a story. Accelerate gave it numbers: elite teams deploy more often, recover faster, and have lower change-fail rates when they combine automation with generative culture (Forsgren et al., 2018).

The technical skeleton is familiar in 2026:

• Version control as the source of truth (Git).
• CI on every change: unit tests, lint, SAST, image build, SBOM.
• CD through environments: staging, canary or blue/green, production.
• IaC so a region can be rebuilt from a repo.
• Containers and Kubernetes (or a serverless stand-in) so "it works on my machine" dies.
• You build it, you run it, with SRE-style SLOs if the org is large enough (Beyer et al., 2016).

Platform engineering is the current refinement. Instead of every squad inventing a pipeline, a platform team offers a paved road: a golden path template, a shared cluster, a catalog. DevOps did not end. It got a product manager (CNCF, 2024).

Problem: developers throw a build over the wall. Ops refuses Friday deploys.
Cause: incentives are split. Dev is scored on features. Ops is scored on uptime.
Effect: tickets, war rooms, and a six-month release train. DevOps collapses the wall. The same team owns the pipeline and the pager.

DevOps tasks and responsibilities

A working DevOps or platform squad typically owns:

• Pipeline design: what runs on pull request, what is required to merge, what promotes a build.
• Environment truth: Terraform/Pulumi modules, secrets via Vault or a cloud secret store plus External Secrets.
• Release mechanics: GitOps apps, rollout strategy, feature flags (LaunchDarkly, Unleash, Flagsmith, or cloud equivalents).
• Runtime: Kubernetes, service mesh or Gateway API, ingress, certificates, network policy.
• Quality gates: tests, image scan (Trivy, Grype), policy-as-code (OPA, Kyverno).
• Basic observability: emit metrics and logs, a default Grafana folder, an on-call rotation, a runbook.
• Cost and capacity: requests/limits, reserved instances, a first-pass FinOps tag.
• Security in the path: identity (IRSA, Workload Identity), least privilege, signed images (cosign).

What they are not automatically: the team that trains foundation models, the SOC, or the people who invent a correlation algorithm. Those sit next door.

What AIOps Actually Is

Gartner coined AIOps years ago. By 2025 they were telling buyers to look past the slogan and buy Event Intelligence: ingest alerts from many tools, correlate and enrich them, find patterns, and drive remediation (Gartner, 2025). That is the useful definition. A product that only draws a prettier graph is observability. A product that turns 400 duplicate CPU alarms and a trace spike into one incident with a suggested rollback is AIOps.

The loop is:

1. Ingest metrics, logs, traces, events, tickets, topology, change records.
2. Normalize so a CloudWatch alarm and a Prometheus alert can share a language.
3. Correlate by time, service, and dependency map.
4. Enrich with owner, SLO, recent deploy, customer impact.
5. Decide with rules plus models: suppress, page, or act.
6. Act by opening a ticket, paging the right squad, restarting a pod, or rolling back via GitOps.
7. Learn from the human who said "wrong root cause" so the next cluster is better.

Vendors in this neighborhood include Dynatrace, Datadog, Splunk, New Relic, BigPanda, Moogsoft-class tools, ServiceNow Event Management, Elastic, and the AI add-ons now bolted onto every observability suite (Network World, 2025). Open source stacks do a thinner version: Alertmanager inhibit rules, Grafana IRM, and homegrown correlation. The science is the same. The difference is how much topology and history you feed the model.

Problem: a Kubernetes node dies. Every pod on it pages a different team.
Cause: each monitor is local. None of them knows the shared cause.
Effect: six bridges and one still-broken node. AIOps should emit one incident: "node X, drain and replace, these five services degraded, last change was a Karpenter template at 01:12."

AIOps tasks and responsibilities

• Signal hygiene: kill duplicate monitors before you train anything. Garbage in, confident garbage out.
• Topology: keep a living map of services, queues, databases, and third-party APIs.
• Baselines: what "normal" looks like per weekday, per region, per release.
• Incident object: one ticket, many raw events. Link to the deploy SHA.
• Runbook automation: restart, scale, fail over, roll back, with an approval step until trust is earned.
• Feedback: operators mark true/false so models do not freeze in 2024's traffic shape.
• Guardrails: an AI that can restart prod without a recorded reason is an outage generator.

How They Differ, and How They Fit

Apples and oranges, as the usual explainer says, and still the same fruit bowl (TechTarget, 2024). DevOps shrinks the cost of a change. AIOps shrinks the cost of a signal. You need both once the estate is larger than one team can hold in their head.

CI/CD: What Matters Now

The CI/CD market is no longer "Jenkins versus the world." Jenkins still runs in banks that will not move. Greenfield teams in 2026 usually pick:

• GitHub Actions: closest to the repo most people already use. Matrix builds, OIDC to cloud, a huge action ecosystem. Watch minute cost and reusable workflows so every squad does not fork a broken YAML.
• GitLab CI: pipeline and repo and registry and security in one product. Strong if you want fewer vendors.
• Azure DevOps: still the default in Microsoft-heavy enterprises, Boards plus Pipelines plus Artifacts.
• CircleCI, Buildkite, Tekton: when you want dedicated runners, or Kubernetes-native pipelines as CRDs.
• Jenkins / Jenkins X: keep it if the plugin city is already paid for. Do not start there without a reason.

CI is the easy half. CD is where teams stall. The pattern that won is GitOps:

• Argo CD or Flux watches Git and reconciles the cluster.
• Argo Rollouts or Flagger does canary and blue/green, often gated on an SLO or a Grafana alert.
• Helm or Kustomize packages the app. Helm is the common language. Kustomize is the overlay.

A modern pipeline is not "build then kubectl apply." It is:

1. Test and scan on the pull request.
2. Build a signed OCI image and an SBOM.
3. Push to a registry (ECR, ACR, GAR, Harbor, GHCR).
4. Open a Git commit that bumps the tag in the env repo.
5. GitOps syncs. Rollout watches error rate. Fail and the canary dies.
6. Change event is written so AIOps can later say "this incident started six minutes after that SHA."

That last line is the DevOps-to-AIOps joint. If deploys are invisible, your correlation engine has no cause except "the moon."

CI/CD and automation tools, grouped by job

• Build: GitHub Actions, GitLab CI, Azure Pipelines, CircleCI, Buildkite, Tekton, Jenkins.
• Deliver: Argo CD, Flux, Spinnaker (legacy), Octopus, cloud-native CodePipeline / Cloud Deploy / DevOps release.
• Progressive delivery: Argo Rollouts, Flagger, LaunchDarkly-style flags.
• IaC: Terraform, OpenTofu, Pulumi, Bicep, CloudFormation, Crossplane if you want Kubernetes as the control plane.
• Config / desired state: Ansible (still fine for metal and VMs), Helm, Kustomize.
• Policy: OPA/Gatekeeper, Kyverno, HashiCorp Sentinel.
• Secrets: Vault, cloud secret managers, SOPS, External Secrets Operator.
• AI-in-the-pipeline: copilot review, test generation, flaky-test clustering. Useful. Not AIOps. Do not rename your Actions file and call the program done.

Monitoring, Observability, and Visualization

Monitoring asks "is it up?" Observability asks "why is it weird?" You need both. A green dashboard with no traces is a lie factory. A trace lake with no SLO is a hobby (Google SRE, 2016; Gartner, 2026).

The contract that matters now is OpenTelemetry. Instrument once. Export to whoever you pay this year. Gartner's observability definition now includes applications, infrastructure, and AI agents, with native OTel support as a must (Gartner, 2026). If your vendor still wants a proprietary agent as the only path, price the lock-in out loud.

The signals

• Metrics: cheap, numeric, good for SLOs and HPA. Prometheus, VictoriaMetrics, Mimir, cloud-native CloudWatch / Azure Monitor / Cloud Monitoring.
• Logs: expensive, high cardinality, still where the exception lives. Loki, Elasticsearch/OpenSearch, cloud log sinks.
• Traces: the request's path across 14 microservices. Tempo, Jaeger, Zipkin, vendor APM.
• Events / changes: deploys, scaling, feature flags, node death. The forgotten fourth signal. AIOps starves without it.
• Profiles and GPU telemetry: continuous profiling, DCGM for NVIDIA. Required once you serve models.

The open stack versus the paid suite

Open, common, and good enough for many teams: OpenTelemetry Collector, Prometheus, Grafana, Loki, Tempo (the LGTM stack), Alertmanager, maybe Grafana IRM. Add OpenCost or Kubecost for money. This is the default I would start on a greenfield cluster.

Paid suites that collapse the last mile: Datadog, Dynatrace, New Relic, Splunk Observability, Elastic Observability, Azure Monitor + App Insights, AWS X-Ray + CloudWatch, Google Cloud Operations. You pay to skip glue work and to get a stronger service map. Several of them now sell the AIOps layer as an add-on: anomaly detection, watchdogs, Davis, Watchdog, whatever the brand is this quarter (Network World, 2025).

Visualization that is not wallpaper

Grafana is the lingua franca. A useful board is built around a question:

• Are we burning the SLO?
• What changed in the last deploy?
• Which dependency is slow?
• Are we about to scale, or already late?
• For a model service: queue depth, TTFT, tokens per second, GPU memory, KV-cache hit rate.

Pretty red/green tiles with no unit and no owner are how on-call goes blind. One service, one SLO row, one drill-down to traces. Then let AIOps use the same queries as features, not a second copy of the truth.

Autoscaling and Scalability

Scaling is where DevOps automation and AIOps prediction shake hands. Classic DevOps writes an HPA: if CPU is above 70 percent, add pods. That is a thermostat. AIOps-shaped scaling asks a better question: will the queue explode in twelve minutes, and do we need a GPU node, not just another replica?

• Kubernetes HPA: CPU, memory, or custom metrics. Still the first tool. Fine for stateless HTTP.
• VPA: right-size the pod. Dangerous if you let it evict blindly. Use as a recommender first.
• KEDA: scale on Kafka lag, SQS depth, Prometheus queries, cron, or "requests waiting" on a model server. CNCF graduated. This is the workhorse for event-driven and inference queues (AWS, 2024).
• Cluster / node autoscaling: Cluster Autoscaler, Karpenter on AWS, GKE node auto-provisioning, AKS node pools. This is how GPUs appear when a training job or a vLLM replica asks.
• Cloud VM scale groups: ASG, VMSS, MIGs. Still real for the non-Kubernetes half of the company.
• Serverless: Lambda, Cloud Functions, Azure Functions, Cloud Run. The platform scales. You still observe cold starts and concurrency caps.
• Predictive / schedule-based: known peaks (9 a.m. login storm) should be a cron, not a surprise. Predictive AWS/Azure policies help. A model that scales on last month's Black Friday without a dry run will scale the wrong region.

Problem: a flash sale hits. HPA waits for CPU. CPU is fine because the app is blocked on checkout queue.
Cause: you scaled on the wrong signal.
Effect: latency dies, replicas stay at two. KEDA on queue depth, plus a load-test in CI, is the DevOps fix. Predicting the sale from marketing calendar plus last year's curve is the AIOps upgrade. Do the first before you buy the second.

Cloud Services: The Same Jobs, Three Catalogs

Pick a cloud for data gravity and people, not for a logo on a slide. The jobs stay the same.

Multi-cloud as a religion is expensive. Multi-cloud as "we can leave" is a Terraform module and OTel. AIOps products that only understand one vendor's events will lie about the other 40 percent of your estate. That is a buying criterion, not a footnote.

Deploying and Training AI Models (MLOps, Not a Rebrand)

Hidden Technical Debt in Machine Learning Systems is still the paper to hand a VP who thinks a Jupyter notebook is a product (Sculley et al., 2015). Models rot. Data shifts. A 2 percent accuracy drop can be a silent outage because no HTTP code turns red.

The path that matches a DevOps shop:

1. Data: versioned datasets, not a shared drive. DVC, a lakehouse table, or the cloud feature store (SageMaker Feature Store, Vertex Feature Store, Feast).
2. Train: a job, not a laptop. Kubeflow Training, SageMaker Training, Vertex Custom Jobs, Azure ML jobs, or Argo Workflows on a GPU pool.
3. Evaluate: holdout metrics plus, for LLMs, an eval harness (lm-eval, RAGAS-style checks, a golden prompt set). Gate the promote step on those numbers, the way you gate a canary on error rate.
4. Register: MLflow Model Registry, or the cloud registry. Name, version, lineage, who approved.
5. Package: a container, or a model URI that KServe / SageMaker / Vertex can pull. Sign it.
6. Serve: KServe for classic ML, vLLM or TensorRT-LLM for large language models, or a managed endpoint (SageMaker, Azure ML online, Vertex prediction, Bedrock/Azure OpenAI if you are calling a hosted API).
7. Observe the model: not only pod CPU. Drift, token latency, quality scores, GPU memory, queue depth. This telemetry is what AIOps later correlates with "checkout conversion fell."
8. Retrain or rollback: a GitOps tag back to the last good model is a first-class incident action.

Inference in 2026 has its own DevOps dialect: NVIDIA GPU Operator, MIG or time-slicing, KV-cache-aware routing, scale-to-zero for overnight dev models, KEDA on num_requests_waiting. That is still DevOps. The AIOps layer is "this model's p95 TTFT just left the SLO and it started six minutes after we shipped tokenizer X."

Automation: Scripts, GitOps, Then Closed Loops

Automation is a ladder. Climb it in order.

1. Manual with a checklist. You cannot automate a process you cannot name.
2. Scripted. Bash, Python, Ansible. Fine for a fleets of VMs. Still the glue.
3. Pipeline. CI/CD runs the script the same way every time.
4. Reconcile. GitOps and controllers. Drift is an error, not a lifestyle.
5. Policy. The cluster refuses a privileged pod. Humans stop being the linter.
6. Suggested action. AIOps says "roll back SHA abc, 80 percent confidence." A human clicks.
7. Closed loop. The same action runs inside a blast-radius box: only this namespace, only this runbook, only if the SLO is already burning.

Most companies that "bought AIOps" are stuck on step 2 with a nicer UI. The ones that get value already had steps 3 to 5. That is the entire thesis of this post in one ladder.

How a DevOps Team Becomes an AIOps Practice

You do not hire a prophet and a new logo. You grow the data and the trust.

1. Instrument everything that pages you. OTel SDK or auto-instrumentation on the top 20 services. No orphans.
2. One collector, one schema. Resource attributes: service.name, deployment.environment, version, team. This is how later clustering works.
3. Emit change events. Every Argo sync, every flag flip, every Terraform apply. Put them next to metrics.
4. Build a service map you would bet money on. Even a simple ownership YAML plus generated topology beats folklore.
5. Reduce monitors. Delete the ones nobody has acted on in 90 days. AIOps on junk is expensive junk.
6. Correlate before you predict. Dedup and grouping pay back in week one. Prediction is year two.
7. Suggest, then automate one runbook. Restart a known-stuck worker. Scale a known queue. Rollback a canary. Measure how often the human overrides.
8. Feed overrides back. If operators always reject a class of alerts, the model should learn or the monitor should die.
9. Put AI actions behind the same GitOps door. An auto-fix that kubectl-edits prod and leaves no commit is a ghost. Write the revert as a PR or a recorded sync.
10. Keep people. AIOps removes toil, not accountability. The on-call still owns the SLO. The model is a junior that never sleeps and sometimes hallucinates a root cause.

Problem: leadership bought a platform after a terrible quarter of incidents.
Cause: they wanted a brain. They had no consistent service names and three conflicting CMDB-ish spreadsheets.
Effect: the demo looked smart on vendor data. On yours it grouped nothing. Spend the first quarter on naming, OTel, and deploy events. Then turn the model on. That sequence is how DevOps becomes AIOps without a reorg theater.

What Really Matters Now

Ignore the slide that says "AI will replace Ops." The constraints that actually decide whether you ship and stay up in 2026:

• Telemetry cost. Logs will bankrupt you before models will save you. Sample, drop debug in prod, keep traces on the error path. Gartner now rates vendors on retention controls for a reason (Network World, 2025).
• Open standards. OTel, Prometheus remote write, Git, OCI. These outlive the AIOps logo on this year's PO.
• Change awareness. The highest-signal feature in any incident tool is "what shipped?" Wire GitOps into the incident object on day one.
• SLOs over raw alerts. Page on user pain, not on a disk that is allowed to be busy.
• Progressive delivery. A bad model or a bad binary should hit 5 percent of traffic, not 100 percent. Canary plus auto-rollback is worth more than a clever chatbot in Slack.
• GPU and queue signals. If you serve models, CPU HPA is a museum piece. Watch queue and TTFT.
• Identity and blast radius. Closed-loop remediation with a god-mode service account is how you automate a worse outage. Scoped roles, dry-run, and an audit trail.
• Platform, not heroics. One paved road. Ten unique Jenkinsfiles is why AIOps has nothing consistent to learn from.
• Humans who can still debug. When the model is wrong, someone must read a trace. That is still a DevOps skill. Teach it. The last post on visual programming was not a detour. Logic still comes before the copilot.

A Worked Example

Imagine a checkout API on EKS, a payments worker on a queue, and a fraud model on KServe.

DevOps layer. Code lives in GitHub. Actions runs tests and Trivy. The image is signed and stored in ECR. A tag bump in the env repo is synced by Argo CD. Rollouts sends 10 percent of traffic to the new checkout. Terraform owns the cluster and the IAM roles. HPA covers the API. KEDA covers the worker. The model has its own deploy pipeline and an MLflow version.

Observability layer. Each service emits OTel traces. RED metrics (rate, errors, duration) sit in Prometheus. Grafana has one checkout SLO board. Deploy events are annotations. The fraud model exports drift and score-latency.

AIOps layer. At 18:40 error rate climbs. Raw alerts: API 5xx, worker lag, KEDA scale events, a CloudWatch RDS CPU blip, and fraud latency. Correlation groups them. Enrichment shows a model version bump at 18:34 and a schema field the worker now drops. Suggestion: roll back model v17, not the API. A human confirms the first time. The second time, policy allows auto-rollback of that model registry stage only. MTTR is 11 minutes instead of 90. The GitOps repo has a commit that says why.

That is the whole architecture in one incident. No new job family required. A DevOps team that kept its telemetry honest, plus one closed loop.

What to Buy, What to Build

• Build (or standardize) the paved road: Git, CI, GitOps, OTel collector, a default dashboards folder, naming rules.
• Buy or adopt when glue hurts: a full observability suite if you lack people to run LGTM. An event-intelligence product when you already have more than ~20 noisy sources and a real CMDB/service catalog.
• Rent GPUs and model APIs: SageMaker, Vertex, Azure ML, Bedrock, Azure OpenAI. Keep registry, eval gates, and rollback in your repo.
• Do not buy: a second CI system "for AI," an AIOps tool before you have service names, or a copilot seat as a substitute for on-call training.

DevOps made change a habit. AIOps makes sense of the exhaust that habit creates. MLOps is the same habit applied to models. The fashion is to flatten all three into "we are an AI-driven enterprise." The work is plainer. Name the services. Ship through Git. Watch with OpenTelemetry. Scale on the signal that hurts. Let a model group the pages only after those sentences are true.

If you remember one line: AIOps is not a replacement for DevOps. It is DevOps with a memory, a map, and a brake.

References

• Amazon Web Services. (2024). Autoscaling Kubernetes workloads with KEDA using Amazon Managed Service for Prometheus metrics. https://aws.amazon.com/blogs/mt/autoscaling-kubernetes-workloads-with-keda-using-amazon-managed-service-for-prometheus-metrics/
• Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (Eds.). (2016). Site reliability engineering: How Google runs production systems. O'Reilly.
• Cloud Native Computing Foundation. (2024). Platforms white paper. CNCF. https://www.cncf.io/
• Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The science of lean software and DevOps. IT Revolution.
• Gartner. (2025). Market guide for event intelligence solutions. Gartner.
• Gartner. (2026). Observability platforms. Gartner. https://www.gartner.com/reviews/market/observability-platforms
• Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps handbook. IT Revolution.
• Kim, G., Behr, K., & Spafford, G. (2013). The Phoenix Project. IT Revolution.
• Network World. (2025). In crowded observability market, Gartner calls out AI capabilities, cost optimization, DevOps integration. https://www.networkworld.com/article/4032218/in-crowded-observability-market-gartner-calls-out-ai-capabilities-cost-optimization-devops-integration.html
• OpenTelemetry Authors. (2024). What is OpenTelemetry? https://opentelemetry.io/docs/what-is-opentelemetry/
• Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F., & Dennison, D. (2015). Hidden technical debt in machine learning systems. In Advances in Neural Information Processing Systems 28.
• TechTarget. (2024). AIOps vs. DevOps: Distinct approaches to IT automation. https://www.techtarget.com/it-infrastructure/feature/AIOps-vs-DevOps-Distinct-approaches-to-IT-automation

Read More