《順豐IT基礎架構運維的焦慮與進化》要點：
本文介紹了順豐IT基礎架構運維的焦慮與進化，希望對您有用。如果有疑問，可以聯系我們。

作者簡介：

周輝

順豐科技 基礎架構規劃副總監

自名甲骨君, 2002年OCP.曾有幸在金融數據大集中的黃金年代負責某金融集團保險、銀行、證券、投資、基金、信托數據庫運維工作,完成其龐大數據庫群標準化規劃和改造過程.

在快遞物流飛速發展的當下主導了順豐科技基礎架構自原生態到標準化、系統化、半自動化的運維模式轉型,完成了順豐集團新數據中心、容災中心的規劃建設和遷移等IT底盤建設工作.現致力于順豐科技運維基礎軟件研發和智能化運維平臺領域工作,是 DevOps 的踐行者.

前言

順豐的數據中心工作內容可能和其他公司的基礎架構部門不一樣,基礎設施、網絡、存儲、服務器、數據庫、中間件等基礎組件規劃、設計、建設和運維全部都在其工作范疇.

接下來的談及的內容不會涉及太多具體的技術細節內容,更多的是順豐在基礎架構方面的治理和演進的過程,包括了組織結構和團隊組建的過程以及流程管理的內容.

1、順豐科技介紹

順豐科技服務于順豐集團,主要專注于物流行業信息技術研究、開發和運維,以及信息技術引領業務創新.

2、 順豐科技的創新與發展演進

2010年前,主要是技術起步和積累階段,通過科技手段將下單、收派、中轉、運輸等業務流的信息化,實現快件路由跟蹤、手持終端收派、自動分揀,并進行大規模的系統整合,支撐并推動業務的高速發展.

2010-2014年商業快速成長,是新技術新應用的爆發期,期間實現了電子支付業務與客戶系統的無縫對接和數據的自動交互；移動端與互聯網接軌,改善客戶體驗；使用大數據提供決策支持、輿情分析、行業分析,培養新的增長點.

2015年以來,為了使人們的生活更加便利,順豐科技一直沒有停下技術創新的腳步.

3、科技重塑業務流程,讓人們變得更便捷

在快遞的下單、收件、中轉、運輸、派送、支付等各業務環節,科技成為優化和重塑業務流程的重要力量,讓人們的生活變得更加便捷.

3.1 莽荒紀-運維原生態(原生態)

在運維原生態這個階段,新上IT系統、用什么基礎軟件和何種設備、用多少等事項,都是研發在規劃和設計,運維按照研發的要求安裝就可以了,基本上業內有些名氣的基礎軟件,都會出現在需求清單上.

而怎么用運維也沒有發言權,往往是運維按照研發的要求拿一個安裝包,安裝上去能起來用就行,其實完全沒有來得及掌握這些軟件的使用和最佳實踐.而且的系統是沒有容災,也沒有備份的,數據安全性很脆弱.相信很多企業經歷過這個階段,也有一些企業還在這個階段.

3.2 莽荒紀-運維原生態(被動式)

在原生態的運維模式下,沒有良好的規劃能力、計劃能力、專業能力和有效的工作流.這種情況讓運維非常被動,資源永遠不夠用,只要起新項目、新系統必須買設備,而且新設備的采購周期很長,嚴重影響交付時效.

同時,缺乏計劃能力時,需求總在不經意間冒出來,需要資源的時候,往往是項目要上線的時候,基礎架構只能東拼西湊到處找設備,甚至找廠商借設備.專業戰線太長,運維人員根本來不及形成專業能力,系統故障的出現頻率不低.

3.3 莽荒紀-運維原生態(焦慮之源)

近五年快遞業務增長很快,系統數在增長,業務量也在持續增加.快遞行業業務工作系統化,自動化程度變得更高,對IT系統的可用性要求越來越高,大概五年前,很多快遞企業沒有自動化.

當年開始試行半自動化和自動化分揀的時候,區別很明顯,IT系統的問題往往導致整個中專場分揀作業的停擺,最終影響到派送時效和用途體驗.而這時基礎架構還停留在“搬運工”階段,且異常多,運維很多人里都陷在異常處理的泥潭,這時候整個運維團隊壓力都很大,處于無限焦慮的狀態.

4、出發-集中填坑和還債

4.1 建立標準,完成標準化改造

我們大概花了6個月時間完成基礎加過運維的各種標準.到底該使用什么軟件,要不要百花齊放,如果人力資源有限、時間有限,如何讓運維人員做到熟練的掌握所采用的基礎軟件?答案是明顯的,基礎軟件需要在考慮適用性、適應性的基礎上標準化,兼顧研發能力成熟情況.

