理想總是要有的，萬一實現(xiàn)了呢，理想有多大，我們就能一起走多遠。在實現(xiàn)理想自由的道路上，我們描繪藍圖踏出探索道路的第一步，未來不是夢，即使是夢我們也要窮極一生做完這場夢。

[[213390]]

運維密室

密室的墻壁與鎖

順豐的技術(shù)運維部門自 2007 年成立以來，伴隨物流行業(yè)飛速的發(fā)展，其運維的規(guī)模也是一路狂奔，到 2016 年技術(shù)運維團隊已經(jīng)衍變成近 200 人的大隊伍。

為了建立專業(yè)技術(shù)能力，自 2013 年伊始經(jīng)過 3 年的建設(shè)，技術(shù)運維團隊組織架構(gòu)和職能逐漸穩(wěn)定成型：

• 從底層基礎(chǔ)設(shè)施到網(wǎng)絡(luò)、存儲、服務(wù)器、操作系統(tǒng)、數(shù)據(jù)庫以及中間件，每個專業(yè)領(lǐng)域都由專業(yè)條線團隊負責(zé)，其工作職能包括專業(yè)條線的規(guī)劃、設(shè)計、建設(shè)、實施以及日常運維。
• 對外交付由基礎(chǔ)架構(gòu)師團隊統(tǒng)籌，工作模式為流程驅(qū)動，通過工單系統(tǒng)來進行推進和跟蹤。
• 部門的制度、流程和質(zhì)量由運維規(guī)劃團隊負責(zé)，來拉通和彌補技術(shù)團隊管理方面的先天弱點。
• 整個技術(shù)運維隊伍以 ITIL 體系作為基礎(chǔ)指導(dǎo)。
• 基礎(chǔ)技術(shù)軟件在 2015 年已經(jīng)實現(xiàn)全開源。

通過專業(yè)化的組織分工，我們培養(yǎng)了很多專業(yè)領(lǐng)域人才，具備了一定的技術(shù)能力，同時也系統(tǒng)性的形成了適合物流行業(yè)業(yè)務(wù)形態(tài)的基礎(chǔ)設(shè)施建設(shè)標準、設(shè)備引入和使用標準、基礎(chǔ)軟件使用標準和架構(gòu)標準。

受益于這些變化，我們的資源使用效率變得更加合理，系統(tǒng)穩(wěn)定性也逐年出現(xiàn)顯著的提升。

經(jīng)歷了 3 年的治理，隊伍組織架構(gòu)、職能和技術(shù)棧進入到了相對穩(wěn)定的狀態(tài)，但新的問題也逐漸浮出水面：

• 運維團隊都背負系統(tǒng)可用性的 KPI，并最終分解到各專業(yè)團隊，在這種評價模式下逐漸出現(xiàn)了責(zé)任氛圍。

由于變更永遠伴隨著風(fēng)險，本著少做少錯的想法，團隊與團隊之間多多少少都存在關(guān)節(jié)部位工作的推諉現(xiàn)象，全時順暢無間的協(xié)作成為一種奢望。

不幸的是，煙囪式的垂直專業(yè)分工團隊，對于協(xié)作的要求是遠遠高于水平分工團隊。

• 出于信息安全考慮，各種系統(tǒng)和應(yīng)用權(quán)限被嚴格切割，很多日常運維工作都出現(xiàn)上層工作人員等待下層依賴團隊授權(quán)或者代執(zhí)行場景。
• 當(dāng)初的專業(yè)分工，讓大家的技術(shù)能力棧出現(xiàn)萎縮，形成技術(shù)能力熱點。稍微綜合一點的專業(yè)技術(shù)問題，研發(fā)和運營人員就需要找對應(yīng)的專業(yè)技術(shù)人員協(xié)助，經(jīng)?？梢钥吹睫k公室里面我們的某個 DBA 或者中間件管理員被一票人圍住分析問題。

