昨天收到提名通过的邮件之后，就开始着手准备答辩PPT，但是思来想去，感觉要写的东西比较多，想要在20分钟讲完讲透，一时半会儿还挑不出重点，写PPT确实不是我的强项，干脆先都先用文字写出来，再从里面挑选重点内容放到PPT里面，也算是一种对这几年工作的全面回顾和反思，以后万一哪天不得不更新简历的时候，也能有点素材。

晋级可以不提名，可以不通过，但是不能不反思不正视自己的不足。权且把答辩当作一次面试。

刚毕业在华为工作，有一句话我印象非常深刻：“板凳要坐十年冷”。要成为大佬，就要耐得住寂寞，顶得住压力，眼光放长远，切莫急功近利。我比较鄙视的一种行为：挖个坑，晋个升，跑个路，循环往复。这么玩儿几次就把自己的技术声誉败光了，我对自己的技术声誉和职业道德还是有信心的，做项目的第一原则：尽量不给后人挖坑，除非真的到了我能力上限。

需要声明的是，如下项目除了前两年我自己做开发的时候自己动手做了不少事情，后面两年其实都是团队小伙伴们实际动手做的，我只能提出想法和规划，毕竟一个人的能力非常有限，项目的成功都是小伙伴们的功劳，项目做得不好，负责人的问题最大。

• 作为事业部内公认的某方面的专家，能够解决较复杂的问题或领导大中型项目；
  • 前面半句比较抽象，也不好自我证明
  • 后面半句更具体一些，我理解要么就是解决某一个专业方向的业界技术难题，以我略懂的云计算领域来举例，你要可以解决底层虚拟化性能问题，优化之后能达到业界领先水平，或者在提升计算资源利用率方面做到业界领先，或者在网络方面性能水平达到业界领先（而不是仅仅用开源跑起来），存储领域你就要对标业界主流开源项目的性能和可靠性（最好可以超越），或者你可以成为某个大型开源社区的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团队规模，最多的时候有超过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水平。

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卡故障、网络丢包等），我们也会补齐对应场景下的监控告警，可以做到第一时间发现抖动的根源，并及时上线进行处理。

优化前：

优化后：

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团队我是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规划支持

文件存储方向上怎么做出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团队也在于我们共建，已经测试出来一些性能数据，更多的场景还在测试中。

团队里李小翠，在架构设计调研方面做得最到位，报告写得最详细，能把各个场景都考虑的非常细致全面，写代码一定是谋定而后动。

Curve块存储最大的优势之一就是高性能，与主流开源项目Ceph RBD相比，小文件随机IO性能远超RBD（时延也是有很大优势），大文件顺序IO场景与其持平。但是只做到这些肯定是不够的，在云原生数据库场景下，数据库对底层存储的性能尤其是时延要求是极高的（时延越低越好，就看我们能做到什么程度），如何保证Curve的高性能优势持续领先？这也是我们面临的一大挑战。

Curve块存储：

• 全链路瓶颈梳理
• 大文件顺序读写性能优化
• raft相关优化
• 高性能硬件适配

Curve文件存储：

• 元数据性能优化
• 数据面性能优化
• FUSE优化
• 多级缓存

高性能硬件适配这方面的工作，还是得靠大佬出手，我们团队高级专家徐逸锋，绝对的实力派资深码神，与阿里多隆不相伯仲，相关适配已经在开发扫尾阶段，近期将会有测试结论。文件存储的元数据和数据面性能优化方面，团队里新秀王海和吴宏松也有不错表现。

上面每一项展开来写，都是一篇技术文章，感兴趣的可以看一下curve公众号文章，或者更早之前的文章在网易杭州研究院的公众号里。

CurveBS对大文件顺序IO的优化：

CurveFS元数据性能对比：

CurveFS数据面性能对比：

安装部署是一个软件的入口和门面，自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。

功能\工具	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对象存储服务，已经上线运行10年，服务了集团互联网几乎所有的事业部，业务数据量xxPB，并将持续发展。但是NOS也面临非常多的问题，我早在20年底就已经基于存储团队内部调研结果加以整理说明过（这里摘录一部分与NOS相关的，括号里面是当时我的评语）：

1. 员工长期保持激情：架构、盈利、成本综合考虑，单纯的考虑某一方面很难长久留存员工（注：这条建议很好，但也比较有挑战；比如架构升级一般都是由业务需求来推动的，盈利和成本这块可以内驱，但如果增量太少，比如nos，也不好做）
2. NOS历史包袱比较重，建议要从长期考虑进行整体架构优化和调整，只关注短期目标很难把业务做稳做实（注：短期主要是指新的存储技术，新的业务拓展，成本优化等，这块已经很多模块处于停止维护状态，但其实还是会有新的模块加进来，后续是不是会变成历史包袱，很难说，只能尽量避免，代码和架构总有腐化的时候，不可能扛几年甚至十几年）
3. 所做产品的价值体现不出来，考评吃亏（注：主要是指业务规模上不去，但又很难拓展，这条说的比较实际，我本身也有这种困扰；内部客户量上不来，虽然说可以拓展外部客户，但从底层平台来说，没有完善的产品，确实难走商业化的路子，基础设施这块应该都有类似的问题）

类似我上一篇文章《我是如何带团队的》里面的叙述，项目遇到的问题首先要考虑的解决方案就是把项目的业务发展好，用业务发展解决内部矛盾。

当时做这个调研整理的原因，也是因为项目组人心涣散，前景一片模糊，非常不明朗，看不到希望，团队在21年初只剩下了3个人（其他人都跑路了，离职率50%）。所以下面的挑战项，也是基于这次调研而定义的。

这个是技术细节问题，但是其本质还是成本问题，先修炼好内功，才能赢得用户。

小文件放置策略、小文件合并策略，直接影响底层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项专利。

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副本引擎的历史遗留问题（都是老大难），后来还把冷归档高质量、高效率的做完了，为人还非常谦虚低调，觉得自己什么也没做。

集团降本增效的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未来