文/授權轉載文章 | 2015-09-02發表
圖片來源: 

林小草

作者：網絡行動科技NETivim工程師鄭富源 和「林小草的光影切片」網站，本文經作者授權轉載。原文網站連結

會議內容不可以錄音錄影，所以這次就只有我的筆記囉。話說過程中因為太多我不懂的東西了，所以我好放空～所幸我在 facebook 打卡後，Gloom 學長浮出水面說他也在現場，我立刻回到大學模式，厚著臉皮端著電腦跑去找他吃飯聊天講八卦兼要筆記，哇哈哈～

【開場致詞：iThome 電腦報總編輯吳其勳】

總編喊了活動名稱，我才發現原來 “DevOps” 的發音是 "Dave up"，我都分開唸挖哈哈XD，而且總編說國外 DevOps 已經熱了一段時間，我要不是因為這場活動我根本不知道這名詞，媽媽對資訊業的脫節感好重。XD

總編致詞提到傳統佈署的期程都以週與月來計算，南非有間銀行導入 DevOps 前，每次佈署約要四週時間，導入之後每次更新只要 17 分鐘。好驚人的時間差距！「天下武功，惟快不破」，主席認為提升佈署速度是有助於增加競爭力的。

一般會有「只有做網站的才需要 DevOps，一般企業沒有導入 DevOps 必要」的迷思，總編也希望能夠透過這個研討會打破這樣的概念，讓大家可以從中互相交流對自己公司有助益的技術。

【DevOps 運動的全球大趨勢：iThome 新聞主編王宏仁】

簡報裡以非洲最大標準銀行 (Standard Bank) 為例，這間銀行在南非是大型主機供應商眼中的大客戶，營運上有採用新的前端技術、也有傳統的後端作業系統平台。2014 年，他們先花兩天時間讓 35 位高層主管瞭解什麼是 DevOps，瞭解導入的技術名詞、可能造成的衝擊，以降低未來導入時的阻力。

接著他們在導入時把一群人帶進 war room，為導入 DevOps 的團隊設計了上頭印有 “chop chop” 的上衣。“chop chop” 在非洲土語有笨蛋的意味，在粵語裡則有「快」的意思，在這個銀行導入時，一方面自嘲導入這個技術像是笨蛋一樣，另一方面也是互相督促要加速導入這個能夠讓開發流程更加快速的概念。

導入前，每次佈署約需花三個月；成功導入後，每次佈署只要 17 分鐘。（備註：我覺得這邊數據有問題，因為我算起來三個月並不是十七分鐘的兩千倍啊，總編提到的四週換算起來比較接近兩千倍⋯⋯不過重點是大大地節省了兩千倍的時間！）

〖相關連結〗

【CI 伺服器全制霸！活用自動化技術重建「最強」團隊：樂天公司旅遊業務開發維運部 旅遊網站團隊經理直井和久】

在 2014 年樂天因為服務過多，造成無法正常讓原有的 CI 運作，這個 talk 就是要講這個問題的排除過程。講者邊講也邊鼓勵大家，要去日本玩也可以使用樂天旅遊服務噢。XD

一開始會想要做改變，是因為原有的 CI server 已過載，無法如期上線，且再增加新的 job 就會使得 CI server 整個掛掉，使得後續營運都無法正常運作。原有的 CI server 上有超過 400 個 job，只有一台 server 來處理，無人維護、監控⋯⋯總之是問題重重。為了不讓客戶流失，所以重組了團隊來處理這些問題。先定義出問題與要監控的標的後，增加了四台 server 來處理 CI，將原來的 server 作為 master server，利用 docker 將 master & slave server 之間互相同步。使用 docker 的原因是對系統維運人員或開發者，docker 都很好上手。為了降低開發人員與維運人員之間的溝通落差，採用 chef。

未來要面對的問題：增加 UT (unit test) 涵蓋率。

