引言
本期分享主题是跳出SRE来看SRE，本期分享内容为认识和理解SRE、可靠性方法，以及平台工程、可观测性和AIOps。
一、认识和理解SRE
（1）SRE是什么？解决什么问题？
● SRE最初是关注分布式业务服务运维可靠性的工程师
● SRE是一种运维视角的系统可靠性实践，也可以说发展成为了一种方法论
● SRE追求的是系统的可靠性，侧重于运维，和研发的追求敏捷是矛盾的
● 敏捷实践者的努力主要聚焦在改进软件的开发流程，对技术的健壮性则不是那么的重视
● SRE最大的贡献是关注研发和运维的关系，通过错误预算来协调开发和运维的协同
● 核心价值：让开发关注运维问题，让运维了解研发软件架构和逻辑
（2）为什么要跳出SRE?
● 不但要认识SRE的优势，更要理解SRE的不足，全面看待SRE
● 跳出SRE,才能全局认识SRE
● 软件问题的根因不仅限于技术健壮性，还源自于企业的组织和文化
● 错误预算和组织文化
● 在敏捷的语境中，技术的健壮性和流程维度是密不可分的。企业往往会忽视敏捷在架构，组织，和文化方面所需的前提条件，而直接将敏捷转型的焦点放在了流程维度。
（3）运维的敏捷才能真正带来研发的敏捷
● 如果我们每次在这些尝试中都不得不规划实现一个未来一两年或五年的笨重架构， 我们将会陷入麻烦。我们做不到敏捷。
● 敏捷部署、持续发布
● 弹性扩展、扩缩容
● 减少研发花费在服务、系统运维上的时间和精力
（4）SRE与DevOps
● 核心是协调研发和运维的利益冲突
● 区别与联系
● DevOps是方法论，SRE是一种实践，一种协调研发和运维协同关系来提升可靠性的实践
● SRE和传统运维的本质区别在于认知和思维，表现在工具和方法上
● DevOps落地是一套体系，SRE侧重于用软件工程的方法做运维，确保可靠性，没有从根本上解决研发和运维的关切
二、可靠性方法
（1）可靠性方法之一
● 稳定、不改变（不折腾）是可靠性保障的方法之一
● 运维人员最喜欢的方法
● 变化就意味着风险、甚至是不可控的风险
● 软件工程中，人是最大的不可控因素，最大变量
（2）可靠性方法之二
● 敏捷自恢复也是可靠性保障方法之一
● 需要基础设施保障
● 云原生的基本能力要求，但并不限于云原生
（3）可靠性方法之三
● 混沌工程，持续探索并消除系统中的不稳定因素
● 混沌工程的价值在于持续探索的知识库，这又涉及另一个概念，知识库和知识工程。
● 知识工程其实又是AIOps的基础
（4）可靠性方法之四
● 软件本身的可靠性
● 架构（软件架构和部署架构）
● 合理逻辑和异常处理
● 高可用和自治
● 故障恢复能力
● 依赖生态可靠性
● ……
三、平台工程、可观测性和AIOps
（1）平台工程
● DevOps已死？平台工程才是未来？
● 这本身就是个伪命题
● 没有经历过，很难真正懂
● DevOps需要从开发和运维的利益诉求矛盾入手解决问题
● 平台工程解决什么问题？
● 赋能
● 自服务敏捷基础设施
● 没有后顾之忧
（2）平台工程和DevOps
● 平台工程和DevOps并不矛盾，可以说是相辅相成的
● DevOps是方法论，协调的是生产关系；
● DevOps没做好，是因为不懂DevOps；
● 平台工程是基础，没有生产工具，没有新的生产力，先进的生产关系是无法适应的；
● 研发懂运维，减少系统bug，提升软件可靠性；运维懂研发，懂软件流程逻辑，有助于快速定位软件故障，提升可用性；
（3）再看SRE的价值是什么？
● 赋能
● 运维的同时提供自动化、自服务化的基础设施工具，实现平台工程的部分能力，也可以说是DevOps的部分能力
● 使运维敏捷化
● 通过“数字”来教育开发者，从源头提升可靠性
● 让开发人员不能无所顾忌，要考虑系统的可靠性措施和异常处理等
● 实践启发产生了一种新的方法论
（4）可观测有助于提升可靠性
● 可观测性是可见性的最好的诠释
● 监控和可观测，被采集和主动暴露
● 软件架构和设计意识的转变
（5）AIOps
● SRE希望通过软件工程实现自动化运维
● 但自动化远远不够，数字化时代有了新的要求
● 需要预测、预警
● 有监控数据、日志数据、资产数据、专家知识、AI算法工具等，为什么不做AIOPS?
（6）企业架构团队
● 理想情况下，团队应该有一个资深技术人员资源池，扮演了代理架构委员会的角色
● 顶层IT架构规划：技术架构、数据架构和应用架构规划
● SRE架构师是企业架构团队的一部分
四、互动答疑（Q& A）
汪照辉，某头部券商架构师，清华大学工程管理硕士（MEM）。
汪老师专注于容器云、微服务、DevOps、数据治理、中台架构、数字化转型等领域，对相关技术有深入的理解和见解。擅长于系统规划和设计，发表了众多文章探讨容器云平台、微服务、DevOps、数字化转型、数据治理、中台建设等内容。
Q1: 从金融行业的角度，目前您看到的DevOps和SRE的落地程度怎么样？如果说满分是五分，现在是做到了几分？
A1: 目前我觉得整体来说可能并不是特别理想。可能也就三分左右吧。
整个DevOps落地实施，包括做DevOps的厂商，其实很多人对这个词的一些理解我觉得都有一些偏颇，也可能从这个厂商自身产品角度来说，他们有自己的考虑。所以以落地的能力来说，DevOps目前可能侧重于研发，会更多一些研发效能，或者一些工具方面的支撑，一些指标等等方面的支撑。DevOps对运维侧的落地的能力就差很多了。那SRE可能从实用的角度增强运维侧方面能力。就目前来说，如果SRE和DevOps能够结合起来可能会更好一些。但是从DevOps本身概念来说，其实DevOps应该是包含运维侧能力的。
我觉得整个研发运维其实可以协作，然后大家比如通过一些方法，一些工具能够把大家的关切能够梳理好，能够协调好就可以。我觉得也没必要非要强调，就是说SRE的职责什么的不用非要非常明确，但需要关注彼此的关切。我觉得最好的话就是让大家能够就是平滑去合作。能够高效于推动这些工作去推进，就比较好。
Q2: DevOps实施是否存在一些速赢的方法或者策略？如果有的话能不能介绍一下？
A2: DevOps我不觉得有什么速赢的方法，我一直觉得是需要一步一步积累的。其实我觉得这些能力构建的话，很重要的话是企业自身能力的一个沉淀。你如果是通过厂商，比如说买一套产品和配套系统什么的，不见得适合自己。我们现在到数字化阶段，这些能力很多时候需要我们对自身数据的处理。有很多工具我们可以拿来用和借鉴，但最终合不合脚其实还要看自己的，还要看自身的能力，所以我觉得想速赢的话可能自身要具备相应的能力。这样会快一些，但是我觉得现在最缺的就是人才（具备这些能力的人才）。
Q3: 老师能不能总结下SRE能解决什么痛点？我们是很传统的金融技术系统。
A3: 我觉得最重要的就是刚才我们提到意识和方法。意识方法要改变,就是不管你多传统，如果意识方法不改变的话，就很难带来改变。首先意识方法改变之后呢，我们去通过工具，就是我们可以引入一些自动化的工具，引入一些相应的平台，推进我们能力建设。然后呢，然后有相应的基础之后，就可以跟这个研发端去做相应的一些协调。比如说我们具备了自动化的能力，自动化的运营能力和自动化的应用支撑能力，这样情况下我们才能跟研发端去讨论相互关切问题。因为我们自身不具备这些能力的话，即便跟他们讨论，人家也不会关心的。
Q4: 怎么看待运维的敏捷化？运维能够敏捷吗？现在有一些新的概念叫高速I T，high velocity提的比较多，您怎么看待运维的敏捷或者快？它的快跟研发的快是一回事吗？通过CI-CD能解决吗？
A4: 刚才我们也提到，运维的敏捷，才能真正支撑软研发的敏捷，运维敏捷肯定是可以实现的。我对高速it这块这个概念并不是特别清楚，我从概念上来说可能是类似的。因为最终的话，其实也是要实现整个it能力的敏捷化。所以说整个运维的敏捷是一个基础。包括我们现在要做这种平台工程。为什么说这个DevOps进行不下去呢？因为我们对DevOps研发侧的支撑能力达不到，所以说DevOps落地的时候就落地不下去。这是为什么我说我们运维侧的敏捷还没有做到，需要我们先去实现运维侧敏捷。我在18年19年上容器云平台的时候就提出三视角四层次一闭环的架构思路，我们要先去建设对应用的支撑能力建设完善。然后才去做服务的研发。我们要支撑这些微服务的话，首先需要支撑弹性伸缩，支撑相应的环境迁移等等的这些能力，也就是整个运维的环境，你得具备相应能力，才能去支撑比如这些微服务。微服务量一旦上来之后，可比我们原来那几个系统复杂多了。各个调用关系，如果你没有这个能力支撑的话，那会累死的。
Q5: 平台工程现在金融行业是否成为一种新的趋势？您有没有接触到或者看到一些成功案例？
A5: 的确是一个趋势。因为整个数字化发展的话要求你要具备相应能力。因为我们原来信息化是单体系统建设，就是一个竖井，他没有统一的基础设施，没有统一的底座。但是数字化不一样，数字化要求一个全局的能力，就是说你需要各个部门，各个系统，各个体系相互之间的协作。我们现在为什么去推平台工程，或者说我们前几年推的云计算，其实通过云计算，然后实现平台工程的部分基础设施能力。其实这些都是不同的方法，或者说是殊途同归的理念。所以现在这些阶段的话是需要有一个统一的底座来提升敏捷的能力。这样的话就是说，你不管是什么样的一个应用。其实和原来有些思想也有点儿类似，就是说我们有统一的底座，然后有可复用的服务，然后前台各种应用快速地去编排，快速去实现部署和发布。这些方法其实都是相通的。
视频回看地址：
1、扫码B站二维码
2、关注微信视频号“SRE专委会 ”
