Improve Chapter 31 reading path

docs/lessons/31_methodology_policy_and_politics/31.11_recommended_reading.md

@@ -1,72 +1,308 @@
-## 31.11 Recommended Reading 📚
+## 31.11 Recommended Reading
 
+This chapter is about the human operating system around Linux: methods,
+policies, tickets, documentation, environments, disaster recovery, SLAs,
+compliance, legal boundaries, and professional communities.
 
+The best reading path is not a pile of random links. It should help you make
+better production decisions, write clearer evidence, and understand why
+organizations add process around technical work.
 
 !!! abstract "What you will learn"
-    - Explain where **31.11 Recommended Reading 📚** fits in day-to-day Linux operations.
-    - Use current Linux tooling to inspect, change, and verify the relevant system behavior.
-    - Connect the concept to a real operational scenario: an operations team trying to become predictable without becoming bureaucratic.
-
-!!! example "Field story"
-    Imagine an operations team trying to become predictable without becoming bureaucratic. Your job is not to memorize a command; it is to build a short evidence trail, choose a low-risk change, and prove whether the system improved.
+    - Build a reading path for Linux operations methodology and governance.
+    - Separate primary sources from commentary and vendor marketing.
+    - Choose resources for DevOps, SRE, ITSM, policy, compliance, and incident
+      response.
+    - Turn reading into local runbooks, checklists, and evidence templates.
 
 !!! success "Operator principle"
-    Policies are useful when they make good work easier and risky work harder.
+    Good reading should change how you operate: fewer risky surprises, clearer
+    handoffs, better evidence, and more reliable recovery.
 
-## Hands-on practice
+## Start with the local truth
 
-Run these on a disposable VM, container, or lab machine unless the lesson explicitly says otherwise.
+Before reading a book or blog, read your own environment.
 
-1. Inspect the current state with a read-only command related to this topic.
-2. Save the command and output in a short lab note.
-3. Make one reversible change or simulate the change in a sandbox.
-4. Re-run the inspection and explain what changed.
+Useful local sources:
 
-## Check your understanding
+- service runbooks
+- architecture diagrams
+- change-management rules
+- incident-response plan
+- access-control policy
+- backup and restore procedures
+- monitoring and alert definitions
+- SLA or SLO documents
+- compliance evidence templates
+- data-retention policy
+- legal-hold or records-management procedure
+
+Ask these questions:
+
+- Is this document current?
+- Who owns it?
+- What system does it apply to?
+- What evidence proves it is followed?
+- What happens when reality differs from the document?
+
+Local truth beats generic advice.
+
+## DevOps and delivery
+
+DevOps reading helps explain why operations and software delivery need shared
+ownership, feedback loops, automation, and fast recovery.
+
+Good starting points:
+
+- **The Phoenix Project** by Gene Kim, Kevin Behr, and George Spafford
+- **The DevOps Handbook** by Gene Kim, Jez Humble, Patrick Debois, and John
+  Willis
+- **Continuous Delivery** by Jez Humble and David Farley
+- **Accelerate** by Nicole Forsgren, Jez Humble, and Gene Kim
+
+Read for operating patterns, not slogans. Look for practices that affect Linux
+work directly:
+
+- smaller changes
+- safer deployments
+- environment separation
+- better change records
+- automated validation
+- rollback planning
+- shared incident review
+
+## Site reliability engineering
+
+SRE reading helps connect service reliability to measurable objectives instead
+of vague uptime hopes.
+
+Primary sources:
+
+- **Site Reliability Engineering** from Google
+- **The Site Reliability Workbook** from Google
+- Google Cloud SRE articles on SLIs, SLOs, error budgets, and incident response
+
+Useful topics:
+
+- defining service level indicators
+- choosing service level objectives
+- using error budgets
+- reducing toil
+- writing incident reviews
+- designing alerting around user impact
+- balancing reliability and delivery speed
+
+When reading SRE material, translate it into Linux operator questions:
+
+- What signals prove this service is healthy?
+- Which alerts wake someone up?
+- What failure modes are common?
+- How do logs and metrics support the SLO?
+- What is the rollback or failover procedure?
+
+## IT service management and change control
+
+ITSM reading explains how larger organizations coordinate support, incidents,
+problems, changes, requests, and service ownership.
+
+Useful sources:
+
+- ITIL Foundation material
+- vendor-neutral service-management articles
+- your organization's ticketing workflow documentation
+- post-incident review templates
+- change-advisory-board or standard-change examples
+
+Read critically. ITSM can help teams avoid chaos, but it can also become
+bureaucratic if it is detached from technical reality.
+
+Focus on:
+
+- incident categories
+- problem management
+- standard changes
+- emergency changes
+- service ownership
+- escalation paths
+- knowledge-base hygiene
+
+## Policy, compliance, and audit
 
