SRE Demystified - 12 - Docs that matter -1
0 likes174 views
The document emphasizes the importance of documentation within SRE teams, particularly for preserving knowledge and preventing fragmented processes as the team grows. It outlines various types of documents needed for service onboarding, running a service, and maintaining policies and SLAs. Additionally, it highlights the roles of templates, such as post-mortems and engagement models, in ensuring smooth operational practices.
SRE Demystified - 12 - Docs that matter -1
- 1. SRE Demystified Docs that matter - 1 ganesh@ganeshniyer.com ganesh.vigneswara@gmail.com, http://ganeshniyer.com Dr Ganesh Neelakanta Iyer
- 4. Why Documentation is important? • In the early stages of an SRE team's existence, the organization depends heavily on the performance of highly skilled individuals on the team • The team preserves important operational concepts and principles as nuggets of "tribal knowledge" that are passed on verbally to new team members • If these concepts and principles are not codified and documented, they will often need to be relearned painfully through trial and error • Sometimes team members perform operational procedures as a strict sequence of steps defined by their predecessors in the distant past, without understanding the reasons these steps were initially prescribed • If this is allowed to continue, processes eventually become fragmented and tend to degenerate as the team scales up to handle new challenges 4
- 5. Documents for New Service Onboarding 5 https://cornerofficedotblog.files.wordpress.com/2018/04/dilbert-onboarding.png?w=700
- 6. Example PRR Template Areas 6 Area Questions Architecture and dependencies What is your request flow from user to front end to back end? Are there different types of requests with different latency requirements? Capacity planning How much traffic and rate of growth do you expect during and after the launch? Have you obtained all the compute resources needed to support your traffic? Failure modes Do you have any single points of failure in your design? How do you mitigate unavailability of your dependencies? Processes and automation Are any manual processes required to keep the service running? External dependencies What third-party code, data, services, or events do the service or the launch depend upon? Do any partners depend on your service? If so, do they need to be notified of your launch?
- 7. Engagement Model Doc • Service takeover criteria and the PRR process. • SLO negotiation process and error budgets. • New launch criteria and launch freeze policy (if applicable). • Content and frequency of service status reports from the SRE team. • RE staffing requirements. • Feature roadmap planning process and priority of reliability features (requested by SREs) versus new product functionality. 7
- 8. Documents for Running a Service 8 https://s3.amazonaws.com/lowres.cartoonstock.com/law-order-running_amok- cars-engine_trouble-engines-auto-mban867_low.jpg
- 9. Post-mortem Template • Timeline. • Description of user impact. • Root cause. • Action items / lessons learned. 9
- 10. Policies and SLA • Policies • Policy documents mandate specific technical and nontechnical policies for production • Technical policies can apply to areas such as production-change logging, log retention, internal service naming, and use of and access to emergency credentials • SLA • SRE teams document their service(s) SLA for availability and latency, and monitor service performance relative to the SLA • Documenting and publishing an SLA, and rigorously measuring the end-user experience and comparing it with the SLA, allows SRE teams to innovate more quickly while preserving a good user experience 10
- 11. Documents for Production Products • SRE teams aim to spend 50 percent of their time on project work, developing software that automates away manual work or improves the reliability of a managed service • These documents are important because they enable users to find out whether a product is right for them to adopt, how to get started, and how to get support • They also provide a consistent user experience and facilitate product adoption 11
- 12. 12
- 13. References 13
- 14. Dr Ganesh Neelakanta Iyer ganesh@ganeshniyer.com ganesh.vigneswara@gmail.com