我这4年都做了什么

为什么要写这篇文章

昨天收到提名通过的邮件之后,就开始着手准备答辩PPT,但是思来想去,感觉要写的东西比较多,想要在20分钟讲完讲透,一时半会儿还挑不出重点,写PPT确实不是我的强项,干脆先都先用文字写出来,再从里面挑选重点内容放到PPT里面,也算是一种对这几年工作的全面回顾和反思,以后万一哪天不得不更新简历的时候,也能有点素材。
晋级可以不提名,可以不通过,但是不能不反思不正视自己的不足。权且把答辩当作一次面试。
刚毕业在华为工作,有一句话我印象非常深刻:“板凳要坐十年冷”。要成为大佬,就要耐得住寂寞,顶得住压力,眼光放长远,切莫急功近利。我比较鄙视的一种行为:挖个坑,晋个升,跑个路,循环往复。这么玩儿几次就把自己的技术声誉败光了,我对自己的技术声誉和职业道德还是有信心的,做项目的第一原则:尽量不给后人挖坑,除非真的到了我能力上限。
需要声明的是,如下项目除了前两年我自己做开发的时候自己动手做了不少事情,后面两年其实都是团队小伙伴们实际动手做的,我只能提出想法和规划,毕竟一个人的能力非常有限,项目的成功都是小伙伴们的功劳,项目做得不好,负责人的问题最大。

我理解的P5大佬应该具备的能力

公司要求和我的理解

【关键词】面:方法论,事业部内
  • 作为事业部内公认的某方面的专家,能够解决较复杂的问题或领导大中型项目;
    • 前面半句比较抽象,也不好自我证明
    • 后面半句更具体一些,我理解要么就是解决某一个专业方向的业界技术难题,以我略懂的云计算领域来举例,你要可以解决底层虚拟化性能问题,优化之后能达到业界领先水平,或者在提升计算资源利用率方面做到业界领先,或者在网络方面性能水平达到业界领先(而不是仅仅用开源跑起来),存储领域你就要对标业界主流开源项目的性能和可靠性(最好可以超越),或者你可以成为某个大型开源社区的core developer,甚至某个子模块的maintainer,或者中小型但比较流行的开源社区的maintainer
    • 就是要领导过大中型项目,这个我理解你要带领团队开发过一个完整的项目,我理解中型项目标准应该是5w行以上业务代码,核心功能模块3个或以上,大型项目则要超过10w行。这个标准可能实际还会更高一些。
  • 在本专业某主要领域具有精通、全面的知识和技能,是集团内公认这一领域的专家,在多个子领域的技术能力在集团内领先,在集团内作出显著创新;
    • 还是后半句更具体,我理解多个子领域的技术能力在集团内领先,这一点就要做到你主导的项目在集团内没有比你更好的解决方案,如果有,则表示你的技术能力不够领先;有一些公司有内部赛马机制(也有叫红军蓝军的),这种情况下就很容易体现出你的项目是否在集团内领先了
    • 在集团内作出显著创新,这方面参考创新奖申报条件,如果是集团外部或者业界已经用了比较长的时间或者成熟的方案,你只是在集团内部最先引入或者稍加改进,这不能算创新,创新要引领业界趋势,而不是简单的跟随
  • 技术成果对所在事业部的成功是重要的依赖因素;
    • 这个也容易理解,你负责的项目是否对事业部OKR有很好的支撑效果,项目的成功对事业部OKR会产生较大的正面影响,项目不成功会导致严重的负面影响。如果这个项目对事业部的OKR来说可有可无,那就要考虑项目存在的必要性和价值了,这方面做维护性的项目肯定是吃亏的
  • 能够解决复杂的问题或领导大中型项目;
    • 与第一条重复
  • 能够把握本专业的发展趋势,并是与本专业发展规划与业内发展趋势相吻合;
    • 这一点比较抽象,比较难自证,但是可以参考第二点,技术能力在集团内领先,并作出显著创新,如果不能把握本专业的发展趋势,就很难做到显著创新
  • 可以指导本专业内的一个子系统有效运行。
    • 参考第一点,能领导大中型项目应该就满足这条

我的不足

  • 在多个子领域的技术能力在集团内领先,在集团内作出显著创新;
    • 创新这块应该有些子领域做的还不错,还有个别领域正在做,但是落地成果还没有很好的体现,目前还处于推广初期
  • 能够把握本专业的发展趋势,并是与本专业发展规划与业内发展趋势相吻合;
    • 这方面跟上面一条有点关联,推广顺利的话就能证明趋势把握的是正确的,否则就比较难说
除了上面公司要求的不足之处外,我理解自己的不足还有如下几点:
  • 绩效不算好,近几年一直都是B+,原因我理解主要包括:
    • 前两年做开发,产出和落地不明显,抖动问题解决了之后,由于规模比较大,升级本身也会造成IO抖动,因此需要非常长的升级上线时间,当时效果还没有体现,并且Ceph项目是维护项目,确实也比较难出高绩效
    • 项目带的不好,主要是Curve这块,近两年一直都在开发新的文件存储功能,近期才刚刚开始落地,项目价值还没有很好的体现出来;另外块存储的性能优势也没有达成质的飞跃
    • NOS项目我认为做的还算不错,虽然也是维护项目,线上故障也有几次,但是近两年一直在进行微创新
  • Curve项目发展不达预期,尤其是开源社区建设方面,外部用户数量还不太多,这个原因有很多,最根本的还是我们内功没练好,功能也比较欠缺,用户想用也用不起来
所以这也是前面几次晋升提名我都没有积极参与的主要原因,这次也是感觉希望渺茫。

怎么弥补

  • 尽快把不足的子领域的推广落地效果拿出来,展示出来项目在集团内或者业界的创新成果和给事业部带来的收益。
  • 某些子领域项目的研发进度有些略低于预期,这与项目的复杂度和团队成员的构成有一定关系,也与个人的项目管理能力有一定关系,这2个方面要继续加强,提升团队战斗力和个人项目管理能力
  • 复盘,思考改进方向

基本信息

工作经历

2018.08-至今  网易/杭州研究院/技术工程事业部   资深服务端开发工程师
2017.07-2018.08  杭州云容科技有限公司   技术总监
2012.06-2017.07   网易/杭州研究院   高级/资深服务端开发工程师
下面是废话:
我这边情况比较特殊,属于“二进宫”,之前因为一些原因出去跟前同事一起搞了一段时间私有云平台,搞了几个项目之后发现有点搞不动(小公司的认可度、长期维护能力等客户都存疑),在外面一年后就又回到现在的部门。
17年出走那次是主管给我报名了P5的晋升提名的,不过我最终还是想出去闯一次,结果其实当时就知道90%是会失败的,不过不试试看总是不甘心的。所以现在的状况我也能欣然接受,都是出走之前考虑到的。
17年之前一直在做云计算平台相关工作,出走的原因之一也是因为平台已经稳定能做的事情不多,还是想在技术上有更多发展;原因之二是当时组里一位基友做线上升级的时候,搞出来一个大锅,我们几个小伙伴花了几个小时紧急修复之后,又折腾了几天几夜才算完成收尾,这让我倍受打击,当时也没啥心情参与晋升答辩了(感觉搞出来这么大的锅哪还有脸晋升),现在想想还是心态不够稳,没有历练出来,这几年明显感觉有进步,遇到线上问题至少手不抖了。
18年回来之后改做云存储,也是云计算的一部分。换一种方向也挺好,我跟之前的同事互相吹捧的时候,就提到过,云计算的3大底层模块,计算&存储我都能玩的转,何愁没有出路(年龄问题不考虑的话。。。)。上一篇文章我写过,工作就是为了赚钱,要么现在赚钱,要么以后赚钱,其实软件行业还可以加一条,要么可以延长职业生涯,做底层存储应该会有这方面的好处。
回来的时候前领导跟我交流,提到一点,就是这次回来能不能做的长远一点,我12年进公司,到17年正好5年,其实在这边工作真的挺好的(发自肺腑),有需求,有落地,有价值,还有好基友,否则也不会考虑“二进宫”了,去别的公司也可以混口饭吃。所以我“二进宫”之前就答应领导只要我还能干的动,部门还需要我,我还有价值,就能一直做下去,18年到现在也4年了,这一点我认为我做到了,不过我的工作还有很多要改进的地方,后续还会继续尽力改进。
近4年来,前面2年其实还是主要做ceph开发和维护工作,后面会有介绍。后面2年主要带存储团队,包括ceph在内一共3个项目,有的做的还可以,有的还需要继续努力,后面也会有介绍。做开发的时候,Ceph已经处于维护状态,而近2年Curve项目新开发的文件存储系统效果还没体现出来,所以我的绩效一直是B+,这个结果我是非常理解的,也清楚做到什么程度才能拿到更高的绩效,并且一直在努力推动落地。

申请理由

申请理由有点“自吹自擂”的感觉,但是还是要把重点工作产出实事求是的讲出来,否则其他人怎么了解你的工作价值?这一部分有很大的难度,因为内容很短,要求很精练,并且突出重点核心工作,我这方面做的不好,容易陷入技术视角,描述很多技术细节;另外还有就是不善于包装,我了解到商业化项目有很多架构师可以把一件不那么有技术含量的东西包装的很高大上来“忽悠”客户买单,这种能力在打单的时候真的是必不可少,在晋升答辩的时候肯定也有一定的效果,但不能过头要把握好尺度(反正我也不会)。
原始理由特别长,肯定不适合放在一个小文本框里:
  1. Ceph项目(2020年开始主导):
    1. 参与Ceph成本优化项目,2020年成本下降到2018年的1/6
    2. 参与Ceph块存储优化项目,通过规范运维标准化及配套工具,优化集群监控报警,块存储近4年未出现较大故障,基本没有SLA损失,云盘抖动情况显著改善,同时节省SA半个人力
    3. 参与并主导cephfs容器场景产品化项目,填补了k8s RWX PVC存储的空白,解决了传媒,严选,云音乐等部门共享文件存储的痛点,集群数量达到10+,业务数据达到xxPB+
  2. Curve项目(2020年开始主导):
    1. 推动Curve块存储业务规模发展,2年内集团内部存储数据容量从不到xxxTB增加到超xxPB,同时发展外部用户数家;近2年未发生集群级故障,性能和稳定性相比Ceph云盘有了极大提升了
    2. 带领团队完成了Curve文件存储的规划、设计及开发,数据和元数据相关性能均达到开源存储项目的领先水平,目前正在推广落地中
    3. Curve开源社区建设方面,推动Curve加入CNCF基金会sandbox项目、信创认证、PG数据库社区共建等社区建设工作,目前已有数位外部贡献者,以及数家外部用户,测试中用户10+
  3. NOS项目(2020年开始主导):
    1. 通过技术架构升级推动NOS内部降本,相比xx云OSS 9折甚至更低;开发上线1.2副本低频存储(xxPB)及冷归档存储(xxPB),为业务方节省大量成本
    2. 持续进行业务拓展(xx、xx、xx等),年营收增长达30%以上
    3. 通过主动为业务降本及共建等手段,持续提升业务方满意度,上半年更创新高;近2年SLA均超过99.5%
