@gaoxiaoyunwei2017
2021-06-29T14:29:32.000000Z
字数 5756
阅读 2689
未分类
说明:本文根据付来文老师在 GOPS 全球运维大会 2021 · 深圳站的演讲速记整理而成。
作者简介
付来文,花名“郁松”,2013年加入阿里巴巴,多年来专注于业务连续性管理领域,见证了服务于阿里经济体的业务连续性管理体系发展。现负责阿里云一站式服务管理平台(AIOS)产品及服务,帮助云上企业解决数字化转型所需的实时运营及管理问题,保障业务连续性,降低服务成本。
今天讲的可能更篇管理领域的事情,所以我会提到调研今天是否有团队管理的角色。
本文将从四个部分介绍:
疫情期间催发的社会现象,大家或多或少都有所感受。疫情也催生了如健康码、直播带货、线上教学等业务的发展。我不知道今天在座有多少同学真正参与到这个业务过程中去?疫情孵化的机会很短暂,如果抓住机会对企业的发展有非常大的帮助,最典型是直播带货和在线教学。
我个人认为,在线教育之前的发展趋势可能会趋于平滑,但是疫情把它拉起来了,诞生了非常知名的一些公司,有些公司也越做越大。有一个典型的例子,去年疫情的时候,因为直播教学非常火,有一家线上教育公司原来的生产环境也是在IDC,之前在学校上课的那么多高中生、中学生、小学生,疫情的到来,导致全部转到线上,这是一个典型的数字化转型:从线下教育到线上教育。
假设这家公司的应用系统只能承载3万学生同时在线,疫情来了业务翻了30倍。但生产环境的IDC,怎么来快速承载业务量的突增?我讲数字化转型,包括疫情这样的突发事件带来数字化改革所孕育的机会,在座的同学是否准备好相关的能力去迎接好这样的机会?
从3万的最高承载量忽然提升到30万,今天我们的经验和能力,尤其从运维角度,是否能够快速的帮助公司业务支撑好这个规模?这给运维带来非常大的挑战。
直播带货也是一样,很多健康公司想抓住这个风口,今天我们同学能否在很短的时间内利用成熟的商业化场景快速搭建一套直播系统,5天搭建和50天自研是两回事。数字化转型带来了非常多的挑战,今天举手说公有云的只有一小部分,我相信这个趋势一定会越来越突出,一定会带来越来越复杂的基础设施。从一朵公有云到多个公有云。另一个层面,更高的程序集成的要求,怎么在业务不受影响的情况下做更高的东西。包括这个过程中怎么保障好业务员的东西。所以每次社会变革都孕育着一些机会。在每次变革过程中,例如第一次革命在英国,第二次在美国,都对世界带来很大的影响。在这次数字化变革过程中,也一定有很大的机会。在转型的背后,我所看到的业务连续性管理的机会。
另一个层面,刚才两位同学提到了一个很有意思的事情,就是中间件是否上云。这是一些数据,第一是公有云IT基础设施支出首次超过传统IT基础设施。第二是Business DrivenIT。包括我这次来的时候路过机场,也发现华为云、腾讯云、阿里云都有对应的公有云广告,不知道大家是否观察到这个现象?我核心想表达的点,是技术基础设施越来越完善,创业创新的成本一定会越来越低,企业一定会越来越专注于业务发展。包括这次疫情有多少家企业基于微信小程序直播带货很快速的把生意做起来,这是一个电信的基于云化的基础设施所带来的便利。在这个便利过程中,我想说业务连续性一定会成为快速发展过程当中企业的生命线。我认为业务连续性管理将会成为运维的核心职责之一。
接下来谈什么是业务连续性管理。管理这个词我更喜欢用它的英语Operatios。
在讲这个概念之前,先解一下题。业务大家容易理解一些,今天对于典型的电商场景,什么是它的业务?成交。在线教育的核心业务是线上教学直播的时长。这些都是业务。什么是连续性?也很好理解,可用性、稳定性、MTTR、SLA等等。管理即运营,实时运营管理。下面是一些国外机构,我不知道大家对业务连续性的理解有多少,想表达的意思是国外已经有一些组织对业务连续性已经有了相关的成熟体系。国外有这些成熟标准体系对标我们国内能做到什么程度,我们在实践过程中,我们在支持云上客户过程中,也有一些可落地的最佳实践的经验。今天大家来听我这个场次,什么概念要印象深刻,这一页大家可以快速形成一个基本的认知,刷新一下大家对于业务连续性管理的认知。
什么时候需要业务员连续性管理?有这么几个场景对大家有帮助。第一是企业突然发生一个重大故障,例如核心业务中断两三个小时,这个时候领导一定很关心今天这个问题发生之后我们有什么体系或者措施保证下次不发生这样的故障,或者下次再发生这样的故障我们有什么措施能快速解决?第二,今天我们运维做的很多工作,运维团队如果要有更大的边界去发展,可以尝试考虑运维连续性管理,可以扩展运维的职责分工和业务范围。第三,对于运维职能扩展和发展方向上的建议,毕竟运维一线的工作会有越来越多的工具,运维同学在某个领域做了这么长时间之后一定会有自己更高阶的发展,有的同学想做架构师,业务员的连续性管理在阿里已经证实是向上走的路径。阿里的团队也非常大,已经证明了是一个成熟的职业路径,可以从运维管理向整个业务连续性管理去考虑。这是几个场景,对大家有一定的受益,帮助大家快速建立认知的场景。
我先从最中间的管理范畴讲起,管理所有资源,这是企业的所有资源,包括基础设施、IOT设备、对应的一些业务和应用。包括管理所有的问题,工单报警、事件、故障。包括这两天开会时很多公司起到的变更事宜。变更是一定会有,如果不变企业产品迭代就没办法持续。
包括度量和可视下面也会讲。还有资源支撑保障。我们和一线运维服务人员聊的时候,他们担心增加工作量。最右边的是流程机制把控质量,本质上是流程化的改进。下面的产品支撑高效管理对应的有哪些产品后面又会有最佳实践的介绍。最终提升业务连续性,降低运维成本。包括在提升业务连续性和降低运维成本过程中一定会推进做相应的改善。今天这个最佳实践不代表是业务连续性的全部,这有个X轴和Y轴,技术发展和业务体量。
包括这里这些体系只是最基本的框架,我希望各位能够基于它结合自身企业的情况能够做相应的扩展,不一定那么多,也不一定那么少,大家可以根据自己企业的情况有一个最基本的框架化的认知,做业务连续性管理要有成体系化的认知,知道要做哪些事情。这是我们最佳实践的经验。
第三部分会展开讲,说说我们最佳实践经验的来源。最左边是阿里巴巴安全生产的实践经验,大家可以期待一下第四场暴晓亚的分享,他会对左边部分展开更细节的介绍,阿里业务连续性会比我的PPT多得多。右边是我们支撑一些云上客户的三年时间的实践经验,既有阿里巴巴自身实践经验的标准化和客制化,也是我们三年多自己所沉淀的合作最佳实践。
这是其中一部分的一站式管理流程图,刚才讲到整体框架,还有非常多的部分。但是那些怎么串联起来,这是一个流程式的指引。它会分四部分,包括业务CMDB配制、发展问题、处理问题、复盘改进。
大家做业务一定会有经验,今天新接手一个业务,一定要梳理得很清楚。今天做业务连续性管理,需要把整个公司的业务做从上到下的梳理,公司的核心产品、核心业务有哪些核心模块,对应的核心指标有哪些。本质上需要运维同学跳过原本基础设施层面更往上看这个事情。它会有很多业务场景。
故障定位是阿里内部的定义,它的核心价值、核心功能、核心作用是定义好业务的优先级。业务发生一定有并行度,要有一个共识。还有干系人、订阅关系、服务组都是处理人的问题。这个流程里面,上面是通过监控来收集系统的问题,下面是通过工单来收集人工的问题,两者相关联才能做整体的业务连续性管理。事件是跟进的机制,确保的是现场每一个发生的异常都能够及时处理,能够有人处理,并且处理时有相应的机制。
对于故障会更加重,每个故障一定会有一个根因,会详细了解背后的根因信息。
就是故障找到原因之后,一定要弄清楚这个故障到底技术问题还是流程问题,还是怎么样的问题,还是第三方不可抗拒的因素导致的一问题,只有这样才能形成改进的闭环,它持续运营下去才会对线上生产环境会有越来越大的帮助。有一个管理者视角的数据报告,业务员管理的是业务,但是做这个事情是管理角色,是面向管理来做这个事情的。你需要借助管理的力量去推进一些运营,通过流程的方式来推动业务管理相关的这些人。
这是一个产品的实践经验,我这里面没有太多的产品截图,更多是讲产品怎么来做这个事情,如果大家想知道产品怎么实现,场外都有宣传,大家可以去看。这是一个产品的实践,每个颜色对应的产品功能或者模块,有CMDB模块、故障等等。大家在看的时候,多个厂商基本都是可视化的非常酷炫的大屏。
做业务连续性管理,管理工作一定非常多,非常需要产品做相应的支撑。只有基于产品的基础上,规范、数据等等才能落地,做更好的运营和可视化。
产品的方式有非常多种,你可以选择自己研发,也可以选择搭建开源的系统,也可以选择用相应成熟的商业化产品。
这是一个监控,监控这个东西没有太多可以去讲的亮点。昨天我听到有提到今天时序数据库是整个数据库中增长最快的模块,情理之中,今天万物皆可时序数据化,包括对应的IOT的监控。我相信其他的基础监控、业务监控、应用监控大家都会提到。
为什么提到IoT监控与下面集成监控系统的对接?因为今天的监控系统实在太多。但是这些监控系统有存在的意义,也非常有必要,却有一个核心的工作要去做,就是把这些监控系统能力做一个整合,不管是把数据统一汇聚到TSDB,还是外部所有的记录做一个汇聚整合也好,否则监控系统那么多会带来非常多的管理成本,基于监控可以做后续的报警、事件等等。如果大家有自研的监控系统需求,可以关注 Prometheus,可以基于 Prometheus 做一些上层的定制化改造,因为我觉得 Prometheus 在云原生领域,还是支撑 IDC ,我觉得它的能力非常全面。当然也可以根据自己企业的需求采用第三方的产品。
这是一个公共云,前面大家举手很少,我不展开讲了,这是对应阿里公共云的能力,想表达的意思是今天各位如果要做监控相关的事情,不管是云上还是开源,已经有非常多的监控产品来做。
监控非常有必要,业务连续性管理的触手或者抓手是监控。监控加的越多,触角才更加细,更加实时。这里的监控层次都是这样几个层次。之所以有这个层次,希望大家有一个框架式的概念,今天我要做业务连续性管理,步是完善层次。
这里面这么多层的监控,如果问我哪一层最重要,答案一定业务监控。我们做了很多客户,帮他把业务监控完善之后,他在知道今天的业务核心峰值是哪一刻,之前他都没有这个体感。
阿里内部的业务监控已经做得非常完善,做业务监控也很难,尤其是很多同学在做业务监控的时候选择的方式想的是直接从数据库里面写一个SQL弄出来,这个方式风险非常多,可能会造成线上故障。
所以业务监控的最佳实践手段一定是日志监控。包括我们自己在阿里内部实践那么多年下来之后,做到秒级交易订单也是基于日志监控。这是一个最基本的格式。这五个标准指标谷歌SRE、腾讯云、阿里都提过:总量、成功量、成功率、失败量和耗时。
这是一些IM工具能力。今天这些IM厂商在这方面的能力已经足够开放。为什么提消息碎片即生产力?不是我们提出的。大家工作过程中一定会有非常多的琐碎的东西,可以和它结合。大家看功能这么多,其实它并不复杂,不会耗费大家太多的研发精力。
这是变更管控,线上变更定带来故障,变更管控到底从哪里入手?审批入手大家都知道了。阿里内部的经验是变更集成对接。今天一个企业工具发展到一定阶段,它能在生产环境做变更的工具一定越来越多,确保线上每发生一个变更一定会有一个集中的变更中后台的地方了解,这样才能和事件及故障做相应的结合,结合之后才能做更好的管控。
这是知识。知识库的经验更适用于有一定业务规模的场景,很多时候不管是说工单的复用处理,让一线客服自解决。而知识库和事件、故障、工单的匹配又很关键,对于我们自己在和一些客户实践过程中,业务连续性管理和业务相关,业务和很多功能相关,很多功能相关的场景都是事件化的,通过知识库来降低一线人员的处理成本,发挥非常重要的作用。
为什么提到要把工单和报警事件做结合?很典型的场景,很多运维同学在做限流的时候,不知道大家是否去关注过一线客服是否有反馈?很可能已经有一些用户反馈过来,只是大家不知道。通过工单和报警事件的结合,运维可以站在更高的业务层面去看已经带来的用户提感,可以在限流手段上更精细化,或者时段避开。
怎么样的运维才能是好运维?大家都是说运维是空气,平时感受不到,只有出了故障才能感觉到。通过可视化,有一个非常关键的作用是将运维工作的业绩通过可视化的方式统一展示,给领导层向上管理主动刷存在感。这非常重要。包括感知,更多是向上的感知,能够让上层知道你今天做了这么多工作,除了有故障的时候,平常没有故障的时候,到底运维做了哪些事情,通过可视化的手段做更好的向上管理运营。越实时效果越好。
这是我们给一个高校做的实践案例,是业务化场景。包括常见的学校教室、教学、教务。这次疫情对学校的影响非常大,很多学生都是在线教学,在线教学的直播延时、人数等都是非常关键的指标,IOT设备整体管控、应急、策略都非常关键。这是我们在教育行业所做的案例,更多想表达的是今天我们能够跳出各自的固化思维,能够上升到业务层面去关心企业发展核心关注的指标是什么,以及站在运维角度怎么更好的服务这些人。
最后讲发展趋势,这是第一次讲。今天业务连续性管理可以交给在座的各位去定义。我为什么讲运维是建造业务,是builder,就像外卖一样,我前面讲的逻辑是今天基础设施越来越完善,企业越来越关注业务开发,谁来负责builder业务?应该是运维。第二,运维的发展趋势是,我今天讲的是业务连续性管理,更长远来看运维应该主导业务连续性的建设,只不过业务连续性管理是抓手。所以我觉得运维背后的逻辑一定在于更好的保障业务连续性,在履约的事情是由运维来完成的。