2023 年 11 月份，我们见证了两次重大的网络服务故障：11 月 12 日下午，阿里云服务出现异常，导致依赖其服务的多个厂商及其产品功能受损，包括其自身的产品钉钉。紧接着，11 月 27 日晚，滴滴打车应用程序出现故障，直到 28 日中午才逐渐恢复正常。这次滴滴的服务中断超过了 12 个小时，引起了用户和司机的混乱和不便。

就在昨天，12 月 1 日上午，上海医保系统无法进行结算，网友形容「看病一分钟，排队两小时」，凸显了网络服务依赖的脆弱性。

特别一点说，滴滴出行在 2023 年 11 月 27 日发生的故障，使我们不得不重新思考我们对系统复杂度的认知。从滴滴的恢复过程中可以看出，系统经历了部分恢复、再次出现问题，数据混乱等现象。整个系统看似处于混乱之中，但在多方努力介入处理后，逐渐恢复稳定并重新运作。这个过程好比一个受伤的系统在逐步疗愈。

公众的反应也多种多样，有人归咎于滴滴的「降本增效」策略，有人认为是管理层的失误，还有人指责技术升级不当。但如果把滴滴看作一个整体的系统，它无疑是高度复杂的，由人员、组织结构和各种在线系统组成。这个系统的复杂性在平时可能被我们低估，因为每个人通常只关注自己负责的那部分工作。

要理解一个系统的系统复杂度，可以从四个维度来考察：组分复杂度、结构复杂度、功能复杂度和描述复杂度。

组分复杂性

组分复杂性是指一个系统中各个部分（或称为「组分」）的多样性、数量以及它们之间的交互关系所带来的复杂性。 这种复杂性主要体现在以下几个方面：

• 1. 构成复杂性：也就是系统由多少个不同的部分组成，这些部分又是如何相互关联和影响的。滴滴出行的系统由订单处理、司机分配、定位导航、支付处理、用户反馈等多个子系统组成。这些子系统都有自己的运行逻辑和规则，而且它们之间还需要相互配合和协调。这些系统的交互和协调就构成了滴滴的构成复杂性。
• 2. 分类复杂性：指的是系统内部的各个部分有多种多样，它们分布的规律性、差异性以及由于各个部分的不同性质带来的复杂性。如滴滴的用户包括乘客和司机，他们的需求和行为都各不相同。比如乘客可能有急需用车的，也有提前预约的；司机可能有全职的，也有兼职的。而滴滴系统需要根据这些不同的需求和行为来做出响应，如何处理这些不同的分类就构成了滴滴的分类复杂性。
• 3. 规模复杂性：这是指系统内部包含的部分的数量和种类的多少。数量越大，种类越多，系统的复杂性就越高。滴滴的用户数量非常庞大，每天需要处理的订单数量也是海量。这就要求滴滴的系统必须能够在短时间内处理大量的信息并做出决策，比如如何快速匹配乘客和司机，如何计算最佳路线等。同时，滴滴还提供了多种服务类型，如快车、专车、顺风车等，每种服务类型又有自己的规则和特性。如何管理这些大规模的数据和多样化的服务就构成了滴滴的规模复杂性。

结构复杂性

结构复杂性关注系统的整体结构以及各个部分之间的排列、组织和层次关系的复杂性。这种复杂性主要体现在以下三个方面：

1. 组织复杂性：这是指一个系统内部各个部分之间的组织方式有多么复杂。例如，一个公司的组织架构，有多少部门，这些部门之间是如何分工合作的，就构成了组织的复杂性。又或者像滴滴系统是由多个子系统组成的，包括订单处理系统、定位系统、支付系统、评价系统等等。这些子系统需要协同工作，以提供顺畅的出行服务。

2. 层次复杂性：这是指一个系统可以被划分为多少个层次或等级，以及这些层次之间的关系也会非常复杂。如滴滴的系统，从上层的应用架构，到底层的服务架构，再到更下面的物理架构层，每个层次都有其内在的复杂性，而层与层之间的交互和协作也会引入额外的层次复杂性。以基础设施为例，这些基础设施的任何故障都可能导致滴滴的线上故障。

3. 过程复杂性：这是指一个系统内部的运行和交互过程有多么复杂。滴滴的运行涉及到许多复杂的过程，如订单匹配、路线计算、费用结算等。这些过程中都涉及到了大量的计算和决策，而且经常需要实时地调整和优化。同时，滴滴的运行还受到外部环境的影响，比如交通状况的变化、法规政策的变更、天气变化等，这些都会影响到滴滴的运行过程，使其变得更加复杂。

