關于作者：

周慧

自數甲骨文王，2002 OCP。千禧年以來先后任職于富士康集團、平安科技、順豐速運，經歷了制造業、金融業、快遞物流業IT運維的歷史變遷。有幸在金融數據集中的黃金時代負責了某金融集團的保險、銀行、證券、投資、基金、信托等數據庫的運維，完成了其龐大數據庫的標準化規劃和改造過程團體。隨著快遞物流的快速發展，引領順豐科技基礎設施從原生態向標準化、系統化、半自動化的運維模式轉變，并完成了規劃、順豐集團新數據中心和容災中心的建設和遷移。工作?，F致力于順豐科技運維的轉型與改革it運維技術，是一名實踐者。

總有一個理想，如果實現了，理想能走多遠，我們才能一起走多遠。在實現理想自由的道路上，我們繪制藍圖，踏出探索之路的第一步。未來不是夢，即使是夢，也要用一生去完成這個夢。

一、運維密室1.1、密室的墻和鎖

自2007年順豐技術運維部成立以來，隨著物流行業的快速發展，其運維規模也一直在瘋狂運行。到2016年，技術運維團隊已成長為近200人的大型團隊。為建立專業技術能力，自2013年初以來，經過三年的建設，技術運維團隊的組織架構和職能已逐步形成：

1、從底層基礎設施到網絡、存儲、服務器、操作系統、數據庫和中間件，每個專業領域都有專業的一線團隊負責，其工作職能包括規劃、設計、建設、實施和日常日常運營。

2、外部交付由基礎架構架構師團隊協調，工作模式為流程驅動，通過工單系統進行推廣和跟蹤。

3、部門的制度、流程和質量由運維策劃團隊負責，以彌補和彌補技術團隊管理上的先天不足。

4、整個技術運維團隊以ITIL系統為指導。

5、基礎技術軟件已于2015年全面開源。

通過專業的組織和分工，我們培養了多個專業領域的人才，獲得了一定的技術能力。同時，我們還系統地形成了基礎設施建設標準、設備引進和使用標準、基礎軟件使用標準和適合物流行業業態的標準。建筑標準。受益于這些變化，我們的資源使用效率變得更加合理，系統穩定性也逐年顯著提升。

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

1、運維團隊都背負著系統可用性的KPI，最終分解成各個專業團隊。在這種評價模式下，責任感逐漸顯現。既然變革總是伴隨著風險，本著少做多錯的理念，團隊之間的接縫工作或多或少有推卸，專職順利協作成為奢望。不幸的是，煙囪式的垂直分工比水平分工需要更多的協作。

2、為了信息安全，嚴格劃分各種系統和應用權限，很多日常運維工作都有上層人員等待下層依賴團隊授權或代為執行。

3、原來的職業分工導致大家的技術能力棧收縮，形成技術能力熱點。對于更全面的專業技術問題，研發和運營人員需要尋找相應的專業技術人員進行協助。經?？吹轿覀冝k公室的一位DBA或中間件管理員被很多人圍著分析問題。

至于技術運維團隊本身，各個團隊同時進入瓶頸期，整體發展壯大受到嚴重制約，大多數人在自己的微觀世界里都沒有意識到。

1.2、密室外的風暴

當我們的運維人員在密室的微觀世界里按照自己的節奏前進，感到舒服的時候，外面的大世界已經在發生快速的變化。現實是什么樣的？

商業：

1、業務流量高峰逐年增加，尤其是每年雙十一；

2、業務形式越來越多。過去，更有可能是我們自己內部用戶使用的各種系統；現在有各種直接的C端和B端用戶；

3、為了適應市場的變化，業務的調整越來越頻繁，隨著版本和變化越來越頻繁，傳遞到技術運維端。

技術方面：

1、云技術的成熟，降低了企業對自建技術運維團隊的需求。市場需求的池塘逐漸枯竭，池塘里的許多魚還沒有感覺到變化；

2、全面的開源和技術的快速演進，讓很多傳統的商業技術專業變得無用武之地。工程師要靠自己的本事吃到最后基本上是不可能的。在池塘干涸之前來不及完成進化的，可能會被提前淘汰；

3、的火爆為運維開辟了另一條更有效的途徑，進而對現有運維人員提出了新的素質要求。運維人員需要具備研發能力，并能夠運用這種能力來提高運營效率和質量。

