Site Reliablity Engineers Handbook (Anupam Singh) (z-library.sk, 1lib.sk, z-lib.sk)

【One-Line Pitch】 A practical, manager-friendly tour of how site reliability engineering fits into the modern software lifecycle—what SRE does, how it differs from DevOps, and which habits and anti-patterns decide whether a system stays reliable. Best for developers, DevOps practitioners, and team leads who want a working vocabulary of SLOs, change management, and reliability practice rather than deep code. 【Book Arc】 - **Opening (~0%–10%)**: Sets up why SRE exists, where the role sits in the SDLC, and how SRE teams divide labor with development and operations; introduces the SLA/SLO/SLI vocabulary that anchors the rest of the book. - **Early (~10%–32%)**: Positions SRE against DevOps—shared practices (CI/CD, quality gates, measurement, change management) and differences—then walks a worked project scenario from requirements through release, monitoring, and incident handling. - **Middle (~32%–48%)**: Moves into building reliable systems: scaling approaches, testing types (unit through chaos), self-healing, capacity planning and cost management, and how to choose monitoring/observability tooling. - **Late (beyond ~48%)**: The excerpts indicate chapters on anti-patterns—what they are, how to recognize them, and how to counter them—but the sampled material does not cover this section in detail. - **Ending**: Not represented in the excerpts; the closing chapters and any concluding guidance are outside this guide's coverage. 【Key Takeaways】 - **SRE is a lifecycle partner, not a firefighting squad** (Opening): The book frames SRE as embedded across planning, build, deploy, and operate, with the cloud-native shift pushing the role toward enablement and developer self-service rather than manual rescue. - **SLA, SLO, and SLI form a hierarchy of promises** (Early): The customer-facing SLA is looser than the internal SLO, and the SLI is the actual measurement (uptime, throughput). The worked example—an incident that dents SLO/SLI but not SLA—makes the distinction concrete and shows why internal targets buy safety margin. - **SRE and DevOps overlap but are not the same** (Early): Both care about quality gates, metrics, and change management; DevOps owns pipelines and delivery speed, while SRE defines what may reach production, reviews changes, and owns reliability outcomes. Useful for settling team-boundary arguments. - **Change management is the hinge between the two disciplines** (Early): Timelines, approval workflows, impact assessment, and rollback options are described as SRE-defined controls that DevOps then automates into pipelines—a practical model for preventing bad deploys. - **Reliability is engineered through testing and self-healing** (Middle): The book catalogs testing layers up to chaos testing, and treats automatic remediation (retries in code, infrastructure auto-scaling/recovery) as a core reliability lever because it hides failures from users. - **Capacity planning and cost management belong together** (Middle): Planning cycles (e.g., multi-week program increments) should be paired with cost assessment across people, tools, and infrastructure; the book borrows lag-style capacity strategies from manufacturing and adapts them to software. - **Tool choice is a planning decision, not an afterthought** (Middle): Define the metrics first, then pick a monitoring/observability tool (Prometheus/Grafana, Datadog, Dynatrace, and similar) based on compatibility, cost, and available skills—open source versus subscription is an explicit trade-off. - **Anti-patterns are the hidden roadblocks** (Late): The book treats recurring engineering and reliability problems as recognizable patterns to be named and countered; the excerpts flag this theme but do not supply the specific catalog. 【Reading Tips】 - Read the SLA/SLO/SLI section and the worked project scenario closely—they are the most transferable material and give you language for reliability conversations with product and ops teams. - Skim the tool lists and capacity-strategy taxonomy if you already know the landscape; extract the decision criteria (metrics first, then compatibility, cost, skills) rather than the vendor names. - Treat the SRE-versus-DevOps chapters as a boundary-setting exercise: note which responsibilities your own organization assigns where, and where handoffs currently fail. - The anti-pattern chapters are the likely payoff for experienced readers; if your copy includes them, read them with a current project in mind and map each pattern to something you have seen. 【Coverage Limits】 This guide is based on stratified excerpts covering roughly the first half of the book; the anti-pattern chapters, later material, and the book's conclusion are only glimpsed or absent, so specifics there are not summarized.