Easy everything in Monitoring & SRE, page 2
Essential tags for a request latency metric
Add method, route template, status code, and maybe service or region; they enable slicing while staying low-cardinality.
Structured vs unstructured logging
Unstructured logs are free-text lines; structured logs are machine-readable key-value or JSON, enabling reliable parsing, filtering, and aggregation.
The three pillars of observability
Metrics show what and when via cheap aggregates, logs give detailed per-event context, traces show where across services.
Proposing availability and latency SLIs for an auth API
Availability as the ratio of successful valid requests; latency as the fraction served under a threshold; measure at the edge from the user's view.
What is an error budget?
Error budget is one minus the SLO, the allowed unreliability; it gates feature velocity versus reliability work.
Relationship between SLI, SLO, and SLA
SLI is the measured metric, SLO is the internal target for that metric, SLA is the external contract with consequences.
What are the Four Golden Signals?
Name latency, traffic, errors, and saturation; explain each briefly; describe measuring latency as a distribution separating success from failure.
Explain the three pillars of observability
Metrics are cheap aggregated time series for detecting and alerting, logs are discrete event records for detail and context, traces follow one request across services to localize latency.
How do SRE and DevOps relate?
DevOps is a broad culture of breaking down silos; SRE is one prescriptive way to do it with specific practices.
SLI vs SLO vs SLA: how do they relate?
SLI is a measured metric, SLO is the internal target for that metric, SLA is the external contract with consequences.
What defines toil, with an example?
Define toil as manual, repetitive, automatable, tactical, no-enduring-value, scaling-with-growth work; distinguish it from overhead; give a concrete example.
SRE Office Hours: Scaling Expertise Through Consultation
SRE Office Hours are a scheduled time for development teams to get expert advice from SREs, scaling reliability knowledge without embedding them everywhere. Use them to review designs or define SLOs. The footgun is treating them as on-call support.
The SRE Mandate: Breaking the Dev vs. Ops Cycle
SRE breaks the classic conflict between developers who want to ship fast and operations teams who want stability. It treats operations as a software problem, not a human one. The footgun is creating a rebranded sysadmin team that still does manual work.
Steady State Hypothesis: The Core of Chaos Engineering
The steady state hypothesis is the core of chaos engineering: you bet your system's key metrics won't change when you break something. It's used to test resilience by defining "normal" (e.g., latency <200ms) and then trying to disrupt it with faults.
Chaos Engineering: Finding Weaknesses Before They Find You
Chaos Engineering intentionally breaks parts of your system to find weaknesses before they cause real outages. It's used to test resilience against events like server crashes or network failures.
Horizontal Scaling: Add More Machines, Not Bigger Ones
Horizontal scaling (scaling out) means handling more load by adding more machines to your resource pool, not upgrading a single one. It’s used for web servers behind a load balancer. The footgun is that your app must be stateless to avoid losing user data.
Single Point of Failure: Your System's Achilles' Heel
A single point of failure (SPOF) is your system's Achilles' heel—one component whose failure causes a total outage. This is critical in high-availability design, like ensuring a website survives a server crash. The footgun is missing implicit SPOFs.
Non-Functional Requirements: How a System Should Be, Not Just What It Does
Non-Functional Requirements (NFRs) define *how well* a system performs its tasks, not *what* tasks it performs. They're the adjectives (fast, secure, reliable) for a system's verbs.
Benchmarking: Know Your System's Limits
Benchmarking finds your system's limits by measuring its responsiveness and stability under a controlled workload. Use it to catch performance regressions, compare tech choices, or for capacity planning. The footgun: trusting benchmarks run on your laptop.
Stress Testing: Finding Your System's Breaking Point
Stress testing finds a system's breaking point by pushing it beyond normal limits. It's used for mission-critical software to test robustness and availability under extreme load, not just normal function.
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