Insights | Neeraja Khanapure

CI/CDCI/CD isn't speed. It's predictable change under load ObservabilityObservability is a label strategy problem disguised as a tooling problem AIOpsAIOps isn't auto-healing. It's faster, safer incident reasoning

CI/CD

cicdreliabilitysre

CI/CD isn't speed. It's predictable change under load

Most pipelines fail not because tests are slow, but because rollout risk isn't modeled, blast radius, rollback, and observability gates are afterthoughts that only matter when something goes wrong.

At scale, the fastest teams are the ones who can rollback in minutes and prove safety with metrics, not the ones who can click Deploy more often. Velocity is downstream of confidence. Confidence is downstream of observability gates and rehearsed rollback.

What I've seen go wrong

Treating "all tests pass" as "safe to deploy". Your test suite doesn't know about your production traffic patterns, cache state, or database connection pool saturation.
Rollback is an untested code path. Teams practice deploying constantly; they practice rolling back maybe once a year. The one time you need it under pressure, the runbook is stale.

If you can't explain rollback + SLO gates in one slide, the pipeline is not production-ready.

Observability is a label strategy problem disguised as a tooling problem

You can't debug what you can't slice. Most 'noisy dashboards' problems are really missing ownership labels, inconsistent dimensions, and no SLI intent, not a Prometheus or Grafana problem.

Teams add more metrics and still can't answer: which customer segment is broken, or which rollout caused it. The cardinality is wrong in the places that matter. The fix isn't more tools. It's defining the question (SLI) and designing labels that let you isolate (service, env, version, tenant) without blowing up cardinality.

What I've seen go wrong

Importing a community dashboard with 200 panels and calling it 'observability', if you can't explain what each panel is answering during an incident, it's decoration.
High-cardinality labels on the wrong dimensions, user_id as a Prometheus label is a cardinality bomb. tenant_tier or region is usually the right granularity.

Define SLIs first, then design labels that let you isolate the failure. Everything else is supporting context.

AIOps isn't auto-healing. It's faster, safer incident reasoning

AI is best at compressing signal: summarizing anomalies, correlating events across systems, and ranking likely causes. So humans can validate and decide quickly. Not so humans can step back entirely.

If the model can't show evidence, metrics, logs, traces, behind a hypothesis, it becomes hallucination-as-a-service. The danger isn't that AI gets it wrong; it's that a confident wrong answer at 2am leads an on-call engineer down the wrong path for 45 minutes.

What I've seen go wrong

Auto-remediation without approval gates, AI identifies the fix, triggers the restart, nobody knows what happened. Until the "fix" made things worse.
Trusting anomaly detection on raw metrics without context, a CPU spike looks identical whether it's a traffic surge, a runaway job, or an attack. The model needs the context humans have.

Use AI for hypothesis ranking + runbook retrieval; keep remediation behind explicit approvals and guardrails.