创业公司需要基础架构团队吗?[极牛编辑修改版]

关于「真格 · 极牛技术分享」

「真格 · 极牛技术分享」- 极牛为真格基金投资公司打造的定期技术分享交流活动,采用“微信群分享 + 线下沙龙”的方式,分享和讨论新技术优秀应用实践、知名创业项目架构分析、技术工具评测和分析等技术话题。极牛愿与真格基金投资公司一起努力,共同提高中国创业技术含金量,打造一流技术能力。

关于唐福林

雪球首席架构师,前微博技术委员会成员,微博平台架构师;Java 后端程序员,已经不写 PHP,C 和 Pascal 很多年;ACM/ICPC 和 NIO 比赛深度参与者。

技术交流欢迎在微博上关注我 @唐福林

炒股,理财,资产管理,量化交易相关,欢迎在雪球关注我 @唐福林 xueqiu.com/fulin


近期,在极牛举办的「真格 · 极牛技术分享」上,唐福林集中分享了在微博和雪球做架构师和带架构团队的经历,并且对创业公司是否需要基础架构团队这个问题给出了深度解答。以下是唐福林分享文字内容。

1. 基础架构团队到底做些什么

要解答创业公司到底需不需要基础架构团队这个问题,首先我们来来聊一聊基础架构团队的职能是什么。

基础架构团队到底做些什么?

  • 为实现业务功能:技术选型,决策
  • 为了更好的实现业务功能:引入新技术/做法,提供内部支持
  • 解决历史遗留的技术债务:发现问题,找出解决方案,并推动解决
  • 业务开发 与 线上运维 中间有很宽的“三不管”地带需要填充,还需要坚实的基础设施支持

架构组工作的特点有哪些?

  •  基础架构团队存在的价值是解决非业务逻辑的技术相关问题,没有产品或运营驱动
  • 从技术角度看,每个问题都有很多种解决办法
  • 这些问题一般都是重要不紧急,短期内不解决也不会崩
  • 解决这些问题带来的价值对于非技术人员(特别是老板)不是很直观

 

2. 基础架构团队是创业公司技术发展的必然产物

在“社会主义初级阶段”,还不需要独立的基础架构组。比如,一开始,1~3 人小团队team leader 自己做决策,出问题 team leader 解决,用啥语言?cache?db?上不上云?这些问题直接导致了团队后续技术力量的升级。

到了Demo阶段,也就是3~5 人小团队,这时候应该有个架构师了,技术问题就会留给架构师解决,比如用啥框架?第三方库怎么选择?

后期发展到上线阶段,大概是5~10 人小团队,可以分组了,每个组都要有一个架构师,解决的问题就变成相互之间怎么配合?怎么保持公共基础部分的一致性?怎么解决互相依赖问题?

做好了前期的准备工作,到了公司的发展阶段,技术团队变成10~30 人,就应该有专人负责基础架构了,主要负责业务无关的技术基础设施维护,服务化框架以及治理,上线的流程等一系列问题。

如果业务到了爆发阶段,有了30~100 人的团队,就应该设置专门的基础架构团队了,开始负责技术基础设施及服务,提供内部的 PaaS,或者 SaaS等。

最后到了100+人的“高级阶段”–平台阶段,应该设置平台团队了,将公司的主体核心业务功能做成服务,供商业化或创新业务使用。在平台内部设置架构组,提供高附加值的技术支撑,异地多机房部署,大规模虚拟化平台这些宏观上的部署和组建就要开始认真思索了。

 

3,基础架构能做的再好一点吗?

 

2012年,我在微博的个人的职责从工程师转变成了架构组的组长,最重要的职责从自己写代码,转变成了“如何创造条件让团队成员更好的写代码”。这一年,微博平台壮大,职责划分逐渐明晰,我开始真正从管理领导层面思考怎么才能让基础架构做的更好一点。

首先是怎么做的问题,最重要的要求是要主动多想,没有外力驱动的时候要自我驱动,提高主动性,寻求目标,进行自我评价,没有外力驱动,没人外人评价,我们很容易陷入一种自我满足的困境:看,我做好了,我做的很牛,这回肯定可以评个优,年底多发奖金了吧。