精简后的理由,总感觉没有抓住重点(也有可能是项目本身也没有什么特别的亮点):
  1. 带领Ceph团队支撑近千台规模Ceph块存储和文件存储产品,对Ceph进行较多定制化开发和性能优化,快速响应解决多次开源社区bug导致的故障
  2. 带领Curve团队持续优化性能并相比开源竞品保持领先优势;在Curve文件存储架构设计和开发落地、开源社区建设等方面成果显著
  3. 带领NOS项目通过内部降本、主动的为业务优化成本,项目的满意度提升显著,年存储数据增量30%以上,容量翻番达xxPB,为基础平台实现收支平衡贡献了较多的营收和利润,同时也获得了xx、xx内部新增大客户,以及外部商业化项目xx

业务贡献

Ceph优化

ceph团队规模,最多的时候有超过x个人,目前有x个人不到在做维护工作。我是18年中加入的,20年开始带团队。
这个标题一直想不好怎么写,因为是一个半维护项目,涉及到的组件或者服务也比较多,怎么才能在标题里把这个项目做的全部或者至少主要工作表达出来,非常有挑战,现在只能简单的写 Ceph优化。
上面申请理由里面提到了一些重点工作,这里再罗列一下(项目产出在成果那一节里面再写):
  • 成本优化:机柜整合,存储池整合,容量均衡,空间清理(社区bug导致集群topo信息额外占用了大量存储空间)
  • IO抖动优化:ceph的io抖动问题对业务影响非常大,而且很频繁,一直是业务抱怨最多的痛点问题,18~19年花了很大力气去优化,这几年已经有了极大改善(当然也有一部分原因是个别业务方做了一些日志异步打印等方面的改造)
  • 运维优化:ceph的运维工作,经历了3个阶段,首先是ceph开发团队自己运维,之后是sre/sa运维,最后又回归到了ceph开发团队,切换给sre/sa的原因是研发团队想专注做开发工作,运维毕竟不是研发团队的强项,后来又切到ceph开发团队的原因,也是ceph运维具有极高的复杂性和问题紧急分析处理能力,如果对ceph不够熟悉,定位分析时间长还只是一方面,严重的话会导致把问题放大进一步恶化,又扯远了。。。总之这块就是把之前要人肉凌晨2点操作的日常运维工作,全部实现了自动化无人值守(之前sre也做过类似工具,但是因为对ceph技术细节了解不够深入,导致了线上事故就没有继续使用),并且做到了不会造成IO抖动,这一点我认为是非常值得ceph团队骄傲的
  • cephfs共享文件存储产品化:ceph团队最开始只有块存储(rbd)项目在做,但共享文件存储需求在k8s集群的部分业务场景下是强需求(RMX的PVC),比如AI训练、机器学习、web服务端共享存储、分布式视频处理等,但是公司内部没有团队提供相关的存储系统,19年的时候ceph团队就把cephfs这个存储系统给产品化了,解决了多个业务团队的需求,后面还跟云音乐机器学习平台共建了几个高级特性,目前有10多个业务方生产集群在跑
  • ceph性能优化:通过改造ceph底层引擎以及增加扩展接口,提升ceph性能
  • ceph生产环境故障处理:面对几十个集群,这几年我们遇到过多次线上生产环境的故障,基本都是社区bug导致的(我们ceph团队开发的功能和运维操作,可以说没有引入过线上事故),从发现事故到业务快速恢复,即考验对ceph的掌控程度,也考验紧急情况下的团队合作能力,这一点我对ceph团队的小伙伴非常满意
  • ceph商业化项目支撑:ceph团队给轻舟、低代码、easyAI等业务也提供了很多poc甚至生产环境的L2支持(主要形态是共享文件存储和对象存储),帮助相关团队解决了不少技术问题;甚至还做了rgw对象存储的商业化尝试,另外也有一些集团内部业务自己部署的ceph集群遇到问题也会找我们解决

背景和必要性

Ceph这个项目最大的问题在于前两年处于半维护状态(近一年多已经是完全的维护状态了),那么项目的必要性就比较难描述,ceph是一个重运维的项目,但是如果没有人做这些事情甚至运维不及时,线上环境肯定早就出大问题了(我们做商业化项目的L2支持的时候,经常遇到poc环境甚至生产环境已经搞得一团乱了才来找我们解决),cephfs集群也不会扩展到10来个。
必要性我这里就按我的理解挑重点写几点吧:
  • 成本优化:这方面的必要性不用细述,都能理解,集团这几年的重点考核要求之一
  • IO抖动优化:这个涉及到业务方满意度甚至基础设施部的SLA,也是基础设施团队的重点考核要求之一
  • 运维优化:节省人力(否则每周2次的日常运维,都是人肉在凌晨2点做,通常耗时半小时以上,ceph团队一共就3个人肯定吃不消),另外可以减少人为操作导致的故障和IO抖动(运维流程标准化、工具化、可回溯),这也是团队经过长期运维实践总结出经验固化到工具里,工具刚开始用的时候也是人肉观察调整了一个多月才敢无人值守,就怕造成抖动或事故
  • cephfs产品化:这个也不用多解释,从0到1,解决了共享文件存储的业务需求
其实上面列出来的重点工作,每一条都有其必要性,毕竟维护项目谁也不愿意做无意义的事情,直白点说就是维护工作难出好绩效。另外很多事情都是业务方主动找我们做的,比如cephfs的产品化和云音乐goblin共建项目,没有cephfs他们就只能自己搭nfs或者自己折腾其他存储系统,并且要承受不可控的SLA水平。

项目挑战

挑战1:IO抖动问题优化

IO抖动的定义:云主机的云盘IO时延超过3s,会导致云盘的util 100%,业务会收到大量磁盘util告警,并且如果IO时延达到几十秒甚至分钟级,就会导致业务集群出现严重问题,甚至引发雪崩效应。
这里面其实包含了多个场景下的IO抖动问题,比如坏盘、慢盘、扩容、容量均衡、宕机恢复、网络丢包或者时延飙高、集群负载飙高等等,以及实施成本优化、运维优化的过程中也有很大可能造成IO抖动,为了解决这个老大难问题。
经过长时间深入分析,Ceph IO抖动问题的根源主要包括:
  • 部署问题:ceph monitor服务是整个集群唯一的中心化服务,正常情况下他不会对IO时延产生影响,但是由于最开始选型的同事没考虑到在异常场景下会导致恢复时间过长带来IO抖动
  • ceph本身架构问题:多副本强一致导致任何一个节点或磁盘的响应时间超过3s就会造成IO抖动,如果是彻底挂掉还好(配置的心跳超时时间在7s左右,IO抖动时间也基本如此),就怕心跳还偶尔半死不活,这种情况就会一直抖动,我们也尝试从代码逻辑层面做了一些优化(遇到半死不活就自杀),不过发现其他策略效果还不错,并且这种问题发生的概率比较低(也有规避手段),就没有打开相关配置(主要怕大面积误杀)
  • ceph代码实现问题:pg锁问题,peering流程问题,monitor负载问题等等
  • 运维操作流程问题:如果不能自动化运维,为了不造成抖动就要进行各种微调,导致运维耗时非常长,自动化才能解决此类问题
  • ceph底层性能问题:filestore存储引擎在大量删除文件和写入大量小文件之后的性能问题等等,因此后续我们上线的cephfs和nos ceph-ec集群全部都切换到了bluestore,也取得了良好的效果(当然也顶住了数据可靠性的风险,其实是偷偷上的,当时的团队负责人担心bluestore数据可靠性有问题不同意使用,在这一点上我们ceph团队的小伙伴还是非常给力的,做到了不给后来人挖坑)。

解决方案:
  • 部署优化:把monitor节点使用的hdd盘换成更高性能的ssd,并把大规模集群的混部的monitor服务独立到单独的服务器上,提升monitor单点性能,减少心跳上报、多副本之间peering过程中的排队现象,缩短异常场景或者运维操作过程中IO中断时间
  • 代码优化:peering流程优化,减少不必要的流程,极大降低了流程耗时
  • 日志和命令行工具优化:新增日志和命令行查询工具,精确定位抖动原因和所在磁盘,便于快速恢复和事后分析
  • 工具迭代优化:自动化运维工具迭代式优化,根据日志发现抖动问题是运维工具不完善造成的之后,持续微调工具操作流程细节(有人可能会问为啥不线下测试好再上线,如果线下小规模环境能复现,问题也就不那么难解决了),直到趋于完美
  • 引擎性能优化:我们基于filestore也做了很多的性能改进尝试,配置调优都已经上线,也取得了一些效果,但代码修改和缓存盘方案受限于文件系统性能限制,以及线上集群升级困难(数据已经在那里了,动不了),最终并没有落地
  • 监控告警完善:这个比较容易理解,我们基于日志和命令行工具,配合专用打桩机,对每个存储池、每台服务器、每块盘,都在哨兵上做了很多新的监控项,这些监控项配合哨兵告警能帮助我们第一时间发现抖动问题,及时进行处理,从此以后,再也没有出现抖动超过几分钟还没找到问题原因的情况,基本做到了抖动发生的几秒钟内就能发现原因
有了上述优化并上线之后,我们会通过日志和监控告警分析每次抖动的根本原因(我们有专门的wiki页面记录了数十次各类场景下抖动问题发生的时间点、影响时间、影响范围,这里就不展示了),这是做IO抖动优化专项攻坚之前从来没有深入细致做的事情,之前只知道做了什么操作或者发生了什么硬件故障导致的抖动,但是没有从底层ceph代码流程层面分析过造成抖动的根本原因并加以优化,如果经过分析发现是ceph架构造成的抖动无法优化(比如慢盘、raid卡故障、网络丢包等),我们也会补齐对应场景下的监控告警,可以做到第一时间发现抖动的根源,并及时上线进行处理。
优化前:
优化后:

挑战2:超百万行ceph代码的掌控问题

