【作者】王洋，招商基金公司信息技術部基礎架構(gòu)師。碩士研究生學歷，曾就職于螞蟻金服金融云團隊、商業(yè)銀行、政府機關信息技術部等。擅長領域：云計算IaaS和PaaS平臺規(guī)劃與建設、系統(tǒng)架構(gòu)設計、一體化運維平臺建設、devops以及分布式存儲，在分布式存儲領域有多年實戰(zhàn)經(jīng)驗，擅長根據(jù)業(yè)務特性建設分布式存儲平臺。持有DevOps Master認證、ITIL認證，并在IEEE Computer發(fā)表論文”on-demand security architecture”，撰寫專利“一種數(shù)據(jù)保護方法、裝置及數(shù)據(jù)保護系統(tǒng)”（專利號：201010538235.8）。
近幾年，在IT軟件領域隨著云計算、微服務、容器、云原生、DevOps等一系列新技術、新思路的出現(xiàn)，“IT驅(qū)動業(yè)務”、“IT引領業(yè)務”這些理念的普及，以及以BATJ為首的互聯(lián)網(wǎng)公司在一些活動上的宣傳，對傳統(tǒng)行業(yè)的IT部門還是造成了一定的影響，傳統(tǒng)行業(yè)的IT部不同崗位人員面對這樣的變化，應該如何調(diào)整應對呢？本文將從架構(gòu)崗、開發(fā)崗和運維崗三個崗位對此問題做一些分享和討論。
首先我們談下架構(gòu)崗。
架構(gòu)崗面臨的問題主要有以下幾個方面：
一是傳統(tǒng)的基礎架構(gòu)向云化基礎架構(gòu)的轉(zhuǎn)變。
以前傳統(tǒng)架構(gòu)下，基于系統(tǒng)建設和硬件設備都是集中式的思路，架構(gòu)師的思路也更多的是考慮的是系統(tǒng)建設和設備的縱向擴容能力，就導致單體應用越做越大，包含的功能越來越多，做一個微調(diào)都會“傷筋動骨”，硬件選型的思路也是看重單個設備的性能、穩(wěn)定性以及縱向擴容能力。但是我們都知道“云計算”的資源池是以穩(wěn)定性遠遠低于小型機的x86服務器為主，并且強調(diào)的是橫向的擴容能力。“穩(wěn)定性差”和“橫向擴容”這兩點就和原來的思維發(fā)生了直接180度的沖突，該怎么辦呢？
首先就要先搞清楚“云”是分層的，一般經(jīng)典的分法是IaaS/PaaS/SaaS層，并且是一種按需分配資源的服務化理念，既然是服務，就首先要看清楚自己的服務對象是誰，然后針對不同的對象設計不同的架構(gòu)方案。
例如，針對IaaS層他的服務對象主要是運維人員和開發(fā)人員，那么在設計IaaS層的架構(gòu)的時候，作為架構(gòu)師就要抓住這兩類角色的不同需求，運維人員更關注的是如何能提供穩(wěn)定、高效的計算和存儲服務，能否支持熱擴容，能夠知道分配出的資源使用是否合理，能否支持同城雙活和異地災備；開發(fā)人員關注的是IaaS層能否提供快速甚至是自助式的計算資源交付，如果出現(xiàn)災難，能否快速的恢復我的應用等。
同時，尤其是在今年疫情期間，移動辦公和統(tǒng)一桌面云也越來越受到重視，這在傳統(tǒng)企業(yè)的傳統(tǒng)崗位上以前是沒有的，現(xiàn)在作為架構(gòu)師，就要考慮為了支持這樣需求，在架構(gòu)層面需要做哪些調(diào)整（網(wǎng)絡接入、帶寬、限流、身份認證、鏈路加密、數(shù)據(jù)防泄漏、后續(xù)擴容等）。
二是容器化技術。
容器作為這幾年的IT界熱詞，尤其是K8S統(tǒng)一江湖后，你出門不和別人談K8S、容器，就會被感覺是落后了一個時代。那么在引入容器化技術后，容器要部署在物理機上還是虛擬機上，容器是單獨部署一個網(wǎng)段還是和原來的網(wǎng)段共用，哪些應用適合部署在容器上，引入容器后對整個開發(fā)和運維模式有什么挑戰(zhàn)，這些都是需要架構(gòu)師去考慮的。
在筆者看來，在引入容器技術的初期，應該優(yōu)先在一些非核心應用的開發(fā)、測試環(huán)境上運行，一方面讓開發(fā)和運維同事熟悉容器場景下開發(fā)、測試和基于虛擬機時整個流程的不同，另一方面是通過在開發(fā)測試環(huán)境運行來驗證容器平臺自身的穩(wěn)定性，通過這兩方面來評估何時部署生產(chǎn)環(huán)境，以及是否將重要的系統(tǒng)部署到容器環(huán)境。同時，對于大多數(shù)應用場景而言，其實容器運行在虛擬機上和運行在物理機上差別不大，但是容器運行的宿主機最好有單獨的網(wǎng)段，這樣有利于網(wǎng)絡策略的配置和問題的快速定位。
三是去IOE。
這是一個老生常談的問題，現(xiàn)在不僅僅是要從技術角度考慮而且隨著中美關系的惡化，美國在科技領域?qū)χ袊?ldquo;卡脖子”越來越多，政治的角度也會加速去IOE的過程。
根據(jù)筆者的了解，在IOE中，相對而言，I（IBM）是大家去的比較快，也比較容易的，畢竟云化的基礎就是x86，架構(gòu)師需要評估好業(yè)務容量、重要程度以及關聯(lián)影響，規(guī)劃方案，分批設計遷移方案即可；再來看看O（Oracle），這個就要分行業(yè)看了，目前國內(nèi)互聯(lián)網(wǎng)公司基本都是使用MySQL了，去O的力度是最大的，但是在傳統(tǒng)行業(yè)里，一些核心系統(tǒng)還是在使用Oracle，這個遷移的方案設計就是對架構(gòu)師的一個挑戰(zhàn)，主要涉及基于MySQL的高可用方案、雙活方案、分庫分表、讀寫分離等；最后來說下E（即以EMC為代表的集中式存儲），這一部分，目前隨著基于x86的分布式存儲技術的普及，作為架構(gòu)師就需要考慮使用分布式存儲的可行性以及落地路徑，筆者還是建議使用萬能公式：“先開發(fā)測試環(huán)境”加“時間驗證”再逐步向生產(chǎn)環(huán)境推廣，最終替換集中式存儲。
四是開源軟件引入。
隨著互聯(lián)網(wǎng)技術在傳統(tǒng)行業(yè)中使用的越來越多，伴隨而來的是大量各種各樣的開源軟件被引入。這就帶來了一個問題，如果架構(gòu)師不能從眾多的開源軟件中選型出適合本公司的開源軟件，而是任由各個開發(fā)團隊自行引入和使用，那將帶來巨大的災難。一方面，同類型的開源軟件引入多個，導致系統(tǒng)對接成本提升和代碼復用率下降；另一方面，每引入一個新的開源軟件，就需要定制其規(guī)范和使用標準以及安全需求，況且開源軟件版本升級快，安全漏洞多，維護成本較大。
因此作為架構(gòu)師，非常有必要根據(jù)公司的具體情況設置開源軟件的可選列表，最好是每個方向（java容器、消息中間件、緩存、協(xié)調(diào)中心等）選擇一個作為標準選項，如果需要引入新的中間件，則需要經(jīng)過評估后才能引入。
五是應用的彈性擴容。
應用的彈性擴容，也是這幾年來被討論較多的話題，往往會被人和淘寶雙十一的秒殺放在一起討論。彈性擴容場景目前在傳統(tǒng)行業(yè)也是有應用場景的，雖然可能達不到雙十一那樣的規(guī)模。例如，現(xiàn)在很多有電商部門的公司也會搞一搞秒殺或者大促，在秒殺或者大促的場景下應用的彈性擴容也是這個場景下非常重要的一環(huán)。
要做彈性擴容，首選的方案是要把應用的架構(gòu)改造為無狀態(tài)應用，這也是業(yè)內(nèi)主流的做法，把應用的狀態(tài)統(tǒng)一集中進行管理后，應用自身的擴容才能平滑進行。但是，一個實際情況是對傳統(tǒng)行業(yè)有些應用很難做無狀態(tài)的改造，那么就需要考慮在將應用擴容后，要做一個狀態(tài)的同步動作，然后才能對外提供服務，這個過程時間會遠大于無狀態(tài)應用，所以有些場景的適應性會差一些。架構(gòu)師能夠根據(jù)公司的實際情況，針對不同應用設計不同的彈性擴容方案這也是一個挑戰(zhàn)。
六是微服務設計。
微服務其實并不是一個新概念，但是這些年隨著容器熱度的提升，微服務也開始成為“網(wǎng)紅”。不夸張的說，現(xiàn)在出去做技術分享，如果你說你們公司還沒有進行微服務的建設，那么真的是會有人覺得你們公司low的。
作為一個架構(gòu)師，在微服務方面，你需要知道什么樣的系統(tǒng)適合進行微服務改造，如何使用領域模型對應用進行設計，需要知道如何對微服務進行治理，微服務的網(wǎng)關應該設計在什么位置上，如何避免微服務拆分過細后變成微服務“地獄”，微服務和容器到底是什么樣的關系等。
七是研發(fā)一體化。
這里涉及需求管理、需求開發(fā)、測試和部署上線等環(huán)節(jié)。在傳統(tǒng)行業(yè)中，每個環(huán)節(jié)基本上都是有存在部門墻并且是都有獨立的平臺在工作。那么為了加速業(yè)務需求的上線速度，讓業(yè)務能更快的響應市場需求，作為架構(gòu)師，就有必要打通以上提到的各個環(huán)節(jié)，建設一個公司級別的研發(fā)一體化平臺。在這件事情上，就不僅僅是考驗架構(gòu)師的技術能力了，還會涉及到溝通能能力，人際交往能力甚至是向上管理能力。
接下來，我們談下開發(fā)崗位面臨的一些挑戰(zhàn)。
一是敏捷開發(fā)。
傳統(tǒng)的瀑布式開發(fā)模式由于響應周期長，已經(jīng)嚴重的掣肘業(yè)務的發(fā)展，跟不上市場的變化。敏捷開發(fā)模式講究的是，快速迭代，小步快跑，這就要求開發(fā)人員要對業(yè)務需求的大背景有清晰的理解，這樣才不至于在做每個小迭代的時候理解錯誤或者增加額外的溝通；另外，敏捷開發(fā)中每個迭代都有清晰的時間點和需求清單，這就對開發(fā)人員的能力有一定要求，會提升開發(fā)人員的開發(fā)效率，一定程度上減少“劃水”的時間。
二是適應云原生的開發(fā)模式。
根據(jù)筆者的了解，目前傳統(tǒng)行業(yè)里真正搞云原生應用的還并不多，但是云原生的應用將是隨著云計算落地后的必然發(fā)展途徑，因此從未雨綢繆的角度來講，開發(fā)人員了解云原生應用的開發(fā)模式也是非常有必要的，并且云原生應用中的一些開發(fā)思想也是可以對現(xiàn)有的工作進行指導和參考的。
三是適應devops的模式。
很多人會把devops看做一個工具，或者一個崗位，其實在筆者看來，devops是一種工作模式，是一種能把業(yè)務人員、開發(fā)人員、測試人員、運維人員聯(lián)系在一起的一種工作模式。而開發(fā)人員在這里有著承上啟下的作用，devops中的CI階段，開發(fā)人員對這個階段的理解和實踐方式，其實是對整個模式的運轉(zhuǎn)效果產(chǎn)生較大影響的。因此，在devops的流程中，CI階段的設計往往會根據(jù)各個公司的實際情況和研發(fā)能力來進行設計，換句話講，看一個公司devops流程中CI的設計，也能從一定程度上反映出該公司devops能力的強弱。
再者，我們聊下運維崗位面臨的一些挑戰(zhàn)。
一是基礎資源從集中式向云化轉(zhuǎn)變。
傳統(tǒng)的集中式基礎資源，講求的是單體的性能和穩(wěn)定性，思考問題的方式是縱向的。但是在基于分布式的云化基礎設施下，運維人員需要考慮的是云資源池的故障域要如何劃分、云資源池的規(guī)模要如何設計、不同環(huán)境的資源池要如何隔離、資源的超售比設置為多少、資源的標準化要如何設計、云化資源池中不同范圍的故障發(fā)生后，如何保證繼續(xù)提供可靠的服務，這些都是云化以后運維人員需要考慮的。
二是運維前置。
筆者發(fā)現(xiàn)，有些公司運維人員做的事情太過于底層，只負責OS層及以下的部分，對應用層的運維完全不懂，以致于在應用出現(xiàn)問題的時候，看起來都是開發(fā)在排查問題，給領導的感覺會比較差。同時，隨著云計算的普及，OS層以下的內(nèi)容，后續(xù)很可能直接被云服務商托管掉，就類似現(xiàn)在很多公司使用的托管機房，以及很多創(chuàng)業(yè)公司直接使用公有云，極端情況下，就可能導致運維人員下崗。
因此，運維人員應該讓自己的技能前置，例如，對于java技術棧為主的公司，對于運維人員而言最好是要學習java虛擬機的相關知識和技能，這樣在java程序出現(xiàn)問題的時候能夠快速定位問題，而不是強依賴開發(fā)人員。
三是容器運維。
容器平臺在被大量使用以后，一定會帶來運維問題，但是容器平臺的運維模式和基于虛擬機的運維模式是完全不同的，這就需要運維人員能夠熟悉容器平臺的運行機制，對容器有理論上的知識儲備以及實際的運維能力，而這項技能對傳統(tǒng)運維人員而言基本就是全新的領域。
四是開源軟件的運維。
前文提到了架構(gòu)師需要對開源軟件的引入進行專業(yè)的評估和把控，那么對于引入進來的開源軟件的運維工作就落到了運維人員頭上。傳統(tǒng)的公司的運維，一般都會買一些外部的運維服務，而這些運維服務大多數(shù)也都是針對傳統(tǒng)的商用軟件而不是開源軟件。因此在引入開源軟件以后，對于運維人員而言，原來可以依靠的外部服務沒有了，自己就需要去能夠具備運維開源軟件的能力，這里要投入的學習成本是相當高的，并且沒有一個所謂的“掌握”標準。
如何應對？怎么轉(zhuǎn)型？
從架構(gòu)師、開發(fā)、運維這三個角色談了這么多以后，接下來談下有哪些途徑是可以幫助傳統(tǒng)行業(yè)的人員進行轉(zhuǎn)型呢？在筆者看來，有以下幾個方面：
一是自主學習。
引用一句老話“活到老，學到老”，尤其是在IT這個新技術日新月異，層出不窮的時代，自我驅(qū)動學習是一項基本要求；
二是加入一些真正討論和提升技術的圈子。
目前社交平臺和軟件有很多，但是魚龍混雜，要不就是一些群打著技術交流的幌子，在里面進行廣告推銷，要不就是加入群以后根本沒人說話，要不就是里面全是一些伸手黨，所以想要找一個靠譜的圈子是有一定難度的，較好的方式還是通過“大牛”引薦或者可以加入以twt社區(qū)為代表的平臺進行從基礎到進階的培育交流，答疑解惑。
三是在工作中，利用項目建設或者其他能接觸新技術的機會，積極參與其中。
通過項目建設本身，學習涉及到的知識，并且伴隨著項目落地自身對涉及到的知識也有了較好的實踐。
