devops 数据库
引起您的注意了吗？ 好！
如果您从事开发工作，则必须弄清楚的一件事就是如何收集所有信息，这些信息将使您能够管理配置并保持应用程序正常运行。 当您在单个服务器上有两个应用程序时，这并不难。 当您将400个应用程序部署到跨多个环境和数据中心的数千个服务器时，要困难得多。
那你该怎么做呢？ 让我们从一些不起作用的事情开始。 在我的下一篇文章我将与大家分享， 做工作的方法。
快速背景
可能是由于某些心理问题，我一直是一名信息策展人。 特别是当我在管理部门时，准确了解我的应用程序的部署位置，它们所依赖的服务器，所依赖的服务和数据库，这些服务和数据库所依赖的服务器以及谁是中小型企业对于我来说始终至关重要。给定的应用程序，依此类推。
如果您在小环境中工作，您可能会想：“有什么大不了的？”
好吧，我不是在狭小的环境中工作，但是当我第一次执行此任务时，我可能会说“不出汗”。 （那是我的开发人员。）无论如何，我决定，现在是该部门周围的人可以回答有关我们系统的看似基本问题的时候了。
尝试1：WIKI WHEELER
我第一次尝试（数年前）时，我是十几个应用程序团队的主管。 因此，我创建了一个Wiki模板，其中包含了我想要的所有信息，并且我追赶我的团队来填写它。 我的热情使我获得了“ Wiki Wheeler”的绰号，这对我来说并不为人所知。 （几年后，我的一位经理与我分享了这些令人振奋的信息。）不过，我猜想其他经理也喜欢这种方法，因为他们也追赶他们的团队。
这种方法很好地开始了，因为所涉及的团队可以管理自己的信息，而且我本人就是Wiki Wheeler。 但这并没有持续。 通过不同的系统重新设计和部门重组，Wiki空间来了又去了，一些空间因疏忽而萎缩了，到处都是多余但矛盾的信息。 质量检查团队有自己的名单，发布人员有他们的名单，应用程序团队有他们的名单。 UX家伙可能甚至参与其中。 无论如何，大约一年后，这是一个大混乱，直到今天，我们的Wiki仍然是一个大混乱。
尝试2：我的巨大视野
第二次，我的方法是从所有应用程序开发团队收集信息。 我们有数百名开发人员，所以为了使事情高效，我发送了一封部门级电子邮件，告诉大家我正在将一个庞大的Visio文档与我们所有的系统放在一起，如果他们能回复的话，我将不胜感激。以及要求的信息。 虽然我必须发送比我想要的更多的垃圾邮件，但最终结果实际上是一个巨大的Visio图，到处都有成百上千的盒子和线条。 我为这件事感到非常自豪，我在部门绘图仪上打印了五六本，然后将它们挂在墙上。
您认为它过时多久了？
我不知道。 我严重怀疑这首先是正确的。 没有人（包括我本人在内）从未使用过该图来进行实际工作，并且其主要用途是使我们的工作场所看起来更加坚硬，因为墙上有大量的色彩工程图。
该图还有另外一个效果，尽管我不敢称它为实用程序。 由于了解所有这些应用程序以及它们之间的关系，我获得了完全不当的声誉。 这种情况持续了好几年，我自己没有错。 我提到它是因为它与下一次尝试有关。
尝试＃3：灾难恢复
这不是我的尝试，但是仍然值得描述，因为我不得不想象我们不是唯一尝试过它的人。
作为一家快速发展的公司，灾难恢复在几年前对我们来说已变得越来越重要，并且有很高的要求来制定计划。 这涉及到收集所有信息，如果我们的主数据中心陷入困境，这些信息将使我们能够保持业务运转。 负责这项工作的人员花了大约两年时间与应用程序团队或“专家”会面（我以及其他与我一样对事物之间如何关联具有最高层次了解的人），并将其记录在文档中。在Sharepoint网站上没人能看到它。
这根本没有用。 大多数人都忙于与她见面，因此信息质量很差。 应用被错误命名，应用套件被误认为应用，总之，结果是不正确或不可维护的。
尝试4：我们的外部顾问甚至更大的视野
经过重大重组后，我们引入了一些外部顾问，他们提出了自己的Visio。 到这个时候，我已经知道与面试团队并组建庞大的Visios是一种失败的方法，因此令我惊讶的是，一群高薪顾问会使用它。 好吧，他们做到了，他们的图表很好，“令人印象深刻”。 （轻轻地说）它也没有我们想要的那样有用和可维护。
尝试5：HP UCMDB自动发现
我们拥有HP uCMDB工具，因此我们的IT服务小组运行了一些自动发现代理，以用数据填充它。 它给uCMDB加载了许多没人关心的细粒度细节，而且我们看不到我们真正关心的东西（例如应用程序，Web服务，数据库等）。
尝试＃6：服务目录
我们的IT服务小组在ITIL方面非常重要，因此他们着手编写服务目录。 执行此操作的人将服务和应用程序信息收集到Excel电子表格中，并将其发布到Sharepoint网站。 但这并没有真正涉及到配置管理的细节。 主要是弄清楚我们提供了哪些业务服务以及哪些系统支持了哪些服务。
他们最终为公司打印了一张有光泽的全彩服务目录，但没人真正要求它，因此它比其他任何东西都更具好奇心。
也有其他尝试（Paul带领了一对我什至没有提到过的夫妇），但是现在您知道了。
为什么这些尝试失败了？
要了解这些尝试为何失败的原因，有助于了解它们的共同点：
- 首先，他们通常涉及尝试从中小企业收集信息，然后将其放入某种文档中。 这可能是Wiki页面，Visio图，Sharepoint上的Word文档或Excel电子表格。
- 信息到达那里后，没有人使用它。 因此，如果信息一开始是正确的和/或完整的，那么它早就过时了，并且没有任何机制可以将其更新。
通常，人们将这个问题视为数据收集问题，而不是数据管理问题。 需要有一种系统的，持续的机制来发现和修复错误。 没有一种方法可以完全解决管理问题，所有这些方法都只是假设组织将足够关心数据以使其保持最新状态。
在下一部分中，我将告诉您我们最终想出的方法。 正如所承诺的，这也是我将解释如何摆脱一些会议的地方。
参考： Devops：如何在Skydingo博客上不从我们的JCG合作伙伴 Willie Wheeler 收集配置管理数据 。
相关文章 ：
翻译自: https://www.javacodegeeks.com/2011/12/devops-how-not-to-collect-configuration.html
devops 数据库
扫一扫
545
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
