理解数据中的关系与向上趋势一样重要。
译自 DevOps Success Isn't Always Numbers Going Up，作者 Andy Corrigan。
故事时间！在过去，我曾在知识管理部门工作过一段时间。在那里，我维护着组织希望帮助内部客户自助的内容。
该组织以前从未拥有过一个合适的知识库，之前将所有技术 支持文档 存储在无数个多年未更新的 PDF 中。在我开始工作之前，所有这些内容——过时且在许多情况下毫无用处——都被复制粘贴到新的知识库中，没有任何更改。
恐怖。
但这并不是我最初几天里唯一令人恐惧的经历。在与管理层的会议中，我们会讨论我们这个小型新成立团队的成功标准，这将带来进一步的惊吓。
“写一篇知识文章需要多长时间？”是第一个令人不寒而栗的问题，就好像“一篇文章”可以是一个可量化的指标一样。网页的长度当然不同，每个页面所需的时间取决于主题的深度或复杂性。
然而，真正的恐怖在于，当我意识到经理对新 知识库 的唯一成功愿景是我们每周可以添加多少篇文章。
为了内容而存在的内容很少有用，但需要重申的是，我们的起点是十多年来未经批判地粘贴到不适合该格式的系统中的旧 PDF。
仍然相关的页面需要进行大量的重写，因为它们在搜索中找不到，或者没有考虑到可访问性。许多页面不适合非技术受众，坦率地说，这几乎是我们整个受众。
为了使知识库变得有用，我们的大部分工作将涉及通过重写、合并和删除不再相关的页面来减少内容量。
成功实际上可能意味着减少页面数量这一现实让大家头脑发热，因为“数字必须上升”是唯一对向我汇报的人有意义的指标。更多总是更好；每个人都知道这一点！
由于这种心态，我经常被阻止使内容变得有用，这意味着即使人们能够找到它，他们也并不总是能得到他们需要的帮助。
所以，如果帮助内容找不到或无法理解……为什么要有知识库呢？
但是，嘿，对于那些向上汇报的人来说，一切都很好：“我的团队表现出色，因为你看，数字在上升！”
其中一些冲突指出了一个系统性的文化问题，突出了当团队没有共享目标时，事情会变得多么糟糕。更重要的是，它还表明，当你的成功和价值观如此之少、狭隘和孤立时，你很容易失去对成功和价值观的真正意义的认识。
在这个轶事案例中，没有办法证明显而易见的事实——即相同的信息，但更容易阅读和查找，可以减轻其他支持部门的负担——因为没有机制来建立这种关联。可能让我们找到内容和客户行为之间联系的信息来源，奇怪的是，却被拒之门外。
这里的教训是，通过过度关注“数字上升”，而不了解这些数字在更广泛的背景下的含义，很容易错过衡量活动对彼此产生的关联影响。你只会掩盖你可能找到新益处的领域。
值得庆幸的是，对于我们这些在软件开发领域的人来说，像持续交付和 DevOps 这样的意识形态可以帮助你将这种可见性构建到你的系统中。强大的 监控和可观察性 是两者中核心推荐的做法。
例如，根据 Octopus 白皮书“持续交付的重要性” ，持续交付不仅建议跟踪每个数据源，而且建议在一个系统中进行跟踪，这样你就可以看到原本不明显的关联关系。它还建议在与你的技术指标相同的系统中跟踪业务指标，以查看技术变更何时对业务产生负面或正面影响，反之亦然。
仔细分析数字（贬义）
听着，我理解在商业中，一些数字必须上升是自然的。组织当然希望看到利润率上升。同样，采用 DevOps 的软件团队应该努力实现更多提交、构建和部署，因为这些都是组织成功的已证实预测指标。
然而，将“数字上升”作为衡量所有任务成功的唯一指标，就等于否认了你对整个业务中价值的含义的完整理解。有时，在一个领域做少一些，才能在其他领域做更多，如果你在信息之间筑起墙，你就无法找到平衡点或需要调整的地方。
只有最大限度地利用可用信息，你才能自信地做出这些决定。上下文为王，如果你不了解数据之间的关系，你就会错过上下文。
