Covers the design, implementation, operation, and continuous improvement of monitoring, observability, logging, alerting, and debugging for machine learning models and their data pipelines in production. Candidates should be able to design instrumentation and telemetry that captures predictions, input features, request context, timestamps, and ground truth when available; define and track online and offline metrics including model quality metrics, calibration and fairness metrics, prediction latency, throughput, error rates, and business key performance indicators; and implement logging strategies for debugging, auditing, and backtesting while addressing privacy and data retention tradeoffs. The topic includes detection and diagnosis of distribution shifts and concept drift such as data drift, label drift, and feature drift using statistical tests and population comparison measures (for example Kolmogorov Smirnov test, population stability index, and Kullback Leibler divergence), windowed and embedding based comparisons, change point detection, and anomaly detection approaches. It covers setting thresholds and service level objectives, designing alerting rules and escalation policies, creating runbooks and incident response processes, and avoiding alert fatigue. Candidates should understand retraining strategies and triggers including scheduled retraining, automated retraining based on monitored signals, human in the loop review, canary and phased rollouts, shadow deployments, A versus B experiments, fallback logic, rollback procedures, and safe deployment patterns. Also included are model artifact and data versioning, data and feature lineage, reproducibility and metadata capture for auditability, continuous validation versus scheduled validation tradeoffs, pipeline automation and orchestration for retraining and deployment, and techniques for root cause analysis and production debugging such as sample replay, feature distribution analysis, correlation with upstream pipeline metrics, and failed prediction forensics. Senior expectations include designing scalable telemetry pipelines, sampling and aggregation strategies to control cost while preserving signal fidelity, governance and compliance considerations, cross functional incident management and postmortem practices, and trade offs between detection sensitivity and operational burden.
MediumTechnical
65 practiced
Case study: Product reports a 6% drop in conversion rate last week while model accuracy metrics appear stable. As the SRE, outline how you would investigate whether the KPI shift is caused by model regression, product changes (UI/UX), external factors, or instrumentation/telemetry issues. Include telemetry queries, experiments to run, and how to communicate findings to stakeholders.
Sample Answer
Situation: Last week product conversion fell 6% while ML model accuracy metrics (AUC/LogLoss) stayed stable. As SRE my goal is to triage root cause across four buckets: model regression, product changes, external factors, or telemetry errors — and communicate clear next steps.Investigation plan (prioritize quick signal first)1) Validate telemetry/instrumentation- Query event counts to detect drop in upstream events: - SQL: SELECT date, COUNT(*) AS events FROM events WHERE event_type IN ('page_view','checkout') GROUP BY date ORDER BY date DESC LIMIT 14; - Prometheus: rate(http_requests_total{job="frontend",handler="checkout"}[5m])- Check for gaps, duplicated events, or schema changes in logs (broken client SDK, deployment that changed event name).- Compare client vs server-side counts and user-agent distribution.2) Check systemic product changes- Pull deploy and feature flags timeline: SELECT deploy_time, service, commit, author FROM deploys WHERE deploy_time >= now()-interval '14 days';- Correlate new UI/UX releases, A/B launches, or experiments with conversion drop window.- Run quick cohort query: conversion_rate by variant and platform (web/mobile) over last 14 days.3) Assess model behavior beyond global accuracy- Compute prediction-distribution drift and calibration by cohort: compare feature distributions (KS-test) and model score distribution last week vs prior baseline.- Telemetry queries: - SELECT bucket(pred_score,0.05) AS decile, conversion_rate FROM predictions JOIN outcomes ON id WHERE date BETWEEN ... GROUP BY decile;- Check per-segment accuracy: precision/recall by geography, device, user cohort.4) External factors & infra- Check traffic quality: spike in bots or new referral sources (referrer breakdown).- Monitor infra health: latency/error rates, DB contention, third-party API failures during window.Experiments to run- Canary rollback: temporarily roll back suspect frontend change for a small percentage and measure conversion.- AB test split: force control traffic to previous model/UI and compare conversion over 24–72 hours.- Synthetic traffic: replay known-good traffic through stack to validate telemetry and pipeline.Decision criteria- If server/client event mismatch or sudden schema change → instrumentation root cause.- If conversion drop confined to variant/device/geography with stable model scores → product/UI cause.- If feature drift (distribution shift) or per-segment model degradation despite global metrics stable → model regression in a segment.- If traffic/referrer or infra anomalies coincide → external/infra cause.Communication- Immediate incident post: summary, impact (6% conversion ~ $X/day), actions being taken, expected ETA for next update.- 30/60/120-min updates with findings (telemetry evidence: charts + key query results), proposed mitigations (rollback, fix instrumentation, AB test), and recommended owners (platform, product, ML).- Final report: root cause, evidence (queries/plots), resolution steps, and preventive actions (more granular model metrics, telemetry tests, automated deploy gates).Key deliverables to stakeholders- Dashboard slices: conversion by variant/device/geo/referrer, event counts, model prediction drift.- Repro steps & experiments executed, with quantitative results.- Timeline and proposed permanent fixes (alerts for event drop, per-segment model monitoring, pre-deploy telemetry smoke tests).
MediumSystem Design
56 practiced
Design a telemetry pipeline to ingest per-prediction events at 100k requests/sec. The pipeline must support low-latency alerting (<5s), efficient aggregation for dashboards, and long-term backtesting. Describe components (ingest, buffering, stream processing, hot/cold storage), a sampling and retention strategy, and how you will maintain queryability for debugging.
Sample Answer
Requirements & constraints:- 100k events/sec steady, <5s alert latency, efficient dashboard aggregations, long-term raw data for backtesting, cost control, and queryability for debugging.High-level architecture:1. Ingest (edge)- Lightweight HTTP/gRPC collectors behind a global LB (or ingress via Envoy). Validate and enrich minimal fields (timestamp, request_id, model_id, features hash, prediction, score).- Use shards by model_id or customer to spread load.2. Buffering- Fronted by a managed Kafka cluster or cloud streaming (Kafka, Confluent, or Kinesis). Provision partitions = throughput/partition (~10-50 MB/s). This decouples producers and consumers and provides retention for replays.3. Stream processing- Two parallel pipelines from Kafka: a) Real-time alerts & metrics: low-latency stream jobs (Flink/ksqlDB/Beam) that maintain per-entity windows, compute anomalies, SLO breaches, and push alerts to Alertmanager/SNS within 1–2s processing + delivery. b) Aggregation & rollups: stream job that increments time-series stores (Prometheus/Thanos, Cortex, or InfluxDB) and writes hourly/daily rollups to OLAP (ClickHouse or BigQuery) for dashboards.4. Hot/Cold storage- Hot: recent raw/near-raw events (last 7–30 days) in compressed Parquet in a fast object store (S3 with lifecycle + AWS S3 Select or Iceberg) plus indexed partition metadata for quick queries; or use ClickHouse for recent detailed queries.- Cold: Long-term raw events (months/years) as compressed partitioned Parquet in S3/GS with catalog (Glue/Hive/Delta Lake) for efficient backtesting.Sampling & retention strategy (cost vs fidelity)- Full capture for a small fraction (e.g., 5–10%) of events per model/customer chosen via deterministic hashing of request_id — guarantees reproducible sampling for backtests.- Head-sample: keep 100% of anomalous/failed/threshold-crossing events and any events flagged by stream detectors.- Retention: Hot store 30 days full raw; sampled full-fidelity raw for 1 year; aggregated metrics forever (or per compliance).- Provide on-demand rehydration: if a backtest needs more data, replay Kafka or restore from cold Parquet.Maintaining queryability for debugging- Store enriched metadata and an index service: - Maintain a small searchable index (Elasticsearch/Opensearch) of recent request_id → S3 path + partition + offset for quick lookup. - Ensure request_id is present in logs/traces and correlate via distributed tracing (Jaeger/X-Ray) so SREs can jump from trace to event. - Provide a developer query layer (Presto/Trino) over the data lake + materialized views for common debug queries.- Retain transaction offsets and schema registry to allow exact replay for reproducing a prediction.Scalability & reliability considerations- Autoscale collectors, use backpressure: if Kafka is saturated, reject with 429 and expose producer-side buffering.- Monitor Kafka lag, stream job latencies, and SLOs with SLOs for alert latency and ingestion loss.- Trade-offs: higher sampling lowers cost but reduces backtest fidelity; keeping more hot data increases cost but speeds debugging.This design meets <5s alerting by using low-latency stream processors and direct alert sinks, supports dashboard aggregation via rollups into TSDB/OLAP, and preserves long-term reproducible data via sampled raw storage with indexing for fast debugging.
HardSystem Design
46 practiced
Design a model artifact and data lineage/versioning scheme that supports reproducibility, rollback, and drilling from a served prediction to the exact training code, data snapshot, and feature transformations. Provide example metadata fields, storage layout, and APIs for lookup and retrieval.
Sample Answer
Requirements:- Reproducibility: given a served prediction, locate exact training code, data snapshot, feature engineering pipeline, and hyperparameters.- Rollback: promote/demote model versions and rollback serving to previous stable artifact quickly.- Drillability & audit: immutable lineage and fast lookup APIs for incident postmortem.- NFRs: high availability, low-latency lookups, access control, retention policies.High-level design:- Central Artifact Registry (AR): immutable store of model artifacts + lineage metadata (backed by object storage + metadata DB).- Immutable Data Snapshots (DS): data lake snapshots with content-addressed storage (e.g., partitioned parquet with manifest).- Feature Store Versioning (FS): feature transformations published as immutable feature specs + containers.- Code Repository + Build Artifacts (CR): Docker images and build hashes for training code stored in AR.- Index services + API gateway for fast lookup and RBAC.Example metadata fields (model artifact record):- model_id, version (semver), artifact_hash (sha256)- created_at, created_by, environment (prod/staging)- train_code_repo, commit_hash, build_image: "registry/app:sha"- training_parameters: {lr:0.01,seed:42}- data_snapshot_id (pointer to DS manifest)- feature_spec_id, feature_version- metrics: {train_auc:0.92,val_auc:0.90}- lineage: {parents: [artifact_hash], dependent_features: [...]}- provenance_url (signed link), retention_policy, slo_impact_scoreStorage layout (S3-like):- /artifacts/models/{model_id}/{version}/model.tar.gz- /artifacts/models/{model_id}/{version}/metadata.json- /data/snapshots/{snapshot_id}/manifest.json (list of object paths + checksums)- /code/builds/{commit_hash}/image.tar /manifests- /features/{feature_spec_id}/{version}/spec.jsonAPIs (REST/GraphQL examples):- POST /v1/models -> register artifact (returns artifact_hash)- GET /v1/models/{model_id}/{version} -> metadata + provenance links- GET /v1/predictions/{request_id}/lineage -> given served prediction id -> {model_ref, input_data_refs, feature_refs, code_ref, snapshot_id}- GET /v1/snapshots/{snapshot_id}/files -> manifest with presigned URLs- POST /v1/models/{model_id}/{version}/promote -> promote to prod with canary options- POST /v1/models/{model_id}/{version}/rollback -> atomic rollback + circuit-breaker toggleOperational considerations:- Make metadata DB strongly consistent (e.g., RDS/Spanner) for atomic promotions; store large binaries in S3 with checksums.- Precompute and cache common lookups (prediction_id -> lineage) in Redis for low latency.- Use signed URLs with short TTL for blob access; audit every lookup.- Integrate with CI/CD: build step computes artifact_hash, registers metadata, snapshots data via content-addressed manifests.- SRE patterns: health checks, circuit breakers on promotion, automated rollback policy (SLO breach triggers), retention garbage collection tied to retention_policy, encryption-at-rest and RBAC.Example minimal lineage lookup flow:1) Serving logs record prediction_id -> model_artifact_hash + input_blob_ref.2) GET /v1/predictions/{id}/lineage returns metadata JSON linking to train code (commit + image), data_snapshot_id, and feature_spec.3) Operator can GET snapshot manifest and pull exact training dataset and docker image to reproduce training locally or in sandbox.
EasyTechnical
59 practiced
What is feature lineage and why is it critical for model monitoring, reproducibility, and debugging? Describe the metadata you would capture to trace a prediction back to data sources, transformation code, feature-store versions, and timestamps.
Sample Answer
Feature lineage is the end-to-end trace that links a model prediction back to the exact feature values, how those features were produced (code), which feature-store versions or tables they came from, and the upstream raw data and timestamps. For an SRE, feature lineage is critical because it enables deterministic replay, root-cause analysis during incidents, automated alerting on data-quality regressions, and compliance/auditability — all of which affect reliability and MTTR.Key reasons:- Model monitoring: detect whether data drift or upstream schema changes caused anomalies.- Reproducibility: recreate a past prediction exactly for debugging or rollback.- Debugging: pinpoint faulty transforms, stale feature-store versions, or late-arriving data.Essential metadata to capture (minimal, immutable, and indexed):- Prediction ID / request ID (unique)- Model version & artifact hash (git commit + build SHA)- Feature set ID and semantic version- Feature-store table names and row keys used- Feature-store snapshot/timestamp and ingestion time- Transformation code reference (repo URL + commit SHA + path)- Data source identifiers (dataset name, partition, file path, S3 URI, DB + primary key)- Raw-data ingestion timestamp and event-time vs processing-time- Deterministic random seeds and config parameters- Checksums/hashes of serialized feature vector- Environment/serving metadata (container image, region, node ID)- Access control and provenance info (who produced/approved)Best practices: make lineage records append-only, store in a scalable tracing/indexing service, expose APIs for automated replay and link alerts to lineage to reduce MTTR.
MediumTechnical
58 practiced
A model's global accuracy is improving but a protected subgroup shows significant degradation. Describe monitoring metrics and processes to detect such fairness regressions, including which per-group metrics to track (TPR, FPR, calibration), statistical testing to avoid false positives, and alerting design to make findings actionable.
Sample Answer
Situation: As an SRE supporting ML services, you need monitoring that catches fairness regressions even when global accuracy improves.Monitoring metrics (per protected group, plus global baseline):- Confusion-matrix rates: TPR (recall), FPR, TNR, FNR per group.- Calibration: group-wise reliability diagrams / Brier score and calibration slope/intercept.- Predictive parity: PPV per group.- Distributional checks: score distribution shifts (KS/TV), input feature drift for groups.- Operational metrics: inference latency and error rates per group (if different routing).Statistical testing & safeguards:- Require a minimum sample size per group before testing; flag groups underpowered separately.- Use proportion tests (two-proportion z-test) for TPR/FPR deltas, or bootstrap CIs for nonparametric estimates.- Correct for multiple comparisons (Benjamini–Hochberg to control FDR rather than Bonferroni if many groups/metrics).- Report both statistical significance (p-value / CI) and practical significance (absolute delta, e.g., TPR drop > 3%).- Compute rolling baselines (week-over-week) and use EWMA to reduce noise; detect persistent changes (e.g., sustained >3 windows).Alerting design (actionable & SRE-friendly):- Multi-tier alerts: warning for statistically-significant but small/prone-to-noise drops; critical for large/practical-impact regressions or simultaneous metric breaches (e.g., TPR drop + calibration failure).- Alert payload: affected group(s), metric deltas, p-values & CIs, sample sizes, time window, recent model version, upstream data drift indicators, links to dashboards and runbooks.- Integrate into incident playbooks: owner (ML engineer), rollback/run model canary, data investigation steps, mitigation (threshold-based throttling).- Automate canary and rollout controls: block full rollout if canary shows group degradation beyond thresholds.- Post-incident: record RCA, update thresholds, and add synthetic tests to CI that simulate boundary cases.This combines statistical rigor, minimal false positives, and operational workflows so SREs can detect, prioritize, and act on fairness regressions quickly.
Unlock Full Question Bank
Get access to hundreds of Model Monitoring and Observability interview questions and detailed answers.