\n\n
Critical feedback: <\/strong> “It’s a good theoretical model in a vacuum, but on-the-job experience has shown me that you don’t always get to handle these in that order.”<\/p>\n\n\n\nResponse:<\/strong> I wouldn’t expect to dictate that the model be deployed in the order I’ve outlined it. Every model is good in theory until it hits the real world of competing interests, capabilities, and ambitions. <\/p>\n\n\n\nThis simplified model of Google’s SRE hierarchy serves two purposes: (1) as a conversation starter and (2) implying that capabilities should be addressed progressively by new teams rather than all at once.<\/p>\n\n<\/div><\/div><\/div>\n<\/div>\n\n
\n
\n\n
Critical feedback: <\/strong> “SRE is not a linear process, but a feedback loop where each of these areas (primarily 1-4) are improved incrementally with continuous effort. The notion that you shouldn’t automate “test & release process” until you’ve “mastered observability” is absurd.”<\/p>\n\n\n\nResponse:<\/strong> I agree that SRE is not a linear process. This is one of many lenses through which I see SRE, and I want to offer people the choice to take on. <\/p>\n\n\n\nMy personal experience has proven a pathway approach to make the whole implementation an easier pill to swallow in complex organizations.<\/p>\n\n\n\n
A few things to consider regarding observability vs<\/em> test and release from an organization design perspective:<\/p>\n\n\n\n\n- Sure, if you have a strong case for test and release procedures first, why not? But most leaders I have personal experience<\/em> working with would cave in on their engineers without the prerequisite of having guiding data (that observability offers)<\/li>\n\n\n\n
- Another way to see it: observability is a technical exercise with upper management not knowing or caring how you do it… when you start talking about setting policy or procedures, that becomes a sociotechnical exercise involving input from developers, team leads, managers, and ultimately egos and ambitions – with raw data from observability, you can argue for a better path<\/li>\n<\/ul>\n\n<\/div><\/div><\/div>\n<\/div>\n\n\n
<\/div>\n\n\n\n
I will explore my visual pathway map in a future post. For now, enjoy greater clarity around Google’s SRE hierarchy. <\/p>\n","protected":false},"excerpt":{"rendered":"
Google’s book on SRE, Site Reliability Engineering (2016), has captured wide acclaim in the software operations world. One of the most discussed aspects in SRE circles about the book is its SRE hierarchy. The hierarchy has merit, but it’s also flawed in a way that would prevent you from educating people about SRE. I’ll get […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[60,1,4],"tags":[],"_links":{"self":[{"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/posts\/555"}],"collection":[{"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/comments?post=555"}],"version-history":[{"count":20,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/posts\/555\/revisions"}],"predecessor-version":[{"id":5763,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/posts\/555\/revisions\/5763"}],"wp:attachment":[{"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/media?parent=555"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/categories?post=555"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/tags?post=555"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}