终结这个话题:运维岗位真的不能干了么?
昨晚马驰和来炜在线交流,话题是运维岗位真的不能干了么?我作为主持人,既是点火的又是拉架的 :) 听两位老兵分享了一些他们各自的观点,受益匪浅。今天抓紧记录一下,以免忘记,算是对昨天直播的一个复盘。
关于工具平台
工具平台会取代一部分人工,这个其实是显而易见的,无需多言。
但是工具平台谁来构建呢?这个值得捋一下。监控系统、CI/CD的平台、混沌工程的平台、中间件服务等,都是Platform,由Platform Engineer来构建,简称PE。PE显然是拆成很多小组的,每个PE小组负责有限的几个平台。这些零散的PE小组整体可以组成一个大的团队,比如叫基础架构团队,也可以拆到多个团队,比如跟工程效能相关的PE小组放到一个部门(比如效能工程部门),数据库、大数据相关的PE小组放到一个部门(比如数据部门),稳定性保障相关的PE小组放到一个部门(比如运维部)。
这个组织的划分,不同公司可能不同,关系倒不是很大,关键是PE团队应该怎么开展工作?PE团队核心要做好以下事项:
- 构建好用的平台,让业务研发团队来自助服务
- 平台要沉淀最佳实践。平台需要满足业务,但也要有业界最佳实践,理论上,如果业务需求和业界最佳实践相冲突的时候,尽量应以业界最佳实践为准,如果短期实在无法做到,也应该制定分步落地的计划,争取未来要做到,否则个性的东西、反模式的东西越来越多,Platform侧就会越来越难受,最后不堪重负,推倒重来,一地鸡毛
- 要想方设法使用平台来落地规范,而不是用规章制度来落地规范,马驰举了一个例子挺好的,他们有个规范,是要求业务程序不能利用本地磁盘存储状态数据,他们没有把这个作为红线法令颁布,而是明确告诉业务方会定期重启容器,让容器漂移!其实用过aws的人应该知道,aws的虚机有的时候也会莫名重启,面向不可靠的基础设施提供高可用的应用程序,本就是应用研发人员的职责
- 需要COE(领域专家)来指导Platform的演进,因为擅长数据库的架构师未必擅长Hadoop,擅长Hadoop的架构师未必擅长可观测性系统,擅长可观测性系统的架构师未必擅长混沌工程。
但所有的Platform都不是一蹴而就的,如果还没有这些Platform,怎么办?公司应该先去招聘COE,让COE来一边做业务顾问,一边建设Platform的能力,业务发展很快,Platform自研太慢,也可以寻求外部供应商的解决方案。甚至COE本身,都是可以寻求外部解决方案的,视情况而定。
关于外部供应商
大家直观上会觉得:欧美的公司更乐于采购SaaS服务,国内的公司更乐于基于开源自建。是不是因为国内的公司理念不行?不尽然。国内很多领域缺少靠谱的ToB企业和产品才是最核心的问题。试想,如果某个ToB公司可以为甲方提供:
- 优秀的、先进的方法论
- 稳定的、易用的产品
- 优秀的、稳定的客户成功团队,帮助客户更好的落地最佳实践
- 价格上,比甲方自己招聘人员自研更便宜
只要CXO脑子没坏,肯定会选择引入这样的外部供应商。但是这样的ToB公司有么?这是个大大的问号。我们创建快猫星云公司,为客户提供可观测性产品,力争成为这样的供应商。希望业界ToB同仁一起努力!
延展一下择业问题,虽然某个细分领域可能现在还没有很好的供应商,但是3年以后呢?5年以后呢?国外是不是已经率先有了?国内是不是有潜力不错的供应商了?如果已经有了,兄弟,你还敢继续投身在这个细分领域么?是否应该早做一些打算?
当然了,对于未来的预估,我们通常过于乐观,也过于悲观,对时间的预估,通常预估的超前,也预估的滞后。道理如此,兄弟,就看你怎么判断了。
关于应急故障处理
应该由研发来OnCall故障响应?还是运维?这个问题很有意思。马驰认为,线上80%的故障跟变更相关,变更是研发做的,研发显然更熟悉,让研发来OnCall故障响应,就意味着,80%的问题研发可以更快的响应。
业务研发如此,数据库变更、基础网络变更、接入层的变更,都是同样的道理,做变更的那个人来响应自己的服务的故障告警,看起来是比较合理的。
实际上,这取决于两个前提:
- 监控、可观测性做的足够好,变更导致的问题能够通过这套平台及时发现,大家加油,希望每个公司都有一套完备的可观测性体系
- 变更引入的问题是即时体现的,有些变更引入的问题如果一周之后才出现,做变更的人也很难怀疑到自己头上
其实我们可以分两种情况对待,变更之后的服务稳定性监测,本就是这个做变更的人的分内之事,日常OnCall是另一个场景,单独对待。那日常OnCall应该由谁来做呢?应该是那些可以直接参与故障定位、止损的人,道理很明显,如果OnCall的人收到告警还需要去联系别人,那这个故障止损的时效性就太差了。
所以首先,应该对告警分门别类的处理,不同的人OnCall不同的告警。所有的告警都交给研发或者都交给运维,这种绝对的做法是不合理的。
关于变更发布
最终目标是有共识的,就是让业务研发可以自由发布版本,但是我们又希望受控,希望安全的发布,希望在发布的同时保障业务连续性。这就对CI/CD的系统提出了极高的要求。
如果不管不顾,变更系统的底层就是去一批机器上批量跑个脚本的事情。但是附加了上述这些要求之后,就困难了很多,变成了一个系统性工程。
业务研发侧,需要做好埋点可观测,需要监控类的系统能够及时发现问题,甚至告警之后自动阻断发布流程。需要有一些蓝绿发布、金丝雀发布的手段落地,需要有些自动代码扫描、安全扫描的能力,工具体系不完备,一味地要求研发确保变更可回滚,确保变更安全也是不合适的。CI/CD的能力水平如何,基本可以看出这个公司的技术实力。
如果你所在的公司,还是研发给运维提单,运维去线上操作,要掂量一下这么做是否合理了哈。当然,上面的做法更多的是偏互联网的做法,未必适合所有的公司,这个直播也只是提供一个思路,你要自行斟酌。
当然了,这个理想的情况怎么达到?在这个理想的情况达成之前应该怎么一步一步走过去?时间问题,直播里并未探讨。如果公司的业务适合跑在Kubernetes上,用Kubernetes来构建这么一套体系是相对容易的,可以尽快行动起来。如果公司的业务必须跑在物理机、虚拟机环境,那就先搞一个统一的变更发布平台,然后哪里缺失补哪里,逐渐完善了。
关于成本优化
两位嘉宾谈的不多,不过大家对这个事情都非常慎重。提醒大家:
- 人比硬件贵,千万不要做花费了5000万的人力,节省了4000万硬件成本的事情
- 要给业务留出足够的冗余算力,如果资源用的太过紧张,该批的预算不批,因为容量导致故障的话,客户体验受损、舆论不利,得不偿失
- 可笑的例子是,用3000万买量,为了节省300万的硬件成本,没抗住量,真的就呵呵了
小结
现在这个阶段,平台体系还没有那么完备,使用自助Platform+COE+BP(Business Partner)的架构来搭建运维体系看起来是靠谱可落地的。未来Platform足够好的的时候,可以缩减BP人力(BP也慢慢具备了COE的能力),Platform继续完备,可以继续缩减COE,再之后,嗯,运维和研发可能就都不需要了吧。