應用運維三部曲，就是告訴你應用運維就該這么干！
在日常的工作中，應用運維是否覺得自己很苦逼。比如說：
是不是要值夜班？是
是不是要不斷應對需求？是
是不是就是一個服務器者和應用發布者？是
是不是要接受開發對我們不懂技術的質疑？是
曾經有個研發想轉運維，問是否要值夜班，如果是夜班的話，我就不轉了。其實還真說明了一個事實，你做得好研發，還真不一定能做好運維哈。
那我們一起來探討一下如何做好應用運維，徹底改變以上大家對你錯誤的定位和認知，我把它稱之為運維三部曲：
在任何一個互聯網的企業中，遵循這三部走策略，一定可以把應用運維有條理的做好（傳統企業不敢說）。另外輔助工具化和數據化的運維平台支撐，應用運維就如虎添翼，會大大影響三部走的進程。但在本篇文章不去談自動化和數據化運維如何做，主要是談標准化、服務化和無狀態化三步走的應用運維路徑，看是如何實現，且一步一步的影響應用運維的，也可以看出對應用運維的一些要求。以下是其詳要的論述：
第一步：標准化
標准化是應用運維強勢走出運維，面向研發的第一步。一個應用運維，如果沒有把標准化理解到位，我覺得是不合格的，會給后續的運維帶來很多問題，包括成本的上升、價值的體現等等。那標准化運維到底包含哪些？我覺得可以小到一個進程的運行屬主，也可以大到系統架構或者機房部署架構等等。此時照樣可以用分層體系來進行細分，識別標准化運維到底要做什么？
1、基礎設施標准化
和應用相關的有服務器、虛擬化、OS、機房部署、公有雲等等。
服務器可以按照自己的服務類型選擇幾個標准類型，比如說CPU計算性（內存可以小一些）、內存性（把內存加大）、數據庫型三種。在涉及到hadoop運算的企業中，可以配置多硬盤的服務器，比如說內置12塊1T no raid的硬盤機器。這種標准化選型沒有壞處，特別是規模越來越大的時候，會逐漸看到這種標准化帶來的好處。第一、變更成本不斷降低。硬件垂直擴展的方式，在規模下運維無法應對；第二、對業務架構形成反向的推動力，根據機型分布自己的服務組件。
虛擬化。並不是每家公司都可以玩得起IAAS雲，特別是基於Openstack，要投入大量研發和運維資源，但是對於任何公司來說，無論大與小，都可以采用虛擬化的技術。無論是操作系統級別的Kvm、Esxi和Xen，還是輕量級虛擬化Docker，都值得去嘗試使用。虛擬化可以解決資源復用問題，突破OS的資源限制（比如說文件句柄）、資源收縮或回收等等，在web類的服務中，更需要去嘗試。前期不導入的話，在后期隨着業務規模越來越大的時候，虛擬化的導入難度會增加。
OS。在OS層面上，其實就是選擇好你的操作系統和內核版本，不要任意的選型，也不要太相信操作系統版本更新帶來的優化效果。注意別用32位的操作系統即可。其他的優化更多的交給應用優化好了，帶來的效果更好、成本更低。
機房部署。這個要結合業務來看，選擇幾個穩定的機房就好了（一般都是兩個）。之前在一家公司，網站類的服務分布在多個機房中，維護非常麻煩，任何一個機房的故障都會有業務的影響，最后全部收攏到兩個機房中，運維復雜度大大降低。核心業務做雙機房部署，非核心機房單機房部署，通過代理提供非核心鏈路出口的服務即可。
公有雲。我把公有雲也作為一種標准的基礎設施，雲因為其彈性能力確保了資源的獲取能力。公有雲可以徹底的解放底層運維的依賴，讓研發都可以做運維，雖然看似資源成本高了一點，但它給你爭取的業務時間和運維成本呢？
2、應用環境標准化
這塊非常簡單，一定要對程序的應用部署環境做標准化約束。程序運行的屬主、程序運行的目錄甚至是配置文件的規范、log目錄等等。之前在【多玩 YY 事業部 軟件包 規范V0.1】中做過詳細的標准化規范約束，詳細目錄如下，供參考：
這塊對后續的工具建設要求有很大的影響，特別是發布工具、自動發現工具等等。一個標准化的環境，讓后續的系統平台復雜度會大大降低，因為你無需處理那么多進程屬主的問題，你也不需要考慮程序運行目錄的問題，你可以使用標准化的監控對應用進行監控，你可以編寫腳本自動化發現服務器上運行的服務等等。如果配置文件是標准的情況下，甚至可以自動化生成業務拓撲等等。
因此我建議這個地方運維一定要建立一個標准規范，是真正的業務運維的根本。而讓研發或者運維規范的所有基礎就是生產環境必須嚴格控制在運維手中，不要讓研發接觸到生產環境，並且最后是平台化，這樣還可以進一步約束運維。
3、組件標准化
在任何一個業務架構中，都能抽離出需要的組件類型，比如說cache組件、數據庫mysql、文件存儲、web組件等等。這個地方一定需要一個標准化的選型，和服務器一樣。特別是對於大規模的研發組織來說，這個標准化就更重要，直接影響了運維的成本、研發的效率甚至是產品的質量。
在YY接觸過一個項目組，研發按照自己的喜好，選擇了cassandra、mongodb、mysql、redis四種存儲，所有的好與不好，都是從自己的角度描述（忌諱啊），最后這個產品的結果是質量問題頻出、無法快速迭代、運維還無法管理。
現實中會經常碰到研發就會根據自己的喜好來進行選型，怎么辦？第一、運維需要客觀的說出會遇到的問題和風險；第二、我采用的方法就是交給研發自己運維，因為不在標准化運維體系之內，最后誰痛誰知道。
建立標准化的組件選型，就是讓業務技術架構到最后就如同搭積木一樣。
4、業務架構標准化
在統一的架構規范之下做研發約束比那些任意選擇架構的要好得多。可是在現實的情況下，遵從統一的架構約束是多么困難的事情。因為人的問題，到最后對架構的理解必然是不統一的，后果就是各出奇招，怎么方便怎么來，怎么爽怎么來。簡單來說，運維需要和研發設定一個標准化架構類型，讓大家統一遵守，見過有些研發寫的前端程序竟然不能接入LVS做負載均衡，這明顯是無架構約束。有了統一的架構標准，目標是沖着架構的可運維性而去的，這個時候會反向對研發程序提出要求。此時運維可以列出很多架構設計原則和要求，如負載均衡、動靜分離、讀寫分離、容災容錯等等，特別是基於前面提到的標准組件。
5、協議標准化
在一個小的業務系統中，可以統一采用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完成了整個工作，正在持續的演習驗證之中。經過這次的專項改造之后，大家都對自己的業務有了更充足的信心，不再依賴機房、不再依賴網絡、不再依賴數據庫的底層同步、不再依賴人的運維處理等等。
其實在這條主線上，應用運維有很多東西可以做的，不僅僅考驗運維在運維側的能力要求，同時也考驗運維在技術側的架構能力。是否感覺運維無所不能？不是，我從來沒這么說過。我相反更提倡運維和研發、測試、產品更全力的合作，沒有一個人或者一個團隊能完成以上我說的一切；另外大家需要共享責任，不要囿於團隊的利益，把責任拋給別人，把利益留給自己，這是不利於以上事務的推進。
在三部走的路上，運維的能力是隨之成長的，業務的可運維性也是隨之提升的，提供給用戶的服務質量也是越來越好的。此時我想說：
是不是要值夜班？是，但我們可以改變。
是不是要不斷應對需求？是，但我們可以改變。
是不是就是一個服務器者和應用發布者？是，但我們可以改變。
是不是要接受開發對我們不懂技術的質疑？是，但我們可以改變。