而实际上,大部分时候,我们做的都还不够好。这里的好有两层意思:从技术本身的角度评价,跟周边公司横向比较等等;另外,就是你做的东西有没有真正的完全解决问题,不是从做的人的角度看,而是从碰到问题需要解决的人的角度看,比如业务开发团队是不是觉得好用,是不是觉得这正是他们想要的?

其次在做事的态度上,要力往一处使,因为解决一个技术问题可能有很多种办法,基础架构团队的职责就是找出一种办法,并推行到所有适合的场合,在这个取其精华去其糟粕的过程中一定要见识一起改进,禁止另起炉灶。

做任何事都要讲求方式,做基础架构的方式就是用数据说话,找到合适的评价数据指标,比如写了一个牛B的rpc框架?到底好不好,好在哪里?

另外很重要的是对于选人的要求,要能耐得住寂寞,尤其是在业务爆发式增长时,基础架构团队更需要耐得住寂寞。组建一支牛B的基础架构团队,让业务开发人员跳槽到另外一家公司以后,还会想起你们的好。所有从 Google 出来的人,都会怀念 G 家的内部基础设施。

对创业公司来说,基础架构极其重要,尤其是小的创业团队应尽早安排一个“架构师”的职位,招聘或内部培养一个架构师,如果发现一个架构师忙不过来,那就是时候扩大成一个基础架构团队了。

漫谈基础架构团队的价值 [分享稿文字版]

漫谈基础架构团队的价值
@唐福林 weibo.com/tangfl
陆续在微博和雪球做了几年的架构师,也带了几次基础架构团队,因而在多个场合被问到类似创业公司需要基础架构团队吗”“基础架构团队怎么招聘,如何管理一类的问题。于是前些天在极牛举办的「真格 · 极牛技术分享」上集中分享了我做架构师和带架构团队的经历,以及我个人对架构团队的价值的理解和思考。现将分享的内容整理成文如下,请大家指正。
  • 关于我
     首先简单介绍一下我自己:
    • 雪球首席架构师
    • 前微博技术委员会成员,微博平台架构师
    • Java 后端程序员,已经不写 PHPC  Pascal 很多年
    • ACM/ICPC  NIO 比赛深度参与者
    • 技术交流欢迎在微博上关注我 @唐福林 weibo.com/tangfl
    • 炒股,理财,资产管理,量化交易相关,欢迎在雪球上关注我 @唐福林 xueqiu.com/fulin
  • 微博平台架构组经历分享
    • 2010年底加入微博平台部
      • 当时名称为微博开放平台
      • t.sina.com.cn 为两套独立体系

Description: weibo.png

     左边是当时的 t.sina.com.cn,内部一般称为主站PHP 写的。右边是我们的基于 Java  API 体系,当时称为 OpenApi,因为我们当时主要面向外面的第三方开发者,为他们提供 open apiOpenApi 主站之间通过 Queue 互相同步数据。微博当时选择的是内部开发的 MemcacheQ,简称 MCQ 。这种模式下最大的好处是互不影响,最大的问题呢,就是数据不一致,甚至业务逻辑不一致。
     当时我个人的职责是重构和维护微博短链接服务t.cn 。事实上,我最开始接手项目的时候,还是 sinaurl.cn,是用 PHP 写的,我拿过来用 Java 重写了一遍,正准备上线,老板说要把域名换成 t.cn,然后我就一通狂改代码。当时平台内部容器都是用 Tomcat 6,短链项目是第一个尝试用 Jetty,但后来失败了又换回 Tomcat 了。
     这一年最大的收获是:学会了怎么写好的业务实现代码。
    • 2011年微博平台化
      • 统一一个平台底层,为上层 OpenApiWeb主站和无线App端提供 api
      • 平台负责稳定性,性能和扩展性

