系统易用性

1. 分清可靠性和可用性

• 什么叫做可靠性？
  设计了一款软件，不小心引入了一个bug，导致了输入1+2，软件返回结果4，这就是可靠性很差。通常通过测试用例，就能很快将其修复。

• 什么叫做可用性？ 还是上面的例子， 输入了1+2，软件没有丝毫反应，不返回结果，这就是可用性很差。通常很难有头绪，将其修复。

2. 导致可用性差的原因

• 资源耗尽
  当程序需要执行时，硬件资源使用快达到最大阈值，无法正常运行

• 上量之后，流量变大
  软件使用者越来越多，当初设计的架构不足以支撑这么大的量

• 外部依赖
  随着功能丰富，外部依赖逐渐增加，一旦某个依赖出问题，软件系统也受到了影响。

• 技术债
  伴随功能需求增多，交付压力增大，有些时候，不得不牺牲质量，赶在deadline之前完成，这就导致了有些优化重构未进行，软件实际变成了功能的堆砌，形成技术债。

3. 解决可用性差的方法

• 要有观测系统运行状态的手段，记录系统每日运行的数据，通过分析数据提早发现问题。借助现在的大模型，分析数据是它专长。

• 能自动化的部分，不要人工进行，像一些环境的部署、软件系统一堆参数的设置，用人工进行不仅枯燥无味，而且容易出错。

• 进行有效容灾，比如1+1或者1+N主备。

• 管理技术债
  对技术债，建立风险管理模型，可以从以下几个方面进行：

  • 找出那些缺陷
    这些可能是来自研发自身开发代码过程中，也有可能来自市场人员发现某些功能实现有问题或者缺失，也有可能来自客户反馈。
  • 波及的影响
  • 界定风险等级
    给风险划分相应等级，从而区分处理策略。高中低，哪些需要立即处理，哪些可以暂时不处理。
  • 评估可能性
    划分发生的概率，可能性大中小。
    如果修改它，需要投入的人力大，且它发生的几率不大，或者造成的影响可承受，那就由它，不然得不偿失。
  • 缓解方法
    当它发生时，有没有缓解方法，暂缓或者避免它造成严重事故

下方的表格可作为参考：

风险项	具体内容	团队	发现时间	风险等级	可能性	缓解方法	是否解决	解决时间