TenMax 飛主堡 事件紀錄 與 回顧會議

前情提要:

TenMax 將整個 RD + PO 拉到新竹基地(高鐵前的PS3大樓) 一整天的時間 一起討論 1個 SRE 事件的演練:「當目前混合雲的服務,若當機房IDC出問題的時候,需要整個服務全部要飛上雲端環境的應變與執行步驟。
(飛主堡 至 全雲端環境 以及 最後回復到混合雲的狀態) https://www.facebook.com/tyhsiao/posts/10215776071096896

TenMax 的飛主堡演練已於 7/25 10:30am ~ 7/26 11:00am 執行完畢。而今日也進行了一些Retro,整個Retro的時間大約花了2hr結束,16個人參與。大致上透過這篇Story來跟大家分享一下我們的反思會議內容:

第一階段: 簡單的復盤

在執行演習前,我們就已經有先指定好兩個區域指揮官(因為TenMax的研發人員是跨新竹/台北兩個基地),一個演習過程的紀錄官,以及特地於Slack上加開的兩個Channel (一個用於討論、一個用於紀錄過程資訊),因此復盤變得非常簡單:

紀錄官的 memo (部份):

第二階段: 反思

大致上將大家的post-it的內容統整如下:

What Went Right? Benefit Gains? (做對了什麼? 得到什麼效益?)
  • 有先讓各component owner解說大架構,大家對於平常沒經手過的元件(新竹台北互相多了解)有更多的認識
  • 有實際操作經驗,大伙都學著用/看Prometheus與Grafana,技能++,也讓Dashboard又進一步更豐富。
  • 事前有討論切換過程中的預期狀況,執行過程中也有比對跟觀察的依據,執行上比較有信心也比較能知道馬上要採取應對措施。
  • 有事前先加開機器並standby,減少了實際執行所需花的時間(降低執行切換的 cycle time),降低當日對商務上的影響。
  • 二年前的code在這麼久後又搬出來用,有機會重新驗證了一下,也沒發生問題,信心++
  • 額外很臨時地增加了一個很有用的測試項目: 測試並量測每個component於雲端Node上的承載能力(QPS數值),讓我們對於目前我們的服務於雲端的承載能力更加了解。
  • 發現了更多的改善的方向。

Richard觀察注記:大家對於演練所產生的價值已經開始透過實際演練操作已經深化,有所感了。

What Went Wrong, Impact, Value Lost:(做錯了什麼? 有什麼Impact? 損失了什麼?)

(有一類屬於各component服務已發現的特定想改善的功能就不列舉了)

  • Dashboard一次新增了太多項目,導致要一個個慢慢看。另外也仍缺了一些當下想關注的metrics尚不在monitoring之列。
  • 有發生Load Balancer, Response time 行為與預想的不一樣,所以造成了下午的 bid-failed rate 上昇。(原因仍未明,目前覺得還是抖抖的)
  • 其中一個服務的 VM Provisioning沒有確實做好(操作的太急),以後應該往減少人為介入方向進行。
  • 其中一個服務群雖然有預開機器並安裝完服務元件,但並沒有拿來真的測是否真的該node可正常服務。因而也導致了當天想臨時重無到有新加開雲端node來撐住,卻因為雲服務的新開node OS無法正常運作及連線,導致最終目標(全在海外serve)無法完成,只能事後向雲服務供應商開issue tickets。
  • 因上述原因,讓最後的全切換到雲端的計畫最後沒有達成,很可惜。(後述補充)
  • 其中一個服務,多開了機器,算是買了保險。但實際並不知道自己這樣會多浪費了多少錢。
Lessons Learned (你學到了哪些?)
  • 動手做才是最實際的學習方式 (關於這點,有成員補充分享說,其實他 Plan前 信心指數 4/10,Plan後 信心指數還是 4/10,直到這次做完他才真的感覺有到 8/10 )
  • 事前規劃、執行中的紀錄都很重要
  • 各類排查/操作技能++
  • Tools版本要盡早要更新(工欲善其事必先利其器),舊版的Tools功能太陽春不好用。
  • 多接觸了不同的codebase
  • 人為操作的風險很高

Lessons Learned團隊分享完後,這時我提出了一個議題,問了一下團隊,這次演練在 Ops 領域若有一個專有術語的話,是想要觀察或降低某個指標數值,到底是哪一個?

