作者介紹：徐桂林，當前在FIT2CLOUD負責公司的技術布道和生態合作。在此之前先后供職于意法半導體、Autodesk和阿里云。徐桂林熱衷于云計算(尤其是公有云IaaS平臺)，有過多年AWS的生產環境工作經歷，是較早在國內分享AWS上實踐經驗的作者之一。
現在，業務上云已經成為一個潮流。尤其是對于公司內部的技術人員而言，經常會有很強的技術沖動去讓業務上云。同時，云供應商們的大力宣傳讓公司決策層及業務人員對于上云也有非常高的期待。但是，不管怎么說，公司業務系統上云還是一個技術活。作為公司內技術人員，仍然要從技術的角度充分考慮上云的路徑、節奏以及具體技術方案。所以，很多時候技術人員的上云姿勢比上云自身還重要。選擇一個正確的上云姿勢會讓你的上云過程更加順利，并能夠為未來充分釋放云生產力奠定基礎，最終達成公司上云的初心：促進業務創新。
姿勢一：掌握正確的上云節奏
當企業決定上云后，掌握正確的上云節奏是讓整個上云過程順利的最關鍵因素。一般來說，如下路徑是企業最常見的上云節奏：
在這個節奏中，技術人員要特別注意下面兩點：
上云過程的第一步(在云上進行開發測試)是一個非常重要的步驟，這是技術人員更深入理解云的關鍵階段。但現實過程中很多技術人員都忽略了這一步的重要性。他們習慣于選擇一些測試工具在云上進行測試，然后以這個測試結果作為認識云的主要信息來源。如果測試結果合適的話就直接在云上部署服務。這種方式經常會讓技術人員在未充分了解云的情況下上線服務，會給后來云上運維及運營帶來很多不確定因素。一個更為推薦的方式是技術人員以云為開發測試環境，并在其上不斷迭代版本，盡早暴露系統在云上運行的問題。同時，這個過程也是技術人員深入理解云平臺，不斷調整使用云資源方式的過程。另外，由于云資源的按需付費特征，從成本上看其也特別適合作為開發測試環境。
在整個上云過程中，不同階段對于云平臺的要求是不盡相同。如果就IaaS層面來說，我們認為上圖不同階段對于云平臺的要求大體如下
所以，隨著上云過程的不斷深入，技術人員需要持續考察云平臺的支撐能力是否能夠匹配當前的上云階段的需求。
姿勢二：選擇合適你的云平臺
目前，市場上云供應商比較多，即使是面向技術人員的IaaS和PaaS也有不少。所以，如何為你的上云業務選擇合適的云平臺就是技術人員必須要面對的重要問題。不同業務、同一個業務不同階段對于云平臺的需求都不盡相同。就IaaS層面來說，技術人員在選擇云平臺時需要注意如下幾個問題：
避免被企業宣傳所影響，拋棄“云是萬能鑰匙”的認識。在選擇任何云平臺前都要充分做好驗證工作(POC);
明確核心驗證指標，避免要一個面面俱全的方案。即使是今天，云平臺仍然在快速發展階段，可能還沒有為你提供全面完整的解決方案。但是，如果因此而望而卻步則有可能因噎廢食。所以在做云平臺驗證之前需要明確業務要求的核心指標，之后再以此為參照做云平臺的驗證工作。對于目前還不能完全滿足的其他指標可以考慮通過技術架構、輔助工具、管理方式等途徑解決;
轉變思路，拋棄不再合適的做法。用戶對于云時代IT基礎設施的很多需求沒有改變，但是也有不少思路發生了巨大變化。例如，自服務IT就是一個非常好的例子。傳統IT中企業傾向通過集中化申請、審批每一份資源來控制成本，而在云時代使用這一套方式管理云資源將極大限制云平臺的生產力。一個更好的方式可能是通過成本預算和費用管理的方式來控制，但不去限制技術人員如何具體使用每一項資源。只有這樣才能夠充分釋放技術人員的生產力，達到效率和成本的新均衡。
姿勢三：使用API管理你的云資源
當技術人員上云后，其最常見的云資源管理方式就是云平臺的Web控制臺。用戶可以通過控制臺申請、釋放資源，完成資源的配置等等。控制臺對于用戶管理云資源很直觀，但是控制臺UI交互的方式卻限制了云資源“可編程”特性的發揮，限制通過自動化完成開發、測試以及運維管理工作的能力。所以，技術人員上云過程中一定要注意盡可能多使用云平臺提供的API工具(包括命令行工具和各種語言SDK)管理資源。通過這些工具，技術人員可以完成很多控制臺并不擅長的工作，例如：
常見的批量操作，例如按一定標準批量申請、釋放資源，對于一批資源進行批量配置等。
流程自動化操作，例如自動化完成資源獲取、初始化、業務部署以及加入系統這一整個流程。
資源調度操作，例如按照一定標準完成資源自動擴縮容，以提高系統應對不同業務負載的能力。
姿勢四：隔離開發測試與生產環境
在傳統IT中，很多公司的開發測試環境與生產環境相關獨立，甚至網絡也相互隔離。這是一個非常必要的最佳實踐，但在云上如何落實這一實踐?其實，云為此提供了一種最簡單直接的方案，就是通過不同的云帳號來完成不同環境的隔離。不同云帳號之間資源、網絡天然隔離，并且可以把他們交給不同的人員進行管理。當然，這種隔離也會帶來數據交換的不方便，一般來說有下面幾個途徑解決不同帳號下的數據交換問題：
通過云平臺提供的跨帳號資源共享能力。例如，跨帳號的鏡像共享機制，數據跨帳號訪問的授權問題。
通過集中化的服務交換數據。例如，通過集中化的制品(artifacts)庫在開發測試和生產環境中共享部署組件包。
姿勢五：讓你的系統更有彈性
業務負載上的彈性是系統彈性最重要的指標。云平臺為業務負載彈性提供了非常好的基礎設施支持。無論是傳統的應用，還是新型云應用都可以從此獲取極大幫助。例如，傳統游戲應用都是按分區模式運營，并且很少涉及到線上跨區數據訪問。云的這種彈性交付模式也可以讓其在開合服上帶來很大靈活性。而新型云應用一般都按水平伸縮和狀態無關來設計技術架構，則更能發揮云平臺的彈性。因此，技術人員決定上云時需要仔細思考業務負載的彈性特征如何，能否在技術架構或者基礎設施層讓整個系統更有彈性，從而讓你的系統因為上云可以獲得更好的彈性。
除了業務負載上的彈性，業務系統的容錯性和高可用同樣也是系統彈性設計中的重要考量。云上資源的獲取非常容易，所以在容錯處理乃至備份容災方面都可以充分利用這個特點。在系統出現問題時快速搭建全新環境并及時切換很多時候比在原來系統中恢復服務更有效。同樣，云平臺帶來的另外一個好處就是全國(乃至全球)的基礎設施資源標準化，可以讓你的系統非常容易在不同區域進行部署，并且當一個區域出問題時候還可以及時切換到其他區域。這也是一個增強服務彈性和系統高可用性的重要途徑之一。
姿勢六：讓自動化和云為伴
自動化是大家經常提到的東西，并且在傳統IT中也在不斷的強調。那么技術人員上云和自動化有什么特別的關系?簡單來說，云為傳統IT中最難自動化的部分(基礎設施)提供了自動化的可能，這也就意味著整個IT系統有可能從零開始全自動化搭建完成。傳統IT技術人員的自動化鏈條很多時候都是以基礎設施準備到位，甚至初始化完成為起點。而在云上技術人員一定要努力將自己的自動化鏈條向前延伸。具體來說，包括如下幾點：
自動化基礎設施資源的獲取過程。這不僅僅包括計算資源(如虛機)的獲取，還包括如磁盤、負載均衡器、虛擬網絡、帶寬、公網IP等等。
自動化基礎設施資源的連接過程。例如，磁盤掛載、負載均衡器掛載，綁定IP等等。
自動化基礎設施的初始化工作，包括鏡像加載，基礎軟件安裝，初始化配置，甚至應用部署等。
為此，很多云平臺還為用戶自動化基礎設施提供了專門服務，如虛機及容器的鏡像、基礎設施模板、虛機的metadata&userdata，代碼部署服務等等。這些服務都值得技術人員去了解和試用。
姿勢七：用好云上安全工具，其實云比你想象的要安全得多
安全是很多客戶對于云平臺最大的擔心。也正因如此，云供應商對安全做了大量的投入，提供了很多安全工具。對于技術人員來說，首先需要牢記在心的云上安全基本原則就是“責任共擔原則”，也就是說云上安全是由云平臺和客戶共同擔當。所以，云平臺客戶和技術人員一定不要指望上云后所有的安全問題都自動解決了，仍然要持續地加強自身的安全意識和安全技術能力。不過好消息是，和傳統IT比，云供應商提供了更為豐富、更加易用的安全工具集，可以幫助用戶更容易地構建一個安全服務。展開來說，包括如下幾個方面：
在數據可靠性上，云平臺的存儲服務(無論對象存儲、快存儲還是數據庫存儲)都是分布式，且數據有多份拷貝，整體來說是值得信賴的。如果仍然有擔心，云上的數據備份服務也非常方便，而且很經濟。
在數據存儲階段，云平臺提供的多種數據加密服務(各種存儲服務都有支持)是一個非常好的選擇。不僅數據加密、解密過程對用戶透明，而且用戶可以選擇不同的密鑰生成機制，保證數據安全性完全可控。
在數據傳輸過程中，無論是對外網還是在內網都可以使用HTTPS協議，并且用戶都可自帶證書。
在數據訪問權限上，云平臺提供的權限管理及主子帳號機制可以在保證正常使用便利性的同時盡可能避免權限外泄。
當然，由于國內網絡環境的惡劣性，網絡攻擊時而發生，如何保證網絡訪問安全是一個頭疼的問題。在這方面，云平臺無論從資源還是技術投入來說都會強于個體客戶，所以這方面選擇信賴云平臺也是合理的。同時，云平臺還會聚集大量的第三方安全公司，客戶從此選擇自己需要的合適云安全供應商也很方便。除此之外，主流云平臺都會主動通過各種行業安全及合規認證，這對于有行業合規要求的客戶非常有幫助。整體來說，作為技術人員，在上云過程中首先要樹立“責任共擔”的安全意識，然后重點關注云平臺的安全工具、以及云平臺推薦的各種安全最佳實踐等，并按照業務需求使用好它們。如此，你會發現云平臺其實比你想象的要安全得多。
京公網安備 11010502049343號