企业网络管理自动化的三个关键

我们从客户那里听到的一些最常见的挑战对你们中的一些人来说可能太熟悉了。IT 领域的事物总是在迅速变化，而且只会加快速度。DevOps、以云为中心的架构和软件定义网络的爆炸式增长使得让监控和管理工具与环境保持同步变得越来越困难。

这导致了另一个问题——管理层和个别团队缺乏对整个环境的可见性。大多数现有的企业网络管理工具在适应大多数组织中正在成为常规的快速变化和部署方面都很慢。

我们发现这通常是因为当管理困难且劳动密集型时，可见性会受到影响。如果需要手动过程来将监控添加到新系统中，那么它就永远无法保持最新​​状态。

通常，整个组织缺乏最新的视图会导致团队实施他们自己的单点解决方案，而且你处理的工具越多，它们就越有可能相互矛盾，更不用说增加了管理和培训负担，以及这可能导致的通信问题。

幸运的是，这些挑战中的大多数都可以通过相同的方式解决——自动化。我们需要一种方法来跟上快速和动态变化的环境，同时保持可见性、避免盲点并保持我们的 SLA。同时不会产生没有人有时间的额外管理开销。

自动化是我们在多年来一直在使用的东西，我们将自动化成熟度定义为 4 个主要阶段：

发现、监控、响应和人工智能或 AIOps。在过去 20 年的发展中，我们的平台已经发展到可以完成所有这些工作。让我们看一下它们中的每一个，您就可以开始了解您的组织今天可能在哪里，以及下一步可能是什么。

第一步：发现自动化

自动化的第一阶段是发现自动化。现在，这项技术一直以其最基本的形式存在。我们可能都使用过执行 ping 扫描或端口扫描的工具来查找网络上的设备。该技术在许多环境中仍然有意义，但它不再是全部答案。

如今，自动发现发生了很大变化。有很多东西是您无法可靠扫描的——孤立的虚拟系统、DMZ、云系统和微服务，仅举几例。现代系统利用 API 集成的力量使自动发现更快、更可靠、更完整，而不会产生网络流量问题。

例如，我们利用这些 API 直接从 ServiceNow CMDB、vCenter、Azure 和 AWS 等系统以及 SD-WAN 编排器中学习。我们提供入站 API 调用，允许用户将我们的系统与 Puppet/Chef 等现有工作流程链接，或轻松创建额外的自定义集成，而无需依赖昂贵的顾问。

第二步：监控自动化

下一阶段是监控自动化。这是添加新设备进行监控并正确配置它们的地方，不再需要手动干预。对于我们与之交谈的许多组织来说，他们甚至还没有真正走到这一步。造成这种情况的原因有几个，但最常见的原因之一是该领域的许多监控平台出人意料地不发达，而且内部开发资源稀缺且昂贵，如果它们存在的话。

为了有效地达到这一阶段，管理平台必须不仅能够在操作系统级别识别新系统，而且还能够检测诸如哪些服务或应用程序正在其上运行，以便就您需要监控的内容做出正确的决定在那个系统上。

例如，将 SQL 服务器作为 VM 启动应该能够监视操作系统、虚拟化堆栈、SQL 应用程序本身、适当的事件日志监视器、当它出现问题时向谁发出警报——这可能会因 SQL 问题而有所不同与操作系统问题相比——以及需要观察什么样的性能指标和统计数据。它还必须包括将其放入正确的类别、站点和业务工作流程（驱动报告的分组）中，以便新部署的系统始终显示在正确的报告中，并且不会漏掉任何东西。

第三阶段：自动响应事件

第三阶段是响应自动化。这使您的管理平台能够在您的 NOC 或工程师必须做任何事情之前采取独立行动来修复问题。为了以这种方式有效地自动响应，我们必须允许基于一天中的时间或一周中的某天等不同的操作 - 例如，如果您希望在工作时间做出不同的响应。它还应该允许依赖关系——例如，如果有其他服务器运行相同的应用程序同时出现问题，则采取不同的措施。

