对软件进行生命周期的整体性关注，这样做能够帮助Google成功地构建、部署、监控和运维世界上现存最大的软件系统。提高系统部署规模、改进可靠性和资源利用效率方面的指导思想与具体实践。

Google SRE代表了对行业现存管理大型复杂服务的最佳实践的一个重要突破，由于Google目前的全球领先地位，SRE模式可以提供业内广大企业深度模仿或借鉴。

SRE介绍了通过自动化、工作方法和组织重组的混合措施来提高服务可靠性的一系列实践。SRE Foundation是为那些关注大规模服务可用性的学员量身定制的课程。SRE（Site Reliability Engineering）Foundation℠课程介绍了使组织能够可靠和经济地扩展关键服务的原则和实践。引入站点可靠性维度需要组织重新调整、对软件工程和自动化的关注以及采用一系列新的工作模式。

该课程强调了SRE的发展及其未来的方向，并为参与者提供了实践、方法和工具，让整个组织的人员都参与到可靠性和稳定性中，通过使用真实场景和案例故事证明了这一点。课程结束后，学员将有切实的收获，例如理解、设置和跟踪服务水平目标（SLO）。

----------------

ITIL4变重了，可能很难一下子找出对自己有用的东西，经理们觉得自己整天坐在火山口，单单使用ITIL来管理，对系统的稳定性没有信心，需要他山之石作为抓手来更聚焦于稳定性、可靠性、服务质量。作为一个套路，能指导具体落实和舒缓情绪。

DevOps推广这么久，发现DevOps比ITIL还要繁杂，全生命周期的框架；ITIL流程化实施会越来越重，管理消耗非常大，应该轻量化。但是，没有指引给出如何从DevOps过渡到ITSM；仅从运维侧推动DevOps往往做成了容器平台，没有拿到很实质的东西跟研发团队对接，也无共同语言来一起实现核心的目标，难以真正拥抱DevOps；

招募有开发特质的人，用开发解决运维的问题，他不是在自己编码就是在帮助别人编码，任何运维的问题其实都是产品的问题，均考虑用代码来解决。现在我们运维遇到的问题其实跟当年谷歌遇到的问题一样，需要成立SRE团队，采用SRE实践，k8s其实比较容易实现金丝雀发布。

站点可靠性工程是一门工程学科，致力于帮助组织在其系统、服务和产品中持续地实现是适当的可靠性水平。SRE的流程其实是一种运作模式，一个可靠的运维大规模系统的框架（套路），就是让软件工程师来设计运维功能所发生的一切事情，SRE在运维层次上负责生产系统的运行，它是构建和运行高可靠性系统的、普遍适用的最佳方式。

若面对大规模集群运维，SRE工作量过载是需要警惕的。建立独立的SRE团队，如同当初导入ITIL建立的服务台组织。SRE独立出来后，去粘合研发和运维，有一个参与过程，要嵌入要当前研发+运维的链条中，因此，首先要打破部门墙，包括SRE指导使用GCP的外部用户使用SRE方法。

新公司第一天就应该实施SRE，第一天就要关注业务的稳定性，稳定性是重要的功能，放入开发计划中。入手点是实施SLO，不断优化。如果你的知识背景更偏向研发，建议你入手DevOps，如果偏向运维，建议先入手SRE。DevOps的面更广。

任何规模的、想提高站点可靠性的组织都可以实施SRE。如果不做SRE，你可能仅仅通过负面的次数（用户没有多少投诉）评价你的服务质量，SRE可以主动、过程化、正向（SLO达标、错误预算剩余）管理你的服务稳定性和质量。

需要从开发那边知道系统到底对稳定性、延迟还是错误敏感，有无代码级容错，然后设置监控策略。开发人员其实也不理解他的程序是如何运行在一个复杂的运行环境中的，有怎样的复杂的网络结构，有哪些稳定性挑战。所以需要与开发人员一起来设置监控策略。例如500内部错误，可能代码问题，可能系统接口问题，不能单纯踢给某一方，所以需要SRE来打通。

要在做这5件事，才能叫做SRE。SLO定义了系统应当具有的正常表现，专注于跟踪客户（人/机）的使用体验。传统监控，问题在于没法了解到用户真正的体验。用户体验不好，并不会来投诉，而是直接使用竞争对手的产品。也有可能你的客户是另一个系统的api。若SLO不达标，系统不稳定了，再上线新功能只能让业务的收益下降。应聚焦在SLI上理解客户体验。

SLI：除了功能代码外，客户眼中的一切。包括：总体稳定性、可用性、延迟、流量、覆盖率、正确率、质量、新鲜度、持久性。SLI是一个监控的对象，SLI的指标采集可能需要在传统监控的基础上开发才能获得。提高被监控的对象的可观测性，如果它没有相关指标，则需要让它提供，并能对观测到的数据进行剖析和依赖分析。若没达到可观测性级别，SRE不接手。

SLO落地的成本可能主要还是跟研发和客户达成SLI的一致认可，工具成本不会是首先要投入的。

