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 毫秒以下。