[[145602]]

追求極致IT性能的運(yùn)維是精益運(yùn)維的高度體現(xiàn)!

　　在復(fù)雜的IT運(yùn)維組織事務(wù)活動(dòng)中，如何確定IT運(yùn)維的目標(biāo)，對(duì)于很多運(yùn)維組織來(lái)說(shuō)也是一個(gè)難點(diǎn)。有些運(yùn)維組織用的是穩(wěn)定性/可用性/質(zhì)量的指標(biāo)，有些團(tuán)隊(duì)用的是效率，有些團(tuán)隊(duì)用的成本指標(biāo)等等。說(shuō)實(shí)話，在以上諸多指標(biāo)中，能夠帶來(lái)巨大變革力和牽引力的，我個(gè)人認(rèn)為還是效率，或者是性能，就是完成某個(gè)事情有多快。但很多時(shí)候，需要對(duì)這個(gè)IT性能形成精確的理解，才能形成真正的作用力。

　　有人會(huì)說(shuō)，為什么運(yùn)維的核心目標(biāo)不是追求業(yè)務(wù)的穩(wěn)定性/可用性/質(zhì)量呢?我個(gè)人一直秉承的觀點(diǎn)，這些指標(biāo)根本不是運(yùn)維人的核心職責(zé)，而是開(kāi)發(fā)、 測(cè)試和運(yùn)維共同的核心職責(zé)。記得Jez Humble說(shuō)過(guò)，“測(cè)試者并不能增加產(chǎn)品的質(zhì)量，而只是讓質(zhì)量透明出來(lái)，更直接的說(shuō)測(cè)試是為了確認(rèn)軟件是否可部署”。而戴明在談質(zhì)量管理的時(shí)候，更是直 接了當(dāng)?shù)恼f(shuō)“停止事后檢驗(yàn)來(lái)達(dá)到高質(zhì)量的依賴，應(yīng)該在產(chǎn)品之初就開(kāi)始考慮質(zhì)量”。其實(shí)類(lèi)推到我們運(yùn)維過(guò)程也是同樣如此，軟件不能靠后期的運(yùn)維來(lái)達(dá)到業(yè)務(wù)的 高質(zhì)量，而更應(yīng)該把運(yùn)維作為早期軟件設(shè)計(jì)過(guò)程的一部分。

　　我們講要追求IT性能，這個(gè)也是來(lái)源早期的一個(gè)管理思想---精益思想。精益思想的五個(gè)原則所蘊(yùn)含的內(nèi)在核心就是“拒絕浪費(fèi)，創(chuàng)造價(jià)值”，從一開(kāi)始就要求從客戶的角度來(lái)定義產(chǎn)品價(jià)值(滿足某類(lèi)功能或者服務(wù)的需求)，通過(guò)這一價(jià)值的定義，再反向推導(dǎo)出內(nèi)部的價(jià)值活動(dòng)流，比如說(shuō)需求設(shè)計(jì)、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、軟件研發(fā)、測(cè)試、運(yùn)維等等。拉動(dòng)式價(jià)值的創(chuàng)造過(guò)程是一種讓客戶的價(jià)值訴求決定內(nèi)部活動(dòng)的價(jià)值創(chuàng)造，是一種精益式做法，是有目標(biāo)的行事。持續(xù)改進(jìn) 式到完美狀態(tài)，其實(shí)這個(gè)從軟件研發(fā)傳統(tǒng)的瀑布模型到敏捷模型，再到DevOps模型，目的都是讓軟件創(chuàng)作的多個(gè)職能組很好的銜接起來(lái)，而不產(chǎn)生停滯的狀 態(tài)。這個(gè)地方更需要提到的是持續(xù)集成，它是實(shí)現(xiàn)精益的一個(gè)有效手段，落地的最佳方式。這一思想的背后，無(wú)不透露著對(duì)性能、對(duì)質(zhì)量的極致要求，比如說(shuō)等待就 是一種精益思想所理解下的性能浪費(fèi)。