而對于技術(shù)運維隊伍自身，各團隊不約而同步入到一個瓶頸，整體的發(fā)展和成長被嚴重束縛，而大部分人在自己的微觀世界中并未覺察。

視野天花板，每個團隊在工作中接收到的信息都是經(jīng)過專業(yè)分層過濾的，只能在不完整信息的基礎(chǔ)上進行分析、判斷等工作。

能力碎片化，沒有一個團隊有全棧運維能力，也沒有一個團隊能夠俯瞰完整技術(shù)運維領(lǐng)域的工作。

密室外的風(fēng)暴

當(dāng)我們的運維人在密室的微世界中以自有節(jié)奏前行，怡然自得時，外面的大世界已經(jīng)在急劇的變化中，現(xiàn)實是怎么樣的呢？

業(yè)務(wù)方面：

• 業(yè)務(wù)流量峰值是一年比一年高，尤其是每年的雙十一。
• 業(yè)務(wù)形態(tài)越來越多，以前更多可能是我們自己企業(yè)內(nèi)部用戶在用的各種系統(tǒng)；現(xiàn)在出現(xiàn)各種面向直接的 C 端和 B 端的用戶。
• 為了適應(yīng)市場的變化，業(yè)務(wù)的調(diào)整也日趨頻繁，傳遞到技術(shù)運維端體現(xiàn)為更加頻繁的版本和變更。

技術(shù)方面：

• 云技術(shù)的成熟減少了企業(yè)對于自建技術(shù)運維團隊的需求，市場需求這個池塘在逐漸干涸，而池塘中的很多魚兒還沒有感應(yīng)到變化。
• 技術(shù)的全面開源和快速的演進讓很多傳統(tǒng)商用技術(shù)專業(yè)成為雞肋，工程師挾一技之長吃到底基本不可能，來不及在池塘干涸前完成進化的職場魚兒們可能會被提前淘汰。
• DevOps 的風(fēng)行為運維開辟了另外一條更有效地路線，反過來也對現(xiàn)有運維人提出了新的素質(zhì)要求，運維人需要有研發(fā)能力且能夠應(yīng)用這種能力來提高運維的效率和質(zhì)量。

密室之內(nèi)斜風(fēng)細雨，密室之外風(fēng)暴已至，不能做風(fēng)干的魚，順豐運維人再一次的將自己置于審判席上。

運維審判日

我們對 IT 運維工作做了四象限分解（如下圖所示），從價值角度來看，理想情況是技術(shù)運維隊伍需要將更多的資源投入在右邊的象限上。

而實際的情況是我們近七成精力都消耗在左邊象限內(nèi)的基礎(chǔ)日常工作上，不停的做各類布朗運動。

基于對運維工作的四象限分解后的反思，我們總結(jié)了運維五宗罪：

笨重的熟練

三年的專業(yè)化和標準化道路走下來，我們的工程師對于平時常規(guī)的工作已經(jīng)非常嫻熟，新一天的工作變成 n+1 的重復(fù)而已；工程師敲鍵盤的手越來越快，腦袋卻逐漸麻木，逐漸失去在工作中獨立思考的能力。

被降維的工作效率

很多日常 IT 運維交付工作真正完成只需要幾分鐘，但是從用戶需求提出到層層審核，一直到交到用戶手中可能需要好幾天。

低效這種大團隊的通病在煙囪式的垂直專業(yè)分工團隊會隨著依賴團隊個數(shù)進一步放大，留下用戶在一旁苦不堪言。透過現(xiàn)象看本質(zhì)，事實是時間都花在了溝通和等待上。

內(nèi)視的黑洞

在企業(yè) IT 團隊中，從技術(shù)的維度看，技術(shù)運維團隊往往有專業(yè)的技術(shù)能力，但從業(yè)務(wù)價值鏈看，技術(shù)運維團隊又處于價值鏈的末端。

從完整工作流來看，技術(shù)運維團隊往往是最后一環(huán)，并不是站在 IT 大軍的最前線。

