<story><title>Things I want from Devs as SRE/DevOps</title><url>https://oschvr.com/posts/what-id-like-as-sre/</url></story><parent_chain><item><author>chrsig</author><text>&amp;gt; If you’re a Software Engineer&amp;#x2F;Developer, then consider that a service (at least, for me), is a piece of code running in a live production system, that YOU wrote, only YOU know how it works, thus YOU own.&lt;p&gt;I&amp;#x27;ve grown unfond of this attitude. I most certainly don&amp;#x27;t own it.  I have no IP rights to it at all.  We&amp;#x27;re both being paid to solve different facets of the same problem.  Coming at me  with &amp;quot;this is your problem&amp;quot; isn&amp;#x27;t going to foster a collaborative environment with me.  Which is much more pleasant than an adversarial environment.&lt;p&gt;Also:  I&amp;#x27;m not the only one that knows how it works, it&amp;#x27;s been peer reviewed in no small part to reduce my bus factor. All documentation requested is perfectly reasonable, and should be part of the organizations standard operating procedure.&lt;p&gt;If it&amp;#x27;s not part of the SOP, then no, you wont have those things.  You need to work at a cultural level to change that, and for that you&amp;#x27;re much better off making allies than anything else.  Make it clear how those things help you, and what you&amp;#x27;ll do to make the developers life easier when you don&amp;#x27;t need to worry about the basics.  If altruism fails you, you can usually count on people to act in their own best interests.</text></item></parent_chain><comment><author>klodolph</author><text>&amp;gt; We&amp;#x27;re both being paid to solve different facets of the same problem. Coming at me with &amp;quot;this is your problem&amp;quot; isn&amp;#x27;t going to foster a collaborative environment with me.&lt;p&gt;SRE here.&lt;p&gt;My takeaway from this is: If you want SRE support running this service, then you need to provide SREs with knowledge of how the system works. As long as only the devs have this knowledge, it&amp;#x27;s a bit unfair to put the SREs on the hook for supporting it.&lt;p&gt;Maybe I&amp;#x27;m reading between the lines too much--the wording in the article is sloppy at best, and at worst, it doesn&amp;#x27;t actually say what I&amp;#x27;m saying.&lt;p&gt;It&amp;#x27;s nice that your code has been through peer review and other people on your team know how it works too. That&amp;#x27;s less helpful for the SREs running it. SREs bear the burden of the pager--sometimes getting woken up at odd hours of the night to fix problems that were, in a sense, created by developers.&lt;p&gt;The SOP for getting SRE support for new services should include things like runbooks and design reviews. SREs should be in the loop when you figure out what metrics to expose from your service, because SREs will be the ones using those metrics to figure out the alerting systems. Very few companies have decent &amp;quot;SOP&amp;quot; for SRE support--there are a few companies which are really good at it, like Google, and then a long tail of companies which dump services on SREs without including SREs in the process.&lt;p&gt;IMO--the right thing to do is to give SRE teams the power to say &amp;quot;no&amp;quot; and refuse to take the pager for any particular service, barring exceptional circumstances. There&amp;#x27;s a deeper discussion to be had about why this should be the case--basically, devs and SREs have different incentives, and neither team should be put in a subordinate position to the other, because both teams have goals that support the business.</text></comment>
<story><title>Things I want from Devs as SRE/DevOps</title><url>https://oschvr.com/posts/what-id-like-as-sre/</url></story><parent_chain><item><author>chrsig</author><text>&amp;gt; If you’re a Software Engineer&amp;#x2F;Developer, then consider that a service (at least, for me), is a piece of code running in a live production system, that YOU wrote, only YOU know how it works, thus YOU own.&lt;p&gt;I&amp;#x27;ve grown unfond of this attitude. I most certainly don&amp;#x27;t own it.  I have no IP rights to it at all.  We&amp;#x27;re both being paid to solve different facets of the same problem.  Coming at me  with &amp;quot;this is your problem&amp;quot; isn&amp;#x27;t going to foster a collaborative environment with me.  Which is much more pleasant than an adversarial environment.&lt;p&gt;Also:  I&amp;#x27;m not the only one that knows how it works, it&amp;#x27;s been peer reviewed in no small part to reduce my bus factor. All documentation requested is perfectly reasonable, and should be part of the organizations standard operating procedure.&lt;p&gt;If it&amp;#x27;s not part of the SOP, then no, you wont have those things.  You need to work at a cultural level to change that, and for that you&amp;#x27;re much better off making allies than anything else.  Make it clear how those things help you, and what you&amp;#x27;ll do to make the developers life easier when you don&amp;#x27;t need to worry about the basics.  If altruism fails you, you can usually count on people to act in their own best interests.</text></item></parent_chain><comment><author>hayst4ck</author><text>Ownership is important to be explicit about, less as a means of assigning blame, but more as a means of coordination and resource allocation.&lt;p&gt;The author is using ownership as a tool to avoid responsibility, and is thus creating an `us vs them` mindset rather than an `us vs the problem` mindset.&lt;p&gt;Having a strong definition of ownership (like committing your organizational structure to your monorepo as config file) is invaluable for building tooling.&lt;p&gt;If you have a strong definition of code ownership it allows for things like people less familiar with a particular piece of code being able to make changes with the approval of the owners, while simultaneously notifying them of the change.&lt;p&gt;Likewise, if you are working on a platform that multiple teams use, you can write tooling that automatically assigns bugs or tickets.&lt;p&gt;Ownership problems and &amp;quot;us vs them&amp;quot; is a clear sign of poor leadership. Most devs that experience it become cyncial or hostile without being able to understand that it is leadership that failed them.</text></comment>