iThome DevOps 2015 研討會 Day 1 心得

約在今年 6 月中的時候,iThome 即宣布將在 9 月 1 日 ~ 2 日舉辦 DevOps 2015 研討會,並且開始廣邀徵稿至 7 月 6 日。雖然上次投稿 ModernWeb 2015 沒被選上,但不灰心本次再接再厲再次投稿,想不到還真的有幸被選上,所以除了要上台當講師的時間之外,其他時間則可以免費入場聆聽這兩日的 DevOps 2015 研討會

網路上似乎已經有一些評論與心得文,所以就不打算重述太多細節,以下就只簡單的記錄個人的幾個心得,針對每一場講題簡短的記錄:

開場致詞 - 吳其勳 / iThome電腦報 總編輯 吳總編輯提到今天的現場約有 300 多人,數量比我個人預期的少?稍微查了一下台大集思的國際會議廳座位有 368 人,首日觀察覺得約 9 成滿,所以人數應該確實是 300 多沒錯,第二天的觀察是約 8 成滿,不知是否大家對於第二日的講題比較沒興趣?

DevOps 運動的全球大趨勢 - 王宏仁 / iThome 新聞主編 王主編再次講了 iThome 網站上已經刊登過的非洲銀行導入 DevOps 的案例,這個案例之所以重要的原因是想要強調就連傳統的銀行業都已經導入 DevOps,那麼身處在軟體、網路、資訊產業你還能不知道什麼是 DevOps 嗎?

CI 伺服器全制霸!活用自動化技術重建「最強」團隊 - 直井 和久 / 樂天 旅遊業務開發維運部 旅遊網站團隊經理 iThome 最近的幾次活動都有找樂天來擔任講者,幾次下來可以理解到樂天的背後確實有強大的技術力,這次來的 直井 和久 先生也是,感覺上在 CI、Jenkins 上的經驗豐富,但實在很可惜因為語言表達的問題,導致這次沒辦法與聽眾們有更多深入的 Q&A 互動,看到他在回答時默默地自言自語說了 How to say 還真是為他捏一把冷汗。不過自己也在自我省察,因為個人在英文的「說」這一方面也是很需要加強,若是在台上遇到英文問題我恐怕也是要冒冷汗了。

樂天的簡報在此,有興趣者可由此連結前往瀏覽。

其中 直井 和久 先生有點到一個重點,不是所有的 information 都需要 measure,只需要 measure 有用的 information,這乍聽之下會覺得,咦?有些人在講 DevOps 時不是說應該要盡可能記錄所有的 information 嗎?但其實不是,而是要記錄那些真正有用的關鍵數據!因為關鍵數據才能真正反映出重要的資訊!而且 measure 在 DevOps 中絕對是一個重點,因為唯有透過 measurement 你才能知道自己目前的現況,那麼你才會有一個標準可以評估未來是否確實有所改善,就像減肥你也要先知道自己目前的體重,未來才能比較得知是否變胖變瘦。

企業 DevOps - Michael Ducy / Chef 全球傳教士 傳教士不愧是傳教士,果然是講得頭頭是道,精簡、快速、準確的介紹 What is DevOps,以及企業與 DevOps 的關係。另外 Michael 也提到一個好笑的點,他說 DevOps 一詞出現也不過 6 年,但你會看到有人宣稱自己有 10 年以上的 DevOps 經驗,這到底是想要嚇唬誰?不過如果你把 Agile、Lean 這些經驗也當作是 DevOps 經驗的話,恐怕也許就能說得過去?另外 Michael 也有提到 DevOps 並不是一種萬靈丹,有了它就立即見效解決所有的問題,DevOps 應該是一條需要時間去學習去實踐的旅程,我自己的想法也是如此,這也是為何我上一個簡報《摩登開發團隊的 DevOps 之道》中會使用「DevOps 之道」這樣的說法來描述它。

其他還有提到離台灣最近的 DevOpsDays 是 10 月份於新加坡舉辦,有興趣的人可以前往參加,不過目前還在徵求講者,所以到底有哪些講題?能否請到哪些重量級講者?這些恐怕都還要再一段時間才會知道。

