Open cjuexuan opened 5 years ago
今天是一篇务虚一点的文章，分享下我对建设一个小规模的中台团队的一些实践，大概从17年底我这边就开始负责我们数据工具团队的相关建设，我们大数据平台部下面有四个开发团队，一个是负责基础设施的，一个是负责可视化和早年负责数据收集的，一个是流计算和元数据系统的，最后一个就是我们，我们大概负责的范围有数据计算平台，调度系统，可视化，权限系统，早年我还做过一个通用的监控系统，在基础设施团队组建之前我也负责基础组件的性能优化，这一块目前都移交给基础设施团队了。 我这边目前的组成是五个服务端。像可视化项目组还有产品，专职前端，测试投入进去。其他项目的话，主要的产品经理还是我们开发自己了:-)。 我们一路走过来大概遇到的问题我这里列举下
16年当我一个人solo的时候其实也没什么流程化，17年有个小伙伴加入了团队，然后他去维护xql，我开始写spoor，当时我们其实也就设计过一下，其他没有什么太多的沉淀的流程，对于代码来说，刚开始几次我还帮他review，后面忙起来（懒）也不怎么看，周会当然是不存在的了，隔着一个座位该讨论的早就当场讨论了。
到了17年年底，我感觉spoor这边我一个人忙不过来，所以又招了一个小伙伴和我一起做spoor，新的小伙伴来了以后我们就有三个人了。这个时候我发现大家时不时帮客户解决一些比较诡异的问题（需要半人/天以上，需要跟踪源代码），而且由于大家做的东西不一样，又对对方做的东西比较感兴趣，所以我们就开始了固定的周会环节，在周会上每个人会分享一下自己本周的工作，这里的分享大概有分享排障过程，演示功能，分享一些新技术等。总体的效果还是非常不错的，只不过花的时间会比较长一点，如果团队再大一点（5人以上），可能也不适合这么弄了。
到了18年我这边又接了调度系统和可视化系统的业务，这样我这边就有4个小伙伴在一起工作了。人多了之后，大家会有自己的一些代码风格，但是在一个repo里面工作，还是需要做到风格的统一，所以大概在这个时候我们开始进行merge request。刚开始做merge request的时候还是比较痛苦的，主要是标准没完全确定，另外一个问题是大家都喜欢找我帮忙review代码，因为他们觉得其他人不一定很熟悉这几个系统，而且我review出的问题也比较多，所以让我压力也很大。我们在做系统的时候都是尽量去掉单点，到review这边也是一样要去掉这一块的单点，所以我们又组织讨论了下，决定发展每个系统有一个第二责任人，然后第二责任人一开始会review一些偏简单的feature，一些不确定的代码可以找多个人一起讨论，所以这一块也得到了比较大的改善。 刚才说到一个代码风格的问题，因为我们主要都是scala，所以我在我们开发的内部scala构建插件里把scalafmt和scalafix封装进去了，新项目创建就自然引入了我们的标准配置。测试这一块的话，我们主要通过gitlab-ci来做，代码提交进来了首先会跑单元测试，当代码被合并到master分支之后，会触发测试环境的构建，会把测试环境用master的代码重新部署一遍，这样就大大降低了人工介入去部署的时间了
由于我们团队主要是中台团队，服务的业务线非常多，所以每天有各种用户来咨询你各种问题，比如如何接入你们系统，出了问题能不能帮忙排查下，能不能帮忙确定下技术方案的选型等。而且我们团队也维护了好几个二方库，导致我们每天花大量的时间在答疑，小伙伴们普遍也觉得这种工作方式很枯燥。这一块我们在19年还是得到了很大的改善，首先我们再三强调文档的重要性，并且文档是要和项目一起持续迭代的。一些新的特性，faq一定要及时的同步到文档中去，帮别人解决问题前先看文档中有没有，如果没有的话，解决完问题一定要及时的同步过去。这样就把给每个人重复一遍变成了你解决一遍，后续出现都是靠文档帮用户解决。另外我们也准备开始搞答疑轮值制度，每个服务周期内有一个小伙伴对外提供技术支持。客户有可能会在调度系统中遇到一个问题，先问了调度系统的小伙伴，排查下去发现是调度系统调用计算平台出了问题，接下来又要问下负责计算平台的小伙伴，沟通和交流的成本变得比较高。所以我们想通过轮值和问答机器人来简化这部分的沟通成本，轮值的好处是让其他小伙伴可以更专注于feature的开发。第三点是我们也要在业务团队培养一些专家，来帮我们承担中台的技术支持工作量，这件事是双赢的，对于业务团队来说，业务团队内部通常是坐在一起的，当面沟通的成本小于钉钉沟通，也小于他们需要过来找我们。对于我们来说，有人帮忙承担了技术支持的工作，可以让我们更专注产品的开发
最后一个就是设计和历史遗留的坏代码的改造了，对于这一块的工作，我们目前每周会有一个小伙伴去找我们的一些坏味道的代码，然后在周三之前发到小组的群里，请大家一起考虑如何优化，然后周五开周会的时候我们会花一部分时间用来过这一块的优化。这里需要注意的是一定要提前发出来，代码的重构都是需要相对安静的环境进行思考的，如果开会当天现场去想，很难想到一些特别好的方案。因为坏味道代码也没那么多，如果这周轮到你你找不到坏味道的代码，那可以换成设计问题，或者算法题。通过这种方式让大家能更好的沟通和交流，团队的技术氛围也会变得比较好
代码相关：
技术支持相关：
开篇
今天是一篇务虚一点的文章，分享下我对建设一个小规模的中台团队的一些实践，大概从17年底我这边就开始负责我们数据工具团队的相关建设，我们大数据平台部下面有四个开发团队，一个是负责基础设施的，一个是负责可视化和早年负责数据收集的，一个是流计算和元数据系统的，最后一个就是我们，我们大概负责的范围有数据计算平台，调度系统，可视化，权限系统，早年我还做过一个通用的监控系统，在基础设施团队组建之前我也负责基础组件的性能优化，这一块目前都移交给基础设施团队了。 我这边目前的组成是五个服务端。像可视化项目组还有产品，专职前端，测试投入进去。其他项目的话，主要的产品经理还是我们开发自己了:-)。 我们一路走过来大概遇到的问题我这里列举下
我们怎么做
16年当我一个人solo的时候其实也没什么流程化，17年有个小伙伴加入了团队，然后他去维护xql，我开始写spoor，当时我们其实也就设计过一下，其他没有什么太多的沉淀的流程，对于代码来说，刚开始几次我还帮他review，后面忙起来（懒）也不怎么看，周会当然是不存在的了，隔着一个座位该讨论的早就当场讨论了。
到了17年年底，我感觉spoor这边我一个人忙不过来，所以又招了一个小伙伴和我一起做spoor，新的小伙伴来了以后我们就有三个人了。这个时候我发现大家时不时帮客户解决一些比较诡异的问题（需要半人/天以上，需要跟踪源代码），而且由于大家做的东西不一样，又对对方做的东西比较感兴趣，所以我们就开始了固定的周会环节，在周会上每个人会分享一下自己本周的工作，这里的分享大概有分享排障过程，演示功能，分享一些新技术等。总体的效果还是非常不错的，只不过花的时间会比较长一点，如果团队再大一点（5人以上），可能也不适合这么弄了。
到了18年我这边又接了调度系统和可视化系统的业务，这样我这边就有4个小伙伴在一起工作了。人多了之后，大家会有自己的一些代码风格，但是在一个repo里面工作，还是需要做到风格的统一，所以大概在这个时候我们开始进行merge request。刚开始做merge request的时候还是比较痛苦的，主要是标准没完全确定，另外一个问题是大家都喜欢找我帮忙review代码，因为他们觉得其他人不一定很熟悉这几个系统，而且我review出的问题也比较多，所以让我压力也很大。我们在做系统的时候都是尽量去掉单点，到review这边也是一样要去掉这一块的单点，所以我们又组织讨论了下，决定发展每个系统有一个第二责任人，然后第二责任人一开始会review一些偏简单的feature，一些不确定的代码可以找多个人一起讨论，所以这一块也得到了比较大的改善。 刚才说到一个代码风格的问题，因为我们主要都是scala，所以我在我们开发的内部scala构建插件里把scalafmt和scalafix封装进去了，新项目创建就自然引入了我们的标准配置。测试这一块的话，我们主要通过gitlab-ci来做，代码提交进来了首先会跑单元测试，当代码被合并到master分支之后，会触发测试环境的构建，会把测试环境用master的代码重新部署一遍，这样就大大降低了人工介入去部署的时间了
由于我们团队主要是中台团队，服务的业务线非常多，所以每天有各种用户来咨询你各种问题，比如如何接入你们系统，出了问题能不能帮忙排查下，能不能帮忙确定下技术方案的选型等。而且我们团队也维护了好几个二方库，导致我们每天花大量的时间在答疑，小伙伴们普遍也觉得这种工作方式很枯燥。这一块我们在19年还是得到了很大的改善，首先我们再三强调文档的重要性，并且文档是要和项目一起持续迭代的。一些新的特性，faq一定要及时的同步到文档中去，帮别人解决问题前先看文档中有没有，如果没有的话，解决完问题一定要及时的同步过去。这样就把给每个人重复一遍变成了你解决一遍，后续出现都是靠文档帮用户解决。另外我们也准备开始搞答疑轮值制度，每个服务周期内有一个小伙伴对外提供技术支持。客户有可能会在调度系统中遇到一个问题，先问了调度系统的小伙伴，排查下去发现是调度系统调用计算平台出了问题，接下来又要问下负责计算平台的小伙伴，沟通和交流的成本变得比较高。所以我们想通过轮值和问答机器人来简化这部分的沟通成本，轮值的好处是让其他小伙伴可以更专注于feature的开发。第三点是我们也要在业务团队培养一些专家，来帮我们承担中台的技术支持工作量，这件事是双赢的，对于业务团队来说，业务团队内部通常是坐在一起的，当面沟通的成本小于钉钉沟通，也小于他们需要过来找我们。对于我们来说，有人帮忙承担了技术支持的工作，可以让我们更专注产品的开发
最后一个就是设计和历史遗留的坏代码的改造了，对于这一块的工作，我们目前每周会有一个小伙伴去找我们的一些坏味道的代码，然后在周三之前发到小组的群里，请大家一起考虑如何优化，然后周五开周会的时候我们会花一部分时间用来过这一块的优化。这里需要注意的是一定要提前发出来，代码的重构都是需要相对安静的环境进行思考的，如果开会当天现场去想，很难想到一些特别好的方案。因为坏味道代码也没那么多，如果这周轮到你你找不到坏味道的代码，那可以换成设计问题，或者算法题。通过这种方式让大家能更好的沟通和交流，团队的技术氛围也会变得比较好
总结一下
代码相关：
技术支持相关：