作者簡介

[[161991]] 

　　余何，在運維領(lǐng)域耕耘十余載，07年加入到平安集團(tuán)旗下的科技公司。2011年，主導(dǎo)集團(tuán)內(nèi)***的應(yīng)用遷徙與架構(gòu)變更；2012年開展IT運維管理變革，打通橫向條線，實現(xiàn)技能融合。光陰荏苒，日月如梭，運維往事歷歷在目，流過汗，熬過夜，攤過事，也拿過獎，運維是一個從無到有、日積月累、不斷提升的過程，也是一個需耐得住寂寞，頂?shù)米毫Φ男挟?dāng)，在此與正奮斗在運維一線的伙伴們共勉。

　　“工作不代表你，銀行存款不代表你，你開的車也不代表你，皮夾里的東西不代表你，衣服也不代表你，你只是平凡眾生中的其中一個。”

————電影《搏擊俱樂部》

　　前言

　　運維人員在忙碌的工作中要面對各種“新概念”潮汐般地沖擊，他們不得不放下精細(xì)化的腳本編程，丟下原生態(tài)的性能調(diào)優(yōu)方法，隨大流的淹沒在這瞬息萬變的“新時代”，運維水準(zhǔn)的高低與這些新概念也扯上了關(guān)系，久而久之我們居然忘了運維的本質(zhì)是什么。

　　運維到底需要什么

　　看看我們每天所做的，都是為了一個共同目標(biāo)，讓應(yīng)用快速上線、穩(wěn)定運行！那些廣告術(shù)語：“彈性擴(kuò)容、自助服務(wù)、按需分配”，以及“成本減少多少，效率提升多少”之類的陳詞濫調(diào)與你并沒有太多關(guān)系，不是嗎?

　　實際上所有一切都是圍繞著應(yīng)用開展的，應(yīng)用自身決定了快速而穩(wěn)定的80%！面對一個龐大的、遺留的、冗余的、配置雜亂的CRM系統(tǒng)、ERP系統(tǒng)，無論外來新概念如何流弊也解決不了你任何問題，你唯一的出路是好好理解這個系統(tǒng)。

　　通過一些自動化腳本盡量的減少一些重復(fù)性工作，或者你強(qiáng)勢的要求開發(fā)人員改造整個系統(tǒng)，采用全新的應(yīng)用部署架構(gòu)，但這又是公司層面問題。重要的事情再說一遍，關(guān)于自動部署、快速擴(kuò)容方面，應(yīng)用自身決定了80%。如果我們還不明白這一點，而迷信于什么互聯(lián)網(wǎng)神器，那終將無功而返。

　　它可以給你什么

　　在基礎(chǔ)架構(gòu)引入虛擬化后，關(guān)于云的暢想一下子被點燃了，讓我看看下面的圖里：

　　云暢想

　　姑且讓我們將虛擬化的引入定義為Cloud 1.0，這個時期將物理服務(wù)器資源拆解為隔離的虛擬計算單元提供給不同用戶。對于不那么挑剔的用戶，我們完全可以在一臺物理服務(wù)器上的OS中提供多個服務(wù)給他，這肯定比虛擬化的資源使用率要來得高，但是，我們(運維人員)無法決定與控制應(yīng)用特性，也就無法避免同一個OS中應(yīng)用間的干擾，如此一來虛擬化的引入幫助我們解決了大問題。

　　對于中小企業(yè)停留在Cloud 1.0就足矣，而對于大型企業(yè)、互聯(lián)網(wǎng)企業(yè)，他們很快發(fā)現(xiàn)其所管理的計算資源陡然上升。亞馬遜Amazon率先將這種虛擬化資源商業(yè)化，通過集中管理界面對外兜售，而開源領(lǐng)域Openstack與各虛擬化組件集成，勢必統(tǒng)一行業(yè)標(biāo)準(zhǔn)。

　　無論是公有云還是私有云，在這一輪Cloud 2.0的戰(zhàn)役中，***的改變是組成了一個更大的虛擬化池，將虛擬機(jī)的資源申請、配置管理、服務(wù)計費等用另外一種方式加以呈現(xiàn)。而關(guān)于虛擬機(jī)(OS)之上的東西和以前并無太多差別。是的，亞馬遜Amazon的公有云，他將平時“閑置”的資源兜售給了外部用戶，國內(nèi)大型“云”提供商，他們很可能是戰(zhàn)略性的“占領(lǐng)”未來行業(yè)市場。

　　至于大多數(shù)企業(yè)內(nèi)部的私有Cloud 2.0，則情況又完全是另一番景象。限于這個階段大部分工作是重新梳理了一種配置管理、資產(chǎn)管理以及服務(wù)定價的方式，讓我們將Cloud2.0定義為Resource-centric。

