小基础设施团队的分工思路

三年时间，我们基础设施团队从1人变成了现在的4+1人小队。同事戏称之为“西天取经四人组”。我首先得申明：我没有在几十人的纯运维团队待过，以下内容，只是我个人经验，仅供参考，学习。

现在想想，就因为我没有受传统的运维团队的洗礼，反倒成了我的优势。

基础设施团队的职责

基础设施团队的职责是什么呢？我常常对其他小伙伴说：除了业务开发，我们什么都要做。

在说这句话时，我忘记了大家对于“业务开发”的理解是不一致的。也存在一定的误导性。

以至于真正的业务开发人员认为：他们只需要懂业务和CURD，而软件工程基本通识，如构建工具的知识、网络的基本知识、网关的基本认知、监控的基础知识、什么是持续集成、什么叫单元测试，他们一点都不需要懂。

换句话说，我认为是软件工程的基本通识，而业务开发并不认为是（时间久了，我发现，这些知识对整个行业似乎都不是通识）。

当你跟他们说，这是“软件工程的基本通识”时，他们会跟老板说：学习成本太高了，业务开发人员就应该只需要懂业务开发。（你该如何反驳这句话呢？文章最后有说明）

这个认知上的偏差可能导致的问题有：

业务开发人员认为基础设施人员就是一个被“指使”的团队，而不是一个协作的存在。整个软件行业似乎都是这样的一个风气；
业务开发开发出来的东西：不可测、不利于部署、不可监控；
基础设施团队人力不足，他们也就没有了时间去做有意义的基础设施升级。

正确的认知应该是：

业务开发人员不应该只要懂业务开发。他们还必须具体最基本的“软件工程基本通识”。比如持续集成是什么、云原生的基本原则、如何做到程序的可测性和可部署性等；没有这些软件工程基本通识，开发出来的软件质量是打折的；
基础设施团队和业务开发人员是协作的关系，只是分工的不同。分工的目的是为了达到整个团队乃至整个公司的最高效率。基础设施团队的部分工作也可以让业务开发人员完成，比配置方式的升级、为应用增加监控指标等。

这个认知偏差，我花了很多时间去纠正，效果甚微。走了很多弯路。现在看来，更合理的做法可能是：

从最上面的人的认知开始改变：即让最有权力的人给你站台；
培训所有人基本的软件工程通识。甚至在所有新人入职时就强调基础设施团队的职责；

说回我们一开始问题。基础设施团队的回答应该是：基础设施团队的职责是提高整个团队及至公司的软件工程效率和软件的可用性。同时，我们也要说明：软件工程效率和软件的可用性是需要所有人的协作的，并不只是基础设施团队的事情。

团队内部怎么分工？

前面，本质上说的是如何在基础设施团队和其它团队之间进行分工。现在我们讲一下团队内部该如何分工。

分工是一把双刃剑。分工太细，会导致资源浪费，因为并不是每种工都时时刻刻有活的。分工太粗糙，导致工作相互推诿，因为活的边界并不是时时刻刻清晰的。

这3年，我基本没有对团队的3人（包括我）进行细分工。我更希望团队内每个人都能成为独挡一面的能手，又能主动成为leader。

但是，我们该如何分工呢？工作总要分到一个个具体的人身上吧？以下是我们这3年的经验。

把所有的工作看作一个队列，三个人根据擅长+优先级两个维度进行分工。如下图：

同时，使用GitLab的Issue Dashboard进行协作。每个人完成任务后，另一个人负责进行check。通过这个check的过程，让另一个人成为backup。这个check的过程才是看板管理的核心。没有这个过程，看板会成为摆设。

如果硬要我说3年里，以上分工方式的不足，我会说：应该在团队里尽早将”不强制分工，但是强调每个人的主要工作方向“这一理念传送给团队里的每个人。

底层运维向左，业务运维向右

根据经验，可以把基础设施团队可分成底层运维和业务运维两个方向。那么他们具体是做什么的？

底层运维：他们负责操作系统、虚拟机、硬件机器、基础网络等的管理
业务运维：他们负责服务的CICD、监控告警、业务应用的架构等

但是我们也强调底层运维并不是不能做业务运维的活，业务运维并不是不能做底层运维的活。

工作没有贵贱高低。业务运维必须将尽可能多的工作进行自动化，让底层运维也能接手。底层运维必须尽可能将工作文档化，让业务运维也方便协作。

招更多人？

3年里，虽然我们有理由，也有机会要求更多的人，但是我们基本没有主动要求更多的人。原因：

我们认为团队就应该少而精，不希望招来一个人后，我们还要招另一个人来管他；
我们的工作理念（Everything as Code）和用到的技术栈，很难招到人；
我们希望业务开发也参与基础设施的建设，比如可观测性的库的实现、配置管理、自动化测试等。我们始终强调，基础设施是所有的团队协作的结果；
自动化做到一定程度后，就不再需要那么多人了。

小结

总结下来，3年里，并不是所有的人都会成为独挡一面的人，包括我自己。我至今不擅长做硬件方面、操作系统层面的底层运维。而且，我也没有强烈地成为这方面的运维人员。同时，从招聘方面来看，能独挡一面的人太少了，我们几乎没有遇到。那么，我们在管理更大型的团队时，应该如何分工呢？这是本篇文章留下来的问题。

如何反驳业务开发人员

当他们说“业务开发人员就应该只需要懂业务开发”。你可以反问业务开发人员：Git是不是业务开发的知识？既然它不是业务开发，那你们为什么要懂Git？如果答案都是肯定的。那么“业务开发人员就应该只需要懂业务开发”，就不成立。网关的部署你可以不关心，但是，网关的概念，你是不是业务开发，你都需要懂。

往期好文推荐：

另类的思路CMDB建设思路
经验谈：如何培养团队使用看板的习惯