如果對 Michael Ducy 有興趣,可以在 Twitter 上找到他,以及它所經營的 Podcast https://goatcan.do

Yahoo 的持續交付經驗分享 - 應百怡 / Yahoo 亞太區產品研發工程部 資深工程師 應姐的演講其實很不錯(叫人家應姐,你跟人家很熟嗎?明明就是第一次知道她),算是大致完整的分享了 Yahoo 的 Continuous Delivery 經驗,在高層梅姐的強力主導之下,Yahoo 快速的全面採用 Continuous Delivery,其實是相當好的企業案例,其中應該有很多細節可以挖寶挖出來一一分享才對。

演講的一個重點是「如何確定你所交付的是 value?」;另一個重點則是對 Yahoo 而言 CD = commit to production without human,由此就可以知道他們的 CD 想必是做的很徹底,畢竟 Yahoo 連 CD 檯燈都做出來了,有沒有問題看燈號就知道了。除此之外應姐有提到導入 CD 之後就有如骨牌效應一樣,可以接著引入更多好的實踐,像是 TDD 、refactoring。

應姐說 CD 並不難,導入 CD 也不難,因為每個公司都應該已經有自己的部署流水線了,CD 就是將其中人為的行為改用工具取代。但說起來簡單,但其實還是不容易,因為實際上可能有的變更會很大,所以在新的專案中導入會比較容易,若是在舊有的專案、產品上要導入就會比較辛苦。同時導入 CD 時,人的重要性是大於工具的,因為工具太多了,隨時都會有更新更好的工具出現,但在工具之前,你要先克服讓人們接受 CD,讓所有的人都能參與導入 CD,形成一種新的企業文化。因為人在面對新東西時都會有 5 stage of grief,這反而會是大企業或團隊首先要想辦法解決的問題,如果無法克服人的問題,那麼想要成功 CD 就不太可能了。

Q&A 當中有一個問題還不錯可以參考:

Q:當遇到需要斷網的私密型環境開如何做到 CI / CD A:私密網段建立另一個專用的 jenkins 環境,由 push 改為 pull 的方式來進行 CI / CD

在公眾雲裡建構 SaaS 的 DevOps 經驗分享 - 陳彥宏 / 趨勢科技 資深工程師 這一場其實我覺得有一點文不對題,因為內容是在講趨勢科技是如何用少量的人力將一個具有 2PB 如此大容量數據的服務搬移到 AWS,其實跟 DevOps 的直接關聯似乎有一點有限。不過整個經驗還是很值得參考學習,以下簡短紀錄幾個重點:

  1. 2PB data (約1000個兩 TB 的硬碟,要花2400 天才能傳完 2PB/ 100MBps)
  2. 實際上只花費 2RD 2QA 2Ops 來完成這個搬移
  3. 規劃到完成花費一年
  4. 經過評估,不採用 RDS 而是自行 hosted mysql
  5. SLA 想要越好,Cost 與 Complexity 會飆得越高,而且飆高的程度超乎你的想像。
  6. 採用分散式的 Ha proxy
  7. 雖然是 AWS 但針對環境還是要自行建立適當的 Monitor
  8. 針對架構一定要真正的做看看 DR Drill,如此才能測試出備份與復原計劃是否可行
  9. 在公有雲上 Security policy & design 加倍重要
  10. 因為是從自家機房搬到公有雲,因此事前有針對自家機房的硬碟健康狀態進行評估,講者提到 S M A R T 的數據中,只有某些數據與 disk 的健康與否有正相關,講者建議大家可查詢某幾篇論文。

百人工研院雲端 OS 團隊如何落實 CI - 符儒嘉 / 雙子星雲端運算 執行長 符執行長的講題重點很單純,即一個主軸「from agile to devops」,由符執行長的分享中可以聽出來是經驗豐富,特別是在 Agile 這方面,在 CI 的運用上也相當到位,特別是提到可以有三個 CI ,分別在 Feature Branch、Release Integration Branch、Release Candidate Branch。另外符執行長也同樣提到了「工具不重要」這件事,重點還是「人」。