　　事物的發(fā)展總是向前的，盡管在發(fā)展道路上常會偏離軌道，但總將回歸本位，運維的本質(zhì)是讓應(yīng)用快速上線、穩(wěn)定運行，對于一個應(yīng)用本身高度可控的企業(yè)，它們選擇了更進(jìn)一步，讓應(yīng)用適應(yīng)平臺，在公有、私有IaaS上構(gòu)建Application-centric的Cloud 3.0，亦即PaaS。

　　在公有、私有IaaS上構(gòu)建PaaS

　　PaaS運維服務(wù)的本質(zhì)

　　PaaS并不是解決一切問題的靈丹妙藥，它專屬于特定領(lǐng)域，這個領(lǐng)域與應(yīng)用部署架構(gòu)、業(yè)務(wù)場景等緊密相關(guān)。如果你發(fā)現(xiàn)組織中有大量需要互聯(lián)網(wǎng)化的應(yīng)用場景，它們大部分集中在渠道領(lǐng)域，要求應(yīng)用加快測試、發(fā)布效率，要求隨時進(jìn)行快速擴(kuò)容，那么我們可以考慮構(gòu)建自己的私有PaaS，它可以管理公、私有IaaS資源(虛擬、物理)。

　　PaaS在業(yè)界的標(biāo)準(zhǔn)并未統(tǒng)一，而充分發(fā)揮PaaS優(yōu)勢的很大一部分決定于應(yīng)用部署架構(gòu)。如果你有一個時髦的開發(fā)團(tuán)隊，他們遵循去中心化、異步消息通信、無狀態(tài)等原則部署應(yīng)用，那么你可以輕松的將其推送到PaaS。反之，如果有著一大堆跑在Window操作系統(tǒng)上的窗口應(yīng)用，好吧！PaaS再神奇也于事無補(bǔ)。

　　至此，讓我們看看在OS之上，運維服務(wù)要解決的問題：

　　1.資源分配

　　我們大部分時間在進(jìn)行資源分配，將服務(wù)器、存儲、操作系統(tǒng)以及軟件等分配給應(yīng)用，工作的復(fù)雜性圍繞著應(yīng)用而產(chǎn)生。

　　2.應(yīng)用部署

　　將開發(fā)兄弟提供的業(yè)務(wù)邏輯放到我們所分配的資源中去。

　　3.服務(wù)發(fā)現(xiàn)

　　如果讓用戶找到這個服務(wù)，如何讓服務(wù)于服務(wù)之間可以互訪問。通常的做法有負(fù)載均衡、域名解析、配置消息中心等方式解決服務(wù)發(fā)現(xiàn)問題。

　　4.監(jiān)控巡檢

　　監(jiān)控巡檢是運維之必須，在此不再累述。

　　在這里，我們討論前三項，資源分配、應(yīng)用部署于服務(wù)發(fā)現(xiàn)。

　　PaaS平臺功能設(shè)計

　　為了能夠?qū)崿F(xiàn)PaaS平臺，我們需要保證運維的四個主要工作內(nèi)容實現(xiàn)自動化，下面這些功能全都是圍繞著實現(xiàn)這個目標(biāo)而引入的。

　　1.計算單元打包

　　虛擬機(jī)鏡像、配置管理工具(puppet、saltstack、ansible)所負(fù)責(zé)的任務(wù)就是將應(yīng)用邏輯計算單元進(jìn)行打包。計算單元包含了運行業(yè)務(wù)系統(tǒng)的全棧組件，其涵蓋了操作系統(tǒng)、中間件、依賴包等。

　　PaaS平臺中，我們選擇Docker替換原有的方式，作為一個輕量級容器，它比虛擬機(jī)更加節(jié)約資源，同時可以基于一份軟件介質(zhì)運行多個實例，Docker的倉庫、鏡像與容器三元素讓應(yīng)用邏輯計算單元大大得到了簡化。

　　誠然，ansible這類軟件配置工具已經(jīng)非常輕巧、快捷，并且滿足95%以上的需求，但當(dāng)決定將PaaS構(gòu)建在跨IDC、跨第三方數(shù)據(jù)中心時，基于鏡像的分發(fā)能夠更加穩(wěn)定的滿足我們需求。Docker也有其缺點，例如不支持32位平臺，不支持windows服務(wù)器。

　　Docker+Ansible 完成計算單元打包

　　2.資源動態(tài)分配

　　與Cloud 2.0的IaaS不同，用戶并不關(guān)注如何獲得CPU、內(nèi)存、存儲資源。他們僅關(guān)注自身應(yīng)用計算邏輯的運行，他們希望資源是動態(tài)分配、彈性擴(kuò)容的。

