SRE成长的故事

这是在一家创业公司里的SRE逐渐成长的故事,写给运维以及想成为SRE的同学。

创业公司意味着人少事杂,就技术团队而言,意味着2个运维一个测试,30个开发,向一位技术总监汇报;

创业团队往往灵活,开发兼职测试偶尔做或干脆做成了产品经理。而运维,除了业务代码之外,和技术沾边的似乎都要做,如果不多提醒自己,稍不留神就会在3平米的写字楼机房网线间迷失自我。因此运维更愿记住的是,每天晚上几个开发代码写完跑过来围着运维喊着“开搞”、“卧槽”、”在我本地好好的呀“,”是不是没更新成功?”,顺利的时候他们说的那句:脚本挺6啊。

创业意味着可能撞上风口,老板更活跃了,业务妹妹的妆容更加精致了,当然团队加班也更多了,2台物理机终于不够用了……

一段时间后,运维在某数据中心对着一排排的机柜洋洋自得,此时开发团队已有百人规模,运维也终于多出一人,得益于此,开发上线也终于有了一个页面,不再需要找运维跑脚本了,大家各自沉浸在自己的领域。

顺利的话,再过一段时间就有各路牛人、大神的加入,有海归博士,也有从大厂高管,对技术的应用自然也一定跟上,云计算,大数据搞起来。这时有两个可能,一个是运维组织升级,落地云计算,接手大数据,成为技术团队里更加重要的量级,另一种,是大数据架构师内部培养或带来一位专门做大数据的运维同学,形成两块。

有句歌词说:“想要死去后让一切重来”,如果有一个可能功成名就的项目给你做,你一定会对其投入最好的资源,并且这些资源只给该项目。包括产品、开发、测试、甚至运维。毕竟这可能是一个改变世界的项目,说不定要独立一家公司运作,那就得用更高的规格来实施这一切。

新招的运维可能没有心思和你一起去做dns,cmdb,proxy,平台等等,他有自己的一套东西,拿来即用,没有的再用你现成的,看好自己的一亩三分地即可,轻轻松松何乐不为。

竖井便这样开始形成。

苦口婆心是脆弱的,show me the code,技术的力量或说是趋势的力量,当docker,mesos,k8s兴起,当应用被封装到镜像中被自动部署,故障后自动重启,机器宕机后自动漂移,运维人员的应用部署工作如虎添翼,不出一年,集团所有无状态应用都可轻易实现容器编排。而当初计划改变世界的项目经过1年的封闭开发之后,终于不温不火的上线,也不自觉的也跑在了统一的容器编排系统中,运维再次合并统一。

竖井竟就这样消失了。

接着业务如期发展,开发团队规模达到500人左右,运维部早已消失无踪,取而代之的是IAAS组、PAAS组,容器技术让PAAS再次兴起并成为现实,运维活跃于两组之中,之所以是PAAS组是因为开始开发PAAS产品,提供容器云平台级的产品,有了专职开发人员介入和他们共同去做之前打包、做镜像、部署、追踪日志、埋探针等工作。

终于要说到本文的主角了,SRE,这些团队中专门写云平台解决运维问题的开发人员算是SRE吗,还不是,他们缺乏运维经验、系统网络技能,他们也不对业务稳定性负责,更多是对云平台产品的稳定性负责。

那么一块做起云平台接口开发的运维算是SRE了吗?SRE不是即懂运维又懂开发,现在他们挺像了。

是像,但还不是。先回到公司的故事上。

业务壮大了,接近1000人的开发人员,业务线林立,产品众多,得益于容器等技术促成内部平台的建立,运维能力并未在各业务线独立各自为战,但这不代表平台足够强壮。

越是大规模的团毒就越需要底层的稳健,当业务快速发展,技术创新和稳定性存在很大的潜在冲突,尤其是人手不足的情况下,接近1000人规模的开发团队,需配备多少运维呢?除了不参与业务的2个网络工程师、2个机房工程师、3个大数据运维,竟只剩下4人。