定了軟件的使用標準以后,從接入層開始至數據存儲層,每個組件都需要考慮高可用和彈性的設計,故軟件架構標準是在軟件好用標準明確后接著需要完成的作業.我們大概用了1年多的時間完成絕大部分業務系統的標準化改造.

同樣的道理,當初我們的設備類型非常多,包含存儲、小機等,市面上主流廠商有的設備我們都有,無法有效形成這些設備的運維經驗和能力積累,硬件的異常頻率也不低,在設備的引入和使用標準制定并執行了一年多以后,基本上沒有再由于硬件原因導致的重大故障出現.基于同樣的原因,我們制定并執行了基礎設施建設標準.

4.2 培養專業,術業專攻,服務統籌

基礎架構標準解決了,專業能力怎么辦?我們進行了專業分工,按照專業條線組建運維團隊,在專業方向上進行深耕,收效比較明顯,半年左右可以形成各基礎架構專業領域的戰斗力.

但這種組織形式在技術架構和技術方案的整體合理性方面比較弱,大家各行其是,沒有一個團隊能夠站在系統整體層面進行設計和思考；另外專業團隊在運維的管理方面初期會比較弱,如何進行統籌和拉通?首先成立基礎架構師團隊,扛起技術和架構標準的制定和更新并應用工作,進行整體的把關和設計.而運維管理相關制度流程規和執行可以成立精干的運維規劃團隊來護航.

2012年以前,我們沒有變更管理,所有的變更都是專業人員根據自己的判斷來做.所以經常會有些異常場景出現在業務高峰時段,系統突然宕了,原來是某個運維的兄弟在做停機維護或者下版本.

痛定思痛,我們提出變更的要求,成立?CAB?組織來保障執行,至少做到變更有固定時間窗、方案和風險評估,執行起來一段時間后,由于隨意變更引起的人為故障出現了大幅度的下降.

4.3 建設工具,培養主動預防的運維能力

有了標準和專業能力還不夠,從基礎設施一直到中間件組件,基礎架構大團隊手上有很多內容需要運維,人多事多,可以說是紛紛擾擾.我們到底有多少組件和設備?它們有各做什么用途?這些組件和設備運行的情況怎么樣?這些是所有基礎架構運維人必須解決的問題,沒有捷徑可走.

經過大量的整理、梳理、配置、觀測、調校工作,我們的運維團隊花了半年多的時間完成了配置管理和監控系統的建設工作,完成之后,大家有了心清目明的感覺,心里也踏實多了,在此之后,我們的系統可用性比之前有了持續、大幅度的提升.經過一年多的努力,我們故障量下降到上一年故障量的一半左右,到目前,故障率可能只有之前的十分之一.

每年的雙十一對資源的需求是喜馬拉雅山形式的,突然飆上去,資源容量怎么辦?我們根據監控系統采集到的數據推入容量預測平臺,利用R語言結合歷史數據和業務量建模,得到和業務量相關的系統容量模型,再代入當年雙十一業務方對于業務量預測的結果即可得到雙十一每個系統的資源容量要求體檢進行準備.而真正進入雙十一的時候,基礎架構團隊會相對輕松,公司的業務系統也可以做到平平穩穩度過雙十一了.

4.4 新的焦慮

快遞行業風云變幻,總體來講近兩三年快遞行業服務單價都在下降,逆向對IT運營成本有增加了的壓力.隨著互聯網的發展,業務形態更加多元化,而且業務的要求也越來越快,IT交付難度愈來愈高.初期的版本需求是一個月下一個版本,或者兩周,而今我們部分系統已經是每周一個迭代.這些變化都要求基礎架構需要更加輕和快.

而實際情況是基礎架構是重資產單位,在整個IT運營成本中占比較高,另外之前采取專業分工的組織模式,也開始出現副作用,專業團隊只站在自己的角度考慮問題,協同弱,溝通環節太多,效率低.專業壁壘已經形成,變成一個無法回避和逾越的問題,運維團隊再一次陷入焦慮的循環.

5、加速-注重效率和成本

5.1 基礎軟件去商業化

全面擁抱開源,經過半年左右時間的預研、測試、研發框架實現,2015年開始,我們所有的基礎軟件實現了全開源,其中包括中間件、消息件和數據庫等.開源以后,在軟件許可和廠商服務方面的投入可以忽略不計了.

由于行業的特殊性,有些公司主要還是使用商業軟件,而且需要使用大量的廠商服務資源,這種和廠商背靠背的運維模式,這種模式投入相對高,對廠商有一定的依賴.