　　數(shù)據(jù)中心需要一個統(tǒng)一的資源管理者，它將所有資源(無論虛擬、物理)抽象成一個整體，如同一個數(shù)據(jù)中心操作系統(tǒng)。這種資源的抽象不僅僅要滿足服務(wù)型計算，還要滿足大數(shù)據(jù)時代的MapReduce計算，以及今后的各種類型計算，這意味著資源分配與任務(wù)調(diào)度兩部分功能是解耦的。

　　在分布式資源管理領(lǐng)域，主流的選擇是Mesos、YARN。

　　◆ Mesos：Mesos最早由美國加州大學(xué)伯克利分校AMPLab實驗室開發(fā)，后在Twitter、Apple、Netflix等互聯(lián)網(wǎng)企業(yè)廣泛使用，成熟度高。

　　◆ YARN：Apache Hadoop YARN是一種新的 Hadoop 資源管理器，它是一個通用資源管理系統(tǒng)，可為上層應(yīng)用提供統(tǒng)一的資源管理和調(diào)度。

　　其他的選擇還有Kubernetes、CloudFoundry、OpenShift等方案，但這幾種不滿足資源分配與任務(wù)調(diào)度解耦，對應(yīng)用規(guī)則要求太高，并不容易兼容現(xiàn)有應(yīng)用。在我們環(huán)境選擇了Mesos，其獨有的靈活性保證了支持更多類型的上層分布式計算應(yīng)用。

　　Mesos 分布式資源管理

　　數(shù)據(jù)中心OS

　　3.任務(wù)調(diào)度功能

　　任務(wù)調(diào)度器與資源管理器的***不同在于其要對運行中的應(yīng)用服務(wù)負(fù)責(zé)，包括啟動、停止服務(wù)，監(jiān)控服務(wù)以及在服務(wù)失效時的故障轉(zhuǎn)移。最初的分布式架構(gòu)設(shè)計中，人們常常模糊了作業(yè)調(diào)度與資源管理二者間的界線。

　　其一是分布式平臺是為某一專屬計算類型服務(wù)，例如Hadoop平臺為MapReduce計算類型服務(wù)。

　　其二，作業(yè)調(diào)度與資源管理的交互頻度高，合二為一后的效率更高。但隨后人們發(fā)現(xiàn)資源管理器的功能是相對穩(wěn)定的，而作業(yè)調(diào)度因為計算類型多。

　　并行計算有MapReduce、Stream，普通計算有Service、批處理等，每一種計算類型的作業(yè)調(diào)度方式完全不同，如果將資源管理器與作業(yè)調(diào)度器綁定在一起則會失去分布式平臺的計算靈活性。

　　是以Mesos為核心，支持多領(lǐng)域的分布式集群調(diào)度框架，包括Docker容器集群調(diào)度框架Marathon、分布式 Cron(周期性執(zhí)行任務(wù))集群調(diào)度框架Chronos和大數(shù)據(jù)的主流平臺Hadoop和Spark的集群調(diào)度框架等，實現(xiàn)系統(tǒng)的資源彈性調(diào)度。

　　Mesos架構(gòu)示意圖

　　對于服務(wù)型的長任務(wù)，我們選擇Marathon作為其任務(wù)調(diào)度器。

　　Marathon任務(wù)調(diào)度

　　4.服務(wù)發(fā)現(xiàn)功能

　　服務(wù)發(fā)現(xiàn)有兩種形態(tài)，一種是用戶(人)來訪問的，一種是應(yīng)用之間互調(diào)的，對于前者需要保持一個穩(wěn)定的入口(不變)，而對于后者，如果在一個寬松的環(huán)境里，是運行變化，并接受變化通知的。而對于長服務(wù)型計算類型，除了解決服務(wù)發(fā)現(xiàn)外，還要考慮將任務(wù)分發(fā)到多個節(jié)點，亦即負(fù)載均衡問題。

　　服務(wù)發(fā)現(xiàn)上可選的有通過動態(tài)寫入DNS系統(tǒng)來滿足用戶需求，通過zookeeper之類的分布式協(xié)調(diào)系統(tǒng)充當(dāng)配置中心通知外部系統(tǒng)。而在負(fù)載均衡上，企業(yè)級的專用設(shè)備，例如F5等都提供了API接口以供調(diào)用，而開源軟件上通常采用Haproxy。

　　通過zookeeper實現(xiàn)服務(wù)發(fā)現(xiàn)

　　Marathon的Haproxy服務(wù)發(fā)現(xiàn)方案

　　5.日志集中管理

