天天看點

運維=平台+資料

<b>運維會比開發更加重要</b>

運維的發展日新月異,曾幾何時,運維僅僅是被認知為跑機房,裝系統,設計網絡,給開發擦屁股。但是現在運維變得極度重要,運維職責也更加細化,譬如稍大點的公司就将運維劃分為基礎運維,網絡運維,dba, 應用運維,架構師。其實我個人認為系統架構師應該都安排在運維裡,開發團隊應該率屬于運維團隊才好。

進入雲時代後,中等層次的運維慢慢會被淘汰,底層次的運維會越來越少,高水準的運維需求量則日益增長。為什麼這麼說呢?雲時代背景下,低層次的運維主要按章循幹活即可,而高層次的運維則需考慮系統架構設計,以及建構自動化的系統。這其實是反應對運維的要求會越來越高,不但要掌控産品的穩定性,做好服務保障的最後一公裡,還要具有系統設計的能力。

運維現有發展方向的問題

運維也越來越朝着平台化,自動化,自助化方向發展。這種發展方式雖然可以解決問題,但是會導緻碎片化以及難以标準化,不可複制,對生态也是不利的。

所謂碎片化指的是針對性的開發工具套件解決問題,比如為了解決配置問題,開發了個配置系統,比如為了部署,開發了部署系統,為了管理應用,針對不同類型的應用開發管理系統。所有這些系統都是為了解決特定一類問題而開發的,系統孤島,很難讓他們産生關聯。

導緻這種現象的原因在于,開發人的能力本身不足,缺乏全局觀,或者各個系統本身的屬性特質就導緻他們難以關聯。每個系統就像一個碎片,是以我們說這事碎片化。

标準化指的是,我開發的配置系統很可能跑到另外一家公司,就不能用了,因為我隻是針對我的環境開發好配置系統就行,這裡就帶來的另外一個問題就是不可複制,也就是我開發的系統沒辦法很容易移植到别的地方去。

對生态不利,則是指,因為無法标準化,難以複制,每家公司各自開發自己的,無法形成社群,大家緻力于統一的運維工具,則必然影響運維生态的發展。

這些問題總結起來,其實就是缺乏一個具有一定規範的容器,将所有的需求框起來東西。

<b></b>

<b>運維發展新方向</b>

之前我寫過一篇文章,談及如何用大資料思維做運維,當然這篇文章有他自己的局限性,隻是談及了運維監控,灌輸一種 data based 的理念。

前面我們提及了運維發展現狀,以及現有的發展模式帶來的問題,解決的方式就是 distributed os + data based::

使用 distributed os 抽象出應用的部署/管理/生命周期監控/自動化體系

使用 data-based 思想inspect 應用内部狀态,當然也包括distributed os,做好監控,報警,容量規劃等。

如果有這麼一個框,能把所有的運維需求給支撐起來,規範起來,這個框就是分布式作業系統(distributed os )。想想我們的單機系統,所謂應用的安裝,運作,解除安裝,互動都是那麼簡單和随意。然而到分布式領域後,單機os 退化後,導緻缺乏這麼一個統一底層系統。運維在這個層面自己也想了很多辦法,通過puppet,通過shell,通過各種開發出來的系統。但這是運維缺乏規範和混論的時期,嚴重依賴于運維團隊的自身的能力。

随着分布式相關應用慢慢成熟,尤其是大資料的崛起,對伺服器有了更多的需求,以資源為粒度的管理需求也變得更加迫切,于是有了google borg,開源的則有mesos,yarn等。google borg 是個典型的。我們所有的運維需求都應該基于borg去做。開發的服務交給borg,後續的服務生命周期(擴容、縮容、排程)都由borg統一接管,服務被borg部署到哪個idc、哪個伺服器,研發人員不用關心。這個是系統層面的。當然類似borg的 mesos,yarn等,都是追求一個動态排程的過程,我們也可以完全利用borg,指定将應用安裝在哪些單元(伺服器群組)上,進而能夠接管所有的服務。

這樣,所謂前面我們提及的配置系統,部署系統,伺服器監控都是在borg提供的基礎服務。就好比單機系統,你通過它安裝,運作,關閉,解除安裝應用,你可以看伺服器的資源使用情況。borg 也是完全一樣的。

也有人會說,很多應用的安裝部署是很複雜的,而且如果使用了borg其實就使得應用必須去适配borg才能被管理。經過我們的實際實踐,大部分應用都不需要對應用進行更改,也不需要對borg進行更改,就可以部署和管理起來。複雜的比如hadoop體系的安裝,則需要borg進行一定程度的支援,我們抽象出了一套應用的部署方案,隻要簡單的寫一些描述檔案,borg拿到hadoop的發型包,就知道如何安裝和管理他們了。如果你需要對hadoop做更細緻的增強或者管理,你可以開發一個第三方應用,然後通過borg安裝去管理。borg提供了互動的api,你可以通過這些api去管理hadoop如果生命周期,而無需知道hadoop安裝在哪。

現在很流行的容器技術,也被廣泛的被mesos/borg排程,對borg來說這是以資源為粒度的應用,我們前面提及的,則是以伺服器為粒度的應用。

前面講的是基礎平台層面的,我們其實更多的是要對應用進行更細緻的觀察。在borg之上的應用可以是非常複雜的,應用的關聯也是非常複雜的,微服務的興起導緻鍊路非常長,是以我們有了全鍊路追蹤的需求。一切服務都是為了幫助資料進行流轉和變換,服務的狀态也都反應在資料流上,這種瞬态和終态的量是非常大的,是以我們需要借助大資料的思維去做處理。

到這裡就可以參考大資料思維做運維灌輸的概念了。

是以未來運維可以完全依托一個固定的分布式作業系統,在其上開發各種運維工具,利用大資料相關的理念和工具,監控,追蹤,分析服務的狀态,解決現有的運維工具碎片化,難以複制,難于貢獻生态的問題。