前言

截止 23 年 3 月末，微博增值团队从上线一站式可观测平台到现在也运行了差不多两年的时间了。在这两年里，团队成员通过一站式可观测平台不断优化和改进服务，提高了整体系统的性能与稳定性（3 个 9 到 4 个 9，tp99 case by case 优化，平均下降 100ms），同时降低问题发现和定位的时间（5 分钟发现问题，30 分钟内定位问题），从而使开发人员能够专注于创新和业务发展。

今天本文主要想说一些整个一站式可观测平台发展过程中需要回顾与反思的一些点。在回顾的过程中，我将从以下几个方面进行思考与总结：

项目开发是一个复杂的过程，需要考虑众多因素。因此，在开发过程中需要不断进行反思和总结，及时发掘问题和给出改进方案，为项目的成功发展提供有效保证。由于篇幅较长，为了便于阅读消化，本文将分为上下两篇来进行整理。上篇主要讲一下目标与需求、技术选型、实施过程和团队协作。

目标与需求

在项目开发过程中，项目的目标和需求是开发的基础。确立好项目目标和需求后，才能从根本上保证项目的开发方向和成果符合用户的期望。在项目开发过程中，需要充分考虑用户的需求和期望，以此为基础制定项目的目标。同时，项目的目标应该具有明确性、可量化性、可操作性和可验证性等特征，以便于评估项目成果是否达到预期目标。在整个开发周期中，需要不断关注用户需求和反馈，及时调整项目目标和需求，以确保项目的持续适应性和可持续发展性。审视我们当初设定的目标和需求是否得到了满足，是否有新的需求和挑战出现，以便对现有解决方案进行持续优化和改进。

为了寻找更趁手的工具，让开发人员更专注于开发本身，团队经历了以下几个阶段的尝试和探索：

第一阶段：使用 ELK+Grafana+Graphite 等工具，作为监控和日志分析方案。历史遗留方案。

但是，这套方案也有一些缺点：

ELK+Grafana+Graphite 方案总体来说是一种灵活、高度可定制的监控和日志分析解决方案，但需要根据具体情况仔细考虑其优劣和适配性。对于我们团队来说最大的问题，过去的运维标准不统一，维护成本高。ELK 成本过高。排查问题需要主动埋点日志。

第二阶段：引入 APM 工具 SkyWalking，提高监控覆盖度并快速定位性能瓶颈。SkyWalking APM 引入了 Trace 的概念，帮助团队找到性能瓶颈和项目依赖。对于存量 PHP、Go 的业务团队来说，引入 SkyWalking APM 工具的优缺点如下。

引入 SkyWalking APM 工具可以提高 PHP 应用程序在生产环境中的监控和性能分析能力，但需要开发人员在使用时充分考虑其缺点，并综合评估是否适合项目使用。这段经历对于团队的最大收获是引入了 Trace，初步了解到了可观测性的概念，同时在不断优化 SkyWalking 相关生态的同时，积累了许多关于 PHP 扩展开发、ClickHouse 等相关技术积累。也在后面起到了至关重要的作用。

第三阶段：在了解到 OpenTelemetry 项目后，团队决定基于 OpenTelemetry 来提升服务的可观测性。OpenTelemetry 提供了一种统一的方法来收集、处理和传输 Metric、Log、Trace 等数据，有助于实现根因分析，同时也降低了成本。利用开源社区减少团队内部维护成本。同时参与社区，达到正向循环。

基于 OpenTelemetry 提升服务可观测性的方案，优缺点如下。

OpenTelemetry 作为一个新兴的且市场火爆的项目，目前尚处于快速发展的初期阶段，可以使监控工作更高效、更简单。开发者需要认真考虑使用 OpenTelemetry 的成本、复杂性和适用性，并结合自己的特定业务需求作出最佳的决策。目前大部分已发布 Bete 版本。部分已发布 Realase 版本。已趋于稳定。

