编者按：这篇客座博客文章由海德堡Druckmaschinen的Java开发人员Jan Hoppe贡献AG。就像在我们的数字经济中，几乎所有的事情，建造一个现代化的印刷机需要大量的软件。作为一名JAVA开发人员，我第一手了解到这一点——DevOps在海德堡德鲁克马斯奇宁公司（Heidelberger Druckmaschinen AG）的领导，也就是世界上最大的胶印机制造商海德堡（Heidelberger Druckmaschinen AG）。软件越来越多地驱动着我们的工程系统，支撑着我们几乎所有的产品和服务，包括我们最新一代的智能连接数字印刷机。我们有十几个开发团队，运行着大约180个连续的交付管道，所有这些都集成到一个统一的系统中。当然，像我们这样规模的系统的问题在于，有时您无法轻松地看到整个环境中正在发生的事情，特别是可能会阻碍关键价值的问题和瓶颈溪流。和这正是CloudBees DevOptics开始扮演有价值的角色的地方，它帮助我们找出价值流中的障碍，并提升价值我们开发团队的生产力和速度。顺便说一句，我们的大多数团队都采用了使用CloudBees核心的连续交付方法来自动化我们的软件开发环境我第一次见到CloudBees Devptics是大约一年半前，也就是DevOps World | Jenkins World 2017之后不久，当时我正在汉堡参加一些后续会议。在观看CloudBees DevOptics价值流的演示时，我被它提供的整体基础设施的清晰"大图"所震撼。你完全可以想象出它的复杂性。此后，我使用DevOptics自动绘制出整个系统的价值流海德堡我们从DevOptics获得的可见性使我们能够更快地发现问题，并更自信地采取行动解决问题。也许一个API被更改了，它破坏了一个构建。或者某个进程挂在某处。现在我们可以立即找到问题的根源并着手解决。我们可以追踪所有这些变化。了解项目之间的各种依赖关系也有助于我们决定需要构建哪些组件和路径来启动系统日期。使用Devptics，我们正在收集一些良好的性能指标，这些指标有助于我们了解团队生产力和开发操作的效率。一种叫做部署频率（DF）的度量方法（即，我们将代码部署到生产环境中的频率）让我们对软件交付的总体速度和效率有一个很好的了解生命周期。另一个我跟踪的指标是平均恢复时间（MTTR），也就是我们修复问题的速度。这个数字很有趣，因为如果它在增加，那么某些东西就走错了方向！值得注意的是，在DevOptics之前，衡量这些指标——以及其他指标，如平均交付周期（MLT）和变更失败率（CFR）——实际上是不可能。去公平地说，我们在海德堡才刚刚起步，要充分发挥其潜力还需要时间。但我相信，DevOptics带来的更大的可视性将转化为更快、更高质量的软件开发，这对任何公司来说都是巨大的竞争优势。让我们的开发者保持尽可能高的生产力将使他们能够进行更多的创新，并且更快地创新。这对海德堡。附加资源学习如何使用CloudBees Devptics了解最新的CloudBees Devptics功能样例如何创建价值流的实时地图