在價值認知的錯位，信息隔離的情況下，如果沒有完全的理性和足夠的前線信息，技術(shù)運維人會形成種種負面自我，聚集成內(nèi)視的黑洞。

自制的鎖鏈

當(dāng)初伴隨公司的成長，部門為了管理系統(tǒng)化、正規(guī)化而建立了 KPI、規(guī)范、流程、標準、預(yù)算、成本、編制等各種制度。

它們的出現(xiàn)就是為了讓運維工作變得有序、有計劃、有規(guī)劃，而且初期都起到了較好的效果。

但是在某些情況下，這些制度將會展現(xiàn)暗黑的一面，成為組織的枷鎖和束縛，例如:

• 制度和流程被過度執(zhí)行，無視人的能動性，所有的人都被制度和流程牽著走，團隊的創(chuàng)造性被閹割。
• 制度和流程所指導(dǎo)和約束的事物本身一直在變化中，但制度和流程跟不上變化的節(jié)奏，最終變成工作的負擔(dān)和腐朽的鎖鏈。
• 重視管理者的需求，忽視用戶和前線的呼聲，遺忘制度和流程建立的初衷，制度和流程最終變成皇帝的新衣。

自動化短板

IT 運維隊伍走到一定的能力水平和規(guī)模，都會開啟運維工作自動化建設(shè)的階段，且開始都會被賦予解決種種問題的美好預(yù)期。

而往往 IT 運維隊伍發(fā)起的自動化工作更優(yōu)先解決的是運維團隊自身的問題，不一定優(yōu)先站在用戶的角度考慮。

我們在 2015 年下半年到 2016 年上半年開始運維自動化；本來預(yù)期可以節(jié)省人力并提高效率和質(zhì)量，但是結(jié)果卻不盡人意。

自動化的任務(wù)結(jié)束了，整體交付效率并未出現(xiàn)質(zhì)的變化，用戶也沒有變得滿意。

回顧原因的時候終于明白我們都是做的執(zhí)行末端的自動化，即將以前手工執(zhí)行工作自動化了，解決了運維執(zhí)行人員自己的問題，但并沒有解決這個交付工作流效率低下的問題。

因為一個用戶需求從提出到評審，到變更，最終反饋給用戶,這個過程非常漫長。很多人做的自動化只是把自己的執(zhí)行工作自動化了，用戶感覺不到任何改善。

運維的夢想

經(jīng)過一系列的反思和自我審判，我們看到技術(shù)運維團隊肌體未老先衰。

總結(jié)如下：

• 失去創(chuàng)造力，所做工作限于維持現(xiàn)有技術(shù)和架構(gòu)特征類型系統(tǒng)的可用性，未能系統(tǒng)性展開前瞻性整體技術(shù)能力建設(shè)工作以支撐公司未來發(fā)展對于IT底盤技術(shù)的要求。
• 視野萎縮，所做規(guī)劃和設(shè)計工作關(guān)注于自身痛點，無法從公司業(yè)務(wù)發(fā)展對IT底盤能力的廣度和縱深進行有效展開。
• 日漸官僚，流程等規(guī)則制度成為擋箭牌和隔音墻，團隊暮氣重重，不再能夠為前線需要技術(shù)炮火的時候提供有效支撐。
• 坐而論道，關(guān)注技術(shù)本身而疏于價值貢獻，無法掛鉤和跟進公司技術(shù)戰(zhàn)略。

總結(jié)至此，感覺技術(shù)運維團隊已是寒山夜雨，千山暮雪，如何打破身與心的牢籠，實現(xiàn)自我救贖？

經(jīng)過多輪的思索和頭腦碰撞之后，我們認為技術(shù)運維工作的理想情形當(dāng)為：