〖演講後的 Q&A〗

  • Q: Roadmap 上有兩段與原本規劃落後甚遠的，似乎如何讓新手對新制度與工具上手就是最難的地方？有沒有什麼訓練的技巧？ 

    A: 兩三年經驗的工程師對學習技術還算容易上手，但還是需要花個一兩週時間來學會技巧，熟悉整個流程需要約一個月的時間。
  • Q: 前面有提到 Jenkins 很慢，那為何使用 Jenkins? 花多少時間做 test case？ 

    A: 選用 Jenkins 只是因為我們有成員希望用它XD。
  • Q: 如果 job 會與其他 sub-system 相依，在 CI 上怎麼處理這個問題？ 

    A: 架一個 serer 來降低 API 的 loading。
  • Q: 如果 master server 的 Jenkins 掛了，要花多久時間復原？

    A: 環境放在 docker 裡，所以下個指令就可以 recover，大約一小時左右就可以復原。

〖相關連結〗

【企業DevOps：Chef 全球傳教士 Michael Ducy】

DevOps 始自 “10 deploys per day"。

搜尋 “DevOps” 可以找到一海票用這名詞包裝過的 solution、一海票相關的職缺，明明是 2009 才出現的名詞但是卻有人號稱有十年以上的 DevOps 經驗⋯⋯DevOps 應該是種文化、是種專業、是種行動 (movement)，而非單一的角色或職缺。導入 DevOps 是為了讓組織變得更好，而非只能應用在新創公司 (start-ups) 或網站相關企業。

DevOps 應該是 CALMS 這五項要素的實踐:

  • Culture: 鼓勵學習、鼓勵改善與犯錯、讓組織變得更好的文化
  • Automation
  • Lean: 採用精實原則持續改善
  • Measurement 
  • Sharing

採行 DevOps 時，要考慮 DevOps 的風險、成本與速度。演講裡提到的案例：Major Telco 導入 DevOps 之前，需要 4 週佈署，現在只要兩小時；當時週日沒有維運人員 (op) 可以為顧客服務，現在則全年無休。

每天都在 release 時，要花多少時間在這些流程上？換句話說，浪費了多少時間？相對於 Muda（浪費），應該追求 Lean（精實），可以嘗試來個 30 天挑戰：

  • Time boxed project
  • Gives organizations chance to experiment
  • Eliminates old processes to prove new
  • Eliminates waste

DevOps Dojo：

  • Build a team of experts（成立專家小組）
  • Use those experts to tran other teams（由這些專家當種子，去帶其他人）
  • Execute a 30 Day Challenge to prove the methods（執行 30 天挑戰，透過實作驗證做法是否正確）

這一場有提到可以利用一些工具來讓工作上的資訊互動更好，除了熟悉的 GitHub，Ducy 也推薦Slack、Google Hangout 來作為工作上的資訊交換輔助。

 （備註：演講裡有提到 coaching kata 這個字眼，kata 好像也是日文來的，這個講者對日文好有愛噢）

〖相關連結〗

【Yahoo的持續交付經驗分享 (Continuous Delivery @Yahoo)：Yahoo 亞太區產品研發工程部資深工程師應百怡】

在開場之前，先問了現場一個問題：大家 release 的頻率有多高？現場的從業人員大約都是每個月更新一次以下。通常我們交付 (deliver) 的目的是要交付出有價值之物，簡報的開頭先以一個誇張的例子為例：需求者希望能得到一張「久坐不累」的椅子，結果產品開發部門提供了一張讓人根本不會想坐在上頭的椅子（這樣就不會久坐，當然也不會坐到累了XD）。在 Yahoo 內部的持續交付，是不由任何人為介入、完全自動化的。在導入 CD (Continuous Delivery) 之後，更新頻率高了四倍、品質也未下滑。對所有人來說都有進化與好處：

  • Developer: 開始習慣先寫測試
  • QA: 更知道測試時要 focus 在哪裡
  • SE: release 成本變小，有更多時間可以做其他有價值的事
  • Product Owner: 專案可以更順利的推展

想推動  CD，得先要塑造一個文化是讓大家都覺得 CD 是一個正常的事，這也不是只有工程師一個人的事，而是整個組織都需要進來幫忙的，無論是 developer, QA, SE or PM。在初期大家不免會有抗拒的情緒。

