看著阿裏雲產品管控慢慢長大的阿裏雲專家尹書威說，未來運維將分為應用運維和業務運維

---

她，從行業軟件、共享軟件、OA係統到聯想網盤，再到阿裏雲，並紮在雲計算領域一幹就是七年。

她，看著雲產品管控慢慢長大，並先後經曆過管控係統的服務化改造、開源DevOps工具與阿裏雲的集成等。

“開源生態對阿裏雲是一塊全新的領域，教主製定了國際包圍國內的方針，擬定了開源社區引導企業用戶的戰略，為阿裏雲開源社區、開發者服務奠定了穩定的基礎。” 阿裏雲高級專家閆長海說到。

但她卻認為隻是邁出了第一步，運維自動化後麵還有很長的路要走，並持續尋求改變。“我們在做一件偉大的事情，也許現在的效果還不明顯，但一兩年後我們會感謝曾經努力的自己。”她堅信成功遲早會來。

她認為未來運維將分為兩個領域：應用運維和業務運維，而傳統運維人要想轉型，就要做到：從Ops走向DevOps，從項目走向產品，從資源走向應用。

她，就是本文的主人公、自動化運維領域牛人尹書威。

尹書威認為，未來雲上的運維一定要做到四方麵：自動化、方便遷移、將IaC進行到底和“永恒的職責”

尹書威，阿裏雲高級專家，就職於阿裏雲雲應用服務部門，負責開源的自動化運維工具與阿裏雲的集成，致力於通過主流開源高效的自動化工具提高雲上運維/開發的便利性。

她的花名——“黎山”，出處來自西遊記中《四聖試禪心》中幾個菩薩的媽媽——黎山老母。談到這個花名，尹書威說：“其實沒啥寓意。”相較之下，她更喜歡另一個因扮演年會小品角色，而得的別名“教主”。

IT行業中，女性程序員非常少，能成為大牛的女性更少，那尹書威是如何一步步進入這個行業，並成為大牛的？

“這個受我父親的影響比較大。”她說，父親是屬於那個年代少有的知識分子，從小就灌輸給她長大要做技術，“所以這個思想一直深深感染著我。”上世紀90年代，計算機還比較奢侈，家裏就給她買了一台386的電腦，因此她早早便開始接觸計算機。

畢業後，尹書威一直從事軟件開發的相關工作，先後做過行業軟件、共享軟件、OA係統，以及聯想網盤。

共享軟件是物業管理係統，屬於行業類軟件，但是以共享軟件的形式存在的——用戶在軟件園下載，購買後會發放注冊碼。尹書威說，那時微軟剛剛提出SaaS概念，這算是第一批SaaS係統了。有單機版和網絡版，網絡版即是“租戶”形式的，用戶隻需要注冊便可使用。“但那時大家還不能接受把‘數據’放到網上，所以單機版的下載量相對較多，並一度持續數周在共享行業軟件排行第一。”尹書威說，她當時還注冊了專利，隻不過後來隨源碼賣了。

接著，她來到阿裏雲，並一直跟著雲計算的成長而成長。對於這步，她不覺得跨界：“看似跨度很大，但有著千絲萬縷的關係。” 

尹書威是2010年加入阿裏雲的，那時阿裏雲剛剛起步，雲產品不多，“隻有幾個雲管控係統，我記得最開始隻有ECS。” 由幾個發展為現在的上百個，她算是看著雲產品管控慢慢長大的。

這樣的時間點來到阿裏雲，也讓她親身經曆過很多重要開發，比如阿裏雲的管控係統服務化改造，這是一個將阿裏雲底層的功能提供可操作的UI方式供用戶使用的係統。

為什麼要進行服務化改造？她稱，雲計算是2010前後才開始大火特火，阿裏雲盡管在雲計算上布局比較早，但也是摸著石頭過河。隨著用戶量和ISV的增加，大家發現一個較嚴重的問題，用戶隻能調用OpenAPI，不能調用阿裏雲的內部接口，雲產品提供的一些重要功能OpenAPI不齊全，有些也並不穩定，這使得用戶無法使用雲產品對外提供OpenAPI做管控或與他們的自有係統集成。

阿裏雲合作夥伴們的一致訴求都是帳號獨立、結算獨立，而管控係統的功能幾乎一致。尹書威思量：“如果為‘虛商’單獨開發管控係統，工作量非常大，同時功能的同步性、Bug修改的同步性都是嚴重的問題，所以一定要一套代碼支撐阿裏雲自身以及虛商的管控係統。”所以，她將基於OpenAPI的管控係統服務化改造分為兩部分：一部分是阿裏雲的管控係統基於雲產品的OpenApi提供功能，另一部分是阿裏雲的管控係統能夠輕量的輸出給“虛擬雲商”使用。

