5 ms·

Blindly replicating what Google is doing is really problematic, I saw something similar at a few companies. The principles are interesting, but they have to con

Blindly replicating what Google is doing is really problematic, I saw something similar at a few companies. The principles are interesting, but they have to consider each company's reality. Google is putting a lot of marketing money on the topic, but from what I saw they are trying to alert that there is no one size fits all for this.

jeffbee 6y ago
So far I haven't seen any companies replicating what Google SRE does, blindly or intentionally. Much as this article describes, organizations I've seen are just inventing a role they perceive to exist in their organization and slapping the label "SRE" upon it. Often these roles are directly contradictory to the way Google SRE works: they are just carrying pagers for products they aren't allowed to improve, they own build/test/release for some reason even though that clearly falls in the domain of the developer, SREs are setting service levels which is obviously the responsibility of product. I think people should realize that when you go into the hiring market looking for SREs, you are about to pay more, not less, for a highly qualified software engineer who is also a systems expert. You want these people to not just operate product, but to be closely involved in architecture and development so the product turns out to be operable. Your SREs should be working in the product code on the bits that ordinary developers might overlook or not be qualified to write, because they lack expertise in system or distributed systems behavior. What this article is calling "real world" is just an attempt to redefine the term.
- sumtechguy 6y ago
  An SRE with no authority to do anything is just an overpaid totally frustrated paperweight. They have to be able to change things on both sides of the 'fence' if they can only do one or the other or neither then their role is not an SRE no matter what sorts of titles you give them. Any org I go into that says 'we want an SRE because google has one' I can not help myself I blurt out 'you are not google. what works for them will not work for you, you need to find your own way of doing this that fits your org. Trying to mimic google without the understanding of why they way they are will damage your org'
  - user5994461 6y ago
    >>> An SRE with no authority to do anything is just an overpaid totally frustrated paperweight. That matches my experience at most companies, the SRE/DevOps is just the sucker who is on call.
    - dodobirdlord 6y ago
      I think authority is a critical differentiator between the SRE described in the Google book and SRE as it’s practiced elsewhere. Google SREs can impose moratoriums on feature development or deployments if they judge that a product is becoming critically unreliable (which has a well-defined meaning based on SLO breaches). SRE teams will also sometimes “offboard” a product that is insufficiently respectful of the finite attention that an SRE team needs to spread across multiple products, returning full production control to the development team along with the pager and all responsibilities thereof.
      - sumtechguy 6y ago
        I think one more differentiator is the dedicated position. Rotation is not SRE. It can be helpful to help people understand both sides. But just rotating your team into the role every few weeks with no real 'group in charge' just seems to make them mad.
  - apple4ever 6y ago
    > An SRE with no authority to do anything is just an overpaid totally frustrated paperweight That's exactly how it is implemented in my company. We are called SREs but everything is driven my management (and by that I mean a single VP who is omnipresent).
- throwayws 6y ago
  I thought an SRE is contacted when your house burns down due to for example scaling and to improve operations where much more load/customers are expected, no? Where the house is expected to fall but where it is not allowed to happen.
  - jeffbee 6y ago
    No, you bring the SREs in to consult on designing a fire-resistant house before you turn a shovel. Calling them after you've already designed, built, and burned the house is likely to leave you disappointed.
the_70x 6y ago
and the fact that not all the companies run the same workloads or scale as google
zimbatm 6y ago
I feel like there is an analogy with self-help books. Every personality and company is different and they have to do the work to find out what works best for them. Internalizing the meaning of things and leading your own thinking is probably as important as the practices themselves. Adopting another company's practices is often lazy thinking. There are no silver bullets.
gowld 6y ago
Marketing money? besides paying people to publish their work?

jeffbee 6y ago

So far I haven't seen any companies replicating what Google SRE does, blindly or intentionally. Much as this article describes, organizations I've seen are just inventing a role they perceive to exist in their organization and slapping the label "SRE" upon it. Often these roles are directly contradictory to the way Google SRE works: they are just carrying pagers for products they aren't allowed to improve, they own build/test/release for some reason even though that clearly falls in the domain of the developer, SREs are setting service levels which is obviously the responsibility of product. I think people should realize that when you go into the hiring market looking for SREs, you are about to pay more, not less, for a highly qualified software engineer who is also a systems expert. You want these people to not just operate product, but to be closely involved in architecture and development so the product turns out to be operable. Your SREs should be working in the product code on the bits that ordinary developers might overlook or not be qualified to write, because they lack expertise in system or distributed systems behavior. What this article is calling "real world" is just an attempt to redefine the term.

sumtechguy 6y ago
An SRE with no authority to do anything is just an overpaid totally frustrated paperweight. They have to be able to change things on both sides of the 'fence' if they can only do one or the other or neither then their role is not an SRE no matter what sorts of titles you give them. Any org I go into that says 'we want an SRE because google has one' I can not help myself I blurt out 'you are not google. what works for them will not work for you, you need to find your own way of doing this that fits your org. Trying to mimic google without the understanding of why they way they are will damage your org'
- user5994461 6y ago
  >>> An SRE with no authority to do anything is just an overpaid totally frustrated paperweight. That matches my experience at most companies, the SRE/DevOps is just the sucker who is on call.
  - dodobirdlord 6y ago
    I think authority is a critical differentiator between the SRE described in the Google book and SRE as it’s practiced elsewhere. Google SREs can impose moratoriums on feature development or deployments if they judge that a product is becoming critically unreliable (which has a well-defined meaning based on SLO breaches). SRE teams will also sometimes “offboard” a product that is insufficiently respectful of the finite attention that an SRE team needs to spread across multiple products, returning full production control to the development team along with the pager and all responsibilities thereof.
    - sumtechguy 6y ago
      I think one more differentiator is the dedicated position. Rotation is not SRE. It can be helpful to help people understand both sides. But just rotating your team into the role every few weeks with no real 'group in charge' just seems to make them mad.
- apple4ever 6y ago
  > An SRE with no authority to do anything is just an overpaid totally frustrated paperweight That's exactly how it is implemented in my company. We are called SREs but everything is driven my management (and by that I mean a single VP who is omnipresent).
throwayws 6y ago
I thought an SRE is contacted when your house burns down due to for example scaling and to improve operations where much more load/customers are expected, no? Where the house is expected to fall but where it is not allowed to happen.
- jeffbee 6y ago
  No, you bring the SREs in to consult on designing a fire-resistant house before you turn a shovel. Calling them after you've already designed, built, and burned the house is likely to leave you disappointed.

the_70x 6y ago

and the fact that not all the companies run the same workloads or scale as google

zimbatm 6y ago

I feel like there is an analogy with self-help books. Every personality and company is different and they have to do the work to find out what works best for them. Internalizing the meaning of things and leading your own thinking is probably as important as the practices themselves. Adopting another company's practices is often lazy thinking. There are no silver bullets.

gowld 6y ago

Marketing money? besides paying people to publish their work?