開源以后,失去廠商背靠背的支持做運維,在開源軟件的穩定性和性能方面必須掌握把控力,要深入掌握體系結構、功能、性能,部分和部件之間的關系,最好能夠做到對?Bug?能夠進行快速修復和性能優化,所以全面規模化的開源,需要形成自己的運維研發能力.

我們在導入?MySQL?的時候,本著“簡單用”的原則,對不適合?MySQL?最佳實踐的用法直接在數據庫開發規范中進行明確約束.試點選擇公司重點系統項目,我們的?DBA?團隊和項目研發團隊一起并肩作戰,陪著研發一起走完了分析、規劃、設計、代碼、測試、調優、試運行一整套完整的過程,這個過程既是研發逐漸接受?MySQL?的過程,也是?MySQL?業界的最佳實踐調校為順豐的?MySQL?最佳實踐的過程.從最終的結果來看,MySQL?更多的承擔這數據容器的角色,業務邏輯絕大多的剝離到了數據庫之外.

5.2 完善服務體系

全開源部分緩解了IT運營成本的壓力,IT資源交付效率怎么辦?最初我們新需求出來,只能做到15天后交付給需求方.后來經過架構師團隊的努力,到一站式交付,通過流程梳理優化、工單系統導入,可以做到2~3天的交付,需求量較大的,最晚5天內交付.

之前做軟件架構標準化改造和全開源,是自上而下的運動式的大躍進,運維和研發由于關注點的不同,目的也不完全一致,相互支持自然少不了,但相互理解方面到不得而知.為了增進理解,形成科技合力,基礎架構運維團隊提供了架構和 DB 設計服務,基礎架構師和 DBA 直接駐點研發重點項目團隊,和研發兄弟一起工作,提供專業能力的支持和問題的解決,實實在在的合作,幾個項目下來,研發對運維的專業性的開始認可.

每次運維質量出現逆向波動的時候,回頭看看?ITIL,檢視管控點的缺失或松懈,多半都是執行的問題.ITIL作為一套成熟的運維治理法則,活學活用還是很有幫助.

5.3 日常工作自動化

受限于人類只能串行的腦和手,工程師無論工作多熟練,其日常工作產出有限.2015年下半年正在開始,我們的基礎架構團隊開始系統性的對待運維自動化,經過近半年多的努力,我們已經可以做到用戶提一個創建型需求,經過運維專業組的線上評估,點一個按鈕,自動生成變更,在系統上設定一個時間執行該變更.非創建型日常變更更多是是半自動式實現,還處在路上的階段.

運維日常工作中,溝通多半是郵件、IM?或者會議,時間都消耗在了溝通和等待中,其本質是一個信息傳遞和確認的過程.處理好信息的準確行和流通有效性,將工作流和信息流放在線上,通過系統可以有很大的效率提升,工單系統是一個典型的例子.

5.4 仍然焦慮

IT運營成本已經不是一個大問題了,服務交付的效率貌似也能夠跟上節奏,是否可以停下來休息了?當然不行,互聯網形態的系統一直在增加,其使用行為和用量的波動區間遠超企業內部系統,對系統的健壯性和架構彈性提出了更高要求.“雙11”峰值一年比一年高,如何更快、更有效的進行高峰應對,而不是靠人來堆?

更輕更快是一個撲面而來的要求,而當時的實際情況則讓人焦慮不已.

• 一是流程重,以?ITIL?理念設計的流程更看重質量,效率不能很好的兼顧,人和事被流程牽著走；
• 二是自動化,把整個流程拉開來看,從需求的發生到結束,自動化只是替代了末端執行環節的手工作業而已；
• 三是架構彈性弱,高峰應對的擴容評估、壓力測試、擴容執行周期長,是“人肉”祭場.
• 四是技術架構縱深層次多,部分重要數據要在?SAN?集中存儲,數據存儲單點如鯁在喉,是運維人心頭上的一根刺,急待解決.

6、狂奔–重定義架構和專業

6.1 基礎運維十字架

基礎架構很多種工作,我們將其分為價值四象限.從外部來看,右上角為價值區間,即我們能夠為業務單位、研發單位等上游部門提供怎樣的科技能力助力公司戰略目標的實現.

左下角完全是為了系統穩定而進行的日常運維工作,重復性非常高,而且只要不出問題,外界基本無感知.整體來判斷,縱軸右面的工作價值高于左邊,正常理解的話,運維團隊的資源應該更多的投入到右邊的工作中.

很可惜,實際情況正好相反,彼時運維團隊75%時間在做各種瑣事,25%做進階工作而已.結果本應右手解決左手的問題,但是右手騰不出來,左手也一直在忙.

6.2 重新定義專業和能力