導入 CD 需要有強而有力的主管來協助，否則同儕之間可能會有抗拒新的作業流程的狀況。以 Yahoo 而言，Marissa Mayer 非常強硬的不允許任何 exception，所有專案都要進 CD；過去的手動測試也不用直接進 CD，應該轉成自動化測試。

Yahoo 計畫導入 CD 的期程僅兩季，由於其內部使用的程式語言眾多、server 也非常多，所以訂定出一些大方向的規則要求所有專案共同遵從：

  • 所有定義的 build 要可重複 (repeatable)、可重新產製 (reproductive)，例如這個 build version 在同一台主機上重複做個十次也應該都產出一樣的結果，哪天 server 掛了，在新機器上應該也要能夠直接佈署
  • 所有的 code 都要可追蹤 (traceable)，可以看得出來異動了哪些內容
  • 所有的程式都要進版本控制 (version control)
  • 先停下手邊的開發來做 CD (STOP development and Do it)
  • 初期讓資深工程師來做，不讓新人做 (Use Senior Engineers)

導入 CD 之前的 release 是通霄達旦的關在 war room 裡等待上線，導入之後，即使是正在 release，看起來也無異於平常開發。Yahoo 有一種特殊的檯燈，亮紫色就表示 build 有問題，亮黃燈表示正常無事。

〖演講後的 Q&A〗

  • Q: 簡報裡有提到 SVN 換成 Git，原因是什麼？ 

    A: 不確定決定的原因，但就自己是個開發者，感覺到的轉至 Git 的好處是，分散式的控管變容易了，code review 也容易，要 folk branch 也容易。
  • Q: 如果不是高層強力推行的話，一般在 release 失敗時，會有壓力反撲要求停止 CD 導入，要怎麼推？另外簡報中提到測試，原本是以人工測試為主、unit test 為輔，後來轉為以 unit test 為主，這個反轉是怎麼辦到的？ 

    A: 追本溯源還是要 manager 來推。 XD 另外之前有推過 CI 但是因為只是 CTO 推動，所以還是會得到阻力，最終還是要最高領導者或真正能做決定的人來推行。至於測試，必須要讓工程師自己感受到 unit test 的自動化帶來的好處，才能夠從根本取代掉人工測試，最初是先把幾個重要的 test case 先轉成自動化。
  • Q: 金融系統會把網段切成兩塊，分成測試與正式，不知道 Yahoo 有沒有類似的困境？ 

    A: 在一般網段會一路 push，到了特殊網段則會用 pulling 的方式，確定可更新才開始做後續的整合上線作業。
  • Q: 遇到阻力怎麼辦？ 

    A: 只要高階被說服，通常就會成功了。阻力如果很多，就從肉粽的最上層開始解決吧，假設高層也很難說服，就先找一個不是那麼至關緊要的先做 pilot，等到 pilot 成功了就可以拿來當案例說服長官了。 XD
  • Q: 四個 form 的 Jenkins 是互為 backup 嗎？ 

    A: 因為有專門的 tools team 在管理，所以細節開發人員這邊不是很清楚。
  • Q: 不同部門之間想法可能各異，如何交流？ 

    A: 比方說，有些 QA team 可能沒有寫測試的習慣，可能就是與他們分享自動化測試的好處，讓他們瞭解自動化測試就可以不用在 release 當日待到那麼晚。

【在公眾雲裡建構SaaS的DevOps經驗分享：趨勢科技資深工程師陳彥宏】

這場要分享的是移植 2PB、約十億支的檔案的大量資料到公有雲 (public cloud) 的經驗。這個案子由兩個 RD、兩個 QA、兩個 OP 來協同作業，將資料佈署到 AWS 上。在趨勢的 DC (data center) 的架構裡有用到 MySQL, Mamcahed, MogileFS，這些東西就以 Amazon 相關的服務來替代，例如 MogileFS 就用 Amazon S3 來取代。

