使用自动化提升您的 ITIL
使用自动化提升您的 ITIL
在自动化和敏捷的世界中，信息技术基础设施库 (ITIL) 似乎不再发挥作用，被视为一种“老派”框架。在作为众多 IT 组织流程指南和蓝图服务了这么长时间后，它是否即将走向终结？
本系列文章展示了自动化，更具体地说，Red Hat Ansible Automation Platform 和基础设施即代码 (IaC) 原则如何帮助将一些 ITIL 主题融入敏捷和自动化的美好体验。
- 配置管理
- 变更和发布管理
- 事件和问题管理
因此，让我们深入探讨配置管理主题，以及每个人仍然熟知的 CMDB（配置管理数据库），即使 ITIL 早已将其称为 CMS（配置管理系统）。名称变更旨在强调该功能可以通过多种数据库和工具的组合来实现，但这在这里并不重要，因此我们将坚持使用臭名昭著的 CMDB 术语。
您喜欢您的 CMDB 吗？根据我与众多客户的经验，可能不是。数据通常过时且错误，被认为无用，这意味着其维护被视为一项苦差事。这意味着它以尽可能少的努力，以粗心大意的方式进行维护，使其更加过时，并陷入恶性循环。
为了避免崩溃，我们首先需要了解 CMDB 和相关的配置管理有两个主要目的
- 记录您环境的期望状态 - 这通常是手动完成的，管理员需要在“现实世界”中维护一次配置，并在 CMDB 中维护一次。为此，公司通常从环境发现中填充 CMDB，这会导致一个记录当前状态的数据库。请注意，不清楚它是否与期望状态相对应。
- 通过允许分析环境来支持变更管理流程，例如，在安装新的臃肿软件之前验证每个服务器上是否有足够的可用磁盘空间。基于对数据质量缺乏信任的认识，它通常被忽略作为流程的一部分。
查看上述缺点，我们需要首先更清晰地构建我们的数据库，因为它包含多种类型的数据
- 期望状态数据 - 这是来自服务或变更请求的信息，表示您在环境中需要拥有的内容。
- 实际状态数据 - 这是从环境中发现的信息，表示其当前状态。
由于数据可能仅为期望状态、仅为实际状态或两者兼而有之，因此我们有三个类别，为了简单起见，我们将用 A 到 C 来表示它们。
由于管理员不希望维护两次期望状态，因此您在您的 CMDB（类型 A 和 B）中使用期望状态作为 Ansible Automation Platform 的清单源，以根据其配置您的环境。管理员知道，CMDB 中的数据越好，现实世界中的结果就越好，从而导致工作量减少。这应该足以激励您快速提高 CMDB 的数据质量。
由于 CMDB 不会将类别 A 数据的期望状态和实际状态混合在一起，因此您可以检测到差异，决定如何修复它，并再次使用 Ansible 进行自动修复。这应该可以帮助您快速使现实与期望状态保持一致，并拥有正确的数据来做出决策。
类型 C 的数据对自动化没有多大用处，旨在用于变更管理流程中的决策，尽管您可以决定跳过修补周期，如果磁盘已满。也就是说，您不应该将此方面与监控混淆；监控磁盘已满情况并快速更正它属于事件管理，而不是配置管理。
一旦您完成了这个第一阶段，您可以进入下一级，并使用 Ansible Automation Platform 自动填充 CMDB 中的期望状态。
假设您有一个服务门户，客户可以在其中订购新服务或修改和停用它们，使用服务目录和对话框引导他们完成需要做出的选择。使用通过对话框获取的输入变量，服务门户可以使用自动化控制器的 API 触发工作流来实现服务。然后，工作流的第一步之一是将这些输入变量作为期望状态（类型 A 和 B）输入到 CMDB 中。它的优势在于，如果工作流作业失败，您仍然拥有记录的期望状态，并且可以在修复故障根本原因后再次触发该操作。
现在最好拥有像 Git 中那样的提交、分支和标签功能，以便轻松回滚此类更改。但也许有人会根据本文发明一个具有此类功能的 CMDB。在此期间，将 Ansible Automation Platform 连接到您的 CMDB，并通过自动化为您的 CMDB 添加价值和质量。
了解如何将 Ansible Automation Platform 用于配置管理
观看视频教程
这段 8 分钟的概述视频 突出显示了 Ansible Automation Platform 最新版本中包含的组件和功能，以及它们如何协同工作以提供全面的企业自动化体验。
