But wait, I don’t develop my own applications so I don’t need SRE’s.
But wait, I don’t have the headcount for SRE’s.
While it is true that shops that develop and run cloud native environments benefit greatly from the SRE role, advancements in observability, automation, and AI requires the SRE job function to fully benefit.
I council people that the SRE role does not need to be specific, named resources. The SRE role in the observability framework is a job function. In many organizations that job function may be carried out by an administrator of the system. This is similar to the ITIL framework.
There are more than 40 roles in the ITIL framework. The ITIL framework never intended that each role was a unique individual. In many organizations one person may fill the role of several ITIL roles. Your Enterprise Architect may be the same person as the Process Architect. The Business Relationship Manager, IT Service Continuity Manager, and the Process Owner may very well be the same person and in reality is the I.T. Director.
Implementing observability and the SRE role is about assigning tasks to the appropriate resources. It is the role of the SRE to understand your production systems. They then manage the services according to service level objectives (SLOs).
The SRE is there to remove toil.
When you move from traditional monitoring to observability you don’t start with a deluge of alerts that with potential causes of outages. The SRE measures symptoms of user pain and then drills down into understanding the outage by using observability tooling such as AIOPS.
As you move up the maturity curve, the mature SRE is using techniques such as feature flagging, continuous verification and incident analysis.
You do not need to hire somebody with the title of SRE. If you want to implement observability, better manage your environment, remove toil, automate, and use greater intelligence, assign these duties to the appropriate teams and you will begin your SRE journey.
