一家公司希望缩短开发新功能的时间。它使用 CodeBuild 和 CodeDeploy 来构建和部署应用程序，并且每个微服务都有一个独立的 CodePipeline CI/CD 管道。公司需要更好地了解一些指标，例如功能发布之间的平均时间以及部署失败后的平均恢复时间。哪种解决方案能以最少的配置工作量提供这种可见性？

正确的解决方案通过在每次管道运行成功或失败时触发 Lambda 函数来实时捕获数据，该函数随后将自定义指标发布到 CloudWatch。这种事件驱动的方法确保了数据的准确性和及时性，避免了不必要的轮询。CloudWatch 控制面板可以直接利用这些指标，提供功能发布和恢复时间的即时可见性，且配置工作量最少。 其他选项的缺点： 选项1的轮询机制（每5分钟调用一次Lambda）会导致数据延迟和不准确，无法提供实时洞察。 选项3和4将数据写入DynamoDB，然后使用QuickSight创建控制面板。虽然可行，但这引入了额外的组件（DynamoDB和QuickSight），增加了配置复杂性和成本，不符合“最少配置工作量”的要求。CloudWatch本身就具备指标收集和可视化功能，是更直接的解决方案。