针对如上问题，笔者发现测试方法由于来自于外部，所以并不存在解耦和跨栈的问题，但可观测性方法，由于与IT单元伴生存在，无法回避解耦和跨栈的问题。

但遗憾的是，在Tracing方向，无论是各类开源或商业的APM，还是Open Tracing/Open Telemetry，都或多或少地需要介入业务运行环境，而无法实现解耦，并且都局限于业务层或云原生，导致缺乏对很多架构组件、操作系统的观测能力。

而在Metrix方向，Prometheus或者Zabbix等方案由于更侧重于架构和组件的状态级监控，欠缺细粒度的应用组件和业务层监控能力，所以缺乏对一个完整的信创集成项目的全面可观测性能力。

由于如上能力的缺失，在笔者参与或了解的多个信创项目，都出现了各种不同程度的质疑、试错、延期等问题，而即使调通上线、通过验收，后期仍然会不断出现各种异常和不确定性，并需要重新邀请第三方公司进行排障和调优的情况。

综上，通过剖析信创项目落地过程中最现实的两类问题，可以简单地得出一个结论，即要加快信创落地的量与质，让更多的用户无疑虑地拥抱信创，本质上是要提出符合信创特征的可观测性方法论和与之配套的产品方案。

一方面，要实现与环境的解耦，才能够在测试环境和（准）生产环境平滑迁移，才能够公允地测量欧美产品与信创产品的差别，才能够让用户放心地在生产环境长时间使用，否则，任何与环境的耦合方法，都可能会因为影响结论评估的准确性和可靠性，而受到用户质疑。

另一方面，要具备从底层硬件或操作系统，到基础软件组件，再到业务系统的跨栈监控能力，既能够通过业务性能表现去评估一个信创集成项目的整体质量，也能细粒度、无盲点地测量每个IT单元的处理性能。

简言之，要切实突破信创落地最后一公里，如期完成国家相关政策的目标，有关部门还需要配套更有针对性的测试和可观测性方法指导，而行业内每个具备测试和监控研发能力的单位，也应该积极深入到每个信创项目，尽快推出切实可行的测试和可观测性方案。