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

​​關注嘉爲科技，獲取運維新知

 

本文目錄

 

• 研發運營一體化平臺是將來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將來建設大的方向，也是一個逐步推動和更迭的過程。路漫漫其修遠兮，吾將上下而求索。

 

一家之言，拋磚引玉，也歡迎各位同儕前輩在留言區一塊兒探討。​​​​