但是在 AWS 上，和傳統的資料異動不同，像要改某個檔案裡的 100bytes 的資料，以前只要開檔、存檔就可以了，在 AWS 上可能得先把整個 project 下載下來，改好以後再整包丟上去，所耗費的時間會變多、也必須在雲上準備適當的空間以便未來做檔案置換。一定要做消防演習，確保事件發生的時候 backup 是有用的。DR drill (Disaster recovery drill) 可以拿來驗證系統可承受到什麼程度的災害。一台機器在雲上開起來，如果沒有做好適當的 security policy 設定，可能很快就被打進來了，所以可以的話就用兩階段認證、設定 IAM-role 等等，

〖演講後的 Q&A〗

  • Q: 前面其他人都有提到文化與主事者的支持，在趨勢是否也有什麼特別的導入經驗？

    A: 每個 project 都有很高的自由度，目前不是每個 projects 都要導入 DevOps，但是老闆都開放大家自由選擇想要用什麼技術。
  • Q: 專案會由誰來主導？是由 developer 或是 infrastructure architect 來主導？ 

    A: 專案中有 project manager，開發者與架構師這兩者之間不會有誰主導誰，彼此間是協作的關係。
  • Q: 2TB 的資料移至 AWS 花了多少時間？頻寬大小多大？如何檢查資料連續性？ 

    A: 頻寬約 1GB（←備註：有點驚人，不確定有沒有聽錯）；我們有做 database checksum 的確認，檔案也有抽測。
  • Q: 在趨勢，RD 本來就熟 infrastructure 的東西嗎？

    A: 在導入的過程開始把資料慢慢帶給他，或是在其他專案執行到特殊狀況時就找他們來一起看。

 

【百人工研院雲端 OS 團隊如何落實 CI：雙子星雲端運算執行長符儒嘉】

從 Agile（敏捷開發） → CI（持續整合） → CD（持續交付），大家會越來越快接受新的典範，例如接受電話、電腦、手機、智慧型手機的整個過程，大家會越來越快速接受新技術。在 2001 年左右，scrum 出現了，大家接受 agile 這樣的開發模式。以符執行長的經驗，他們習慣以 trello 來做專案的追蹤工具。他推薦使用 spiraTest，每個 build 的 result 都可以記錄下來，test 有幾個 pass、幾個 failed 都可以被記住，這個工具的費用也不貴。

“DevOps is an evolution from Agile.” 上頭的人 (senior manager) 要支持，也要保留學習的時間給底下的人，DevOps 的導入才能成功。

〖演講後的 Q&A〗

  • Q: 做系統時，目前有很多硬體還是沒辦法模擬的，例如 switch 的品牌等等，不知道有沒有什麼自動化的測試資源可使用？

    A: 確實有些硬體設備在軟體面無法模擬，僅能用 spec 來做測試，但又因為每個 vendor 不一定照 spec 做，還是要手動做測試。
  • Q: 有沒有說服老闆導入 DevOps 的技巧？ 

    A: 要有 KPI 吧！（笑）以前很多人會說系統廠開發是沒辦法用 agile development 的、只能用在網路業，但是現在 agile 也變成通案了。
  • Q: 從 SVN 轉到 Git 有沒有什麼推薦的升級工具 (migrate tool) 或是 log 的轉檔機制？

    A: 剛好在這個導入是新專案，所以沒有升級 (migration) 的疑慮，偶爾參考到原有專案的 code，還是回頭去看 SVN 上的 log。

【Whoscall 的 Realtime Monitoring 經驗分享 (How Realtime Monitoring Works in Whoscall)：Gogolook 架構師葉秉哲】

這一場演講結束後講者當日就在 facebook 的 DevOps Taiwan 社團公開了簡報連結。

 

首先先提到有張 DevOps 相關工具元素週期表，是國外有人以元素週期表的概念整理了所有 DevOps 工具，不過 Gogolook 並沒有神農嘗百草的把全部都試過一次，這邊主要是講週期表最下面的監控工具，都是目前他們用得很流暢的，在此拋磚引玉。

在導入工具之前，首先遵照 PMBOK，為系統做風險清冊。對 Whoscall 而言最嚴重的就是 APP 當機、服務或資料庫停擺，影響較小的就是效能降低之類的，前者是一發生就要立馬處理的。

