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 軟件機器人有兩大價值。一個是，它可以降低軟件開發的準入門檻；另一個則是讓技術的事情變簡單，對人的依賴性更小，從而降低人力成本和溝通成本。
