運維世界大會幹貨總結

02-04

演講主題

我自己聽了以下幾場：

雲時代下的運維
秒級時代下的全棧溯源
google運維解密
海量日誌搜索分析技術及行業應用案例
基於日誌數據的運維和運營之道
devops在又拍雲的實踐
魅族基礎系統運維之道
基於devops的paas運維實踐

針對我聽的這幾場演講談幾點心得體會：

現場人很多，大家對devops的熱情很高啊，可能是這幾年互聯網＋的熱炒，很多傳統廠商也轉型做互聯網了吧
對於演講內容，首先承認是有乾貨的。但是乾貨不夠干。有些演講變成了產品推銷會。
新的乾貨不多，有不少演講之前就在公眾號文章就看過了
我聽的這幾場演講，主題基本可以劃分為5類：監控， SRE, devops， paas，雲實踐。我畫了思維導圖，分享出來讓大家參考。（url鏈接在文末）

乾貨總結

下面簡要談一下這5個主題相關的一些主要觀點，詳細的內容見文末的參考資料：雲實踐

應用上雲是一種大趨勢，不可抗拒

在雲上也是有坑的，比如說很多系統參數不透明，造成排障時間長的問題

在雲上，瓶頸還在，只是被隱藏了

混合雲是一種趨勢

雲時代，運維人員的價值體現在混合雲管理，雲平台的調優，排障等等

個人觀點 : 演講的嘉賓是網易的工程師，對於網易這種大型的互聯網企業而言，他們的機器規模大，場景複雜，有深度調優的需求，因此踩了很多上公有雲的坑。對於中小的互聯網企業和創業公司，未必會遇到類似的問題。總體而言，上雲的利大於弊。

監控

全棧溯源和日誌分析都是為了快速定位和解決故障而生的

機器學習和人工智慧將會是日誌分析技術的下一代引擎

日誌分析，檢索，監控應該打造成一個ops品牌服務提供出來

個人觀點：對互聯網企業而言，日誌就是隱藏的寶藏，而日誌分析技術就是打開寶藏之門的鑰匙。在日誌分析上，已經有比較成熟的技術方案，開源的有： elkstack, 商業方案有splunk，日誌易，阿里雲LogSearch等。

SRE

SRE的兩個職責：應急響應和日常運維

每個SRE要有50%的工程時間，用於開發，用於有價值的系統運維

每個事故要6個小時去處理，這裡其實強調的是，事故後的深度分析追蹤，從故障中學習

要有計劃的安排災難演習，這樣能使系統更加健壯，更能防範於未然

應用系統的設計應該充分考慮人可能會犯的錯誤

不需要處理的告警，就不要告警

要開發能夠自愈的系統

個人觀點: 即使我們不是SRE，但是也要有SRE的心，堅持以google的SRE的標準來要求自己。時常檢視自己是否一直在做重複無意義的運維工作，是否可以自動化。做運維是管理和駕馭機器和系統，而不是反過來被其奴役。

DevOps

運維的八榮八恥

雲原生應用的12要素原則

個人觀點：話題基本是圍繞著12要素原則來講的，運維的八榮八恥可以理解為12要素原則的中文翻譯。總結起來就是設計一個可配置，高可用，自動化，標準化，可視化的運維繫統。

PaaS

提出將運維能力平台化的觀點

實現NoOps的目標，即自助式運維

構建運維自動化平台需要考慮八個方面：標準化， xaas化，持續交付，高可用架構，彈性擴展， noops，收益和風險，平台運營。

個人觀點：運維能力PaaS化是一種站在更高層面的ops視角。初級的自動化是構建一些自動化腳本和工具，但是這些工具還是需要運維工程師來執行，當用戶的需求量上去了，運維工程師依然會佔用大量的時間來處理這些需求。如果能變成可控的自助式服務，將會大大簡化運維工程師的運維工作，同時提供更快的交付速度。我自己總結了一個運維形式的演進過程是這樣的：人肉 -> 腳本 -> web工具應用 -> 供運維工程師使用的運維繫統 -> 用戶自助式的運維平台。

擴展閱讀

基於 DevOps 理念的私有 PaaS 平台實踐 http://www.tuicool.com/wx/bMriYbi
詳解DevOps八榮八恥 http://jiasuhui.com/archives/106524
來自 Google 的 DevOps 理念及實踐 http://www.tuicool.com/articles/7NFjumb
12要素原則 https://12factor.net/zh_cn/
ops world 演講思維導圖 http://naotu.baidu.com/file/4641e828c679dc46f1b1ecaa917e33d8?token=45d171bd832baf43

[歡迎關注我的微信公眾號hackstoic，在移動端獲得最新的文章推送］n