ceph最新的代码量已经达到180w行,即使是之前的版本,肯定也有几十上百万行,团队一共最多的时候就5个人,每个人20w行代码,做到深入全面的掌控肯定是不现实的。这一点不得不提华为,我当年在的时候,libvirt/qemu这种规模的项目,仍然是每个人负责一块,把所有代码都吃透(要有代码分析文档、要有内部代码走读分享),并且有KPI考核,他们最大的优势是人多,每个开源项目甚至十几个人在做,甚至一个驱动模块就有几个人负责,每个人就是一颗螺丝钉,会有半年时间全部给你分析代码流程,完全掌控之后再做版本开发。我们显然做不到这种程度,但是又不能不掌控,只能挑重点。另外还有一个方面的问题比较难解决,单纯的代码分析是没有绩效的,或者至少不会有高绩效,大家动力不足,更多的是凭个人的兴趣和主动性在做。
解决方案:
  • 从遇到的问题入手,把问题涉及到的代码流程吃透,并尽可能扩散覆盖到更多的流程
  • 从核心流程入手,把核心IO流程的代码吃透,遇到相关问题时可以快速深入问题细节,找到解决方案或者规避手段
  • 从版本社区已知bug入手,定期去社区bug tracker平台分析我们使用的版本新报告的bug,并深入分析bug产生的场景和相关代码流程,合入补丁时做到心中有数、举一反三
  • 代码责任田,每个人负责一块,比如monitor、mds、mgr、osd等
  • 团队内知识分享,每次解决的问题或bug都有详细的分析报告,并组织团队内部讨论分享,并通过学习分享这块考核进行牵引
在这方面,我们团队吴宏松做的很不错,他是我们团队最能静下心来研读代码的同学,也总结了非常多的流程分析文档,还有自己的知乎专栏,给Curve也做了不少引流。大部分时候你问他某某功能或特性的具体实现逻辑是什么样的?他都会回答,等我翻一下我的云笔记,我问他你怎么有这么多的总结文档,他说因为热爱,一有空就看代码。其实我知道,他是想成为业界大佬,好赚大钱(因为我也一样,你看我把curve代码流程大部分都理了一遍,虽然一知半解,但是也算能帮助外面的人入门)。

项目成果

  • 参与Ceph成本优化项目,2020年成本下降到2018年的1/6
  • 参与Ceph块存储优化项目,通过规范运维标准化及配套工具,优化集群监控报警,保障了近xx个块存储集群x百台服务器xPB业务数据,近4年未出现较大故障,基本没有SLA损失,云盘抖动情况显著改善,同时节省SA半个人力
  • 参与并主导cephfs容器场景产品化项目,填补了k8s RWX PVC存储的空白,解决了传媒,严选,云音乐等部门共享文件存储的痛点,集群数量达到xx,存储机x百台,业务数据达到xxPB+
在ceph现有集群的维护方面,团队里马杰同学真的是劳苦功高,基本上一个人扛下来了所有集群的问题处理(相信使用ceph的团队应该都跟他打过交道),知识面也非常宽,还乐于学习新技术,开发了不少运维自动化工具、监控脚本、部署流程文档,也做了不少功能增强,比如回收站功能,也受到非常多的外部同行关注。curvefs的CSI工具也是他快速“糊”出来的,他就是我上一篇怎么管理团队的文章里写的效率高但质量意识稍差的代表,但他可以快速迭代,发现问题及时改掉,人的性格有差别,只要用对地方,每个人都有自己的优势。

总结复盘

做的好的:
我们针对IO抖动问题攻坚,总结出来的核心方法论就是:对症下药!先找出来准确的问题根因,再讨论解决方案并验证效果,反复迭代优化,才有了Ceph集群近两年的平稳运行。
这一块工作我认为做的还算比较到位,即使复盘重来一次,唯一需要改进的就是应该更早的开始攻坚解决这个问题,但我18年刚来就开始做了,也没办法做的更早。
需要改进的:
如何用较少的人力掌控超大型开源项目,并落地到大规模的生产环境?这不仅仅是技术问题,还涉及到团队管理问题。这一挑战我们做的也有不太好的地方,主要是绩效牵引不到位,也没有这么多的人力、时间精力去做(半年时间不做业务只分析代码,这在我司有点不现实,但是华为就可以)。

Curve项目

背景和必要性

Curve团队我是20年中接手的,Curve块存储当时已经上线了,并且有了一定的量,这方面我做的工作主要是把容量从xxxTB扩展到xPB,并且保证服务可用性SLA超出预期,数据可靠性100%,另外一大块工作是性能优化相关,继续保持curve的性能优势。
这里重点讲一下Curve文件存储的背景和必要性。
内部需求情况:
自19年开始cephfs部署的xx个集群,几乎全部是用在AI训练场景的(广义上的AI,包括机器学习,深度学习,文本语音视频分析等),也有少量场景是web服务端共享存储和分布式并行视频编解码等。而openstack场景下的云盘需求基本没有增量,已经基本都被k8s取代,部分老业务在往k8s上迁移,新业务基本都在3.0云平台k8s上,存储需求一般是两种,对共享存储没有强需求的使用hostpath本地存储,有需求的则使用cephfs共享文件存储。
业务的第二个诉求是性能,提升存储性能对训练加速,从而提升GPU资源利用效率,也是为业务降本的一种手段。根据云音乐goblin机器学习团队反馈,现在cephfs的性能问题会导致部分训练场景下GPU利用率只有30%只有,亟待提升。
第三个诉求是降本,对象存储已经从3副本降低到1.2甚至更低副本冗余度,文件存储使用cephfs仍然以3副本为主,有很大的降本空间。常规手段是冷热数据分离存储,冷数据使用1.2副本甚至更低冗余度,热数据使用3副本,配合高性能热数据缓存层,按冷热数据8:2比例计算,可以节省50%左右的存储空间。另外集团在海外的业务拓展也在加速进行,海外没有专门的数据中心,也涉及到数据合规性问题,因此都是在云上部署,一旦要使用文件存储就涉及到比较高的费用问题,以aws的efs文件存储为例,其费用相比对象存储是非常高昂的(标准存储类型为例:$0.3/GB/月 vs $0.023/GB/月),因此如果可以在云上使用对象存储作为数据存储空间,可以为业务节省大量存储费用。
外部需求情况:
Ceph 2021用户调查报告显示,61.95%在ceph集群中使用了cephfs,cubefs则在今年进入了CNCF的孵化项目,juicefs的用户star数达到了6k+,curve用户群新增了数百个用户,其中大部分都有共享存储需求。minio是对象存储,但其在云上的发展策略也是值得curve学习借鉴的,他们在重点拓展公有云和混合云架构,这也是未来的存储发展趋势。
功能类别
功能项
juicefs
cephfs
cubefs
curvefs
备注
基础功能(主要对标)
POSIX 兼容
CSI插件
否*
curvefs csi插件开发中
元数据管理
第三方组件
数据一致性
close-to-open
强一致
close-to-open
close-to-open*
JuiceFS 确保了数据的高可靠性,在文件关闭时会将其同步上传到对象存储。curve一致性目标处在规划中
S3兼容引擎
自有S3组件
自有S3组件
juicefs为各家对象存储厂商提供了独立的驱动层(用的是各家的专有SDK,curve用的是aws s3的sdk对接所有厂商)
客户端缓存
内存、硬盘
无客户端缓存
3.0版本支持内存、硬盘缓存、3副本引擎
内存、硬盘、3副本引擎
juicefs商业版本支持单副本的读缓存
自有存储引擎
多挂载
目录配额
是*
是*
否*
juicefs、cubefs支持volume级配额,curvefs规划支持配额功能
多文件系统
是*
cephfs多文件系统支持不完善,目前以单文件系统用法为主
开发语言
Go
C++
Go
C++
认证、权限管理、多租户
否*
否*
curvefs规划支持,juicefs没有看到相关文档(操作过程中也没有看到类似参数)
扩展功能
内置stat工具
否?
文件锁
否?
否*
curvefs规划支持
HDFS兼容引擎
curvefs是否要支持待定
NFS协议
插件支持
curvefs规划支持
S3协议
curvefs规划支持,优先级低
HDFS协议
curvefs是否要支持待定
CIFS协议
插件支持
curvefs是否要支持待定
ceph rados引擎
curvefs规划支持,优先级低
fsck数据校验
否?
curvefs规划支持
对象分片合并
同一个文件反复随机写入的碎片整理
垃圾对象清理
需要调研与分片合并的区别(目前看是游离分片数据的清理功能)
内置benchmark工具
否?
多桶写入
/
/
否*
curvefs规划支持同一集群配置多个后端存储桶
元数据备份恢复
是?
否*
curvefs规划支持
高级特性
主动目录缓存
否*
juicefs为warmup命令,curvefs规划支持
数据加密(传输、静态)
是?
curvefs是否要支持待定
数据压缩
否?
curvefs是否要支持待定
跨集群数据同步
是指将阿里云oss(或其他对象存储厂商)某个桶中的数据同步到aws s3(或其他对象存储厂商)的某个桶,与文件系统本身的关系不大,类似rclone等第三方数据同步工具
快照
否?
否*
curvefs规划支持快照功能
回收站
否?
否*
curvefs规划支持回收站功能,https://juicefs.com/docs/zh/community/security/trash
内核态客户端
否*
curvefs是否要支持待定,https://juicefs.com/docs/zh/community/metadata_dump_load , juicefs支持自动定期备份
冷热数据分层
否*
curvefs规划支持,ceph cache tire更适合对象存储场景,cubefs 3.0版本支持了3副本和ec的分层存储
数据生命周期管理
否*
curvefs规划支持

项目挑战

挑战1:技术架构和应用场景

文件存储方向上怎么做出curve的特色?怎么从业界众多项目中脱颖而出?
存储系统尤其是文件存储已经有几十年的历史了,最早的NFS、到专用NAS设备,再到分布式存储系统(GlusterFS、LustreFS、CephFS、FastCFS、CubeFS、JuiceFS等等),每个都支持POSIX接口,这些文件系统有什么差异?在哪方面做了演进?文件存储后续5年甚至10年的技术架构和重点应用场景是什么?这些都是Curve需要回答的问题,否则怎么做到技术架构的前瞻性和创新性,怎么让未来最广泛的业务应用场景选择curve?
我们的答案:
我一直在跟团队小伙伴们强调一点,我们做CurveFS,一定不能做成第二个xxxFS,如果做成xxxFS,谁会来用,社区用户会对curve感兴趣吗,用户为什么要选一个完全没有特色的新项目而不是一个完全一样的成熟稳定的老项目?重复造轮子,就算大家以后出去面试,也没有什么值得吹嘘的东西可以给面试官讲。我想让大家做一些用户真正需要的东西,或者同类项目里面有优势的东西,让大家觉得这几年没白忙活,脸上有光,即使出去也能多赚钱。
Curve文件存储研发目标:
  • 高性能
  • 高性价比
  • 支持公有云部署
  • 支持混合云部署
  • 支持冷热数据分层存储及数据生命周期管理
  • 支持多级缓存
  • 完整的POSIX兼容性
