華爲工程師SRECon Asia見聞：聚焦可靠性、資源優化及性能提高

內容來源：2017年6月17日，華爲軟件架構師馬博文在「西安活動 | 6月17日DevOps MeetUp」進行《SRECon Asia 2017見聞》演講分享。IT 大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：1552 | 4分鐘閱讀

嘉賓演講視頻回顧及PPT：suo.im/4ViT57

摘要

軟件系統40%-90%的開銷是在維護上，對於大規模，關注軟件可用性、可靠性和性能的公司，使用軟件工程的方式去解決運維領域的問題就變成了一個選擇。由此，Google發起了SRE(軟件可靠性工程師)這樣關注可靠性的組織，大名鼎鼎的Borg, Borgmon都出自SRE之手。除了Google以外，關注可靠性的其餘大規模互聯網公司，如Facebook、Ebay、Dropbox、Linkedin、百度、阿里等也採起相似的實踐。SRECon則是這些公司分享SRE在技術、文化等方面實踐的會議。最近我有幸參加在新加坡SRECon亞洲的會議，藉此機會和你們分享下一些有趣的話題、idea以及我觀察到的一些SRE領域的趨勢。

什麼是SRE

SRE就是網站可靠性工程師。SRE對技能的要求很是高，Goggle SRE中50%-60%是標準軟件工程師，其他的要知足80%-90%軟件工程師要求，而且瞭解unix細節以及網絡。

SRE會用軟件工程的思惟去解決運維領域問題，負責可用性、性能、效率、監控、事務處理等。

SRE方法論

SRE主要關注的是研發工做，在保障服務SLA/SLO前提下最大化迭代速度。並涉及到監控系統、應急事件處理、變動管理、需求預測和容量規劃、資源部署、以及效率和性能。

SRECon Asia

SRECon的主辦方是USENIX，亞洲區會議主要贊助商是Baidu、Facebook和Linkedin。到會人數在250人左右。貢獻話題的講師都來自比較大的互聯網公司，有Google、Facebook、Linkedin、PayPal、CloudFlare、Dropbox、Yahoo、Atlassian以及REA Group等，國內的公司有Baidu、Alibaba、Didi、QiNiu、Tingyun和Tsinghua。

監控與告警

如圖所示，軟件最基礎的要求是監控，一切都是在監控的基礎上運行，只有監控到發生了什麼樣的事故，才能作出相應的應急處理。過後總結問題，分析問題根源在哪裏。對應的作出改進後進行測試，確認問題後修改代碼而後進行發佈。

Open-Falcon: Motivation

Zabbix：當管理的服務器超過2000臺的時候，它的水平擴展會比較困難。

OpenTSDB：它的優勢是寫性能，水平擴展好，可是Query慢。

InfluxDB：國外一些小公司會使用InfluxDB。它的Query性能很是好，aggregator聚合強大，缺點是水平擴展難。

Open-Falcon: Performance

容易水平擴展，每分鐘能處理百萬級transaction (query/ judge/store/search)，輕鬆支持超過100,000主機。RRA機制，能夠查詢1年曆史數據，100+ metric秒級響應時間，性能很是好。能夠存儲10年以上的metric歷史數據。

問題

運維OpenStack，修復問題所須要的知識複雜，操做過多。這些知識很難Transfer。

解決思路

使用天然語言查詢系統狀態，好於CLI和Regex。

使用最基本的規則自動發現系統知識，構建一個知識圖譜SOSG，將特定系統的查詢轉化爲圖遍歷，異常檢測發現隱藏的問題。

來自話題《Talking to an OpenStack Cluster in Plain English》by Xu Wei From Tsinghua

服務生命週期

雙分佈一致算法，Paxos算法；可靠的發射規模，發射檢查表；在雅虎Hadoop基礎架構服務器上無縫地管理變動，由Chef管理的45000個節點。

Reliable Launches at Scale

在上線前會檢查架構、容量、可靠性、監控、自動化程度、增加趨勢以及第三方（google內部）服務是否準備好，確認這些都沒有問題後纔會正式上線。

Managing Server Secrets at Scale with a Vaultless Password Manager

Key/CredenHals隨着服務器增多而增多。

在配置管理工具中保存Secrets，啓動配置管理工具須要key/pair etc，由於每一個服務器密碼不能相同致使沒法scale key，Key RotaHon。

還有一種方式是保存在服務器上，服務器啓動時生成。root password，磁盤加密比較困難，無狀態時磁盤的服務器沒法存儲。

事故管理

事故管理的一些挑戰

如何達成更短的MTTR；

不少事故的處理比較簡單，如重啓等，如何自動處理這些事故；

falsealarms如何減小；

報警如何給出正確信息，快速定位問題。

服務擴展

Small,Cheap, and EffecHveTesHng forProducHon Engineers.

Merou:A Decentralized, AuditedAuthorizaHon Service

Shameon facebook and dropbox.

容量規劃/性能調優

Capacity Planning and Flow Control

容量估算: 單機壓測；

模擬: ab/jmeter/gatling；

複製: 複製生產環境流量；

重定向；

負載均衡: weight。

Why Flow Control

隊列堆積：服務器性能下降，響應時間增長，影響應用以及用戶體驗。

雪崩效應；

須要限制過載的流量。

And a Formula!

計算原則：

EntranceSize= volume * RT(response Hme)

Requests= constants * LOAD * RT

流量控制原則：系統超載則限制volume，負載正常則去掉限制。

使用動態閾值控制。

總結

SRECon參會人數很多，交流效果也比較好。

能夠了解到不一樣的公司，好比Cloudfare，亞馬遜的A9。

雖然不少話題看着很小，可是大部分的話題都有可學習的地方。

能夠感覺到的一個運維方面的趨勢是數據流水線+大數據+機器學習+AI+Bot。

我今天的分享就到這裏，謝謝你們！