在IT领域，往往在确定确切需求之前，变化就已经发生。

首先是DevOps，以加速软件交付，然后是基础设施即代码，以继续云之旅并进一步加快部署。现在我们看到可观测性即代码，其目标不是让事情变得更快，而是深入了解什么工作在以非常快的速度完成。

与基础设施即代码类似，可观测性即代码使用代码来促进可观测性工作流中的自动化和可重复性，旨在让开发人员团队了解整个软件堆栈。

对可观测性的需求源于现代应用程序的范围和复杂性的增加。与传统的单片方法相比，现代应用软件堆栈是云中的分布式设计，通常在没有主机系统的情况下运行。

这限制了IT团队在故障排除方面的选项：如果你在无服务器云环境中执行代码，则没有传统的平台进行故障排除。对于DevOps专业人员来说，这种故障排除差距创造了一种新的需求，可观测性旨即代码在满足这种需求。

但是，可观测性即代码是否适合你的企业？在决定是否部署该方法时，请记住以下注意事项。

部署可观测性即代码需要权衡取舍

可观测性即代码工具的供应商承诺了很多，从可重复的最佳做法和改进的协作，到提供深度见解的仪表板。

从表面上看，这听起来很不错；它可满足管理层的很多需求。但是，虽然提供对软件堆栈的更多可见性的自动化方法似乎很好，但可观测性即代码也有其缺点。

复杂性

首先，可观测性即代码涉及权衡：更复杂的整体软件堆栈，以换取更深层次的洞察力。

在整个软件过程中，请确保最佳实践是可重复和协作的，这有助于解决软件堆栈的整体复杂性。但是，第三方工具（例如Splunk和Terraform）在从仪表板中获取所需的见解时仍然增加了复杂性。

性能问题

采用可观测性即代码可能不会在应用程序中产生性能问题。但是，如果你曾经在应用程序中执行过详细日志记录，你就会知道生成所有这些数据可能会产生影响。此外，收集和存储这些数据并挖掘信息可能会产生大量费用。

时间

另一个问题是部署可观测性即代码框架所需的时间。由于在DevOps中速度非常重要，因此延迟通常不受欢迎。添加任何新延迟风险都会受到阻碍，特别是对于云端更大规模的分布式应用程序。

相反的论点是，采用可观测性即代码最终将节省时间，因为它使DevOps团队能够加快故障排除过程。但这些时间节省可能主要（尽管并非完全）发生在部署之后，而不是在创建过程中。

跟踪

可观测性即代码工具也不会跟踪基础结构或网络问题。当然，这种代码可以为你指明正确的方向，但它不会解决防火墙问题或虚拟LAN问题。

还有多云工具和应用程序的问题。因为没有两个云以相同的方式做所有事情，所以你被迫根据你所在的云进行调整。

可观测性即代码是必要的吗？

最终，真正的问题是你的企业是否需要可观测性即代码。

与IT中的很多事情一样，没有直接的答案。不断增加的应用程序规模、无服务器应用程序的兴起以及当今IT环境的整体复杂性和互通性意味着，企业必须为出现的问题提供解决方案。但是答案是可观测性即代码还是它的修改版本？

最有可能的是，这将是一个混合体，因为很少有IT组织在纯状态下运行任何东西。事物永远不会落入简单、理想的类别，每个企业都是不同的。

但是，随着云部署的继续发展，以及DevOps 团队需要对关键应用程序的更多见解，对强大的可观测性实践的需求将继续增长。可观测性即代码的这部分部分并没有被夸大;事实上，这将是云计算和无服务器应用程序未来的关键点。

可观测性即代码的可重复最佳实践和理想的协作方面更像是一种“可有可无”功能，很多供应商对这些方面的细节含糊不清。这类似于多年来在监控中承诺的单一管理平台方法：每个人都在谈论，但很少有人能在实践中展示。