这些目标也是我们经过反复讨论,调研,与社区用户交流,分析内部业务需求总结出来的,业界已有的存储系统,目前都没有做到具备上述全部的能力。
有了这些目标,还要匹配到业务场景,才能更好的落地,外面用户的情况我们可以了解也可以进行宣传推广,但没有内部业务的打磨,怎么保证你的项目是好用的、高质量的、能解决用户痛点的?一个好的产品必然要自己对上层业务有深入接触深入理解才能真正抓住业务痛点。内部业务场景在前面项目背景部分已经有了描述,CephFS已经有了比较多的使用,具体场景来看,主要就是AI训练,其他场景大部分都还是本地盘hostpath模式,既然网易互联网业务都是如此,应该可以推而广之,外面的互联网业务也不会有特别大的差异(非互联网业务我们接触的很少,不敢妄下结论),因此我们打算首先主推AI训练场景,有一定用户基础之后再推广到其他业务场景。
目前内部已经有AI业务上线使用curvefs,最吸引他们的就是成本,3台服务器共3块ssd盘(可以混部到其他业务机器上)就可以跑起来,后端用nos低频存储(1.2副本,比cephfs的3副本成本低很多很多,cephfs用的是8T盘,nos是18T,密度也高很多)。另外多媒体AI团队也在于我们共建,已经测试出来一些性能数据,更多的场景还在测试中。
团队里李小翠,在架构设计调研方面做得最到位,报告写得最详细,能把各个场景都考虑的非常细致全面,写代码一定是谋定而后动。

挑战2:如何保证Curve具备高性能优势

Curve块存储最大的优势之一就是高性能,与主流开源项目Ceph RBD相比,小文件随机IO性能远超RBD(时延也是有很大优势),大文件顺序IO场景与其持平。但是只做到这些肯定是不够的,在云原生数据库场景下,数据库对底层存储的性能尤其是时延要求是极高的(时延越低越好,就看我们能做到什么程度),如何保证Curve的高性能优势持续领先?这也是我们面临的一大挑战。
我们的行动:
Curve块存储:
  • 全链路瓶颈梳理
  • 大文件顺序读写性能优化
  • raft相关优化
  • 高性能硬件适配
Curve文件存储:
  • 元数据性能优化
  • 数据面性能优化
  • FUSE优化
  • 多级缓存
高性能硬件适配这方面的工作,还是得靠大佬出手,我们团队高级专家徐逸锋,绝对的实力派资深码神,与阿里多隆不相伯仲,相关适配已经在开发扫尾阶段,近期将会有测试结论。文件存储的元数据和数据面性能优化方面,团队里新秀王海和吴宏松也有不错表现。
上面每一项展开来写,都是一篇技术文章,感兴趣的可以看一下curve公众号文章,或者更早之前的文章在网易杭州研究院的公众号里。
CurveBS对大文件顺序IO的优化:
CurveFS元数据性能对比:
CurveFS数据面性能对比:

挑战3:如何提升Curve的易用性

原有的ansbile部署方式存在的问题
安装部署是一个软件的入口和门面,自20年中Curve开源以来,用户在使用ansible安装部署过程中遇到了各种各样的问题,还需要部署人员对ansible非常熟悉,并且要对Curve本身的部署架构有一定的了解,门槛非常高,首次部署的成功率非常低:
  • ansible本身的安装就比较复杂,依赖比较多的python库,而且我们还对ansbile的版本有依赖,导致用户安装指定版本ansible遇到了很多问题
  • ansible部署方式是通过二进制包方式安装curve,无法适配到不同的操作系统版本(依赖的glibc等基础库可能不兼容),要么在各个发行版上编译不同的二进制或者安装包,并且需要进行非常复杂的测试验证,工作量巨大
  • 安装过程易出错,不同用户环境下的Curve依赖没有办法全面检查到,我们内部使用的问题比较少,因为我们的操作系统和相关配置等都非常的标准化,外部用户则有非常大的差异性;并且出错之后定位分析困难,需要频繁的与用户进行沟通等待用户反馈,解决问题的效率太低
  • 扩容、升级等高级运维操作步骤繁琐易出错,不支持周边组件如tgt、pfs等的部署
我们的行动:
为了解决部署成功率、操作系统普适性等问题,传统的方案应该是在各个操作系统发行版上制作对应的安装包并放到安装源里,但是这种方案的工作量巨大,维护成本非常高。作为云原生存储我们肯定优选docker或者k8s部署方式,为此我们调研了Ceph和TiDB的部署工具cephadm和TiUP,经过对比我们认为TiDB的工具TiUP对用户非常友好,支持很多的高级功能,可以参考其功能设计Curve专属的部署工具CurveAdm
CurveAdm与业界存储系统部署工具的对比
功能\工具
ansible
CurveAdm
TiUP
CephAdm
一键安装
Y(依赖容易出问题)
Y
Y
Y
一键部署
N(各个组件单独部署)
Y
Y
N(步骤稍多)
playground
N
Y
Y
N
多集群管理
N
Y
Y
N
一键扩容
N(步骤稍多)
Y
Y
N(步骤稍多)
一键升级
N(步骤稍多)
Y
Y
Y
一键停服
N
Y
Y
N
一键清理
N
Y
Y
N
部署环境预检
Y(少量预检项)
Y
Y
N
操作审计
N
Y
N
N
周边组件部署
N
Y
/
N
一键日志上报
N
Y
Y
N
集群状态统计上报
N
Y
Y
N
N
Y
N?
N
TiUP还有一些功能没有列出来,总体来说比我们CurveAdm的功能要更加全面,但是目前来看,CurveAdm的功能已经基本满足我们需求,后续我们会根据用户反馈继续优化。
此外还有命令行工具的易用性问题,对比重构前后两个工具的输出结果截图:
curveadm是我提出来想法,团队小伙伴陈静力一人开发完成的一个中小型项目,代码量1w+(Golang有很多第三方库可用,所以能省不少代码),静力的产品思维和用户体验意识令我印象非常深刻,开发的功能总是可以超出我原本想法的预期,开发效率也是超级高效,很多功能也都是抽空实现的,实际投入时间应该不到3个人月。
命令行工具则是由团队新秀程义负责完成的(同时也负责了ceph的日常运维工作),原来的工具我真的是看不下去了,太low,影响curve的形象,就让程义同学跟静力学习工具类的用户体验改进经验,小伙子完成的还不错,另外新工具部署也更简单,golang打包好二进制,一键下载使用,不像原来的工具,各种依赖,部署都折腾好久。
需要继续完善的方向:
我们后续规划的多云和混合云部署架构场景下,用户为了计算资源的弹性能力,通常使用k8s管理计算资源,那么存储资源如果也可以通过k8s管理,才是真正的云原生存储(类似minio),因此我们后续的工作重点就是支持Curve文件存储的k8s云原生部署,好在我们curveadm的docker化部署方式,也是基于yaml配置文件来进行部署的,只要我们将相关配置迁移适配到k8s operator,支持k8s云原生存储部署应该也比较简单。

项目成果

  • 推动Curve块存储业务规模发展,2年内集团内部存储数据容量从不到xxxTB增加到超xxPB,同时发展外部用户数家;近2年未发生集群级故障,性能和稳定性相比Ceph云盘有了极大提升了
  • 带领团队完成了Curve文件存储的规划、设计及开发(代码量13w行,是所有curve小伙伴的结晶),数据和元数据相关性能均达到开源存储项目的领先水平,目前正在推广落地中,已有2个业务使用
  • Curve开源社区建设方面,推动Curve加入CNCF基金会sandbox项目、信创认证、PG数据库社区共建等社区建设工作,目前已有数位外部贡献者,以及数家外部用户,测试中用户10+,项目star数1.5k,社区用户群人数1k

总结复盘

这一块需要好好总结复盘一下,如果晋升不通过,那么应该就是这块的问题,也是我前面几次没有申请提名,觉得晋升条件不够充分的点。
项目从BS开发完之后,后续的发展方向这块,花费了比较长的时间讨论分析,并且一开始也没有特别精准的思路。包括BS存储发展方向确定是高性能和云原生数据库场景之前,和确定开发支持多云、混合云架构的文件存储系统之前。目前curvefs的架构思路我认为应该是正确的,国内比较流行的文件存储系统除cephfs之外(架构固定,不太会为某个场景做特殊改造),cubefs、juicefs都在往高性能缓存方向演进,并且他们都走在了我们前面,所以当初应该更早确定下来目前的架构。
另外我们当前集团内部业务使用了不少cephfs集群,如何把curvefs做出比较优势,并且把这些集群逐步切换到curvefs,也是我们要重点考虑的问题,如果内部业务都拿不下来,外部用户更没希望。我们也跟业务沟通过这方面的问题,curvefs要做到什么样的优势才能替换cephfs,业务认为主要有两点:1)性能有较大优势;2)成本也更低;简单来说就是性价比要高才行。但我理解还有一层隐含要求,稳定性不能比cephfs差,否则业务不会接受,我们作为一个新开发的项目,如何达成与相当成熟的cephfs相近的稳定性,这也是非常大的挑战。
高性能这块,我们面临了极大的技术挑战,boss给我们团队配备了两个P6技术大佬,怎么把大佬的能力更好的发挥出来,以及把团队能力建设起来。大佬来之前没能更早的把高性能硬件适配做起来,这也跟团队能力和人员分工有关(人力都投入到了文件存储功能开发,目前仍然以文件存储开发为主,高性能块存储适配高性能硬件方向目前投入P6架构师一名,P4资深开发一名,这方面后续要多投入人力加快版本落地)。
总的来说,Curve最大的问题,我在上面也提到过,没有特别多的落地,开源用户社区规模也不大(主要是活跃用户数比较少),开发者也略少,star数量还不够多。
与Ceph这个10年以上的老项目就更没法比了。

NOS项目

背景和必要性

NOS对象存储服务,已经上线运行10年,服务了集团互联网几乎所有的事业部,业务数据量xxPB,并将持续发展。但是NOS也面临非常多的问题,我早在20年底就已经基于存储团队内部调研结果加以整理说明过(这里摘录一部分与NOS相关的,括号里面是当时我的评语):
  1. 员工长期保持激情:架构、盈利、成本综合考虑,单纯的考虑某一方面很难长久留存员工(注:这条建议很好,但也比较有挑战;比如架构升级一般都是由业务需求来推动的,盈利和成本这块可以内驱,但如果增量太少,比如nos,也不好做)
  2. NOS历史包袱比较重,建议要从长期考虑进行整体架构优化和调整,只关注短期目标很难把业务做稳做实(注:短期主要是指新的存储技术,新的业务拓展,成本优化等,这块已经很多模块处于停止维护状态,但其实还是会有新的模块加进来,后续是不是会变成历史包袱,很难说,只能尽量避免,代码和架构总有腐化的时候,不可能扛几年甚至十几年)
  3. 所做产品的价值体现不出来,考评吃亏(注:主要是指业务规模上不去,但又很难拓展,这条说的比较实际,我本身也有这种困扰;内部客户量上不来,虽然说可以拓展外部客户,但从底层平台来说,没有完善的产品,确实难走商业化的路子,基础设施这块应该都有类似的问题)