-- What evidence would tell you that this system is healthy?
-- What is the riskiest command in this lesson, and how would you make it safer?
-- How would you explain section 31.11 to a teammate during an incident handoff?
+Compliance sources should be treated carefully. Prefer primary sources and
+official control language over random summaries.
 
+Useful sources:
 
-Immersing yourself in the Linux universe is a never-ending journey, with new features, tools, and best practices emerging continually. Indeed, the flame of learning must never extinguish.
+- CIS Benchmarks for Linux distributions and common services
+- NIST Cybersecurity Framework
+- NIST SP 800-series guidance relevant to your environment
+- PCI DSS official standard if payment-card data is involved
+- SOC 2 trust services criteria summaries from reputable audit firms
+- ISO/IEC 27001 overview and control references
+- vendor documentation for audit logging and retention features
 
-A well-rounded understanding of the Linux environment isn't limited to hands-on experience but also includes theoretical knowledge. In this section, we have curated some thought-provoking resources for your continual education journey in Linux, DevOps, and IT-related fields.
+Operator reading goals:
 
-📖 **‘The Cathedral & The Bazaar’** by Eric S. Raymond
-- This legendary book makes it clear why methodologies matter, particularly in the world of Open Source Software. ±
+- understand the control intent
+- identify Linux evidence that supports the control
+- document exceptions precisely
+- avoid claiming compliance without proof
+- know when to involve security, compliance, or legal teams
 
-📖 **‘The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win’** by Gene Kim, Kevin Behr, and George Spafford
-- Hailed as a modern classic, the novel underlines the emergence of DevOps and its significance in the IT sector.
+## Incident response and disaster recovery
 
-📖 **‘Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation’** by Jez Humble and David Farley
-- A comprehensive text that explains the essence of environment separation and deployment automation in the DevOps cycle.
+Incident and disaster-recovery reading should make you calmer during failure.
 
-📖 **‘Clean Code: A Handbook of Agile Software Craftsmanship’** by Robert C. Martin
-- Read this for a deep dive into code quality, software methodology, and principles for writing clean, maintainable code.
+Useful sources:
 
-📘 **Online Resources:**
+- NIST incident-handling guidance
+- CISA incident-response and ransomware guidance
+- Google's SRE incident-management material
+- Atlassian, PagerDuty, and incident.io incident-management guides
+- backup vendor restore-testing documentation
+- cloud provider disaster-recovery whitepapers
 
-- **Linux Documentation Project**
-    - A trove of tutorials, guides, and man pages concerning every aspect of Linux.
+Read for practical mechanics:
 
-- **Official Linux Kernel Documentation**
-    - Stay updated with this continually revised official documentation for Linux kernel development.
+- triage roles
+- communication channels
+- evidence capture
+- escalation timing
+- customer-impact language
+- restore testing
+- after-action review
+- follow-up ownership
 
-- **Linux Journal**
-    - An excellent source for Linux news, tutorials, reviews, and more.
+Turn good ideas into a small checklist before you need it.
 
-🎧 **Podcasts:**
+## Legal and licensing references
 
-- **The Changelog**
-    - Contains interviews with the innovators and influencers of the software world, often covering Linux-related topics.
+Operators should not improvise legal interpretations, but they should understand
+where legal issues tend to appear.
 