结构复杂性就是由于一个系统内部各个部分之间的关系错综复杂，使得系统的行为和性质变得难以预测和理解。

功能复杂性

功能复杂性实际上描述了一个系统在不同情况下处理问题的难易程度，包括预测、保持和调控三个方面。

1. 预测复杂性：就像预测天气一样，系统未来的状态可能会因为很多不确定的因素而变得难以预测。如滴滴系统在未来某一时刻的状态，如，预测在特定时间和地点的需求量可能会因为许多因素（天气、节假日，甚至是附近有没有大型活动等）而变得相当复杂。

2. 保持复杂性：保持系统稳定正常的运转也需要对各种要素进行精细的平衡，如遇到大流量的冲击，安全攻击，甚至爬虫或者某些 BUG，想象你在平衡一只装满水的杯子，这需要非常多的复杂性和一些精细的调整。

3. 调控复杂性：如果你想改变系统的某些功能，就像在一个复杂的机器中更换部件一样，像增加某些功能，对于现有复杂度的影响，以及删减某些功能或子系统，对系统中的组分的影响，结构的情况等等。

在我们面对一个复杂系统时，对系统进行预测、保持和调控都是在钢丝上跳舞。

描述复杂性

简单来说，描述复杂性就是理解和描述一个系统需要多少工作量和信息量的度量。 稍微复杂一点，描述复杂性是从描述系统的状态的工作量、信息量以及存储量角度来定义系统的复杂性。它以数学的复杂性理论和信息论为基础，主要包括以下三个方面：

1. 计算复杂性：这是指解决一个问题所需要的计算资源，包括时间和空间，也就是我们在编程时常说的时间复杂度和空间复杂度。例如，一个问题如果需要很长的时间或大量的内存来解决，那么我们就说它具有高计算复杂性。

2. 算法复杂性：这涉及到解决问题的过程中的多样性和随机性。想象你正在解决一个复杂的拼图，需要尝试不同的拼接方法，这就是算法复杂性，描述了解决问题的过程中的步骤和方法有多复杂。

3. 有效复杂性：如果你要向别人解释一个很复杂的概念，你需要多少话才能解释清楚，这就是有效复杂性，代表了描述一个系统的规律性需要多少信息。

在这些方面中，计算复杂性和算法复杂性主要关注解决问题的过程，而有效复杂性则更多地关注对问题本身的描述。

上面四种复杂性中，组分复杂度和结构复杂度看起来会有一些相似的地方，容易搞混，它们关注的角度和内容有所不同：

1. 组分复杂性：这是关注系统中各个部分（或组分）的多样性、数量以及它们之间交互关系的复杂性。组分复杂性的关注点在于系统的各个组成部分以及这些部分之间的关联关系。例如，一个城市的交通系统中，公交、地铁、出租车、自行车等多种交通工具以及它们之间的转换和配合，这就构成了交通系统的组分复杂性。

2. 结构复杂性：这是关注系统的整体结构以及各个部分之间的排列、组织和层次关系的复杂性。结构复杂性的关注点在于系统的整体架构、层次关系以及系统运行的过程。例如，一个公司的组织架构中，不同部门的划分、部门之间的协作关系，以及公司运营、决策的流程，这就构成了公司的结构复杂性。

简单来说，组分复杂性着重于系统的各个部分和它们之间的关系，而结构复杂性则更加关注系统的整体架构和运行过程。在实际应用中，我们往往需要同时考虑这两种复杂性，以全面理解和处理复杂系统。

通过这种四种复杂性我们能较全面的评估我们所面对的系统的复杂度，不低估，也不过度夸大它的复杂性。

对系统复杂度的综合评估揭示了系统的脆弱性和潜在的优化路径，引导我们设计出更为韧性强、可适应性高的系统结构。这种洞察力使我们能够制定针对性的决策和策略，优化资源配置，创造更加流畅的用户体验，并在面对不断变化的需求和潜在危机时，保持服务的连续性与质量。

通过深入理解系统的组分、结构、功能和描述复杂度，我们不仅能够减少业务中断的风险，还能在持续的服务创新中保持竞争优势，实现系统的长期可持续发展。