我們以怎樣的方法論建設研發運營一體化平臺



本文目錄


  • 研發運營一體化平臺是未來IT建設的方向

  • 建設“研發運營一體化”,從哪些方面着眼?

  • 時間維度的建設目標:自動化、數據化、智能化

  • 空間維度建設目標:監、管、控、流程、分析

  • 組織與團隊

  • PaaS平臺與SaaS場景分離,沉澱工具文化


研發運營一體化平臺是未來IT建設的方向

“一切以業務爲中心”應該說已經成爲IT界的共識,研發部門也好,運維部門也好,共同的目的都是支撐好業務的發展。


在這樣的共識下,研發和運維部門由傳統的獨立、相對隔離,逐漸走向融合和統一,也是必然。伴隨着DevOps、微服務、敏捷、運營自動化等理念和技術的逐步成熟、完善,這一進程正在加快。

 

在一套平臺上實現研發和運維的敏捷、緊密、流暢的協同和配合,建設研發運營一體化的IT運營平臺,是現在的共識,是未來的方向。

 

建設“研發運營一體化”,從哪些方面着眼?

理論基礎、組織架構、工具平臺,這三個方面可能是我們要重點考慮的。



首先需要明確建設的目標和方向,通過調研、溝通、討論和決策,確定建設的方向和建設的口號。目標本身可能按照時間和空間維度又有不同:在未來的不同時間點上,要達成怎樣的建設目標;在當前空間的能力狀態下,要達成怎樣的建設目標。


我們用於指導確立目標的理論基礎有哪些:ITIL、ITOM、DevOps、精益敏捷、行業標準、巨頭公司最佳實踐、國家標準?這些理論基礎在當下是否是正確的?用於指導目標的確立是否是合適的?於我們需要達成的業務目標是否是有益的?這些可能是我們需要考慮清楚的。


其次針對我們要實現的目標,要經過怎樣的分解,確保能夠責任到團隊、責任到人,確保有人在全力以赴推動目標達成。以及我們當前的IT架構是否需要進行調整,以確保目標的達成。


最後我們需要選購或者研發怎樣的產品、工具或者平臺,才能確保我們的目標是可行的,是可達成的。中間還需要考慮產品或者平臺本身的成本、建設週期以及是否有益於目標的持續推進。


時間維度的建設目標:自動化、數據化、智能化

我們的淺薄理解:在時間維度上,“研發運營一體化平臺”從能力層面大體上應該會經歷“自動化”、“數據化”、“智能化”三個階段。



在“自動化”階段,重點在於實現工具驅動運維。“自動化”,顧名思義,重點通過平臺和工具實現研發、測試、部署、運維、運營等IT場景的自動化。將以往斷點的、手工的、孤立的場景,通過平臺和工具的自動化能力,悉數串聯,在可視化界面中,打通從研發到運營的整個IT流程。


在“數據化”階段,重點在於實現數據驅動運維。通過在平臺中接入大數據模塊,實現研發、運維和運營的數據的接入、存儲和分析,在對數據進行全面挖掘和分析的基礎上,實現研發運營的數據化驅動。例如,通過蒐集用戶對於某個新功能的體驗數據來判斷是否啓動新的研發需求和研發計劃,來改變業務或者應用的體驗。

 

在“智能化”階段,重點在於實現機器驅動運維。這個階段是比較靠後的階段,需要前面兩個階段的能力積累和傳遞。在這個階段,基於智能算法的機器學習來訓練智能運維/運營機器人,實現無人值守和智能的運維與運營。

 

三個階段,彼此獨立,又相輔相成,共同構成“研發運營一體化平臺”時間線上的建設目標梯度。

 

空間維度建設目標:監、管、控、流程、分析

無論“研發運營一體化平臺”的建設處於哪個時間目標點,可能都需要考慮IT對象的監、管、控、流程、分析。



:對於業務、應用以及支撐應用的組件進行整體的監控,並能夠對接故障自愈模塊,實現流程內故障的自動恢復。

 

:IT對象的配置管理,統一的配置中心,提供配置數據,用於支撐研發運營一體化中的場景。


:通過SaaS層工具實現研發、測試、部署和運營各個場景的自動化、數據化和未來的智能化。

 

