內容來源：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之外，關注可靠性的其他大規?；ヂ摼W公司，如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秒級響應時間，性能非常好?？梢源鎯?0年以上的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。
我今天的分享就到這里，謝謝大家！