类似我上一篇文章《我是如何带团队的》里面的叙述,项目遇到的问题首先要考虑的解决方案就是把项目的业务发展好,用业务发展解决内部矛盾。
当时做这个调研整理的原因,也是因为项目组人心涣散,前景一片模糊,非常不明朗,看不到希望,团队在21年初只剩下了3个人(其他人都跑路了,离职率50%)。所以下面的挑战项,也是基于这次调研而定义的。

项目挑战

挑战1:EC存储引擎小文件空间利用率问题

这个是技术细节问题,但是其本质还是成本问题,先修炼好内功,才能赢得用户。
小文件放置策略、小文件合并策略,直接影响底层Ceph EC存储引擎空间利用率,利用率低会导致单位存储空间的成本上升,最终影响报给用户的价格和NOS利润率,低频存储EC引擎自2018年上线之后,存储空间利用率一直在60%左右(不考虑副本冗余),业界的解决方案通常是在收费标准上做文章,比如各家公有云的价格单上,低频存储类型,单个文件不足32k或者64k的就按32k或64k收费,以此来规避空间利用率不高的问题。而我们则是想通过底层存储引擎的技术创新来解决。
EC条带利用率问题,对大文件其实不敏感,但是不幸的是,NOS存储的文件80%以上都是小文件,而且是比业界定义的小文件还要小很多(业界128k或64k以下,我们小文件超过60%都达不到这个标准),导致我们的EC条带利用率更低。
解决方案:
针对小文件合并方案,我们一共演进了2个版本,第一个版本(水平放置,以EC 3+2为例进行说明):
写入k个小文件,需要 (3+2)*k 次IO,读取这k个小文件需要 (3+2)*k 次IO。这是我们第一个版本的效果,解决了条带利用率不足的问题,但没有完全解决IO放大问题,而HDD盘又对IOPS非常敏感,所以必须要解决这个问题。
为此我们又演进了第二种合并方案(垂直放置,还是以EC 3+2为例进行说明):
首先把条带大小调整为1M,EC 8+4 策略下每个分片是128K,也就是可以保证80%的小文件可以保存到1个分片里。这样的策略下,写入k个小文件,需要 (3+2) 次IO,读取这k个小文件需要 k 次IO。
可以看到,方案二比方案一在写入小文件场景下有k倍的IOPS提升,读取有3+2倍提升,即保证了空间利用率又保证了性能。
经过统计,可以看到我们绝大部分条带空间的利用率都达到了90%以上,没有低于80%的,从60%到90%,有显著提升,相当于我们用同样的空间多存了30%的数据。
这方面团队里俞乐勤和袁伟是绝对主力,把这块小文件相关的优化真的是研究透了,就是以后这块再想突破也有点难度了。这方面应该搞出来了2项专利。

挑战2:冷归档存储业务需求和小规模成本问题

NOS对象存储服务提供的存储类型一直缺少超冷的归档类型,原因有很多,之前可能是业务诉求不足,近两年来集团对各个事业部的降本增效的要求越来越高,NOS服务各大业务方,除了给到更多折扣之外,也已经大量使用了低频存储(我们18年上线的是EC 8+4折合1.5副本,之后20年上线了20+4折合1.2副本),但这仍然不能满足降本诉求,为此我们调研了归档存储架构和实现方案,但受限于IDC机房条件和我们存储容量规模问题,在超冷归档存储类型下无法做到业界成本,我们与各家公有云厂商沟通对接,最终选择xx云作为冷归档存储类型的底层存储供应商,NOS做全托管的封装,让业务既能享受到更低的价格,也能无缝使用(不需要自己开发转存程序)。
解决方案:
虽然我们由于上面提到的限制条件,没有上线自研冷归档,但是我们为此做了充分的技术调研和评估。我们为了跟xx云砍价,在与他们技术人员对接技术细节的过程中,也跟他们一起计算了我们一组存储机可以存储的数据总量(他们可以据此推算出成本,这可能有点不太合适,但因为大家用的都是业界标准技术,实际上也没有什么秘密可言),据此把xx云给到网易集团的折扣,从y折砍到了x折(超过x折就跟我们自研方案成本持平,没有必要选他们),x/y=0.6,整个集团都能从中受益。这也是我们把单位存储空间的成本做到很低之后的一大收获,有技术才有话语权。
对于普通归档存储类型,我们计算成本和可靠性之后,认为自研方案可以做到比公有云低一些的成本,具备成本优势,目前已经部署上线。
这方面冯一乔和俞乐勤的功劳最大,尤其是冯一乔,作为新入职半年的社招同学,不但极高效率完美解决了很多腐化3副本引擎的历史遗留问题(都是老大难),后来还把冷归档高质量、高效率的做完了,为人还非常谦虚低调,觉得自己什么也没做。

挑战3:业务拓展问题

集团降本增效的KPI已经给各个事业部带来了极大压力,而对象存储又是各个事业部(尤其是互联网行业)的重要基础设施,资源使用量都挺多,尤其是NOS大客户,对象存储服务的结算成本也都是排在前面,那么自然而然的,压力也就传导到了我们NOS项目。大客户降价诉求也就越来越强烈,已经到了影响业务满意度的程度,甚至有部分客户已经开始寻找外部供应商来替换NOS。
如何在一个上线运行10年的老项目的基础上进行更新迭代,持续创新,保持产品竞争力,并拓展业务规模和场景?
在我的理解中,存储系统关注的3大核心要素:
  • 单位存储成本
  • 服务稳定性
  • 数据可靠性
其中后两个是基础要求或者是用户愿意使用的必要条件,如果不能满足,不管你成本多低用户都不会使用(谁能接受数据丢失?谁能接受时不时的业务中断?)。但是从业界情况来看,后面两个要素基本都做得差不多,没有特别差的。所以到最后大家只能卷单位存储成本,成本下来之后,自然就会有更多的业务愿意使用。
NOS也是在保证服务稳定性和数据可靠性的前提下,持续的优化单位存储成本,在取得了良好的效果之后,给集团内大客户持续的降价,以此来为业务降本。因为成本降低,也吸引了多个业务方的增量业务接入NOS,比如xx业务(已转存3PB+数据)、xx业务(自18年已沟通多次,都因成本问题没有谈成,目前已经在沟通部署第一个集群),也有外部的商业化客户已经基本谈妥(xxxx)。
修炼好内功,客户自然来。
这方面俞乐勤是核心贡献者,团队里颜值与实力兼备的技术专家,为NOS内部降本保持盈利做出了突出贡献。

项目成果

  • 通过技术架构升级推动NOS内部降本,给业务的报价相比xx云OSS 9折甚至更低(大客户报价连续两年打折,非常好的满足了业务方降本诉求)
  • 开发上线1.2副本低频存储(xxPB)及冷归档存储(xxPB),以及新上线的自研归档存储,完善了NOS存储产品线,非标准存储占比达60%,为业务方节省大量成本
  • 持续进行业务拓展(xx、xx、xx等),年营收增长达30%以上;近2年存储容量实现翻番达到xxPB,并拓展了商业化客户
  • 通过主动为业务降本及共建等手段,持续提升业务方满意度,上半年更创新高;近2年SLA均超过99.5%
  • 解决了团队内部信心不足、人心涣散问题,团队凝聚力和士气显著提升
为了降本和拓展业务,我们还有很多挑战没有详细描述:
  • 低频、归档存储演进过程中的数据可靠性保障问题,我们转存了超过60%的数据到低频或归档存储引擎,同时我们还在底层把大量数据从filestore集群转移到bluestore集群,以及从1.5副本转移到1.2副本甚至更低冗余度的集群,这一系列过程中,我们承担了极大的数据可靠性风险(也在转存到各个阶段做了大量的校验程序),但是我们做到了转存xxPB数据的100%可靠性,并且做到了对业务无感知,没有造成任何性能和故障问题
  • 通过cdn进行直传优化,节省了大量的边缘节点成本(之前是aws海外虚拟机,或者国内idc租赁服务器来搭建直传边缘加速节点)
  • 我们还在公有云和私有云环境完成了网宿CDN到融合CDN的数千个域名的平稳迁移工作,也是为了给业务节省成本,改造了CDN管控服务,并且修复了多个CDN厂商间的兼容性问题
  • 我们调整了计费策略,让业务可以享受更多折扣,为此我们多次改造统计计费服务,承担了大量的改造工作量
  • 还有我们正在进行的ddb改造tidb工作,由于ddb存储的对象数量已经超过千亿,要扩容已经非常困难并且会导致空间严重浪费
  • 老旧腐化存储引擎的维护工作,也非常有挑战,比如sdfs,已经是10年前的软件,nefs也有5年历史,目前NOS日增数据近百TB,都是靠这两个引擎承担,并且我们为了节约成本又不适合进行扩容,因此这两个引擎的IO压力非常大,同时机器也比较老旧,各种异常都容易触发,而这两个引擎已经没有非常专业的人可以维护,为此我们也做了大量工作,来熟悉并掌控他们,也解决了多个严重问题
  • 为了提升xx业务数据转存到NOS的速度,我们对转存服务也做了大量性能优化工作,从最初的媒体xTB,到xxTB,提升了10倍;为了提升xx业务转存NOS低频存储数据到冷归档存储的速度,我们也对转存服务再次进行了优化,从每天xxTB提升到xxxTB,速度提升了4倍,数据转存时间从半年左右降低到了1.5个月,为业务节约了大量成本
  • 富媒体处理业务私有化部署改造,为云音乐海外云上私有化部署提供支持,节约业务开发成本,我们也有比较大的工作量
  • 与视频云共建视频处理服务,简化业务方使用逻辑的同时还可以为业务节省成本(价格更低)
  • 我们也做了很多安全增强工作,来提升业务使用nos的安全性
NOS的小伙伴们真的都非常给力,打绩效的时候每次都为给谁打A而发愁,幸福的烦恼。

总结复盘

NOS项目最大的收获就是,验证了我用业务发展解决团队问题的想法,也让团队明白了做最好的技术,追求卓越,才能赢得客户信赖,才能拓展更多的业务。
其实NOS整体发展还算比较符合预期,但还有很多挑战,我们还没来得及解决,比如:
  • 原有的两种3副本引擎的下线和替换成EC引擎的工作,比预期的进展慢,这两种腐化的存储引擎导致我们出现了几次线上故障;另外这也涉及到过保服务器的利旧和成本问题,如果一次性下线,成本太高,但又不能利旧给EC引擎用,所以目前我们的策略是开放大文件EC直接写入后对老的3副本集群逐步缩容
  • 计费系统的演进跟不上我们业务形态的发展,导致很多计费需要运营同学手工出帐解决
  • 以及对外商业化探索,可以适当早一点发起,至少可以和已有的商业化客户进行一些接触,多了解外面客户的需求
  • 虽然我们这两年已经清理或重构了不少模块,但还有更多的腐化模块,需要厘清并尽快处理下线或者重构(如ddb、httpdns、cdn、跨分区同步、s3 sdk兼容性、事件通知等)
  • NOS性能问题与公有云还有比较大的差距(主要是时延),但好在用户不太敏感,尤其是对接CDN的资源,回源比例非常低,时延问题基本没有影响,所以目前也没有排在很高的优先级来解决,但问题已经确认是腐化的3副本存储引擎性能不足导致的
