可观测性驱动的软件开发（Observability Driven Development，缩写为 ODD）鼓励开发团队在整个开发过程中考虑应用程序的可靠性和软件质量，利用工具或是开发人员的插桩来观测系统的状态和行为。可观测性并不是要直接调试代码逻辑，而是在每次新功能或者版本发布到生产环境后，检验生产环境的状态，帮助发现并定位潜在问题，找出系统中需要调试的代码所处的位置。
这里有一些最佳实践和准则可以遵守，包括建立文化、有意义的代码插桩，还有选择合适的可观测工具。
建立文化
开发不应该只是关注于产品功能的实现，也需要为系统整体的可靠性负责。在这个认知的前提下，我们也需要建立可观测性驱动的开发文化，鼓励开发更好地参与到可观测性的建立上来。
拥抱失败：与其害怕失败，拼命避免失败，不如认清现实，那就是 100% 可靠的系统在现在这个时代是不存在的。所以我们首先需要承认，我们不可能预测到代码在生产环境中出现问题的所有方式。所以说，如果仍然只采取测试驱动的开发方式，是无法有效地编写所有的测试用例的。
允许犯错：同样，也正是由于这个世界上没有 100% 可靠的系统，如果不能容忍一个因为无心之失引发的错误，那整个团队就会变得畏手畏脚，抵触改变，进入一种少做少错的状态。这绝对不是我们的初衷。我们事件后审查的目标应该是识别系统和流程中的弱点，并通过建立可观测性和工程化来避免这个错误再次发生。
拒绝个人英雄主义：英雄文化是建立可观测性的文化的障碍。如果你的团队中只有极少数人拥有在生产环境中进行故障排除所需的知识，风险就比较大了。因为现代分布式系统比几年前的系统复杂得多，继续依靠少数人甚至一个人的能力来理解和调试这些系统是不可信的。我们应该去让大家都能够理解可观测性，学会使用工具分析问题，减少对少数“专家”的依赖。
更新之后尽早排查：当开发人员把代码部署到生产环境后，应及时通过可观测性来查看生产环境的状态，而不是被动地等着最终用户反馈问题。构建系统的开发人员比任何人都更了解系统，如果及时注意到那些可以在早期修复的异常，可观测平台的效果就充分显现出来了。
鼓励有意义的代码插桩
我们在代码设计阶段，就必须考虑和确定系统在生产环境运行时需要达到的目标。比如说，定义好服务水平目标 SLO，为了提供预期的服务质量，你需要什么程度的可观测性？你的用户关心什么？他们会注意到什么？试图找出可能出错的地方，以及提前发现错误的方法。
极客时间版权所有: https://time.geekbang.org/column/article/575311
代码插桩主要包括下面几种类型。
第一种类型，日志推荐，它是以 JSON 方式输出的。这个方式最重要的是在日志输出过程中能够添加与业务分割相关的标签（即我们常说的 tag），以便后续的日志分析统计。
第二种类型是链路追踪。一般情况下，我们可以通过无埋点的方式进行追踪，但是如果开发工程师针对部分业务可以进行深入的埋点，或者集成更多业务相关的标签，那会更有意义。
第三种类型是用户体验监测，即 RUM（Real User Monitoring）。如果前端或者 App 端开发工程能够将用户体验也纳入到整体的可观测性范围内，那么就可以进一步地保障用户的服务质量，更有效地发现和定位问题了。前端或者 App 端团队要对用户体验进行集成，可以采用插桩或集成更多业务相关标签等方式。
最后，我们还可以建立统一的数据规范。例如，相同的指标命名规范、相同的日志格式、相同的链路系统（即使都遵循 OpenTelemetry 标准，仍会出现不同），定义串联整个系统的统一标签规范（如，所有错误都是 Status: Error）。
《深入浅出可观测性》课程笔记 day08
