虽然将可观察性整合到系统中似乎令人望而生畏，但好处是巨大的。一个著名的例子是 PhonePe，通过实施数据可观察性解决方案，它的数据基础架构增长了 2000%，数据管理成本降低了 65%。这有助于缓解性能问题并最大限度地减少停机时间。
可观察性驱动开发 (ODD) 的影响不仅限于 PhonePe。许多组织都体验到了 ODD 的好处，发现问题的可能性提高了 2.1 倍，解决问题的平均时间缩短了 69%。
什么是ODD?
可观察性驱动开发 (ODD) 是一种将左可观察性转移到软件开发生命周期最早阶段的方法。它使用基于跟踪的测试作为开发过程的核心部分。
在 ODD 中，开发人员在编写代码的同时声明您查看系统内部状态和过程所需的输出和规范。它适用于组件级别和整个系统。ODD 也是一种标准化仪器的功能。可以跨编程语言、框架、SDK、API。
什么是 TDD?
测试驱动开发 (TDD) 是一种广泛采用的软件开发方法，强调在编码之前编写自动化测试。TDD 的过程包括通过创建测试用例来定义软件的预期行为，运行测试以确认其失败，编写最少的必要代码使测试通过，并通过重构改进代码。针对每个新功能或需求重复此循环，由此产生的测试可作为防止未来潜在回归的保障。
TDD 背后的哲学是编写测试迫使开发人员考虑手头的问题并生成重点突出、结构良好的代码。遵守TDD可以提高软件质量和需求合规性，并有助于及早发现和纠正错误。TDD被认为是提高软件系统质量、可靠性和可维护性的有效方法。
可观察性和测试驱动开发的比较
相似之处
可观察性驱动开发 (ODD) 和测试驱动开发 (TDD) 致力于提高软件系统的质量和可靠性。这两种方法都旨在确保软件按预期运行，最大限度地减少停机时间和用户面临的问题，同时促进对持续改进和监控的承诺。
差异
- 重点： ODD 的重点是实时持续监控软件系统及其组件的行为，以识别潜在问题并了解系统在不同条件下的行为。另一方面，TDD 会在错误对系统或用户造成损害之前优先检测和纠正错误，并验证软件功能是否满足要求。
- 时间和资源分配：实施 ODD 需要投入大量时间和资源来设置监控和日志记录工具和基础设施。相比之下，TDD 需要在开发阶段投入大量时间和资源来编写和执行测试。
- 对软件质量的影响： ODD 可以通过提供对系统行为的实时可见性来显着影响软件质量，使团队能够在问题升级之前检测并解决问题。TDD 还有可能通过在错误进入生产环境之前检测和修复错误来显着影响软件质量。但是，如果测试不全面，错误仍可能逃避检测，从而可能影响软件质量。
在生产中从 TDD 转向 ODD
在软件开发中从测试驱动开发 (TDD) 方法转变为可观察性驱动开发 (ODD) 方法是一个重大变化。多年来，TDD 一直是在将软件发布到生产环境之前对其进行测试的既定方法。
虽然 TDD 通过重复测试提供一致性和准确性，但它无法深入了解整个应用程序的性能或真实场景中的客户体验。通过 TDD 进行的测试是孤立的，不能保证实时应用程序中没有错误。此外，TDD 依赖于一致的生产环境来进行自动化测试，这并不代表真实场景。
另一方面，可观察性是 TDD 的进化版本，它提供对基础设施、应用程序和生产环境的全栈可见性。它通过日志、跟踪和指标等遥测数据确定影响用户体验和产品发布的问题的根本原因。这种持续监控和跟踪有助于预测最终用户对应用程序的看法。
此外，有了可观察性，就可以在代码到达源代码控制之前编写和发布更好的代码，因为它是工具、流程和文化集的一部分。
实施 ODD 的最佳实践
以下是实施可观察性驱动开发 (ODD) 的一些最佳实践：
- 从一开始就优先考虑可观察性：从一开始就在开发过程中考虑可观察性。这将帮助您及早发现潜在问题并实时进行必要的更改。
- 采用端到端方法：确保可观察性涵盖系统的所有方面，包括基础设施、应用程序和最终用户体验。
- 监控和记录一切：从所有来源收集数据，包括日志、跟踪和指标，以全面了解系统的行为。
- 使用自动化工具：利用自动化的可观察性工具实时监控系统并提醒您任何异常情况。
- 与其他团队协作：与DevOps、QA 和生产等团队协作，以确保将可观察性集成到开发过程中。
- 持续监控和改进：定期监控系统，分析数据，并根据需要进行改进以确保最佳性能。
- 拥抱持续改进的文化：鼓励开发团队拥抱持续改进的文化，并持续监控和改进系统。
结论
可观察性驱动开发(ODD)和测试驱动开发(TDD)都在确保软件系统的质量和可靠性方面发挥着重要作用。TDD 侧重于在 bug 损害系统或其用户之前检测并修复它们，而 ODD 侧重于实时监控软件系统的行为以识别潜在问题并了解其在不同场景下的行为。
