后端研发价值体现之如何将技术建设与业务结合

工欲善其事必先利其器，研发人员就像军队，除了勇气、忠诚，还要有先进的武器、装备。

笔者去年曾写过几篇文章探讨后端研发方向和技术团队管理，发表了一些拙见。事过一年，在日常研发之外也做了一系列新的尝试：尝试跨团队自组织推进大型项目、尝试研发提升产品研发迭代的工具、尝试团队轮换新方式、尝试大规模实习生招聘等。

经过这些实践，对后端技术团队的管理，以及后端技术团队的发展方向有了一些新的心得体会，特别是如何将技术建设与业务相结合方便有很深刻的体会，发现技术建设和业务可以和谐统一，而不是割裂。让技术建设更直接的服务于业务，不仅会让技术建设在公司范围内获得更大的认同度，获得更多的资源支持，也能够对业务有很大的支撑作用，将技术的价值扩大化，从而达到事半功倍之效。

后端技术建设也可以自下而上

去年微博 Feed 系统面临着峰值流量应对的巨大挑战，李晨事件导致短时间内 Feed 请求量翻了一倍多，导致 Feed 业务有几十分钟服务质量特别差，其他几次类似的事件也对系统有很大的影响，通过降级各种功能才没有把影响扩大。同时，由于目前 Feed 系统的机器规模已经非常大，成倍的扩容成本压力会很大，且由于峰值流量的出现并没有规律，所以大多数情况下机器使用率都很低。在这个背景下，在领导 @TimYang 的支持下，我们发起了基于公有云（阿里云）和 Docker 的混合云解决方案，在半年时间投入二十几个开发的情况，完成了一套混合云解决方案 DCP 系统，在春晚时为业务提供了千余台服务器的支撑，保障了 Feed、红包飞等业务很好的应对了春晚峰值。

这个项目首先是一线技术根据面临的问题和挑战，以及出现的技术机遇（公有云和容器技术的快速发展），发现通过这方面的建设不仅可以帮助业务解决日常峰值流量应对问题，也可以降低春晚应对的成本问题。往年为了应对春晚几个小时的峰值流量，微博要提前 1~2 个月就采购服务器，且服务器经常要空耗几个月左右时间，造成了很大的浪费。同时，由于机器规模是提前评估的，到春晚时即使发现流量可能更高，也没办法即使补充机器。这个项目思路抛出后就获得了微博研发中心总经理的支持，之后在业务负责人的支持和推动下又获得了老板的支持，从而实现了自下而上提供技术解决方案，然后自上而下进行了立项和资源支持。正是依靠各级领导的支持，项目才得以拉通多条专线，并制定了新的成本结算方式。如果单靠技术本身，每一块都极难完成。相信很多公司的技术改造还是技术部门单独立项推进，其实技术改造需要更多从对业务价值的角度去思考和拆解，可以根据业务的发展阶段以及业务的挑战确定当前比较合适的技术战略和技术关注点，集中精力去突破这些关键点就能实现技术改造与业务价值的统一。

这个项目的特点除了是自下而上发起，跟很多项目研发不同的另外一个特点是这个项目的开发人员来自多个平级的研发团队，并有来自成本采购、基础设施建设、安全、监控等多个兄弟部门的支持。一个项目由一个部门负责的优点是思路比较容易统一，且权责更明确。但缺点也很明显，一个十几个人的部门不可能调集一半人到一个改造项目，所以也没办法承担混合云这种 20 多人开发的项目。按照微博的发展阶段，很多简单、小的技术建设已经基本完成，接下来有价值的项目都是这种大投入、大收益的平台型项目。混合云的开发团队采取联盟的方式，由主要参与团队的经理组成一个 4 人决策小组，所有重大事项均有决策小组来确定。同时，每个部门的参与团队均负责一个相对独立方向，这样就能确保每个小团队的权责清晰。在这一制度下，混合云项目团队最多时集结了将近 30 号开发，为项目目标的达成奠定了人力基础。同时，由于参与开发的部门也都负责一些业务，所以项目在这些部门的业务落地时会获得很大的支持力度，能够帮助项目完成推广的第一步。当然这种模式要注意的是一定要明确各个团队的职责和收益，要在分配任务的时候就讲明白，这样才能打消参与团队担心最后没有任何收益的情况。

他山之石可以攻玉

