Site reliability engineering - what is SRE?
As companies today are racing to build site reliability engineering(SRE) practices within their engineering teams, site reliability engineering has become one of the hottest and highest paying jobs in tech.
What is Site reliability engineering?
Site reliability engineering was a term coined by Google engineer Benjamin Treynor in 2003 when he was tasked with making sure that Google services were reliable, secure and functional. He and his team eventually wrote the book on SRE which is available online for free for anyone interested in research and implementation of SRE best practices.
Site reliability engineering is the application of facets of software development to operational issues, basically bridging the gap between development and operations teams. Treynor himself has spoken about SRE:
“ SRE is what happens when you ask a software engineer to design an operations team. When I joined Google in 2003 and was tasked with running a “Production Team” of seven engineers, my entire life up to that point had been software engineering. So I designed and managed the group the way I would want it to work if I worked as an SRE myself. That group has since matured to become Google’s present-day SRE team, which remains true to its origins as envisioned by a lifelong software engineer.”
The primary goal of SRE is creating scalable, available and highly sound software systems. This applies to not just companies with the scale of Google, small companies can also utilize SRE to strengthen their architecture. Site reliability engineers work with production, operations, and end-users to develop metrics and goals for service reliability. In other words, SREs help companies define SLIs and SLOs for uptime and availability.
At this point, you may be wondering what is the difference between SRE and DevOps?
DevOps and SRE share similar core philosophies of unifying development and operations teams, automating processes and saving time during deployment. However there are key differences between the two, DevOps is a culture that emphasizes on streamlining development and non-development environments, whereas SRE is more focussed on the sysadmin role and the production environment. DevOps embraces failure as a learning experience to make systems stronger while SRE prioritizes on balance between incidents and the release of new features.
Both DevOps and SRE help organizations deliver software more efficiently while bridging gaps between IT and non-IT departments. Both of these methodologies also advocates the use of automation tools to decrease manual toil increasing reliability further.
Why are companies implementing SRE?
SLA driven performance monitoring: Site reliability engineers help measure and analyze your performance against predefined SLA guidelines. The SRE team ensures an efficient incident response, monitoring, and performance of systems so there is no breach in agreements and subsequent loss in revenue. There are also allowances for error budgets, which is a clear standard of how unreliable a service can be in a single quarter. SRE helps companies find a balance between reliability and innovation.
Embrace risk: No service can be reliable 100% of the time, it’s an unrealistic and expensive goal. SRE culture understands that risk is a part of the game and the challenge is identifying what can go wrong and protecting systems from it.
Continuous delivery: Successful SREs practice something known as “chaos engineering”, this is a practice where faulty code is deliberately injected into healthy working systems in a controlled manner to test response times, MTTR and incident management. This is crucial in a continuous delivery environment where new features are pushed every few hours to safeguard against catastrophic failure.
Cross-team skills: As already mentioned, SRE leverages the skills of developers and sysadmins to build stronger more balanced systems. Collaboration between these two disciplines is integral to developing high-quality software. SREs mainly focus on improving reliability while engineers can focus on new features fostering innovation.
Common areas to focus on while adopting site reliability engineering:
Make sure that all teams understand and believe in SRE while introducing it to your teams. If an insufficient amount of members do not get on board during implementation, your organizations might end up getting ineffective results. Communication is key when it comes to adoption, make sure all teams are on the same page when you are making changes in operations to ensure cross-team implementation. Integration should be a seamless process, with tasks being as simple as possible. Develop customized checklists for different roles to ease the transition. “Blameless post mortems” are another important aspect of SRE, meetings where there are no accusations, but productive learning from mistakes and not repeat them.
Documentation is another key aspect, as memory can be a fickle thing. Make sure that post mortem meetings are documented and published internally to make sure that searching is an easy process.
These are basic outlines of the advantages of adopting SRE, which is a never-ending process. SRE teams are constantly learning, evolving and fine-tuning their skills to improve the reliability of modern systems. Once successfully implemented, review your team strength every six months to ensure that they are not making the same mistakes they initially made.
