高效的技术团队-序

如何打造高效的技术团队总结：
在来途家的三年里面供应链后端研发团队完成了对交易系统、接入、C端、B端高并发的请求的架构设计。从系统的清晰化定义到支撑起峰值的6000QPS。实现真正高可用、高并发的架构。
1、业务熟悉：所有对历史系统的重构都必须从熟悉业务开始。在2017年3月到2017年8月的时间里面。开始深入了解供应链相关的系统，包括.net、java、等30个web服务的熟悉。期间还支持一些新的业务需求的开发。输出了整个交易系统的模型和系统架构。
将交易系统切分为中间层、搜索、报价、营销、订单、支付、结算、产品、库存、基础数据。
2、架构选型：在重构第一期采用模板化编程统一编码风格和工程模板，进行了相关的技术选型。采用熟悉的前后端分离架构，后端使用Spring+mybatis+redis集群+ elasticsearch+mysql 的基础技术栈。采用所有服务做到无状态，支持水平扩展，采用分布式部署。支持CEQ宫格的大流量接入，输出系统的架构图。相关的业务流程图。支持原有业务流程的同时做无缝迁移。当时30w商户做到无感迁移到新的交易系统。
3、业务模型和数据库设计：非标民宿的业务模型较为复杂，房屋就有200个属性分类达到7项之多：房源位置、房源概况、设施和服务、房源描述、房源照片、售卖价格、入住规则、资质验证。
4、编程阶段：统一监控、统一模板 Tmoniter和 ApiTeamplate 和APIRequest 和APIResponse 这些基础类能统一返回值风格和统一监控。我们可以用AOP 的拦截监控，但是那种太过统一，让人缺少意识，如果使用APITeamplate中key方式使人有很强的主动意识。核心接口一下就能分辨：AOP 拦截一般通过方法名称去生成监控例如：分页查询民宿接口时的方法名称。queryHotelPageList 如果使用接口名单查询的时候queryHotelPageList_time\queryHotelPageList_excepiton\queryHotelPageList_count 类似于这类。但是通过定制化我们可以是监控的key 的左右更加明确DUBBO_Query_Hotel_Page_List_Time\DUBBO_Query_Hotel_Page_List_Exception\DUBBO_Query_Hotel_Page_List_Count.如果还有类似Dao 层的定义。Controller层的定义都可以指定对应名称。有时候还需要加上特定的来源。B_DUBBO_Query_Hotel_Page_List_Time(B端查询门店列表)
5、测试发布阶段：Jenkins支持热部署，服务细分以后一定要做到热部署，开始业务量不大的时候，可以将机器的配置降低一些。后续方便升级扩容。每个应用使用多机房分布式部署，随时扩容。
6、线上运行监控：两部分：业务监控、服务器监控、数据库监控、这几块非常重要需要时刻紧盯。业务监控需要过滤无效监控。分时间段，设置不同的阀值。自建机房的对硬件监控和网络监控做到可视化。数据监控主要是还是大SQL 和慢查询的监控。避免业务直接的相互影响。
7、团队打造：一定要有核心的2个人以上代码高手、高效执行指定的计划、然后留住核心业务熟悉的老员工1-2个。其他成员停留在2年的水平就可以，这样子的团队能覆盖核心业务系统的80%，抓住这个80%后续的可以暂时放弃。一个系统能满足80%的业务场景就能有更多的时间做技术的优化和迭代。 有效控制团队成本。也能高效支撑公司的业务的快速迭代。一定不要太多牛人。来一帮都是牛人的人。代码各异、风格各异、开始没有问题对后续团队的成长和发展都不利。维护成本高。
8、团队分享：定期的团队分享主题可以是现有业务、员工原来业务架构的优缺点分享、新技术等的分享。第一能让团队1-2年的成员获得业务开发之外的成长喜悦。积累的知识也便于后续系统的跌停和维护。
9、定期的个人沟通和TB建设，人员不要太多。TB 建设20人左右能达到感情的增进。如果经常搞50 到100人的TB建设意义不是特别的大，这种能鼓励到员工，但是如果要打造高执行力、高效能战斗的团队就不太适合。在其他行业不清楚。但是在IT互联网研发中比较合适。一定要扁平化，算一下20*20就可以打造400人的技术团队。如果都能保持高效的战斗力是一直非常高效的军队。直接下手超过20个可能熟悉起来比较麻烦。
这些是简单总结相当于列一个提纲。后续对这些进行一个扩展。真正搭建高效的技术团队。