6.2.1 專業重定義

為了再一次蛻變,擺脫運維十字架的負重,我們決定重新定義專業能力.以往專業團隊掌握技術軟件,熟練進行各種應用場景和使用方法就夠了.現在夠不夠?明顯不夠!

再一次,我們需要重新組織隊伍：

• 一是技術團隊不能只做日常工作,一定要沉下心做專業領域的研究；
• 二是運維團隊上浮,日常基礎架構運維團隊聚焦應用,基礎架構運維人很多時候根本不了解應用系統,也不關心主機、存儲和網絡上跑什么系統,每次出現問題處理的要求時,大家都各講各話；
• 三是研發團隊聚焦,聚焦在打通專業壁壘,做到更徹底的運維自動化.

6.2.2 去掉中間環節

在煙囪垂直專業分工模式下,一個系統顆粒度的完整作業,工作流需要類串行的流經所有的專業團隊,中間溝通環節多,慢! 對用戶而言,如果能夠實現端到端的自助交付或自服務是最快的方式,要做到這一點,需要要做基礎架構數據整合和可視,打通專業和安全壁壘.

另外在隊伍的組織層面,在整個平臺打通工作還未完成前,可以嘗試全棧運維,聯合作戰,在組織層面降維,讓大家在一個平面上工作,實現信息和能力的透明共享.

在互聯網系統領域,我們把基礎架構專業人士抽一部分出來,和應用運營同事放在一起組成完整能力團隊.現在效果比較明顯,專業都有了,相互影響和學習,整體工作能力和效率都有提升.

6.2.3 優化技術架構

傳統架構層次較深,尤其是數據存儲層,不但徒增交付工作環節,同事有事數據安全和性能的熱點,怎么辦?對數據庫的用途進行輕量化處理.

數據庫只作為數據存儲容器,不要把太多邏輯放在數據庫處理.應用層要承擔更多邏輯的實現,同事對數據庫進行分片來拉低數據庫主機和存儲的需求門檻,一個數據庫承載的數據量太大,邏輯太重,對數據庫所在主機提出更高的要求,才會出現以前很多企業用小型機或更好的機器和光纖存儲.

當然,對于 MySQL 數據存儲本地化后,數據庫 HA 方案不管是數據的完整性和切換的效率方面都要做好嚴格的設計和驗證,我們的 ThinkDB 就是為解決這個問題而起的任務,從當前的進展來看,是完全可以解決的問題.

在資源和架構的彈性部分,如何更彈性?大家在物理機集群遇到一個問題,擴容要有機房同事把機件上架、拉好、初裝,一旦涉及物理設備的操作就會變慢和重,這時我們將物理設備準備工作前置池化,當然,在量方面做好預測工作.邏輯層使用 Docker?和?KVM?虛擬群來做到相對輕量化的快速橫向擴展.

談到這里,開源的好處進一步凸顯,開源可以無縫支持可編程的基礎架構,投入一些研發資源,除了物理設備本身外,很多邏輯層的工作都可以從手工搬到線上,定時定量都可以處理,而且相關運維標準植入系統后,標準化的工作可以執行的更好.迄今,這些設計已經進入我們的技術架構標準.

7、新故事-維X

雖然我們可以在管理、團隊組織進行局部優化,但無法解決一個問題,當一個團隊大的時候,當你管理的設備、應用形態、軟件技術多了,如何做到所有的人都知道狀況?

如何共享信息、流通信息,一旦信息無法共享和流通,所有人都站在知曉的信息范圍內工作怎么辦?

我們看了業內一系列的解決方案,也和業內同行交流了很多次.他們都是非常優秀的平臺和軟件,我們發現這件事最后還得自己來.

平臺滲入了一定的管理思維,對公司的能力、組織形式、業務形態以及相關的管理理念都有要求,你接受一個軟件必須接受那些東西,能否完全接受,接受后的調整和適應需要多長時間?最后評估的結果是還得自己干.

我們希望通過維X,做到基礎資源的提供、專業能力的提供,都以原子服務的形式在滿足安全的前提下暴露出來,在系統進行集成,讓我們的被服務方能夠自助的獲取,給我們的上游團隊賦能,達到價值最大化的效果.

這個平臺應該有幾個特征：一是數據共享透明；二是交付自主；三是專業服務能夠自服務；四是自調整和自適應；

談智能有點超前,我們短期做不到這種程度,但相信前四點能夠解決我們大部分的問題.這條路不易,運維人員開始轉型運維研發人員時,思維模式和對研發項目的組織是欠缺的,后面有一定的積累再和大家分享!

文章來自微信公眾號：高效運維

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/2747.html