運維會比開發(fā)更加重要
運維的發(fā)展日新月異，曾幾何時虏两，運維僅僅是被認知為跑機房愧旦，裝系統(tǒng)，設計網(wǎng)絡定罢，給開發(fā)擦屁股笤虫。但是現(xiàn)在運維變得極度重要，運維職責也更加細化祖凫，譬如稍大點的公司就將運維劃分為基礎運維琼蚯，網(wǎng)絡運維，DBA, 應用運維惠况，架構師遭庶。其實我個人認為系統(tǒng)架構師應該都安排在運維里，開發(fā)團隊應該率屬于運維團隊才好稠屠。
進入云時代后峦睡，中等層次的運維慢慢會被淘汰翎苫，底層次的運維會越來越少，高水平的運維需求量則日益增長榨了。為什么這么說呢煎谍？云時代背景下，低層次的運維主要按章循干活即可龙屉，而高層次的運維則需考慮系統(tǒng)架構設計呐粘，以及構建自動化的系統(tǒng)。這其實是反應對運維的要求會越來越高叔扼，不但要掌控產品的穩(wěn)定性，做好服務保障的最后一公里漫雷，還要具有系統(tǒng)設計的能力瓜富。
運維現(xiàn)有發(fā)展方向的問題
運維也越來越朝著平臺化，自動化降盹，自助化方向發(fā)展与柑。這種發(fā)展方式雖然可以解決問題，但是會導致碎片化以及難以標準化蓄坏，不可復制价捧，對生態(tài)也是不利的。
所謂碎片化指的是針對性的開發(fā)工具套件解決問題涡戳，比如為了解決配置問題结蟋，開發(fā)了個配置系統(tǒng)，比如為了部署渔彰，開發(fā)了部署系統(tǒng)嵌屎，為了管理應用，針對不同類型的應用開發(fā)管理系統(tǒng)恍涂。所有這些系統(tǒng)都是為了解決特定一類問題而開發(fā)的宝惰，系統(tǒng)孤島，很難讓他們產生關聯(lián)再沧。
導致這種現(xiàn)象的原因在于尼夺，開發(fā)人的能力本身不足，缺乏全局觀炒瘸，或者各個系統(tǒng)本身的屬性特質就導致他們難以關聯(lián)淤堵。每個系統(tǒng)就像一個碎片，所以我們說這事碎片化顷扩。
標準化指的是粘勒，我開發(fā)的配置系統(tǒng)很可能跑到另外一家公司，就不能用了屎即，因為我只是針對我的環(huán)境開發(fā)好配置系統(tǒng)就行庙睡，這里就帶來的另外一個問題就是不可復制事富，也就是我開發(fā)的系統(tǒng)沒辦法很容易移植到別的地方去。
對生態(tài)不利乘陪，則是指统台，因為無法標準化，難以復制啡邑，每家公司各自開發(fā)自己的贱勃，無法形成社區(qū)，大家致力于統(tǒng)一的運維工具谤逼，則必然影響運維生態(tài)的發(fā)展贵扰。
這些問題總結起來，其實就是缺乏一個具有一定規(guī)范的容器流部，將所有的需求框起來東西戚绕。
運維發(fā)展新方向
之前我寫過一篇文章，談及如何用大數(shù)據(jù)思維做運維枝冀，當然這篇文章有他自己的局限性舞丛，只是談及了運維監(jiān)控，灌輸一種 data based 的理念果漾。
前面我們提及了運維發(fā)展現(xiàn)狀球切，以及現(xiàn)有的發(fā)展模式帶來的問題，解決的方式就是 Distributed OS + Data Based：：
- 使用 Distributed OS 抽象出應用的部署/管理/生命周期監(jiān)控/自動化體系
- 使用 Data-Based 思想inspect 應用內部狀態(tài),當然也包括Distributed OS绒障，做好監(jiān)控吨凑，報警，容量規(guī)劃等户辱。
如果有這么一個框怀骤，能把所有的運維需求給支撐起來，規(guī)范起來焕妙，這個框就是分布式操作系統(tǒng)（Distributed OS ）蒋伦。想想我們的單機系統(tǒng)，所謂應用的安裝焚鹊，運行痕届，卸載，交互都是那么簡單和隨意末患。然而到分布式領域后研叫，單機OS 退化后，導致缺乏這么一個統(tǒng)一底層系統(tǒng)璧针。運維在這個層面自己也想了很多辦法嚷炉，通過puppet,通過shell,通過各種開發(fā)出來的系統(tǒng)。但這是運維缺乏規(guī)范和混論的時期探橱，嚴重依賴于運維團隊的自身的能力申屹。
隨著分布式相關應用慢慢成熟绘证，尤其是大數(shù)據(jù)的崛起，對服務器有了更多的需求哗讥，以資源為粒度的管理需求也變得更加迫切嚷那，于是有了Google Borg,開源的則有Mesos,Yarn等。Google Borg 是個典型的杆煞。我們所有的運維需求都應該基于Borg去做魏宽。開發(fā)的服務交給Borg，后續(xù)的服務生命周期（擴容决乎、縮容队询、調度）都由Borg統(tǒng)一接管，服務被Borg部署到哪個IDC构诚、哪個服務器蚌斩，研發(fā)人員不用關心。這個是系統(tǒng)層面的唤反。當然類似Borg的 Mesos,Yarn等凳寺，都是追求一個動態(tài)調度的過程鸭津，我們也可以完全利用Borg,指定將應用安裝在哪些單元(服務器群組)上彤侍，從而能夠接管所有的服務。
這樣逆趋，所謂前面我們提及的配置系統(tǒng)盏阶，部署系統(tǒng)，服務器監(jiān)控都是在Borg提供的基礎服務闻书。就好比單機系統(tǒng)名斟，你通過它安裝，運行魄眉，關閉砰盐，卸載應用，你可以看服務器的資源使用情況坑律。Borg 也是完全一樣的岩梳。
也有人會說，很多應用的安裝部署是很復雜的晃择，而且如果使用了Borg其實就使得應用必須去適配Borg才能被管理冀值。經過我們的實際實踐，大部分應用都不需要對應用進行更改宫屠，也不需要對Borg進行更改列疗，就可以部署和管理起來。復雜的比如Hadoop體系的安裝浪蹂，則需要Borg進行一定程度的支持抵栈，我們抽象出了一套應用的部署方案告材，只要簡單的寫一些描述文件，Borg拿到Hadoop的發(fā)型包竭讳，就知道如何安裝和管理他們了创葡。如果你需要對Hadoop做更細致的增強或者管理，你可以開發(fā)一個第三方應用绢慢，然后通過Borg安裝去管理灿渴。Borg提供了交互的API,你可以通過這些API去管理Hadoop如果生命周期，而無需知道Hadoop安裝在哪胰舆。
現(xiàn)在很流行的容器技術骚露，也被廣泛的被Mesos/Borg調度，對Borg來說這是以資源為粒度的應用缚窿，我們前面提及的棘幸，則是以服務器為粒度的應用。
前面講的是基礎平臺層面的倦零，我們其實更多的是要對應用進行更細致的觀察误续。在Borg之上的應用可以是非常復雜的，應用的關聯(lián)也是非常復雜的扫茅，微服務的興起導致鏈路非常長蹋嵌，所以我們有了全鏈路追蹤的需求。一切服務都是為了幫助數(shù)據(jù)進行流轉和變換葫隙，服務的狀態(tài)也都反應在數(shù)據(jù)流上栽烂，這種瞬態(tài)和終態(tài)的量是非常大的，所以我們需要借助大數(shù)據(jù)的思維去做處理恋脚。
到這里就可以參考大數(shù)據(jù)思維做運維灌輸?shù)母拍盍恕?/p>
所以未來運維可以完全依托一個固定的分布式操作系統(tǒng)腺办，在其上開發(fā)各種運維工具，利用大數(shù)據(jù)相關的理念和工具糟描，監(jiān)控怀喉，追蹤，分析服務的狀態(tài)船响，解決現(xiàn)有的運維工具碎片化躬拢，難以復制，難于貢獻生態(tài)的問題灿意。