-- **Command Line Heroes**
-    - Produced by Red Hat, it narrates the epic true tales of the developers, hackers, and open-source rebels revolutionizing the tech landscape.
+Useful sources:
 
-- **Linux Unplugged**
-    - Offers Linux news, insightful discussions, and excellent community interaction.
+- Free Software Foundation license resources
+- Open Source Initiative license list
+- SPDX license identifiers and SBOM guidance
+- distribution package metadata and source-package records
+- internal legal or procurement guidance for software use
+- data-retention and legal-hold procedures
 
-Remember, these resources are a starting point, not an endpoint. Make it a habit to explore, read, and delve deeper into the subjects that interest you. Stay curious, stay hungry. Your Linux and IT journey is an adventure of discovery, and this list should guide you well on the paths less traveled.
+For Linux work, pay attention to:
+
+- software redistribution
+- container-image contents
+- appliance images
+- source-code obligations
+- customer data access
+- evidence preservation
+- records deletion
+
+If a legal question affects a customer, employee, regulator, law enforcement,
+contract, product shipment, or public statement, escalate.
+
+## Professional communities
+
+Communities are useful when they expose you to real incidents, trade-offs, and
+operator experience.
+
+Good places to learn:
+
+- USENIX papers and conference talks
+- SREcon talks
+- LISA conference material
+- Linux Foundation events and training
+- distribution communities such as Debian, Ubuntu, Fedora, Rocky Linux, AlmaLinux,
+  and FreeBSD
+- vendor engineering blogs from teams that publish detailed postmortems
+- local DevOps, cloud, Linux, and security meetups
+
+Evaluate communities by signal quality. A useful community values evidence,
+clear reproduction steps, and respectful correction.
+
+## How to evaluate a source
+
+Before trusting a source, ask:
+
+- Who wrote it?
+- What are they trying to sell?
+- Is it current?
+- Does it cite primary documentation?
+- Does it distinguish opinion from requirement?
+- Does it include commands that are safe to test?
+- Does it explain rollback or risk?
+- Does it match your distribution and version?
+- Does your organization already have a policy for this topic?
+
+Avoid copying commands from random posts into production. Reproduce ideas in a
+lab and tie them back to local policy.
+
+## Build a local reading notebook
+
+Create a small notebook or repository section with entries like this:
+
+```text
+Topic:
+Source:
+Date read:
+Applies to:
+Key idea:
+Local system affected:
+Command or evidence:
+Runbook or policy update needed:
+Open question:
+```
+
+The value is not collecting links. The value is turning learning into better
+operations.
+
+## Suggested four-week path
+
+Week 1: Read local policy, change-management, incident-response, and backup
+documents. Write down gaps or stale sections.
+
+Week 2: Read one DevOps or delivery source. Identify one change that would make
+deployments smaller, safer, or easier to roll back.
+
+Week 3: Read SRE material on SLIs, SLOs, error budgets, and incident response.
+Map one service to real Linux metrics, logs, and alerts.
+
+Week 4: Read one compliance or security-control source. Build a short evidence
+template for accounts, sudo, SSH, patching, logging, backups, and network
+exposure.
+
+## Hands-on practice
+
+Use your lab notes, not production systems.
+
+1. Pick one source from this lesson.
+2. Write a five-line summary in your own words.
+3. Identify one Linux command, log, configuration file, or ticket field that
+   connects the reading to daily operations.
+4. Create a small checklist or evidence template based on the reading.
+5. Mark whether the source is primary, secondary, vendor, community, or opinion.
+
+Example evidence template:
+
+```text
+Control:
+System:
+Owner:
+Requirement:
+Command or source:
+Output location:
+Reviewed by:
+Exception needed:
+Next review date:
+```
+
+## Check your understanding
 
-Happy Learning! 🥳📚🚀
+- Why should local runbooks and policies be read before generic advice?
+- What is the difference between primary documentation and commentary?
+- How can SRE reading improve Linux monitoring and alerting?
+- How can compliance reading turn into concrete evidence commands?
+- Why is copying a command from a blog risky without testing?
+- What should go into a local reading notebook?
+- How can a reading habit reduce incident and audit pain?