SRE通常负责多种服务或应用，与可能更专注于少数应用程序的开发人员不同。对大型代码库的深入了解可能是一项艰巨的任务，尤其是如果重点是通过中断驱动的SRE工作性质来分散的。
要在编码中表现出色并能够与开发人员在编程方面的专业水平相匹配，花费更多的时间进行连续编码，这可能是不可能的。纯粹的开发角色似乎拥有更好的职业道路。
此外，关于SRE应该将大部分时间都花在编码上而不是在操作上的说法似乎与现实有些脱节。并非所有操作都是邪恶的，也不是所有代码都是天使。就像有人说的那样，“最好的代码是从未编写的代码”。有效且可靠地运行操作是SRE的一个重要目标，而编码不是实现此目标的唯一手段，但有助于实现该目标。
因此，对于SRE而言，合理的期望是什么？编码？拥有两个SRE的干部是否可行-以开发为中心的“ SWE SRE”和以运营为中心的或“ Operation SRE”？他们可以成为同一团队的一部分吗？在这两个角色之间轮换人是否可行？
我希望这个问题不要被视为基于观点的问题。
#1 楼
如果工程师是一名出色的开发人员，为什么要选择SRE角色？这里是成为一名开发人员的讽刺意味：在Sprint中工作，获得所有BA工作的入场券，花费3-解决该问题4天，将其标记为已完成，获得下一张票，依此类推。这是一个非常无聊的工作环境。是的，这里有更好的工作环境，并不是所有的开发角色都会陷入混乱的平庸陷阱，但它经常发生。当然，尚未将所有的工程挑战都安排到单独的角色中，因此它允许某些类型的开发人员在快速的环境中使用多种技能来工作，从而享有更多自由。
对于SRE来说，对编码的合理期望是什么？
他们是您在开发团队中想要的程序员。对于不合格的开发人员来说，SRE不是一个地方。 SRE的发展挑战与开发领域的挑战一样大，但出错的空间更少。
拥有两个SRE的干部是切实可行的-以开发为中心的“ SWE SRE”和以业务为中心的SRE或“运营SRE”？
不是。要进入SRE，您必须了解Dev和Ops。如果不是这种情况，则说明您没有在做SRE，而是在做其他事情。这并不意味着它是错误的，也不是对您不起作用-可能只是您的环境所需要的，并且拥有让它起作用的人员。如果他们为团队带来了开发人员无法覆盖的重要技能（例如，底层网络或linux内核知识），那么有可能不是团队中真正的开发人员的专家。很少。
他们可以成为同一个团队的一部分吗？
您可以将Dev和Ops置于同一团队中。这将带来一些有趣的管理挑战。请以更看板的方式管理团队，ops在sprint中不起作用
在这两个角色之间轮换人员是否可行？
大多数开发人员都可以从DevOps领域获益。但是，如果这是一个真实的操作环境，则该时间段最多可能为2-3天。不确定大多数操作人员能否以开发人员的身份提供有意义的帮助，但他们通常会成为优秀的测试人员。大多数操作人员都不想长期担任测试角色。
#2 楼
我认为，如果SRE将“大量时间花在操作任务上”，那么他们就失去了通过代码来改善自身状况的机会。并非所有代码都得到管理，但DevOps和SRE模型的驱动原则之一就是像软件问题一样处理操作问题。关于轮换角色和SRE团队，您需要做的是为您的组织创造价值。我认为没有一个正确的答案；我确实认为，目标是尽可能减少手动干预，并尽一切可能识别并解决可靠性问题。无论您是作为传统开发人员还是通过零代码方法实现此目标，都没有关系。
#3 楼
那么，编码方面对SRE的合理期望是什么？拥有两个SRE的干部是否可行-以开发为中心的“ SWE SRE”和以运营为中心的或“ Operation SRE”？他们可以成为同一团队的一部分吗？在这两个角色之间轮换人是否可行？
class SRE implements DevOps正如他们所说。还有其他模型。如果您将SRE归类为负责运营的软件工程师，并被要求提供面向软件工程的解决方案，那么您将希望雇用具有运营知识的SWE，并请他们建立一支团队来灌输该知识。 。它们应该首先进行编码，但是要针对系统和基础结构。 SRE是处理高度歧义和无知的通才的地方。总是会有一些新事物。
具体来说：SRE应该是那种看着Kubernetes并乐于直接针对API编写代码的人，而不是通过YAML作为接口进行路由。
评论
正如您提到的，在sprint上运行ops太糟糕了。但是我不禁要强调这一点。
–小鸡
20年6月23日在18:07