从更长远的视角来看,NOS后续还面临更大的挑战,我们要对标的已经不是私有化对象存储厂商,而是业界公有云厂商,各大云厂商都在死命的降价抢占用户数据,甚至不惜亏本在做,每年都会强制各产品线降价,NOS怎么应对?毕竟我们的体量太小,规模优势完全没办法跟公有云厂商比较,IDC条件、硬件等也有很大差距,软件方面不敢说我们有优势,但目前应该还不太是劣势,我们唯一的优势就是人力成本比较低,我们人少。不过好在我们近一两年也做了一些技术储备,虽然不多,但应该还能扛3~5年。

专业贡献

各种奖项,专利
  • 2020年10.24创新奖:Curve项目获得最佳技术开源贡献奖【自研开源】,这不是我的功劳,是Curve团队的
  • Curve:信创认证,信通院OSCAR尖峰开源项目及开源社区,可信开源项目认证
  • Curve:捐献给CNCF基金会sandbox项目
  • 专利:NOS 2篇、Curve一篇
  • NOS:2022H1 云计算降本增效奖

学习分享

各种分享
  • Ceph:云音乐goblin平台共建项目infoq文章一篇
  • Curve:杭研公众号、Curve自有公众号文章数篇,ITPUB专访一篇,
  • kms高质量文章数篇(一篇上首页推荐/月度最佳),NEXT训练营高质量文章数篇(结营仪式上受到专项表彰)
  • 实践者论坛分享一次《Ceph云盘IO抖动原因及优化措施》,课程一项《分布式存储介绍(curve&ceph)》
  • 2022.08.25:参加阿里云金融创新峰会,演讲主题《网易数帆开源社区建设实践 — 以Curve社区为例》
  • 团队同学还有很多文章、直播、外部会议等等分享,不是我去讲的就不算在内了,团队外部会议分享这块比较随意,谁有空或者谁合适就谁去参加,毕竟每个同学都要有各自的发展空间

未来发展计划

对于未来我思考过很多,首先是职业生涯问题,我一直在想我还能做这行几年(我今年37岁,软件行业35岁的坎儿我已经超过)?我要凭借什么能力或技能让公司觉得我还有价值?我怎么延长我的职业生涯?
为了能在网易干到40岁,我要做如下几件事:
  • 把Curve项目做好
    • 对于文件存储,今年和明年上半年先把AI场景和云上场景的效果做出来,拿到一批用户案例;之后再拓展更多场景
    • 对于块存储,今年先把高性能硬件(NVME/RDMA)适配起来,明年上半年把Curve软件层的性能优化好,争取性能可以对标到阿里云ESSD云盘,保底也要做到超过阿里云高效云盘(主要是时延),支撑好云原生数据库应用场景
    • 要在40岁之前把Curve项目带进CNCF孵化项目,目前来看,这也是一件非常有挑战的事情,需要把Curve开源社区发展的非常好,并且要有相当多的用户案例
  • NOS项目要保持盈利
    • 内部业务,要继续拓展增量并保持存量,通过软硬件优化来降低成本并最终给业务降价,做到薄利多销来对抗公有云厂商的逐年降价,希望能在40岁之前让NOS存储的数据量再翻一番,这个事情不确定性比较大,毕竟目前可以拓展的业务已经非常少,单靠业务数据的自然增长是完全没希望的,另外就是软硬件优化的方向和思路还不太清晰,还需要进一步深入调研,可能可以考虑的方向是数据压缩。
    • 外部商业化,今年开始尝试,明后两年能拿下2~3单合同
  • Ceph项目还是维护好,别出问题就行
为了让我40岁以后还能不丢工作,考虑过两个方向:
  • 管理岗方向,这个目前在做一些团队管理工作,但是就像我上一篇文章说的,还没有完整的方法论,套路不清晰,时不时要修正,这个方向比较有挑战,主要是不知道怎么成长,是不是各位大boss有什么经验可以传授一下?还是说都是一步一步慢慢总结改进走出来的?这个方向可能确实没有速成途径吧
  • 商业化架构师方向,我个人感觉这个方向挺不错的,就是得能忽悠、会忽悠客户,还得能写一手好材料(word、ppt要玩的很溜,各种高大上的专业名词要搞得很透,各种新鲜技术都要略懂能跟客户聊得很嗨,各种人情世故、客情关系要做的很到位),也非常有挑战,这个方向做好了个人综合素质会上一个台阶

文章预告

最后预告下我的下一篇文章:《NOS这10年》,谨以此文来庆祝NOS上线10周年,敬请期待。
文章大纲:
  1. 序 — ps. 希望了解NOS的大佬能帮忙做序
  2. NOS介绍
  3. NOS历史
  4. NOS现状
  5. NOS未来

70. 爬楼梯

题目链接:https://leetcode.cn/problems/climbing-stairs/

这道题不会做,看官方题解才明白。

 

160. 相交链表

题目链接:https://leetcode.cn/problems/intersection-of-two-linked-lists/

下面两种方法都想到了,官方题解的双指针法想不到。

 

146. LRU 缓存

题目链接:https://leetcode.cn/problems/lru-cache/

这道题超出时间限制了,原因应该是时间复杂度是O(n)不是O(1),用list保存缓存的key列表,调换list里面元素的顺序比较慢。

等我看官方题解更新吧。

 

 

 

我是如何带团队的

这篇文章荣获网易集团内部知识分享平台《2022年度十佳作者》及《2022年度十大人气文章》。

这篇文章怎么来的

近期收到HRBP通知,做了一次一线管理者述职,从接手存储团队以来不知不觉已经过去2年,这两年有不少感想,从去年初就在想(刚看了一眼popo待办,这项任务已逾期546天,现在总算可以标记为已完成了,尴尬~),能否整理出一篇文章,详细的讲讲自己是怎么带团队的,有哪些方式方法是需要纠偏的,有哪些是可以改进的,又有哪些是可以继续保持并加强的。这些东西如果我自己不整理分享出来,就很难被外人获知,也就无从给出辅导反馈,自己也就没有改进的机会。因此借这个机会,把述职PPT里面没有发散出来的东西,整理出来,算是一种总结沉淀,也算是一种同事或者上下级之间的互相交流。针对文章中的各种管理方式、问题或者案例,欢迎各位同事领导找我沟通指导。

我的工作经历

介绍我的工作经历,是为了让大家对我的管理理念或者思路有更清晰的了解,人们总是习惯按照自己的工作方式方法或者质量标准为尺度去要求其他人,并且过往的工作经验能很大程度上左右自己对某件事或者某项工作的看法。比如有些人认为一个功能开发工作量20天搞定,而另外一个人则认为至少1个月,那这两个人如果技术能力和工作效率差不多的话,工作量的偏差就在于代码开发之外的工作量的评估了。作为一个主管,你更认可哪个人的评估结果?这在很大程度上需要依靠主管自己的工作经验。主管之前做事考虑全面、细致、测试充分、代码质量自我要求高,工作性格偏严谨,那极有可能他会认为至少要1个月,而不是20天撸完代码就发布上线。

我是10年参加工作,前两年在华为工作,有比较严格的开发流程和质量规范,自己只要按部就班的遵守就ok了。但12年入职网易之后,流程和规范就没有公司级的标准了,通常都是项目或者部门自己的规范,这是互联网行业和传统软件行业的差异,这里不做评价。在网易做了2~3年开发之后,也开始做leader带小团队,那时候团队的小伙伴们,绝大部分都很给力,几乎不用怎么操心,定好目标之后各司其职,发现问题自己修掉就行了,开源社区时不时的push几个pr过去,还能收获不少成就感。

再后来就遇到了一些不那么给力的小伙伴,给人的感觉就是带不动,从不用带到带不动,给我的落差感很大,经常想不明白为啥会不知道工作怎么做(技术能力是一方面,工作方式是另一方面)。也有另外一些比较给力的小伙伴,一部分是本来就知道怎么做工作,一部分是看组里大佬怎么工作,也都不怎么费心。遇到不给力的小伙伴,感觉自己也比较受打击,经常怀疑自己带人到方法不对,说不定换个leader人家就能变得很给力,绩效可以好的飞起。

在后来在网易工作了5年,最开始身边的那批小伙伴们也都慢慢的分开了,项目也基本进入维护状态了,加上前同事一直邀请去他那边小公司做同样的事情,就出去做了一整年。这一年带了小公司10几个研发,最多的时候接近20人,从最开始的团队没有任何流程,到稍微规范,我也花了一些心思,主要是在小公司里流程依赖的工具、平台都要自己动手弄。这里的小伙伴们,虽说都不是什么名牌大学毕业的本硕生(甚至有一个前端同学是高中毕业,这里没有任何歧视前端同学的意思),但也都能在指导下做出来想要的东西,可能大家知道自己学校不行,能找到一份程序员的工作实属不易,也想趁刚毕业多学点技术,一个个的干劲很足,自己也有一些经验可以给他们一点指导,所以并没有感觉带人吃力,工作氛围也比较轻松愉快。虽说后来2年这家小公司的母公司收缩业务,杭州这边分公司基本裁撤了,但是之前一起工作的那群年轻小伙伴们,也都有了新的不错的工作,这也是我一年做到的自认为稍微有点成就感的事情之一。

再后来就又回到网易工作,先做了一年多的开发,之后接手团队。团队有3个小组或项目,状态各有不同,一个纯维护状态基本没有开发量(用开源)、一个10年的老项目还在持续更新有一定的开发量(半自研半用开源)、一个近几年的新项目还在发展阶段有很大的开发量(做开源项目)。

人才招聘

招什么样的小伙伴

