<- Back to featured projects

Draft Case Study

AIOps for AKS - Anomaly Detection and Platform Reliability

Platform teams need earlier visibility into AKS anomalies and deployment risk while maintaining controlled remediation and operational governance.

AIOpsAKSManaged PrometheusGrafanaContainer InsightsReliability

Problem

Platform teams need earlier visibility into AKS anomalies and deployment risk while maintaining controlled remediation and operational governance.

Architecture

Reference architecture (proposed): AKS telemetry from Azure Monitor managed Prometheus, Grafana, Container Insights, and Log Analytics is aggregated into an analysis workflow. AI-assisted reasoning helps classify workload health and deployment-failure patterns, then proposes controlled next actions for human-approved remediation.

AKS SignalsAnomalyApprovalRunbooks
Proposed reference architecture for AKS AIOps anomaly analysis, operator review, and controlled remediation flows.

Reference/proposed architecture diagram for portfolio demonstration. Not a client production architecture.

Architecture Explorer

AKS AIOps Reliability: Anomaly detection with controlled remediation workflow.

Proposed

Data flow: AKS runtime signals feed anomaly analysis and recommendation workflows, then human-approved remediation executes runbooks.

Accessible alternative: use the component buttons below to inspect architecture details without zoom.

Legend

  • Ingress / Trigger
  • Orchestration
  • Data / Storage
  • Security
  • Observability
  • Operations
  • AKS Runtime Signals ~> Observability Stack (signal ingestion)
  • Observability Stack -> Anomaly Analyzer (analysis stream)
  • Anomaly Analyzer -> AIOps Brief (insight output)
  • Anomaly Analyzer -> Runbook Controls (recommended action)
  • AIOps Brief -> Runbook Controls (operator context)

Component Details

AKS Runtime Signals

Collect workload, node, and deployment telemetry.

Responsibilities: Metrics stream | Deployment event intake

Security controls: Namespace-scoped telemetry access

Dependencies: Anomaly Analyzer

Design decisions: Multi-signal observability to reduce single-metric bias.

Security

Reference security controls include namespace-scoped access, role-based Grafana/monitoring permissions, managed identity for automation components, and audited approval trails for remediation actions.

Verified Outcomes

  • Reference design for portfolio demonstration; no production reliability metric claim.
  • Draft: improved AKS incident triage context using combined metrics, logs, and deployment events.
  • Draft: safer remediation posture through mandatory approval and rollback-oriented workflows.

Interactive Demo

Explore a local technical simulation with deterministic logic, explainable state transitions, and no live cloud integration.

Try Interactive Demo

Design Decisions

  • Combine metrics, logs, and events to avoid single-signal anomaly bias.
  • Treat anomaly scoring as decision support; do not claim predictive certainty without validated models.
  • Require operator checkpoints before production remediation to reduce unintended service impact.

Implementation

  • Stream AKS telemetry from managed Prometheus, Container Insights, and Log Analytics.
  • Apply anomaly-detection and failure-pattern rules for workload health and release regression signals.
  • Generate AIOps incident briefs that include probable contributing factors and suggested runbook paths.
  • Execute remediation only through controlled workflows with explicit human approval and rollback plans.

Trade-offs

  • Higher observability depth improves diagnosis but increases signal volume and tuning effort.
  • Conservative remediation controls reduce automation risk while limiting immediate hands-off recovery.
  • Detection quality depends on baseline calibration and continuous review of false positives.

Engineering Evidence

Implemented demo evidence

Architecture Evidence

Diagram classification: Proposed

Sanitized data flow: AKS runtime signals aggregate into anomaly analysis and AIOps briefs, then approved runbook controls apply remediation decisions.

Diagram source id: aks-aiops-platform-reliability

Linked Demo Routes

Automated Tests and Results

  • Incident lifecycle and remediation controls used by the AIOps demo

    tests/aiops-incident-lab.test.ts

  • Diagram validation and explorer rendering

    tests/architecture-explorer.test.ts

Latest test run (2026-09-26): Automated tests passed for pipeline simulator logic, AIOps incident lab logic, architecture explorer coverage, project evidence integrity checks, and Landing Zone IaC artifact checks.

Command: node_modules/.bin/tsc.cmd -p tsconfig.test.json && node --test .test-dist/tests/**/*.test.js

Latest build run (2026-09-26): Production build completed successfully with prerendered case-study routes and both interactive demo routes.

Command: node_modules/.bin/next.cmd build

Limitations and Verification Gaps

  • AKS-specific anomaly and runbook execution is represented by shared simulation logic, not a live cluster integration.
  • No production SLO or reliability metric evidence is included.

Evidence Pending

  • Manual verification needed for real AKS telemetry and runbook integrations outside this repository.

Evidence Status

  • Local checks: Local demo logic and unit tests executed in repository.
  • CI checks: Uses repository test/build checks; no external cloud credentials required.
  • Azure deployment: Not performed / Evidence pending.

Reproduction and Dependencies

Dependencies

  • Node.js (current project uses Next.js 16.x, React 19.x, TypeScript 6.x)
  • npm install
  • Local binaries under node_modules/.bin for lint/typecheck/test/build

Reproduction steps

  1. npm install
  2. node_modules/.bin/tsc.cmd -p tsconfig.test.json
  3. node --test .test-dist/tests/**/*.test.js
  4. node_modules/.bin/next.cmd build