Site Reliability Engineering Webinar

Transcript

1. Introduction to SRE & DevOps Yury Niño Roa Software Engineering II Universidad Nacional de Colombia
2. • What is DevOps & SRE? • How did I become in SRE? • How is my daily life? • DevOps Practices • Resilience & Chaos Engineering • Human Factors & Postmortems
4. Shana Diez Director of Build Reliability
5. Reliability is an Important Feature If a system isn't reliable, users won't trust it. 500 Something was wrong!
6. DevOps SRE
7. Introducción El framework provee referencias, lineamientos, políticas, mejores prácticas y protocolos que se administran de manera centralizada. DevOps Culture
8. DevOps is a mindset inspired in the collaboration between operations and development teams. SRE is talent and technical experience that engineers develop to solve problems related to Infrastructure, Security and Operations using Software Engineering. Introducción SRE vs DevOps
9. SRE is an organizational model for running online services more reliably by teams that are chartered to do reliability focused engineering work. What is SRE book SRE is what happens when you ask a software engineer to design an operations team! SRE Book SRE is doing work that has historically been done by an operations team, but using engineers with software expertise and with the ability to design and implement automation to replace human labor. What is SRE book
10. Site Reliability Engineering is what you get when you treat operations as if it’s a software problem. Their mission is to protect and progress software with an ever-watchful eye on their availability, latency and performance. They are not Heroes!!!
12. How did I become in SRE?
13. Key skill areas for an SRE? • Software engineering • Distributed systems design • Operating systems • Networking • Databases • Security • Reliability best practices • Troubleshooting • Customer support
14. Introducción SRE Areas of Expertise
15. Introducción From SysAdmin to SRE
16. Introducción From Developer to SRE
17. https://roadmap.sh/devops
18. https://roadmap.sh/devops
19. https://roadmap.sh/devops
20. How is my daily life?
23. Why DevOps? DevOps Practices
26. DevOps Pillars Culture Automation Measure Sharing
27. DevOps Practices CI/CD Monitoring Infra as Code Containers Security Reliability Performance Tooling Config as Code
28. DevOps Continuous Integration/Deployment
29. DevOps Infrastructure as Code
30. DevOps Monitoring
31. DevOps Tooling
32. DevOps Containers
33. DevOps Security Dev[Sec]Ops is empowered engineering teams taking ownership of how their product performs in production [including security]
34. • Automating everything. • Choosing the right tool. • Writing all your infrastructure in code. • Building a good CI/CD pipeline. • Integrating tests. • Applying security with DevSecOps. • Monitoring your system. • Evolving project management. DevOps Recommendations
35. What about SRE?
36. 2008-2013 DevOps is born Ben Treynor coined SRE 2014 First Conference about SRE: SRECon 2016-2018 SRE Books are released Why SRE in Google? 2019 SRE massification
37. Following SRE Practices Practical Alerting Emergency Response Being On-Call Effective Troubleshooting
38. Following SRE Practices Testing for Reliability Load Balancing DC Software Engineering Load Balancing FE
39. Following SRE Practices Handling Overload Distributed Scheduling Cascading Failures Distributed Consensus
40. Following SRE Practices Processing Pipelines Chaos Engineering Data Integrity Reliable Launches
41. Resilience & Chaos Engineering
42. Chaos Engineering It is the discipline of experimenting in production on a distributed system in order to reveal their weakness and to build confidence in their resilience capability. https://principlesofchaos.org/
43. What my mom thinks I do What my friends thinks I do What software engineers think I do What I really do Who is a Chaos Engineer? Help service owners to increase their resilience through education, tools and encouragement.
44. Human Factors & Postmortems
46. The best way to promote a postmortem culture is adopting a new view, a view focused in the syntoms, no in the causes ...