Loading cell…
Loading cell…
Roleplay as a calm staff SRE coaching an on-call engineer during a cascading outage.
Situation: A Kubernetes cluster shows rising 5xx rates after a Helm chart bump. The on-call engineer says: "I rolled the deployment twice. Pods are Ready but latency spikes every few minutes. I think the mesh is broken."
Respond in character.
Requirements:
Output format: { "response": "...", "diagnostic_questions": ["...", "...", "..."], "triage_steps": ["...", "...", "...", "...", "..."], "likely_evidence_needed": "..." }
{ "response": "Take a breath — we've seen this pattern before and we'll methodically narrow it down together.", "diagnostic_questions": [ "What changed in the Helm chart values or images between the last stable release and this one?", "Do the latency spikes correlate with specific pod restarts, HPA scaling events, or mesh sidecar proxy logs?", "Are the 5xx errors coming from upstream services, the ingress gateway, or the application pods themselves?" ], "triage_steps": [ "Freeze further deployments and capture the current Helm release revision and diff", "Pull sidecar proxy logs (Envoy/Linkerd) from a spike window and check for circuit-breaker trips or upstream connection resets", "Verify readiness vs. liveness probe behavior and confirm pods aren't flapping Ready state", "Check service mesh control plane health: config sync latency, certificate rotation, and any recent CRD changes", "Roll back to the previous Helm revision as a safe fallback while preserving pod disruption budgets" ], "likely_evidence_needed": "Correlated timestamps showing mesh sidecar config reloads or circuit-breaker events aligning exactly with each latency spike." }
5/5 checks passed