通过这10多年工作中的观察体会,我认为一个高绩效或者说我愿意与他共事的小伙伴,应该具备以下几个特质:

  • 有能力:光有想法是不行的,要自己有能力做出来或者设计出来,空口说白话谁都会,show me your code才是王道。
  • 有动力:首先我声明自己就是一个俗人&穷人,所以看待身边的人也是按照我这个视角来看的。是什么让你出来做码农这种工作?是什么让你在职场拼命往上爬?是缺钱还是想赚更多钱?我共事过的小伙伴中也有不少富裕家庭出来的,但我经常想如果真正富裕到一定程度,应该不会出来做码农吧?我还是建议这类小伙伴最好不要出来跟我们卷了,回家接手家族产业才是王道。当然不排除有小伙伴是为了用代码改变世界才出来做这行,但是很可惜我没遇到过。
  • 有意愿:这个是说,你有能力做一件事情,但是你得愿意动手才能落地,有些小伙伴偶尔会跟我说这块功能我不感兴趣,不想做。如果他真的不想做,那我总不能强迫他去做,强扭的瓜不甜,即使委屈做了也肯定不能追求卓越,好在这种情况不太多见。
  • 有想法:有的小伙伴有技术能力做一个功能或者小的项目,也有很强烈的意愿和动力,但是在整体思路上和具体实现的方案上,没有清晰的想法,就是设计架构能力不太行,或者对产品体验方面没有想法,做出来的东西让用户用起来总是感觉很别扭不顺手。而有想法的小伙伴则能做到自己就是用户,深刻理解用户或者业务需求和使用场景,做出来的东西用户用着特别顺手,就跟自己开发的一样。说到这个,怎么才能产生好的想法,我理解一方面要有产品思维,一方面要和用户在一起。

后来网易发布了自己的人才观:

  • 聪明
  • 有活力
  • 自驱
  • 有Sense

我理解正好与上面那几条不谋而合。

作为主管,想招进团队的人肯定是自己愿意与他长期共事的人,上面已经解释过这方面的标准。但是,我不得不说但是,面试过程中真的很难把这几个方面的东西都考察到,培训过的SBO面试法,当然是一种很好的手段,但是我认为仍然不能让你避开所有的坑,以我的经验来说,身边优秀小伙伴推荐的他愿意共事的人才更靠谱。你 — 你欣赏的小伙伴A — A欣赏的小伙伴B,那么你如果把B招进来,十有八九是不会让你失望的。

招聘最大的困难是什么?

撒不开网,捞不到合适的候选人。

不要觉得大公司候选人多,小公司也有一堆简历,因为能进大厂的都是比较好的学校毕业的,但是你想想985毕业的比例就知道,更多的码农还是普通学校毕业的。

简历多有用吗?其实没多大用,反而增加了筛选和面试的负担。少而精准才是最关键的。怎么做到呢?我也没有好的思路,但是凭直觉最理想的就是点对点直接挖人,认识的小伙伴也都分散到各个公司,想找总是可以找到,但成本太高,开不起价。

最痛苦的是什么?

预算不足。

有一种是简历筛选的时候就知道候选人定级应该超出预算,这种还不是最痛苦的。另一种是面试都ok了,但是候选人薪资要求比预期高,这种就很难达成一致,原因可以参考我上面说的“有动力”的解释。遇到这种情况怎么办?我理解可以看两个情况:如果是薪资要求差距不大,还是可以通过尝试沟通项目的发展前景和从事的工作的前沿性、挑战性,说白了就是画画饼,让候选人觉得,即使我现在进去这个项目赚钱不如预期,但是一旦我做好了这个项目,以后就能赚更多的钱。第二种如果是差距很大,直接over得了,别浪费两方时间。

换位思考下,如果我出去找工作,那么我只考虑钱,也分两种情况:1是这份新工作让我立刻可以赚到钱(给到的薪资比较满意);2是这个新工作可以让我以后赚更多的钱(给到的薪资不太满意但还不至于感觉到被鄙视,但是我能通过这份工作变成大佬)。再次强调下:我是个俗人&穷人。

最惨的是什么?

候选人看不上你的团队或者项目或者公司。

这种情况在小公司特别常见,大厂也偶有发生。被候选人看不上怎么办?我也没啥好办法,每个人都有自己的发展规划和看项目的视角,候选人就像投资人一样,觉得你这个项目没前途,不会成,那你要么坚持自己的方向说不定哪天就能一飞冲天让他们后悔莫及,要么重新审视自己的项目对现在的方向进行修正。谁都有看走眼的时候,你只能找那些志同道合的小伙伴,否则不认可你项目的人才加入进来并不一定是好事。

boss在述职现场的提问:为什么你没有招到大佬级的人才?

我现场的回答:

  1. HC的级别不到大佬级
  2. 我个人的大佬资源也不够,搭不上线

回来后,我又想了一段时间这个问题,我认为boss的问题可能还可以尝试从另外一个角度理解:为什么你没有培养出来大佬级的人才?
这个问题我认为对我来说更有挑战,为什么我没有培养出来大佬级的人才?甚至可以更直接一点:为什么我自己没有成为大佬级的人才?

如果我自己都做不到,怎么能要求或者期望小伙伴们做到?培养人才、构建人才梯队,确实是一个管理者的本职工作之一。

要回答这个问题,理由或者说借口总是能找到,但现在不是boss在问我,是我自己在扪心自问,怎么回答自己?我认为要培养出来大佬级的人才,天时地利人和都要具备。

  • 天时:风口的项目
  • 地利:老板的支持,项目的需要,公司的背书
  • 人和:你团队里有一个具备大佬潜质的小伙伴,或者你自己就是这个人

我见过或者听说过一些华为的大佬,也了解网易一些大佬的开挂经历,大部分都是有大佬潜质的人才,在公司或者项目需要立一个业界大佬flag的时候,这些人主动或者被动的站出来并且顶上去了,经过一段时间的痛苦期之后,大佬就练成了。你可曾见过或者听过,一个长期维护阶段的项目出过大佬?你又可曾听过一个生命周期快结束的项目出过大佬?以我略微熟悉的云计算/虚拟化相关开源项目来说,想要成为社区的core developer或者甚至maintainer,没有长期稳定的公司项目和需求做支撑,你连需求都找不到,只能做一些修修补补的工作,怎么能进入社区核心开发团队?

最后回答下我自己为什么没有成为大佬,我认为主要是我离大佬潜质还有一点距离,项目的需求也不太强烈。

案例

其实述职的时候列了几个案例,但是感觉案例也都是项目里的个别情况,时间长了总能招到几个还不错的小伙伴,所以这里就不列了。但是最难的是招到的每个小伙伴都是非常优秀的。更何况也不是每年都有招聘指标。

绩效管理

我自己做开发时的绩效

工作的前几年,除了第一年刚入职绩效不是A,前面几年都是A。为啥我能拿A?我自认为有如下几个原因:

  1. 对工作有敬畏心:学校一般,能进大厂不容易,不要因为不能胜任工作被开除了,有危机感
  2. 对公司有感激心:公司给发工资,相比其他小公司薪资还可以,不能白拿
  3. 对赚钱有上进心:用比较流行的话来说,小镇做题者(不能称为家,因为做题也不十分拿手),家穷人丑,只能拼命赚钱,在大厂里拿到高绩效才能比别人赚得多(卷起来)
  4. 对技术有钻研心:学好技术以后才能赚更多钱

有了这些基础,做工作的时候只要超出leader预期,就能拿到好绩效。超出预期有很多种情况:

  1. 提前完成任务
  2. 高质量完成任务
  3. 积极主动,不要让leader催,而是催leader
  4. 帮leader分担压力
  5. 帮团队解决难题

我相信如果你能做到以上几种情况的1到3个,绩效不会差(除非有人比你还卷)。

我带团队时的绩效

众所周知,带领高速发展的业务,容易拿到高绩效,而维护状态的业务则很难。能高速发展一般有两种情况:一是公司内部或者外部环境有强需求、大痛点,没你不行;二是你带领团队克服艰难险阻把本来发展一般的业务搞上去了,发展起来了。当然肯定是第二种管理者更厉害,第一种有一点运气成分,类似站在了风口,大部分人都能起飞。

具体到我自己,两种情况应该算是都经历过,但是很遗憾,第二种情况我还没能做到最好。所以绩效一直一般,我的压力有点大,并不是怕boss开掉,而是怕项目被我带到沟里,所以我经常在想,换一个人来带这个项目会不会比我做的更好?我有没有尽力而为?说实话第一个问题我自己没办法回答,我相信肯定有很多人会比我做的更好,我只能回答第二个问题,自己尽力了就ok,要不要换掉我交给boss就好。

怎么搞好团队绩效?

怎么让团队整体绩效保持较高水平?怎么提升团队里个人绩效?怎么沟通绩效?怎么做绩效辅导?这些都是同一类问题。

通常我都是以自己的经验来要求团队里的小伙伴做一下超出leader预期的工作,如果每个人都能超预期,那团队绩效肯定也会远超预期。但是据我观察,有一些小伙伴是很难做到像我刚毕业那几年做开发时一样卷,可能不像我一样家穷人丑吧,安安分分按部就班做一份工作有一份工资做零花钱就ok。

这里我有一个例子,虽然不是我们这行,但也非常有参考价值,我一个高中同学,师范大学毕业后去深圳一所普通公立高中当班主任,有一个学生经常翘课,打电话给家长忙着挣钱没时间管,找学生谈话,问他天天翘课怎么考大学?被说烦了,就说,我家在深圳有多少套房,几家工厂,不考大学也一样活得很好。后来我同学干了3年就改行不当老师了。

举这个例子只是想说,不是每个人都差钱,每个人都追求是不一样的,所以我一般跟小伙伴沟通的时候,也会根据他们家庭情况来区别交流,不差钱的小伙伴,尽量用技术成就感来聊,差钱的那直接聊高绩效就能升职加薪。但是高绩效的要求还是要一视同仁讲讲清楚的,就是上面我提到的5点超预期的方向。

另外,不差钱的小伙伴很多也做得很好,还是有很多有追求有理想的小伙伴的,公司价值观“热爱”可以解释这种人。在这方面每个人都应该向我们丁老板学习,绝对的不差钱,绝对的有追求,绝对的“热爱”。

激励不动怎么办?

也有实在激励不动的,躺平或者半躺平的小伙伴,怎么办?没办法,团队还要继续发展前进,也不是养老的地方,包括我自己也做好随时被淘汰的准备。361的1就是为这种情况准备的。我相信如果一个团队没有这种人,那团队绩效就不会差,我也一定会据理力争尽力保证没有这个1的存在。如果团队绩效都没做好,我怎么好意思厚着脸皮去争取?我自己都要引咎辞职了吧。

怎么绩效沟通?

绩效沟通有时候挺难,有时候也不难,只要你别给小伙伴惊吓就都还好,提前打好预防针,把沟通辅导工作做在平时。哪里不行要提前说,给人机会改进。

当然也不排除有些小伙伴就是觉得自己做的很到位了,或者有些绩效指标的标准确实也有一点模糊,按指标来说他自认为达到4分或者5分,你为啥给3分。这种情况一般我是团队内横向比较,把好的标杆挑出来,列清楚理由和建议。如果还是沟通不来,我通常会跟我的主管和HRBP交流学习,看看他们的建议,当然最关键的是你的考核结果要有依据而不是根据个人喜好打分。做不到每个人都心服口服,也要做到公平公正。

