DevOps只是一個開始。現在，組織在IT內部和外部都採用了其他形式的Ops。但他們有沒有抓住重點呢?
BizOps、MarketingOps、DevOps、AIOps、MLOps、DataOps。顧名思義，它們都是跨職能的，但公司是需要全部、部分、還是完全不需要呢?這取決於個人的觀點。顯然，組織根據其行業、規模、年齡、文化、技術採用和預算處於不同的成熟階段。各組織越來越需要不同種類的Ops所提供的價值。
與DevOps一樣，各種類型的運維都致力於加速流程和提高交付內容的質量:軟件(DevOps)、數據(DataOps)、人工智能模型(MLOps)、以及分析洞察(AIOps)。有些人認爲不同的Ops類型很重要，因爲每種類型所需的專業知識都不同。
另一些人則認爲這只是炒作，特別是重新定義已經存在的內容，或者不同團隊所創造的碎片化可能會產生額外的組織機構，阻礙更快的價值交付。
XOps始於DevOps
敏捷軟件開發實踐在商業領域已經興起一段時間了。自千禧年伊始，商業領袖們就一直躍躍欲試，因爲他們的公司需要更加靈活，才能保持競爭力。
與此同時，許多敏捷軟件開發團隊已經採用了DevOps，並且越來越多地公司採用了持續集成/持續交付(CI/CD)，這使額外的任務自動化，從而實現了端到端流水線，從而提供了貫穿整個流程的可視化，這比傳統的瀑布式傳遞更順暢。與DevOps、DataOps、MLOps和AIOps一樣，它們都是專注於持續、效率和流程的改進。
XOps藍圖
Ops領域繼續擴大，但本文主要關注DataOps、MLOps和AIOps。
DataOps是一種面向流程的方法，它使用自動化來提高數據相關任務的速度，並最終提高了數據洞察的質量。據DataOps平臺StreamSets的首席技術官Arvind Prabhakar介紹，DataOps爲擁有複雜數據基礎設施的公司提供了靈活的變更管理。
數據供應鏈中的人數已經達到了頂峯，所以現在的現代企業正在努力跟上。就數據基礎設施而言，它比10年前複雜了一個數量級。
與DevOps一樣，DataOps涉及快速迭代、度量和監視，以促進端到端溝通。這裏的關鍵角色是數據工程師。而且，在擁有這些數據的公司中，首席數據官(CDO)希望推動流程優化，以確保數據治理的可靠性。
MLOps爲機器學習模型的創建、部署和生產操作搭建了橋樑。DataOps和mlop被認爲比AIOps更密切，因爲與其他兩個相比，AIOps是一個更高的級別的應用程序。
管理和技術諮詢公司博思艾倫漢密爾頓(Booz Allen Hamilton)通過研究DevOps概念，並詢問如何將它們應用於MLOps，開始了其MLOps之旅。
Booz Allen高級副總裁兼公司分析業務負責人JohnLarson說：你必須召集技術專家、數據架構師、建模師（和）安全專家。在建模框架中，考慮構建一些需要容器化的東西以便可以擴展和部署是不直觀的服務。建模的第一個原則往往是 我的目的是什麼？
Booz Allen使用MLOps實時瞭解模型性能和發展趨勢，以及模型是否按預期部署。
我們強調的是數據版本、模型版本和部署的重要性，在DevOps框架中，MLOps與DataOps和DevSecOps的集成使您能夠擁有這些類型的洞察。我認爲擴展我們正在做的事情和採用我們正在做的事情是很重要的，因爲它將爲我們提供機制、工具、可追溯性，以瞭解模型在部署時發生了什麼，它是如何發展的，它是如何刷新的。
Gartner對AIOps的定義是，它將大數據和機器學習結合起來，實現IT操作流程的自動化，包括事件關聯、異常檢測和因果判斷。
AIOps的主要好處是可操作的洞察力。事實上，AIOps特別有利於數據分析。
另一方面，XOps只是炒作嗎?
Forrester首席分析師查爾斯•貝茲建議不要陷入XOps的炒作。
在某種程度上，人們通常會發出嗡嗡聲，把想法扔到牆上，看看什麼能堅持下去，所以我並不真的擔心BizOps、DevOps、DevSecOps、BizDevSecOps、Marketing Ops。它基本上都做同樣的事情，這是朝着一個更跨職能的工作方式運動，貝茨說。
不去追求各種形式的Ops的一個原因是，它與IT人員配備的趨勢相牴觸。傳統上，專業化被認爲是一件好事，但更現代的是，IT角色變得越來越廣泛(例如，全棧開發人員或站點可靠性工程師)。事實上，現代人力資源專業人士認爲，對於一個部門或團隊來說，擁有正確的技能組合比擁有正確的頭銜或角色組合更重要。
大公司告訴我他們有協調問題。貝茨說：同一周，我有兩位高級副總裁對我說，我沒有足夠的資源讓每個產品團隊都能得到一個dba，所以我們最終會遇到共享服務的問題。我們需要專業知識，所以我們怎樣才能解決這個問題而不回到過去的糟糕日子呢？當我需要什麼東西的時候，需要六個月的時間才能讓任何人回到我身邊。這就是爲什麼人們想要跨職能的世界。
Betz還認爲Scrum和敏捷方法應該有正確的方向，默認的方向應該是產品團隊。
理想情況是產品團隊擁有完成工作所需的資源和批准。貝茨說：你沒有一個依賴交換和交易的運營模式，你有一個依賴合作的運營模式。所有這一切的基本點是，運營模式從高事務流程開銷轉向這些專注於流程和事務的團隊之間的純協作流程，事務摩擦則是例外，而不是規則。
雖然不同類型的行動需要不同類型的專家，但要小心不必要的複雜性和官僚主義。
有壓倒性的證據表明，當你過度專業化時，過程會出現僵局，Betz說。你有一羣中層管理人員，他們都試圖增加自己的王國，因爲你的工資與向你彙報的人數掛鉤。
最終，Betz認爲XOps的元素不過是一組用於內部營銷目的的術語。
我不反對，我不在乎它，我也沒有太多耐心，因爲更深層次的趨勢是，越來越多的合作產品團隊模型（其中）過程摩擦是一個例外，貝茨說，在許多情況下，最大的交易摩擦是在那些創造者和那些實際執行者之間，所以這就是爲什麼所有這些東西都是XOps。
總結
在今天的企業中，越來越多類型的類似DevOps的組織正在形成，供應商也在用DataOps之類的解決方案來應對。然而，從競爭的角度來看，擁有正確的能力比這些能力被稱爲什麼更重要。考慮到不同公司之間的組織獨特性，任何企業對XOps的考慮都將不同於其他公司，比如DevOps。
推薦
本文分享自微信公衆號 - 雲原生技術愛好者社區（programmer_java）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。