• 工作信息必須是流通和共享的，信息是在考慮了安全和工作職責(zé)的基礎(chǔ)上對原始數(shù)據(jù)過濾后的結(jié)果，技術(shù)運維人員能夠看到工作所需的所有信息，技術(shù)運維和被服務(wù)對象都在同一個信息平面上溝通和協(xié)同。
• 交付類工作應(yīng)該是基于全流程端到端自動化的，即自助的。用戶需要什么交付不再需要提前溝通后發(fā)起流程，而是直接在終端工作界面上即可獲取。其自助獲取資源在各方面的合規(guī)性由系統(tǒng)植入規(guī)則引擎來保障。
• 關(guān)鍵專業(yè)技術(shù)能力服務(wù)化，實現(xiàn)跨部門工作能力依賴解耦。涉及對專業(yè)技術(shù)細分領(lǐng)域的依賴型工作，由技術(shù)運維方以終端工作臺的形式提供，需求方可以自助使用，無須需求方提服務(wù)流程和排隊等待。
• 常規(guī)事件和異常實現(xiàn)自反應(yīng)和自愈，讓運維工作變得相對智能，在提高系統(tǒng)可用性的同時達成工作減負、降低成本的目的。

籌謀

方向已經(jīng)清晰，目標就在彼岸，如果到達呢？更謹慎的執(zhí)行、更負責(zé)任的態(tài)度、更細顆粒度的管理都解決不了問題，唯有突破現(xiàn)有思維模式，基于現(xiàn)狀而不限于現(xiàn)狀才有出路。

我們決定從如下六個方面進行突破：

• 重新定義對專業(yè)技術(shù)能力的要求，技術(shù)運維人員需要在熟練或精通基礎(chǔ)軟件應(yīng)用的基礎(chǔ)上，需要具備新技術(shù)研究和引入的能力或者運維研發(fā)能力。
• 專業(yè)技術(shù)支撐團隊有責(zé)任通過系統(tǒng)化的方式提供便捷的自助渠道，實現(xiàn)和關(guān)聯(lián)依賴團隊的能力解耦。
• 業(yè)務(wù)為先，在工具平臺打通之前，從現(xiàn)有專業(yè)團隊抽調(diào)精干力量，組成全棧技術(shù)能力運維團隊，支持敏捷產(chǎn)品團隊的運維支持工作。
• 不降低運維質(zhì)量的要求，原有 ITIL 的管控環(huán)節(jié)抽象成規(guī)則邏輯，植入工具平臺。
• 所有自動化工作秉承端到端的用戶思維，讓用戶能夠自助式的享受服務(wù)，原有流程環(huán)節(jié)，通過規(guī)則引擎植入運維系統(tǒng)，對用戶透明。
• 持久化內(nèi)容存儲必須是可編程的，可扁平技術(shù)架構(gòu)，降低工作依賴層級，同時也可進一步讓 IT 設(shè)備統(tǒng)一 X86 化。

經(jīng)過全面的考量之后，我們啟動了下面五個任務(wù)：

• 豐箱：容器自動自助的可視化管理平臺，實現(xiàn)容器在順豐技術(shù)架構(gòu)標準規(guī)則下的自動創(chuàng)建和擴容即日常維護，同時實現(xiàn)和應(yīng)用發(fā)布流程的無縫對接。
• 豐云：KVM 集群自動自助的可視化管理平臺，優(yōu)先實現(xiàn) KVM 虛機在順豐技術(shù)架構(gòu)標準規(guī)則下的自動創(chuàng)建和擴容即日常維護，最終實現(xiàn)和應(yīng)用發(fā)布流程的無縫對接。
• 維石：順豐技術(shù)自動化運維的大腦，是運維信息流通和運維規(guī)則自動應(yīng)用的核心，是最終面對用戶的終端自助工作臺提供方。
• ThinkDB：基于 X86 的高可用的數(shù)據(jù)庫池管理系統(tǒng)，其承擔(dān)了解除高容量高性能 DB 對 SAN 存儲依賴的使命，同時進一步提高 DB 的可用性和數(shù)據(jù)庫運維工作的簡易性。
• OSS：文件型對象可編程存儲系統(tǒng)，目的是對文件型存儲可編程化，解除對 NAS 的需求，讓這類型的所有運維規(guī)則和數(shù)據(jù)能夠回歸線上。