　　在一般情況下，日志以文件的形式存放在本地操作系統(tǒng)上以供查詢，而在分布式系統(tǒng)中，計算單元不會再固定于一個物理節(jié)點上。如果日志仍以文件形式存放在本地，隨著計算單元的漂移，日志將留存在與計算單元沒有關(guān)系的物理節(jié)點上。對于系統(tǒng)管理人員、運營人員來說，日志查詢檢索將變成一門繁雜工作。

　　在分布式平臺上構(gòu)建集中的日志管理平臺，將各種類型的日志收集、索引好，以消息的形式看待每一條日志將成為分布式平臺上的一個重要功能。采用開源社區(qū)流行的ELK組件(elasticsearch、logstash、kibana)，我們會看到如何將所有節(jié)點的日志導(dǎo)入到一個集中平臺進(jìn)行可視化管理。

　　elastic日志集中管理

　　PaaS下的運維發(fā)展之路

　　PaaS時代的來臨，對運維職業(yè)發(fā)展將產(chǎn)生深遠(yuǎn)影響，一個嚴(yán)重的誤區(qū)是認(rèn)為云計算將徹底取代運維行業(yè)，實際上在IT發(fā)展的過程中，對運維的要求在不斷提高。云計算、大數(shù)據(jù)、物聯(lián)網(wǎng)以及移動互聯(lián)等無一不是這個時代向前發(fā)展的標(biāo)志， 只要IT越貼近用戶，就會產(chǎn)生更多的數(shù)據(jù)、發(fā)現(xiàn)更多的需求，運維則愈加之重要。

　　運維職業(yè)發(fā)展的三個硬道理是：

　　1.不變應(yīng)萬變

　　要做到不變應(yīng)萬變，就必須掌握業(yè)內(nèi)最基礎(chǔ)、最穩(wěn)固的知識點，打下結(jié)實的基礎(chǔ)。相對于開發(fā)應(yīng)用框架、前端UI的變化，存儲、計算、網(wǎng)絡(luò)三大資源知識是非常穩(wěn)固的，即便是變化也一定是建立在基礎(chǔ)原理之上。

　　互聯(lián)網(wǎng)變化之快，新技術(shù)層出不盡，運維人員不能太過于跟風(fēng)，一定要看清事物背后的本質(zhì)，與基礎(chǔ)原理相聯(lián)系，深入底層內(nèi)部思考，這樣才能做到萬變不離其宗。以Linux操作系統(tǒng)為例，運維人員并不需要將所有發(fā)行版的安裝、命令等背誦入流，而是精通一到兩種，并通過操作系統(tǒng)的運行原理來解釋一切問題。

　　2.精通編程

　　不會編程的運維人員不是好運維，在開源風(fēng)潮涌現(xiàn)的年代，可以預(yù)見未來對運維人員的開發(fā)能力要求會非常之高。系統(tǒng)開發(fā)與應(yīng)用開發(fā)在完全不同的兩個維度，系統(tǒng)開發(fā)更貼近于底層，掌握程序的運行原理對編程能力的提升有極大幫助，例如可執(zhí)行文件的結(jié)構(gòu)、在內(nèi)存中的形態(tài)等。

　　運維人必須精通一門編程語言，參與到社區(qū)，品讀開源代碼，養(yǎng)成編程習(xí)慣。引用Linux之父Torvalds的一句話“just for fun” ，這是運維人看待編程應(yīng)保持的心態(tài)。

　　3.敏銳觀察力

　　時代依然在不斷變化，運維人雖不必立即掌握每一項新出爐的技術(shù)，但他們必須保持對行業(yè)的關(guān)注度。預(yù)留一些時間給自己閱覽社區(qū)新聞，積極參加線下社區(qū)活動，隨著新技術(shù)的成熟以及自己的個人興趣，在新興領(lǐng)域投入必要的時間。

　　Larry Wall是Perl語言的設(shè)計者，他屬于運維鼻祖，也就是系統(tǒng)管理員。當(dāng)時Larry遇到了一個問題，如同我們現(xiàn)在遇到的一樣。他需要在繁雜的內(nèi)容中萃取文本信息，而手頭的工具只有awk和shell這些工具可以幫助解決問題。

　　這些工具用起來卻是那么痛苦，Larry太懶了——如果用awk來做的話，要做大量工作，這讓他無法忍受；Larry也太急躁——awk做起來很慢，他可等不及；最終他的高傲促使他完成了一件壯舉，設(shè)計一門新語言——Perl，造福整個社區(qū)。是的，你會發(fā)現(xiàn)運維時代在變，但同樣的故事還在發(fā)生，你是否已做好準(zhǔn)備?