你是否也遇到过线上出问题了，查找日志，发现都是 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 工具等；
• 解码：接收者对所获取的信息的理解过程；
• 接收者：信息接收者、信息达到的客体，可能是一个人也可能是一群人，也可能没有人。

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

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

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

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

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

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

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

非正常成本

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

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

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

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

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

小结

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

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

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