5 月 29 日，阿裡雲開發者大會的《基礎設施的雲上管控》分論壇上，Mobvista 資深運維架構師于龍水發表了主題為《雲架構下的運維體系建構》的演講，詳細闡述了如何高效地用雲以及雲上成本優化的五個方向。
Mobvista 資深運維架構師于龍水
本文根據于龍水的演講整理成文。
為什麼要用雲？
首先來看一個比較簡單的雲的原生态架構。相較于傳統 IDC 來說，雲計算的架構有五大特點：
- 開發要求變高。上雲需考慮單機能力、請求能力、負載能力和轉發能力。
- 伺服器數量變化。雲上資源可以自由地彈性伸縮，資源不再固定，這對運維人員挑戰很高。
- 資源使用率高。雲計算平台最大的特點是高彈性，能根據使用者需求提供雲資源，提升整體資源使用率。
- 業務增長不受限。上雲後，可以靈活地使用雲資源，随時調整雲的使用量。不論是目前的業務，還是未來的業務都不受資源限制。
- 安全性高。像阿裡雲的公有雲，都有一套内置的安全方案。隻要用雲，就可以免費使用這套安全方案。在雲上，安全方案會提醒 DDoS 的觸發時間、處理情況與結果。是以，安全性會相應提高。
如何高效地用雲為企業服務？
既然相比 IDC，上雲更符合企業發展方向，那如何高效地使用雲為企業服務？
用雲的最常用思路
考慮到每家業務的特殊性，先來看看用雲的最常用思路。
- 先配 VPC。通常網絡配置裡包含了 VPC 和 Subnet 的選擇。
公有雲的 Subnet 跟它的可用區有關，一個 Subnet 對應一個可用區。Subnet 需要關聯什麼樣的網關，也都要進行統一設計。
這裡，最容易讓人忽略的是，設計 Subnet 時 IP 預留不足會導緻後續資源在擴容時機器無法鋪開。
- 選擇計算資源。注意規劃好是否需具備彈性與伸縮能力。
公有雲平台的執行個體計費方式是多樣的，比如阿裡雲平台上有包年、包月、按需和搶占式。采用一種多比例的配置設定，才能既達到資源的高使用率又享受到低成本。做計算資源時也要計劃好負載，雲平台一般都會提供相應的負載，像 SLB 或 ELB 等。
- 存儲資源意識。存儲資源用的好，可能比計算資源要節省的多。
- 權限配管。在公有雲裡，權限配管涉及兩個部分：
- 使用者可以申請一個權限對雲資源進行操作；
二是資源的 RAM，作為一個使用者可以去控制資源，這很容易了解。但很少人了解，可以用一個資源控制一個資源，但這非常有必要。
舉一個例子：我有一台 ECS 機器，想操作一個 RDS 或 OSS。我隻需要把權限給這個 ECS 即可，不用暴露任何的 access key，隻需要從背景授權給他某一個 OSS 或者某一個資源的權限。這部分是很多人會忽略的或不願去配的，但卻相對來說更安全。
監控要有一定的智能化
接着我們來看看智能監控，監控主要分為資源、業務和應用三層。
第一，資源層。如 CPU 情況、記憶體、磁盤、IO、網絡流量，這些屬于雲平台的底層資源，監控好資源狀态情況，可以保證資源的穩定運作。
第二，業務層。深入業務内的監控項，比如廣告業務會監控召回量、日志情況和廣告傳回延遲等，保證業務異常能及時捕獲并處理。
第三，應用層。隻需看應用本身的狀态，如端口監控、服務存活等，保證資源正常情況下、應用是正常提供服務的。
做好監控以後，一定要讓這個監控有一定的智能化。監控智能化主要展現在讓不同組的機器去監控不同組的項目，這樣新起的機器才能進行分組、分類的監控。
在建立監控的雲伺服器時，會有多個 public 的 template，大家都會用的 CPU、記憶體、磁盤 IO 等屬于公共類，然後基于 public、再根據不同的業務内容建立專有的 template。基于專有的 template，最後是雲主機、Agent，Agent 會自動關聯不同的 template，這樣一組機器都是基于同一個 template 做的監控，最終形成一個比較完善的體系。
監控報警的更新
有了監控就需要進行監控的報警，報警分為兩類：
一類如 sent message。有 high level 和 low level 兩種情況。
另一類，報警更新情況。比如 5 分鐘報警情況下是一個 low level，超過 15 分鐘 low level 可以更新為 middle level 或 high level，同時可以擴大報警人的範圍。
其中，有一部分服務是可以自動恢複的，那就無需發資訊，自己恢複即可。這就涉及一些 action，action 裡面要具備一些像 auto recovery 的功能。
運維自動化之工具、發版和部署
雲上自動化的必要性要比 IDC 強烈的多，因為雲上資源比 IDC 複雜太多，而且機器的數量多、種類會更多一些。怎麼做運維自動化管理呢？運維人員可以自己開發或者借助雲平台提供的自動化工具來實作。
三個運維自動化工具
雲平台會提供一些自動化工具，包括各類語言的 SDK 和 CLI 等工具，其中 CLI 是一種指令行的工具，通常運維人員在用指令行的時候是大部分開發人員不能比拟的，運維人員可以用 CLI 的形式來實作部分自動化工作。
同時，雲平台還提供了元組資料，提供一個專有的 IP 接口，你在本機上調 IP 接口時，會看到本機上的資訊，包括 instance ID、public IP、網卡資訊，你可以利用這些資訊去做一些事情。
既然用上了工具，就可以進行自動化的管理。
通常情況下，最多用的是如何執行批量、怎麼去歸組。建立好相應的 CMDB，是所有資源的核心，一定要在 CMDB 裡面才能對所有資源核心進行管理。CMDB 的建立有兩個提示：
- 通常雲平台會将資源資訊提供在 SDK 裡，可以直接查詢它相應的執行個體資訊，然後将它寫入 CMDB。這個方法方式有很多種， Github 開源裡面有好多别人已經寫好的，你直接調就行了。
- 盡量選用 Go 語言做 CMDB 的開發， Go 語言的并發能力和親和性相對來說好很多；Python 的話，并發性比較差，調用 CMDB 接口等待時間比較長。有了 CMDB 後，當用 Ansible 或 salt 調機器時，可以從 CMDB 裡進行一些分類歸組處理。
運維自動化——發版
相應的 CMDB 建立好了，批量工具也已經做好了，做好批量工具，後面是正常的操作發版。相信每個運維人員都會面臨發版的問題，在雲發版的情況下，這地方就很有意思了。
假如說，發版的情況下恰好遇到有機器起來了，起來的機器那些發版内容到底是最新的還是舊的？
我提供幾個處理技巧。
在發版時因為有版本控制，有的是 gitlab 或 SVN。在發版時，預先将第一份發到一個固定路徑，可以是 OSS 或其他托管類目。放到 OSS 下，這是發第一份。發完以後，通過批量工具發你現有的線上目前存活的機器量所有的版本。
這時候如果觸發自動伸縮，進行擴容機器時，這時擴容的機器可以在啟動時直接從固定路徑拉最新的代碼，這保證了不論是擴容還是主動發版的内容都保持最新版本。
再看自動化監控，這裡指自動注冊與自動解注冊。由于雲的不固定性，可能遇到擴容時機器建立了。作為監控人員不能手動配置把它加到監控裡，延時也不固定，在晚上也無法及時處理，是以一定要具備自動監控能力。
- 自動注冊：像最常用的 Zabbix，在啟動 agent 時必須要自動注冊，注冊自己的内容。配置如 matadata，把特征值上報給 Zabbix server，從 matadata 進行歸類，找到不同的 template，這樣不同的執行個體會注冊到不同的 template 下面去，才能做到自動注冊的歸組。
- 解注冊：最難做的地方還不是注冊，最難做的實際上是解注冊，建議多利用雲平台的雲監控。用了雲監控，每一個執行個體或者每一個資源的操作都會有一個事件，隻要捕獲到那個事件、分析事件的内容，然後進行 Server 端解注冊工作。
運維自動化部署
我們要搭建一套廣告平台，特别是多 region 部署時，非常繁瑣，我可能在新加坡部署了，我可能要去美國部署，可能要去法蘭克福部署。是以，在自動化部署工作上，要善用公有雲提供的編排工具，阿裡雲叫 ROS，AWS 叫 CloudFormation。
編排工具屬于一類特殊語言，内容是一個 yaml 檔案，包含你所有利用的資源，資源内的一些環境處理、鏡像和一些網絡的建立都可以在裡面預先設定好，設定好後可直接實作一鍵部署基礎環境。
雲上成本優化的五個方向
我們用雲是因為它的成本，但如果用不好雲，成本反而比 IDC 要高。
在成本節省方面有五個方向和大家分享一下：
1. 成本可以節省最高的一個方案—搶占式執行個體。搶占式執行個體是一種按需執行個體，相對于按量付費執行個體價格有一定的折扣，充分利用搶占式執行個體來節約計算成本，最大可節約 90% 的計算成本。
- 彈性伸縮。用了彈性伸縮後，才能認為我們的業務是上雲了，你用了彈性伸縮以後，成本最少可以減少 30% 左右。
- 多利用 OSS 的特性，不是所有東西都要放在計算節點上作為存儲。OSS 其實有标準計費、低通路計費、歸檔計費和冷存儲計費多種計費形式。可以寫一個自動化的腳本或者自動化的工具來檢查這些資料的通路頻率，将他們轉化成不同的計費方式，可以很大程度上減少存儲費用。
- 控制資源方面。要定期清理空閑資源，也是一筆不小的費用節省。
- Tag。合理利用 Tag 做好分組，按照不同 team 進行分組，就可以知道各家的用量，進行成本歸類，分析優化點。
最後介紹一下我們自研的一個 SpotMax 工具，它增強了像伸縮組關于 Spot 執行個體的用法。解決如當遇到 Spot 回收情況下該怎麼做或者當遇到資源不足情況下該怎麼做的問題。
這個功能最基礎的一點是當遇到 Spot 執行個體回收的情況下，提前補充資源，然後補充到 scaling 裡面，這樣就不會有一個損失。最基礎的功能是，像搶占式執行個體會提前告知你下線時間，讓你有一定時間補充新資源，以替代舊資源。再進階一點，當想去補充時，可能拿不到搶占式執行個體 Spot。這時就嘗試補充一個按需機器，補完後後再去探測，當能夠拿到 Spot 時，再替換按需執行個體。
同理擴容失敗也是一樣，擴容用 Spot scaleup。但擴容失敗，就補充一些按需執行個體，按需補進後會繼續去輪詢，能夠拿到 Spot 時再把按需的替回來。這既能夠保證這個服務業務的穩定性，也能保證使用的成本是最低的。
基于這種方案，我們自研了 SpotMax。SpotMax 現在可以節省最多 90% 的成本。
目前 Spot 執行個體支撐了彙量科技全球廣告業務的發展，并取得了很不錯的成果：廣告平台是中國第一，全球排名前十，覆寫的流量國家有 200 多個，廣告的日請求大概 1000 億次以上，一些模型特征都在百億級以上，但是廣告平均響應時間基本上都在 50 毫秒以下。