內容來源：2017年6月17日，華為軟體架構師馬博文在“西安活動 | 6月17日DevOps MeetUp”進行《SRECon Asia 2017見聞》演講分享。IT 大咖說（ID：itdakashuo）作為獨家視訊合作方，經主辦方和講者審閱授權釋出。

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

獲取嘉賓演講視訊及PPT，請點選：http://t.cn/Ezw4rI2

摘要

軟體系統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。

我今天的分享就到這裡，謝謝大家！