在当今时代，互联网已成为我们生活中不可或缺的一部分，涉及到日常的方方面面。无论是打车、购物还是社交，我们都依赖于各种应用程序。但是，这些服务一旦出现中断，就可能引起严重的后果。

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

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

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

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

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

你是否也遇到过线上出问题了，查找日志，发现都是 ERROR 日志？

你是否也遇到过虽然有日志，但是日志实在太多，在茫茫日志中无法有效地定位到问题？

你是否遇到过要去排查前人写的代码产生的 BUG，却还需要把先把相关的代码过一遍，找到相关日志点，再去搜索日志？

你是否遇到过日志越来越多，不同的人都在打，有些日志没有用了，还是在不停的打？

你是否遇到过奇怪类型的日志，甚至相互冲突以至于无法定位问题？

你是否遇到过因为打个日志，导致客户端崩溃？

……

当日志不在大家的视野中，凭着个人的喜好去打，去定位问题，最终整个日志就会变成一个不断膨胀的怪物，变成大家使用起来都感到困扰和无助的混乱池塘。

当日志的生成和使用没有统一的规范和标准，每个人都按照自己的方式和喜好来记录和查找日志，日志的内容和格式就会变得五花八门，导致理解和分析日志的难度大大增加。另外，无效的、重复的、甚至是错误的日志会像野草一样无序地生长，使得日志的数量越来越大，而有效的、有用的日志则可能会被淹没在这个日志的海洋之中。

此时，我们需要建立一套有效的日志管理策略，包括设定清晰的日志记录标准，实施有效的日志标准管理，优化日志存储和清理策略等。只有这样，我们才能把这个日志怪物驯化，使得日志成为我们解决问题的有力工具，而不是一种困扰。

从过往的经历和上面描述的这些问题里面我们洞察了如下的问题点：

1. 日志规范管理的问题
2. 日志无序增长的问题
3. 日志劣化和无人维护的问题
4. 日志导致的线上问题

那么我们如何有效的去解决这些问题呢？

大概有如下六个步骤：制定标准、系统化实现标准管理、实现统一的日志 SDK 接入、使用统一的日志管理系统、定期复盘标准并落地日志的生命周期管理。具体如下：

1. 制定标准：日志的标准应包括但不限于如下几个方面：

   • 日志级别：定义不同级别的日志，如 DEBUG、INFO、WARN、ERROR 等，以便于过滤和查找。
   • 日志格式：定义统一的日志格式，包括时间戳、日志级别、日志来源、日志内容、错误堆栈等信息。
   • 日志内容：明确记录哪些信息，如请求信息、业务数据、错误信息等。避免记录敏感信息，如用户密码、身份证号等。
   • 日志保留时间：根据日志的重要性和存储成本，设定不同级别日志的保留时间。
   • 是否废弃：类似于接口的 Deprecated 注解，废弃的接口在定时间内会停止上报，并无法查询。

2. 系统化实现标准管理：以系统的方式将标准、SDK 下载管理起来，并且和集成的日志系统关联上，主要包括以下三点：

   • 标准管理：实现日志标准的管理和维护，包括日志的级别、字段、格式等。此外，也应当支持标记废弃等生命周期相关的字段，以确保所有人员都能了解到哪些标准不再使用。
   • SDK 下载：提供一个 SDK 的下载功能，允许开发同学根据需要下载适合特定平台或语言的日志 SDK。这种 SDK 应当已经集成了日志标准，以确保开发者在使用 SDK 时能够自动地遵循标准并上报到统一的日志平台。
   • 日志系统跳转：和真正的日志系统（如 ELK）打通。如提供一个默认的跳转链接，可以直接跳转到 ELK 的对应界面，查看满足这些参数的日志。

3. 实现统一的日志 SDK 接入：提供一个统一的日志 SDK，用于记录和上报日志。这样可以简化开发同学的工作，只需要调用 SDK 提供的接口，就可以按照标准记录日志。而且，SDK 可以处理一些公共的日志任务，如添加时间戳、格式化日志、处理错误堆栈、防止打日志时崩溃等。SDK 应该是跨平台、跨语言的。

