對于人工智能，我們通過機器學習、深度學習算法已經有很了很多了解了。但實際上，我們還在人工智能的初級階段，未來一段時間內可能處于并將長期處于人工智能初級階段。在人工智能逐漸“智能”的過程中，有一種形態有點意思，那便是知識圖譜。

這是Google在2012年5月17日提出的新概念，它本質上是實體之間關系的語義網絡，把信息轉化為知識。日常生活中我們接觸到的信息是外部的客觀事實，比如這里有一只冰淇淋，它現在是凝固狀態，而知識是對外部客觀規律的歸納和總結，比如冰淇淋的保存維度是0度以下，大于0度時就會融化。

DevOps，即研發運維，它指的是技術團隊一種新的軟件研發管理思想，把團隊開發人員和運維人員一體化，將業務需求拆分原子化，使用云計算、微服務、持續集成交付工具來最大化的將業務流程自動化，對所有的過程進行記錄和分析，使用數據來精準營銷與決策。

大家覺得DevOps和人工智能都是技術領域的兩個分支，都是賦能業務的，兩者之間不會有什么交集。那你可就錯了。人工智能是技術領域的一個分支，它適用的范圍非常廣，只要有數據的地方它都能發揮作用，用戶使用產品產生的數據，研發開發產品所產生的數據，系統內部交互的數據，它都可以做分析。DevOps可以讓人工智能領域的開發人員更好的開發，讓業務部門的開發人員更好的利用人工智能領域的數據，反過來，人工智能數據也可以讓DevOps更好的進行，我們就一起來看看人工智能的分支知識圖譜如何在DevOps中大展身手吧。

在軟件研發過程中，從需求的開發到上線包含很多數據。它包含需求評審確認之后的研發開發工時、測試工時、整個需求上線時長；研發開發過程中的代碼提交次數、代碼量；上線過程中的成功發布次數、回滾次數；運行產品的數據中心、物理機、虛擬機、接入交換機、核心交換機、路由、部署實例。通過一整套數據可以搭建軟硬件研發運維知識圖譜，以全局的視角只是系統內各個應用、軟件、硬件、虛擬機、物理機的邏輯、調用關系、鏈接關系，幫助研發人員在遇到問題時更好的找到問題、解決問題，幫助產品人員在產品開發時更好的知道風險、解決風險。

研發運維知識圖譜其實很好搭建，它的模型其實是最簡單的。為什么這么說呢？因為它的數據來源、數據類型、數據結構、使用用戶都是固定的，機器硬件產生的數據、系統之間調用的數據、研發工具軟件產生的數據全匯聚到一起，每一個實體與實體之間的關系也是相對固定的，比如系統間的調用關系、部署集群與業務的所屬關系、數據與數據的上下游關系。相對業務所遇到的不同場景的半結構化數據、非結構化數據的收集與處理，實體之間關系的甄別、論證、優化來說，研發運維知識圖譜真的太簡單了。

在研發運維知識圖譜搭建的過程中，我們可以使用圖數據庫來進行存儲。圖數據庫的模式天然就是和知識圖譜匹配的，都以實體為中心，實體與實體之間通過關系鏈接起來，因此采用圖數據庫存儲數據是最好的選擇。此外圖數據庫在查詢數據、獲取數據時性能也很好，不需要像關系型數據庫那么復雜。圖數據庫的擴展性也很好，有新的數據增加時就增加新的實體屬性、關系屬性就好了，不用像關系型數據庫那樣還需要增加新的表、新的字段、新的關聯關系。

在研發運維知識圖譜搭建好了之后，我們就可以基于此建立我們的告警規則了。在系統數據告警中，可以基于告警數據的模型訓練來智能建立告警規則，也可以通過人為的經驗值來設定告警閾值，不斷的調整適應。通過人為經驗值就比較簡單了，有經驗的開發同學他會根據所遇到的業務規模、用戶流量、機器系統硬件配置、負載情況來設定，比如設置CPU達到90%時觸發告警，內存使用率超過80%時告警。通過數據訓練告警模型就是一個比較長期的事情，我們需要先采集告警數據，數據分類，歷史發生過的告警次數，準確告警次數來學習告警、分類告警，最后達到預測告警。

智能運維的目標是實現告警風暴收斂、告警準確預測、告警自動恢復、根因自動定位，這也是研發運維中所期待的內容。隨著知識圖譜技術不斷的發展，運維知識圖譜的不斷建設和豐富，告警知識圖譜的不斷優化和完善，人工智能與DevOps必定會更好的協同，共同提升開發運維人員的工作效率，為企業降本提效，為用戶提供更好服務～