Easy everything in Monitoring & SRE, page 2
Symptom-based versus cause-based alerting
Symptom alerts fire on user impact like high error rate or latency; cause alerts fire on internal conditions like high CPU. Page on symptoms, treat causes as diagnostic.
Core components of Prometheus
Server scrapes targets found via service discovery, stores samples in a local time-series database, with Alertmanager and exporters as helpers.
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.
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