做过几乎所有的研发角色
从2011年加入华为赛门铁克（下文简称“华赛”）算起，我在存储领域已经深耕15年了。
加入公司后，我的第一个任务是参与自研文件系统的预研。彼时文件系统真是一穷二白，没有产品，没有代码，我能接触到的只有一份十来页的设计文档。组里前辈还在基于这个文档紧锣密鼓地开发代码，而我们新来的每天的任务是学习文件系统相关知识。入职一个多月，我们拿到了第一版不到1万行的文件系统代码。基于这份代码，我们慢慢摸索Shell命令如何对接VFS（虚拟文件系统），又如何对接到具体的文件系统，文件系统又如何处理这些请求。
这段时期发生的两件事让我特别触动。一是我得知华赛设有一个保密室，专门存放赛门铁克的VXFS（一种高性能的日志文件系统）源码。尽管我们是合资公司的一员，但想进入保密室须层层审批。这种被“防”着的感觉，让我心里埋下一颗种子：一定要做出属于自己的文件系统产品！
另一件事是在一次培训中，讲师提到，我们的自研文件系统是基于XVE（一个无限智能的虚拟化引擎）平台构建，我忽然想起上一份工作有个项目需要一种特殊设备：一台主机宕机时，另一台主机能立即接管业务，不中断服务——那时的我就惊叹于它的先进与复杂。而如今，我们正要做这台梦寐以求的 “神奇设备”。世界如此奇妙。
这两件事对我影响很大。当我遇到困难想退缩时，它们就会从我大脑里蹦出来，提醒我坚持一下，再坚持一下，这一坚持就是15年。我见证了华为存储从起步到成为引领者的发展历程，也深度参与了Oceanstor系列、Dorado系列、A系列三代存储产品的研发，历经了软件开发工程师、业务组长、设计工程师、系统工程师、系统测试工程师等几乎所有的研发角色。
第一代文件系统的研发团队成员（左三为作者）
从一穷二白到自研主力产品
华赛回归华为后，我们加快了自研NAS（网络附属存储）的研发速度，规范和流程要求也严格起来。我们在XVE平台上将交付文件系统产品化，而我负责SIO（启动输入输出）模块的设计开发。
一开始，PL（项目主管）要求我按模板写一个SIO模块的设计文档，我质疑道：“SIO模块的功能很聚焦清晰，写文档的功夫，代码都写完了，费那劲不是浪费？”
PL耐心地解释：“现在清晰不代表后面也清晰，如果没有文档明确模块边界、子模块职责与接口规范，随着需求迭代，系统极易陷入混乱。更重要的是，这不仅是交付要求，更是你能力成长的练兵场。如果不借此锤炼设计思维，未来面对更复杂的模块，又将如何从容应对？”
这番话如拨云见日。我严格按模板输出了一份结构清晰、接口明确的设计说明书。正因前期设计扎实，后续开发推进顺畅、高效。最终，SIO模块高质量交付，现网运行多年，保持“零故障”纪录，至今仍是我在技术复盘时引以为傲的案例。
这段经历让我深刻领悟到：人的成长，始于对“不理解”抱有谦逊与开放。面对规则与规范，我们不妨先问自己：是规范有瑕，还是认知未至？许多看似繁琐的要求，实则是前人用经验筑起的护栏。待阅历沉淀、视野拓宽，我们方能读懂其背后的深意。
经过5年的发展，华为存储产品Oceanstor V3这栋大楼已经建成，SAN（存储区域网）和NAS的特性也慢慢成熟起来。为了进一步提竞争力，团队启动了硬件切换的预研项目——这也是Oceanstor V5的起点。我作为NAS软件移植的责任人，要让文件系统软件在全新的硬件平台上“跑”起来。
新硬件的一大变化是把X86 CPU（中央处理器）换成自研的ARM CPU。说实话，一开始我觉得挺轻松的：不就是换个CPU吗？底层驱动搞定，上层业务照跑，能有多难？我甚至有点小得意，这活简单、能出成绩，简直捡到宝了。
可现实，从来不会按剧本走。新机器刚到手，问题就接二连三地冒出来，设备动不动“躺平”。我们只能蹲在实验室，插着串口线，像老中医把脉一样，一条条看日志、猜病因。有时候折腾半天才能找到问题，如果问题出在硬件或者软硬配合上，我们必须把整台设备扛去硬件部修复。那时的我已经怀孕了，经常在成研L2和U7两栋楼之间拉着小推车来回走，就当散步了。
经过一段时间努力，硬件的问题趟得差不多，不会动不动变成“砖”了，可软件又开始“闹脾气”。
一天，测试同事发来消息：“新机器跑业务时宕机了！”
我赶紧导出栈信息一看，心一沉：出问题的地方，是我们跑了好几年的老代码，从来没出过岔子。我的第一反应是 ：“肯定是别人踩了内存！”于是立刻加监控、埋钩子，想抓那个“肇事者”。
可怪事来了。操作一上，问题就消失了。它就像个幽灵，只在你最松懈的时候现身，等你布好天罗地网，它又销声匿迹。接下来两个来月，我们轮番上阵。我反复读代码，拉上几个资深同事一起“会诊”，测试兄弟也一有空就试着复现……可那bug（缺陷）就像故意躲着我们，始终不肯露真容。
版本逐渐稳定，测试加大了压力。突然，它又出现了——而且不是一次，是在两个不同 B 版本、两台不同设备上，同一个函数、同一段栈。那一刻，我脑子“轰”地炸了：不对，这不是偶然踩内存，问题就藏在这段看似无懈可击的代码之中！可为什么过去几年都没事，偏偏现在出问题？差异点在哪里？CPU 核数变了，压力增加了概率？……一个念头从我的脑子里闪过：是不是多线程配合出了问题？
我屏住呼吸，重新一行行走读那段熟得不能再熟的逻辑。终于，在父子任务协作的缝隙里，我揪出了藏得极深的幽灵：在高核数环境下，多个子任务可能全部先于父任务完成，并提前释放父任务的上下文结构。而此时，父任务线程还在运行！它茫然不知自己已被“注销”，访问了已释放的内存。
两个多月的迷雾，就此散开。
这个教训刻骨铭心：ARM众核架构，不是x86的简单替代。那些我们习以为常的多线程模式——父子任务、生产者消费者，在高并发下都成了“雷区”。bug不是明显的逻辑错误，而是潜伏在时序缝隙里的幽灵，稍不留神就会引爆系统。我们痛定思痛：建立多线程编码规范、梳理所有高并发场景、对存量代码逐项排查整改……每一步，都是用血泪换来的经验。
一年后，OceanStor V5成功量产，成为我们的主力产品。命运似乎也在悄悄奖励我们的远见。2019 年，当制裁突至，许多产品线陷入断供危机时，存储业务受到的影响较小。因为早在风暴来临前，我们已经把“命脉”握在了自己手里。而那个在实验室盯着串口日志、满头雾水的我，大概没想到自己也参与了一段未来会被反复提起的故事。
Oceanstor V3和V5版本统一存储，实现了SAN和NAS一体化架构，用一套架构应对结构化与非结构化数据增长。华为存储入选Gartner魔力象限“领导者”象限，其全球竞争力得到认可。而我也完成了一个存储小白到设计工程师的转变，具备了跨模块设计的能力。
Oceanstor V5文件系统的研发团队成员（右三为作者）
打造Dorado产品的“杀手锏”
2017年，华为存储全力推进新一代全闪存架构产品Dorado上市，我休产假没能赶上Dorado的第一班车，本来还担心自己技术脱节。但很快，机会就来了。2018年，我休完产假刚回到工作岗位，部门就找我沟通，要我切换到SAN业务领域，参与新一代全闪架构Dorado产品的开发工作。我欣然接受了安排。
Dorado V3上有支持持续数据保护和快照一致性组两个特性，涉及 6个子系统、9万行代码，规格要求极高，但交付周期却只有5个月。由于两个特性深度关联，部门决定将两个特性打包组建交付团队，可是谁来做FO（特性负责人）呢？
没等我发表意见，项目经理直接摊牌：“其他人我不太放心，必须你来担任FO。”就这样，在全新的领域和新的架构上，我迎来了一次新的挑战。
不只我是新人，团队很多其他成员也刚转过来。新人多，业务难，工期紧，业务不熟练……各种困难叠加，我的压力值拉爆。但我心里有个执念：我没能赶上全闪化的首航，当前必须迎头赶上。
我一边熟悉现有业务，一边和特性的设计负责人梳理需求、规格和方案。随着对特性理解的深入，我逐渐理清了两个关键点：一是北向接口，需新增5个MO（管理对象），各类接口超300条，评审入库极耗时间；二是空间回收机制，这对现有业务的理解和编码功底都有相当高的要求。
针对北向接口，我安排专人负责和可服务性SE（系统工程师）对接，一看他工作软件在线就给他打电话，对方也很头疼：“你们一打电话，我脑壳就嗡嗡响……”“我们也很无奈呀，要不你每天早上留一到两个小时给我们，这样集中时间、有计划地评审，效率和效果都更好。”就这样，我们和可服务性SE达成了一致，评审效率极大提升。
针对空间回收机制，我们要重构优化现有代码，既要熟悉现有机制实现，还要满足新的诉求。我提出了一个策略：最复杂的部分，不能靠人海战术，得依靠“尖刀兵”单点突破，而这只能靠特性设计责任人了。我快速和他达成一致——他负责空间回收的方案和实现，扎进核心算法的深水区攻坚，而我扛起外围功能的设计、联调与集成。我们像两把互补的利刃，一内一外，稳步推进。
最终，我们如期交付了持续数据保护与快照一致性组两大特性，达到了当时行业标杆级的能力——秒级RPO（恢复点目标，指业务系统所能容忍的某段时间范围内的数据丢失量）。这个特性迅速成为产品“杀手锏”，助力华为在多个银行核心项目中成功中标，持续作为产品的技术门槛和亮点特性。
两次临危受命
此时，在Dorado架构上支持NAS变得刻不容缓。鉴于我在上一代产品Oceanstor NAS领域的积累，我被任命为新项目的设计工程师，负责NAS增值特性快照、双活、VAAI（阵列集成应用接口）的设计和交付。
做NAS“双活”特性设计时，摆在我们面前的有两个方案，一个是继承Oceanstor V5的方案，交付风险小，但特性性能毫无竞争力。另一个是重新设计，但从技术难度和交付时间上都有极大风险。我认为，“双活”作为存储的高端特性，本来就要做到两个中心同时工作，数据实时同步——一个中心故障，另一个中心自动接管业务。没有竞争力，做出来也是失败，我们别无选择。
瞄准第二个方案，版本SE小华姐把复制、文件系统、卷管理、系统控制等NAS软件栈上几乎所有领域的骨干，拉到会议室封闭攻坚，我作为文件系统领域的设计工程师参与其中。经过近一个月的攻关讨论，我们完成了新方案的理论论证。这给了我极大的触动，在特性竞争力和交付进度风险之间，我们必须选择竞争力。
到了交付最后阶段，版本PM（项目经理）找到我，称当前遇到了一个棘手的问题：创建满规格dtree的文件系统，“双活”分裂后创建满规格快照，再启动“双活”同步，同步时长长达数天。分裂后未下业务仅产生了快照配置，无差异数据。这个同步时长严重不合理，客户无法接受，需进行优化。
数据同步的实现主要依靠Volume（存储卷），虽然我只是文件系统领域的负责人，但有volume开发设计经验，所以被指定为问题的分析责任人。我介入后迅速判断，这个问题在Volume解决不了，必须从更上层的文件系统切入。
“有解决方案么？”PM问。
“方案是有，但工作量有两千行代码，离TR5只有1个月了，代码量大，稍有不慎还可能引入双活主从数据不一致问题。”但看着PM焦急又为难的神情，我又补充道：“给我一个星期，我来修改，保证高质量交付。”
一个星期后，代码如期上库。同样的场景下，数据同步时长从7天降为10分钟，且代码未引入任何问题。我零缺陷达成了对PM的承诺。
时间来到2023年5月的一天，领导突然找到我，语气急切地说：“Volume组现在非常困难，急需你去支援。”我虽然在这个团队待了一年多，但并不熟悉全部业务，且时隔4年其业务范围也发生了巨大变化，说实话，有些为难。但面对这个曾见证我斗与成长的地方陷入困境，我又实在难以推辞。
进入业务组后，我发现现实远比我预想的更加严峻：一个业务组的问题密度占整个版本的半壁江山，超过了第二至第四名业务组的总和。需求堆积如山、历史债务沉重、现网问题频发、版本测试阻塞严重……巨大的业务压力让所有人喘不过气，士气低迷。四方八面的人都在说：当前版本交付的最长路径在Volume。领导嘱咐我：“一定要把Volume搞定，否则版本就悬了。”
Volume模块在存储系统中处于“十字路口”，几乎所有的上下游问题定位、方案对齐、需求澄清等，都需要Volume团队深度参与。我快速梳理情况，发现核心瓶颈集中在几个关键特性上：NAS快照空间回收、UNMAP（解除映射）、NAS“双活”和SmartMove（智能移动）。于是，我和组内一位技术骨干分工——他主攻双活与SmartMove，我聚焦快照空间回收和UNMAP的技术债务清理。我笃定，只要从乱麻中找出几根关键的线头，整个业务就能逐步“解套”。
我接手了全组的需求分析与跨团队的方案设计讨论工作，同时主攻NAS快照空间回收和UNMAP两大技术难点。针对NAS快照空间回收，我从可定位性、可维护性、异常主动检测与兜底机制、回收性能等多个维度，提出了20余项优化措施，并按照快速止血、优化改进稳步推进落地。这样一来，特性质量很快稳定下来。
UNMAP这块“硬骨头”格外硌牙。这是一个困扰团队长达十年的老大难问题：一方面，我们无法准确掌握上层应用，如VMware、AIX、Windows等，对UNMAP命令的实际处理行为；另一方面，受外部制裁影响，我们无法得到原厂技术支持。改动稍有不慎，可能引发更严重的问题。
不过，我想到一个终极解决方案——将UNMAP后台化。天下武功，唯快不破，只要性能足够强，问题自然消失。但该方案涉及上万行代码，短期内无法交付，远水解不了近渴，而那时维护负责人明确要求：方案必须要能制作热补丁，否则无法解决现网问题。
彼时的我也曾抱有一丝希望，试图用一个简洁方案“一招制敌”。我联合测试团队一点一点地调整场景和参数，对照梳理不同主机操作系统对UNMAP在并发、时延、重试等方面的处理特征与诉求。一年内，我们尝试了十余版方案，虽大幅改善了很多场景的问题，但剩余的场景就像打地鼠，一个问题解决，另一个问题又冒头，无法实现稳定的平衡。
这段攻坚历程最终告诉我们，我们无法通过简单、可在落地补丁的方案彻底解决UNMAP顽疾，唯有从根本上提升UNMAP的处理性能，才能真正终结这一历史难题，这也为后续我们坚定落地后台化方案提供了坚实的依据。终于，在我加入团队一年半后，我们在第三个版本上背水一战，将Volume业务组带出了泥潭——Volume组不再是版本的短板，彻底掉出版本问题密度前三名。
自此，Dorado凭借高性能、高可靠，成为金融等行业的首选，我也持续在数据保护、安全快照、“双活”等多个价值特性浇筑心血。
数据存储平台测试部团队合影（前排左四为作者）
新领域，新角色，新征程
十五载春秋，作为一个女工程师，我努力克服了婚育带来的职业发展空窗期的迷茫和挑战，在工作和家庭中寻求着动态平衡：在项目攻坚期，以工作为重；在孩子生病或家庭关键期，以家庭为重。在工作中，不因家庭角色的转变而限制自己，让自己的成长与存储技术的演进保持同频共振。在工作之余，我尽心地陪伴孩子，用心地规划家庭出游，有时间就做做饭。
2025年，鉴于我在存储领域的积累，加上当前AI、高速网络、存算融合的快速发展，我转入了新的领域——测试，有了新的角色——TSE（系统测试工程师）。虽然依然面临诸多困难与挑战，但得益于过往诸多岗位的历练，我能更加从容、系统地应对复杂局面。
我相信，只要保持对技术本质的执着，踏实地在每一个角色、每一次挑战中做到极致，就能在时代的浪潮中稳住自己的节奏，书写属于自己的故事。