密室里面是斜風細雨，密室外面又是暴風雨，不可能做魚干。

二、運維審判日

我們對IT運維工作做了四象限分解（如下圖）。從價值來看，理想的情況是技術運維團隊需要在右象限投入更多的資源，但實際情況是我們近70%的精力消耗在左象限的基礎日常工作上象限，做各種布朗運動。

基于對運維工作四象限分解的反思，我們總結出運維的五種死法：

2.1、龐大的熟練度

經過三年的專業化和標準化，我們的工程師對平時的日常工作已經非常熟練了，新的一天的工作只是n+1的重復；工程師們在鍵盤上打字的手越來越快，但他們的腦袋卻逐漸麻木，在工作中逐漸失去了獨立思考的能力。

2.2、工作效率降低

很多日常的IT運維交付工作真的只需要幾分鐘就可以完成，但從用戶需求到層層審核再到交付給用戶，可能需要幾天的時間。大團隊普遍存在的效率低下的問題是，煙囪式的垂直專業分工會隨著依賴團隊數量的增加而進一步放大，讓用戶苦不堪言。透過現象看本質，其實時間是花在溝通和等待上的。

2.3、向內觀察黑洞

在企業IT團隊中，從技術的角度來看，技術運維團隊往往具備專業的技術能力，但從業務價值鏈的角度來看，技術運維團隊處于價值鏈的末端；從完整的工作流程來看，技術運維團隊往往是最后一環，而不是IT大軍的第一線。在價值認知錯位、信息孤立的情況下，如果沒有完全的理性和充足的一線信息，技術運維人員就會形成各種負面的自我，匯聚成內心視覺的黑洞。

2.4、自制鏈條

起初，隨著公司的成長，該部門建立了KPI、規范、流程、標準、預算、成本等各項制度，為系統化、規范化的管理做準備。它們的出現使運維工作有序高效。規劃、規劃，并在起步階段起到了很好的作用。但在某些情況下，這些機構會表現出陰暗面，成為組織的桎梏和桎梏，例如：

1、制度和流程執行過度，無視人的主動性，所有人都被制度和流程帶走，團隊的創造力被閹割。

2、系統和流程所引導和約束的事物是不斷變化的，但系統和流程卻跟不上變化的步伐，最終成為工作的包袱和爛鏈。

3、關注管理者的需求，忽略用戶和一線的聲音，忘記建立制度和流程的初衷。制度和流程最終成為皇帝的新衣。

2.5、自動化缺點

當IT運維團隊達到一定的能力和規模后，將進入運維工作的自動化構建階段，并在一開始就給予解決各種問題的良好期望。很多時候，IT運維團隊發起的自動化工作，優先解決運維團隊自身的問題，不一定站在用戶的角度。

我們從 2015 年下半年到 2016 年上半年開始自動化運營；本來希望可以節省勞動力，提高效率和質量，但結果卻不盡如人意。自動化的任務結束了，整體的交付效率沒有發生質的變化，用戶也沒有變得滿意。回顧原因，我終于明白，我們都是在做執行端的自動化，也就是把之前的人工執行工作自動化，解決了運維主管自己的問題，但并沒有解決效率低下的問題交付工作流程。因為一個用戶需求是從審核提出，到修改，最后反饋給用戶，這個過程是很長的。許多人所做的自動化只是自動化他們自己的執行，

三、運維夢

經過一系列的反思和自我判斷，我們看到了技術運維團隊未老先老。總結如下：

1、失去創造力，工作僅限于維護現有技術和架構特征類型系統的可用性，未能系統地進行前瞻性的整體技術能力建設，以支持公司未來對IT機箱技術的發展需求。

2、愿景在縮小，規劃設計工作聚焦自身痛點，無法從公司業務發展中有效拓展IT底盤能力的廣度和深度。

3、官僚主義越來越官僚化，流程等規章制度成了盾牌和隔音墻。當需要技術炮火時，團隊已經筋疲力盡，無法再為前線提供有效支持。

4、坐以待斃，只關注技術本身，忽視價值貢獻，無法鏈接和跟進公司的技術戰略。

綜上所述，感覺技術運維團隊已經是寒山夜雨，千山暮雪，如何沖破身心的牢籠，實現自我救贖？經過多輪思考和頭腦風暴，我們認為技術運維工作的理想狀態應該是：