　　從軟件交付的角度來(lái)說(shuō)，運(yùn)維是離用戶最近的，那么運(yùn)維的IT性能和整個(gè)IT組織的性能息息相關(guān)，另外運(yùn)維要把IT性能要求反向傳導(dǎo)研發(fā)、測(cè)試過(guò)程，催其持續(xù)改進(jìn)。而對(duì)IT性能的核心的識(shí)別原則，就是從用戶的角度來(lái)設(shè)置指標(biāo)。其實(shí)本質(zhì)上來(lái)說(shuō)，IT性能的核心指標(biāo)是吞吐率和延時(shí)，但這兩個(gè)指標(biāo)需要和用戶價(jià)值流進(jìn)一步去關(guān)聯(lián)。進(jìn)一步分解，就可以形成如下的指標(biāo)體系：

　　（一）服務(wù)交付的延時(shí)

　　延時(shí)就是看完成一次服務(wù)交付要多長(zhǎng)時(shí)間。這個(gè)地方的場(chǎng)景就很多了，核心的就兩類(lèi)場(chǎng)景：

　　第一、持續(xù)的軟件新功能和新特性交付過(guò)程，應(yīng)用發(fā)布的過(guò)程，處理的粒度是應(yīng)用，和研發(fā)、測(cè)試過(guò)程密切相關(guān)。這個(gè)就是當(dāng)前持續(xù)集成思考的范疇。

　　第二、因?yàn)槿萘俊⒎?wù)搬遷等原因，面向用戶的整體服務(wù)的交付過(guò)程，比如說(shuō)用戶訪問(wèn)量增加，擴(kuò)容數(shù)據(jù)庫(kù)，擴(kuò)容前端，擴(kuò)容某個(gè)組件等等，這個(gè)聚焦在運(yùn)維內(nèi)部過(guò)程就可以了，無(wú)須軟件設(shè)計(jì)、軟件研發(fā)過(guò)程的接入，純運(yùn)維的輸出。以下就是一個(gè)完整的服務(wù)上線過(guò)程圖：　

　　（二）服務(wù)交付的頻率

　　頻率可以算是單位周期內(nèi)的交付能力。一個(gè)典型的場(chǎng)景就是每個(gè)月持續(xù)部署的數(shù)量，由此折算出交付的頻率怎么樣。以下是我們當(dāng)前游戲持續(xù)部署平臺(tái)的交付能力，有了平臺(tái)之后對(duì)人的依賴大大的降低，同時(shí)吞吐率大大提升。

　　而剛剛說(shuō)的整體服務(wù)交付過(guò)程，可以由自己的業(yè)務(wù)調(diào)度變更平臺(tái)輸出，這個(gè)地方重點(diǎn)關(guān)注批量作業(yè)的能力，比如說(shuō)一個(gè)變更單能擴(kuò)容多少臺(tái)，花費(fèi)時(shí)間多少?這種往往是用戶需求拉動(dòng)的，所以對(duì)他的頻率考察要求就不是太高了。

　　（三）故障恢復(fù)的延時(shí)

　　故障恢復(fù)的延時(shí)直接會(huì)影響服務(wù)的可用性，影響用戶對(duì)產(chǎn)品質(zhì)量的感知。服務(wù)恢復(fù)的越快，就說(shuō)明運(yùn)維故障處理能力越強(qiáng)。在進(jìn)一步細(xì)分故障處理能力的過(guò)程，可以分解成三個(gè)部分：故障發(fā)現(xiàn)、故障定位、故障處理與解決。這三部分都直接考察了運(yùn)維的能力，這三部分能力可以直接的映射到監(jiān)控系統(tǒng)上。故障發(fā)現(xiàn)是需要監(jiān)控系統(tǒng)要走向基于用戶的實(shí)時(shí)監(jiān)控上去；故障定位是需要監(jiān)控系統(tǒng)能夠打通基于用戶流的數(shù)據(jù)能力；故障處理是需要運(yùn)維人工的處理經(jīng)驗(yàn)沉淀，然后再自動(dòng) 化。

