Intermediate everything in DevOps & Cloud, page 3
Little's Law for capacity planning
L equals lambda times W, concurrency equals arrival rate times time in system; rearrange to size threads or concurrency for a target throughput and latency.
Capacity planning for annual traffic spikes
Forecast peak from history, load-test to find per-unit capacity, use autoscaling with pre-warming and headroom, and protect with caching and graceful degradation.
Diagnose database CPU saturation under load
Find the expensive queries via the database's stats, check for missing indexes and full scans, then fix with indexing, query rewrites, caching, or read replicas.
Client-side vs server-side feature flags
Client-side is fast and offline-capable but exposes flag logic and risks stale or leaked values; server-side keeps logic secret and consistent but adds latency.
Design automated canary analysis scoring
Track the golden-signal SLIs, compare canary to baseline statistically, weight and combine into a score with promote/rollback thresholds.
Diagnose a degraded canary release
Check statistical significance versus baseline, confirm apples-to-apples comparison, isolate the cause via traces and logs, then weigh the regression against SLO budget.
Blue-green deploys with schema migrations
The shared database means both versions hit one schema, so breaking changes must be split into backward-compatible steps via expand-and-contract.
Design automated microservice provisioning workflow
Template scaffolding plus a pipeline that creates repo, CI/CD, and infra as code, with idempotent steps and rollback.
Systematically reduce noisy alert toil
Inventory alerts, measure frequency, actionability, and time cost, then prioritize by volume times effort.
Idempotency in infrastructure provisioning scripts
Idempotency means repeated runs converge to one end state; achieve it via desired-state reconciliation or idempotency keys with read-before-write.
Proximate cause versus root cause
Proximate cause is the immediate trigger, root cause is the systemic condition that allowed it; fix the root to prevent recurrence.
Resolving post-mortem disagreement with data
Anchor the debate in the timeline, deploy events, traces, and metrics; correlate cause and onset; allow multiple contributing factors.
Why 'human error' is not a root cause
Human error is a starting symptom; ask why the system allowed it, find missing guardrails.
Conducting a blameless post-mortem in practice
Focus on systems not individuals, assume good intent, use neutral language and facilitation, end with owned action items.
Fast rollback versus targeted fix in an incident
Weigh time-to-recovery and blast radius against rollback side effects; prefer restoring service fast, gated by data like deploy diff and migration risk.
Designing a SEV1-SEV4 severity matrix
Tie levels to user impact, scope, and SLO burn with concrete thresholds; map each to response and escalation.
Designing an escalation policy
Define timeout-based escalation tiers, multiple notification channels, secondary and management layers, coverage across time zones, and severity-based routing.
Anatomy of an effective runbook
Alert meaning and impact, diagnostic steps with dashboard and query links, concrete remediation with rollback, and escalation contacts.
SLO-based alerting and error budgets
Define SLI/SLO, derive an error budget, alert on how fast you burn it using multi-window multi-burn-rate rules so fast burns page and slow burns ticket.
Fixing a noisy non-actionable alert
Review the data to see if it is ever actionable, then tune threshold or duration, re-target at user-facing symptoms, or delete it.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles