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