運維會比開發更加重要
運維的發展日新月異，曾幾何時，運維僅僅是被認知爲跑機房，裝系統，設計網絡，給開發擦屁股。但是現在運維變得極度重要，運維職責也更加細化，譬如稍大點的公司就將運維劃分爲基礎運維，網絡運維，DBA, 應用運維，架構師。其實我個人認爲系統架構師應該都安排在運維裏，開發團隊應該率屬於運維團隊纔好。
進入雲時代後，中等層次的運維慢慢會被淘汰，底層次的運維會越來越少，高水平的運維需求量則日益增長。爲什麼這麼說呢？雲時代背景下，低層次的運維主要按章循幹活即可，而高層次的運維則需考慮系統架構設計，以及構建自動化的系統。這其實是反應對運維的要求會越來越高，不但要掌控產品的穩定性，做好服務保障的最後一公里，還要具有系統設計的能力。
運維現有發展方向的問題
運維也越來越朝着平臺化，自動化，自助化方向發展。這種發展方式雖然可以解決問題，但是會導致碎片化以及難以標準化，不可複製，對生態也是不利的。
所謂碎片化指的是針對性的開發工具套件解決問題，比如爲了解決配置問題，開發了個配置系統，比如爲了部署，開發了部署系統，爲了管理應用，針對不同類型的應用開發管理系統。所有這些系統都是爲了解決特定一類問題而開發的，系統孤島，很難讓他們產生關聯。
導致這種現象的原因在於，開發人的能力本身不足，缺乏全局觀，或者各個系統本身的屬性特質就導致他們難以關聯。每個系統就像一個碎片，所以我們說這事碎片化。
標準化指的是，我開發的配置系統很可能跑到另外一家公司，就不能用了，因爲我只是針對我的環境開發好配置系統就行，這裏就帶來的另外一個問題就是不可複製，也就是我開發的系統沒辦法很容易移植到別的地方去。
對生態不利，則是指，因爲無法標準化，難以複製，每家公司各自開發自己的，無法形成社區，大家致力於統一的運維工具，則必然影響運維生態的發展。
這些問題總結起來，其實就是缺乏一個具有一定規範的容器，將所有的需求框起來東西。
運維發展新方向
之前我寫過一篇文章，談及如何用大數據思維做運維，當然這篇文章有他自己的侷限性，只是談及了運維監控，灌輸一種 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之上的應用可以是非常複雜的，應用的關聯也是非常複雜的，微服務的興起導致鏈路非常長，所以我們有了全鏈路追蹤的需求。一切服務都是爲了幫助數據進行流轉和變換，服務的狀態也都反應在數據流上，這種瞬態和終態的量是非常大的，所以我們需要藉助大數據的思維去做處理。
到這裏就可以參考大數據思維做運維灌輸的概念了。
所以未來運維可以完全依託一個固定的分佈式操作系統，在其上開發各種運維工具，利用大數據相關的理念和工具，監控，追蹤，分析服務的狀態，解決現有的運維工具碎片化，難以複製，難於貢獻生態的問題。
作者：祝威廉
來源：CSDN
原文：https://blog.csdn.net/allwefantasy/article/details/81039590
版權聲明：本文爲博主原創文章，轉載請附上博文鏈接！