# Projects
All Projects notes →Error Budget Policy
How error budgets are calculated, consumed, and enforced.
Production Readiness Review (PRR)
The Production Readiness Review gate — what a service must satisfy before prod.
03 — Reliability Engineering
The SRE practice: charter, SLOs, error budgets, and the prod-readiness gate.
Reliability Review Archive
Archive of completed reliability / PRR reviews.
SLO Registry
Registry of all SLOs across ShipSolid platform services.
SRE Charter
The SRE practice charter — scope, principles, and how reliability work is prioritized.
KPIs, SLIs, SLOs & SLAs
Defines the **metrics hierarchy** used to align technical observability signals with business
Production Readiness Review Template
- **Service**: [FILL] - **Service Team TL**: [FILL]
SLO Document Template
- **Service**: [Full service name] - **Owner**: [Team name]
# Sre
All Sre notes →1 — What is Site Reliability Engineering?
What SRE actually is when you strip away the Google mythology — applying software engineering discipline to operations problems, with error budgets as the mechanism that makes reliability a measurable, negotiable trade-off instead of an absolute.
2 — History of SRE (Google and Beyond)
How Ben Treynor's 2003 Google team turned an operations headcount problem into a discipline, and how the practice diverged as Amazon, Microsoft, Meta, and Netflix each adapted it to their own org shape.
3 — DevOps vs SRE vs Platform Engineering
Three overlapping answers to the same organizational question — who owns production — and where each discipline's boundary actually sits when a service crosses it.
4 — Reliability as an Engineering Discipline
Why reliability has to be designed and budgeted like a feature, not bolted on afterward as an operations concern.
5 — Service Lifecycle
The stages a service moves through from design to deprecation, and the reliability gate that should exist at every transition.
6 — Production Readiness Reviews
The structured checklist that turns 'is this ready for production' from a gut call into a repeatable, auditable gate before a service takes real traffic.
7 — Reliability Engineering Mindset
The shift from reactive firefighting to designing for known failure modes — probabilistic thinking about what will break, not just how to react when it does.
8 — Shared Ownership Model
Why 'you build it, you run it' only works with a real ownership contract behind it — the engagement model, escalation path, and toil ceiling that keep shared ownership from silently becoming SRE-owns-everything.
9 — Cost, Reliability and Velocity Trade-offs
The three-way trade-off underneath almost every reliability decision, and why optimizing any one of cost, reliability, or shipping velocity in isolation breaks the other two.
1 — Linux Internals Every SRE Must Know
The kernel-level mental model — syscalls, the VFS, the scheduler — that turns 'the server is slow' from a guess into a diagnosable claim.
10 — gRPC
Why internal service-to-service calls increasingly run on gRPC instead of REST, and the deadline propagation and streaming semantics that change how you debug a slow call chain.
11 — TLS and Certificates
The handshake, cipher negotiation, and certificate chain validation that fail silently until an expiry takes down a service nobody remembered depended on it.
12 — Load Balancers
L4 vs L7 load balancing, health check design, and why a load balancer's own failure mode is often the single biggest blast radius in the stack.
13 — Reverse Proxies
What a reverse proxy actually buys you — TLS termination, routing, buffering — and the latency and failure modes it adds in exchange.
14 — CDNs
Cache hit ratio as a reliability metric, not just a cost one, and what happens to origin load the moment a CDN's cache goes cold.
15 — Linux Troubleshooting
The strace/perf//proc-level toolkit for answering 'why is this box actually doing that' when the metrics dashboard has run out of answers.
2 — Processes, Threads and Scheduling
How the Linux scheduler decides what runs next, and why CPU throttling in a container often has nothing to do with raw CPU usage.
3 — Memory Management
Virtual memory, paging, and the OOM killer — why 'out of memory' in Kubernetes is rarely about the number top reports.
4 — Filesystems and Storage
How filesystems, page cache, and I/O schedulers interact to turn a disk-bound service's latency graph into something explainable.
5 — TCP/IP Deep Dive
How TCP's handshake, flow control, and congestion control actually behave under production load, and what that means when 'the network is slow' shows up in an incident.
6 — DNS
Why DNS is the failure mode that takes down services that have nothing to do with DNS, and the resolution chain an SRE needs to trace under pressure.
7 — HTTP/1.1
The request/response semantics, keep-alive, and head-of-line blocking behavior that still underpin most production traffic today.
8 — HTTP/2
Multiplexing, stream prioritization, and header compression — what HTTP/2 actually fixed from HTTP/1.1, and the new failure modes it introduced.
9 — HTTP/3
Why HTTP/3 moved off TCP entirely, and what QUIC changes about how connection loss and retransmission show up in your latency metrics.
1 — CAP Theorem
Why every distributed system is already choosing between consistency and availability during a partition, whether or not the team ever wrote that choice down.
10 — Distributed Caching
Cache invalidation, consistency, and the thundering-herd failure mode that turns a cache miss into a cascading origin outage.
11 — Service Discovery
How a service finds a healthy instance of its dependency at runtime, and what happens to that discovery layer's own reliability under churn.
12 — API Gateways
Centralizing auth, rate limiting, and routing at the edge — and the single point of blast radius that centralization creates in exchange.
13 — Message Brokers
At-least-once vs. exactly-once delivery, backpressure, and why the broker's own durability guarantees are usually the real SLA you're depending on.
14 — Event-Driven Architectures
The reliability trade-offs of decoupling services through events — replay, ordering, and the debugging cost of a causal chain with no single call stack.
2 — Consensus Algorithms
The problem every consensus algorithm is solving — getting a set of unreliable nodes to agree on one value — and why it's harder than it sounds.
3 — Raft
Leader election, log replication, and the safety guarantees Raft trades for being easier to reason about than Paxos.
4 — Paxos
The original consensus protocol, why it's notoriously hard to implement correctly, and where it still shows up under the hood of production systems.
5 — Distributed Transactions
Two-phase commit, saga patterns, and why 'just wrap it in a transaction' stops being an option the moment a write crosses a service boundary.
6 — Eventual Consistency
What you're actually promising a caller when a system is 'eventually consistent,' and the read-your-own-writes gaps that turn into support tickets.
7 — Leader Election
How a cluster picks a single coordinator without a coordinator, and the split-brain failure mode that shows up when the election protocol itself degrades.
8 — Distributed Locks
Why a distributed lock is a liveness and safety trade-off, not a free primitive, and the fencing tokens that keep a stale lock holder from corrupting state.
9 — Time Synchronization
Clock skew, NTP, and why 'just use timestamps to order events' quietly breaks in any system spanning more than one machine.
1 — Virtual Machines
The hypervisor-level isolation and resource accounting that containers still inherit assumptions from, and where VM-level failure domains differ from container ones.
10 — Multi-Region Deployments
Active-active vs. active-passive across regions, and the data-replication latency that ultimately caps how 'active' active-active can really be.
11 — Infrastructure as Code
Why declarative infra state, not scripts, is what makes an environment reproducible — and the drift between declared and actual state that erodes that guarantee over time.
12 — Immutable Infrastructure
Replacing instead of patching running infrastructure, and why it turns configuration drift from a chronic failure mode into one that mostly can't happen.
13 — GitOps
Git as the single source of truth for cluster state, and the reconciliation loop that makes 'what's actually running' a query instead of a guess.
14 — Configuration Management
Where config lives, how it's validated before rollout, and why a bad config push is still one of the most common root causes of a full-severity incident.
2 — Containers
Namespaces and cgroups as the actual mechanism behind 'containers,' and why a container's reliability characteristics are really the host kernel's.
3 — Kubernetes Fundamentals
The control-plane/data-plane split and reconciliation-loop model that everything else in Kubernetes — scheduling, networking, storage — is built on top of.
4 — Kubernetes Scheduling
How the scheduler turns resource requests, affinity rules, and taints into a placement decision, and why a 'Pending' pod is almost always a scheduling constraint, not a mystery.
5 — Networking in Kubernetes
The CNI, Service, and kube-proxy layers that turn a flat pod network into something with DNS names, load balancing, and — inevitably — new failure modes.
6 — Storage in Kubernetes
PersistentVolumes, StorageClasses, and the CSI driver layer, and why stateful workloads are still the hardest thing to run reliably on Kubernetes.
7 — High Availability Clusters
Multi-master control planes, etcd quorum, and the failure domains that determine whether a single zone outage takes the whole cluster with it.
8 — Autoscaling
HPA, VPA, and cluster autoscaling, and why autoscaling on the wrong signal turns a capacity problem into a cascading one instead of solving it.
9 — Multi-Cluster Architectures
Why teams split a single Kubernetes footprint into multiple clusters — blast radius, compliance, scale limits — and the fleet-management cost that decision buys.
1 — Reliability Principles
The handful of first-principles ideas — redundancy, graceful degradation, known failure modes — that every other chapter in this Part is a specific application of.
10 — Failure Domains
Drawing the boundary around 'what breaks together' — AZ, region, tenant, deploy group — so a single fault has a bounded, known blast radius instead of an open-ended one.
11 — Redundancy Patterns
Active-active, active-passive, and N+1 redundancy, and the trade-off each makes between failover speed, cost, and the complexity of keeping replicas actually consistent.
12 — Graceful Degradation
Designing a system to shed non-critical functionality under stress instead of failing completely — and deciding in advance what's non-critical.
13 — Backpressure
The signal a slow consumer sends a fast producer to prevent unbounded queue growth, and why a system without backpressure fails by silently falling further behind until it doesn't.
14 — Queue Management
Queue depth as a leading indicator of saturation, and the policies — bounded queues, priority lanes, dead-letter handling — that keep a backlog from becoming the outage.
15 — Load Shedding
Deliberately rejecting a fraction of requests to protect the system's ability to serve the rest, and the prioritization logic that decides which fraction.
16 — Circuit Breakers
Failing fast instead of piling up timeouts against a dependency that's already down, and the half-open state that decides when it's safe to try again.
17 — Retry Strategies
Exponential backoff and jitter as the difference between a retry storm that takes down a recovering dependency and one that lets it heal.
18 — Timeouts
Why every network call needs an explicit timeout budget, and how an unset or mismatched timeout turns one slow dependency into a resource leak upstream.
19 — Bulkheads
Partitioning resources — thread pools, connection pools — per dependency so one slow downstream can't exhaust the resources every other call path also needs.
2 — Service Level Indicators (SLIs)
Picking the metric that actually reflects user-perceived reliability, and why the wrong SLI makes every SLO built on top of it meaningless.
20 — Idempotency
Designing an operation so a retry is safe by construction, which is what actually makes retries, at-least-once delivery, and failover recoverable instead of dangerous.
3 — Service Level Objectives (SLOs)
Turning an SLI into a target with a time window, and why the window you choose changes what 'reliable' even means operationally.
4 — Error Budgets
The spendable resource an SLO creates, and how a burned error budget becomes an organizational decision — freezing launches — instead of just another alert.
5 — Availability Engineering
What 'three nines' actually costs to achieve, and why each additional nine is an order-of-magnitude harder engineering and financial commitment than the last.
6 — Latency Engineering
Why tail latency (p99, p99.9), not the average, is what determines whether users actually experience a service as fast.
7 — Capacity Planning
Forecasting demand ahead of the traffic that would otherwise turn a capacity gap into an incident, and the headroom math that makes the forecast survivable.
8 — Scalability Engineering
Designing a system so growth is a capacity-planning exercise, not a rewrite — and knowing which scaling axis (vertical, horizontal, functional) actually fixes the bottleneck you have.
9 — Reliability Modeling
Quantifying failure probability across a system's dependency graph before it fails, using the same math that predicts hardware MTBF applied to services.
1 — Observability Foundations
The distinction between monitoring known failure modes and observability — being able to ask new questions of a system you didn't instrument in advance for that exact question.
10 — Grafana
Turning raw telemetry into a dashboard that actually answers 'is this system healthy' at a glance instead of requiring someone to already know what's wrong.
11 — Loki
Index-light, label-based log aggregation built to pair with Prometheus's label model — and the trade-off it makes against full-text search to get there.
12 — Tempo
Object-storage-backed trace storage designed for the exemplar-driven workflow — jump from a metric spike straight to the trace that explains it.
13 — Alerting Philosophy
Alerting on symptoms a human needs to act on right now, not on every cause — the design discipline that determines whether on-call trusts the pager.
14 — Alert Fatigue
How a noisy alerting system trains engineers to ignore the pager, and why that's a more dangerous failure mode than having no alerting at all.
15 — Dashboard Design
The three-question test for a vanity panel, and the top-down layout that mirrors how an actual investigation drills down from symptom to cause.
16 — High-Cardinality Metrics
Why an unbounded label — user ID, request ID, raw URL — turns a cheap metric into a production incident for the observability pipeline itself.
17 — Sampling Strategies
Head vs. tail sampling for traces, and how to keep the interesting 1% — errors, outliers — without paying to store 100% of uninteresting requests.
18 — Cost Optimization
Ingest volume, retention, and cardinality as the three levers that actually control an observability bill, and the FinOps discipline of tuning them without losing signal.
2 — Telemetry Signals
Metrics, logs, and traces as three different projections of the same underlying system behavior, and why you need more than one to actually diagnose most incidents.
3 — Metrics
Counters, gauges, and histograms as the aggregate signal — cheap at scale, but only as useful as the cardinality budget and label schema behind them.
4 — Logs
The highest-cardinality, highest-detail signal, and the structured-logging discipline that determines whether logs are searchable evidence or just noise at 2am.
5 — Distributed Tracing
Following a single request across every service it touches, and why trace context propagation is the one piece of plumbing the rest of tracing quietly depends on.
6 — OpenTelemetry
The vendor-neutral instrumentation standard that decouples how you emit telemetry from where it ends up, and why that's the whole point.
7 — Context Propagation
How trace and baggage context survives a hop across a network boundary, a queue, or an async job — and everywhere that propagation silently breaks.
8 — Instrumentation Strategies
Deciding what to instrument, at what cardinality, before you write the code — because retrofitting observability into an incident you're already in is the expensive way to learn this.
9 — Prometheus
Pull-based scraping, the metric data model, and the local-storage limits that are exactly why Prometheus federates or remote-writes at any real scale.
1 — Incident Response Lifecycle
Detect, triage, mitigate, resolve, review — the phases every incident moves through, and why skipping the review phase is how the same incident happens twice.
10 — Blameless Postmortems
Why a blameless structure is what makes Five Whys produce an honest systemic answer instead of a defensive, cover-yourself one.
11 — Communication During Incidents
Status page updates, stakeholder comms, and internal channel discipline — the incident-adjacent work that determines how the outage is remembered as much as the fix does.
12 — Chaos Engineering
Deliberately injecting failure in a controlled experiment to validate the failure modes a design only claims to handle, before production finds them for you.
13 — Game Days
Scheduled, team-wide incident simulations that build on-call muscle memory and test the runbooks nobody's had to actually use yet.
2 — Severity Classification
The objective criteria that decide how big a response an incident gets, so severity is a judgment call made once, consistently, not renegotiated mid-incident.
3 — Incident Command System
The role structure — commander, comms lead, ops lead — that keeps a live incident from collapsing onto one overloaded engineer trying to do everything at once.
4 — On-call Engineering
Designing the rotation and escalation policy itself as an engineering problem, not just a schedule — the discipline distinct from the day-to-day on-call handbook.
5 — Escalation Policies
What happens when the first responder doesn't acknowledge in time, and the escalation chain that has to be correct precisely when everyone is least likely to check it.
6 — Runbooks
Step-by-step operational procedures written before the incident, so 3am execution doesn't depend on anyone's memory of how a system behaves under stress.
7 — Playbooks
Decision trees for ambiguous or novel incidents, one level up from a runbook's fixed steps — how to reason through a failure mode nobody's documented yet.
8 — Root Cause Analysis
Moving past 'a bad deploy caused it' to the systemic condition that let a bad deploy reach production undetected in the first place.
9 — Five Whys
The simplest RCA technique that works — repeatedly asking why until you hit a structural cause — and where it breaks down on genuinely multi-causal incidents.
1 — Performance Fundamentals
Latency, throughput, and utilization as the three numbers that describe any system's performance — and why optimizing one in isolation usually degrades another.
10 — Soak Testing
Running sustained load over hours or days to surface the failure modes — memory leaks, connection exhaustion, log disk fill — that only appear over time.
11 — Capacity Testing
Finding the actual ceiling of a system's current configuration, which is the number capacity planning is supposed to be forecasting against.
12 — Performance Bottlenecks
Why a system's bottleneck moves once you fix the current one, and the systematic method for finding the next constraint instead of chasing symptoms.
13 — Performance Optimization
Measure first, optimize the actual bottleneck, measure again — the discipline that keeps performance work from becoming expensive, unmeasured guesswork.
2 — CPU Profiling
Sampling vs. instrumenting profilers, and reading a flame graph to find the function actually burning cycles instead of guessing from intuition.
3 — Memory Profiling
Heap growth, allocation patterns, and the leak-hunting workflow for the class of bug that only shows up as a slow, inevitable OOM hours into a service's uptime.
4 — Disk Performance
IOPS, throughput, and queue depth as the metrics that separate a genuinely disk-bound service from one that just looks that way in a dashboard.
5 — Network Performance
Bandwidth, latency, and packet loss as distinct failure signatures, and the tools that tell you which one is actually behind a 'the network is slow' report.
6 — Benchmarking
Designing a benchmark that measures what production actually does, not what's convenient to measure — and the methodology gaps that make most benchmarks lie.
7 — Load Testing
Validating a system behaves correctly at expected peak traffic, and the difference between a load test that proves capacity and one that just proves the test ran.
8 — Stress Testing
Pushing a system past its expected limits to find where and how it breaks — the failure mode, not just the breaking point, is the actual finding.
9 — Spike Testing
Testing a system's response to sudden, extreme traffic jumps — the autoscaling lag and cold-start behavior that a gradual ramp-up test never exposes.
1 — Continuous Integration
Merging and testing changes continuously so integration problems surface in minutes, not in the multi-day merge conflict that used to be normal.
10 — Supply Chain Security
SBOMs, artifact signing, and provenance attestation — verifying what's actually being deployed is what was actually built, not something injected in between.
2 — Continuous Delivery
Keeping every merged change in a deployable state, which is the precondition every other release-engineering practice in this Part builds on.
3 — Deployment Strategies
The spectrum from all-at-once to fully progressive rollout, and the blast-radius-vs-speed trade-off each point on that spectrum makes.
4 — Blue-Green Deployments
Running two full production environments and switching traffic between them atomically — instant rollback, at the cost of running double the infrastructure.
5 — Canary Releases
Shipping a change to a small traffic slice first and watching its SLIs before a full rollout — the deployment strategy error budgets were built to gate.
6 — Feature Flags
Decoupling deploy from release so a bad feature can be turned off in seconds instead of requiring a rollback — and the flag-debt that accumulates if they're never cleaned up.
7 — Progressive Delivery
Combining canaries, feature flags, and automated analysis into a single rollout pipeline that promotes or rolls back on its own based on live SLI data.
8 — Rollbacks
Why 'roll back' has to be a tested, fast, boring operation — the incident-response tool you only find out is broken during the incident where you need it.
9 — Release Automation
Removing the manual, error-prone steps from a release so the process is identical — and equally safe — at 2pm on a Tuesday and 2am during an incident.
1 — Identity and Access Management
Who can do what, to which system, and how that access is granted, reviewed, and revoked — the control plane every other security chapter in this Part depends on.
10 — Business Continuity
The organizational plan for keeping the business running through a disaster, of which technical disaster recovery is only one component.
2 — Secrets Management
Why a secret hardcoded in a config file or env var is a standing incident waiting for a git history search, and the vault-backed rotation that closes that gap.
3 — Zero Trust
Verifying every request regardless of network origin, on the assumption the perimeter is already compromised — and what that means for how services actually authenticate to each other.
4 — Network Security
Segmentation, firewalling, and the assumption that lateral movement is possible the moment any single node is compromised.
5 — Kubernetes Security
RBAC, pod security standards, and network policies — the layers that keep a compromised container from becoming a compromised cluster.
6 — Runtime Security
Detecting anomalous behavior in a running workload — the security signal that exists only after static scanning and admission control have already passed.
7 — Incident Response for Security
Why a security incident's containment-first response differs from a reliability incident's restore-service-first one, and where the two response models collide.
8 — Compliance
Where audit and regulatory obligations intersect with the reliability practice — access logs, retention policies, and the postmortem review process itself.
9 — Disaster Recovery
RTO and RPO as the two numbers that actually define a DR plan, and the difference between a plan that exists on paper and one that's been tested.
1 — Relational Databases
ACID guarantees, transaction isolation levels, and the reliability characteristics an SRE inherits the moment a service depends on one.
2 — NoSQL Systems
The consistency, availability, and schema trade-offs different NoSQL models make, and why 'NoSQL' is really a dozen different reliability postures wearing one name.
3 — Distributed Databases
How a database spreads data and consensus across nodes, and the CAP-theorem trade-off it's making on your behalf whether or not that's documented.
4 — Replication
Synchronous vs. asynchronous replication, and the replication-lag failure mode that turns a 'read your own write' assumption into an intermittent bug report.
5 — Sharding
Partitioning data across nodes to scale past a single machine's limits, and the resharding operation that's usually the actual hard part.
6 — Backup Strategies
Full, incremental, and snapshot backups, and the retention policy that has to balance recovery granularity against storage cost.
7 — Recovery Strategies
Restoring from a backup is the easy half — validating the restored data is actually correct and current is the half most recovery plans skip until it matters.
8 — Data Reliability
Durability, consistency, and corruption detection as their own reliability discipline, distinct from the service-availability SLOs the rest of this book focuses on.
1 — Platform Engineering Fundamentals
Building the internal platform other teams build on, which changes the job from operating one service to operating the thing every service depends on.
2 — Internal Developer Platforms
The self-service layer that turns 'file a ticket and wait' into 'click a button and get a compliant environment' — and the golden-path opinions that make that safe.
3 — Self-Service Infrastructure
Giving product teams the ability to provision infrastructure themselves without giving up the guardrails that keep that infrastructure compliant and reliable.
4 — Golden Paths
The paved, supported way to build a service on the platform — and why an easy golden path is what makes the unsupported path rare instead of forbidden.
5 — Kubernetes Platforms
Turning raw Kubernetes into a platform product — multi-tenancy, policy enforcement, and the abstractions that hide cluster complexity from application teams.
6 — Developer Experience
Treating the platform's internal users as real users with real UX expectations, because a platform nobody wants to use gets worked around, not adopted.
7 — Multi-Tenant Platforms
Isolating tenants sharing the same underlying infrastructure — noisy-neighbor prevention, quota enforcement, and the blast-radius containment that makes sharing safe.
8 — Platform Reliability
Why the platform's own SLOs matter more than any single service's — a platform outage takes down every team building on it at once.
1 — Designing Planet-Scale Systems
What changes architecturally once a system has to serve every region on earth — the assumptions that hold at one datacenter's scale and break at planet scale.
2 — Global Traffic Management
Routing users to the right region by latency, health, and capacity simultaneously, and the DNS- and anycast-level mechanics that make global failover fast.
3 — Edge Computing
Pushing compute and data closer to the user to cut latency, and the consistency and deployment complexity that distributing logic to the edge buys in exchange.
4 — Multi-Cloud Reliability
The real cost — not just financial — of running reliably across more than one cloud provider, and where multi-cloud actually reduces blast radius versus just adding complexity.
5 — Active-Active Systems
Serving live traffic from more than one region simultaneously, and the conflict-resolution problem that active-active pushes onto every stateful write.
6 — Active-Passive Systems
Keeping a standby ready to take over, and the failover-testing discipline that's the only thing standing between 'passive' and 'silently broken.'
7 — Disaster Recovery Patterns
The concrete architectural patterns — pilot light, warm standby, multi-site — that turn a DR strategy from a document into something that actually executes under pressure.
8 — Cost vs Reliability
Why every nine of additional availability has a real, escalating price tag, and the point past which more redundancy stops being worth what it costs.
9 — Sustainability Engineering
Carbon and energy footprint as an emerging constraint on architecture decisions, alongside cost and reliability rather than instead of them.
1 — Building an SRE Organization
The team-topology decisions — embedded vs. centralized, how many SREs per service — that determine whether SRE scales with the org or becomes its bottleneck.
2 — Defining Reliability Strategy
Setting reliability targets and investment priorities at an org level, not per-service — the strategy layer above any individual team's SLOs.
3 — Reliability Reviews
The recurring cadence that keeps SLO attainment, error-budget burn, and toil trends visible to leadership before they become a crisis.
4 — Executive Reliability Metrics
Translating error budgets and burn rate into the handful of numbers an executive actually needs to make a reliability-vs-velocity call.
5 — Engineering Culture
Why blameless postmortems and error budgets only work if the surrounding culture actually rewards surfacing problems instead of hiding them.
6 — Hiring SREs
What to actually screen for in an SRE hire — the systems-thinking and incident judgment that don't show up in a standard coding interview.
7 — Mentoring Engineers
Building the next generation of on-call-capable engineers deliberately, instead of letting incident experience be the only teacher.
8 — Technical Leadership
Driving a reliability initiative across teams that don't report to you — the influence-without-authority skill every staff-plus SRE role actually runs on.
9 — Organizational Scaling
How SRE practices that work at 10 services and one team break at 1,000 services and thirty teams, and what has to change structurally to keep up.
1 — Linux Interview Questions
The Linux-internals questions that actually come up in SRE loops, and the level of depth — not just the right answer — that separates an L4 response from an L6 one.
10 — System Design for SRE
How an SRE-flavored system-design interview differs from a generic one — operability, failure modes, and observability weighted as heavily as the happy-path architecture.
11 — Troubleshooting Interviews
Live, ambiguous debugging exercises where the interviewer is grading your hypothesis-and-elimination process, not whether you guess the bug in one try.
12 — Behavioral Interviews for SRE
STAR-format incident and leadership stories, and why 'what did you personally do' is the follow-up that separates a real story from a team-credit one.
13 — Staff/Principal SRE Interviews
What changes at L6/L7 — cross-org influence, strategy, and ambiguous scope replace hands-on execution as the thing being evaluated.
14 — End-to-End Production Case Studies
Full incident-to-postmortem case studies that string together design, detection, response, and review into the single narrative a real interview loop is actually testing for.
2 — Networking Interview Questions
TCP, DNS, load balancing, and TLS questions framed the way interviewers actually ask them — as a debugging scenario, not a trivia quiz.
3 — Kubernetes Interview Questions
The Kubernetes questions that probe whether you've actually operated a cluster under failure, not just deployed a YAML file that worked once.
4 — Cloud Architecture Interview Questions
Designing for a specific cloud's failure domains and managed-service trade-offs — the questions that test whether you understand what you're actually building on.
5 — Distributed Systems Interview Questions
CAP, consensus, and consistency questions posed as system-design trade-offs, which is how they actually show up in a Staff-level loop.
6 — Observability Interview Questions
Questions that test whether you can design an SLI/SLO and instrumentation strategy from scratch, not just recite what Prometheus and OpenTelemetry do.
7 — Incident Response Scenarios
Live incident-simulation questions that evaluate triage judgment and communication under pressure — the format most SRE loops actually weight heaviest.
8 — Performance Debugging Interviews
Being handed a symptom — high latency, high CPU — and narrating a systematic diagnosis instead of guessing, which is what the interviewer is actually scoring.
9 — Reliability Design Interviews
Designing SLOs, redundancy, and failure handling for a system from a one-line prompt — the reliability-flavored half of an SRE system-design loop.
Site Reliability Engineering: From Foundations to Internet-Scale Systems
The complete 184-chapter, 15-part Site Reliability Engineering curriculum — from Linux internals and distributed-systems theory through reliability engineering, observability, incident response, platform engineering, and Staff/Principal-level MAANG interview preparation, ordered the way SRE expertise actually develops rather than as a topic index.