```I don’t really understand how this is an example of circumventing the dev/ops split. I can see how it’s true in one sense, but the example of stopping all releases because an error budget got hit doesn’t seem fundamentally different from the “sysadmin” example where teams push back against launches. It seems that SREs have more political capital to spend and that, in the specific examples given, the SREs might be more reasonable, but there’s no reason to think that sysadmins can’t be reasonable.```

Seems we don't understand the point of SREs at all.

In a world where "ops" and "dev" are split and sysadmins occupy "ops" it is customary that system admins are not programmers, may not know how to program, do not venture into the VCS for the codebase and may not even have rights to check-in code to the software. It would certainly be unusual to see check-ins to the codebase from the ops/sysadmin team.

This leads to the situation where you have 10 year old codebases running on 10 year old frameworks on 10 year old operating systems. The system admins are naturally tearing their f---ing hair out over this situation. The devs, however, have the platform on life support and are off writing new code for shiny systems because that's a lot more interesting and useful than keeping the old garbage on life support. No progress is made and the problem typically doesn't resolve itself until the old systems become sufficiently problematic that the devs rewrite the entire system.

If you have an SRE model it should never get quite this bad. The Devs will support the code in production until they're ready to hand it over for maintenance. When it is handed over the SREs get all the keys to the kingdom and have the rights, responsibility and ability to fix bugs in the software they're running.

If you have legacy codebases run entirely by ops people who don't have any ability to maintain the codebases then you aren't doing SRE.

This is one of the manifestations of the "chinese wall" between ops and dev (which is what "DevOps" and "SREs" are entirely antithetical to--it may be hard to define what those terms /are/ but it is pretty easy to define some patterns that they definitely /are not/). If "Ops" has to come begging to "Dev" to fix their software then you're not doing it right.