　　有了如上的核心指標(biāo)之后，那么我們就需要同步思考那些因素會(huì)影響IT性能，這些點(diǎn)就需要后續(xù)持續(xù)的改進(jìn)。個(gè)人也總結(jié)了一些自己看到的點(diǎn)：

　　（四）建立開(kāi)發(fā)與運(yùn)維之間的互信

　　開(kāi)發(fā)一定不要把運(yùn)維當(dāng)做一個(gè)簡(jiǎn)單的資源提供者角色來(lái)看待，需要準(zhǔn)確的看待運(yùn)維的價(jià)值。只有運(yùn)維才有能力從所有業(yè)務(wù)的角度出發(fā)，構(gòu)建統(tǒng)一的IT服務(wù)平臺(tái)提供給業(yè)務(wù)使用，對(duì)于公司來(lái)說(shuō)，也是一種降低浪費(fèi)的方式。開(kāi)發(fā)和運(yùn)維之間的互信、合作以及責(zé)任共享的團(tuán)隊(duì)氛圍是高性能運(yùn)維團(tuán)隊(duì)的基礎(chǔ)，缺少研發(fā)、測(cè)試的支持，運(yùn)維只能在低級(jí)層次上做服務(wù)封裝，而缺少對(duì)運(yùn)維的深層次理解。

　　（五）團(tuán)隊(duì)的多樣性

　　對(duì)于運(yùn)維團(tuán)隊(duì)來(lái)說(shuō)，首先需要保證運(yùn)維研發(fā)和運(yùn)維執(zhí)行者角色搭配，但需要有一種機(jī)制就是運(yùn)維執(zhí)行者需要不斷的把需求轉(zhuǎn)換到運(yùn)維研發(fā)團(tuán)隊(duì)，讓他提供平臺(tái)性的實(shí)現(xiàn)，甚至運(yùn)維執(zhí)行者自己也需要嘗試轉(zhuǎn)變，使自己具備運(yùn)維研發(fā)的能力。其次對(duì)于團(tuán)隊(duì)來(lái)說(shuō)，需要有個(gè)階梯性，都是運(yùn)維執(zhí)行不行，都是運(yùn)維研發(fā)也不行，都是運(yùn)維技術(shù)性高手也不行，需要有推動(dòng)能力強(qiáng)的，技術(shù)能力強(qiáng)的和運(yùn)維研發(fā)能力強(qiáng)的搭配等等；最后運(yùn)維團(tuán)隊(duì)需要有女性角色存在，當(dāng)然你不能把她當(dāng)男人使用，這樣你的團(tuán)隊(duì)就缺少了柔性。

　　（六）可視化運(yùn)維過(guò)程

　　我覺(jué)得沒(méi)有比可視化的要求更能驅(qū)動(dòng)運(yùn)維的過(guò)程。但你想著要可視化的時(shí)候，一定想著如何簡(jiǎn)化你的運(yùn)維過(guò)程，否則實(shí)現(xiàn)起來(lái)非常的繁瑣。可視化，是運(yùn)維把問(wèn)題化繁為簡(jiǎn)、把思路從模糊變清晰、把工具變產(chǎn)品的一個(gè)過(guò)程。

　　（七）持續(xù)交付(持續(xù)集成+持續(xù)部署)

　　這是敏捷業(yè)務(wù)形態(tài)下的標(biāo)配了，更是互聯(lián)網(wǎng)業(yè)務(wù)的一個(gè)標(biāo)配。但對(duì)于傳統(tǒng)業(yè)務(wù)來(lái)說(shuō)，實(shí)施持續(xù)交付貌似還有一點(diǎn)難度，很大一部分和服務(wù)耦合有關(guān)系。做互聯(lián)網(wǎng)不可能不知道Jenkins，不可能不知道持續(xù)部署。具體的最佳實(shí)踐請(qǐng)參照【持續(xù)集成】那本書(shū)，里面寫(xiě)了很多最佳的實(shí)踐標(biāo)準(zhǔn)。

