Reliability, Observability, and Incident Response Questions
Covers designing, building, and operating systems to be reliable, observable, and resilient, together with the operational practices for detecting, responding to, and learning from incidents. Instrumentation and observability topics include selecting and defining meaningful metrics and service level objectives and service level agreements, time series collection, dashboards, structured and contextual logs, distributed tracing, and sampling strategies. Monitoring and alerting topics cover setting effective alert thresholds to avoid alert fatigue, anomaly detection, alert routing and escalation, and designing signals that indicate degraded operation or regional failures. Reliability and fault tolerance topics include redundancy, replication, retries with idempotency, circuit breakers, bulkheads, graceful degradation, health checks, automatic failover, canary deployments, progressive rollbacks, capacity planning, disaster recovery and business continuity planning, backups, and data integrity practices such as validation and safe retry semantics. Operational and incident response practices include on call practices, runbooks and runbook automation, incident command and coordination, containment and mitigation steps, root cause analysis and blameless post mortems, tracking and implementing action items, chaos engineering and fault injection to validate resilience, and continuous improvement and cultural practices that support rapid recovery and learning. Candidates are expected to reason about trade offs between reliability, velocity, and cost and to describe architectural and operational patterns that enable rapid diagnosis, safe deployments, and operability at scale.
MediumTechnical
47 practiced
Discuss trace sampling strategies for a high-throughput microservices data platform producing millions of traces per hour. Compare head-based sampling, tail-based sampling, adaptive sampling, and event-driven sampling. For each approach, explain implications for cost, debugging rare errors, and how you would preserve traces for error cases.
Sample Answer
Start with a short definition: sampling reduces telemetry volume by selecting which traces to store/ingest. For a high-throughput microservices platform (millions of traces/hour) you must balance cost, observability for rare errors, and system overhead.Head-based sampling- What: decide at trace start (agent/SDK) to keep or drop (probabilistic).- Cost: lowest ingestion/compute cost and minimal downstream processing.- Debugging rare errors: poor — many rare/faulty traces are dropped before you know they’re important.- Preservation: add lightweight metadata (trace ID, sampled flag, error hint counters) and use deterministic rules (e.g., sample all traces from critical services or by user ID) to increase chance of keeping important traces.Tail-based sampling- What: collect and buffer spans temporarily, evaluate full trace (e.g., error status, latency, anomaly) then decide to keep.- Cost: higher CPU/memory and network (buffering, extra processing) but more efficient at retaining diagnostically useful traces.- Debugging rare errors: best for catching late-manifesting errors (timeouts, error spans) because decision uses full trace.- Preservation: maintain a short-duration span buffer (in-memory or streaming topic with TTL) and only persist full traces that meet rules.Adaptive sampling- What: dynamically adjust sampling rates per service/endpoint based on traffic and error signals (e.g., target throughput per key).- Cost: medium — more control reduces waste; needs control-plane logic.- Debugging rare errors: better than static head-based because low-traffic but important signals can get higher sampling; still may miss truly rare anomalies without additional rules.- Preservation: compute per-key reservoirs (per-service/route/user) and increase sampling on anomaly detection; log effective sampling rate with trace metadata so analysts can scale metrics.Event-driven sampling (rule-based)- What: sample when external events occur — alerts, SLO breaches, logged exceptions, feature flags.- Cost: targeted; inexpensive if event streams are compact.- Debugging rare errors: excellent when events reliably indicate problems; depends on event coverage.- Preservation: link alerting/telemetry pipelines (alerts, logs, metrics) to a trace-capture path that forces retention (e.g., when an alert fires, tag and persist related trace IDs).Practical hybrid design (recommended)- Use low-overhead head-based default sampling (e.g., 1-5%) to control baseline cost.- Add deterministic sampling rules for critical services and important user segments.- Implement a tail-based tier: buffer recent spans in Kafka/Redis for a short TTL (tens of seconds) and run a rule engine to persist traces exhibiting errors/high latency.- Add adaptive control to raise sampling for noisier or error-prone endpoints and to maintain a stable ingestion budget.- Integrate event-driven hooks: when alerts/log anomalies occur, look up trace IDs in buffers and force-export full traces.- Record sampling metadata (effective rate, reason kept) in spans so analysts can correct for selection bias.Trade-offs summary- Cost: head < adaptive ≈ event-driven < tail (due to buffering/compute).- Rare-error debugging: tail ≈ event-driven > adaptive > head.- Operational complexity: head simplest; tail and adaptive require buffering, control-plane, and tuning.Implementation notes- With OpenTelemetry/Jaeger: enable local decisions in SDK, emit lightweight trace IDs to logs/metrics, stream spans to Kafka for short-term retention, run a tail-sampling processor (e.g., jaeger-collector or custom consumer) that persists selected traces to long-term storage.- Always tag traces with sampling_reason and effective_rate; store minimal indices (traceID → timestamp/error flags) so event-driven lookups can rehydrate traces from buffers.This hybrid approach keeps costs bounded while ensuring you can capture and debug rare, high-value failures.
EasyTechnical
54 practiced
Explain SLI, SLO, and SLA and how they relate to data platform reliability. For a reporting ETL that must deliver fresh data for business reports, propose one SLI, one SLO (with numeric target), and an SLA-level consequence, and justify your choices including measurement method and window.
Sample Answer
SLI, SLO, SLA — short definitions and how they tie to data-platform reliability:- SLI (Service Level Indicator): a measurable metric that reflects service behavior (what we monitor).- SLO (Service Level Objective): a target or acceptable range for an SLI (a reliability goal).- SLA (Service Level Agreement): a contractual promise to customers that often includes penalties if SLOs aren’t met.Context: reporting ETL that must deliver fresh data for business reports.- SLI (proposed): Percentage of scheduled reports whose underlying dataset partitions are updated with the latest source data before the report run time.- Measurement method & window: For each scheduled report run, check whether the ETL completed successfully and wrote the latest partition timestamp >= source cutoff. Compute hourly over a 30-day rolling window: SLI = (successful fresh runs) / (total scheduled runs) * 100.- SLO (numeric): 99.5% of scheduled report runs must have fresh data over any 30-day window.- SLA-level consequence: If monthly availability (30-day window) falls below 99.5% two months in a row, vendor credit = 10% of that month’s support invoice and a joint postmortem with a remediation timeline within 7 days.Justification:- SLI targets freshness directly (business cares about fresh data).- Hourly check aligns with report cadence and gives fast detection; 30-day window smooths transient blips while enforcing sustained quality.- 99.5% balances operational effort vs business impact (≈1–2 failures/month for daily reports).- SLA consequence mixes financial incentive and mandatory remediation to ensure accountability without extreme penalties.
HardTechnical
60 practiced
As a data engineering lead, propose an organization-wide SLO policy that covers streaming ingestion, batch ETL, and analytics query latency. Define SLO tiers, error budgets, enforcement mechanisms, developer workflows when budgets are exhausted, and incentives to balance velocity and reliability.
Sample Answer
Overview: I propose a tiered, measurable SLO policy across three surface areas—streaming ingestion, batch ETL, and analytics query latency—backed by error budgets, automated enforcement, clear developer workflows when budgets exhaust, and incentive structures to balance velocity and reliability.SLO tiers (examples):- Platinum (business-critical): 99.99% availability / freshness SLA (max 52 min monthly downtime); e.g., finance feeds, regulatory reports.- Gold (important): 99.9% / freshness within 15 minutes; e.g., near-real-time dashboards.- Silver (operational/adhoc): 99% / freshness within 24 hours; e.g., exploratory datasets.Surface-specific metrics:- Streaming ingestion: event delivery success rate, end-to-end lag (p50/p95/p99), data completeness.- Batch ETL: job success rate, latency percentile, freshness (time since source commit), and row-count drift.- Analytics query latency: p50/p95/p99 query time for defined SLAs per dashboard/BI workload and throughput limits.Error budgets:- Error budget = 1 - SLO. Tracked daily and rolling 30-day windows per service/dataset. Allow controlled burn: rapid consumption triggers staged actions.- Reserve global “blameless buffer” for infra upgrades (small % of budget) with governance sign-off.Enforcement mechanisms (automated + governance):1. Monitoring & alerting: centralized telemetry (Prometheus/Datadog/GCP Monitoring) with per-dataset/service SLO dashboards and automated alerts on burn rate thresholds (e.g., 25%, 50%, 80% consumed).2. Automation: when >50% burn in 7-day rolling, require mitigation plan and reduce non-essential scheduled jobs; when >80% in 72h, auto-suspend risky deploys (see CI gating) and rate-limit low-priority traffic.3. CI/CD gates: error-budget-aware pipelines. Deploys check current budget; non-urgent releases blocked when budget exhausted unless approved via emergency process.4. Incident runbooks and postmortem requirements after budget breaches.Developer workflow when budgets exhausted:- Immediate: automated alert to owning team with required info (root cause hints, metrics).- Triage: 1-hr SLA to acknowledge; validate mitigation (rollback, throttle, patch).- If unresolved within defined window, escalations to Platform SRE/DataOps for joint mitigation.- To release code while budget exhausted: submit “Exception Request” including risk assessment, retro plan, and temporary guardrails; exception requires sign-off from Data Ops and Product stakeholder.Incentives and balancing velocity vs reliability:- Shared objectives: SLO attainment part of team OKRs; infra costs and support time tracked.- Reward reliability: quarterly bonus/recognition for teams that maintain SLOs while delivering features; highlight reusable fixes into platform.- Product trade-offs: allow limited fast-path for innovation—graceful “playground” datasets tagged Silver that don’t affect core SLOs.- Invest in developer ergonomics: provide sandboxed test data, longitudinal test harnesses, canary environments, and feature flags to reduce risk.- Transparent reporting: public SLO dashboard and leaderboard to encourage ownership; blameless postmortems with quantifiable follow-ups.Governance and rollout:- Pilot with 3 critical pipelines for 8 weeks, refine thresholds and automation, then scale. Maintain a lightweight SLO registry (metadata per dataset/service) and quarterly SLO reviews with stakeholders to reclassify tiers based on business impact.This policy creates predictable reliability, clear guardrails for developers, and explicit trade-offs so teams can move fast where safe and protect critical data consumers.
HardTechnical
60 practiced
Design observability strategies for serverless ETL functions (e.g., AWS Lambda or GCP Cloud Functions) that are ephemeral and scale rapidly. Cover structured logging, cold-start metrics, tracing across async steps, sampling, cost considerations, and how to correlate serverless invocations with downstream batch jobs and storage writes.
Sample Answer
Requirements:- Observe ephemeral, high-scale serverless ETL (Lambda/Cloud Functions)- Track cold starts, latencies, errors, resource usage, cost- Trace across async steps (queues, batch jobs, storage writes)- Correlate invocation → downstream batch runs and object writesHigh-level strategy:1. Structured logging- Emit JSON logs with standardized fields: trace_id, span_id, invocation_id, function_name, cold_start (bool), start_ts, end_ts, status, input_source, record_count, bytes_processed, cost_estimate.- Use SDK / logger wrapper that auto-injects these fields. Example field names: trace_id, invocation_id, parent_id, user_id, batch_id.2. Distributed tracing & async correlation- Generate a globally-unique trace_id at the pipeline ingress (API/ingest job). Propagate via X-Custom-Trace header into function and into downstream messages (SQS/SNS/PubSub), object metadata (S3/GCS x-amz-meta-trace-id), and job submission parameters (Airflow run_id / batch_id).- Use OpenTelemetry in functions to create spans for processing, downstream publish, and storage writes. For async boundaries, create a producer span and attach trace_id to the message metadata so consumers can continue the trace.3. Cold-start metrics- Detect cold_start on init (lambda global var not set). Emit a metric/counter tagged by runtime, memory size, region, and function version. Track cold-start latency separately from execution latency.- Export to metrics backend (CloudWatch, Prometheus via pushgateway, or OTLP collector).4. Sampling & cardinality- Sample full traces (100% for failures and cold-starts; adaptive sampling for high-throughput success traces, e.g., 1% or head-based sampling). Always log minimal structured events for every invocation to retain aggregation ability.- Reduce high-cardinality tags (avoid user emails in metrics; keep IDs in logs only).5. Cost considerations- Minimize client-side telemetry payload; batch/flush logs to collector; use lightweight OTLP exporters; apply sampling before exporting traces to vendor to reduce ingestion costs.- Use metrics (aggregates) for dashboards and retain histograms; store raw traces only for sampled periods or errors.6. Correlating with downstream batch jobs & storage- When function enqueues a batch job (e.g., EMR/Spark), include trace_id and invocation_id in job metadata / tags and in job submission arguments. For storage writes, set object metadata: trace_id, invocation_id, partition_keys.- For batch jobs, emit startup logs referencing trace_id and job_run_id so joinable later. Build a materialized view in your observability store joining invocations → messages → job_runs → storage_objects using trace_id and timestamps.7. Practical implementation- Use OpenTelemetry SDK + central collector (OTel Collector) to translate to vendor backends.- Logs → structured JSON to CloudWatch/Stackdriver/ELK; metrics to CloudWatch/Prometheus; traces to Jaeger/Lightstep/Datadog.- Implement Lambda wrapper/middleware that: - sets trace_id (or continues incoming), - records cold_start, - measures init vs handler latency, - enriches outgoing messages and storage writes with trace metadata, - applies sampling decision.Edge cases & tests:- Network failures when exporting telemetry: fallback to buffered disk or drop with counters to track telemetry loss.- Cross-account or cross-region propagation: ensure metadata follows security best practices (no PII).- Validate correlation by synthetic test: fire an event with known trace_id and assert visibility from ingestion through final storage and batch job logs.Key trade-offs:- Sampling reduces cost but can hide rare patterns—keep 100% minimal logs + sampled traces.- Adding metadata increases payload size (S3 metadata, messages) vs. observability benefits—keep keys compact (trace, inv).Metrics to monitor success:- Cold-start rate and median cold-start latency- End-to-end latency (ingest → storage/commit)- Trace coverage (% of errors traced)- Telemetry cost per million invocationsThis approach gives end-to-end visibility while controlling cost and cardinality, and enables reliable correlation between ephemeral serverless invocations and downstream batch jobs/storage writes.
MediumTechnical
55 practiced
Create an alert routing and escalation policy for a multi-team data platform that includes ingestion, transformation, and serving teams. Specify which alerts go to which team, escalation timing, on-call rotations, playbook links, and how to avoid noisy cross-team pages while ensuring timely resolution for customer-impacting incidents.
Sample Answer
Requirements & goals:- Fast resolution for customer-impacting incidents (data missing, SLA breaches, corrupted tables).- Clear ownership per domain (ingestion, transformation, serving).- Minimize noisy cross-team pages; preserve visibility when handoff needed.- On-call fairness, documented runbooks.Alert taxonomy & routing:- P0 (Customer-impacting, data loss/SLA miss): pages primary team owning the stage where failure is detected + cross-team notification channel. - If origin = ingestion (failed connectors, stalled offsets, >15m lag): page Ingestion on-call. - If origin = transformation (job failures, schema drift, data corruption detected post-ETL): page Transformation on-call. - If origin = serving (slow queries, missing partitions in warehouse, API returning stale data): page Serving on-call.- P1 (Degraded but not yet customer-impacting, e.g., growing lag, retryable failures): page primary team as silent alert (SMS/email only) and create ticket to on-call inbox.- P2/P3 (informational / advisory): log to dashboard & Slack channel (no direct paging).Escalation timing & flow:- P0: page primary on-call immediately. If no ack in 5 minutes -> escalate to secondary. If still unacked in 10 minutes -> escalate to team lead + notify platform incident commander (IC).- P1: notify on-call; if not acknowledged in 30 minutes -> escalate to secondary; if unresolved in 2 hours -> open incident review and notify lead.- For any alert that requires handoff, primary on-call must add context and call the other team within 15 minutes; if handoff accepted, ownership transfers and escalation timers reset.On-call rotations & responsibilities:- 1-week primary rotation per team, with a secondary overlap for 1 business day for knowledge transfer.- 24/7 coverage: weekday primary handles daytime; weekend rotation uses smaller pool with 1-week shifts.- Primary on-call: respond/triage, execute playbook, communicate status to stakeholders.- Secondary on-call: backup for escalations, takes over if primary unavailable.Playbooks & runbooks:- Every alert type links to a canonical playbook (hosted in internal docs) with: - Triage checklist, key logs/queries, run commands, rollback steps, and postmortem triggers. - Example links: - Ingestion failures: /playbooks/ingestion-failure - Transformation schema drift: /playbooks/schema-drift - Serving stale data: /playbooks/serving-stale- Playbooks include decision tree: when to page other teams, when to declare incident, required communications.Avoiding noisy cross-team pages:- Enforce alert enrichment: alerts must include source, pipeline/job id, last-success timestamp, affected downstream consumers, and suggested owner.- Use escalation policies and silent alerts for early warnings to reduce pages.- Introduce a “cross-team notification” Slack channel for low-severity multi-team visibility; only P0 triggers multi-page.- Require a quick pre-handoff sync (5-10 min) before paging another team for non-P0 issues; prefer creating a ticket with clear context first.- Rate-limit flapping alerts and implement aggregation (e.g., group repeated identical errors into one incident within 5 minutes).Post-incident:- Mandatory postmortem for P0 / repeated P1s within 7 days, assigned to owning team with cross-team reviewers.- Track mean-time-to-detect (MTTD) and mean-time-to-recover (MTTR) per pipeline; iterate alert thresholds and playbooks quarterly.Example scenario:- Job X fails producing NULLs in table T (detected in data validation): - Alert: P0 data corruption → pages Transformation on-call. - Transformation triages using playbook, finds root cause in ingestion schema change → pages Ingestion as secondary notification within 10 minutes; if ingestion accepts, ownership moves; otherwise Transformation mitigates with rollback and coordinates fix.This policy balances clear ownership, fast escalation for customer impact, documented playbooks for repeatability, and noise controls to avoid unnecessary cross-team pages.
Unlock Full Question Bank
Get access to hundreds of Reliability, Observability, and Incident Response interview questions and detailed answers.