《SRE究竟能解决什么核心问题.docx》由会员分享，可在线阅读，更多相关《SRE究竟能解决什么核心问题.docx（4页珍藏版）》请在第壹文秘上搜索。
1、SRE既做研发也做运维，并且要求研发的时间不低于50%,但SRE是偏运维的，包括SRE研发的大部分工作也是和运维相关的.这也让我有了个疑问，SRE解决的核心问题是什么？直观地来看，SRE要解决的是系统运行的可靠性问飕，特别提倡使用软件工程的方式来消除手工运维的问题，但似乎又不仅仅是这样.软件系统可靠性跟众多的因素相关，比如说软件架构、代码质量、逻辑处理、部若架构、部署位置、使用组件、调用他路、网络、数据量.配置参数、安全机制、基础软硬件等，任何一个点的异甫都可能会导致软件系统异甫.因此SRE不但要懂软件研发，还要从事软件研发，消除软件运行过程中存在的不稳定因素.通过持续完善运维工具、可赤性组件
2、等提升运行系统的可靠性。另外,从SRE职责来看，通常包含可用性改进、延迟优化、性能优化、效率优化、变更管理、监控.紧急事务处理、容量规划与管理等。很多看似运维的工作都跟研发密切相关，所以，SRE工程师要做一部分研发工作，甚至一部分产品的研发工作.运营运维反饰应用运荏SRE是偏运维的，那么除了研发，SRE和传统运维有什么本质的区别？我曾经从分层角度讨论过，运维的工作从层次上可以划分为业务应用系统运维、基础平台运维和基础设施资源运维（图1）.业务运营人员应刖运维人员平台运维人员资源运俳人员图1运堆层次业务应用系统包含交易、CRM、财务、人力等业务系统及业务相关的管理系统等；基础平台包含如数据库、中
3、间件、云平台、数据和大数据平台、AI平台等在内的工具平台，用于支建赋能业务；基础设施资源则包含数据中心机房的存储、服务器、网络设备、安全设备、机房设备等.传统运维人员基本上承担了所有这些运维工作，分组分团队或分部门维护着不同的内容.随着系统和设备的增多，运维人员数最也持续膨胀.SRE需要解决的一个很由要问题是:不随着系统和设备的线性增长而线性增加运维人员。比如说，10个系统最初可能10个人来运维，用SRE方法论，当系统增加到100个时，可能还是10个人来运维，这才是SRE的价值.这么多的工作内容如何处理？当然是用自动化的工具和手段，甚至需要完全消除人工的操作，这样才能在系统线性增加时，不会导致
4、运维人力的线性增加.运维的分层使运维的内容和职责更明确，也使层次之间的支持和赋能衔接更容易通过标准化接口来实现.这可能也是企业在引进SRE方法论的时候需要进一步优化SRE的地方。SRE方法论确保长期关注研发工作，在保障服务S1.O的前提下最大化迭代速度，做好变更管理，通过监控系统实现可见性和可观测性，支持应急事件的处理；根据系统对基础设施资源的需求做好需求预测和容量规划，及时部署资源以支持弹性扩展；同时持续优化业务流程中的堵点，持续提升性能.减少延迟，持续优化运维流程，提高且用，减少重复造轮子，提升效率.这和我提出的“运维的敏捷才能支撑研发的敏捷”思想相一致.SREGoogle运维解密一书中提
5、到SRE的日常工作包括几个方面：一是SRE使用计算机科学和软件工程手段设计和研发大型分布式计算机软件系统.或与产品团队合作，或研发产品系统的备份、负载均衡等组件；理想情况下.推进公用组件在多个项目中的且用，以及用现有的组件解决遇到的新的问题。这是SRE50%的研发工作时间要做的事情.研发的时候就关注可用性、可扩展性.安全性、豆用性等可症性和效率等问期.组件的且用其实和我们所提倡的中台架构思想是相通的，企业级的复用就是中台架构所追求的.二是SRE关注可靠性.SRE专注于软件系统架构设计、运维流程的持续优化，让这些大型分布式软件系统更可靠的运行，扩展性更好，更有效的利用资源等.软件系统架构设计是研
6、发关注的，运维流程是运维关注的，很多时候运维人员是难以参与到系统架构设计的，虽然说运维的参与对于系统部署架构、网络架构、可扩展性等的设计会有帮助，但普通的SRE工程肺是很难有机会参与的.人都不喜欢别人对自己指手画能.一个好的方式可能是由全局架构师团队参与系统架构设计以及系统运维流程的优化设计，从顶屣设计上能有个全局视角.这是软件系统全同可症性的保证.第三,SRE主要工作是运维在分布式集群管理系统上运行的具体业务服务，比如说云平台、存储系统、虚拟化系统、客户管理系统、人力系统、OA、邮件系统等等.SRE中的S最初指的是网站的运维服务，SRE最初的工作就是维持网站的正常运转.随若时间的推移，其管理
7、运维的内容越来越多.不过这其实还是按照传统单体系统运维的方式，从上到下，从应用到资源层，没有形成整体分展向上赋能的方式.这种方式已经不适合数字化系统融合的要求.这也是SRE方法论在数字化时代可以借鉴改进的地方。SRE的工作偏运堆却又长期关注胡发，看起来是矛盾的，不过却也是必须的.W发懂运维才能在软件研发的时候就关注部署运行可靠性、伸缩性、性能、可观测性等问题；运维懂研发才能运用软件工程的思想和方法解决运维过程遇到的自动化、体系化工具匹配，快速找到异常根因，面对应急事件时能快速定位处理等.所以SRE解决的核心问感是研发不懂运维、运维不懂研发的割裂问题。SRE的方法论为DevOps的提出提供了实践
8、和方法论基础，提出了开发运维一体化，所以也说SRE是DevOps的一种实践。SRE和传统运维的本质区别在于认知和思维,表现在工具和方法上.不同认知和思维屣次的人在面对同一个问题时所采取的方法和采用的工具是不一样.传统运维关注的是自己的一亩三分地，对别的部分不了解，额外的内容超出了自己的控制，所以害怕变更和变化.SRE通过全局的参与对整个软件产品的生命周期过程都是了解的，再辅以工具化的支持，在面对芭外情况时，做到心中有数，从容应对.当前很妥公司在推混沌工程，其实就是一种增强系统运行可靠性的方式.但是如果把混沌工程单独拿出来，可能会使向期豆杂化，混沌工程的思想和方法应该融入到日常的研发和运维工作中，持续积累完善系统运行的知识库.将知识库也作为研发和运维的支撑工具。使其成为SRE或者DevOps的一部分。SRE运维的内容不断地扩展，其方法也在不断地完善和进步.我们在学习SRE的时候，要尽可能去学习和思考其内在的思想，得其形更要有其实.从信息化到数字化，系统的豆杂度成级数增长，特别采用微服务分布式架构，众多的微服务虽然带来了迭代敬捷，也使变史和版本管理、调用链路和复用复杂化，使问题定位难度增加，所以系统的可见性和可观测性、安全性等变得越来越里要。对于一个软件人员来说，仅僮编码或仅懂运维是远远不够的。需要用研发的技能来保证运维的敏捷，用运维的思想来关注研发.