当然，应该有跨平台的能力——无论是路由器、Windows、Linux、交换机还是云托管提供商。这需要与这些设备进行不同的交互方法，因为有些需要 JSON API 调用，而另一些可能需要 SSH、powershell 甚至 telnet。

现在，这可能是一大步，一些组织会坚持要求操作员干预，至少要在采取行动之前批准行动——所谓的“点击重启”按钮。这对于采取激烈的行动是一个好主意，但它也让组织在完全自动化响应行动之前熟悉这个过程并验证他们的配置。无论哪种方式，我们的平台都支持这样做。

新领域：基于人工智能的自动化

最后阶段是基于人工智能的系统。如果您认为最后一步很重要，那么这远远不止于此。虽然围绕人工智能的确切构成显然有很多不同的定义，但我们在这里使用该术语来定义可以做出自主决策的系统。这通常被称为“AIOps”，它实际上只是将 AI 技术应用于您的常规操作。

例如，系统可以查看从您的监控平台发出的警报，并检测到某种警报发生过于频繁并且可能是误报，然后抑制这些警报，或者修改您的设置以阻止它们正在发生。或者它可能会注意到特定日志消息与后来的应用程序故障之间的相关性，并自动重新启动一些服务以修复问题，因为上次发生应用程序故障时这种方法有效。

理想情况下，人工智能管理系统将建立这些联系，并可能根据了解您的环境以及其他客户遇到的最佳实践和场景采取行动。能够决定允许哪些操作完全自主发生以及哪些操作需要操作员干预至关重要，尤其是在刚开始时。

人工智能最大的潜在缺点是它驱动了非常高的资源需求，通常超出了您自己提供的实际能力。这通常意味着您需要一些云托管资源来提供帮助，以便对进入系统的所有数据进行分类，这将驱动连接依赖以实现完整功能。

关键 #1：利用现有系统

因此，自动化 IT 管理的第一个关键是确保我们充分利用发现和监控自动化。显然，这里的第一步是使用我们的自动发现工具来确保在配置新设备时将其添加到监控中。

识别设备后，我们需要确保对它们进行全面的监控自动化，因此我们要确保识别出我们需要在这些系统上监控的所有不同应用程序或服务。

我们的平台使用基于级联模板的配置系统，这使得这变得更加容易。使用级联模板，我们可以将多个模板适当地应用于设备或应用程序。

我们的自动发现方法采用三个并行路径，因此不会遗漏任何东西。当然，我们有可配置的子网扫描，因此我们可以在配置新系统时快速识别它们。这是大多数工具使用的传统方法。

但是，我们还希望利用其他发现方法来提供更快或更详细的信息，因此我们实现了与多个供应商平台的 API 连接，以便能够在您将新的 Meraki 边缘路由器上线时找到它们，或者快速开始监控新的AWS 实例或新虚拟机。

我们还提供用于系统配置的开放入站 API，因此如果您使用 Puppet、Ansible 等部署自动化工具，甚至只是 python 脚本，您可以将监控链接到该过程。

通过同时使用这三种方法，我们可以确保没有遗漏任何东西，即使事情正在迅速或动态地变化，即使有人没有按照他们应有的方式准确地遵循部署过程清单。

为了让这个进入下一阶段，我们真的需要获取发现的设备数据并确保它得到完全配置。如果检测到新系统并将其添加到监控中，这很有用，但如果我们没有同时监视关键应用程序和服务，或者如果我们没有在出现问题时自动向正确的团队发送通知，那么它就无法获得完全的可见性工作不正常。

