前言
Site Reliability Engineering (SRE) 和 DevOps 是目前相当热门的开发与运维文化，有着很高的相似程度。SRE是什么?它与DevOps有什么关系?本文将对两者之间的异同点进行简单的讨论。
SRE产生背景
Google公司在发展过程中，同样也遇到了运维人员与开发人员目标矛盾的问题，开发人员专注于创建新功能并推向生产，运维人员却试图保证生产稳定性。为了缓解这两个部门的矛盾，Google的一位工程副总裁Ben Treynor考虑出了一种新的解决方案。招募及内部转岗具有研发背景的软件工程师后不再独立属于系统管理员团队或者ops团队，而是独立设计创造软件系统来维护系统运行以及替代传统模型中的人工操作，实现解决方案自动化。
站点可靠性工程(SRE)岗位随即应运而生。SRE工程师负责生产环境的稳定性，但同时又致力于新功能和运维改进。Google认为SRE团队应由50%的软件工程师和50%的系统管理员组成。软件工程师通过软件来实现历史上手工解决的问题，并且与开发人员轻松集成，促进代码质量改进和自动化测试等。团队目的是帮助Google生产环境服务运行更稳定、健壮、可靠。
DevOps和SRE区别
SREs VS DevOps
DevOps的概念就是将开发与运维结合起来，定义系统的行为，并了解需要做些什么来弥补两个团队之间的“鸿沟”。这个概念背后的理论是关于使两个团队合而为一需要做些什么。但SRE却谈到了"如何"做到。它是通过使用正确的工作方法，工具等将理论部分扩展到有效的工作流程。这还涉及到在每个人之间分担责任，并使每个人都具有相同的目标和愿景。
我们通过DevOps的5个原则来对比下DevOps和SRE的区别：
减少部门间的孤岛
大型企业中通常都会有比较复杂的组织架构，很多团队之间都是独立工作，各自发布各自的产品，并没有与公司其他部门沟通交流，因此，部门之间了解不够，不能从整体上把控全局。
DevOps的工作是减少这些鸿沟，并确保团队中不存在与公司其他部门不符的团队。他们以共同的愿景将团队最小化并桥接到一个小组中。
SRE不再关注公司中有多少鸿沟，而是在谈论如何让所有人参与讨论。这是通过使用整个公司相同的工具和技术来完成的，例如公司中台。
故障接受程度
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团队则关注更为关注变更、故障、性能、容量相关问题，会涉及具体业务，产出工具链会有：容量测量工具、Logging 日志工具、Tracing 调用链路跟踪工具、Metrics 性能度量工具、监控报警工具等。
但是目的是一样的，都是希望通过消除手动操作来为开发人员和运维人员提供价值。
结果度量
DevOps和SRE团队都需要确保他们朝着正确的方向发展，DevOps度量结果偏向自动化实现程度及项目交付的速度，SRE度量结果更加偏向于可靠性与稳定性。
SRE关键词是「高扩展性」「高可用性」。高扩展性是指当服务用户数量暴增时，应用系统以及支撑其服务(服务器资源、网络系统、数据库资源)可以在不调整系统结构，不强化机器本身性能 ，仅仅增加实例数量方式进行扩容。高可用性是指，应用架构中任何环节出现不可用时，比如应用服务、网关、数据库 等系统挂掉，整个系统可以在可短时间内恢复并重新提供服务。
DevOps和SRE关系
DevOps和SRE都接受一种理念，即为了改进，变更是必要的。
合作是DevOps工作的核心，有效共享和合作是SRE发挥作用的必要条件。与DevOps一样，SRE也具有跨组织共享的强大价值，这样更容易打破团队之间的鸿沟。
生产服务器故障发生时，SRE和DevOps都应该进行各自的事故复盘，目的为了消除无意义的争论与甩锅以及知识沉淀。
使用正确的工具至关重要，工具在一定程度上决定了工作效率。
结果度量是DevOps和SRE如何工作的关键。对于SRE, SLOs (服务质量目标) 决定着是否改善和优化服务。当然，如果没有度量以及在产品、基础设施/SRE和业务之间的跨团队合作，就不可能有SLOs。对于DevOps，结果度量行为通常用于理解流程的输出是什么，反馈周期的持续时间是什么等等。
DevOps或SRE是一种整体行为，愿景就是用一种特定的工作方式共同协作，促使整个团队运营的更好。
DevOps和SRE在其日常工作中存在非常大的重叠。正如托尔斯泰说过的：有效的操作方法都是相似的，而失败的方法都有各自的失败之处。
结论
在IT运维整体领域的许多方面，虽然两者多多少少有些不同，但实际DevOps和SRE在实践和理念上都非常接近。两者都有助于合并开发人员和运维人员，同时承担相似的责任，并专注于实现自动化和可靠性。实施任何一个都是一个较长的过程，而不是一个快速解决方案。DevOps关注的范围更广，因此很难将每一步都规范成一个具体的流程，但正是因为广泛的关注，前期遇到的阻力可能会跟小。SRE将大部分时间花费在技术和流程方面的职责上，与其他团队合作，提供适当的监控、事件响应和管理，共同实现可靠性的目标。
归根到底，无论是DevOps还是SRE，都面临着同样的目标与愿景：让生产环境变得更好---不管被称为什么!
