CTO药方:如何搭建运维/SRE能力
近期有很多文章在探讨运维岗位去留的问题,我主持的SRETalk公众号里也发了多个运维总监的观点,个人也和行业内挺多人做了交流,有些许小小的想法,记录下来,供各位CTO/CIO参考,作为运维/SRE的你如果觉得迷茫,也推荐你仔细读一下本文。
本文欢迎有理有据的讨论,不欢迎杠精,另外,很多事情其实也没有非黑即白,文章内容对你有些启发,对CXO们的决策带来新的思考,那就是极好的。
关于标题
首先说一下标题,《如何搭建运维/SRE能力》,这里我没有写搭建团队,而是搭建能力,因为有些目标的达成未必一定需要自建团队,从成本、结果可预见性、长期投入维护的角度来看,需要慎重决策,决策错了,未来将是一地鸡毛,这个后文再展开。
关于运维/SRE团队
另外一点也要提前澄清,文中提到的运维/SRE团队都是为业务服务的,业务的成功是第一要务。有些运维团队做了一些产品在对外商业化输出,本身成了一条业务,这个另当别论,而且,以我在老东家的经验来看,运维/SRE团队这样的做法(对外商业化输出)不可取,尤其是在一个没有ToB基因、没有相应的ToB组织建设的公司。
从哪里获取运维/SRE能力
既然一切都是为了业务成功(不考虑业务,只考虑自己能否晋升能否忽悠老板的另当别论),我们就重点来看业务需要哪些运维能力(后文详细讲解),需要从哪里获取这些运维能力,典型的获取方式有三种。
自建团队
首先是通过自建团队提供相关能力,这个方式大家最为熟悉,自建的团队对业务的交付物通常包括两部分:产品+服务。先说产品:
- 如果产品需求是通用需求,产品大概率是直接使用的开源项目。需要考虑开源项目的持久性(开源项目研发人员是否有商业公司做收入上的支持,个人开源项目大都会死在没有收入上)、活跃性(项目是否已经多年未更新?提的issue、pr是否及时处理?通常一周内处理就可以看做是活跃的)、生态繁荣性(是否有很多人参与做贡献?很多公司投入使用?)
- 开源项目是否要二次开发?如果二次开发的代码可以merge回主干,通常意味着二次开发的代码具有通用性,得到了开源项目团队的认可。如果无法merge回主干,后面的维护就是麻烦事了,尤其是人才变动之后,一地鸡毛。基于开源项目的API做一些胶水代码,和内部系统做整合,通常是可以的,毕竟没有改造开源代码,后面开源项目升级还是可以跟得上的
- 当然也有不用开源完全自研的(只是使用一些开源的lib库,核心产品逻辑自研),这种要慎重,如果开源社区没有相关的产品,那只能自研,但是自研之后就要考虑长期维护的问题,研发人员通常喜欢做从0到1的事情,后面收益小了,无法晋升涨薪,就容易变动。而运维这个赛道,开源社区的产品琳琅满目,需要自研的产品可能屈指可数,三思。
其次就是服务,这里所谓的服务,说的是向业务侧输出的专家经验。比如自建团队做了一款监控产品,这个团队需要给公司内部的“客户”输出监控的最佳实践、监控产品出问题的时候需要这个团队快速解决。其实,公司内部的中后台团队需要有很强的服务意识,同时还得了解行业最佳实践,否则,就容易被业务牵着鼻子走,走出了和行业最佳实践背道而驰的路子,后面,就都是问题了。
服务的核心,是靠人(当然,能把最佳实践固化到产品里,那自然是极好的),作为管理者,要想让这个团队输出好的服务,就需要考虑很多人的问题,比如:能否招到相关的人才、能否留住相关的人才(发展空间、薪资等)、自建团队每个方向至少两个人互备,成本是否可以接得住。
第三方供应商
通过第三方供应商来获取运维能力,是另一个路子,供应商的交付物显然也包括两部分:产品+服务。产品分为开源、闭源两种类型,有哪些考量点呢?
- 开源的产品通常会有更多的用户、更多的场景来打磨,但是一些长尾需求,通常不开源,至于原因么,要么是开源团队把这些长尾需求作为收费项,要么就是开源团队觉得这些长尾需求不够通用,不值得放到产品里。
- 闭源的产品,通常受众小,没有太多的开源用户帮助打磨产品,就需要经过较长时间的商业化客户打磨,或者,闭源产品的供应商有很强大的质量管理体系,对产品有完备的测试,这就需要找那些家大业大的供应商了,而且,测试人员和终端用户毕竟是两类人群,商业客户的打磨是不可或缺的,只是,如果供应商有强大的质量保障团队,会让这个打磨过程变得短一些。
- 不管是开源还是闭源,供应商都是带着产品来的,作为甲方可以直接测试,来看产品匹配度,很快就可以得到反馈,而自建团队来做的话,可能需要几个月甚至一两年的时间来开发,业务可能等不起,开发完了之后产品是否真的符合预期,又有很多因素决定,结果具有不可预见性。
其次是服务,供应商相比自建的团队,通常会有优势。原因如下:
- 因为供应商见识了更多的客户场景,而ToB公司,长期的行业Know-How的积累,是这个公司的核心竞争力,供应商会不断的从优秀客户那里汲取经验,反哺给那些不那么先进的客户,良性循环,多方共赢。
- 也是因为供应商见识了更多的场景,可以对产品做更好的抽象,可以让产品更通用,更像一个产品,而自建团队做的产品,通常更偏工具,无意冒犯,我说的是通常。
- 供应商之所以在运维这个赛道创业,大概率是在这个赛道有些建树的,相比自建团队,供应商的顶层认知通常会好一些,你真的去招人的时候就会发现了,最牛逼的那群人,要么创业了,要么太贵了,要么不愿意来。
另外说一下成本问题,供应商的收费大概率是比自己招人(前提是招到合适的人)来的划算,否则的话,商业逻辑不成立。这个道理显而易见不再赘述。
从第三方供应商这里获取运维能力,看起来是碾压自建团队的,所以,后面的文章还用读么?其实也不尽然,对于某个运维能力,到底更看重的是产品能力,还是服务能力,你最需要的是产品能力还是服务能力,需要 case by case 的看,后文,我会从业务侧需要的各个方面的运维能力分别拆解。
业务需要哪些技术支撑能力
运维本质是一类技术支撑能力,跟基础架构团队很像,有些活放到运维团队是可以的,放到基础架构团队问题也不大,甚至有些公司直接把这类人放到业务研发团队,我们暂且不管分工的问题,先来梳理一下业务需要什么样的技术支撑能力。
这个图其实已经很能说明问题了,我再稍微啰嗦一下:
- 可靠的基础环境和组件:业务程序要运行,需要基础网络、硬件、操作系统、数据库、中间件等,需要这些环境和组件稳定可靠
- 快速安全变更的能力:快速变更的能力,大家很容易理解,作为研发人员,写了一个feature或者做了个bugfix,肯定很想快速交付,但是变更很容易导致故障,变更需要受控,需要尽量确保安全
- 可靠性保障能力:软件部署到生产环境之后,可能会遇到各类问题,如何能够提前做好风险量化,如何能快速发现问题、定位问题、快速止损,这可能是业务侧对运维侧最重要的诉求了
- 最佳实践:业务依赖很多基础支撑能力,这些能力用的如何?是不是业界最佳实践?是不是公司内其他大部分业务的最佳实践?需要基础支撑团队反哺给业务
各个能力如何获取
上面谈及的四个能力,应该如何获取?下面我们就掰开了揉碎了讲一讲。
可靠的基础环境和组件
首先说基础硬件环境,显然有两种选择,上云 or 自建,如果是政策有要求必须自己折腾,那没有办法,以政策为准。如果可以自行选择,现在这个时代,大概率是上云更合适,除非公司体量很大,机器量很大,自建才可能有优势。注意,我这里说的是才可能,算成本的时候切记要把人力成本算上,别只算了硬件的成本。
关于择业:对于系统运维工程师、网络运维工程师,看起来并不是个好消息,云的出现确实抢占了一部分这类岗位的空间,没办法,时代的车轮滚滚向前,大家都是历史的尘埃。
再说组件,比如MySQL、Redis、MongoDB、Kafka、ElasticSearch、Nginx、Kubernetes等等,显然有3种选择,使用云上PaaS产品 or 自己折腾 or 自己出硬件+供应商出方案和服务。针对每种选择,我们分别做一下点评:
- 云上PaaS产品:如果规模不大,没有相关人才储备,使用云上PaaS产品,是比较合适的,可以快速把能力建设起来,选择使用云上PaaS产品的甲方,通常已经使用了云上的虚拟机、Kubernetes类的Runtime环境,顺带采买PaaS类的产品,也比较丝滑,不需要再跟新的供应商做对接。
- 自己折腾:如果某个组件规模很大,或许是有自建的必要性的,比如Kafka,自己折腾,招2个人一主一备,水平还可以,出了问题能兜底,在北京的话每年大概100万的成本,得多大的规模才能从硬件和组件上省出这些钱呢?当然,也可以招聘一些低成本的运维工程师(划重点,这里可能需要运维工程师,但是职级不高),能解决日常问题,高阶问题解不了,高阶问题可以求助外部供应商的专家服务。
- 自己出硬件+供应商出方案和服务:第三方供应商相比云厂商的PaaS产品,通常性价比更高,响应更快,但是组件如此之多,每个供应商大概率只能搞定有限的几款,作为甲方,可能要同时跟多个供应商打交道,略微麻烦。对于需要跨云协同的产品,比如统一监控、故障定位、FinOps相关的产品,如果公司用了多家云或是混合云架构,大概率是第三方供应商更为合适。
关于择业:各组件的资深老炮,第一选择是去云厂商工作或创业输出经验,第二选择去自建组件的大厂,普通中小厂,很难有高薪资,毕竟第三方的专家服务性价比不低。
快速安全变更的能力
业务研发最常做的变更是二进制、配置的变更,当然,还有对基础环境以及组件的变更需求。
我们先说二进制、配置的变更,怎么做才能又快又安全的迭代呢?可以分阶段,公司还比较小的时候,不用太关注工具的建设,只需要定好规范和流程即可。规范方面比如:部署在哪个账号下,哪个目录下,日志怎么放,进程怎么托管,任何变更必须能够可回滚等等,流程方面比如:变更通报机制、多模块协同上线机制、无法回滚的需要有审批机制等等。
然后,需要有历史变更的量化数据,比如某个团队最近一个季度有多少次变更,回滚率如何,故障率如何,各个团队有个对比,做的不好的团队就会在下个季度好好改善的。
当公司继续变大,就可以投入人力做变更类的平台,把规范制度落实到平台上,产出量化数据,因为不同的公司情况各异,在传统的物理机虚拟机时代,很少看到有商业化的变更系统。当然,Kubernetes起来之后,屏蔽掉了底层的很多差异,基于Kubernetes做变更平台通用性强了很多,开始有相关的产品出来。
生产环境的变更,和测试环境、联调环境的变更还不太一样,生产环境对稳定性要求比较苛刻,测试环境、联调环境则相对没有太高的要求。所谓的CI/CD的系统,大都是针对测试环境、联调环境的,能够对生产环境做到CD的公司,屈指可数。
划重点:测试、联调环境的CI/CD系统,更多的是为研发效率提速;生产环境的变更系统,更多的是确保稳定性、落地规范制度的。公司前期体量小,靠规章制度就够了,后面就需要规章制度+变更平台协同发力了。
这个规范制度谁来定?变更平台谁来开发?
规范的制定其实偏前期,可能运维团队都还没有的时候规范就已经有了,所以,大概率是CTO以及下辖的Core团队来制定就好了。如果之前没有制定过,运维总监(运维总监上场了)可以牵头制定,CTO下辖的Core团队来评审(大家有参与度),最终CTO拍板(自顶向下)发布,大家执行。
变更平台的开发,由运维团队来开发相对比较合适,后文还会介绍一些其他的平台,成立一个专门的运维团队(这里我说的运维和SRE没有区别,你也可以管这个团队叫SRE团队)是合适的。变更平台因为要落地公司的规范,外采的情况比较少,公司大到一定规模之后,基于开源的东西自研、攒,是个大概率的选择。
关于择业:变更管理是企业中的重要一环,同时服务于稳定性体系。这是一个典型的DevOps岗位,天花板大概在P7+的水平(纯属个人看法,仅供参考)。
另外就是基础组件和环境的变更,典型的比如MySQL表结构、Nginx配置、DNS、VIP等等,这类变更可以内化到组件管控平台里,让组件能力提供方提供变更入口和管控能力。
可靠性保障能力
这个能力非常重要,SRE就是Site Reliability Engineering的缩写,即站点可靠性工程。从CTO的角度,软件部署到生产环境,后续可能会有各种问题发生,希望能有一套工程体系来保障可靠性。这是一个巨大的话题,本文不会事无巨细,只是理清楚哪些事哪些人来负责即可。
所谓的可靠性,就是与故障做斗争的过程,所以,我们还是来看故障的生命周期,从生命周期的各个环节着手,把故障打趴下,甚至直接把它扼杀在摇篮之中。
故障开始之前降发生
事前的预防和风控,有很多的工作。比如:制定告警完备性标准并对各个业务线做量化评估;制定定位原则和流程以及故障定级定责的标准;提前梳理各个业务的核心功能和服务模块的对应关系,建立全局稳定性视图或者作战室,便于快速揪出故障模块或接口;对架构做优化;梳理故障预案并定期演练保鲜,也就是混沌工程那摊事;等等等等。
这里有些事情是需要业务研发来搞定的,比如架构优化,剩下的事情,我的建议是:让运维团队来牵头,研发配合。比如CTO下辖的Core团队大概率既有运维一号位也有各个业务的技术一号位,名义上要CTO拍板,授权运维一号位来牵头,各个业务的研发一号位来配合,当然了,实际操刀的时候,运维一号位可能是找了一个得力干将来实操,各个业务线可能也是有技术一号位依仗的人来做接口人配合。
除了架构优化之外,其他这些事情都是横向的事情,是可以有一些方法论和最佳实践的,把大家拉通,有利于共享这些方法论和最佳实践。当然,有些人会有疑问:我们能否直接在研发团队找个人来组成这么一个稳定性的虚拟组织,共同推进这个事情呢?其实也可以尝试。不过会有这么几点问题:
- 每个业务线通常只有这么一两个接口人,人少活多,这个人大概率很难兼顾业务代码开发和稳定性工作,如果这个人全职做稳定性了,其实就相当于SRE了
- 如果是SRE,和业务研发人员的考核体系其实是不同的,KPI怎么定?而且这个人可能也没有很好的归属感
- 如果这个人同时兼顾两个事情:稳定性、业务研发,可能会引发人的惰性,稳定性工作遇到问题的时候,天然的就会想去干点业务研发的活,业务研发遇到问题的时候,又想偷懒去干稳定性的活
划重点:事前的预防和风控,请各位CXO找运维总监要结果,但是必须给予极大的配合,从上往下推。对于搞定这摊事的SRE工程师角色,看起来是需要非常专业的高级别人士,工作5年以内大概率认知跟不上,或许,从资深研发团队招SRE是一个不错的选择,各位CXO可以尝试下。
故障开始之后降影响
一旦故障发生,我们的首要目标就变成降影响了。相关团队立马协作起来,快速定位直接原因、快速止损,事后再慢慢排查根因即可。这里会涉及如下一些工作内容:
- 定义故障:通常,业务的指标出现问题就代表故障开始了,比如订单量下跌、叫车呼叫量下跌、支付量下跌,老板会尤为关注这类指标;而某个机器的CPU飙高或者磁盘用满,可能只是团队内部消化的问题,甚至K8s类的系统自动漂移解决,通常对客户主流程没有影响,老板是不关注的。为了不至于草木皆兵,我们就需要区分故障和问题的定义,不同的业务线指标不同,但是总体方法论是一样的。
- 响应故障:故障告警接收人是给业务研发?还是SRE?还是OnCall中心?不同的公司做法差异巨大,我个人的想法是:直接发给有能力处理的人!没有非黑即白,不同的告警不同的处理机制,比如基础网络有问题,显然是要发给网工,某个业务有问题,发给对应的运维和研发,尽量不要在中间再转一次,发给张三,张三处理不了去联系李四,就浪费时间了,故障处理应该争分夺秒。
- 快速定位:一套行之有效的故障定位系统,是大杀器。故障定位系统通常是基于可观测性数据构建的,可以看做是驾驶舱级别的产品。可观测性数据是海量的,如果不经过梳理利用,这些海量的数据无法变成有价值的信息。从定位的角度来看,通常需要的是:可观测性体系+故障定位+持续运营,这里要展开的话内容就太多了,如想详细探讨可以联系我,什么?不知道怎么联系?SRETalk公众号,了解一下。
- 快速止损:止损要快,就要有完备的预案,每次故障复盘的时候,建议CTO、运维总监关注预案有效率,就是说,这个故障是否是利用一个既有的预案来止损的,还是现攒的解决方案。如果是现攒的,说明你们的预案不够完备啊。
OK,上面洋洋洒洒一片,回归问题,针对这块工作内容,CTO找谁要结果?我的建议是:SRE团队(文中多次出现运维、SRE字眼,在本文中基本都代表一个意思,这里的运维不止是Operations)。显然SRE无法搞定所有的故障,应该说大部分故障都得借助其他团队的人,但是CTO总不能一会找A团队一会找B团队吧。所以,SRE要携CTO的尚方宝剑,牵头整体的稳定性建设,各个业务需要出接口人极力配合,所谓的稳定性建设,包括事前的预防风控、事中的统筹协同、事后的复盘推进,这也是SRE对公司的最大价值。
最佳实践
这个内容很多,比如用什么机型套餐比较合适,用什么组网方式比较合适,用哪些组件公司具有更好的掌控力、可以得到更好的支持(不管是内部团队还是借助第三方供应商),公司推荐甚至要求的编程语言、框架是什么,业界推荐的接入层方案是什么?变更方案是什么?可观测性怎么做?等等等等。
不可否认,牛逼的业务研发团队,这些实践方式是门清的,但是同样不可否认,业务线多了之后,水平是良莠不齐的,水平差的团队势必需要教练角色的人,总不能啥事都去找CTO吧,SRE团队作为一个横向的技术团队,特别适合负责这摊事。但是显然,这是一个高端职位,新瓜蛋子干不来,招聘高阶人士做业务BP是推进技术栈趋于统一的有效手段,如果CTO用不好这个抓手,技术体系会百花齐放,后面则是各种治理困局。
上面的四个支撑能力,业务侧应该如何获取,CTO应该如何统筹,各团队应该如何配合,大致就说这么多。下面我们再做两个小结。
小结1:CTO如何帮助业务线获取这些支撑能力?
显然,CTO不需要亲力亲为,但CTO要做好把关,CTO要颁发政策,是全军统帅。横向的工作落给SRE团队,各团队出接口人极力配合,大概率是个最佳实践。如果把横向的工作目标完全打散到业务团队自闭环,就无法享受到横向团队带来的经验传播能力。而且,屁股决定脑袋,不在其位不谋其政,各个业务自己容易有小九九,中心的横向组织也是一个削藩机制,抱歉这个词用的重了,本意是好的,你要自己体会啦。
另外补充一点FinOps的话题,FinOps也是一个横向能力,是否也要交由SRE来做呢?这个倒是未必。就让业务自闭环我觉得也挺好的,业务自己要负责盈亏,IT支出是支出大头,业务的GM理应是很上心的,CEO把营收净利相关的KPI压给业务GM,业务GM可以自闭环做好折中的。
小结2:运维/SRE择业建议
如果没有太高的职级和薪资期望,做一些相对基础的Operations工作也是可以的,10年内这个岗位大概率不会消亡。如果对职级和薪资有更高期望,先深扎某个细分领域,做到行业专家,是一条行之有效的路径。再之后,则讲究多个技术方向的融会贯通了,又要往广度发展。再之后,创业或者高管。
本文作者
秦晓辉,Open-Falcon、Nightingale 创始研发,极客时间《运维监控系统实战笔记》作者,公众号 SRETalk 主理人,快猫星云创业合伙人,创业方向是稳定性保障方向。