什么是生成式人工智能？它是通向 AIOps 的途径吗？

基础设施的挑战之一是配置交付和保护单个应用所需的大量设备、服务和系统。 如果排除“即服务”产品，组织平均依赖 23 种不同的应用服务。 

现在，我不需要告诉您配置 Web 应用程序和 API 保护服务与配置普通的旧负载平衡服务不同。 这意味着负责配置和操作应用服务的人员可能需要精通十几种不同的“语言”。 

多年来，该行业一直在努力解决这一问题。 当 API 成为配置一切的主要手段时，应用程序交付和安全服务也不例外。 每个人都从命令式 API 开始，它只是改变了发出命令的方式。 您无需在 CLI 上输入命令，而是通过 HTTP 发送 API 命令。 

很快，人们就发现依赖命令式 API 所产生的API 税太高了，因此行业转向了声明式 API。 但不幸的是，大多数行业认为声明式意味着“配置为 JSON”。 因此，我们不再使用声明背后的意图（这个词很重要，记住它），即“告诉我你想做什么，我会为你做”，而是最终得到“这是我想要的配置，去做艰苦的工作吧”。 

它并不完全相同，并且仍然需要对给定解决方案所特有的操作模型具有相同程度的专业知识。 我不确定业界是否就负载均衡器是否使用“池”或“场”达成一致，更不用说虚拟服务器如何与真实服务器和应用实例交互的更复杂的细节了。 因此，业界对声明所做的一切就是将命令级工作从操作员转移到系统上。

现在，生成式人工智能带来的是一种低代码/无代码的形式。 这些比某些结果更可靠，因为它们基于指导结果生成的完善的规范。 毕竟，编写“hello world”的方式是有限的，而回答一个问题的方式却有千万种。

这意味着我应该能够告诉训练有素的模型，“嘿，我想配置我的负载均衡器来扩展应用程序 A”，然后系统应该能够给出一个配置。 但更重要的是，我应该能够告诉它，“给我一个脚本，让我使用 Z 在系统 Y 上执行 X”，然后 BAM！ 它不仅应该生成配置，还应该生成将其部署到正确系统所需的自动化。 

哦，看。 它已经做到了。

但这是一件简单的事情。 我还应该能够告诉它，“哦，顺便说一下，部署它。” 当我正在享用早晨的咖啡时，这件事应该能完成。 也许还可以给我唱首小歌。 

且慢，还有更多！ 如果我稍后还可以告诉生成式人工智能系统，“嘿，绿湾的用户登录次数很多，但性能下降了，克隆应用程序 A 并将其移动到我们在密尔沃基的站点。” 

事实确实如此。 因为在本质上，所有这些都只是一个由 API、配置和命令组成的网络，如今它们可以而且通常通过脚本自动执行。 这些脚本通常是参数化的，这与我的 AI 提示中的参数大致相关： 绿湾、密尔沃基、App A。那么变化的是发电机，以及它发电的速度。 

我经常说人工智能和自动化是力量倍增器。 因为技术不知道它需要做什么，所以我们知道。 但是人工智能和自动化可以更快、更高效地完成这项工作，有效地提高生产力，增加价值实现时间，并释放专家的时间专注于战略决策和项目。 随着时间的推移，人工智能可以向我们学习，进一步增强我们的能力并揭示新的可能性。 

这不再是科幻小说，而是计算机科学现实。