4. 使用统一的日志管理系统：使用一个专门的日志管理系统，来收集、存储、查询和分析日志。这样可以提供一致的日志服务，提高日志的可用性和可维护性。例如，可以使用 ELK（包括 Elasticsearch、Logstash、Kibana）作为日志管理系统。

5. 定期复盘标准：随着业务和技术的发展，可能需要更新日志标准。因此，需要定期复盘标准，看是否需要改进。定期复盘标准的频率可能会因为具体情况而变化。如果业务和技术环境比较稳定，那么可能每年复盘一次就足够了。如果环境变化比较快，那么可能需要每季度甚至每月复盘一次。

6. 日志的废弃管理：日志的生命周期管理包括日志的生成、收集、存储、查询、分析和废弃等步骤。其中，废弃管理是一项非常重要的任务，因为它直接关系到日志系统的健康和效率。日志的废弃管理可能包括以下几个方面：

   • 过期删除：设置日志的保留期限，过期的日志将被自动删除。这个期限可能会根据日志的级别和重要性而变化。比如，ERROR 级别的日志可能需要保留一个月，而 DEBUG 级别的日志只需要保留 3 天。
   • 空间限制：设置日志的存储空间限制，当存储空间达到一定的阈值时，最旧的日志将被自动删除，以释放空间。
   • 废弃标识：为废弃的日志添加标识，这样在查询和分析日志时可以忽略这些日志。同时，废弃的日志应当尽快被删除，以节省存储空间。
   • 废弃通知：当一个日志标准被废弃时，需要通知所有相关的人员，以避免他们继续使用这个标准。同时，也需要更新日志 SDK 和管理系统，使它们不再支持这个废弃的标准。

回顾一下，我们制定了一套清晰的日志标准，随后通过系统化的管理方式实施和维护这些标准。借助统一的日志 SDK 和日志管理系统，我们可以提升日志生成和使用的效率。这样，日志便从混乱的信息池转化为强大的问题解决工具，从而提升整体的研发效率。

在前面的文章中我们聊了技术成本的精细化运营；聊了要识别出成本要素，找出每个要素的关键成本点，将成本定义为顾客付出的代价，根据成本的基本特性对其分类包括生产性成本、支持性成本、监察成本和浪费成本；聊了成本的核算以及成本和业务以及公司商业化策略的关系等等。

今天我们从一个技术团队的负责人角度来聊一下软件研发过程中的成本。

研发过程中成本主要包括研发过程的成本和对业务产生的影响而带来的「非正常成本」。而其中软件研发成本的核心是认知成本和沟通成本。

认知成本

认知成本是一个相对宽泛的概念，它涉及到所有获取、理解、处理信息以及进行决策的努力和资源。在一般情况下，认知成本可以分为以下几个部分：

1. 学习成本：这是指为了掌握新的知识、技能或工具所需要的时间和精力。如一个开发同学需要学习一种新的编程语言，那么这就会产生学习成本。
2. 理解成本：这是指为了理解新的信息或知识所需要的时间和精力。如阅读和理解一份复杂的技术方案文档就会产生理解成本。
3. 处理成本：这是指为了处理信息，比如进行分析、整理或应用，所需要的时间和精力。如分析一份用户行为数据报告就会产生处理成本。
4. 决策成本：这是指为了做出决策，比如评估选项、权衡利弊、制定策略，所需要的时间和精力。如选择一个软件开发框架或选择一个市场策略就会产生决策成本。

在实际应用中，降低认知成本通常是提高效率和效果的重要目标。例如，良好的用户界面设计可以降低用户的认知成本，提高用户体验；有效的信息管理和知识共享可以降低团队的认知成本，提高团队效率。

研发过程中的认知成本，其差异点在于对于事情的了解。从认知神经科学的角度来看认知成本又分为认知载入（ Cognitive load ）和认知投入（ Cognitive effort ）。