　　（八）一鍵化調(diào)度平臺(tái)

　　通過(guò)該平臺(tái)來(lái)解決整體服務(wù)交付的能力問(wèn)題，一鍵化調(diào)度平臺(tái)需要打通所有的運(yùn)維內(nèi)部服務(wù)，把所依賴的運(yùn)維服務(wù)和技術(shù)架構(gòu)服務(wù)抽象成一個(gè)個(gè)API供其調(diào)用。此時(shí)需要對(duì)線上服務(wù)環(huán)境做一些標(biāo)準(zhǔn)化的約束，比如說(shuō)服務(wù)之間的調(diào)用抽象到名字服務(wù)中心，應(yīng)用環(huán)境對(duì)系統(tǒng)環(huán)境零依賴等。線上技術(shù)架構(gòu)的運(yùn)維管理應(yīng)該Api服務(wù)化，可以通過(guò)API來(lái)控制技術(shù)架構(gòu)中的服務(wù)，比如說(shuō)配置文件管理/組件服務(wù)管理/服務(wù)降級(jí)服務(wù)/服務(wù)過(guò)載保護(hù)設(shè)置等等。越API化，意味著機(jī)器能夠控制的能力越強(qiáng)，也就意味著運(yùn)維性能能力可以越高。

　　（九）端到端的監(jiān)控平臺(tái)

　　監(jiān)控在故障恢復(fù)延時(shí)中起到核心作用，需要化運(yùn)維被動(dòng)監(jiān)控變?yōu)橹鲃?dòng)監(jiān)控。從用戶的角度實(shí)現(xiàn)主動(dòng)式的監(jiān)控才是真正的監(jiān)控系統(tǒng)發(fā)現(xiàn)問(wèn)題的有效手段，而非傳統(tǒng)的監(jiān)控系統(tǒng)從系統(tǒng)內(nèi)部指標(biāo)看問(wèn)題。端到端，從用戶側(cè)到服務(wù)側(cè)，基于應(yīng)用的拓?fù)渫瓿烧麄€(gè)數(shù)據(jù)通路的構(gòu)建。

　　還有一個(gè)因素要特別注意，就是架構(gòu)的智能決策能力。在個(gè)人推動(dòng)SDK雙中心的時(shí)候，當(dāng)我們?cè)O(shè)定服務(wù)故障恢復(fù)時(shí)長(zhǎng)為8分鐘，發(fā)現(xiàn)真正的系統(tǒng)恢復(fù)能力不是靠人，而是讓后臺(tái)故障被前臺(tái)感知，從而讓前臺(tái)實(shí)現(xiàn)智能決策，屏蔽故障節(jié)點(diǎn)。這樣的例子比比皆是，mysql的故障由proxy來(lái)屏蔽決策；proxy的故障由名字服務(wù)來(lái)調(diào)度屏蔽；名字服務(wù)的故障實(shí)現(xiàn)高可用，不依賴中心節(jié)點(diǎn)；邏輯層故障也由名字服務(wù)中心來(lái)調(diào)度屏蔽；web層故障由負(fù)載均衡層調(diào)度屏蔽；負(fù)載均衡層故障由DNS或者h(yuǎn)ttpdns調(diào)度屏蔽。

　　IT性能，應(yīng)該成為運(yùn)維團(tuán)隊(duì)的核心驅(qū)動(dòng)力，它能夠直接反映運(yùn)維能力水平。運(yùn)維對(duì)IT性能的極致苛求，也直接反映了運(yùn)維團(tuán)隊(duì)自我價(jià)值要求，甚至也決定了運(yùn)維團(tuán)隊(duì)的能力建設(shè)。沒(méi)有IT性能最強(qiáng)的運(yùn)維團(tuán)隊(duì)，只有IT性能更強(qiáng)的運(yùn)維團(tuán)隊(duì)。它如同優(yōu)化線上的業(yè)務(wù)程序一樣，運(yùn)維團(tuán)隊(duì)的性能優(yōu)化也永遠(yuǎn)沒(méi)有終點(diǎn)。