對于其中的主干任務(wù)維石，任務(wù)組在年初制訂了非常完美的計劃（如下圖所示），計劃在 2017 年 4 月初把資源交付做到自助，到 7 月份就轉(zhuǎn)入優(yōu)化階段。

碰壁

在美好愿景的驅(qū)動下，我們從原有專業(yè)組抽調(diào)了部分力量組成需求團隊，研發(fā)實現(xiàn)團隊主要是沒有做過運維工作的 Java 工程師，然后大家熱火朝天的開干了，不想剛邁開步子即踏入煉獄，進入到為期兩個月的無盡循環(huán)。

• 需求泛濫，每個專業(yè)組需求很多，即使這些需求不在任務(wù)主目標的關(guān)鍵路徑之上，也都想把自己的痛點扔給項目團隊并被優(yōu)先解決。
• 需求理解偏差大，運維不懂研發(fā)，研發(fā)不知運維，需求和實現(xiàn)團隊始終無法就需求規(guī)格說明達成一致以展開工作。
• 任務(wù)管理方法運用不當(dāng)，邯鄲學(xué)步，一開始就希望用我們本來就不太熟練的產(chǎn)品和敏捷方法來進行管理，結(jié)果成了東施效顰、徒具形式而已。
• 越俎代庖和用力過度，由于之前沒有做個綜合型研發(fā)項目，基礎(chǔ)的職責(zé)沒有厘清，大家憑熱情和喜好做事，工作無法有效展開。
• 紙上談兵，大家會議上講的內(nèi)容和計劃的完全不一樣；會后反應(yīng)的也不一樣，言行背離。

如此種種不順，兩個月下來，參與這個任務(wù)的同事們，不管是做需求的還是做架構(gòu)的，大家天天指責(zé)對方而沒有結(jié)果，疲憊且痛苦著。傳統(tǒng)運維轉(zhuǎn)運維研發(fā)的艱辛，遠遠超出了當(dāng)初的預(yù)期。

陸陸續(xù)續(xù)的，有成員開始放棄，平臺和前端研發(fā)有人離開了，產(chǎn)品經(jīng)理也不玩了，架構(gòu)師也跑路了。

面壁

痛定思痛，關(guān)鍵人員集體面壁，對任務(wù)進行回顧和反思，最終制定了如下的五條規(guī)則：

• 規(guī)范需求，堅持價值導(dǎo)向。需求很多沒有問題，但需要排隊，優(yōu)先級上還要看這些需求本身的價值和在關(guān)鍵路徑上是否是核心依賴。
• 拉近認知，讓運維的需求方和研發(fā)一起背靠背做研發(fā)。
• 看清事情本質(zhì)，不玩時髦概念，放下包袱，相關(guān)工作以更輕更高效的形勢來做。
• 言行一致，規(guī)范我們的計劃和過程管理，保障說的和實際做的，以及對外公布的信息保持一致。
• 職責(zé)回顧，大家各自重新把自己的職責(zé)厘清并遵守。

破壁

客觀和理性再次成為行事的主流，大家停止了相愛相殺式的爭執(zhí)，運維大腦 Vishnu（維石）的設(shè)計理念終于出爐。

設(shè)計理念如下：

• 以 KVM、Docker、OSS、ThinkDB 提供的標準接口為基礎(chǔ)，實現(xiàn)底層資源的可編程；原有 SAN、NAS、LB 硬件設(shè)備以封裝原子服務(wù)的形式實現(xiàn)資源分配的可編程。
• 包括 DB、MW、MQ 在內(nèi)的 OS 之上的軟件服務(wù)以封裝原子服務(wù)的形式實現(xiàn)。
• 以編排框架實現(xiàn)完整工作流的編輯和管理；輔以任務(wù)管理的能力做時間排程。
• 具體的架構(gòu)和運維規(guī)則邏輯在上層功能模塊實現(xiàn)。
• 通過權(quán)限認證模塊實現(xiàn)登陸和鑒權(quán)的處理。
• 面對用戶主體功能模塊包括自助交付服務(wù)、自服務(wù)、自適應(yīng)和管理視圖模塊。

