在上一篇文章“ 如何不收集配置管理数据”中 ，我简要介绍了我和其他人过去尝试过的一些丢失的CM数据方法。 这些方法中的大多数都是要求人们提供信息，将他们的答案放在文档中的某个位置而不再查看文档的方法。

这次，我将描述我们团队最终做出的一项关键突破-使得收集和更新相关数据变得更加容易。

突破是闭环的概念及其与配置管理的关系。
[[碰巧，这个概念在配置管理界是众所周知的，但在当时我们并不为人所知。 因此，我们发现了其他人已经知道的东西。 我说我们在一定程度上是取得了突破。]

我们将必须建立闭环概念。 让我们开始看看谁拥有组织中最好的CM数据。

谁拥有最好的CM数据？

不同的组织是不同的，因此很难对谁拥有最好的CM数据做出笼​​统的声明。 但是我所能做的就是为我的工作场所提供答案，并且希望这些原则会有意义，即使工作地点的实际情况有所不同。 但我敢打赌，许多组织都非常相似。
为了避免让您感到悬念，答案是…

获胜者：发布团队。 在我工作的地方，发布团队拥有最好的CM数据，其中“最好”的意思是诸如全面，准确和积极管理的内容。 发布团队知道哪些应用程序在哪些服务器上运行，哪些服务帐户可在其下启动Tomcat或JBoss，在部署过程中抑制哪些警报，等等。 他们在所支持的所有应用程序中都了解这些事情。 全部记录在案（在YAML文件，数据库，脚本等中），并且都实时维护。
让我们看看其他球队。

• 应用团队具有非系统数据。 应用程序团队通常会知道其应用程序的URL，其应用程序所在的服务器（或至少是VIP），其应用程序与其他相邻系统（Web服务，数据库）之间的相互依赖性。 但是知识不够系统化。 它更像是浏览器书签，部落知识和不最新的Wiki页面。 而且任何给定的开发人员都知道他自己的应用程序，也可能是他从事的最后一个或两个应用程序，但不是全部。
• 运维团队必须依靠繁忙的开发人员来获取信息。 运维团队的信息根据其与应用团队的接近程度而有所不同。 NOC中的团队几乎完全由应用程序团队来决定编写和更新知识库文章。 如您所料，确保开发人员在截止日期之前编写可靠的KB文章并维护较旧的文章可能是一个挑战。 对于NOC来说，面对这样的挑战，了解谁是应用程序中小企业是非常重要的。 甚至随着组织的变化，新应用程序的出现，旧应用程序的新名称等等的出现，这种情况也不总是很清楚。
• 应用支持团队更多地是由专业知识驱动而不是数据驱动。 应用程序支持团队（他们负责处理NOC的升级问题）通常对应用程序本身更为熟悉，因此对应用程序的了解会更深，但是对于“有问题的孩子”应用程序，这些知识往往会更强。 同样，不同的人倾向于通过特定的应用程序开发专业知识。

为什么发布团队拥有最好的CM数据？

发布团队拥有最好的CM数据，因为正确维护的CM数据对于他们的工作至关重要，而其他团队则不会。

首先，快说吧。 如果您的公司不受SOX的监管，您可能想知道发布团队是什么以及我们为什么拥有发布团队。 在许多其他事项中，SOX要求将编写软件的人员与在生产环境中部署/支持软件的人员分开。 发布团队的主要职责是将软件发布到生产环境中。 实际上，我们有几个发布团队，每个团队都为许多应用程序提供服务。 从成本和利用率的角度来看，让每个应用程序团队拥有自己的专属发布工程师是不可行的。 发布团队通常在凌晨时间内以小批量发布软件。

回到这个想法，即发布团队比其他团队更需要适当的CM数据。 我为什么这么说？

这就是为什么。 软件开发团队非常有动力定期发布软件。 数量有限的发行工程师必须为数百个应用程序提供服务（尽管通常不是一次全部），因此，在了解在何处部署内容时，“部落知识”不是可行的策略。 必须对其进行彻底而准确的记录。 发布会在每周的深夜进行，因此发布团队召集他的好友到应用程序团队并请求应用程序服务器列表是不合理的。 发布团队需要这些信息，唾手可得。 如果他们没有，则软件组织将无法实现其开发投资的价值。
实际上，“记录在案”在这里是错误的词，因为部署自动化驱动了部署。 CM数据必须正确地“可操作”，这意味着它必须可以通过自动化来使用。 没有Word文档，没有Excel电子表格，没有Wiki页面。 更多类似YAML文件，XML文件，针对CMDB的Web服务调用等。
重要的是，当数据错误时，部署将失败。 人们真的很在乎部署不会失败，因此，如果存在数据问题，人们一定会发现并修复它们。 让我们再次查看应用程序和操作团队。

• 应用团队无需大量CM数据即可完成工作。 应用程序开发人员对其CM数据的依赖性更弱。 是的，开发人员需要知道他的应用程序调用了哪个Web服务，但是有人只是在解释说他加入该项目时就已经足够了。 如果他对传递依赖有疑问，可以向队友询问。 如果他需要在测试环境中使用该应用程序，则可能将URL标记为书签，并将凭据记录在某处，但是如果没有，他可以轻松地向某人询问。 在99％的时间内，开发人员无需参考特定的CM数据点就可以完成他需要做的事情。 开发人员可能会或可能不会针对CM数据进行自动化。
• 运维/支持团队需要良好的CM数据，但短期到中期的专业知识则便宜。 除了涉及非常激进的SLA的情况外，甚至操作人员对CM数据的依赖性也通常比发布团队要弱。 由于（希望）应用程序中断发生的频率比应用程序部署发生的频率要低得多，因此知识库投资的回报要比部署自动化的回报少。 如果所涉及的应用不是特别重要，那么对知识库文章的投资确实可能非常有限。 在大多数情况下，对严重的支持火力进行投资（当出现问题时，需要大量的专业知识来解决问题），可获得更好的中短期回报。 （当然，从长远来看，该策略会失败，因为最终会因为代价高昂的停机而使企业停运几天。这是另一天的主题。）

现在，我们可以轻松了解闭环以及为什么闭环对于配置管理数据如此重要。

闭环及其重要性

我想到这样的闭环。 我们要针对CM数据建立和维护一个“稳定状态”。 我们希望它是全面，准确和相关的。 当CM数据的状态偏离所需的稳定状态时，我们需要反馈循环来提醒我们注意这种情况，以便我们可以解决它。 那是一个闭环。

示例1：部署自动化。 最好的例子就是我们已经描述的例子：部署数据。 部署数据驱动部署过程，如果数据错误，则部署过程将失败。 由于部署过程对组织极为重要，因此一定程度的紧迫性关系到修复错误的数据。 但这不仅是错误的数据。 如果我们需要部署应用程序，而CMDB中缺少数据，那么抱歉，没有部署！ 请放心，如果部署很重要，那么丢失的数据只是暂时的问题。

示例2：细粒度的访问控制。 这是另一个示例：团队成员资格数据。 我们已经注意到，出于运营原因，了解谁在哪个开发团队中非常重要。 这不是人力资源系统中要解决的事情，与更新团队成员数据相比，人们要做的事情更好。 但是，当该团队成员资格数据驱动ACL来执行您关心的事情时，例如将应用程序部署到开发环境，会发生什么呢？ 现在，您将看到更好的团队成员数据。

基本概念是找到人们真正非常关心的东西，然后使其完全依赖于拥有良好的CM数据：

理想情况下，最好是CM数据驱动人们关注的自动化流程，但这不是绝对必要的。 例如，在我的组织中，有一个相当健壮但手动的目标计划和目标跟踪过程。 整个部门每个季度都要经过一个目标计划过程（我的目标汇总到老板的目标等等），然后我们每两周就这些目标跟踪进度。 目标规划和跟踪应用程序需要有关谁在哪个团队上的正确信息，因此这有助于在团队成员资格数据上建立另一个闭环。 它还说明了您可以通过多个循环访问相同类型的数据的意义。

全面设计CM策略

全面了解设计需要在技术的几个领域中进行：安全性，用户体验和系统测试。 在每种情况下，您都需要在更广泛的组织环境中考虑给定的技术系统。 （如果人们不得不在便利贴上写下超级双密码，那么密码要求无济于事。）
配置管理是采用整体方法进行设计的另一个有意义的地方。 对于任何给定类型的数据（此处没有一个万能的答案），请尝试找出依赖于它的重要内容，然后找出如何将这些内容与您的数据相关联，以便车轮开始掉落如果数据错误，不完整等。 同样，数据驱动的自动化流程在这里更胜一筹，但是任何重要流程（无论是否自动化）都将有所帮助。

会议更少？

差点忘了。 在上一篇文章中，我提到我将使您摆脱一些毫无意义的会议。 有问题的会议是有人希望与您聚会以收集您的CM数据，以便他们可以将其发布到其Sharepoint站点的会议。 拒绝这些-他们只是浪费时间。 坚持人们能够清楚地说明将要创建的闭环，以确保有人发现数据中的空白和错误。 我参加过很多这样的会议，在某些情况下，它们被设置为半天或全天会议。 我不再做那些了。

我正在开发一个名为Skybase的开源CMDB，它可以帮助您建立闭环配置管理。 请参阅Skybase GitHub网站 。

参考： 闭环：从Skydingo博客的JCG合作伙伴 Willie Wheeler 收集配置管理数据的秘密 。

相关文章 ：

• Devops：如何不收集配置管理数据
• Devops使发布和部署变得很酷
• 如何解决生产问题
• GlassFish响应生产中的GZIP压缩