容器虽是利器,但也需要充分掌握它的人才能更好发挥,否则反而可能误伤自己——容器平台复杂度持续上涨,学习成本高,自然稳定性要遇到挑战。

与此同时领导也发现技术与业务部门的矛盾,技术部门有很多资源,但又都各自为战,业务方着急却又用不好,想实现一个功能需串联许多个组,体验不佳,成本很高。于是致力于将部门内资源整合,对外输出统一服务能力的组织诞生了(当时叫SPG),特种部队吧算是,带着所有技术能力(IAAS,paas,saas,安全)对接业务线,变被动为主动。

而运维,则在那时对应的成立了CRE团队,做的几个改变是,第一,运维开发人员停止参与容器云产品的开发,高压情况下即写产品又维护底层是两边都无法保证,让产品开发团队关注上层业务逻辑。第二,运维开发人员编入CRE团队,关注底层组件稳定性和底层功能扩展支持。第三,招聘,人手严重短缺,得尽快补充血液。

啥是CRE? 就像线上发生重大故障,业务中断了,最牛逼的不一定是现场排查定位解决,而是马上用各种手段先恢复业务,有时即便破坏现场。我们知道,提升稳定性不一定非得要开发运维样样精通,从流程、沟通、意识上面下功夫也是可以提升起来的,毕竟公司希望要的是:稳定性、开发人员对云平台的满意度提升。CRE便是这样的一个角色,Customer Reliability Engineering,强调云平台与客户价值利益的共享,随后再细说。

为什么是CRE不是SRE?

  • 招不到人,SRE在国外流行,国内也刚开始不久,技术门槛高,短时间内招不到合适的。

CRE的行动策略是:

  • 先易后难,从稳定性提升角度出发把所需工作罗列出来,挑选其中可立即执行的先做起来。(如流程、沟通、协同、信息同步等方面的提升)
  • 综合输出,CRE整合IAAS、PAAS、安全的能力以解决方案形式对外输出
  • 挑客户,SRE也强调不会确保所有应用的高SLO,CRE资源也是有限且需对方配合的,所以会将其投入在最关键业务线中。

产出是:

  • 变更流程优化,线上所有变更全部按照标准流程走:变更及回滚方案、测试用例、同伴Review、关联人员通知。
  • 解决方案白皮书,整合多小组能力对外综合输出时选出最佳、最常见的使用方案
  • PRR,既然要CRE对业务稳定性负责,那业务在上线或重大变更前便需通知到CRE,提交PRR做审批和记录
  • 值班机制、巡检自动化等的落地,一主一备,备份人员只负责紧急联系主责任人
  • 复盘机制,所有线上故障均做复盘,每次都会产出一些TODO list便是接下来的重点工作

那这样就能解决了吗,当然不是,部分人员去做CRE先去救火,才能在内部腾出时间给SRE快速把生产中的关键问题梳理出来,解决一部分减轻整体压力;一个不恰当的比喻,如打仗,当我方因武器上处于弱势,想赢得胜利除了一部分人去外面硬抗,另一部分在喘息之余必须加紧修复枪炮,以支援前线。

如果团队中没有这样的SRE,那就需调配人员过来支援,就像敏捷文化也强调团队成员需要保护一样,Google的SRE实践里也提到,当SRE开始陷入大量手工作业时就需要专门的开发团队过来支援,以维护好50%的开发、运维平衡。

后来一些组织架构调整,SPG被取消了,但CRE留了下来,还陆续招到两位优秀的SRE,再随着时间的积累,前线压力降低,二者合作越来越多,形成正向循环,一些善于学习总结的CRE也就有机会成长为真正的SRE。

完了吗,我觉得没有,我理解的SRE应该不仅对云计算了如指掌,还在开发架构,性能、安全等领域均有造诣,还要有丰富的经验,这样才能担负起直到业务系统进行稳定性保障的责任。

但谁说要一口吃成个胖子了,还是那句话———慢慢来。

这便是在一家创业公司里SRE逐渐成长的故事,写给自己,写给那段时光:)