问题描述
SRE（Site Reliability Engineer）和编码是一个有争议的话题。在大多数情况下，SRE们花费大量时间处理运维任务，即使他们注重效率和自动化。这意味着SRE们花在编码上的时间并不像全职开发人员那样多，这在编程严谨性方面使他们处于非常不利的位置。
此外，与开发人员可能更专注于少量应用程序不同，SRE们通常负责多个服务或应用程序。对于SRE工作的中断驱动性质，使得深入了解大型代码库可能是一项艰巨的任务。
要在编码方面非常出色并能够与开发人员的编程水平相匹配，SRE们需要持续花费更多时间进行编码，但这可能是不可能的。
此外，问题出现了 – 如果一个工程师是一个优秀的开发人员，为什么他或她会选择SRE角色？纯开发角色似乎有更好的职业发展道路。
此外，认为SRE们应该花费大部分时间编码而不是进行运维似乎有些脱离实际。并非所有运维都是邪恶的，也并非所有代码都是天使。正如有人所说，“最好的代码是从未编写过的代码”。高效可靠地运行运维是SRE们的重要目标，编码可以帮助实现这一目标，但并不是唯一的手段。
那么，对于SRE在编码方面有什么合理的期望？在编码方面有两个不同的SRE类别 – 以开发为重点的”SWE SREs”和以运维为重点的”Operation SREs” – 是否可行？他们可以成为同一个团队的一部分吗？在这两个角色之间轮换人员是否可行？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
如果一个工程师是一个优秀的开发人员，为什么他或她会选择SRE角色？这是一个常见的问题。开发人员的工作环境通常是按照Sprint进行工作，拿到一个已经完成了所有BA工作的任务，花费3-4天解决这个问题，标记为完成，然后拿到下一个任务，如此循环。这是一个非常无聊的工作环境。是的，有更好的工作环境，不是所有的开发角色都会陷入Scrum的平庸陷阱，但这种情况经常发生。
DevOps还不是一个被“解决”的问题。它还没有将所有的工程挑战管理为单独的角色，因此它允许某种类型的开发人员在快节奏的环境中使用多种技能，获得更多的自由。这并不适合胆小的人。
那么，对于SRE在编码方面有什么合理的期望？他们应该是你希望在开发团队中的程序员。SRE不是一个低水平开发人员的地方。SRE的开发挑战与开发空间中的挑战一样大，但错误的空间较小。
方案2
在SRE团队内部进行角色轮换是可行的。大多数开发人员从DevOps的角度受益。然而，如果是真正的运维环境，那么这个时间段可能只有2-3天。不确定大多数运维人员是否能够作为开发人员提供有意义的帮助，但他们通常会成为一个很好的测试人员。大多数运维人员不会想长时间担任测试角色。
方案3
SRE们花费大量时间处理运维任务，这意味着他们错过了通过编码改善自己状况的机会。并非所有的代码都是被管理的，但DevOps和SRE模型的主要原则之一是将运维问题视为软件问题来解决。
至于在SRE团队内部进行角色轮换，你需要尽力提供组织的价值。我认为没有单一的正确答案；我认为目标是尽量减少手动干预，并尽一切可能识别和解决可靠性问题。无论是传统的开发人员还是零代码方法，都可以实现这一目标。
方案4
如果将SRE分类为“负责运维并要求提供软件工程导向解决方案的软件工程师”，那么你将希望雇佣具有运维知识的SWE，并要求他们建立一个团队来传授这些知识。他们应该首先进行编码，但以系统和基础设施为导向。SRE是一个适合在高度模糊和无知环境中应对的通才角色；总是有新的东西要学。
具体来说：SRE应该是那种看到Kubernetes并愿意直接针对API编写代码的人，而不是通过YAML作为接口进行路由。
方案5
在大规模中获得既懂运维又懂软件工程的软件工程师是非常罕见的。
以上是对于SRE在编码方面的合理期望的解决方案。在编码方面，SRE们应该是你希望在开发团队中的程序员。在SRE团队内部进行角色轮换是可行的，但需要根据实际情况进行调整。
以上是对于SRE在编码方面的合理期望的解决方案。