我们解决这个问题的方法是使用我们称为“自动配置”的功能。自动配置附带一组规则来帮助您入门，并且可以轻松自定义或创建它们以适应您的环境。您可以使用它们来设置设备属性，例如基于任何设备标准的类别、站点和业务工作流——包括诸如正在运行的进程、打开的端口、设备的名称，甚至是 SNMP 值。这可以确保没有手动配置过程来确保设备最终出现在正确的报告中，并且它们始终应用正确的设置。

这些会在设备被发现时自动应用到设备，无论使用什么方法添加它们或它们在什么平台上运行，也可以自动重新应用，或者根据需要重新应用，所以如果你想确保一切都按照您想要的方式进行配置，您可以强制执行。

但是为了关闭自动化循环，一旦应用了属性，我们的平台就会动态地将所有相关模板应用到您的设备上。这可确保在无需手动干预的情况下应用您需要应用于新设备的所有设置。

因此，例如，一个新的 SQL 服务器上线不仅会获得您想要的基本 Windows 服务器设置，还会获得特定于 SQL 的应用程序检查和设置，并且只要它出现问题，SQL 团队就会收到警报. 我们还可以预先定义要查找和报告的事件日志，并设置我们想要观察的性能指标。

您可以使用模板来定义身份验证、升级、日志记录警报、配置规则、主动响应自动化操作等。它的设计足够灵活，可以满足全球企业客户的需求，同时对于小型 IT 部门来说仍然足够简单，无需大量培训或专职人员即可使用。

关键 #2：自动化您的响应

既然我们已经自动化了配置新监控的过程，那么自动化监控的下一个级别包括自动化您的响应。这允许您通过在设备上自动执行命令或向您的应用程序或云提供商发送 API 调用来在发生故障甚至异常时采取适当的措施。

您可以链接 SSH 或 powershell 等 CLI 命令，或使用 Web 挂钩等 API，以便您的监控系统可以重新启动端口、部署其他容器、重新测试应用程序，甚至转储实时诊断以响应事件。

有些人对自动执行命令感到不舒服，因此如果您愿意，我们的平台允许您通过操作员干预手动控制这些命令。这样，如果您想将“单击以重新启动服务器”功能直接添加到监控系统的 Web 界面中，并将访问权限限制为管理员，那么有一种简单的方法可以做到这一点。

一位客户甚至将系统设置为在下班后自动重启服务器，但只在工作时间通知 NOC，以便他们可以在有空时做出决定。

要记住的一个重要事项是，如果您要自动响应，维护窗口就变得非常重要。否则，计划的软件升级可能不会如您预期的那样进行，因为您的监控系统开始在后台采取行动。没有什么比暂停应用程序服务以进行部署并让服务器突然重新启动更令人沮丧的了。不过，我们让这一切变得简单——您可以通过 Web 界面、移动应用程序甚至 API 创建维护窗口，将其直接绑定到您的变更控制或故障单系统。

自动化事件响应的一个关键部分是使用我们所说的“事件管理”。这就是我们所指的过程，它允许平台了解复杂或高级的依赖关系，以达到零误报的目标。

这是一个基于规则的系统，可让您轻松覆盖配置的操作，以发送自定义警报、抑制冗余警报或自动执行特定响应。这方面的一个例子是一个客户，他有很多带宽有限的远程零售点。一旦他们检测到站点变得拥挤，他们就会安排电路升级，但这需要 30-45 天。因此，他们制定了一条规则，拦截该站点的任何带宽或延迟警报，并向分行经理发送消息，让他们知道他们知道问题，并且已经下令升级 - 并设法将这些呼叫减少到他们的 NOC 80%。

您可以基于分组配置依赖关系——例如，如果您在站点上看到带宽问题，您可以抑制同一位置的任何延迟警报。或者，如果您正在运行一个系统集群，您可以根据当时其他集群成员的状态采取不同的操作。

为了真正利用自动响应，我们要确保我们正在消除误报以及发现隐藏的问题。检测异常行为，而不是仅仅依靠静态警报设置，是实现这项工作的关键方法。

