每当我提到自己的角色时，我都会进行一次典型的对话。

让我首先回答我在“ 开发运维中的业务分析师”任期内所提出的几个问题。

开发运维在交付中的作用是什么？

开发运维只是一个流行词。由于正确的原因，该术语在技术上引起了很多关注。

开发运维弥补了在SDLC中处于孤岛工作的团队之间的鸿沟。持续集成和持续交付增强了敏捷交付模型。这使得交付可以连续地以较小的块发送代码。它加快了将代码交付生产的速度。

我在DevOps中使用过的一些示例：

• 作为交付的一部分，体系结构更改/升级（例如：升级不支持的SMTP服务器）
• 实施有助于交付的新工具（例如：监控工具，如Splunk，appdynamics，jenkins的使用）
• 支持非产品环境
• 设计部署管道
• 在管道中集成早期测试
• 提供强大的功能

而且最重要的是在交付和运营过程中培养DevOps的心态！

是的，工具对于实现最终目标很重要，但是如果没有固有的文化转变，我们就无法取得进步。

谁是DevOps BA的利益相关者？业务分析师需要考虑什么？

高级管理人员，交付团队，测试团队，运营和您自己：它们都是您的利益相关者。改善应用程序的开发，交付，测试或操作的想法或要求可以来自任何人。

业务分析师的基本核心角色不会随项目或需求类型而改变。 开发运维中的业务分析师也是如此。以下示例将说明BA必须在需要DevOps工具和思维方式的情况下进行工作的项目。

a）一键式部署： 这项要求来自我们必须作为团队进行的大量手动部署。这意味着要不断监控，并让某人手动从一个步骤转到另一个步骤。像任何其他过程一样，手动干预越少，人为失误的机会就越少。

利益相关者：

• 运营团队（实际部署团队）
• 开发运维团队（创建一键式管道0
• 交付团队（提供意见）
• 高级管理人员

作为业务分析师要考虑的事项：

• 了解运营团队当前面临的问题。
• 涟漪效应以及由此产生的发行问题。
• 优势交付团队将继续前进。
• 如何构建它以添加自动化测试和蓝/绿部署作为迭代方法？
• 需要提供哪些工具

b）迁移到 云: 随着基础架构向云迁移的广泛普及，这是许多组织中的普遍项目。没错！迁移可以是仅使用云中的API或队列端点进行的小型迁移和转移，也可以是大规模迁移。

利益相关者：

• 管理（指令和时间表来自他们）
• 解决方案架构师（解决方案和设计将来自该小组）
• 项目经理
• 表演团队
• 功能测试
• 安全团队
• 数据库管理员
• 开发运维
• 交货
• 运作方式
• 第三方供应商（如果有）

作为业务分析师要考虑的事项：

• 与解决方案设计师和业务人员合作，以了解用例
• 开始创建史诗来管理范围并确定优先级
• 与交付团队一起将高级设计或史诗分解为较小的工作
• 将安全性和非功能性需求纳入交付的用例中
• 制定数据迁移策略
• 与测试团队合作创建功能和回归测试计划
• 吸引相关利益相关者制定运营准备，灾难恢复策略和最终过渡策略

c）业务需求（功能/功能驱动的工作）：交付业务功能需求。这项工作与上述工作一样涉及DevOps思维方式。在交付功能时，我们需要考虑非产品环境所需的BAU支持，涉及代码部署的工作，交付非功能性要求。用“我不在孤岛上工作”的心态完成的所有工作使DevOps与其他任何工作一样多。

这是业务分析师需要考虑的事情的快照。这不是一个详尽的清单。

BA必须具备哪些技能才能成为DevOps的一部分？

业务分析师需要使用其工具包中的所有工具以及过去获得的经验来导航DevOps世界。但是，最重要的是持续交付，集成，连续部署的心态，以及对非功能性需求的敏锐理解和重要性。

无论是在名为“ 开发运维”的团队中还是在功能交付团队中，这种心态都将确保我们将“可靠性”，“性能”，“安全性”和“稳定性”视为功能，而不是“好用”。 

然后，BA的职责就是像往常一样帮助提供世界一流的平台。

成为业务分析师的核心是不会改变天气，我们使用传统的瀑布方法，敏捷框架或敏捷DevOps框架工作。实际上，我们使用的任何框架都需要DevOps思维方式。它实质上是将NFR视为一项功能，并不断协作并根据功能性业务需求不断交付它们。

我希望这有助于解答DevOps难题中的业务分析师。