Description: weibo2.png

     当时我的个人职责是负责引入Redis来实现计数器和关系缓存功能。微博大约是国内第一家大规模应用Redis 的公司了吧,到2011年底的时候,我们已经部署了超过100台服务器,总计超过8T的内存。我们有自己修改过的RedisCounter专门用来高效的存储计数(用户的关注数粉丝数,每条微博的转发数,评论数,赞数等等)。我在Jedis client 的基础上包装了内部使用的客户端,增加了大量的异常处理,HAFail Fast等功能,还开发了一个支持滚动删除旧数据的 Redis 集群功能。
     这一年最大的收获是:学会了怎么设计并实现一个大的模块功能,做到高可用,以及如何应付高并发流量。
     PS,这也是我现在给创业公司推荐的架构,后端HttpHttps Rest Api,优先推荐Java技术栈实现,Cache 推荐使用RedisDB推荐使用Mysql,前端WebAndroid iOS、微信公众号等等都独立实现,或者共享某些 H5 页面。如下图所示

Description: commonArch.png

 
    • 2012年,平台壮大,职责划分
      • 用户关系
      • 内容
      • 私信IM
      • 公共:通知,提醒,导航 etc
      • 架构
     当时我个人的职责从工程师转变成了架构组的组长,最重要的职责从自己写代码,转变成了如何创造条件让团队成员更好的写代码。那一年微博平台架构团队最重要的几个产出包括:
      • 新版聚合框架 poly
      • redis 二次开发
      • 多机房同步队列 weibus
      • 数据管道firehose
      这一年,我最大的收获是,在摸索中逐渐理解了基础架构团队应该做什么,应该怎么做,并且逐渐的学习如何带基础架构团队,如何为团队中的其它人创造更好的条件,帮助他们写更好的代码。
    • 2013年,微博高可用改进
      • 压测平台 touchstone
      • 平台SLA体系
      • 平台多机房隔离部署
    • 2013年,微博平台服务化
      • RPC 框架 motan
      • 服务化治理体系:config servicetrace 系统,monitorCI & CD
     2013年因为人员变动,我从架构组组长空降到用户关系组任组长。虽然换到了业务组,但还是主导了平台的多个重大技术改造项目,比如压测平台touchstonerpc框架motan,以及motan上线后的服务化治理体系。
     这一年,我最大的收获是,从业务组的角度观察架构团队,更清晰的感受到了架构组的作用和价值,也更深的理解了架构组如何做项目,如何将项目成功落地推广。
    • 2014年,微博上市
      • 商业化:各种商业化需求支持
      • 成本缩减
      • feed流性能优化
     2014年主要的技术工作是feed流性能优化,和成本缩减。在feed流性能优化项目中,我负责探索从 App 客户端到 PHP 再到 Java Api 再到 Cache 最后到 DB 的全链路耗时监控统计;而成本缩减项目最后演变成了 Docker 应用预研。后来我离职后,Docker 的应用转交给用户关系组的接任组长继续进行了。
     这一年,我最大的收获是,学会了从更高层(部门,公司,甚至行业)的角度去理解基础架构团队的工作,去决策做什么,以及更重要的:不做什么。
  • 雪球平台组经历分享
    • 2015年,雪球首席架构师
      • 上半年牛市:性能优化,可用性改进
      • 下半年熊市:大数据平台,推荐,反垃圾,流式计算平台
      • 对外分享,招聘面试
      • 对内建立技术规范,上线流程
     在2015年底,雪球基础架构组升级成了平台组。当前负责维护雪球内部多个重要服务,包括用户关系服务,IM服务,搜索服务,大数据平台,推荐服务,反垃圾服务,以及开发流程和代码质量改进等等。
     这一年,我最大的收获是理解了基础架构团队在不同的公司中,以及公司的不同发展阶段的差异,包括价值观,做事方式,评价方式等等。
  • 基础架构团队的价值与思考
首先来聊一聊基础架构团队应该做什么
    • 做什么
      • 为实现业务功能:技术选型,决策
      • 为了更好的实现业务功能:引入新技术/做法,提供内部支持
      • 解决历史遗留的技术债务:发现问题,找出解决方案,并推动解决
      • 业务开发  线上运维 中间有很宽的三不管地带需要填充,还需要坚实的基础设施支持