Whoscall 的 Realtime Monitoring 經驗分享 - 葉秉哲 / Gogolook 架構師 最後又到了葉大的場子,雖然他說不要叫他葉大,但我想在大家的眼裡,明明就是資歷、經驗豐富的大神級人物,怎麼能不稱呼一聲葉大呢?而且有聽過葉大上台的人就知道,他會在現場立即修改簡報,拿前面講者的梗來使用,由此就可以知道他有多認真的在準備講題了。

這一場的重點在於 Monitoring,所以葉大也呼應上午樂天的 直井 和久先生提到的「要記錄有價值有意義的資訊」。那麼哪些資訊是有意義的呢?這就可以由「風險管理」的角度來切入,例如主機掛掉沒辦法提供服務,或主機反應太慢這可能是重大災難,這樣的事件就需要被優先透過 Monitoring 發掘出來。另外風險的另一面代表的意義是「機會」,透過 Monitoring 你也能發掘出哪些資源沒有被妥善運用,可以從中找出可以 cost down 的地方。

詳細的細節可以直接參閱葉大的簡報,所以就不再重複記錄了。最後補充一下葉大提到的 prometheus,之前也有注意到 SoundCloud 所推出的這個工具,但沒人引進門還真是有一點不太理解,沒想到葉大對它也很有興趣,而且還打算出國取經,飛去美國紐約參加 O’REALLY Velocity 2015,看來等葉大歸國之後可以好好的拜師學藝一下。

最後記錄幾個個人覺得重要的 Q&A:

Q:是一套 Monitoring 監控全部的系統 (全世界的主機) ,還是多套?是否遇到多套 Monitoring 所以要一直切換管理界面感到很困擾? A:確實有太多 monitor 及管理後台,所以在管理上很麻煩,所以 prometheus 就是一個好東西。因為是一個分散架構,所以可以在各地分散先記錄,在統一集中到總部。

Q:為何不用 elastcisearch 官方的一整套 ELK A:如果只是使用在 elastcisearch 本身,官方本身是夠用,但實際上用他自己的東西來處理有時候會有 OOM,另外 Kabana 在時間序列上比較弱一點,在數值搜尋上比較弱。

Q:Fluentd or Logstash why ? A:Logstash 是 java 寫的,太重了,Fluentd 實際使用上 Line 集團本身有在使用,所以集團其他人很推薦 Fluentd。另外,Fluentd 也可以有 HA 架構。

小結 第一天的研討會聽下來其實收獲不少,雖然確實如其他人的感想,似乎講者開場都要講一下 What is DevOps 這樣太重複了。但我其實覺得還在可接受範圍,因為可以比較一下各講者分別是從哪個角度切入,是如何詮釋 What is DevOps。另外我也覺得這狀況實在難免,因為相信光是湊齊講者就不容易了,如何在事前就針對講者的講題內容、深度與品質的控管上這又是另一件大功夫,再說有辦過社群活動的人都知道,在台灣你要找到講者不容易,要找到好的講者又更難了,若要找到講得好、經驗豐富、不藏私又能切合研討會議程主軸的講者又更是難上加難。

整個業界還是需要有更多的前輩們站出來多多分享經驗,不然每次看大型的研討會上台的講者老是那幾位,就像這次我有注意到在 Agile 經營很久的泰迪軟體似乎也有一些人來聽這次的研討會,其實 DevOps 與 Agile 是密切相關的,倘若還有這類的活動希望 Agile 方面的前輩們也能參與投稿,分享一些深度經驗。相信這次的研討會對於整個產業界還是有些幫助,至少會讓那些原本沒聽過 Lean、Agile、Continuous Integration、Continuous Delivery、DevOps 的人開始知道這些東西,讓這些詞再次被炒熱,以這樣的角度看來其實大家都還是能從中有所獲益的。

轉貼本文時禁止修改,禁止商業使用,並且必須註明來自「艦長,你有事嗎?」原創作者 Cheng Wei Chen,及附上原文連結。

工商服務

更多文章