> In my understanding SRE is more related to "keep the lights on and systems running", it might be just a different understanding of the nomenclature.
SREs at Google own production in a very deep sense. They are decision makers on things like when teams can deploy, how frequently, what dependencies they can use, and possibly most significantly, who gets SRE support and who has to handle their own on call rotation. They also build monitoring and reliability services and tools.
Google also employs traditional Ops people, but not as many as you might suspect. When SREs look at traditional Ops work, they see a threat to reliability and a target for automation. The mantra is that the "E" isn't for show, and that SREs are software engineers who specialize on the topic of running highly reliable services. One of the things the SRE book stresses is making sure that SRE teams aren't so bogged down in oncall responsibilities that they don't have time to work on automating their oncall responsibilities.
SREs at Google own production in a very deep sense. They are decision makers on things like when teams can deploy, how frequently, what dependencies they can use, and possibly most significantly, who gets SRE support and who has to handle their own on call rotation. They also build monitoring and reliability services and tools.
Google also employs traditional Ops people, but not as many as you might suspect. When SREs look at traditional Ops work, they see a threat to reliability and a target for automation. The mantra is that the "E" isn't for show, and that SREs are software engineers who specialize on the topic of running highly reliable services. One of the things the SRE book stresses is making sure that SRE teams aren't so bogged down in oncall responsibilities that they don't have time to work on automating their oncall responsibilities.