3 ms·

It still means mandatory, potentially grueling, on-call rotations.

• dijit 2y ago
  If you can affect the quality of the on-call, then it's not so bad. If you can't, then that's your ammunition to remove the feature from being "blessed". This is the gift that the SRE book actually gave people. That, and error budgets. It loosened peoples idea of what ops was, before this it was 100% uptime of all services at all times, and ops people being responsible for things that they could not reasonably affect nor push back on without extreme resistance from developers and management.
  • xena 2y ago
    In my experience, being "SRE" means being pager bitch. I was almost completely burned out by being pager bitch for a company that had two warring tribes of PHP and Haskell developers that just sort of threw things over the wall for SRE to keep up. We had no meaningful way to push back on developers because that impacted product release timelines and we can't have that, can we? IDK, part of the reason I got into things like DevRel is that I am good at SRE style work, but I'm just not cut out to be pager bitch like other people are. I now have a 500% premium for any job that involves oncall work. Nobody's taken me up on it, surprisingly.
  • nunez 2y ago
    Do you know of any company that actually _does_ error budgets? Like, they did the statistics on their previous downtime, calculated them and wrote SLOs with them baked in?