有個 Lead 沒多久就舉手回答並命中答案 了: MTTR (Mean Time to Recover)

謎之音:其實應該要讓給其他人多想想的啊~~~ ^_^~

這時,我也讓大家試著透過我們 dropbox 上 paper 紀錄的 history (timeline)來算一下,某些 故障排除的 的 Time to Recover有多少,也又跟大家講說那我們這些上面的回顧,大家剛剛提的哪些事會影響(增長或縮短)到 Lead Time / Cycle Time,以及最終 MTTR / SLA 會是怎麼個影響,哪些事情讓大家有個感覺。

What Next? (你想到的下一步是什麼?)

這邊就讓大家自由發揮了,這時大家有點像是開始搶頭香似的很想先發表。

總之這些改善項目,最後請團隊在我們DevOps Project中建立相關的tickets,後續我們將討論如何一步步安排把這些改善項目做到位。

(大家都提要 Auto-Scaling,不過這個美好的願景我們幾個Lead也都有跳出來說,這沒那麼容易啊、要按幾個步驟逐步來進行… blah blah )

最後,我也在這時總結了一下,包含了目前我們 DevOps的招募狀況/日後的維運的合作走向,預期要成立的 DevOps變革小組,以及所要達到的願景為何。

而最後的最後,我們的總Product Owner出來感謝大家這次的投入與努力、也謝謝大家都努力讓這次在Production/Live環境的飛主堡,不致降低了我們整體廣告服務的Avaliability Time。而透過這次,也證明團隊的維運是可以更上一層,更多人可以參與。但也別忘了,其實 DevOps 最後需要去服務的目標,還是 客戶商業上的滿意 ! 是的,雖然 RD 成員多數都會專注以及喜好這方面可以針對 技能/技術++ 的學習及演練過程,最終我們還不要忘了:

Agile / DevOps Practices 最後要去服務的終極目標,還是 「商業上的成功」,那才是真的!

(後續補充在此)

像是,團隊成員在最後因為想在雲服務上手動緊急加開的VM來讓服務可以在夜晚比較平順穩定,但緊急手動要新開的VM 在 provisioning 後竟然都死機。在 “堅持演習目標但開不出新vm只能以現狀去撐” V.S. “維運上的穩定度” 兩個衝突點的考量之下,最後,團隊決定採取退一步的策略,切換至 SG:TPE = 2:1 ,來讓服務順利過夜,讓我們在服務上不會造成問題而有商譽上的損失。

會顧慮到 商業上的運行,是好事。

而在Retro的過程中,團隊也針對 是否 要堅持住 做了些討論及交流,有些人想繼續嘗試,有些人想要先確保沒有問題,但確實不能忘記,商務上能穩住不造成問題,其實是很重要的事情!

而這次我們也觸及了不少文化上的議題:

堅持到底 vs 妥協、相信團隊 !

Effective DevOps 四大主軸: 協作、親和力、工具、擴展 的四個議題,這次的飛主堡計畫、執行與 Retro ,這次,一個都沒少!

我們仍持續的在招募 DevOps Engineer / SRE Engineer 喔,有興趣加入我們的歡迎與我們連繫:

在此誠徵專職的 DevOps / SRE 來與我們一起共同讓數位廣告的服務可以更上一層,也可以讓團隊進入到打亞洲盃的程度。歡迎有興趣的朋友一起來努力。歡迎與我連絡。在這邊可以摸到每天上億等級的流量(廣告相關的請求與相關活動)的營運環境,雖然目前還不是世界級的流量但在也已算到達了大數據等級的流量了。

職缺內容可參照 
https://www.104.com.tw/job/?jobno=5wxmv
,不想透過104的也可以直接 fb messenger 與我連絡。

附錄產出:

演習行前準備
  • 產生了8份文件(共6398字)
  • 產生了9個新的Grafana Dashboard
  • 新建了15台機器
  • 一併解決2個跟切流量有關的known issues
  • 實際演練各component服務的開機器與佈署
演習後產生的價值:
  • 機房流量跟Cloud流量會更為順暢
  • 緊急應變會比較有經驗
  • 同仁對於整個網路架構更為暸解
  • 同仁對於加開機的流程更為了解