在我们的平台中，您可以使用我们的异常检测功能来发现应用程序行为的变化，它几乎可以应用于任何地方——CPU、内存使用、正在运行的进程，甚至是日志消息。例如，如果您的应用程序从每小时 10 次登录失败变为 1000 次，那么最后一次部署可能没有您预期的那么顺利，现在您可以开始进行故障排除了。

我们将使用我们保留的大量历史数据（通常默认为 100 天的高分辨率数据）自动生成基线行为模型，并且随着您的环境动态变化和演变，我们将自动调整基线。可以根据观察一天中的某个时间、一周中的某天甚至每小时的基线行为的变化来检测异常情况。

这使您可以发现意外影响，例如导致后端 SQL 服务器上 CPU 出现异常行为的软件更改。我们的一位客户发现了一个问题，通常在周三上午 10 点，数据库服务器运行在 50-60%，但突然以 15% 运行。事实证明，前一天晚上推送到 UI 的更改将测试 API 密钥放入应用程序而不是生产密钥，客户无法完成他们的订单。这种异常是一种不寻常的行为，永远不会触发基于静态阈值的警报，但在这种情况下，早在他们注意到可能导致的订单急剧下降之前就发现了一个问题。

关键#3：利用人工智能

即使在发现要监控的新事物的过程自动化，并自动化设置所有监控的过程之后，我们仍然需要定期检查环境中发生的事情，调整以减少误报，并优化我们的运动配置。因此，为了达到自动化成熟度的第四阶段，现在我们将利用人工智能和机器学习的力量来帮助我们保持环境的运行和监控。

第一阶段是我们称为 AI Autopilot 的自动管理工具，我们使用 AI 工具来评估我们的系统配置方式、我们使用的性能指标和阈值，并分析它们在我们的环境中的执行情况。本质上，人工智能正在为我们查看报告，因此它可以提出建议或更改。

AI Autopilot 系统可以自动识别常见的配置问题或集成问题，例如查找身份验证凭据已更改且监控系统未更新的系统，并找到正确的系统并自动应用它们——因此我们不会错过任何性能数据或警报。它还可以查看其他客户正在做什么并制定最佳实践建议，指出可能配置异常的事情或存在更优化的监控方式的地方，然后它可以提供建议，以便管理员可以应用它们单击一下，甚至自动部署更改。

由于这是完全自动化的，因此只需将其打开，并决定您是否希望它在进行更改之前请求批准。AI Autopilot 会检查所有不同系统元素的配置，然后查找它可以优化的东西、配置错误或未正确集成的东西，或者以与最佳实践相反的方式配置的东西，然后提供报告和建议，包括手动批准过程（如果需要），然后自动将批准的更改应用于平台内的各种配置。

这有效地减少了培训和管理负担，并确保该工具可以为您的环境保持最佳配置，而无需大量时间投资。建议和最佳实践会从云端不断更新，以确保当我们的客户找到新的、更有效的做事方式或行业标准发生变化时，您的平台可以持续保持最新状态。

人工智能开发的下一阶段包括无需询问即可生成自动报告的能力。因此，例如，如果系统检测到存在看起来像容量问题的模式，即使您没有安排自动运行的容量规划报告，它也可以生成并向您发送一份说明您可能会这样做的原因想看看那些特定的系统或电路。或者推荐您所在行业的其他人认为有用的报告，然后自动为您设置它们。

它还将包括优化的主动响应，当检测到新问题时，如果其他客户已成功自动解决该问题，系统可能会根据对具有类似环境的其他客户有效的操作向您推荐操作。

它还包括使用人工智能进行高级类型的根本原因分析和事件关联的能力，包括预测关联。例如，“85% 的客户在 1 天内 10 次看到这种类型的日志消息，在 24 小时内出现与高内存利用率相关的服务故障”，然后提供可能防止该问题的选项，例如安排服务重启或服务器重启。