1，脱离职责的流程是没有意义的
软件架构与组织架构相匹配，不仅仅体现在功能边界，更体现在职责划分。
清晰的职责边界，才能构筑良好的团队协作与发展。每个团队、每个人都应该明白自己的目标，什么事情应该承担，什么事情应该回避，将时间和精力投入到对主要目标有增益的事情，不能陷于琐屑。如此，团队中的成员才不会那么累，有可能沉淀一些领域知识，进行有深度的思考。
清晰的职责边界很难。这并不是一个管理上的问题，而是一个执行的问题。一个流程可能会涉及到很多的人，但这些人的业务水平在各自的领域并不一定在同一个档次。通常，我们在大公司能看到清晰的边界，很重要的一点是他们招聘了一群牛人。而在中小公司，牛人的比例很少，一旦某个环节出现了短板，就需要其他人补充。这样就破坏了职责的边界，进入了无流程的状态。
职责边界的破坏会让团队总是处于救火的状态。每次出了问题，团队中的人不去关注自己的职责范围，而依赖于少数的消防员灭火。因为这些消防员精通整个流程，处理问题又快又好，越用越顺手。但这并不是一个可持续的方式，随着业务的增长，问题会越来越多，但消防员也能同比例增长吗？是否在不同的业务阶段，我们依然需要不同比例的消防员，这是一个值得继续思考的问题。
下面主要讨论的是 DevOps 和 SRE 的两种协作流程。
2，DevOps 向右
如下图，从工作流看，DevOps 是向右的。
在流水线上，开发人员借助于平台，依次完成需求管理、编码、编译、部署等环节。这里简化了整个流程，也没有形成经典环路。
DevOps 强调的是端到端的价值交付，一端指的是需求，另一端指的是用户。从需求到交付给用户使用，才算一次完整的 DevOps 迭代。
DevOps 并没有强调对交付价值的度量和管理，这与 SRE 有着显著差异。
虽然交付是由研发自助完成，但是运维和运维开发人员会对其进行支撑。运维开发人员主要是提供自动化的能力，降低交付的门槛，提高交付的效率。而运维人员主要是以专家的形式，提供领域上的指导，设计整个流程。
3. SRE 向左
如下图，从工作流看，SRE 是向左的。
如果说 DevOps 的工作方式类似 KPI，那么 SRE 的工作方式更像 OKR。DevOps 从需求出发，制定良好规划，稳步推进，一个流程一个流程转交，最终上线交付给用户。但 SRE 不一样，SRE 是先有目标，再来考虑应该做出哪些努力，从哪些方面入手以达成目标。
也有一种说法，SRE 是 DevOps 的一种最佳实践。我认为这是一种概念上的泛化而已，因为他们讨论的对象重合度太高。快速发展的概念，总是会有各种解读和扩展。但这里，我们可以明显看到 DevOps 和 SRE 在工作流上的一个差异。
我们一起来看看 SRE 工作流。首先是由运维人员或领域人士制定 SLI 核心指标。制定指标的目的是为了可以度量。只有业务指标可以度量，业务指标才能够得到管理。接着，根据管理者的 OKR 制定相关的 SLO 指标目标，应该达到多少。然后，研发人员配合 SLO 目标进行业务的改进。
SRE 工作流之后，需要再走一次 DevOps 的流水线，才能发布上线。
4. 总结
本文主要讨论了职责划分对流程的重要性和 DevOps、SRE 两种工作流。这里并没有对立 DevOps 、SRE 两种工作流。实际上，SRE 工作流也需要 DevOps 工作流的支撑，他们并不是孤立的存在。
另一方面，适用场景、业务阶段也很重要。直接指定一个新业务的 SLO 并不合适，因为 SLI 并不好制定和度量，此时应该采用 DevOps 工作流，稳步迭代上线。
