我在小米负责一个叫做 Pegasus 的开源存储系统,这个项目在我初接手的时候是三个人,写作这篇文章的时刻已有四个人。Pegasus 是在 15 年就立项开始做的,而不过是今年才转到我手上。

一个存储系统,怎么做项目?

我并非从0开始,这点有好有坏。我们的起点:

1. 成型的开发+运维体系。此时 Pegasus 已有数百张表,平均每秒百万级请求量,可以说是初具规模。配套运维工具虽然粗糙但也算齐全,功能上也可谓是五脏俱全。其中所有开发均由 Pegasus 团队负责,运维团队仅负责线上操作,这是传统的 Dev/Ops 体系。

2. 开发已步入上升期,即核心功能已基本完成,公司内部也拥有了不少忠实用户,此时需要通过规模化,继续挖掘痛点。因此 OKR 上,我们使用 “feature pool” 来规划项目,通俗地说就是项目负责人维护一个大池子,有人空闲就把池子里优先级高的任务分派给他。

3. 两个老人一个新人。可谓是乞丐级团队配置。由于贵部门注重人员精简高效,Pegasus 经历了数次拆分,将部分核心人员输出到新立项目上,因此起点稍显寒酸。

总体而言,这样的一个起点意味着:1. 服务可靠性要求高,为了对得起忠实用户; 2. 产品深度要求高,毕竟核心功能的坑已填完; 3. 人员培养要求高,人越紧缺越不可放羊式管理。

面对这样一些问题,我们解决的核心思路是:

1. 思考可扩展的可靠性工程方法

简而言之,我们不希望事越多,人越多。通过自动化,科学化运维,减少运维人力,这是 Google SRE 的核心思想。

2. 思考产品的核心方向

一个存储产品应该聚焦在可靠性性能两个主轴上,这两个主轴延续在系统的整个 lifecycle,是两个永远做不完的 OKR。分主轴思考,这是一种自顶向下 (Top-Down) 的思维模式,原来 “feature pool” 的项目规划方法是一种自底向上 (Bottom-Up) 的思维模式。

feature 是短期的,暂时性的 (虽然也是长达数月的),一旦做完了,这个 feature 的生命周期几乎就结束了,我们不会再继续投入人力,除了少量维护工作。对于小伙伴来讲,从一个 feature 到另一个 feature 的过渡过程,与其说是游戏里从一个关卡进阶到下一个关卡,不如说是从一个游戏切换到另一个游戏。因为他始终在 “feature pool” 里游走,而非纵向前进。

所以说,feature 之间绝不能缺少主轴。例如 Pegasus 曾经同时投入了 4 个新人(包括我)做客户端(SDK)相关的工作,但始终没有产出一个用户接口的负责人。易用性也是一个主轴,但除了项目负责人外,团队里应该有人对易用性(或者说接口)负责,这需要针对性的培养和接班机制。当时在接口上 Pegasus 做了一个如今看来值得争议的决定,我们决定实验 MySQL on top of Pegasus,以支持 SQL 接口。虽然 SQL 的易用性毋庸置疑,且 TiDB 的火热也带来了一波 NewSQL 热潮,但从工程来讲,Pegasus 的易用性这条轴还大有提升空间。而由于缺少 Top-Down 思维,我们难以判断当前的 key-value 接口处于易用性路线图的什么位置,这就造成了路线的迷失。

3. 思考人才的培养路径。

如今 Pegasus 已规划了可靠性和性能两个大轴,易用性和开源两个小轴。如果管理者仅仅如此声明,那么团队人才很难自主地思考路线,他依然感知不到 Top-Down 和 Bottom-Up 的区别,因为他仍是被动接受工作。

那该怎么办呢?我们要将合适的人,分配到合适的轴上。要强调,让其专注于一条轴,从轴心思考问题,解决问题,从而主动进行路线规划。我们现在正在实践这个思路,典型的例子是可靠性这个轴:我们实验 SRE 机制,让 Pegasus 的运维负责人和我共同主导可靠性。

Pegasus 历来使用 Dev/Ops 分离的管理方式,运维在配置上虽然服务于 Pegasus,但实际上许多自动化运维开发仍然由 Dev 进行,这使得运维只负责线上操作,恶性循环下,运维与开发合作松散,两方效率并下。

在想清楚可靠性的主轴后,我便与运维同学共同推进可靠性路线图,例如监控梳理,自动化机器管理,自动化资源申请(集成在小米内部的融合云平台)等。最终,在两个月内我们完成了多个可靠性 feature,而这些经验仅集中在两个 SRE 人员身上。经验就好像游戏里刷怪练级,有限的怪让越少的人打,他们的升级就越快。

未来或许我们会在可靠性,性能,易用性上继续实行负责人机制。


文章到这里就结束了,路还很长,我们走的还很短,还有很多事情需要沉淀。这里夹一点私货:【小米生态链战地笔记】这本书给我对项目管理启迪颇深,这是四两拨千斤的典型案例:少数人做一个产品,比如小米电饭煲。专注,精确定位,不花精力做除了做饭外的功能。效率,极低的利润率,往往能逼出更高效的团队,让每个环节都有效率的提升。放权,占资不占股,不经营超大部队,而是放权让小部队自己抢食。

对我们软件产品道理也是一样:专注,不自己瞎造需求。效率,每个人头都要照顾清楚。放权,积极地让小伙伴负责一条主线工作,不大包大揽。