最后,同样的,案例也不放了。

团队氛围

什么叫团队氛围?

团队小伙伴们整天一起吃吃喝喝、吹水打屁、欢声笑语,算不算氛围好?每个人都愁眉苦脸、广投简历、随时跑路,肯定不是好的团队氛围。一个正常的团队,应该是开发时小心翼翼、测试时吹毛求疵、上线时严肃认真、业务稳定运行时举杯相庆。刚毕业入职华为,有一句类似公司价值观的话讲的很好:胜则举杯相庆,败则拼死相救。

好的团队氛围关键因素之一,要保持团队稳定性,但要做到这一点很难,所以可以退而求其次,保持团队人才梯队稳定性:老带新,新成老,老升职或跳槽去追求更大成长空间。一个再好的项目,经过多次不完整交接之后,也会面临腐化挑战,出问题都没人能解决或者花费很长时间熟悉项目代码,改动代码也会瞻前顾后,担心掉到暗坑里。什么叫完整交接?我的理解,完整是指经过梯队培养的新人,在项目里做过相对比较长时间的深入开发,对已知的问题或设计缺陷有比较清晰的理解,知道怎么避坑,敢改代码,敢加功能。我认为以校招同学来看,至少全职投入一年,两年最好,才算是完整的交接。离职前一个月的工作交接,不能算交接,只能算转交,其实接手的人可能完全没接住,尤其是之前都没接触过这个项目的核心代码。

好的团队氛围还有一个比较关键的点,业务发展要好,只有团队业务发展好了,团队才能保持稳定,才有机会构建人才梯队,否则HC都没有了怎么培养接班人?只有每个人都有发展,有一定的技术挑战,有成长,才能稳定。所以要用业务发展解决团队里的各种问题,把蛋糕做大,团队成员每个人才能吃饱,只在团队内互相卷、做表面功夫大家都没有出路。

怎么把团队氛围搞好?有什么挑战?

根据上述好的氛围的解释,要搞好氛围其实说起来比较容易,但是做起来很难。我这块做的不算好,原因是部分业务发展没有达到预期,这就是搞好的团队氛围的挑战。这里就只讲一下我在团队氛围这块做了什么事情。

  • 给团队找方向
    • 项目1:高性能为核心优势,持续强化;以性价比为特色,持续完善
    • 项目2:降本、增加业务粘性、提升稳定性,练好内功
    • 项目3:用心维护、保持稳定、不出问题
  • 给团队找业务
    • 项目1:以项目3当前服务的业务为切入点,新增业务优先考虑使用项目1,后续再逐步切换
    • 项目2:以集团内部业务为主,挖掘增量,扩大营收,提高利润
  • 给团队立愿景
    • 项目1:将其打造成为存算分离架构下的最佳开源云原生分布式存储系统
    • 项目2:通过技术架构演进为业务降本,通过扩大存储规模来提升营收和利润,成为基础设施团队的重要利润贡献者
  • 给人才找发展
    • 根据个人意愿和业务需求确定个人发展方向,最终还是靠业务发展来促进人才发展
  • 给团队立标杆
    • 团队优秀案例宣贯,红黑星制度
    • 以身作则,践行公司3大价值观

此外,我接触过的程序员都比较单纯,没有遇到过勾心斗角、互相拆台的戏码,最多也就是在技术上争辩几句,无伤大雅。以后真遇到了这类人,肯定不会留在团队里。

任务分派

听过一个观点是说团队80%的工作是20%的人做的,如果团队内小伙伴都是差不多的级别,这个比例应该有点夸张,但是也有一定的道理。比如一个团队里有一个技术大佬,他一个人做的工作,可能是几个校招生都做不出来的,这样比较的话,比例就很高了。

任务怎么分?分给谁?

通常我会把任务分为几类,同时还要了解每个小伙伴的技术兴趣和发展规划,以及每个人的技术专长:

  • 重要且紧急:提需求给组长,沟通确认需求细节和优先级,初步评估复杂度,和当前人力分工以及任务饱和度,匹配最合适的人选,是否与当前工作有冲突,是否需要调整工作优先级或者更换其他人选
  • 其他任务:加入需求清单,根据需求重要程度和优先级,排入合适的迭代或版本进行开发,具体人选综合考虑任务所属模块和个人主动认领来确定
  • 线上故障:立即组织全体核心成员进行会诊,分头行动,快速修复
  • 架构师或技术大佬:沟通对齐项目面临最大技术/架构挑战即可,预研完成后的版本落地由其他中低职级的开发负责

小伙伴的技术专长这块怎么发现?怎么把任务分配到合适的小伙伴?

我通常是看简历、review其代码和文档、使用或测试其开发的功能、观察其做事风格、与其深入沟通技术兴趣点(通常兴趣点就是其专长)。

一个紧急不重要的任务,通常不太建议分给一个做事认真细致考虑全面(这不是说这种小伙伴不好,相反很好但不适合这类任务),否则极有可能超出预期完成时间。通常这类任务一般分给做事迅速果断,先撸一版上线不行再花几个小时改好那种同学。

一个大家都没有知识储备的调研任务,通常应该分给那些学习能力特别强、对新技术特别敢兴趣的小伙伴,他可以在短时间内了解这块技术的大致情况,并给出后续的研究方向。

而一个重要且紧急的任务,就要确保一次做到完美,并且要保证按期完成,那么技术能力和deadline意识很强、考虑问题全面、代码质量高的小伙伴就是首选。你不能指望一个过往任务都经常延期或者bug频发的人,突然接手一个重要紧急的事情,就能很好的如期高质量完成,工作习惯很难短时间改变。

有些小伙伴代码写的很好,但不擅长让代码跟人打交道,就是产品意识不足,做出来的东西没有bug质量很高,但是用起来就差强人意,用户感觉非常别扭,这类小伙伴通常适合做纯后端开发,不适合做接口、命令行工具、前端交互界面等类型的工作。

分配任务,当然也要看任务所属模块和模块的负责人,上面说的是模块有多个负责的小伙伴,或者新模块的情况,如果只有一个人负责一个模块,那就得考虑梯队人力了。

任务和技术职级的关系?任务的挑战/复杂度如何定义?

为了每个小伙伴都有各自的发展(直白点就是晋升),每个人要承担符合各自发展需要的任务,否则任务和职级不匹配,会导致人力浪费或者项目进度受影响。P5的人做P3的事,或者P3做P4的事情(33~41还好,跨多个级别就不合适了),都不合理。

所以要先把一项任务定义到所对应的级别,考虑好任务的复杂度和挑战,这需要比较多的开发经验才能作出合适的评估。我有时候也做不好,一般有两种方式来尽量准确,一是参考leader或者其他小伙伴的意见,二是先安排一个小伙伴去调研/PoC,而不是直接安排到版本去开发落地。

那么一些团队里必须要做的基础工作(比如日常值班解答用户问题,日常运维等等)怎么安排?通常新人会承担多一些这类任务,一来熟悉项目和业务,二来也符合级别发展需求。如果已经都比较熟练了,或者级别都稍高一点了,可以尝试值班排期,团队内部共同分担这类“杂活”,防止某些小伙伴一直“打杂”,影响他的发展。据我经验,很多小伙伴沟通的时候,一旦此类“打杂”工作过多(尤其是相对其他小伙伴),都会表达出来,如果再不解决,极有可能跑路。

绩效考核的时候,基础工作(或者“打杂”)其实对绩效的正面影响不是特别大,因为大家都做的差不多,除非某些小伙伴在运维的时候没遵守操作流程搞出锅了,这是减分项。重点还是看关键任务产出,所以一般在沟通的时候都会提前讲清楚这方面的事情。

怎么让每个小伙伴都有合适的发展路径?

一般来说,新入职的小伙伴,都是从周边非核心模块开始上手,搞出了问题,影响可控,不会给团队造成比较大的不良影响,等他把周边模块搞得风生水起后,也有新的小伙伴过来接手这块工作了,他就可以抽出来做更核心的业务模块了,这样也就有了自己的发展。否则一上来就做核心模块,学起来也吃力,大家也不放心,容易受打击。

高级别的小伙伴,关键要能给项目带来更高的价值,承担重任,关键问题能hold住,关键时刻能顶上去,关键业务能拿下来,组织绩效或者OKR就是靠这些小伙伴搞定的。业务拿不下来,OKR完成不了,项目都可能要被裁撤了,何谈个人发展?

最好的结果是了解团队中每个成员的能力和兴趣点,匹配项目目标,做到项目和个人成长的双赢。

领导业务

明确业务目标(制定OKR目标就是明确的一个过程),带领团队促进目标达成,上面的招聘、绩效、分工、氛围都是为了达成业务目标,都是具体的手段。

每个团队的业务和目标都不同,如何领导业务这块感觉也没啥好写的。

领导自己

领导自己也是为了更好的领导业务,为了领导自己做了哪些事情?

  • 多沟通、多倾听团队意见,共同制定改进措施,持续跟进改进效果并进行修正
  • 理论实践结合:读书、动手做事情(了解项目、了解团队成员,编译部署/找问题、写代码/review代码、写文章、写文档、宣传),了解项目和团队的优势和短板,扬长避短
  • 拓展视野:了解竞品进展和优势、接触用户、拿需求
  • 把项目放在心里:思考与竞品的差距和弥补措施、思考差异化发展路径、思考用户需求场景
  • 破釜沉舟的心态:把当前项目作为个人职业生涯的最后一个项目,没有退路,必须成功

目前我感觉到的自己的不足之处主要有:

  • 团队内部个别员工的积极性很难调动起来,苦口婆心没有效果,不知道怎么才能激励
  • 项目发展方向制定时怕犯错,担心试错成本
  • 个人的技术和产品视野不够开阔,对存储领域的理解不够深入,例如想做出差异化,但是又没有特别好的思路
  • 没有形成体系化的管理方法论,还比较零散,需要多学习、思考、总结、沉淀

其他应该还有一些,尤其是在领导和小伙伴们眼里应该还有不少,希望能听到更多你们的声音。

141. 环形链表

题目链接:https://leetcode.cn/problems/linked-list-cycle/

一开始被题目里的pos误导了,后面直接看了官方题解,让我做感觉不一定做得出来,第一种方法估计会想不到增加一个set或者map或者vector保存链表节点的地址,第二种方法更想不到。

 

94. 二叉树的中序遍历

题目链接:https://leetcode.cn/problems/binary-tree-inorder-traversal/

 

344. 反转字符串

题目链接:https://leetcode.cn/problems/reverse-string/

 

237. 删除链表中的节点

题目链接:https://leetcode.cn/problems/delete-node-in-a-linked-list/