背景介绍
设计DFR技术
DFR是指在产品开发过程中，通过一系列的技术活动，消除产品的潜在缺陷和薄弱环节，防止故障发生，以确保满足规定的固有可靠性要求。DFR的目的是确保产品在预定使用环境下能够稳定、可靠地工作，减少故障发生的概率，提高产品的使用寿命和用户的满意度。在许多情况下，DFR发生在设计阶段，而且是在制作物理原型之前，其通常可作为整体卓越设计（DFX，Design for eXcellence）战略的一部分。成功的DFR需要将产品设计和流程规划集成到被称为并行工程的统一交互式活动中。
软件DFR
产品开发一般涉及软件和硬件结合，不同领域有各自的DFR技术和设计原则。本文着重介绍通用的软件DFR设计原则。
从openUBMC业务软件的运行环境及业务软件本身来看，可通过以下标签进行划分：系统资源、系统环境、业务进程、业务线程、网络通信、文件管理、数据库、主备管理、数据管理、固件升级、日志、用户操作。
系统资源
系统资源包括CPU、内存、目录空间、磁盘IO、网络IO、文件句柄等关键资源。系统资源容易出现过载、资源受限等问题，需要对关键指标做监控。
- 【要求】关键的系统资源指标需要有过载检测；
- 【要求】系统公共资源需要有统计机制，如CPU、内存占用、磁盘IO、网络IO，统计精细到进程粒度；
- 【要求】内存受限系统要提供内存泄漏检测机制；
- 【要求】共享资源需要有隔离机制，避免资源独占或互相影响。共享资源包括总线、共享内存、共享存储、共享队列、分布式锁、系统调用等；
- 【要求】目录需要限制最大占用空间；
- 【建议】过载状态下记录系统资源统计记录日志；
- 【建议】过载状态下业务丢弃数据记录日志；
- 【建议】检测关键目录剩余空间，低于阈值时告警并提供清理或垃圾回收机制。
系统环境
系统环境变化，如系统重启、系统挂死、时钟跳变等，需要有对应处理措施。
- 【要求】业务软件必须有时间跳变的处理措施；
- 【要求】业务软件例测周期不得依赖于系统时间；
- 【要求】限制短时内复位次数。
业务进程
业务进程异常，如进程创建失败、异常退出、挂死等，要有对应处理措施。
- 【要求】重要业务进程需要有守护进程；
- 【要求】守护进程要有感知自身卡死的能力，如watchdog;
- 【要求】业务进程要有进程级独立重启恢复能力；
- 【要求】业务进程异常退出后可自动重启恢复；
- 【要求】业务进程故障可感知并由对应的恢复措施，故障不限于进程崩溃、D/T/Z状态、死循环、内存/fd/thread资源泄泄漏；
- 【要求】进程重启不产生不合理异常，如误告警；
- 【要求】大颗粒业务处理需要有资源占用控制机制，如切分业务处理防止CPU持续冲高；
- 【建议】进程启动过程保护，避免故障导致进程启动失败。
业务线程
业务线程异常，如线程创建失败、异常退出、挂死、线程过多等，要有对应处理措施。
- 【要求】显示临时线程的最大创建数量；
- 【要求】确保线程退出后资源完全释放；
- 【要求】重要业务线程要有异常检测和恢复机制，如心跳设计；
- 【建议】批量任务执行时应容忍单个任务失败。
网络通信
网络通信异常，如会话过多、会话挂死、丢包、乱序、非法消息、消息过载、消息超时、连接超时等，要有对应处理措施。
- 【要求】端侧应对网络通信异常做预防和异常处理；
- 【要求】网络请求必须设置超时时间；
- 【要求】网络请求失败时应作重试，并设置最大重试次数；
- 【要求】接收网络数据后要有合法性、完整性校验；
- 【建议】特殊网络数据要有数据一致性校验机制，如多节点同步数据、实时数据；
- 【要求】限制最大网络通信连接数量，对超限情况要有恢复机制；
- 【要求】网络消息接收和处理要有限流机制，如限定接收队列长度、触发网络反压等；
- 【建议】网络消息异常检测、限流应该在消息接收处理的上游环节完成；
- 【要求】异常报文在检测到异常所在的处理阶段丢弃，不能把异常报文传递给下游。
文件管理
文件涉及的异常情况包括文件丢失、文件超大、文件受损、文件操作失败等。
- 【要求】重要文件丢失、损坏时影响不扩散，不影响系统业务或导致系统重启；
- 【要求】文件读写必须考虑数据损坏及其容错，如读写失败；
- 【要求】重要文件应该有备份和恢复机制；
- 【要求】大文件存储需要限定其最大空间占用；
- 【要求】频繁更新的文件必须flash写入量过大问题并由消减措施，如限流、限制最大写入量等；
- 【要求】防止重要文件因目录空间满导致文件操作失败；
- 【建议】大文件隔离存放在空间固定的目录下。
数据库
数据库操作异常包括连接失败、连接资源耗尽、性能下降、表项过多、查询超时、匹配项过多、flash写入量过大、文件损坏、数据篡改、主备不一致等。
- 【要求】支持数据库状态监控；
- 【要求】频繁更新的持久化数据写入要有缓存机制；
- 【要求】支持数据库大小或数据条目数量上限限制；
- 【要求】支持数据删除策略，泛指数据持续增加而不删除；
- 【要求】flash写保护生效时禁止持久化数据库写操作；
- 【要求】使用分页等限制检索量的功能，防止查询结果集过大。如联表查询，易产生大量匹配项，影响系统IO性能、数据库性能和占用大量系统资源；
- 【建议】支持数据库所在分区的空间余量大小检测‘
- 【建议】数据库写入增加回读校验和重试机制；
- 【建议】支持数据库可用性和性能监控，支持数据库关键资源监控，不限于监听器状态、进程状态、表空间、大表水位、日志空间、连接数、锁资源数。
主备管理
主备管理要注意主备通信丢失、主备不一致、主备故障、倒换等场景。
- 【要求】支持备用单元故障检测，避免静默故障；
- 【要求】保持运行时主备间配置数据和运行数据的一致性；
- 【要求】避免出现双主、双备状态；
- 【要求】支持主备间通信及其通信检测，主备间通信中断时告警；
- 【要求】支持升主前健康检查；
- 【要求】支持自动倒换，主用设备故障时备用设备自动升主并接管业务；
- 【要求】支持倒换抑制，避免反复倒换；
- 【要求】提供手动倒换手段作为异常逃生通道。
数据管理
数据管理要注意输入、数据受损、数据老化、冗余存储、数据恢复、数据关联等场景。
- 【要求】重要数据支持备份，且主用数据被破坏时备份数据能启动；
- 【要求】保证数据合法性，避免外部输入数据异常导致系统异常。合法性是指数据类型和数值有效；
- 【要求】保证数据完整性，避免外部输入数据异常导致系统异常。完整性是指逻辑、结构和时序上不存在错误；
- 【要求】重要数据定期备份（时间冗余），支持周期性全量、增量备份，误删除或受损数据可通过备份恢复；
- 【要求】重要数据多副本备份（空间冗余），受损数据可通过备份恢复；
- 【建议】重要数据的冗余备份数据保持一致性。
固件升级
固件升级涉及升级包检查、升级前异常检查、升级后验证、升级失败回退、升级不影响业务等。
- 【要求】软件升级或补丁操作不中断业务；
- 【强制】升级前对软件环境、硬件环境做健康检查，检查失败不做升级；
- 【要求】升级前对升级包做完整性和合法性检查，检查失败不做升级；
- 【强制】支持升级过程故障保护，升级过程限制对升级有影响的后台任务、维护操作等，避免升级失败；
- 【要求】支持固件升级、生效与业务互斥处理，避免升级过程业务出现非预期异常，如误告警；
- 【强制】支持升级过程出现重大异常时快速回退。
日志
日志相关异常包括日志刷屏、资源过载、flash写入量过大等。
- 【要求】flash写保护生效时禁止写入持久化日志；
- 【要求】频繁触发的日志记录要有限流机制，限流机制覆盖系统或进程反复重启场景；
- 【强制】日志类文件必须有滚动清楚旧数据的机制；
- 【要求】应用层进程或服务的日志避免在关键分区存放，如根分区；
- 【要求】日志记录不影响系统稳定运行；
- 【要求】第三方库、组件日志记录要有限流机制；
- 【建议】日志文件隔离存放在有空间大小限制的目录下；
- 【建议】日志有单独分区存放，避免被其他数据覆盖。
用户操作
用户操作涉及用户配置、删除操作和批量用户操作。
- 【强制】支持配置数据合法性检查；
- 【强制】支持对用户输入的防御和保护，如用户输入的合法性、有效性检查，重复提交、异常输入不影响系统正常运行；
- 【要求】防止用户直接删除或修改配置文件；
- 【要求】关键数据高危操作支持二次确认机制；
- 【要求】限制单个用户可创建任务的最大数量。