从SRE看DevOps平台建设.docx
《从SRE看DevOps平台建设.docx》由会员分享,可在线阅读,更多相关《从SRE看DevOps平台建设.docx(9页珍藏版)》请在咨信网上搜索。
1、 从 SRE 看 DevOps 平台建设 【导读】SRE可以被看作是DevOps理论的一项具体实践,但也不能把它当作最佳实践神化。本文着重从SRE实践出发阐述了DevOps的建设思路。SRE就是在用软件工程的思维和方法论完成以前由系统管理员团队手动完成的工作。SRE的职责是运维一个服务,该服务由一些相关的系统组件组成,为最终用户(可以是内部用户也可以是外部用户)提供服务。SRE的终极责任是确保该服务可以正常运转。为达成这一目标,SRE需要完成开发监控系统、规划资源容量、处理紧急事件、跟踪修复事故根源等。SRE对重复性、手工性的操作有天然的排斥感,并有足够的技术能力快速开发出软件系统以替代手工操
2、作。DevOps的核心思想是协调开发Dev和运维Ops关系,使之能有效沟通和协作,通过工具链、流水线高效衔接,持续反馈,实现研发Dev到运维Ops流程的持续优化和完善。一、理解SRE和DevOps异同有人说SRE就是DevOps,DevOps等于SRE,其实是不对的。DevOps是一种协调开发和运维之间协作关系的思想理念,SRE是在Google类似于DevOps思想理念的一种实践。SRE更关注站点或产品或应用服务等运行的稳定性,以“错误预算”协调开发和运维之间的利益关系,所以SRE其实更多是在Ops端。但关注“运维Ops”这无疑是正确的,和我们习惯于更关注“开发Dev”是不一样的。SRE强调用
3、工程化的手段应对运维问题。软件运维问题达到一定规模时,也确实只能通过软件工程化的手段来解决。SRE团队替代了很多研发Dev的工作,使Dev更专注于业务应用或产品的研发,而不再关注软硬件基础设施和中间件工具,所以研发的工作就聚焦化了。同时通过SRE团队所构建的自动化工具链、流水线等提升了研发效率。DevOps和SRE的关系类似于SOA和ESB的关系。SRE是DevOps思想落地的一种方式。SRE模型成功的关键在于对工程的关注,如果没有持续的、工程化的解决方案,运维的压力就会不断增加,也就需要更多的人来完成工作。SRE的终极目标是推动整个系统趋向于无人化运行,也就是智能化,不仅仅是自动化。“如果系
4、统正常运转中需要人工干预,应该将此视为一种bug”。SRE既做运维也做开发。其开发时间不少于50%。既保障SRE有足够的时间和精力去进行真正有创造性的、自主性的研发工作,同时也保障了SRE团队有足够的运维经验,深度理解运维的需求,从而让他们设计出切实解决问题的系统。但SRE只是关注于运维工具和流程自动化的研发,而不做业务应用或产品的研发。这也从实践说明了DevOps的建设是需要靠自己而不是靠外部厂商。因为这是一个持续的,不断变化改进的过程。二、研发和运维之间的利益冲突企业中研发Dev和运维Ops之间最主要的矛盾就是应用服务迭代创新的速度与应用服务稳定运行程度之间的矛盾。我们总是强调敏捷研发、敏
5、捷交付,但是研发之后交付之后改怎么运维却考虑的比较少。虽然目前智能运维AIOps等很多人都在讲,但个人觉得目前更多只是噱头,远未到智能运维的阶段。试想基本运维都没做好就去做智能运维,就像让不会走的小孩就要跑起来,有点可笑。要解决Dev和Ops双方的利益冲突,则需要同时能关注矛盾双方的诉求、保障矛盾双方的利益。既要保证“速度”,更要关注“稳定性”。但任何软件系统都不应该一味追求100%可靠。对最终用户来说,99.99%、99.999%和100%的可用性并没有实质的区别。因此DevOps建设就是追求这种矛盾的统一。我们说过,在软件整个生命周期过程中,研发阶段可能只占20%,大部分时间都是在运维、在
6、持续优化。所以SRE关注运维是正确的。解决方式就是通过软件工程化、系统化的方法来解决运维问题,这也就是很多人说的“研发运维一体化”(这里的研发是“运维研发”,不是“产品研发”)。企业DevOps建设就需要设法协调研发与运维之间的矛盾,满足双方的利益诉求。SRE是通过高层所定下的“错误预算”来协调双方矛盾的(但错误预算有其局限性,我们将在后续详细讨论DevOps效率建设问题)。在DevOps建设中,研发关注需求、CI,CD则需要和运维协作,这也是我们一直反对在容器云平台做流水线做CICD的一个原因。运维平台、运维工具、运维方法、运维流程、运维组织和运维思想的首先建立是必要的。做好运维,将会更好的
7、支撑敏捷研发和持续部署发布,真正实现敏捷。三、DevOps建设思路对DevOps的错误理解之一就是一个人什么都干。要提升软件工程效率,就必须实现分工。这和社会生产发展规律也是一样的。只有分工才能提升效率。因此DevOps建设首先就需要考虑职责分工。从SRE实践我们看到,DevOps建设要关注运维,运维要分层,职责要轮换,体系要简单,追求矛盾的统一。用软件工程化的方式建设软件基础设施来支撑产品研发,提升研发效率。(1)DevOps建设重点在运维Google SRE虽然也做运维工具和运维组件的研发,但本质上是运维团队。只有运维团队把软硬件基础设施准备好了,应用或产品开发团队才能更好的享受软硬件基础
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- SRE DevOps 平台 建设
1、咨信平台为文档C2C交易模式,即用户上传的文档直接被用户下载,收益归上传人(含作者)所有;本站仅是提供信息存储空间和展示预览,仅对用户上传内容的表现方式做保护处理,对上载内容不做任何修改或编辑。所展示的作品文档包括内容和图片全部来源于网络用户和作者上传投稿,我们不确定上传用户享有完全著作权,根据《信息网络传播权保护条例》,如果侵犯了您的版权、权益或隐私,请联系我们,核实后会尽快下架及时删除,并可随时和客服了解处理情况,尊重保护知识产权我们共同努力。
2、文档的总页数、文档格式和文档大小以系统显示为准(内容中显示的页数不一定正确),网站客服只以系统显示的页数、文件格式、文档大小作为仲裁依据,平台无法对文档的真实性、完整性、权威性、准确性、专业性及其观点立场做任何保证或承诺,下载前须认真查看,确认无误后再购买,务必慎重购买;若有违法违纪将进行移交司法处理,若涉侵权平台将进行基本处罚并下架。
3、本站所有内容均由用户上传,付费前请自行鉴别,如您付费,意味着您已接受本站规则且自行承担风险,本站不进行额外附加服务,虚拟产品一经售出概不退款(未进行购买下载可退充值款),文档一经付费(服务费)、不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
4、如你看到网页展示的文档有www.zixin.com.cn水印,是因预览和防盗链等技术需要对页面进行转换压缩成图而已,我们并不对上传的文档进行任何编辑或修改,文档下载后都不会有水印标识(原文档上传前个别存留的除外),下载后原文更清晰;试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓;PPT和DOC文档可被视为“模板”,允许上传人保留章节、目录结构的情况下删减部份的内容;PDF文档不管是原文档转换或图片扫描而得,本站不作要求视为允许,下载前自行私信或留言给上传者【快乐****生活】。
5、本文档所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用;网站提供的党政主题相关内容(国旗、国徽、党徽--等)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
6、文档遇到问题,请及时私信或留言给本站上传会员【快乐****生活】,需本站解决可联系【 微信客服】、【 QQ客服】,若有其他问题请点击或扫码反馈【 服务填表】;文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“【 版权申诉】”(推荐),意见反馈和侵权处理邮箱:1219186828@qq.com;也可以拔打客服电话:4008-655-100;投诉/维权电话:4009-655-100。