3 ms·
in most places SRE is title-inflation for DevOps, but in a less cynical interpretation it's the idea of 1) having reliable enough base-layer systems that produc
by rrix2 4y ago
in most places SRE is title-inflation for DevOps, but in a less cynical interpretation it's the idea of 1) having reliable enough base-layer systems that product engineers don't need to care about servers or debug networks or in the most extreme cases log in to production machines themselves 2) putting engineers who have strong systems engineering, software engineering, and debugging skills in the same seats as the most critical product teams to carry the pager and fine tune and optimize those services without reporting to the product teams' leadership whose goals might be in conflict with engineering reliable systems.
This really only happens well at Google AFAICT.
the "new SRE" team Will mentioned was a bunch of ex-Google Infra folks who brought a holy book [https://sre.google/sre-book/table-of-contents/ https://sre.google/sre-book/table-of-contents/] with them and asked us to institute these practices whole-cloth. some of them had already been phased out of google by then but how could we have known
- GauntletWizard 4y agoJust because it's been phased out at Google doesn't mean it's not worthwhile. There's a lot to be learned and a lot of value to be gained out of building GFS before Colossus (Though that example is getting out of date - I would no longer recommend that anyone try to build a GFS-Patterned distributed filesystem, but for several years after the party I attended to celebrate the final death of GFS I would still recommend that new-unicorns looking to build their own distributed filesystem layer go for the GFS Architecture first). There's a lot of techniques and tools that are no longer in favor at Google not because they're not the best available SRE tools, but because that's how far Google has fallen from grace.