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

[[213390]]

運維密室

密室的墻壁與鎖

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

為了建立專業技術能力，自 2013 年伊始經過 3 年的建設，技術運維團隊組織架構和職能逐漸穩定成型：

• 從底層基礎設施到網絡、存儲、服務器、操作系統、數據庫以及中間件，每個專業領域都由專業條線團隊負責，其工作職能包括專業條線的規劃、設計、建設、實施以及日常運維。
• 對外交付由基礎架構師團隊統籌，工作模式為流程驅動，通過工單系統來進行推進和跟蹤。
• 部門的制度、流程和質量由運維規劃團隊負責，來拉通和彌補技術團隊管理方面的先天弱點。
• 整個技術運維隊伍以 ITIL 體系作為基礎指導。
• 基礎技術軟件在 2015 年已經實現全開源。

通過專業化的組織分工，我們培養了很多專業領域人才，具備了一定的技術能力，同時也系統性的形成了適合物流行業業務形態的基礎設施建設標準、設備引入和使用標準、基礎軟件使用標準和架構標準。

受益于這些變化，我們的資源使用效率變得更加合理，系統穩定性也逐年出現顯著的提升。

經歷了 3 年的治理，隊伍組織架構、職能和技術棧進入到了相對穩定的狀態，但新的問題也逐漸浮出水面：

• 運維團隊都背負系統可用性的 KPI，并最終分解到各專業團隊，在這種評價模式下逐漸出現了責任氛圍。

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

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

• 出于信息安全考慮，各種系統和應用權限被嚴格切割，很多日常運維工作都出現上層工作人員等待下層依賴團隊授權或者代執行場景。
• 當初的專業分工，讓大家的技術能力棧出現萎縮，形成技術能力熱點。稍微綜合一點的專業技術問題，研發和運營人員就需要找對應的專業技術人員協助，經常可以看到辦公室里面我們的某個 DBA 或者中間件管理員被一票人圍住分析問題。

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

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

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

密室外的風暴

當我們的運維人在密室的微世界中以自有節奏前行，怡然自得時，外面的大世界已經在急劇的變化中，現實是怎么樣的呢？

業務方面：

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

技術方面：

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

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

運維審判日

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

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

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

笨重的熟練

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

被降維的工作效率

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

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

內視的黑洞

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

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

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

自制的鎖鏈

當初伴隨公司的成長，部門為了管理系統化、正規化而建立了 KPI、規范、流程、標準、預算、成本、編制等各種制度。

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

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

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

自動化短板

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

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

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

自動化的任務結束了，整體交付效率并未出現質的變化，用戶也沒有變得滿意。

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

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

運維的夢想

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

總結如下：

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

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

經過多輪的思索和頭腦碰撞之后，我們認為技術運維工作的理想情形當為：

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

籌謀

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

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

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

經過全面的考量之后，我們啟動了下面五個任務：

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

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

碰壁

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

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

如此種種不順，兩個月下來，參與這個任務的同事們，不管是做需求的還是做架構的，大家天天指責對方而沒有結果，疲憊且痛苦著。傳統運維轉運維研發的艱辛，遠遠超出了當初的預期。

陸陸續續的，有成員開始放棄，平臺和前端研發有人離開了，產品經理也不玩了，架構師也跑路了。

面壁

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

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

破壁

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

設計理念如下：

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

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

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

隨著功能的逐步上線，運維團隊的工作模式和內容也開始相應的出現變化：

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

維石（Vishnu）和 ＶＭ

現在和未來

走到今天，我們仍然在加強運維研發能力的建設：

• 更有效的需求發現和管理。
• 系統代碼質量的提升。
• 建設自動化測試框架，提高測試效率和質量。
• 更適合運維的技術框架和平臺架構。
• 更簡潔有效的任務組織形式。

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

運維的自由

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

[[213394]]

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