对于 IT 管理员、工程师和架构师而言，语言模型能够节省时间、减少挫折感，并增强在故障排除、配置等众多任务中的信心。以下为其使操作更轻松的六种方式。
谈到生成性人工智能及一般人工智能时，我们需要明确，我们的目标应当是让人们的生活更美好，而非仅仅为了削减成本。在我看来，我们需要聚焦于这项技术——没错，我认为人工智能是一种赋能技术，而非一款产品——思考它如何助力那些工作压力巨大的人。比如系统管理员、站点可靠性工程师、企业架构师、网络管理员、数据库管理员等，有时他们被统称为运营人员。这些都是我所关注的人群，所以我会致力于解决他们的困扰。
生成性人工智能是一项成熟的技术。如今我们终于有机会（只是！）来审视它，开始了解它应当和不应当被使用的时机以及原因。对于像系统管理员这样的运营人员，生成性人工智能有可能节省时间与精力，并增强信心。以下是生成性人工智能和语言模型能够使系统管理员更具生产力和更精确的五种方式，同时也会探讨平衡使用生成性人工智能与人类干预的重要性。
执行日志分析
无论是系统管理员、网络管理员还是数据库管理员等运营人员，都需要持续审查系统日志，以在数百万的警报中识别出模式。随着时间推移，当出现 40,000 种警报、30,000 种另一种警报和 5,000 种警报时，如果异常警报引发了严重警报，人们便能察觉到这些操作。（实际上，那些零星出现的警报往往会带来真正的麻烦。）虽然有一些产品能够辅助进行这种分析，但最终做决策的还是人类，而人类应当继续发挥这一作用。
生成性人工智能并不会改变人类干预的需求，但它能够帮助人类更高效、更自信地分析警报。毕竟，系统、网络和数据库管理员在研究警报时都在做什么？他们通过研究来训练自己——通常是借助谷歌搜索。他们查找警报的定义，然后必须结合特定的基础设施或环境来综合理解警报的含义。这听起来是不是很像训练语言模型？没错！
判断日志条目是好、坏还是无关紧要，一直以来都是一种艺术形式。例如，在凌晨 2 点停电后恢复服务时，人类永远无法拥有 100%的置信区间。我们大概“认为”服务又启动了，我们检查日志，匆匆看上一眼，并宣布它“恢复到正常状态”，这意味着并非完美无缺，只是再次能够工作了。在某个时刻，我们才能回去休息！
在分析“错误消息”的日志时也是如此。人工编写的英文错误消息，由人工管理员在某处的日志中进行分析。双方之间的沟通最多只能说是不完美的。这种不完美的沟通可能会导致误报，从而减慢管理员的工作速度。管理员无法确定，语言模型也无法确定，但语言模型能够增加人类对可疑警报做出正确判断的机会。这对于人类来说是一种潜在的辅助能力，希望无论是在工作时间还是在凌晨 2 点停电期间，都能让他们的生活更轻松。
生成配置文件
如果有人喜欢从头开始生成配置文件，请举手。有人吗？有人吗？格式的复杂性、复杂的语法、软件版本间的语法差异、特定于环境的要求、验证、安全问题、集成问题……挑战数不胜数。仅仅一个服务器特性（如 Bind、Apache、Nginx、Redis 等）在生产环境中要实现所有需要做的事情，总共可能需要 5 个、10 个甚至 20 个不同的配置文件。管理员必须确保网络接口、DNS、NTP、Web 服务器等都配置得完美无缺。
出于上述种种原因，使用语言模型生成配置文件非常出色——能够节省大量时间，或许能将数百个人工工作小时减少到仅仅几个小时。然而，完全依靠生成性人工智能来生成配置文件是不可行的。人类必须审查和验证文件，以确保它们符合特定组织的因素，例如，或者遵守行业标准和监管要求。人类还需要确保配置文件有详细的记录，以避免未来转换时出现问题。（请参阅下面的“翻译配置文件”。）
我们知道这即将成为现实，因为如果您查看 GitHub Copilot 或 Ansible Lightspeed，语言模型已经能够生成诸如 Python、Ruby、Node.js 等正式语言的语法。在未来的几个月和几年里，将其扩展到更有限的语法（如配置文件）应该会轻松取得成功。更妙的是，Ansible Lightspeed 甚至还引用了它的工作成果，展示了它训练的源代码，这是我认为我们对于任何语法生成代码都应当要求的功能。
翻译配置文件
如果生成配置文件令人感到拖沓，那么翻译它们可能会更糟糕。假设您正在升级服务器或软件，配置文件的格式稍有变化。您需要将现有的配置文件转换为新的格式，以确保服务（如 Apache、Redis、Nginx 等）能够正常启动和运行。您必须保持配置文件的功能完整性——该文件可能是由某人在几年前按照自己的方式编写的——同时准确翻译需要更改的内容。
在我担任系统管理员的日子里，我花费了大量（非常多！）令人沮丧的时间，费力地处理配置文件：Sendmail、Bind、Apache 重定向等等，有人有同感吗？（人们不禁会想，为什么“确保您的应用程序已更新”并非是最容易遵循的安全最佳实践。）语言模型能如何提供帮助？同样，我们所追求的是更多的信心，而非 100%的确定性，但机器学习模型能够轻松地告知您哪些配置选项已被弃用，哪些新选项已经就位。就最终的可行性而言，系统管理员必须是最终的决策者，但机器学习模型能够在整个过程中提供支持。
此外，我要向您分享我从使用大型语言模型中总结出的最佳实践：在您正在创建或翻译的工件中保存提示文本。对于我为演示文稿生成的图像，我将“提示文本”放在演讲者注释中，但对于配置文件，我会将其作为注释保存在文件中。这将有助于未来的管理员了解您的想法和试图实现的目标，即便未来的系统管理员就是您自己。来吧，六个月后，当您看到自己的代码时，可能会咒骂自己，责怪是谁写的，结果通过“git blame”发现那个人就是您自己。
提供“同行”视角
最好的建议往往来自有过类似经历的人，但您特定环境中的每次软件升级都如同涉足未知领域。关于贵公司使用的标准操作环境（SOE），总是存在一些细微差别和细节，或者更糟糕的是，对该 SOE 进行一次性更改，以确保工作负载正常运行（例如，禁用 SELinux）。
当然，您可以在 Reddit、LinkedIn 等管理员聚集的地方寻找答案。您也可以尝试在供应商提供的（因而超级积极的）用例之间进行筛选。这里有一个公开的秘密：尽管供应商尽了最大努力，但他们永远无法测试您在特定环境中所拥有的软件和配置的确切组合。
至少可以说，为您的特定环境综合所需了解的所有信息是极具挑战性的。这正是语言模型能够发挥作用的地方。在不泄露自己公司数据的前提下，您可以使用 ChatGPT、Bard、Perplexity，甚至 Granite 或 Mistral 等本地模型，询问公司在从特定公共云迁移到使用特定硬件供应商的混合模型时，或者从一个软件平台版本升级到另一个版本时，有哪些经验教训。
人工智能生成的这类“故事”可能非常强大，因为大型语言模型实际上非常擅长从 Reddit、Stack Overflow、博客等中抓取信息，并创建叙述和揭示主题，为您节省数小时的研究时间。我成功地使用 LLM 来发现常见的问题和最佳实践，获得了大量值得思考的内容。也就是说，您应当验证所得到的叙述性回答。要信任，但一定要验证。以这种谨慎的方式使用 LLM 让我在做出艰难的架构决策时充满信心。
为命令行提供动力
我开始看到语言模型被集成到 shell 和 CLI 中的例子。这些是使用 LLM 的理想场景，因为 shell 命令已经有机地发展了 30 或 40 多年。命令本身具有难以理解的简洁语法，手册页通常帮助不大。通常，这些命令和手册页是由一个人编写的，目的是提醒自己如何使用他们编写的命令，并非我们所有人都是出色的用户体验专家。如果我们的目标是吸引更多人，并为更广泛的受众启用 Linux，那么启用 LLM 的 shells 是让人们感到更舒适的绝佳方式。
启用 LLM 的外壳简化了新用户的过渡，并对长期用户有所帮助。我已经数不清有多少次忘记了一段时间未使用的操作的确切语法，特别是当它需要复杂的命令选项时。启用 LLM 的 shell 允许用户使用自然语言与计算机进行交互来解决这个问题。例如，用户可以询问“目录中的哪些文件是这个目录中最古老的？”或“查找所有大于 237MB 的文件”或“从此目录中所有文件的名称中删除数字”。使用 awk、sed 和 bash 构建这类命令可能非常复杂，使用那些我们大多数人早已遗忘的神秘语法。
虽然曾经展示自己的 awk 技能是一种“灵活性”，但如今的云运营商和管理员必须支持如此众多的技术，以至于他们永远无法成为任何一项技术的深度专家。利用启用 LLM 的外壳、插件和包装器可能会成为支持越来越多技术的关键。
为供应商软件赋能
除了 ChatGPT 等公开可用的工具以及使用内部语言模型外，技术提供商已经开始在其产品中构建生成性人工智能能力，并将随着时间的推移继续这样做。AIOps 和 MLOps 的定义似乎已经迅速演变为与基础设施相关的“LLM 支持的一切”。
话虽如此，我确实看到了一些有趣的用例。人们可以很容易地想象，启用 LLM 的工具将能够帮助您为操作系统、企业数据库、CRM 软件和其他大型系统等复杂软件生成标准操作环境（SOE）。
部署大型企业工作负载通常需要阅读大量的文档，以获取需求和最佳实践。然后，几位架构师（企业、存储、网络和数据库）必须共同努力，将他们从文档中获得的知识与特定的安全标准、合规性规则、网络配置、存储配置和架构标准相结合。
这绝非易事……
我看到了一个未来，您不再需要阅读 SAP、Oracle NetSuite、Microsoft SQL Server 或 Red Hat Enterprise Linux 的参考架构和大量文档，并综合如何自己组装这些部件，而是使用这些公司之一提供的启用 LLM 的工具来生成必要的配置，以根据您的安全标准、合规性要求以及网络和存储需求在组织内运行工作负载。虽然我认为这在未来还需要几个月或几年的时间，但我认为这是您应当关注的一个方向。
管理员和架构师的语言模型
无论系统管理员如何使用语言模型和生成性人工智能，考虑准确性、性能、资源管理和数据隐私等众多因素都至关重要。而且，随着越来越多地转向更小、更专门构建的语言模型，系统管理员应当思考如何将多个模型一起使用。此外，这些模型将需要与应用程序经历相同的生命周期工作：升级、测试、更换等。
对于管理员和架构师来说，LLM 是一项令人兴奋的技术，因为它们能够很好地处理自然语言。他们致力于讲述故事，无论我们是否意识到，故事在我们的工作中无处不在。程序员嵌入其应用程序中并随后转储到日志文件中的所有错误消息，基本上都是这些开发人员向管理员讲述的故事。它们不受任何规则的约束，也并不总是准确的。它们需要解释和综合才能真正被理解。日志文件也是如此，文档、参考架构等也是如此。这些信息来源都无法提供 100%准确的信息。
但也许在我这里提出的建议以及未来出现的任何新用例中，最重要的共同点是，运营人员——以及其他人——不应当只是将他们的权力和责任交给生成性人工智能和大型语言模型。这并非因为您不希望人工智能接管您的工作，而是因为人工智能无法接管您的工作。相反，基础设施和运营专家应当寻找能够利用人工智能的方法，以帮助他们更出色地完成工作。
