如果我们是墙上那只比喻性的苍蝇，在软件工程师和 DevOps 工程师之间进行一次非常常见的 Slack 对话之后，它可能会是这样的：

软件工程师： 这会花很长时间。“我的应用程序需要一个新环境。”

两个小时后…..

DevOps： 为什么软件工程师认为我有心灵感应！？“好的，您需要什么实例类型？” 

一小时后（在与团队协商后……）

软件工程师： “我需要一个 g3.8xlarge 来测试我们最新的可视化功能。”

明天…。

DevOps： “太棒了，你需要它在哪个可用区？另外，它应该与哪个安全组相关联？”

软件工程师： 难道他们不知道所有这些操作性的东西，比如自动操作！“us-west-1 中的任何 AZ，它是 sg-3164z279。”

48 小时后，在对一些额外的参数、权限和其他可爱的细节进行了一些反复的讨论之后，DevOps获得了启动环境的绿灯，走出去买了一些甘草作为对他们所有痛苦的奖励，并忘记通知直到当天起飞前 5 分钟，软件工程师才知道请求已获批准。

听起来有点熟？如果是这样，可能会在您的软件工程和 DevOps 部门的核心深处进行一场效率极低的冷战。 

核心

核心是什么？为了理解这一点，让我们分析一下从这个不太顺利但非常熟悉的场景中出现的两个主要问题。第一，没有共同语言，没有畅通的沟通渠道，简单的事情都不可能两方合作，更别提复杂的事情了。其次，即使使用共同的语言，所有多余的工作、上下文切换、延迟和不可避免的摩擦都会导致您的组织内酝酿着冷战级别的挫败感。

除了这些问题之外，DevOps 模型还为软件工程和 DevOps（也称为运维）团队创建了模糊的责任界限。但现实是：

• 软件工程师希望编写代码、实现功能并在基础架构上运行它们（以便客户可以使用它们），而不会遇到很多麻烦，也不会陷入操作细节的泥潭。

• DevOps 希望专注于简化和保持生产稳定、优化基础架构、改进监控和一般创新，而不会陷入最终用户（例如，软件工程师）的服务和访问请求的困境。 

当双方在运营瓶颈上花费多个周期时——在互相投掷无形的仇恨匕首之间——组织会失去软件开发生产力以及 DevOps 方面的潜在创新，因为没有人得到他们想要的东西。

这种巨大的生产力损失不能仅通过 DORA 指标来衡量。它深入人心，直达您组织文化的核心。但现在，软件工程师与 DevOps 之间长达数十年的冷战终于结束了。

DevOps 和平奖获得者的演变 

没有人认为我们在这里看到的情况——软件工程师和 DevOps 之间的根本脱节——是好的。浪费这种程度的时间和精力，任何企业都无法有效地开展工作。这就是为什么几年前，内部人士开始宣布自助服务 DevOps 的曙光。

当您想到自助服务 DevOps 时，它可能会让人想起小机器人来配置您的开发人员可能需要的所有基础设施。如果那是真的就好了。

目前，自助服务 DevOps仍处于青春期阶段，拥有繁琐的内部开发人员门户、服务目录、工作流自动化工具和其他闪闪发光的玩具。

但由于已经在进行中的进化过程，这个空间正在迅速成熟。

昨天：它始于聊天机器人

模拟对话一直追溯到计算的黎明。现代聊天机器人肯定更聪明，但仍然未能兑现他们最初的承诺，即聊天机器人会理解任何请求，轻松与 DevOps 工具集成，并自动化工作流程。

实际上，聊天机器人有些用处，但面临许多基本问题。从本质上讲，它们依赖于简单的、预先确定的流程和基于规则的固定线性交互。但我们都知道，在现实世界中，问题和请求可能是多种多样且独特的……本质上，这不是聊天机器人能够处理的。

另外，让我们面对现实吧——一个不做这项工作的聊天机器人比什么都不做更糟糕：软件工程师试图猜测将使聊天机器人执行任务的神奇命令，如果失败（可能），他们无论如何都必须跑去 DevOps 团队——除了现在是 24、48 或 72 小时后，他们就像 [填空] 一样沮丧。

要创建一个真正能在工程和运营方面节省时间的界面，您需要比简单的聊天机器人所能提供的更多的智能。

今天和明天：对话式 AI 将继续

聊天机器人是有限的，因为它们不理解我们（人类）开发人员使用的语言。但是，如果您可以使用 AI 来推动更复杂的理解呢？要达到这种理解水平，您需要两种截然不同的策略：

• 自然语言处理 (NLP) 使用 AI 系统地解析您的单词，并通过大多数 AI 解决方案所需的大量训练来尝试确定含义。

• 然后，自然语言理解 (NLU) 更进一步，学习识别反映人们在现实世界中不精确交流方式的语言变化，包括考虑情感、语义、上下文和意图等因素。

从本质上讲，NLP侧重于构建识别和理解自然语言的算法，而 NLU 侧重于句子的含义。把这些放在一起，你最终会得到真正的对话式人工智能。

NLP 和 NLU 只是进入对话式 AI 以提供最终将取代聊天机器人的真正理解和智能的众多基本构建块之一。让我们看看其中的一些构建块：

• 自然语言处理引擎（使用 NLP/NLU）来评估用户输入并理解所请求的内容

• 与 Okta 等身份提供者 (IDP) 和知识库或云提供商等其他来源集成，以严格控制权限和安全性

• 迭代机器学习以识别新数据集并测试用户行为预测以推动响应的持续改进

• 对话管理系统保留对话上下文并允许对话式 AI 做出相应响应

• 上下文管理或“保持状态”，以准确跟踪对话停止的位置和到达的最后一步 

• 与用户交互的界面，通常通过文本或语音，最好是通过他们最喜欢的工作流工具

作为上下文管理的示例，在上面虚构的开发人员/DevOps 对话中，即使中断 24 小时或更长时间后，AI 也需要记住到达的阶段，以便在获得授权后继续进行

此外，最后一点——用户界面——至关重要。要实现真正简化 DevOps 的真正对话智能，您需要一个与您的团队已经工作的方式相匹配的界面。这样，您就不会因上下文切换而增加额外的压力，而上下文切换本身会极大地消耗生产力和注意力。 

和平奖获得者是……您的 DevOps 虚拟助手 

还记得我之前提到的 Dev 和 DevOps 之间的脱节吗？好吧，虚拟助手可以弥合差距，为双方提供他们想要和需要的东西。开发人员希望编写代码，轻松获得所需的基础设施。DevOps 工程师需要安全性和效率，以避免过度许可和过多的云成本；他们也不想将时间浪费在重复的、乏味的、需要大量上下文切换的任务上。

有了虚拟助手，交互可能会这样进行：

• 软件工程师使用他们喜欢的工作环境：Slack、Microsoft Teams 等。

• 他们以简单的英语提供所有详细信息。

• 虚拟助理然后执行他们的请求。例如：

• 提供新的云资源

• 触发复杂的工作流程

• 提供一些很难找到的数据

• 最后，虚拟助手会在软件工程师选择的工作环境中提供确认，以便他们可以立即开始工作。

借助对话式 AI，双方都能保持专注和高效。软件工程师可以专注于开发，DevOps 不必将时间浪费在上下文切换或无休止的重复请求上。

本文由本站原创或投稿者首发,转载请注明来源！

本文链接：http://www.ziti66.com/net/html/182.html