• 认知载入是一个信息处理的心理过程，是装载、把…的信息加载到工作记忆的过程。
• 认知投入是指在知识加工过程中付出的脑力及努力程度。

对于开发过程来说，认知投入往往相对平稳，成本的主要差异点在于认知载入，而认知载入和人的记忆相关。

记忆分为中短时记忆和长时记忆，中短时记忆一般只维持数十秒或数分钟，长时记忆可以存储很多年并可以被回忆，短时记忆中的内容如果不被刻意记录，可能会完全丢失。

工作记忆（Working Memory）是对短时记忆模型的一种扩展，代表一种容量有限的、在短时间内保存维持信息，并对这些信息进行心理处理操作的过程。工作记忆的内容可以源于感觉记忆的感觉输入，也可以从长时记忆中提取获得，并且后者是一个重要的来源。

据此，我们可以得出造成开发同学需要付出的认知成本的差异的关键原因在于：

• 载入工作记忆中的代码内容来源：如果是自己编写的代码，它将唤起长时记忆中的回忆，更快地加载对代码内容的理解；如果是别人编写的代码，所有的内容需要经感觉记忆输入，它将变得较难理解，并需要更多的时间与长时记忆中的内容建立关联，或写入长时记忆；
• 代码中的模式与长时记忆的关联性：如果代码遵循了一致的规范（包括命名、缩进、结构、接口标准等），大多数开发者都共享了这一规范（存于长时记忆），将能够更快地加载理解过程，从而提升处理速度；
• 代码中的领域知识与长时记忆的关联性：与编写规范一样，领域知识是另一种可共享的长时记忆内容，它也能够加速理解的过程。

基于此，我们可以从认知过程的改进，论证得出减少认知成本，或者说在平时积累认知的方法：

• 选拔正确的人：以选拔/面试的方式，找到满足认知成本的人；
• 经常性的交叉评审代码：如果代码规模庞大，相比传统的代码走读方式通常为从核心模块开始，更推荐从活跃代码开始（如 30 天内的活跃修改范围），以更快地熟悉近期的工作；
• 共享且强制执行的标准和规范：代码规范，数据库规范，文档规范……；
• 共享的领域知识：包括系统顶层结构、如何开始工作和必须的业务知识，构建团队的知识库。

沟通成本

有同学说「白天在开会，晚上才能写代码」

有同学说「不是在沟通就是在去沟通的路上」

软件研发是高度协作的工作，沟通成本非常高。

沟通成本是指为了达成共识，传递和理解信息，以及协调团队成员间或者团队与团队之间的工作所需花费的时间和精力。在软件研发中，沟通成本包括以下三个方面：

1. 信息交流成本：包括团队成员之间进行面对面交流、写邮件、开会等方式的沟通所需的时间和精力。
2. 知识转移成本：当需要将知识或信息从一个团队成员传递给另一个团队成员时，可能需要进行培训、编写文档等，这都会产生一定的成本。
3. 协调成本：在团队成员之间协调工作，比如确定任务分配、同步项目状态、解决冲突等，都需要投入时间和精力。

不管是哪种成本，从沟通的角度，本质是一样的，都是一个信息传输的过程。

沟通过程中主体是发送者、接收者和渠道，主要操作是编码、传输和解码。

• 发送者：沟通的发起者，本次信息传输的主导者；
• 编码：整理信息，以自己的理解和技能把信息、思想与情感等内容用相应的语言、文字、图形或其他非语言形式表达出来的过程；
• 渠道：信息传输的载体，常见的渠道包括：语言、电话、文档、传真、电子邮件、各种 IM 工具等；
• 解码：接收者对所获取的信息的理解过程；
• 接收者：信息接收者、信息达到的客体，可能是一个人也可能是一群人，也可能没有人。

如我们想给比较多人的讲一个事情，一种性价比比较高的方式就是写文档或电子邮件发给这些人看，这个写文档/邮件，发给接收者阅读并理解整个文档的过程就是一次信息传输的过程，也就是一次沟通的过程。