从团队发展历程的角度看
    • 一开始,1~3 人小团队
      • team leader 自己做决策
      • 出问题 team leader 解决
      • 用啥语言?cachedb?上不上云?
    • Demo阶段,3~5 人小团队
      • 应该有个架构师了
      • 技术问题架构师解决
      • 用啥框架?第三方库选择?
    • 上线阶段,5~10 人小团队
      • 应该分组了
      • 每个组有一个架构师
      • 怎么配合?怎么保持公共基础部分的一致性?怎么解决互相依赖问题?
    • 发展阶段,10~30 人团队
      • 应该有专人负责基础架构了
      • 业务无关的技术基础设施维护
      • 偏技术的
        • 性能,高可用等等
        • docker
        • HadoopELK
      • 偏工程的
        • 重构
        • 服务化框架,治理
        • 公共第三方依赖管理,升级:jvmtomcatlog4j
      • 偏运维的
        • trace 系统
        • monitor
        • alert
        • 线上开关系统
      • 偏流程的
        • 开发流程规范
        • 代码质量保证:UTcode review
        • 上线流程:CI & CD
    • 爆发阶段,30~100 人团队
      • 应该设置基础架构团队了
      • 技术基础设施即服务
      • 提供内部的 PaaS,或者 SaaS
        • DB / Cache / Queue Service
        • 虚拟化平台
        • 大数据平台
        • 流式计算平台
    • 平台阶段,100+ 人团队
      • 应该设置平台团队了
      • 平台即服务
      • 将公司的主体核心业务功能做成服务,供商业化或创新业务使用
        • 用户服务
        • 帖子服务
        • 商品服务
        • 评论服务
      • 在平台内部设置架构组
      • 提供高附加值的技术支撑
        • 异地多机房部署
        • 大规模虚拟化平台
    
     再往后?我也不知道,大概是设立研究院之类的吧
    • 架构组工作的特点
      • 基础架构团队存在的价值是解决非业务逻辑的技术相关问题,没有产品或运营驱动
      • 从技术角度看,每个问题都有很多种解决办法 
      • 这些问题一般都是重要不紧急,短期内不解决也不会崩
      • 解决这些问题带来的价值对于非技术人员(特别是老板)不是很直观
    • 怎么做
      • 最重要的要求:主动,多想
        • 没有外力驱动:自我驱动
        • 没有产品KPI:自己寻找目标
        • 没有外人评价:自己评价
        • 有哪些要做的,哪些应该先做,哪些应该延后做
        • 最后一公里:我能做的再好一点吗
     没有外力驱动,没人外人评价,我们很容易陷入一种自我满足的困境:看,我做好了,我做的很牛,这回肯定可以评个优,年底多发奖金了吧。而实际上,大部分时候,我们做的都还不够好。这里的好有两层意思:从技术本身的角度评价,跟周边公司横向比较等等;另外,就是你做的东西有没有真正的完全解决问题,不是从做的人的角度看,而是从碰到问题需要解决的人的角度看,比如业务开发团队是不是觉得好用,是不是觉得这正是他们想要的?

 

      • 做事的态度:力往一处使
        • 解决一个技术问题有很多种办法
        • 基础架构团队的职责就是找出一种办法,并推行到所有适合的场合
        • 觉得不满或有意见?一起改进,禁止另起炉灶
      • 做事的方式:数据说话
        • 找到合适的评价数据指标
        • 写了一个牛Brpc框架?到底好不好,好在哪里?
        • 服务质量数据指标三板斧
        • qpsp99响应时间,error rate
      • 选人的要求:耐得住寂寞
        • 业务爆发式增长时,基础架构团队需要耐得住寂寞
        • 业务不增长时,基础架构团队更需要耐得住寂寞
    • B的基础架构团队
      • 让业务开发人员跳槽到另外一家公司以后,才想起你们的好
      • 举例:所有从 Google 出来的人,都会怀念 G 家的内部基础设施
  • 简单总结
    
     简单总结一下,结论就是
    • 基础架构很重要,应尽早安排一个“架构师”的职位,招聘或内部培养一个架构师;如果发现一个架构师忙不过来,那就应该扩大成一个基础架构团队了
    • 架构师自己要有想法,知道要做什么,知道先做什么,知道要做成什么样
    • 架构师自己要动手写代码
    • 架构团队不能离业务太远,要适当负责一些底层业务
    • 用数据说话,不仅架构团队,整个技术团队都应该这样
 
啰嗦了很多,回过头一看,自己感觉还是有些凌乱,大概是自己也还有很多没有想清楚的地方吧。欢迎大家就这个话题一起来讨论。