“用那時比較流行的一句話就叫‘Dog Food’，自己吃自己的狗糧，打磨OpenAPI的健壯性和豐富性。”

也正是這樣的改造，使得一套代碼完美的支撐了各個虛商，並且可以輕量化的輸出。增加虛商時，管控係統的代碼幾乎不感知，隻需要業務人員在管控係統的管控係統中做配置即可。

3月底，圈內有一篇很火的文章《深度解析國內公有雲大廠基礎實力》，文中有對開源生態覆蓋度的描述：“同時Azure和阿裏雲都在開發基於Terraform的模板部署項目...”這句話，肯定了阿裏雲去年在市場上的布局。阿裏雲資深專家湯子楠，就此也給予了階段性的肯定：“單騎救主，讓阿裏雲在新的‘戰場’也能保持領先。”

一切看似風淡雲輕，但對尹書威而言，卻是職業生涯挑戰最大的一次，“可謂一步一艱難。”在采訪中，她一字一頓說到。

她這次參與的是研發與阿裏雲集成的開源DevOps工具。然而開始開源生態集成工作時，她發現DevOps工具玲琅滿目，但是一個也不支持阿裏雲，也就是說不能用任何一個自動化工具管理阿裏雲的資源。

麵對眾多的工具，大家集成開發的優先級是什麼，功能範圍是什麼，都無從所知。為了理清頭緒，尹書威開始研究主流DevOps工具在運維流程中的角色。隨著研究的深入，她頭腦裏也逐漸形成一張大圖，串起一張從基礎設施管理→持續集成→持續交付→持續監控的主線。基於此，她決定每個主線挑選一個工具由自己團隊開發，其他由合作夥伴來。“我們負責架構設計和代碼Review，這樣當主線工具集成後，可以在其上長出一個產品，實現針對於阿裏雲DevOps的閉環。”尹書威解釋。

然而理想很豐滿，現實很骨感，開發開源DevOps工具一波三折，最典型的兩個問題是：各個開源DevOps工具的開發語言不同；另外一個是國內自動化觀念的問題。

開發語言上的不同，體現在：Terraform和Packer是Golang，Ansible是Python，Chef是Ruby。挑戰，不僅僅是要在短時間內掌握這些語言，也要掌握各個社區的編程規範、文檔規範、TestCase規範。尹書威說，後者不能隨心所欲，“因為回饋給社區是一定要符合他們的章法和套路。”

用戶教育的問題是什麼？是當這些工具與阿裏雲逐步集成後，尹書威想提供更多真實的Sample給用戶使用，但在調研中發現雖然大家都知道“基礎設施即代碼”的詞，但真正這樣做的並不多。“有很大一部分用戶是用了一些DevOps工具，但也隻是解決臨時性的問題，大家還是習慣性的用UI操作。”尹書威指出，這樣就違背了IaC的原則，使基礎設施的變動不可追溯、不可做版本管理、不可測試。

“比如想要修改資源Tag和Name，如果用IaC的理念，隻需要修改兩行代碼，執行變更就可以自動更新這些資源，但用戶卻用了傳統的手工方式：導出到Excel→在Excel上修改→再導回到列表中……這個過程需要更多的時間，不僅無法追溯更改之前的值是什麼、也無法回滾。再舉一個例子：想要在已有實例上掛載數據盤，如果用IaC的理念，隻需要把磁盤的那個資源加上，執行下變更，可以快速自動的執行掛載數據盤。而很多用戶的做法是做個臨時的小工具，把所有要掛載的實例取出來，然後再執行掛載。雖然達到了效果，比純手工操作要快，但已經違背了‘基礎設施即代碼’的理念，使基礎設施和代碼不對等，已經破壞了他們的完整性和一致性。”

目前這個工具已經研發好，並且Terraform的代碼已經納入官方社區。由於“Alicloud”的字母優勢，還排在Terraform官方文檔和代碼倉庫的第一個位置。

尹書威的同事閆長海說：“以阿裏雲四大件產品為先導，迅速的覆蓋了Packer、Terraform、Ansible三款工具的實施落地。得到了開源社區、開發者的一致認可。”這位同樣也是阿裏雲高級專家的還指出，尹書威積極推進的Terraform跟阿裏雲商業合作，也進一步提升了阿裏雲在國際市場的占有率和在社區的影響力。”

但尹書威認為這隻是邁出第一步，後麵還有很長的路要走。對比海外的自動化程度：網絡的搭建（VPC+Nat網關）全套代碼搭建，以及SLB的監聽也是用代碼實現。她感歎到：“國內自動化教育任重而道遠。”

