引言
我是蒋烁淼，观测云的首席技术架构师兼产品把控者。今天，我有幸与大家分享我们团队在设计和实现产品过程中所坚持的核心理念。这些理念不仅是我们工作的指导灯塔，更是推动我们技术不断进步的动力源泉。
在观测云，我们坚信，一个产品的强大生命力和竞争力，源自于其内在的哲学和理念。作为团队的领航者，我带领着每一位成员，坚守着这些核心理念。它们是我们设计和实现产品的基石，是我们在技术发展道路上的指南针。
以工程师们为中心
观测云是一款面向企业级市场的监控观测产品，旨在满足最终用户的需求。我们认识到，产品要想拥有持久的竞争力，就必须得到工程师们的认可，使用便捷，并能为他们创造价值。通过提升工程师的工作效率，我们相信最终客户也将从中受益。
在传统监控产品中，设计往往以运维人员的需求为主，涵盖仪表盘、告警、数据接入等多个方面。然而，观测云的设计理念有所不同。举几个例子:
观测云的 Agent 模型采用了类似 OpenTelemetry 的架构，将 Instrumentor（探针）和 Collector(Agent)分离，完全不同于传统的 APM 厂商。
该架构设计具有多项优势，在此仅列举一个关键好处。我们认识到，无论是使用 eBPF 探针还是传统字节码探针，都可能对应用程序产生一定影响。同时，为了不断增强监控能力，探针和 Agent 可能需要定期升级。这种架构允许研发团队独立验证探针的稳定性和数据字段的扩展性，而运维团队则负责 Agent 的升级和配置调整。通过分离探针和 Agent，Agent 的升级不会干扰应用程序的正常运行，最多只会导致数据暂时不可用。在应用程序升级过程中，我们确保其与探针的兼容性已在测试环境中得到验证，从而避免了因探针升级不当而导致的整个业务系统的故障风险。
此外，这种架构还提高了系统的兼容性，能够支持多种 Instrumentor，包括但不限于探针、日志采集器以及 Prometheus 生态系统的集成。
使用观测云的用户将深刻体会到其赋予的广泛自由度，这不仅仅体现在随心所欲地设计个性化仪表盘、灵活配置数据结构、自定义查询模板，以及创举性地设计告警策略上。我们深刻理解研发工程师的微妙心理需求，因此在多处功能设计中巧妙地融入了“仅我可见”的选项，旨在为工程师们提供一个私密的空间，让他们能够安心地进行自我调试、仪表盘分析，而无需担心被他人窥探。这种贴心的设计，正是出于对研发者心理的深刻洞察与尊重，它鼓励了更自由、更无拘束的创新实践，从而真正释放了可观测性能力的潜力，为项目带来实质性的价值提升。
前面的模型示例不仅简化了研发流程，还赋予了他们在探针中自由扩展字段、深化业务洞察的能力，从而助力构建更为准确和全面的分析体系。众多观测云用户反馈，相较于某些标榜为AIOps的产品，我们的解决方案在功能强大性、AI 分析能力上更胜一筹，却谦逊未以此为核心卖点。原因在于，我们坚信算法的真正价值远不止于运维（Ops），它应广泛渗透于离群分析、异常检测等各个环节，赋能研发团队。这不仅仅意味着监控 CPU 行为异常，更关乎于深入理解代码调用在不同场景下的异常表现。
过分渲染 AIOps 概念的产品，往往陷入夸大其词的误区，而真正出色的产品则是将这些高档能力无缝融入日常研发运维流程中，成为他们工具箱中不可或缺的一部分。我们致力于让技术回归本质，为用户提供实实在在的价值，而非空泛的概念炒作。
我们对观测云的细致打磨体现在诸多方面，例如时间控件的灵活性。我们支持直接输入unixtime，简化了工程师在时间转换上的繁琐操作，避免了使用 Linux 命令或在不直观的日历控件中进行选择。这种对细节的关注是许多同类产品所忽视的。
观测云的更新频率为每两周一次，这不仅是为了引入新功能，更重要的是，我们致力于根据用户的真实反馈来优化产品。这些更新可能涉及大量的细节改进，虽然无法一一列举，但它们共同构成了我们对产品不断改进的承诺。我们相信，真正使用观测云的用户能够从这些细节中感受到我们的专注和诚意。
做一个开放的产品
我对开源的态度是明确的:我支持真正的开源精神，即开放代码并与全球开发者进行交流。然而，我反对那些以开源为名，实则追求商业利益而忽视社区和技术发展的“伪开源”行为。观测云在这一点上采取了开放的姿态，我们公开了所有端侧代码，并在 Github 上维护着数十个开源项目。我们鼓励团队成员积极参与开源社区，发现问题时提交 Pull Request（PR），以促进相关项目的进步。
同时，我们也持续为开源项目如 Victoriametrics 贡献代码。尽管观测云是一个商业产品，我们依然坚持开放的原则，但这种开放是有选择性的。我们的目标是提供一个既开放又可控的环境，确保产品的稳定性和安全性。
我们致力于整合开源技术，以增强观测云的功能。我们全面支持现有的观测技术框架，例如与 Prometheus 生态系统的深度集成。我们的系统不仅能够收集 Prometheus 的各种数据类型，包括 Exporter 和 Push 数据，而且在 Push 数据支持方面，我们在稳定性和性能上均超越了 Prometheus 官方的 Push Gateway。此外，我们还加强了对 Prometheus 自发现功能的支持。
在日志采集方面，我们兼容多种日志生成方式，例如支持 Log4J 通过 Socket 直接发送日志，避免了日志写入磁盘的需要。这种支持使得在性能要求很高的场景下，开发者也能够有效地收集大量日志数据。
对于分布式追踪（Tracing），我们同样提供了广泛的支持，兼容了包括 ddtrace、OpenTelemetry、Zipkin、SkyWalking 以及 Jaeger 等多种追踪协议。这些开源方案在不同应用中可能采用不同的实现，导致分析上的分散。观测云通过统一的集成方式，使得这些不同来源的数据在使用上保持一致性，仿佛它们是专为观测云设计的一样，尽管它们采集的数据内容可能各有差异。
同样，我们对开源技术的承诺不仅体现在支持 eBPF tracing 上，更在于我们将其开源，以促进统一标准的形成。与国内其他开源厂商不同，我们致力于生成符合 OpenTelemetry 标准的 span 和 trace。这意味着使用观测云采集的 eBPF 数据能够与其他技术方式接入的数据一同分析，无需额外的后台系统或专用数据库存储集群。
在技术文档方面，我们致力于开放和透明的分享。观测云在技术文档的公开程度上，自信地处于行业领先地位。我们公开了大量的技术实现细节，以便于业界同仁学习和参考。
用认知驱动取代需求驱动
对于熟悉观测云的老朋友或初次接触的新朋友而言，或许已知晓或未曾留意到这样一个事实:观测云不仅提供云端服务，实现全球无缝接入，同时也支持灵活的私有化部署方案，以满足不同用户的特定需求。然而，鲜为人知的是，观测云在产品开发上坚守着一个重要原则——我们从未为任何单一客户定制产品。从中国的本土版本到海外的国际市场，再到那些部署于客户私有环境中的定制化方案，尽管部分版本因市场策略或技术迭代进度略有差异，但观测云始终如一，坚持为所有用户提供统一、标准的产品体验。
这是我们的坚持。为什么呢?
首先，观测云坚守为客户负责的原则。在快速迭代的产品环境中，我们深知保持产品主线的重要性。定制化产品虽看似能即时满足特定需求，但长远来看，它们往往与主线版本分离，形成分叉，这不仅损害了客户的长期利益，也增加了我们维护产品体验的难度。因此，我们坚决避免任何形式的版本分叉，确保每位客户都能享受到持续、稳定且有效的产品服务。
其次，我们注重有价值需求的快速响应与标准化。在快速迭代的过程中，我们深知客户需求的多样性与复杂性。然而，并非所有需求都能直接转化为产品功能，特别是当这些需求存在逻辑悖论或表述不清时。作为产品专家，我们倾听客户声音，结合产品架构与行业洞察，将特定需求转化为标准化的产品功能。这种负责任的做法不仅提升了产品价值，也加深了我们对产品行业的认知，而这些认知又反过来推动我们不断优化产品，形成良性循环。我们的更新速度远超客户自行探索开源方案的效率，确保研发运维工程师们能够轻松、有效地使用我们的平台。
最后，我们致力于产品的开放性与灵活性。为了满足用户多样化的个性化需求，我们努力实现各种技术栈的标准化集成，而非依赖定制化。通过构建丰富的灵活性机制，我们完整打造了一整套架构体系，以应对更广泛的业务场景和需求。这种高度定制化的灵活性要求我们不能简单地采用开源产品拼凑而成，而是需要自主设计数据引擎、数据库及UI框架等核心组件，从而确保产品的整体性能和用户体验。这种从底层到上层的全面掌控，使得我们的产品能够灵活应对各种挑战，为用户创造更大的价值。
观测云是我们团队精心打造的产品，它不仅承载着我们的技术追求，更融入了我们的价值观。我们致力于持续优化和完善产品，以确保它能够为用户带来实际的价值。我们的目标是让观测云在企业中发挥关键作用，特别是对于工程师团队。我们相信，通过不断的努力和创新，观测云能够提升工程师的工作效率，增强企业的运营能力。我们的目标不仅是满足用户当前的需求，更是预见并引领未来的技术趋势，从而为企业带来长远的价值。
（推广）