Learn the stack in the order an SRE operates it.
The fastest useful path is to build one mental model at a time. Start with what the model is, then learn the application layers around it, and only then go deep on production operations.
AI, ML and LLM fundamentals
Understand the difference between AI, machine learning, neural networks, transformers and large language models. Learn tokens, context, inference and why a model is only one component of the production system.
Start with AI →Prompts, APIs and application behavior
Learn how applications call models, how context is assembled, how streaming behaves, and why rate limits, timeouts, retries and provider quotas become operational concerns.
Browse the complete learning path →RAG, embeddings and knowledge systems
Retrieval-Augmented Generation adds ingestion, embeddings, vector databases, ranking, authorization and data freshness to the request path. These are dependencies with their own latency and failure modes.
Learn RAG →Agents, tools and MCP
Agents turn model output into actions. Once an AI system can call tools or use MCP, SREs must reason about loops, state, permissions, downstream services, blast radius and safe containment.
Learn agents → Learn MCP →LLMOps, model serving and GPU capacity
Move into inference servers, GPUs, VRAM, batching, KV cache, routing and autoscaling. This is where familiar capacity engineering returns, but the scarce resources now include context length, tokens and accelerator memory.
LLMOps roadmap → GPU basics →Reliability, observability and SLOs
Measure the experience users actually receive: availability, task completion, latency, TTFT, TPOT, answer quality, retrieval quality, tool success, provider health and cost. Build SLOs around the critical user journey.
Observability guide → SLO concept →Security, incidents and FinOps
Production AI needs trust boundaries, least privilege, prompt/RAG/tool defenses, kill switches, provider failover, incident runbooks and cost controls. Reliability includes safe behavior and sustainable spend.
AI FinOps → AI Security Engineering →HTTP 200 is only the beginning.
An AI service can be technically reachable and still fail the user. A useful operating model combines traditional service telemetry with AI-specific signals.
Can the user complete the task, including critical dependencies?
How long until the first generated token makes the system feel alive?
How quickly does output arrive once generation begins?
Is the answer relevant, grounded, safe and useful?
Do agent actions and downstream calls actually complete correctly?
Are the right documents available, fresh and authorized?
Are queues, concurrency, GPU memory and provider limits under control?
What does each successful request or task cost, and is spend drifting?
Production rule: optimize the complete user journey, not the component with the most familiar dashboard.
Think in dependencies, not just models.
A modern AI request can cross authentication, an API gateway, prompt assembly, retrieval, vector storage, reranking, model inference, tool calls, policy checks and output validation. Any one of those components can dominate latency or cause the task to fail.
User
↓
AI Gateway / Application
↓
Prompt + Context ──→ Retrieval / Vector DB
↓ ↓
Model / Provider ←─────────┘
↓
Agent / Tools / MCP
↓
Validation / Policy
↓
User-visible result
Across every hop:
metrics · traces · evals · security · cost · ownershipTriage the failure domain before applying a generic retry.
AI incidents often look similar from the outside but require different mitigations. A slow answer could be queue saturation, provider throttling, oversized context, slow retrieval or a tool dependency. A bad answer could be model regression, stale knowledge, retrieval ranking, prompt changes or policy failure.