但她並不氣餒，覺得這也是機遇，並持續尋求改變：“通過海外的需求完善工具，再不斷的反哺國內用戶。”就此，她也唿籲到：“希望有更多的開發者一起加入到工具集成的開發中，使中國的自動化運維步伐再快些，加快國內自動化的Sense，使企業有更多的時間去創新。”

“我和團隊都認為我們在做一件偉大的事情，也許現在的效果還不明顯，但一兩年後自動化的理念被接受，並加以實施時，我們會感謝曾經努力的自己，也感謝在路上踩過坑的用戶們。”尹書威堅信成功的那一天很快就會到來。

據悉，尹書威團隊會在4月份持續將主流工具對阿裏雲的集成回饋到社區，包括Packer、Ansible、Chef、Jenkins等，造褔更多的運維/開發者。

雲計算給企業帶來了便利，有無限可用的資源、基礎設施硬件不用維護、負載均衡/網絡/備份等都有成熟的方案，隨時可擴容等。因此，在雲計算領域浸淫七年之久的尹書威認為，未來運維將分為兩個領域：應用運維和業務運維。

這對運維人員，也提出了更高的要求。除了需要了解各個雲服務平台采用的不同技術、提供的不同雲服務、不同的專業術語，運維人員也要知道怎樣構建各個雲計算平台的基礎設施、部署、運維、監控等，以及各個應用對於雲計算平台的最佳選擇。

那傳統運維人，該如何轉型呢？尹書威的答案是“三從”。傳統運維人要從Ops走向DevOps，從項目走向產品，從資源走向應用。

具體則落到兩方麵，一方麵應該快速掌握各個雲平台的自動化工具及雲平台的能力，利用Dev手段管理雲上的基礎設施和應用，將開發、測試、預發、生產各個環境的自動化打通；另一方麵則是理解和應用業務運維的能力，比如業務架構是什麼樣子、業務壓力情況、用戶訪問規律、讀寫情況、Cache命令中率等，並結合雲平台的特點及業務數據，優化運維的成本、效率，以及優化業務架構、業務模塊的部署架構及對雲資源需求。

她還指出，雲上的自動化運維在以下四個方麵是一定要做到的：

1. 自動化：自動化你所能的一切，自動化比手工快得多。工具一旦被配置好，驗證也是正確後，之後每次執行任務都不會出錯；
   
2. 方便遷移：運維的根本是要保證穩定和安全，但有時也要考慮成本，方便遷移的方案可以靈活選擇適合自身業務的最合適的雲平台；
   
3. 將IaC進行到底：基礎設施的變更也要通過代碼維護。很多企業運維麵臨的兩大問題：人員變動頻繁、文檔更新不及時。將IaC進行到底，不止是創建時自動化，變更、銷毀也都通過代碼維護，這樣就可以將腳本做為基礎設施的文檔，可以做版本管理，每次的變更也都會有曆史記錄。
   
4. 永恒的職責：“自動化、基礎設施即代碼”、“持續集成/測試”、“持續交付/部署”、“持續監控/反饋”。
   

“教主擁有超強的業務前瞻能力和驅動能力。”阿裏雲高級專家閆長海在一段文字中說到。而在另一麵，尹書威也有很多糾結。

她說，前幾年部門節奏比較快，可預見一年之後部門人員將呈現頭部、中部、尾部較大的差距趨勢。“到底是托著尾部的前進、還是頭部快速跑？”尹書威躊躇萬分。“後來想起小時候玩‘魂鬥羅’的遊戲，如果是兩個人一起玩，快的那個是會被慢的拖死，後來決定是頭部的快速前進。”她坦然，這個選擇其實比較殘酷。

接下來，她又深陷另外一個抉擇：業務？還是技術？並在這裏徘徊很久。因為前幾年的行業軟件讓她感覺無限的“危機感”，對行業很了解，但卻視野很窄。後來鑽研了一段時間的技術，同樣有“危機感”，因為又離市場很遠。對於一個做技術的人來說相信很多人有這樣的迷茫，但她最終決定以業務為方向，技術圍繞業務做拓展。

現在，她最關注雲上自動運維的各種開源工具，包括它們適合的運維場景、功能、如何開發擴展，以及多個工具組合的的最佳實踐。比如Jekins2.0和Salt的結合、InfrastractorAsCode與PipelineAsCode的最佳實踐等。並通過輸入、實踐、輸出形成的閉環，快速掌握多方麵的技術。

“人生是一種修行。”尹書威說，她沒有任何宗教信仰，但卻非常喜歡這句話。

“修行的道路上，沒有失敗者也沒有成功者，隻有一段又一段各式各樣的人生，無論哪一段，都足夠絢麗多彩、苦樂參半。”

不以物喜，不以己悲——也許正是這樣的人生態度，才造就了今天自動化運維的大牛。