應用運維三部曲，就是告訴你應用運維就該這麼幹！前端
在平常的工做中，應用運維是否以爲本身很苦逼。好比說：mysql
是否是要值夜班？是web
是否是要不斷應對需求？是redis
是否是就是一個服務器者和應用發佈者？是sql
是否是要接受開發對咱們不懂技術的質疑？是mongodb
曾經有個研發想轉運維，問是否要值夜班，若是是夜班的話，我就不轉了。其實還真說明了一個事實，你作得好研發，還真不必定能作好運維哈。數據庫
那咱們一塊兒來探討一下如何作好應用運維，完全改變以上你們對你錯誤的定位和認知，我把它稱之爲運維三部曲：api
在任何一個互聯網的企業中，遵循這三部走策略，必定能夠把應用運維有條理的作好（傳統企業不敢說）。另外輔助工具化和數據化的運維平臺支撐，應用運維就如虎添翼，會大大影響三部走的進程。但在本篇文章不去談自動化和數據化運維如何作，主要是談標準化、服務化和無狀態化三步走的應用運維路徑，看是如何實現，且一步一步的影響應用運維的，也能夠看出對應用運維的一些要求。如下是其詳要的論述：服務器
第一步：標準化
網絡
標準化是應用運維強勢走出運維，面向研發的第一步。一個應用運維，若是沒有把標準化理解到位，我以爲是不合格的，會給後續的運維帶來不少問題，包括成本的上升、價值的體現等等。那標準化運維到底包含哪些？我以爲能夠小到一個進程的運行屬主，也能夠大到系統架構或者機房部署架構等等。此時照樣能夠用分層體系來進行細分，識別標準化運維到底要作什麼？
一、基礎設施標準化
和應用相關的有服務器、虛擬化、OS、機房部署、公有云等等。
服務器能夠按照本身的服務類型選擇幾個標準類型，好比說CPU計算性（內存能夠小一些）、內存性（把內存加大）、數據庫型三種。在涉及到hadoop運算的企業中，能夠配置多硬盤的服務器，好比說內置12塊1T no raid的硬盤機器。這種標準化選型沒有壞處，特別是規模愈來愈大的時候，會逐漸看到這種標準化帶來的好處。第1、變動成本不斷下降。硬件垂直擴展的方式，在規模下運維沒法應對；第2、對業務架構造成反向的推進力，根據機型分佈本身的服務組件。
虛擬化。並非每家公司均可以玩得起IAAS雲，特別是基於Openstack，要投入大量研發和運維資源，可是對於任何公司來講，不管大與小，均可以採用虛擬化的技術。不管是操做系統級別的Kvm、Esxi和Xen，仍是輕量級虛擬化Docker，都值得去嘗試使用。虛擬化能夠解決資源複用問題，突破OS的資源限制（好比說文件句柄）、資源收縮或回收等等，在web類的服務中，更須要去嘗試。前期不導入的話，在後期隨着業務規模愈來愈大的時候，虛擬化的導入難度會增長。
OS。在OS層面上，其實就是選擇好你的操做系統和內核版本，不要任意的選型，也不要太相信操做系統版本更新帶來的優化效果。注意別用32位的操做系統便可。其餘的優化更多的交給應用優化好了，帶來的效果更好、成本更低。
機房部署。這個要結合業務來看，選擇幾個穩定的機房就行了（通常都是兩個）。以前在一家公司，網站類的服務分佈在多個機房中，維護很是麻煩，任何一個機房的故障都會有業務的影響，最後所有收攏到兩個機房中，運維複雜度大大下降。核心業務作雙機房部署，非核心機房單機房部署，經過代理提供非核心鏈路出口的服務便可。
公有云。我把公有云也做爲一種標準的基礎設施，雲由於其彈性能力確保了資源的獲取能力。公有云能夠完全的解放底層運維的依賴，讓研發均可以作運維，雖然看似資源成本高了一點，但它給你爭取的業務時間和運維成本呢？
二、應用環境標準化
這塊很是簡單，必定要對程序的應用部署環境作標準化約束。程序運行的屬主、程序運行的目錄甚至是配置文件的規範、log目錄等等。以前在【多玩 YY 事業部 軟件包 規範V0.1】中作過詳細的標準化規範約束，詳細目錄以下，供參考：
這塊對後續的工具建設要求有很大的影響，特別是發佈工具、自動發現工具等等。一個標準化的環境，讓後續的系統平臺複雜度會大大下降，由於你無需處理那麼多進程屬主的問題，你也不須要考慮程序運行目錄的問題，你可使用標準化的監控對應用進行監控，你能夠編寫腳本自動化發現服務器上運行的服務等等。若是配置文件是標準的狀況下，甚至能夠自動化生成業務拓撲等等。
所以我建議這個地方運維必定要創建一個標準規範，是真正的業務運維的根本。而讓研發或者運維規範的全部基礎就是生產環境必須嚴格控制在運維手中，不要讓研發接觸到生產環境，而且最後是平臺化，這樣還能夠進一步約束運維。
三、組件標準化
在任何一個業務架構中，都能抽離出須要的組件類型，好比說cache組件、數據庫mysql、文件存儲、web組件等等。這個地方必定須要一個標準化的選型，和服務器同樣。特別是對於大規模的研發組織來講，這個標準化就更重要，直接影響了運維的成本、研發的效率甚至是產品的質量。
在YY接觸過一個項目組，研發按照本身的喜愛，選擇了cassandra、mongodb、mysql、redis四種存儲，全部的好與很差，都是從本身的角度描述（忌諱啊），最後這個產品的結果是質量問題頻出、沒法快速迭代、運維還沒法管理。
現實中會常常碰到研發就會根據本身的喜愛來進行選型，怎麼辦？第1、運維須要客觀的說出會遇到的問題和風險；第2、我採用的方法就是交給研發本身運維，由於不在標準化運維體系以內，最後誰痛誰知道。
創建標準化的組件選型，就是讓業務技術架構到最後就如同搭積木同樣。
四、業務架構標準化
在統一的架構規範之下作研發約束比那些任意選擇架構的要好得多。但是在現實的狀況下，聽從統一的架構約束是多麼困難的事情。由於人的問題，到最後對架構的理解必然是不統一的，後果就是各出奇招，怎麼方便怎麼來，怎麼爽怎麼來。簡單來講，運維須要和研發設定一個標準化架構類型，讓你們統一遵照，見過有些研發寫的前端程序居然不能接入LVS作負載均衡，這明顯是無架構約束。有了統一的架構標準，目標是衝着架構的可運維性而去的，這個時候會反向對研發程序提出要求。此時運維能夠列出不少架構設計原則和要求，如負載均衡、動靜分離、讀寫分離、容災容錯等等，特別是基於前面提到的標準組件。
五、協議標準化
在一個小的業務系統中，能夠統一採用http協議，隨着架構的複雜度愈來愈高，架構會逐漸分離出接入層和邏輯層，那麼接入層和邏輯層之間的訪問也建議最好統一協議。基於統一的協議，後續的測試框架都很好實現；基於統一的協議，後續的運維管理、監控也很容易實現。
第二步：服務化
這一部分是對上面的組件化服務進一步昇華，也能夠把他理解成「架構及服務」。
當咱們對組件作了標準化的選型以後，服務能力會從過去的分佈式逐漸走向集中管理。就拿圖片存儲來講，以前各個團隊本身實現圖片存儲，用NFS、ftp的，最後運維推薦fastdfs（咱們如今用的是ssdb），但依然存在一個問題，每一個運維團隊都維護fastdfs仍是成本過高，特別是面向業務的一些應用場景須要作重複性開發，好比說圖片的多規格處理、圖片的壓縮等等。此時運維該驅動讓這類組件管理公共化，走向集中式，統一實現以上所提到的業務需求。再往前一步，作可視化管理，避免運維在操做系統中進行命令式管理，從而提升維護的效率和質量。
服務公共化以後，運維方面的能力變得更聚焦。以前每一個人都須要掌握的能力，後續能夠按照技術棧的要求來設置運維角色，最終能把面向業務的運維思路轉換到面向技術架構服務的運維思路上，作到和業務無關。這一點對於海量業務來講，很是重要，能夠大大減小運維成本和業務的可運維性。
當前在公有云IAAS或者PAAS，這塊實現得都很是的好。他們都把技術架構中涉及到的能力統一抽象成服務，提供api的形式供應用使用便可。好比說分佈式cache服務，在傳統的架構中，你們要麼使用mc或者redis，但到公有云平臺中，他們提供的分佈式cache服務，統一支持mc協議和redis協議，此時公有云不是提供mc或者redis服務組件。對於應用來講，服務能力是透明的，無物理感知的！
在我當前維護的負責業務線中，正推進業務正在往服務公共化轉型，好比說把小文件存儲接入到圖片雲系統、memcache
接入到浮雲系統、把mysql統一接入到mysql HA系統（已完成）、名字服務中心、httpDNS服務等等。基礎組件組還正在實現統一消息發佈訂閱服務，進一步解耦服務之間的調用關係；另一個研發小組正在構建統一的業務灰度發佈系統，進一步提升系統的灰度發佈能力。後續還讓頁面端的全部服務接入統一防攻擊的服務模塊中，進一步提升系統的應用層抗攻擊能力。
第三步：無狀態化
在服務公共化實現以後，此時貌似看到了一個完美的狀態，但事實是沒有完美。在業務量不斷上升、業務變得更加複雜的狀況下，技術架構不斷在變化，但此時須要有一個技術架構的運維標準---無狀態化。什麼是無狀態化？在服務訪問路徑中，某個節點（不管是物理的仍是邏輯的）異常，用戶感知到的服務都是可用的。對其進一步深刻解釋，物理的節點包含機房、機架、服務器、LVS等等；邏輯節點，好比說某個接口、某個進程或者端口等等；異常，最直接的理解就是不可用；服務可用，不管是服務容錯調度仍是服務降級，都須要作到對用戶來講是可用的。無狀態化，也能夠進一步細化成一些技術架構要求，好比說服務降級、柔性可用、服務雙中心、過載保護等等，根據不一樣的業務和服務，在這些能力維度上的要求會有些不一樣。
無狀態化對應用運維有了更進一步的精細化要求。首先須要運維對業務和服務進行重要性分級，對於那些核心的業務來講，最重要的就是雙中心的要求了，好比說基礎用戶服務類、支付類、基礎平臺類等等。對於核心的服務路徑，識別出來，作好容災容錯的識別，這個時候須要運維深刻了解業務，並結合技術來作綜合的判斷，遊離在業務以外，去設計技術架構是好笑的。
以前咱們針對核心業務和服務作了一次單點的梳理，從三個方面入手：單點梳理checklist（節點級）、物理部署和依賴的外部接口。但最後效果不是太好，我我的的總結是由於這塊人工梳理的成本過高，而且架構會變化，特別是規模很大的服務來講，這塊的梳理更是複雜。不過在這個地方，我保留一個想象力，隨着咱們的名字服務上線以後，服務之間的調度關係盡收眼底，咱們是否能夠搭建相似netflix的「Chaos Monkey」服務來測試咱們的服務可用性呢？
最近咱們也在某個核心業務上，運維和研發、測試、項目管理組一塊兒啓動了個雙中心的服務質量優化專項。咱們分紅了7個維度，如端到端監控、服務降級、數據雙中心分佈、客戶端智能路由、SDK異常處理、過載保護、跨機房流量轉發等等。基於這7個維度，咱們又分解了17個子項目跟蹤，差很少一個Q完成了整個工做，正在持續的演習驗證之中。通過此次的專項改造以後，你們都對本身的業務有了更充足的信心，再也不依賴機房、再也不依賴網絡、再也不依賴數據庫的底層同步、再也不依賴人的運維處理等等。
其實在這條主線上，應用運維有不少東西能夠作的，不只僅考驗運維在運維側的能力要求，同時也考驗運維在技術側的架構能力。是否感受運維無所不能？不是，我歷來沒這麼說過。我相反更提倡運維和研發、測試、產品更全力的合做，沒有一我的或者一個團隊能完成以上我說的一切；另外你們須要共享責任，不要囿於團隊的利益，把責任拋給別人，把利益留給本身，這是不利於以上事務的推動。
在三部走的路上，運維的能力是隨之成長的，業務的可運維性也是隨之提高的，提供給用戶的服務質量也是愈來愈好的。此時我想說：
是否是要值夜班？是，但咱們能夠改變。
是否是要不斷應對需求？是，但咱們能夠改變。
是否是就是一個服務器者和應用發佈者？是，但咱們能夠改變。
是否是要接受開發對咱們不懂技術的質疑？是，但咱們能夠改變。