DevOps 是一个很火的概念，在过去的几年中很多企业一头扎进了 DevOps 相关的实践中，准备转型。但是，成功的却是少数。
一般来说，我们在加入 DevOps 大军之前，应该问问自己：我们为什么要使用 DevOps?无疑，多数企业都是为了降本增效、提高竞争力。然而，如果我们把目光仅仅锁定在 IT 团队本身，很可能就本末倒置了。
从大的范围上来讲，DevOps 转型应该是超越开发和运营两种职能的存在，它必须与企业的其他部门发生联系。一些非技术部门是 DevOps 团队的重要参与者，他们所站的不同立场完全可以起到平衡作用，避免技术部门陷入 “唯技术陷阱”。
这一点对一些面临数字化转型的传统企业尤为重要。因为在传统企业内部，业务部门才是主体，而 IT 部门是为了业务部门赋能的。除此之外，在 DevOps 实践中，一些法律和财务的风险也是需要提前规避的。
一、这些非技术部门为什么要参与 DevOps?
让非技术团队参与到 DevOps 中来，这并不是说要组织中的每个员工都需要了解 DevOps 和软件需求的来龙去脉。
相反，一些部门的参与却是 DevOps 的刚需，核心 DevOps 团队和非技术角色的同事之间建立战略联系绝对是一件物超所值的事。
1、业务团队让 DevOps 更瞄准 “靶心”
业务团队的重要性不言而喻。一些观点认为，在 DevOps 文化中就不再应该出现业务与技术不同步的事情，销售组织可以将客户的反馈和要求传达到开发周期中，更快地让下一版本就包含客户所需要的功能。
但实际上，人们对此的认识要比 DevOps 更滞后一些。2020 年，一群关心这个话题的人发布了 “BizOps 宣言”。该宣言倡导从根本上改变 IT 团队和业务用户在软件开发过程中的协作方式。
具体来看，BizOps 要求：1)业务成果高于单个项目和执行度量;2)信任和合作高于个人主义和层级制度;3)数据驱动的决策高于意见、判断和说服;4)学习和转变高于遵守严格的计划。
https://www.bizopsmanifesto.org/
再然后，BizDevOps 这个概念应运而生，它被称为 DevOps 2.0。在这种方法中，业务团队不仅设定要求，他们还直接与开发人员合作，为敏捷软件开发冲刺和积压的工作设定优先级。他们成为业务方的合作伙伴，与管理人员一起解决问题，实现业务目标。
2、法律团队为 DevOps 保驾护航
“软件吞噬世界，开源吞噬软件。” 这句名言一语成谶。当下，开源软件无处不在，一些统计结果显示，90% 的现代应用程序中包含了开源代码，软件已经被开源组件所占领，企业既绕不开也躲不掉。而且，开源软件还能为组织带来降低成本、提高代码质量等诸多好处，绝大多数企业也愿意投身其中。
但这也带来了合规性问题，因为意识不足等问题，许多开发人员在不了解开源软件许可证相关规定的情况下，违规使用开源软件，就会带来麻烦。面对类似 MIT、Apache 等宽松许可证或许还好，但一些强传染性的许可证则需要特别注意。
其实，不仅是开源合规性，软件行业还有很多专利以及流程问题，都会引发合规和法律问题，如果不重视，很可能就会变成被告。
因此，法律团队在 DevOps 中的重要作用是：确保软件即使在持续发布时仍然合规。更多时候，法务更像是 DevOps 项目的编外人员，平时似乎用不上，但关键时刻又少不了。
3、财务部门强调价值，为利润工作
在 DevOps 转型期间，难免需要资金和人力的持续投入。但究其根本，很多 DevOps 团队的建立是一个 “商业行为”，目的也是商业目的，大家都是为利润工作的。如果抛开这个不谈，多少有点耍流氓的意思。
前文我们提到业务部门与 DevOps 结合，叫做 “BizOps”，也就是 Business + DevOps;而财务与 DevOps 的结合也有个概念，叫做 “FinOps”，是 “Finance” 和 “DevOps” 的结合体，通过帮助工程、财务、技术和业务团队在数据驱动的支出决策上进行协作，使组织能够获得最大的业务价值。
如今，FinOps 是很多企业数字化转型中不可或缺的一项。这需要 DevOps 尽早与财务部门合作，将财务控制和监控纳入 DevOps 的规划阶段。
二、这些不写代码的人，如何参与 DevOps?
无论是业务、法律还是财务团队，我们实际上很难找出既懂代码又懂法律或者是财务的跨行业人才，一味去追求这样的跨界人才也是不现实的。这会加大我们在人才招聘和培养上的投入。
那么，我们还有什么好办法去让这些不懂代码的人，发挥自身专业长处加入进 DevOps 呢?
首先，文档永远是降低沟通门槛的利器。
在 DevOps 的理念中，技术文档的协作应该是被纳入到整个 DevOps 生命周期之中的，文档写作者必须适应 DevOps 的节奏和方式。目前，已经有不少开源项目提供了 API 文档，这一类型的文档同样在各大规模企业的 DevOps 团队中使用，让文档写作能够跟随上 DevOps 的脚步。
而且，文档在 DevOps 的转换过程中也发挥着至关重要的作用，这些文档可以记录下一些 DevOps 中实现效率和收益的最佳实践。这些东西几乎是无法口耳相传的，必须通过文档留存下来。与此同时，如果组织内存在多个 DevOps 团队，文档也会起到统一作用，它可以将最佳实践标准化起来，最终形成基准测试的指标。
要想与其他非技术部门(特别是业务部门)进行基本的协同，文档透明性必须加大，向他们开放文档访问。此外，还可以通过演示、或者是测试版本试用等方法，加大非技术团队的参与度。
其次，流程上一定要为非技术部门留下特定的 “沟通接口”。
在整个 DevOps 流程的顶层设计时，就应该考虑进法律、财务等非技术部门的 “进场时间”。但在实际操作中，又存在很多突发情况和特殊情况，尤其在 DevOps 的特性中，及时性尤其重要。因此，几乎每个大小节点都应该留下 “沟通窗口”。
这些 “沟通窗口” 可以是同步工具，也可以是定期会议，还可以是特定的对接人员。具体来说，非技术部门的及时介入是风险防范的有效措施，这需要各方都有足够的协作意识，及时处理，避免出现 “亡羊补牢” 的情况。
最后，利用市面上的先进自动化工具，也是非技术部门切入的好办法。
DevOps 自动化能够减少人工辅助，简化工作交互，从而将迭代更新更快地部署到生产应用中。
自动化是 DevOps 的重中之重。对于一些非技术部门，特别是业务部门，是需要了解自动化是如何改变软件交付方式的。一些专家还会建议，从持续集成 / 持续开发 (CI/CD) 工具链中去生成自动化数据报告，是让营销部门收益的良策。
目前，市面上已经出现了不少自动化工具来帮助 DevOps 团队解决问题。其中采取全栈式开发的自动化平台 SoFlu 软件机器人就是其中的佼佼者。
具体来说，SoFlu 软件机器人是利用 “可视化开发” 来改变传统编写代码的开发方法。通过拖拽方式以及参数配置实现等同于编写复杂代码的业务逻辑，业务逻辑可视化展示，极大地降低开发门槛，让非技术部门更加流畅地参与到 DevOps 中。
正如 SoFlu 软件机器人在 5 年协助 5 家企业突破百亿营收的君智咨询数智化转型项目的应用中，君智咨询 CTO 韩之斐的感受，“君智用 SoFlu 软件机器人开发系统，很多时候前一阶段做需求分析的小伙伴在下一个开发阶段就成了程序员，而且开发出来的功能更准确，质量也很高。有了 SoFlu 软件机器人，可以让不懂开发但了解业务的业务分析师们学会使用 SoFlu 软件机器人并完成基于他们设想的开发工作。”
总体上，SoFlu 软件机器人有两大价值。一个是，它可以降低软件开发的准入门槛;另一个则是让技术的事情变简单，对人的依赖性更小，从而降低人力成本和沟通成本。
（免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。 ）