在信息传输过程中，有较多的噪声会影响整个传输的效果，比如我们刚才说的写文档，编码的过程就是我们将想法、思想和逻辑转化成文档的过程，而每个人写文档的能力，对于问题的理解不一样，从而写出来的文档参差不齐，这里的差异就是我们编码中的一种噪声。

在语言沟通过程中，除了讲，还要听，做彼此的倾听者，沟通过程中随时调整沟通的方式和方向，以求达到沟而相通的目的。

从信息传输的模型来看，这里的倾听其实就是为了更好的解码，更好的接收传递过来的信息，而调整沟通的方式和方向是为了优化编码的方式，以适配对方的解码逻辑。

汉字其实很形象地表述了听的逻辑，听的繁体字写法是「聴」，拆开来看，它要求我们听的时候要用耳朵、眼睛和心来聆听，这样你才能准确地理解他人的意思。而简体字的「听」拆开是「口」和「斤」，这仿佛在告诉我们现代人听不再用耳朵, 而用的是「口」， 而且是根据对方的「斤」两来决定到底听还是不听。

从沟通的本质出发，降低沟通成本的策略可能包括：优化沟通方式和流程，提高沟通技巧，使用有效的工具支持沟通，以及建立明确的角色和责任，以减少不必要的沟通。

另外，从整体研发效率来说，可以设置不沟通的时间，如设置研发静默时间，专注于写代码。

非正常成本

非正常成本则相对难以预计和控制。它们可能源自多种因素，如项目延期、需求变更、技术难题、产品缺陷等。当这些问题出现时，团队可能需要付出额外的时间和努力来解决，这就产生了非正常成本。例如，如果因为技术难题导致项目延期，那么团队可能需要加班，甚至可能需要聘请外部的专家或顾问来帮助解决问题，这些都会增加非正常成本。

最为常见的非正常成本一定有过度设计和技术债务。

过度设计是指在开发过程中投入的工作远超过解决问题所需的程度，这通常体现在过于复杂的系统设计、不必要的功能，或过早优化的代码上。涉及到开发、维护和产品质量三方面，这种过度设计会导致更多的开发和测试时间，更复杂的维护工作，以及可能降低的产品质量。

技术债务是指由于短期内的快速开发和决策，而在长期内需要支付的额外工作。例如，为了赶项目进度，团队可能会选择快速但不完美的解决方案，而不是花费更多时间来寻找更好的解决方案。为了解决技术债务，可能需要进行代码重构或重新设计系统，这将带来额外的开发和测试时间。此外，技术债务可能会降低开发团队的生产力，例如，如果代码质量低，团队可能需要花费更多的时间来理解代码、修复错误和添加新功能。

比较特殊的一种非正常成本是线上事故，线上事故对于任何技术团队来说都是一种非常严重的非正常成本。这类事故可能会对用户产生直接的影响，包括用户体验降低、数据丢失、服务中断等。这不仅可能导致用户对产品或服务的信心降低，甚至可能导致用户流失。此外，严重的时候，线上事故还会导致公司的资产损失。

小结

在提升软件研发效率的过程中，技术团队需要有效地管理和控制「隐形」的认知成本、沟通成本和非正常成本。认知成本，包括获取和处理信息以及决策的代价，可以通过选拔合适的人才和制定共享标准来优化。沟通成本，主要涉及达成共识和协调团队工作所需的资源，可以通过优化沟通方式和明确角色责任等来降低。非正常成本，源自如项目延期、技术难题和线上故事等因素，其控制需要避免过度设计和及时偿还技术债务。

此外，团队需要有明确的计划，有效的项目管理和质量控制流程，并与业务部门和市场部门紧密合作。同时控制和防范线上事故也至关重要，技术团队需要在系统设计和开发过程中考虑安全性和稳定性，建立有效的监控和预警系统，并制定实施恢复和应急计划。

因此，掌握这些研发成本的管理和控制，以及有效的项目管理和防范措施，构成了提升软件研发效率的黄金法则。