追求極緻IT性能的運維是精益運維的高度體(tǐ)現！
在複雜(zá)的IT運維組織事務活動中(zhōng)，如何确定IT運維的目标，對于很多運維組織來說也是一(yī)個難點。有些運維組織用的是穩定性/可用性/質量的指标，有些團隊用的是效率，有些團隊用的成本指标等等。
說實話(huà)，在以上諸多指标中(zhōng)，能夠帶來巨大(dà)變革力和牽引力的，我(wǒ)個人認爲還是效率，或者是性能，也就是說，完成某個事情能有多快。當然很多時候，需要對這個IT性能形成精确的理解，才能形成真正的作用力。
有人會說，爲什麽運維的核心目标不是追求業務的穩定性/可用性/質量呢？
我(wǒ)個人一(yī)直秉承的觀點，這些指标根本不是運維人的核心職責，而是開(kāi)發、測試和運維共同的核心職責。
記得JezHumble說過，“測試者并不能增加産品的質量，而隻是讓質量透明出來，更直接的說測試是爲了确認軟件是否可部署”。而戴明在談質量管理的時候，更是直接了當的說“停止事後檢驗來達到高質量的依賴，應該在産品之初就開(kāi)始考慮質量”。
其實類推到我(wǒ)們運維過程也是同樣如此，軟件不能靠後期的運維來達到業務的高質量，而更應該把運維作爲早期軟件設計過程的一(yī)部分(fēn)。
我(wǒ)們講要追求IT性能，這個也是來源早期的一(yī)個管理思想—-精益思想。精益思想的五個原則所蘊含的内在核心就是“拒絕浪費(fèi)，創造價值”：
從一(yī)開(kāi)始就要求從客戶的角度來定義産品價值（滿足某類功能或者服務的需求），通過這一(yī)價值的定義，再反向推導出内部的價值活動流，比如說需求設計、概要設計、詳細設計、軟件研發、測試、運維等等。
拉動式價值的創造過程是一(yī)種讓客戶的價值訴求決定内部活動的價值創造，是一(yī)種精益式做法，是有目标的行事。持續改進直到完美狀态。其實這個從軟件研發傳統的瀑布模型到敏捷模型，再到DevOps模型，目的都是讓軟件創作的多個職能組很好的銜接起來，而不産生(shēng)停滞的狀态。
這個地方更需要提到的是持續集成，它是實現精益的一(yī)個有效手段，落地的最佳方式。這一(yī)思想的背後，無不透露着對性能、對質量的極緻要求，比如說等待就是一(yī)種精益思想所理解下(xià)的性能浪費(fèi)。
從軟件交付的角度來說，運維是離(lí)用戶最近的，那麽運維的IT性能和整個IT組織的性能息息相關，另外(wài)運維要把IT性能要求反向傳導對研發、測試過程，催其持續改進。而對IT性能的核心的識别原則，就是從用戶的角度來設置指标。
其實本質上來說，IT性能的核心指标是吞吐率和延時，但這兩個指标需要和用戶價值流進一(yī)步去(qù)關聯。進一(yī)步分(fēn)解，就可以形成如下(xià)的指标體(tǐ)系：
服務交付的延時
延時就是看完成一(yī)次服務交付要多長時間。這個地方的場景就很多了，核心的就兩類場景：
持續的軟件新功能和新特性交付過程，應用發布的過程，處理的粒度是應用，和研發、測試過程密切相關。這個就是當前持續集成思考的範疇。
因爲容量、服務搬遷等原因，面向用戶的整體(tǐ)服務的交付過程，比如說用戶訪問量增加，擴容數據庫，擴容前端，擴容某個組件等等，這個聚焦在運維内部過程就可以了，無須軟件設計、軟件研發過程的接入，這是一(yī)種純運維的輸出。以下(xià)就是一(yī)個完整的服務上線過程圖：
服務交付的頻(pín)率
頻(pín)率可以算是單位周期内的交付能力。一(yī)個典型的場景就是每個月持續部署的數量，由此折算出交付的頻(pín)率怎麽樣。以下(xià)是我(wǒ)們當前遊戲持續部署平台的交付能力，有了平台之後對人的依賴大(dà)大(dà)的降低，同時吞吐率大(dà)大(dà)提升。
而剛剛說的整體(tǐ)服務交付過程，可以由自己的業務調度變更平台輸出，這個地方重點關注批量作業的能力，比如說一(yī)個變更單能擴容多少台，花費(fèi)時間多少？這種往往是用戶需求拉動的，所以對他的頻(pín)率考察要求就不是太高了。
故障恢複的延時
故障恢複的延時直接會影響服務的可用性，影響用戶對産品質量的感知(zhī)。服務恢複的越快，就說明運維故障處理能力越強。
在進一(yī)步細分(fēn)故障處理能力的過程，可以分(fēn)解成三個部分(fēn)：故障發現、故障定位、故障處理與解決。這三部分(fēn)都直接考察了運維的能力，這三部分(fēn)能力可以直接的映射到監控系統上：
故障發現是需要監控系統要走向基于用戶的實時監控上去(qù)；
故障定位是需要監控系統能夠打通基于用戶流的數據能力；
故障處理是需要運維人工(gōng)的處理經驗沉澱，然後再自動化。
有了如上的核心指标之後，那麽我(wǒ)們就需要同步思考那些因素會影響IT性能，這些點就需要後續持續的改進。個人也總結了一(yī)些自己看到的點：
建立開(kāi)發與運維之間的互信開(kāi)發一(yī)定不要把運維當做一(yī)個簡單的資(zī)源提供者角色來看待，需要準确的看待運維的價值。隻有運維才有能力從所有業務的角度出發，構建統一(yī)的IT服務平台提供給業務使用，對于公司來說，也是一(yī)種降低浪費(fèi)的方式。開(kāi)發和運維之間的互信、合作以及責任共享的團隊氛圍是高性能運維團隊的基礎，缺少研發、測試的支持，運維隻能在低級層次上做服務封裝，而缺少對運維的深層次理解。
團隊的多樣性對于運維團隊來說，首先需要保證運維研發和運維執行者角色搭配，但需要有一(yī)種機制就是運維執行者需要不斷的把需求轉換到運維研發團隊，讓他提供平台性的實現，甚至運維執行者自己也需要嘗試轉變，使自己具備運維研發的能力。其次對于團隊來說，需要有個階梯性，都是運維執行者不行，都是運維研發也不行，都是運維技術高手也不行，需要有推動能力強的，技術能力強的和運維研發能力強的搭配等等；最後運維團隊需要有女性角色存在，當然你不能把她當男人使用，這樣你的團隊就缺少了柔性。
可視化運維過程我(wǒ)覺得沒有比可視化的要求更能驅動運維的過程。但你想着要可視化的時候，一(yī)定想着如何簡化你的運維過程，否則實現起來非常的繁瑣。可視化，是運維把問題化繁爲簡、把思路從模糊變清晰、把工(gōng)具變産品的一(yī)個過程。
持續交付（持續集成+持續部署）這是敏捷業務形态下(xià)的标配了，更是互聯網業務的一(yī)個标配。但對于傳統業務來說，實施持續交付貌似還有一(yī)點難度，很大(dà)一(yī)部分(fēn)和服務耦合有關系。做互聯網不可能不知(zhī)道Jenkins，不可能不知(zhī)道持續部署。具體(tǐ)的最佳實踐請參照【持續集成】那本書(shū)，裏面寫了很多最佳的實踐标準。
一(yī)鍵化調度平台通過該平台來解決整體(tǐ)服務交付的能力問題。一(yī)鍵化調度平台需要打通所有的運維内部服務，把所依賴的運維服務和技術架構服務抽象成一(yī)個個API供其調用。此時需要對線上服務環境做一(yī)些标準化的約束，比如說服務之間的調用抽象到名字服務中(zhōng)心，應用環境對系統環境零依賴等。線上技術架構的運維管理應該Api服務化，可以通過API來控制技術架構中(zhōng)的服務，比如說配置文件管理／組件服務管理／服務降級服務／服務過載保護設置等等。越API化，意味着機器能夠控制的能力越強，也就意味着運維性能能力可以越高。
端到端的監控平台監控在故障恢複延時中(zhōng)起到核心作用，需要将運維被動監控變爲主動監控。從用戶的角度實現主動式的監控才是真正的監控系統發現問題的有效手段，而非傳統的監控系統從系統内部指标看問題。端到端，從用戶側到服務側，基于應用的拓撲完成整個數據通路的構建。
還有一(yī)個因素要特别注意，就是架構的智能決策能力。
在我(wǒ)個人推動SDK雙中(zhōng)心的時候，當我(wǒ)們設定服務故障恢複時長爲8分(fēn)鍾，發現真正的系統恢複能力不是靠人，而是讓後台故障被前台感知(zhī)，從而讓前台實現智能決策，屏蔽故障節點。這樣的例子比比皆是：
mysql的故障由proxy來屏蔽決策；
proxy的故障由名字服務來調度屏蔽；
名字服務的故障實現高可用，不依賴中(zhōng)心節點；
邏輯層故障也由名字服務中(zhōng)心來調度屏蔽；
web層故障由負載均衡層調度屏蔽；
負載均衡層故障由DNS或者httpdns調度屏蔽。
IT性能，應該成爲運維團隊的核心驅動力，它能夠直接反映運維能力水平。運維對IT性能的極緻苛求，也直接反映了運維團隊自我(wǒ)價值要求，甚至也決定了運維團隊的能力建設。
沒有IT性能最強的運維團隊，隻有IT性能更強的運維團隊。它如同優化線上的業務程序一(yī)樣，運維團隊的性能優化也永遠沒有終點。
