Joseph Sibony
更多的信息总是意味着更好的结果吗？这完全取决于项目所处的环境。
以烘焙为例。当你做蛋糕时，你的原材料经历了许多化学变化和烹制过程。如果任何一个环节出现问题，蛋糕就做不好。但这并不意味着你需要理解食材在分子级别上发生了什么，你只需要具备高层次的知识能够发现你哪里出错了并在下次改正。
当然，如果你经营一个蛋糕工厂，这仍然是烘焙， 只是正在发生的相同情况的规模更大，你需要可靠的方法来监测化学过程和变量。如果没有细致的信息，你将无法迅速找到问题的根源，改进生产过程，并避免高成本试错误。
在任何开发团队中，构建可视化都是如此。假设你是一个小组织或团队，只有几个相对简单的构建项目需要关注。如果一个构建失败，可能不会太难追溯你的步骤并找出错误。这可能只是一个简单的情况，例如，滚动查看手动日志，询问你的同事谁改变了一段代码，并进行更正。
这并不是说你不需要任何构建可视化。毕竟，你仍然需要知道问题出在哪里，尤其是如果你将来想要扩展的话。但在这种情况下，匆忙采用一些更复杂的工具将相当于在你的厨房安装最先进的、NASA 级别的温度和湿度监测设备，因为你担心你的巧克力酱可能会融化。更简单的工具可能会给你所有你真正需要的洞察力，而不需要先把复杂难懂的工具搞定。
构建越多， 问题越多
然而，对于规模较大的团队，这种基本水平的可视并不能提供足够的细微足够深入的洞察来确保项目扩容增长。你的项目越复杂，团队越庞大，运行的构建越多，就越难以发现深埋在你的文档中的错误，尤其在通过翻阅文本日志的方式定位错误而不是使用高效的具有可视化功能的工具的情况下。
与其对问题作出反应，并想办法避免后续同样的错误，不如在你的扩容阶段收集细微的日常洞察，用它们来解决构建中的更大问题。
你是否不断重复地看到相同的错误和瓶颈？你是否没有充分利用你的处理能力？或者距离最大容量太近，冒着崩溃的风险？最好在你过载的系统崩溃之前，就发现负荷过重的迹象并解决。
适应不同团队成员的习惯
如果你的团队规模太大，以至于你的开发人员和 DevOps 同事甚至不在同一个部门工作，并且需要完全不同类型的信息才能有效地完成工作，会发生什么呢？
再次想象我们用来打比方的蛋糕工厂：主面包师在一个部分监督生产，而你的技术或工程团队则在另一个部分设置。每个人都希望确保最终消费者得到最好的产品，但与你的开发团队和 DevOps 团队对待这个挑战的看法并不相同。
与开发人员类似，面包师们主要关注检查最终产品以确保它是正确的，例如，原料是否没问题？机器是否出故障？生产线上的某人是否弄错了他们的任务。
另一方面，工程师和技术负责人更像是你的 DevOps 团队。他们担心机器的运行细节，或者其他可能引发不可预期的状况，最终影响结果。他们在寻找超越直接原因以外更高层次的东西，举个例子，问题表象是“这个组件一直崩溃”但其实本质是关于潜在条件和每个元素工作的复杂性。他们需要确切地知道他们可以做什么来确保它不会失败，以及如何持续调整全局，通过最大程度地提高性能来避免未来出现更多问题。
更好的策略，灵活调整
当制定开发和 DevOps 团队的构建可视化策略时，意味着我们需要一种方式来满足两种类型的洞察：为开发团队提供主要、宏观级别的洞察，并为 DevOps 提供关于更旧加详细、精确、持续的信息流。
这样，它们可以完美地互补，共同定位问题并加快构建速度，确保它们发生计划之外所需的 CPU 容量，并确保最终用户得到尽可能好的体验。
简而言之，为团队制定完美的构建可视化策略完全取决于组织。它受到团队规模、结构方式、构建项目的大小以及复杂程度等因素的影响。
话虽如此，给自己留有扩容的空间总是好的。即使是一个拥有简单代码库的小团队，不需要也没有时间监控每一小块数据，仍然需要简单、可靠的方法来找出你的构建中出了什么问题。否则将无法进行扩展。
这就是策略发挥作用的地方。
打造长期赢家
无论你的组织规模如何，你现在不应只考虑勉强度日。你还要考虑如何未雨绸缪你的流程和系统。
如果开发团队具有适合的构建可视化能力，过去的错误和更持久的问题将更容易被识别，比如编译时间、利用率、系统容量以及网络处理能力等问题，这样你就不会在下一个更复杂的构建过程中遇到障碍。
对于大型团队来说，风险就更大了。如果没有这些洞察，要保持灵活和竞争力就会很困难，特别是如果新兴的竞争对手已经拥有了一流的构建可视化策略。我们需要在被赶超之前找出如何应对的方法。
如果你喜欢本期博客，并想了解更多有关开发构建可视化策略及工具选择的详细建议，请在此下载完整的白皮书。