四、陰謀

方向明確，目標在彼岸。如果我們達到它怎么辦？更細心的執行、更負責任的態度、更細粒度的管理都解決不了問題。只有突破現有的思維模式，立足現狀，不拘泥于現狀，才有出路。我們決定從以下六個方面進行突破：

1、重新定義對專業技術能力的要求。技術運維人員需要在精通或精通基礎軟件應用的基礎上，具備研究和引進新技術的能力或運維研發能力。

2、專業的技術支持團隊有責任以系統的方式提供便捷的自助服務渠道，實現依賴團隊的能力解耦。

3、業務是第一要務。在工具平臺開放前，將從現有專業團隊中招募精英，組成全棧技術能力運維團隊，支持敏捷產品團隊的運維支撐工作。

4、在不降低運維質量要求的前提下，將原有ITIL的管控環節抽象為規則邏輯，嵌入工具平臺。

5、所有自動化工作都堅持端到端的用戶思維，讓用戶以自助的方式享受服務。原有流程環節通過規則引擎植入運維系統，對用戶透明。

6、持久化內容存儲必須是可編程的，可以扁平化技術架構，降低工作依賴程度，進一步統一X86 IT設備。

經過深思熟慮，我們啟動了以下五項工作：

對于主線任務微視，任務組在年初制定了完善的計劃（如下圖），計劃在2017年4月上旬交付資源自助，然后轉入優化七月的階段。

五、我撞墻了

在美好愿景的推動下，我們將原有專業團隊的部分優勢轉移到需求團隊。研發和實施團隊主要是沒有做過運維工作的Java工程師。步入煉獄，進入兩個月的無盡循環。

在這一切都出了問題之后，兩個月后，參與這項任務的同事，無論是為了需求還是為了結構，每天都在互相指責，沒有結果，筋疲力盡，痛苦不堪。傳統運維、運維、研發的艱辛已經遠遠超出了當初的預期。

一個接著一個，有的成員開始放棄，有的平臺和前端研發離開，產品經理不玩了，架構師也跑了。

六、面對墻壁

骨干人員集體對墻，對任務進行回顧和反思，最終制定了以下五項規則：

七、打破圍墻

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

1、基于KVM、OSS提供的標準接口，實現底層資源的可編程；原有的SAN、NAS、LB硬件設備以封裝原子服務的形式實現資源分配的可編程性；

2、OS上的DB、MW、MQ等軟件服務以封裝的原子服務的形式實現；

3、用編排框架實現整個工作流的編輯和管理；日程安排輔以任務管理能力；

4、具體架構和運維規則邏輯在上層功能模塊中實現；

5、通過授權認證模塊實現登錄和認證的處理；

6、面向用戶體的功能模塊包括自助配送服務、自助服務、自適應和管理視圖模塊。

按照這個概念，次元stone()的原型如下：

經過六個月的不懈努力，我們已經迭代到1.5版本，實現了容器管理平臺、KVM、自交付模塊和自助服務四大塊的階段性目標，1.6的迭代已經開始切入管理視圖部分的容量管理功能。隨著功能的逐步上線，運維團隊的工作方式和工作內容也開始發生相應的變化：

1、專業的團隊可以充當優秀的資源供應商，只需要做好線上資源的庫存管理；

2、需求方無需通過工單系統進行拆單，直接在微視工作平臺獲取資源，最后給出良性反饋：“終于可以優雅工作了”。交付效率比以前提高了1到2個數量級；

3、由于存在誤操作風險，不需要在人力最緊缺的晚上進行大量例行變更it運維技術，打破人員與工時反向差的瓶頸；

4、專業能力依賴于解耦。此前，由于專業能力和安全權限，需要排隊的專業組同事提供的服務可以在工作臺上獲取。這部分還在進一步優化中。

Stone() 和 VM

八、現在和未來

今天，我們還在加強運維研發能力建設：

我們意識到過去我們認為不可能的事情經歷了很多艱苦的工作。只要我們努力，我們就能實現?？梢灶A計，再過一年，可以達到部分自適應、自愈的運維水平。

九、運維自由

最后，希望廣大運維人員能夠自由自在。內心的自由，不用時時刻刻害怕，如履薄冰，擔心不能按時交付東西，擔心系統故障。這個夢想，希望廣大運維同仁一起實現！

結尾