在开发过程中，Google还遇到了运维人员与开发人员之间的冲突问题。开发人员专注于创建新功能并将其投入生产，而操作员和操作员则试图确保生产稳定性。为了缓解两个部门之间的矛盾，Google工程部副总裁Ben Treynor考虑了一种新的解决方案。具有研发背景的招聘和内部转移软件工程师不再独立于系统管理员团队或运维团队，而是独立设计和创建软件系统来维护系统操作并替换传统模型中的手动操作以使解决方案自动化。
站点可靠性工程（SRE）职位应运而生。 SRE工程师负责生产环境的稳定性，但同时致力于新功能和运营改进。 Google认为，SRE团队应由50％的软件工程师和50％的系统管理员组成。软件工程师使用软件来实现历史上已解决的问题，并轻松与开发人员集成以促进代码质量改进和自动化测试。该小组的目标是帮助Google的生产环境服务运行起来更加稳定，强大和可靠。
DevOps和SRE之间的区别
SRE和DevOps是敌人还是朋友？谁将领导未来？
SRE VS DevOps
DevOps的概念是将开发，运营和维护结合起来，定义系统的行为，并了解需要做些什么来弥合两个团队之间的“鸿沟”。这个概念背后的理论是关于如何使两个团队团结在一起的。但是SRE谈到了“怎么做”。通过使用正确的工作方法，工具等，它将理论部分扩展到有效的工作流程。它还涉及在每个人之间分担责任，并赋予每个人相同的目标和愿景。
我们通过DevOps的五项原则比较DevOps和SRE之间的区别：
减少部门之间的孤岛
大型企业通常具有更复杂的组织结构。许多团队独立工作。他们发布自己的产品，并且不与公司的其他部门联系。因此，各部门知之甚少，无法整体控制。全球。
DevOps的工作是缩小这些差距，并确保团队中不存在与公司其他部门不匹配的团队。他们最大程度地减少了团队，并将其与具有共同愿景的团队联系在一起。
SRE不再关注公司有多少差距，而是如何让所有人参与讨论。这可以通过在整个公司（例如公司的中期）使用相同的工具和技术来完成。
故障验收
SRE和DevOps是敌人还是朋友？谁将领导未来？
SRE故障标识符尽管DevOps的概念在故障发生之前已经得到处理和响应，但现实在不断变化，我们无法完全避免故障。 DevOps通过将失败视为不可避免的事件，并通过事后总结经验来帮助团队学习和成长来接受这一点。
在SRE看来，虽然失败是不可避免的，但可以通过制定公式来平衡事故与新版本之间的关系来实现。换句话说，SRE希望确保没有太多的失败或失败，即使这些失败的经历是我们学习成长的方式。
SRE通过两个关键标识符来衡量此公式：服务水平指示器（SLI）和服务水平目标（SLO）。 SLI是随时间变化的指示器，例如请求等待时间，每秒请求的吞吐量或每个请求的失败。这些通常随时间汇总，然后转换为受阈值限制的比率，平均值或百分位数。 SLO是从此阈值，百分比或数字得出的，它表示SLI在一段时间（例如“最近30天”或“本季度”）内累积SLI的成功目标。
在Google，请区分SLO和服务水平协议（SLA），这是服务提供商的可靠性保证。 SLA中的可用性SLO通常比内部可用性SLO宽松。
实施渐进式改革
公司希望经常发布产品，不断更新产品，并使团队成员专注于新技术。
DevOps和SRE均以该目标为目标，但是是以逐步方式进行处理的。 DevOps和SRE都希望快速增长，而Google指出SRE强调这样做的同时要降低故障成本。
工具与自动化
不同的职责导致两个职位的工作分配不同，导致工具略有不同。
DevOps的工作主要是为了开发链接服务。 DevOps团队通常提供一系列工具链，包括：开发工具，版本管理工具，CI连续交付工具，CD连续发布工具，警报工具和故障处理。
SRE团队关注与变更，故障，性能和容量相关的问题。它涉及特定的服务。输出工具链将包括：容量测量工具，日志记录工具，Trac呼叫链接跟踪工具，指标性能指标，监控警报工具等。
但是目标是相同的，希望通过消除手动操作为开发人员和操作员提供价值。
结果测量
DevOps和SRE团队都需要确保他们朝着正确的方向发展。 DevOps指标往往是自动化的，项目交付速度也很高，而SRE指标更偏向于可靠性和稳定性。
SRE关键字是“高可伸缩性”和“高可用性”。高可伸缩性意味着当服务用户数量增加时，在不更改系统结构的情况下就无法调整应用程序系统及其支持的服务（服务器资源，网络系统，数据库资源），并且不会提高计算机本身的性能。高可用性意味着当应用程序体系结构的任何部分（例如应用程序服务，网关，数据库等）不可用时，可以在短时间内恢复整个系统并为其提供服务。DevOps和SRE关系
SRE和DevOps是敌人还是朋友？谁将领导未来？
DevOps和SRE都接受更改是改进所必需的想法。
合作是DevOps工作的核心。有效的共享和协作对于SRE的工作必不可少。像DevOps一样，SRE也具有在组织之间共享的能力，从而更容易打破团队之间的鸿沟。
当生产服务器发生故障时，SRE和DevOps都应执行自己的事故重新发现，以消除毫无意义的争端，坩埚和知识沉淀。
使用正确的工具很重要，这些工具在某种程度上决定了工作的效率。
结果指标是DevOps和SRE如何工作的关键。对于SRE，SLO（服务质量目标）确定是否改善和优化服务。当然，如果没有产品，基础架构/SRE和业务之间的指标和跨团队协作，就不可能有SLO。对于DevOps，通常使用所得的度量行为来了解过程的输出是什么，反馈周期的持续时间是什么，等等。
DevOps或SRE是一种整体行为，其愿景是以特定的方式合作，以使整个团队运作更好。
DevOps和SRE在日常工作中有很大的重叠。正如托尔斯泰所说：有效的操作方法是相似的，而失败方法有其自身的失败。
中文
电话咨询
微信咨询
公众号
