今年情人节思明区登记的新人比2014年少了一半多

在信创IT转型如火如荼的趋势下，IT业务系统首先要保证的是业务的稳定性。

其实在这个过程中有两个阶段的考量：

1. 业务如旧，正常运行。
2. 业务变化（包括业务量和业务形态），仍然保持稳定。

功能的保证是毋庸置疑的，是最基本的，验证也是相对简单的，不管是手工还是自动化，都已经有成熟的经验和工具了。

但非功能能力的保证就复杂了。 我们经常在信创相关的文章中看到这样的图：



（以上图来自网络）

也就是说现在信创产品其实也是不少了，至少看起来不少了。

可能有人说，这里面有大量的产品是来自于开源产品的小修小改，所以不值得庆幸。

其实在我看来，只要从源代码开始掌握在自己手里，这就已经是非常大的进步了。

在资本横行的互联网业务场景疯狂扩张的前十几年中，我们的技术市场过多的关注了上层业务的能力，对基础设施技术人员的需求缺口（高工资的也集中在这层）也多在业务上。

IT基础技术的能力要求并不少，但相应的职位工资偏低，并且相应的职位也更需要沉静的心态，需要多年的打磨，从而导致了很多人不愿意选择，毕竟大家都要生存。

这就导致了现在做信创国产化的替代时，市场上技术人员的缺口也是非常明显的。

在信创趋势下，可以看到，很多岗位的职位能力都是欠缺的，进而导致很多信创产品看似已经有了，但是替代能力仍然不足。

再进一步导致了IT系统的非功能能力得不到保证。这也是信创国产化转型过程中必须经历的阵痛。

对于一个IT系统来说，非功能能力是需要平衡的。

就像上图看到的一样，每一个特性的不足都会导致整个IT系统出现不平衡。但是，如果在某个特性上做得过多也会导致不平衡。

在之前的一篇文章《从阿里云崩溃看IT系统非功能能力验证》中有这样的一个图。

其实对于一个IT系统的非功能特性描述，在大家的脑子里可能不止这些，为了更全面地整理非功能特性，我也搜索了不少的资料。如这些：

也查了一些国际标准、国家标准。得到的结果是：仍然没有统一的说法。所以根据查到的材料和自己工作过程中的总结，在我的非功能体系中把非功能特性分为：

运行状态10类：可用性、性能、安全性、可扩展性、灾难恢复、易用性、互操作性、兼容性、鲁棒性、可靠性。

非运行状态6类：可维护性、可移植性、易安装性、易替换性、可管理性、可监控性。

针对上面的各个特性，我也进行了定义，先放两个在这里给大家参考：

可用性的质量属性属于运行期质量，运行期质量描述运行态，与服务、部署、资源配置相关。可用性主要考察服务在运行过程中，服务、部署、资源配置出现故障或参数配置问题时业务的表现。

可扩展性是指对系统与应用的处理能力设计的指标。通过增加或者减少资源时（例如CPU、内存、存储、网络、服务节点等），实现整个系统处理能力的增加或降低。

当然这个划分，可能你觉得不合理，也可以自己定义。

即便是有了这些定义，也仍然不可验证。因为每个特性都是需要有具体的技术实现支撑的。

比如可用性，它靠什么支撑呢，非常典型的技术实现就是负载均衡了。在信创技术栈中，我们经常会讨论应用层的微服务分布式架构，在这样的架构中，负载均衡有多少种具体的技术实现呢，拿常见的ribbon实现的负载均衡策略来说，就有七种：轮询策略、权重策略、随机策略、最小连接数策略、重试策略、可用性敏感策略、区域敏感策略。

在一个具体的应用中，要选择哪种策略取决于业务需要，可能我们最常用的是默认的轮询策略。这里我们就以此为例，来把上面的描述串起来：

$$可用性?应用可用性?负载均衡?ribbon?轮询策略$$

这样的话，我们要验证可用性，在具体的验证点上，就是要验证这个轮询策略。类似这样，把每个特性的每个技术实现对应上，而每个特性又会对应多个技术实现，细分下去会有很多层级，在我之前的工作中，最多的分到九级，会有几百上千的网状末梢。

有了这张大网，也才有了非功能能力验证的基础。

可能有人觉得：现在市面上讨论的混沌工程不就是在做非功能的事情吗？

在我看来，混沌工程只是验证非功能特性能力的一种手段、一种工具，还远远达不到覆盖非功能特性能力的级别，相差太远，即使没有混沌工具，手动操作也照样是可以的。

在实际的工作中，至少在现阶段，即使有了混沌工具也不见得可以提高工作效率，因为我们需要关注的不是混沌工具实现的那些功能，而应该关注的是**出现了问题后业务系统的处理能力。**所以我把它们描述成这样的关系：

在信创国产化的这些年中，不管是生产事故导致的被迫接受，还是上线前验证的主动出击，IT系统的非功能能力关注度一定会慢慢提高。

最后，希望大家的IT系统都能稳定运行下去。