为了实现 90%的问题能通过报警主动发现，而非用户反馈，团队采取了以下措施：

团队的这些措施可以大大提高监控覆盖度和问题发现率，但要实现 90%的问题能够通过报警主动发现，还需要不断改进和创新。

首先，团队可以继续引入更多的监控工具，并逐步强化监控的精细化。例如，可以尝试引入更加细致的监控指标，对代码中的异常进行更加精细的监控和分析。同时，还可以对多个工具进行整合和优化，以进一步提高监控效果和减少告警误报率。引入根因分析能力。更加快速的发现问题，定位问题。

其次，团队可以进一步优化告警方式和处理流程。例如，可以设计人工干预的监控，设定特定的策略和告警动作，以最大程度地减少误报和深化问题的定位和排除。

最后，团队可以制定更加周密和科学的故障排查流程，结合实际情况采用合适的方法和流程来分析和解决可能存在的问题。同时，还可以持续学习和发掘新的问题排除方法和经验，以进一步提高监控效果和质量。

总的来说，团队通过引入 APM 工具、设定告警阈值、优化告警方式、持续改进监控系统以及建立健全的故障排查流程等措施，已经取得了一定的成果，在实现 90%的问题主动发现方面也已经有了很大的提升。随着技术和管理的不断进步，该目标在未来也有望得到更好地实现。

为了将问题从发现到定位的耗时缩短至 15-30 分钟，并缩短 MTTR（平均修复时间），团队进行了以下工作：

通过上述努力，团队在问题发现、定位和修复方面取得了显著的成果，90%的问题处理时间缩短至 15-30 分钟，从而降低 MTTR。然而，实际效果可能因项目和团队具体情况而有所差异，需要不断地持续优化和改进。

为了将服务 RT（响应时间）降低 30%，我们进行了以下工作：

通过以上工作，团队旨在降低服务的响应时间，提高系统性能和用户体验。然而，实际效果可能因项目和团队具体情况而有所差异，还需要持续关注并不断优化，这将是一个持续的治理过程，而非一劳永逸。

技术选型

技术选型是项目成功的关键因素之一。在选择技术方案的时候，需要考虑多方面因素，包括性能、可维护性、安全性、可扩展性、成本效益等。在选择技术方案时，需要全面分析技术特点和应用场景，并根据实际情况进行选择。同时，也需要关注技术的更新和发展，及时更新技术选型，以确保项目的技术质量和竞争力。

整体架构图

更多实现细节请参考：微博增值团队可观测性探索与实践-初探、微博增值团队可观测性探索与实践-实践

实施过程

实施过程是项目成功的保证之一。在实施过程中，需要全程跟踪、监控项目开发进度、质量和成本等指标，及时调整和协调项目开发中的问题和冲突，确保项目按时、按质、按量完成。同时，也需要保持代码质量和文档规范，确保项目的可维护性和可持续发展性。在项目实施过程中，需要注重项目交付和用户培训等环节，提高用户满意度和项目成果转化效益。回顾项目实施过程中遇到的问题和挑战，分析原因并提炼经验教训，从而为今后类似项目的实施提供参考。

团队协作

团队协作是项目成功的重要保证之一。在团队协作中，需要明确角色分工、沟通协调机制和团队文化建设等方面。同时，也需要关注团队成员的专业技能和人际交往能力的提升，以提高团队的绩效和协同能力。反思团队间的沟通、协作和知识共享是否得到了有效实现，以便进一步优化团队协作机制，提高工作效率。如何在团队内推广，培训，甚至推广到其他大团队。

将可观测性系统推广到其他兄弟部门总结为以下步骤：

篇幅原因，用户体验、成本和效益、风险管理、组织和文化将在微博增值团队可观测性探索与实践-回顾与反思-下篇中更新。暂时先想到这些，文章后续可能会因更多的思考而进行调整。

作者介绍：

张铃崎，前微博研发工程师。目前在百度任职。