Whoscall 的架構裡有使用到 CDN, load balance 等。就像前面提到的，影響最大的風險 app crash & service outage，維運人員會監控它們是否正常、回應時間是否正常、有無 error 等。會使用 pingdom 來確認網站服務是否正常。如果有異常，會發 slack 出來通知維運人員。

資料庫要監控有無正常 I/O，或是資料可否正常取得。MongoDB 只要安裝 mongo 的 cloud manager，資料會被傳回 mongo 網站，維運人員可以到網站上看維運的報表。如果需要 cluster 等級的升級，還有付費功能可以買。

程式的效能降低時，可以透過 AWS cloudwatch 來觀察，不過沒辦法看到 memory space & disk space。加上有些記錄不會長期留存，所以會先用 fluentd 撈出來，再轉到 StatsD 裡。

詳細的 fluentd 說明可以參考另一為 gogolook 工程師曾書庭在 Taipei.py 的分享：

一樣是曾書庭分享的 Gogolook 使用的工具，還有這個《使用 Elasticsearch 及 Kibana 進行巨量資料搜尋及視覺化》：

把 raw data 轉存到 StatsD 裡後，可以搭配 Grafana 看報表。在 Java 裡，可以使用 Metrics 來做資料的轉換。相關的使用可以參考 Alan 在 JCConf 2014 的分享。

 Prometheus 是個多維度的時間序列資料庫，可以做很多統計學家喜歡的複雜處理(slicing and dicing…etc.)，能比 cloudwatch & StatsD 更具彈性。 

〖演講後的 Q&A〗

  • Q: 目前遇到的問題是工具太多、dash board 太多了，要四處看資料，有無其他輔助工具？

    A: 使用 Prometheus 就是為了解決這個問題。
  • Q: 在維運上成本與人力配置的狀況？ 

    A: 成本部分因為不直接管錢所以不清楚，不過 BigQuery / EC2 都不貴；人的話，在 Gogoglook 每個人都有能力可以開發、寫程式、監控、處理問題，真正專職做 OP 的人只有兩個，其他 developer 都可以同時處理佈署、監控等問題。
  • Q: 有監控到個別使用者嗎？ 

    A: 要抓刻意做怪的使用者是靠 API 這邊 log 使用者行為，再從 dash board 人工判斷是否有異常的行為。
  • Q: 有沒有 guidline 來要求工程師要寫怎樣的 log，以避免 GIGO（收到太多垃圾資料）？ 

    A: log 當然是多多益善，各個程式語言都有自己的 log library，問題在於工程師不會勤勞的寫 log，通常都是遇到問題後回頭檢討補上 log。
  • Q: 在 docker 上 monitor，應該從 container 監控還是主機比較好？

    A: 應該要看產品，像 Prometheus 有針對 docker 去做分析，所以可以從 container 去做分析。
  • Q: 即時監控對效能有影響，是所有監控都持續一直跑嗎？還是特定期況才打開？ 

    A: 其實沒有真正的 real-time，像金融業的 real-time 是以秒為單位、電信或飛彈可能以毫秒為單位。real-time 產品的監控對系統造成的負擔，是取決於監控的工具，越新的工具 overhead 越小。很少人看的報表就會在每季檢討後關掉。

〖其他補充資料〗

〖其他人的心得文〗

〖我自己的心得〗

  • 今天的重點關鍵字應該就是 docker、chef、Jenkins、slack 了，都沒用過。XD
  • 這天議程最喜歡的就是最後一場 Gogolook 的監控心得分享，真的好想哪天去別人家公司待個幾天，看看別人都怎麼用工具、流程怎麼走啊！
  • 其他議程強調文化的形塑，我覺得比較適合講給高層聽、或是企業內訓的時候講，這種頂多派一兩個人出來上課的場合聽到回去實在很難改變什麼，只能默默把種子放心裡了XD。其中有一場，好像是 Yahoo 的應百怡說的？該場講者在 Q&A 時提到，高層是工程師上來的，就比較能接受新技術導入、願意主導這樣的文化。

 

熱門新聞

Advertisement