按照這種理念，維石（Vishnu）的雛形如下：

經(jīng)過六個月堅持不懈地努力，我們已經(jīng)迭代到了 1.5 版本，實現(xiàn)了容器管理平臺、KVM、維石自助交付模塊和自服務(wù)以及 ThinkDB 這四大塊的階段性目標，1.6 的迭代已經(jīng)開始切入管理視圖部分的容量管理功能。

隨著功能的逐步上線，運維團隊的工作模式和內(nèi)容也開始相應(yīng)的出現(xiàn)變化：

• 專業(yè)組充當(dāng)好資源的供給方即可，只需做好在線資源的庫存管理。
• 需求方也無需在通過工單系統(tǒng)進行拆單派單，直接在維石工作平臺上獲取資源即可，而且最終也給出了良性的反饋：“終于可以優(yōu)雅的工作了”。交付效率更是較之前整體提高了 １ 到 ２ 個數(shù)量級。
• 大量常規(guī)變更無需由于擔(dān)心誤操作風(fēng)險，而集中到晚間人手最緊缺的時候執(zhí)行，人和可工作時間的逆向差瓶頸被打破。
• 專業(yè)能力依賴解耦，之前由于專業(yè)能力和安全權(quán)所限需要排隊找專業(yè)組同事提供的服務(wù)可以在工作臺上獲取，這部分還在進一步的優(yōu)化中。

維石（Vishnu）和 ＶＭ

現(xiàn)在和未來

走到今天，我們?nèi)匀辉诩訌娺\維研發(fā)能力的建設(shè)：

• 更有效的需求發(fā)現(xiàn)和管理。
• 系統(tǒng)代碼質(zhì)量的提升。
• 建設(shè)自動化測試框架，提高測試效率和質(zhì)量。
• 更適合運維的技術(shù)框架和平臺架構(gòu)。
• 更簡潔有效的任務(wù)組織形式。

我們體會到以前認為不可能的事情經(jīng)歷摸爬滾打下來，只要努力去做，是可以實現(xiàn)的?？梢灶A(yù)期的是，再過一年，還可以達到部分自適應(yīng)和自愈的運維程度。

運維的自由

最后，希望廣大運維人是自由的。心的自由，無需時刻誠惶誠恐、如履薄冰，擔(dān)心無法按時交付誤事，擔(dān)心系統(tǒng)出故障。這個夢想，希望廣大運維同路人一起來實現(xiàn)！

[[213394]]

周輝，自號甲骨君， 2002 年 OCP。自千禧年以來先后就職于富士康集團、平安科技和順豐科技，深刻經(jīng)歷制造行業(yè)、金融行業(yè)和快遞物流行業(yè) IT 運維工作的歷史變遷。曾有幸在金融數(shù)據(jù)大集中的黃金年代負責(zé)某金融集團保險、銀行、證券、投資、基金、信托數(shù)據(jù)庫運維工作，完成其龐大數(shù)據(jù)庫群標準化規(guī)劃和改造過程。在快遞物流飛速發(fā)展的當(dāng)下主導(dǎo)了順豐科技基礎(chǔ)架構(gòu)自原生態(tài)到標準化、系統(tǒng)化、半自動化的運維模式轉(zhuǎn)型，完成了順豐集團新數(shù)據(jù)中心、容災(zāi)中心的規(guī)劃建設(shè)和遷移等IT底盤建設(shè)工作?，F(xiàn)致力于順豐科技運維轉(zhuǎn)型和變革工作，是 DevOps 的踐行者。