可能是性格保守的原因，笔者对各种新的技术、解决方案总是比较谨慎，但对照了 Graphite 系统和之前自研的监控系统后，发现现有的成熟的、先进的方案是更好的选择。在去年年底，去硅谷做业务技术交流，更加明白技术没必要纠结系统是否自研、技术是否炫酷，而是借助哪些技术和方案能帮助业务更快、更稳定、更低成本的达成目标。而且只要有可以参考借鉴的系统，就尽量去参考、学习、借鉴和使用。

去年年底偶然的机会看了一篇介绍 AB Test 的一篇文章，介绍从 Google 回国创业的工程师参照 Google 的 AB Test 系统而研发的一套系统，看完之后顿时茅塞顿开。在之前的两三年我们团队曾多次尝试这个方向，并投入了最精锐的工程师，但最终都没法使用。而有了新思路之后，我们调集了三个工程师，在一个月左右时间就做出了一套新的 AB Test 系统，快速推广到业务后很受产品好评。同时，通过扩展这个系统，其他很多棘手的问题也得以很好解决。所以在新的一年我们团队的各种技术改造项目都更多参照兄弟公司、兄弟部门的先进思路和做法，多做竞品分析，并根据自己的业务场景和实际情况加以改造，最终形成适合自己的先进的解决方案。

制度建设与个别培养并进

去年的有段时间比较重视制度的重要性，年中的轮岗也采用竞选的模式，除了个别核心岗位外都是根据团队成员的意愿和竞选来确定的。这种方式的优点是让一些同学可以跨越式的成长，快速去负责一些重要的岗位，但也很快暴露出问题，有的同学有意愿而能力还没达到，贸然去负责不仅压力大，成果也不好。

同时，为了让团队建设标准化，采用了多支撑少干预的模式，能不干预小组的事务就不干预，希望借由竞争等机制促使团队很好的发展。当然最终也事与愿违，实际情况很不理想，不仅团队没发展好，还导致了人员流失。痛定思痛，核心点还是太理想化了，忽略了团队的发展阶段，在团队不成熟的时候就撒手不管绝非明智之举。而是要帮着团队逐步走向正轨，在负责人经验成熟、人才梯队合理、业务相对稳定之后再更多的授权，并借助制度进行支撑。

从这些事情可以看出理想是好的，但是一定要从现实出发，否则会焦头烂额。我们没有 Google、Facebook 那种层次的工程师，就不能贸然照抄他们的组织制度。组织制度总要适应团队的发展阶段，早期就更多人治，成熟后就更多制度化。

今年我们就开始根据小组的成熟度来确定授权程度，对于成熟度高的小组就更多授权，对于成熟度不够的小组则更多的直接干预，协助将小组逐步成熟化。同时，依据业务与改造的不同特点，我们业务方向更多采用传统的小组制，而改造方向则是项目负责制。改造项目有固定的项目负责人，但开发人员并不直接分配到各个项目，而是按项目的阶段分配人力。项目早期更多是项目负责人自行调研，做原型。当思路清晰了，需要大规模推进了，再将主要的开发力量集中到这个项目，并在项目完成后快速撤出。

小记

后端研发由于离最终用户较远，所以很多团队建立起来之后就很难有好的发展，微博 Feed 研发团队也遇到了这样的困境。庆幸的是，在业务负责人和领导的支持下，在团队全体成员的共同努力下，我们终于能够实现技术建设与业务发展的统一，并借助技术建设为业务发展培养更多优秀的开发人才。如果只有业务开发，而没有技术建设，技术团队就很难留人、培养人，最终也无法很好的支撑业务。只有技术建设与业务发展齐头并进才能实现技术建设与业务发展的双丰收，不断为业务发展提供强劲动力，也让团队的技术竞争力不断提升。

最后，在新的一年我们在业务方面、技术建设方面都有更多、更富有挑战的项目，欢迎有想法、爱折腾的各位技术大牛小牛们加入我们的研发团队，和微博 Feed 业务一同成长、发展。同时，我们对应的 Feed 大数据研发团队也在进行招聘，欢迎对机器学习、大数据感兴趣的同学投递简历，与我们携手共进，做一些年老时可以跟子孙吹牛的事情，不枉这大好青春。

关于作者

刘道儒，毕业于北京信息工程学院，现任微博平台研发高级技术经理、Feed 项目技术负责人，负责Feed 体系后端研发，先后在TRS、搜狗、新浪微博从事社区& 社交业务研发，专注于大规模分布式系统的研发、高可用等领域。他曾代表平台在2012 年主导了微博广州机房部署项目以及北京双机房部署项目。

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。