Deploy, cost, latency, observability
Runbook
Write an ops checklist for your service
- Serving and streaming (browse)
- Networking for AI apps (browse)
- Cost and latency routing (browse)
- OpenTelemetry for LLMs (browse)
- MLflow for LLMOps (browse)
- Cost control for LLM apps: cache, shrink, and route (example)
- Observability for LLM apps: traces, evals, and user feedback (example)
- Netflix-style LLM gateway: batching, KV cache, and one API (example)
- Multi-tenant AI SaaS: isolation, quotas, and noisy neighbors (example)
Learning objectives
- Write an ops checklist for your service
- Include rollback and key rotation
- [object Object]
Serving platforms vs training stacks
Netflix-class serving problems: routing models, latency SLOs, caching, gradual rollouts, observability — what this module covers. Meta-class training problems: thousand-GPU efficiency, checkpoint sharding, data pipelines — different team, different runbooks. Your ops checklist should reflect inference and agent serving, not pretend you operate a pretraining cluster.
A runbook is the document a tired engineer follows at 2am — commands, not architecture essays.
Runbook sections
Minimum RUNBOOK.md:
- Service overview — what it does, owner, on-call rotation (can be "you").
- Dependencies — model provider, vector DB, MCP servers, secrets location.
- Health checks —
/health, canary command, expected latency. - Deploy — steps, flags, smoke test after deploy.
- Rollback — previous image/tag, prompt version revert, feature flag off.
- Incidents — symptom → diagnosis → mitigation tables.
- Key rotation — provider API keys, JWT secrets, without downtime plan.
- Cost emergency — disable route, lower max_steps, switch model tier.
Callout — Rollback prompt version: Git revert is not enough if prod loads prompts from object storage — document prompt artifact versioning and pointer rollback.
Incident playbooks (examples)
| Symptom | Likely cause | First actions |
|---|---|---|
| p95 latency 3× | slow tool, cache cold | check waterfall traces |
| 429 spike | retry storm | enable circuit breaker, reduce concurrency |
| canary fail after deploy | prompt regression | rollback prompt pointer |
| cost alert | runaway loop | disable feature flag, inspect max_steps |
Link each to dashboards/log queries (grep trace_id, canary_history.jsonl).
Key rotation without drama
Procedure stub:
- Issue new key in provider console.
- Dual-write secrets manager entries
API_KEY_PRIMARY,API_KEY_SECONDARY. - Deploy reading primary; validate traffic.
- Swap primary; revoke old after 24h.
Document for each secret your service uses.
Close Milestone 11
Milestone acceptance — deployed service (local docker counts if documented):
- FastAPI + SSE API (11.1)
- Per-request cost logging + rollup (11.2)
- Cache experiment with benchmarks (11.3)
- JSONL traces + waterfall (11.4)
- Resilient client (11.5)
- RUNBOOK.md (this lesson)
milestone-11.md— one-page ops summary + demo URL or curl
Industry comparison note: your mini gateway parallels Netflix-style model routing at toy scale — cite in milestone doc, do not overclaim.
On-call readiness without on-call
Solo portfolio still benefits from runbook: future you is on-call. Include "first day with repo" section: where secrets live, how to get read-only prod logs, who to email for vendor outage (status page links).
Post-incident template
After any sev-worthy bug (data leak near-miss, day-long outage in prod if you have one), append postmortem to incidents/YYYY-MM-DD.md: timeline, root cause, action items with owners. Course capstone can use tabletop incident as practice postmortem — still valuable.
Capacity planning stub
Document expected RPS and tokens/day at 10× current demo usage; note which component breaks first (API worker count, provider TPM, vector QPS). Connects Meta literacy (scale) to your serving reality without overbuilding.
Putting it together in practice
ShipAI treats this lesson as executable curriculum, not reading alone. Before marking complete, trace one real request through your portfolio stack and label where this lesson's concepts apply — even if the first pass is messy. Document what broke in the module README; that gap list becomes your next sprint.
Compare your implementation against the industry callouts cited earlier without copying their scale. Name one deliberate simplification you kept (mock auth, SQLite not Postgres, single-region deploy) and one simplification you refuse to ship without (no eval gate, no trace on mutating tools, no fail-closed guardrail on exfil cases). That contrast is what interviewers and graders look for.
Callout — Teach back: Explain this lesson's core tradeoff to a peer in five minutes without slides. If you cannot, re-read the failure modes section and add an example from your own run logs.
Common questions and misconceptions
"Is this overkill for a side project?" Side projects can skip pieces; capstones and production cannot skip knowing the pieces exist. You may waive cost accounting in v1 but your architecture diagram should still show where it would attach.
"Should I rewrite from scratch?" Extend what you built in prior modules — graders reward evolution, not parallel unused folders. Link file paths in your checklist.
"Which metric matters most?" The metric tied to user harm or revenue: policy violations, failed refunds, silent wrong answers — not vanity leaderboard scores.
Extension paths after the micro-project
After the micro-project passes smoke check, choose one extension aligned with your capstone pillar: tighten eval coverage, add a chaos or red-team case, or wire observability into SSE streams. Extensions belong in BACKLOG unless scope freeze explicitly includes them — avoids capstone death by optional polish.
Engineering problem (staff framing)
On-call needs runbooks: symptoms → checks → mitigations → communications.
Diagram — Incident loop
flowchart TD
Alert --> Triage --> Mitigate --> Confirm --> Postmortem
Precise definitions & mental model
SLO burn, rollback, degrade modes (smaller model, disable tools).
Tradeoffs — when to use what
Auto-rollback vs human confirm.
Failure modes (interview + on-call)
No owners; tribal knowledge; no degrade path.
Production & OSS practices
Page-worthy alerts only; quarterly game days.
Micro-project: Ops checklist for your service
Ship:
- Complete RUNBOOK.md with all sections above.
- Execute tabletop exercise: simulate canary fail — write timestamps as if real.
- Document rollback you actually tested (revert one commit or flag).
- milestone-11.md linking cost sample, trace waterfall screenshot, runbook.
- README "Production readiness" checklist derived from runbook.
Acceptance: stranger follows runbook deploy + smoke sections successfully.
Checklist
- RUNBOOK.md complete with rollback and key rotation
- Tabletop incident exercise documented
- Milestone 11 doc with cost + traces evidence
- Deploy/smoke steps tested once
- Module README points to on-call owner and health URL
ShipAI delivery model is: