漫谈固态硬盘SSD全生命周期的质量管理

SSD架构中，包括了SSD控制器、NAND颗粒、DRAM颗粒三大组件，SSD控制器的固件需要兼顾坏块管理、ECC纠错、垃圾回收GC、磨损均衡WL、NAND die介质管理、缓存交互等等。是一项复杂的工程。

在用户使用过程中，SSD常见的故障现象通常有多种情况，其中FW固件异常占比最高，达到60%，硬件异常达到10%，其他问题占比30%。也就是说通常看到的SSD故障，有70%是真实的故障，硬件或者固件的问题。另外其他30%的问题原因会各种各样（扩展阅读：如何快速debug定位SSD延迟问题？）。

• 高温异常。SSD在持续大压力读写的场景，加之散热不能完全，导致温度急剧升高，高温影响会导致或者加速硬件出现异常，常见的是性能降速，在系统下看到IO hang或者IO 抖动的异常。

• 硬件在物理层面的破坏。如果出现外力导致SSD的外壳或者内部器件出现破损，此时会影响到SSD PCB板子上电子器件的可靠性和稳定性，出现意外事件，甚至最恶劣的情况会导致数据丢失的可能。
• 使用方式错误。SSD通常是基于NAND颗粒，存在NAND介质本身特性的寿命限制，如果持续出现高写放大（扩展阅读：SSD写放大的优化策略要统一标准了吗？）的情况，也会导致寿命提前损耗，SSD提前退役了。还有一种情况，就是在SSD使用过程中，频繁出现突然掉电的情况，使得SSD经常性处于异常的使用环境，也会加速盘的异常。
• SSD FW固件异常：固态硬件的固件Firmware内部包括了SSD的FTL算法，读写逻辑，ECC纠错等算法，非常复杂，出现FW bug的概率也相当高。或者出现盘内部异常，FW出现锁死的情况，导致盘处于只读模式或者无法访问的状态。
• SSD硬件异常：在企业级SSD中，通常会遇到大电容异常，控制器内部bit flip导致meta data异常，甚至还会遇到NAND介质工艺问题导致NAND出现介质相关的异常。

业内通常的FW Qual的流程如下：会先后经历Design Coding、EVT、DVT等阶段。

• Design Coding阶段：主要验证代码基本功能的可执行性，并通过软件模拟的方式发现一些代码的初级问题。
• EVT阶段：这个时候已经有工程样品了，拿到实体的SSD进行功能验证和性能验证，发现早期FW设计漏洞或者硬件设计异常。
• DVT阶段：会系统性的增加更多的测试，长期可靠性，包括RDT等。发现一些规模上量后才会发现的概率问题。

虽然经过了相对系统的FW Qual流程，FW固件异常的出现依然有多种因素：

• FW设计隐藏一些bug：比如FW设计中的计数算法、时序算法、内存分配、介质管理参数设定不符合预期导致寿命提前磨损等，这些问题，通常验证过程，并不容易发现。需要一定几率的触发或者特定场景corner case触发。
• FW管理中的低级错误：FW固件开发不是一个人的工程，是一群人的工程。每个开发工程师都会向master分支提交代码。在代码量相对庞大的时候，会出现一些低级错误，原本fix的问题，在后续代码提交过程给覆盖掉或者漏掉了。最终导致已经解决的问题，在后续更新FW版本中，重新再犯。对于FW稳定性这一环节来讲，是不可宽恕的
• FW架构的修改诱发其他问题：FW是一个复杂的系统，牵一发而动全身。任何一个参数、变量的修改，都可能会影响其他的代码。代码修改后，需要完整验证整体的可靠性和影响。一名代码开发人员，一定要对代码保持敬畏之心
• 
  

SSD质量的整体保证，需要从NAND颗粒、FW固件、SSD Qual质量、SSD运行质量完成全生命周期的端对端E2E质量管理。

在追求SSD质量的过程，为了让质量管理形成一个可持续性的工程，需要形成“设计前移”的思路。在工程样品、量产后、客户大规模上量等环节遇到的各种问题，可以快速形成优化思路和核心点，反哺产品设计。通过持续的优化反馈，使得SSD的质量管理得到持续的完善。