近期有很多文章在探讨运维岗位去留的问题,我主持的SRETalk公众号里也发了多个运维总监的观点,个人也和行业内挺多人做了交流,有些许小小的想法,记录下来,供各位CTO/CIO参考,作为运维/SRE的你如果觉得迷茫,也推荐你仔细读一下本文。
我自认为这是一个深度的思考了,可能枯燥,但对择业和团队搭建都会有些帮助。本文欢迎有理有据的讨论,不欢迎杠精,另外,很多事情其实也没有非黑即白,文章内容对你有些启发,对CXO们的决策带来新的思考,那就是极好的。
另外,SRETalk的运维总监采访还会继续,还会有更多不同的观点持续输出,供大家参考,而我的观点,不一定对,也是仅供参考哈。
首先说一下标题,《如何搭建运维/SRE能力》,这里我没有写搭建团队,而是搭建能力,因为有些目标的达成未必一定需要自建团队,从成本、结果可预见性、长期投入维护的角度来看,需要慎重决策,决策错了,未来将是一地鸡毛,这个后文再展开。
另外一点也要提前澄清,文中提到的运维/SRE团队都是为业务服务的,业务的成功是第一要务。有些运维团队做了一些产品在对外商业化输出,本身成了一条业务,这个另当别论,而且,以我在老东家的经验来看,运维/SRE团队这样的做法(对外商业化输出)不可取,尤其是在一个没有ToB基因、没有相应的ToB组织建设的公司。
既然一切都是为了业务成功(不考虑业务,只考虑自己能否晋升能否忽悠老板的另当别论),我们就重点来看业务需要哪些运维能力(后文详细讲解),需要从哪里获取这些运维能力,典型的获取方式有三种。
首先是通过自建团队提供相关能力,这个方式大家最为熟悉,自建的团队对业务的交付物通常包括两部分:产品+服务。先说产品:
其次就是服务,这里所谓的服务,说的是向业务侧输出的专家经验。比如自建团队做了一款监控产品,这个团队需要给公司内部的“客户”输出监控的最佳实践、监控产品出问题的时候需要这个团队快速解决。其实,公司内部的中后台团队需要有很强的服务意识,同时还得了解行业最佳实践,否则,就容易被业务牵着鼻子走,走出了和行业最佳实践背道而驰的路子,后面,就都是问题了。
服务的核心,是靠人(当然,能把最佳实践固化到产品里,那自然是极好的),作为管理者,要想让这个团队输出好的服务,就需要考虑很多人的问题,比如:能否招到相关的人才、能否留住相关的人才(发展空间、薪资等)、自建团队每个方向至少两个人互备,成本是否可以接得住。
通过第三方供应商来获取运维能力,是另一个路子,供应商的交付物显然也包括两部分:产品+服务。产品分为开源、闭源两种类型,有哪些考量点呢?
其次是服务,供应商相比自建的团队,通常会有优势。原因如下:
另外说一下成本问题,供应商的收费大概率是比自己招人(前提是招到合适的人)来的划算,否则的话,商业逻辑不成立。这个道理显而易见不再赘述。
从第三方供应商这里获取运维能力,看起来是碾压自建团队的,所以,后面的文章还用读么?其实也不尽然,对于某个运维能力,到底更看重的是产品能力,还是服务能力,你最需要的是产品能力还是服务能力,需要 case by case 的看,后文,我会从业务侧需要的各个方面的运维能力分别拆解。
运维本质是一类技术支撑能力,跟基础架构团队很像,有些活放到运维团队是可以的,放到基础架构团队问题也不大,甚至有些公司直接把这类人放到业务研发团队,我们暂且不管分工的问题,先来梳理一下业务需要什么样的技术支撑能力。
这个图其实已经很能说明问题了,我再稍微啰嗦一下:
上面谈及的四个能力,应该如何获取?下面我们就掰开了揉碎了讲一讲。
首先说基础硬件环境,显然有两种选择,上云 or 自建,如果是政策有要求必须自己折腾,那没有办法,以政策为准。如果可以自行选择,现在这个时代,大概率是上云更合适,除非公司体量很大,机器量很大,自建才可能有优势。注意,我这里说的是才可能,算成本的时候切记要把人力成本算上,别只算了硬件的成本。
关于择业:对于系统运维工程师、网络运维工程师,看起来并不是个好消息,云的出现确实抢占了一部分这类岗位的空间,没办法,时代的车轮滚滚向前,大家都是历史的尘埃。
再说组件,比如MySQL、Redis、MongoDB、Kafka、ElasticSearch、Nginx、Kubernetes等等,显然有3种选择,使用云上PaaS产品 or 自己折腾 or 自己出硬件+供应商出方案和服务。针对每种选择,我们分别做一下点评:
关于择业:各组件的资深老炮,第一选择是去云厂商工作或创业输出经验,第二选择去自建组件的大厂,普通中小厂,很难有高薪资,毕竟第三方的专家服务性价比不低。
业务研发最常做的变更是二进制、配置的变更,当然,还有对基础环境以及组件的变更需求。
我们先说二进制、配置的变更,怎么做才能又快又安全的迭代呢?可以分阶段,公司还比较小的时候,不用太关注工具的建设,只需要定好规范和流程即可。规范方面比如:部署在哪个账号下,哪个目录下,日志怎么放,进程怎么托管,任何变更必须能够可回滚等等,流程方面比如:变更通报机制、多模块协同上线机制、无法回滚的需要有审批机制等等。
然后,需要有历史变更的量化数据,比如某个团队最近一个季度有多少次变更,回滚率如何,故障率如何,各个团队有个对比,做的不好的团队就会在下个季度好好改善的。
当公司继续变大,就可以投入人力做变更类的平台,把规范制度落实到平台上,产出量化数据,因为不同的公司情况各异,在传统的物理机虚拟机时代,很少看到有商业化的变更系统。当然,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拍板,授权运维一号位来牵头,各个业务的研发一号位来配合,当然了,实际操刀的时候,运维一号位可能是找了一个得力干将来实操,各个业务线可能也是有技术一号位依仗的人来做接口人配合。
除了架构优化之外,其他这些事情都是横向的事情,是可以有一些方法论和最佳实践的,把大家拉通,有利于共享这些方法论和最佳实践。当然,有些人会有疑问:我们能否直接在研发团队找个人来组成这么一个稳定性的虚拟组织,共同推进这个事情呢?其实也可以尝试。不过会有这么几点问题:
划重点:事前的预防和风控,请各位CXO找运维总监要结果,但是必须给予极大的配合,从上往下推。对于搞定这摊事的SRE工程师角色,看起来是需要非常专业的高级别人士,工作5年以内大概率认知跟不上,或许,从资深研发团队招SRE是一个不错的选择,各位CXO可以尝试下。
一旦故障发生,我们的首要目标就变成降影响了。相关团队立马协作起来,快速定位直接原因、快速止损,事后再慢慢排查根因即可。这里会涉及如下一些工作内容:
OK,上面洋洋洒洒一片,回归问题,针对这块工作内容,CTO找谁要结果?我的建议是:SRE团队(文中多次出现运维、SRE字眼,在本文中基本都代表一个意思,这里的运维不止是Operations)。显然SRE无法搞定所有的故障,应该说大部分故障都得借助其他团队的人,但是CTO总不能一会找A团队一会找B团队吧。所以,SRE要携CTO的尚方宝剑,牵头整体的稳定性建设,各个业务需要出接口人极力配合,所谓的稳定性建设,包括事前的预防风控、事中的统筹协同、事后的复盘推进,这也是SRE对公司的最大价值。
这个内容很多,比如用什么机型套餐比较合适,用什么组网方式比较合适,用哪些组件公司具有更好的掌控力、可以得到更好的支持(不管是内部团队还是借助第三方供应商),公司推荐甚至要求的编程语言、框架是什么,业界推荐的接入层方案是什么?变更方案是什么?可观测性怎么做?等等等等。
不可否认,牛逼的业务研发团队,这些实践方式是门清的,但是同样不可否认,业务线多了之后,水平是良莠不齐的,水平差的团队势必需要教练角色的人,总不能啥事都去找CTO吧,SRE团队作为一个横向的技术团队,特别适合负责这摊事。但是显然,这是一个高端职位,新瓜蛋子干不来,招聘高阶人士做业务BP是推进技术栈趋于统一的有效手段,如果CTO用不好这个抓手,技术体系会百花齐放,后面则是各种治理困局。
上面的四个支撑能力,业务侧应该如何获取,CTO应该如何统筹,各团队应该如何配合,大致就说这么多。下面我们再做两个小结。
显然,CTO不需要亲力亲为,但CTO要做好把关,CTO要颁发政策,是全军统帅。横向的工作落给SRE团队,各团队出接口人极力配合,大概率是个最佳实践。如果把横向的工作目标完全打散到业务团队自闭环,就无法享受到横向团队带来的经验传播能力。而且,屁股决定脑袋,不在其位不谋其政,各个业务自己容易有小九九,中心的横向组织也是一个削藩机制,抱歉这个词用的重了,本意是好的,你要自己体会啦。
另外补充一点FinOps的话题,FinOps也是一个横向能力,是否也要交由SRE来做呢?这个倒是未必。就让业务自闭环我觉得也挺好的,业务自己要负责盈亏,IT支出是支出大头,业务的GM理应是很上心的,CEO把营收净利相关的KPI压给业务GM,业务GM可以自闭环做好折中的。
如果没有太高的职级和薪资期望,做一些相对基础的Operations工作也是可以的,10年内这个岗位大概率不会消亡。如果对职级和薪资有更高期望,先深扎某个细分领域,做到行业专家,是一条行之有效的路径。再之后,则讲究多个技术方向的融会贯通了,又要往广度发展。再之后,创业或者高管。
秦晓辉,Open-Falcon、Nightingale 创业研发,极客时间《运维监控系统实战笔记》作者,公众号 SRETalk 主理人,快猫星云创业合伙人,创业方向是稳定性保障方向,如有需求欢迎联系我做交流。
以上是从CTO视角来看:如何搭建运维/SRE能力的详细内容。更多信息请关注PHP中文网其他相关文章!