对软件进行生命周期的整体性关注，这样做能够帮助Google成功地构建、部署、监控和运维世界上现存最大的软件系统。提高系统部署规模、改进可靠性和资源利用效率方面的指导思想与具体实践。

Google SRE代表了对行业现存管理大型复杂服务的最佳实践的一个重要突破，由于Google目前的全球领先地位，SRE模式可以提供业内广大企业深度模仿或借鉴。

SRE介绍了通过自动化、工作方法和组织重组的混合措施来提高服务可靠性的一系列实践。SRE Foundation是为那些关注大规模服务可用性的学员量身定制的课程。SRE（Site Reliability Engineering）Foundation℠课程介绍了使组织能够可靠和经济地扩展关键服务的原则和实践。引入站点可靠性维度需要组织重新调整、对软件工程和自动化的关注以及采用一系列新的工作模式。

该课程强调了SRE的发展及其未来的方向，并为参与者提供了实践、方法和工具，让整个组织的人员都参与到可靠性和稳定性中，通过使用真实场景和案例故事证明了这一点。课程结束后，学员将有切实的收获，例如理解、设置和跟踪服务水平目标（SLO）。

----------------

ITIL4变重了，可能很难一下子找出对自己有用的东西，经理们觉得自己整天坐在火山口，单单使用ITIL来管理，对系统的稳定性没有信心，需要他山之石作为抓手来更聚焦于稳定性、可靠性、服务质量。作为一个套路，能指导具体落实和舒缓情绪。

DevOps推广这么久，发现DevOps比ITIL还要繁杂，全生命周期的框架；ITIL流程化实施会越来越重，管理消耗非常大，应该轻量化。但是，没有指引给出如何从DevOps过渡到ITSM；仅从运维侧推动DevOps往往做成了容器平台，没有拿到很实质的东西跟研发团队对接，也无共同语言来一起实现核心的目标，难以真正拥抱DevOps；

招募有开发特质的人，用开发解决运维的问题，他不是在自己编码就是在帮助别人编码，任何运维的问题其实都是产品的问题，均考虑用代码来解决。现在我们运维遇到的问题其实跟当年谷歌遇到的问题一样，需要成立SRE团队，采用SRE实践，k8s其实比较容易实现金丝雀发布。

站点可靠性工程是一门工程学科，致力于帮助组织在其系统、服务和产品中持续地实现是适当的可靠性水平。SRE的流程其实是一种运作模式，一个可靠的运维大规模系统的框架（套路），就是让软件工程师来设计运维功能所发生的一切事情，SRE在运维层次上负责生产系统的运行，它是构建和运行高可靠性系统的、普遍适用的最佳方式。

若面对大规模集群运维，SRE工作量过载是需要警惕的。建立独立的SRE团队，如同当初导入ITIL建立的服务台组织。SRE独立出来后，去粘合研发和运维，有一个参与过程，要嵌入要当前研发+运维的链条中，因此，首先要打破部门墙，包括SRE指导使用GCP的外部用户使用SRE方法。

新公司第一天就应该实施SRE，第一天就要关注业务的稳定性，稳定性是重要的功能，放入开发计划中。入手点是实施SLO，不断优化。如果你的知识背景更偏向研发，建议你入手DevOps，如果偏向运维，建议先入手SRE。DevOps的面更广。

任何规模的、想提高站点可靠性的组织都可以实施SRE。如果不做SRE，你可能仅仅通过负面的次数（用户没有多少投诉）评价你的服务质量，SRE可以主动、过程化、正向（SLO达标、错误预算剩余）管理你的服务稳定性和质量。

需要从开发那边知道系统到底对稳定性、延迟还是错误敏感，有无代码级容错，然后设置监控策略。开发人员其实也不理解他的程序是如何运行在一个复杂的运行环境中的，有怎样的复杂的网络结构，有哪些稳定性挑战。所以需要与开发人员一起来设置监控策略。例如500内部错误，可能代码问题，可能系统接口问题，不能单纯踢给某一方，所以需要SRE来打通。

要在做这5件事，才能叫做SRE。SLO定义了系统应当具有的正常表现，专注于跟踪客户（人/机）的使用体验。传统监控，问题在于没法了解到用户真正的体验。用户体验不好，并不会来投诉，而是直接使用竞争对手的产品。也有可能你的客户是另一个系统的api。若SLO不达标，系统不稳定了，再上线新功能只能让业务的收益下降。应聚焦在SLI上理解客户体验。

SLI：除了功能代码外，客户眼中的一切。包括：总体稳定性、可用性、延迟、流量、覆盖率、正确率、质量、新鲜度、持久性。SLI是一个监控的对象，SLI的指标采集可能需要在传统监控的基础上开发才能获得。提高被监控的对象的可观测性，如果它没有相关指标，则需要让它提供，并能对观测到的数据进行剖析和依赖分析。若没达到可观测性级别，SRE不接手。

SLO落地的成本可能主要还是跟研发和客户达成SLI的一致认可，工具成本不会是首先要投入的。