流程:通過平臺對接流程平臺,實現ITIL流程的自動化執行。


分析:在自動化和數據化的基礎上,通過提取數據進行分析,來得到研發運營中某些方面的知識。


針對IT對象的監、管、控、流程、分析,貫穿於“研發運營一體化平臺”建設的整個週期中,通過這幾個方面的實現,來構建不同階段的“研發運營”的整體藍圖。


組織與團隊

在實現“研發運營一體化平臺”建設過程中,從技術角度而言,組織與團隊本身可能也需要經歷某些調整,以便與目標匹配。



例如,如若採用藍鯨作爲構建“研發運營一體化平臺”的整體PaaS平臺,由於藍鯨的PaaS平臺與SaaS場景分離的特性,傳統的運維團隊會經歷一些裂變:

  • 部分擅長於SaaS工具開發的人員轉型爲運維開發,專職於技術運營SaaS工具的構建;在數據化階段,可以進一步提升爲運維AI工程師

  • 部分擅長於運營需求溝通和規劃的人員轉型爲運維規劃,專職於需求對接和工具規劃;未來有可能進一步提升爲運維數據分析師

  • 而傳統的運維操作部分的工作,則可能由成本更低的專職的運維職能團隊或者運維外包團隊使用構建的工具去執行。


依託平臺提供的內部生態,使得IT團隊人盡其才,各展所長,穩定成長;對於業務目標和IT建設目標的實現有着積極的作用。


PaaS平臺與SaaS場景分離,沉澱工具文化

“研發運營一體化平臺”的建設落實到具體的方案或者產品的選擇階段,我們的粗淺理解是:應該摒棄以往的煙囪運動—即通過不斷部署更新的、更多的、彼此孤立的煙囪式工具和產品來解決問題,而應該基於統一的PaaS模式平臺,通過運維開發模式來實現場景SaaS工具的構建,構建企業內部的研發運營生態體系,沉澱自己的工具文化。


藍鯨研發運營一體化平臺架構圖

 

由於平臺本身採用SOA鬆耦合架構模式,針對時間維度的建設目標:自動化—數據化—智能化,通過PaaS平臺中接入“數據平臺”模塊、“AI平臺”模塊,能夠實現PaaS平臺本身由自動化平臺向數據化平臺、智能化平臺的進化。

 

同時由於平臺本身PaaS平臺與SaaS場景分離的特性,PaaS平臺本身的升級並不影響SaaS工具的使用,兩者是鬆耦合關係;因此,我們能夠基於平臺本身提供的前後端開發框架,使用Python持續沉澱我們的工具文化,去覆蓋研發(CI)、部署運維(CD)、運營(CO)等應用的完整生命週期。

 

SaaS工具的運維開發,同樣遵循OASR的方法論體系,如下所示:



所謂的工具文化指的是:能用工具的地方不用人,必須用人的地方用工具輔助人。

 

由此,工具文化需要解決的核心問題就是:需要爲哪些人(角色)的哪些日常工作(場景)的哪些IT對象的哪些活動提供工具。

 

例如,我們分析一個系統管理員的工作,可能如下:

運維的對象:windows系統、Linux系統、AIX系統等;

涉及的運維活動可能包括:部署系統、初始配置、軟件安裝、基線管理、安全管理、日常巡檢、補丁修復、日誌分析、故障排除等;


上面的活動所屬的場景可能包括:系統資源交付、系統日常管理、系統可用性保障、系統安全保障等;

執行這些操作的角色就是:系統管理員。


針對上面這樣一個需求,完全可以在納管Windows、Linux、AIX的基礎之上,將所有這些運維場景和活動納入一個“系統管理門戶”APP,爲系統管理員定製一個PaaS平臺之上的SaaS工具,使得其能夠在這樣一個工具中實現日常絕大部分工作的自動化執行。


嘉維藍鯨系統管理門戶

 

“研發運營一體化平臺”是IT未來建設大的方向,也是一個逐步推進和更迭的過程。路漫漫其修遠兮,吾將上下而求索。


一家之言,拋磚引玉,也歡迎各位同儕前輩在留言區一起探討。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章