前言

前一篇文章提到了維護模式工具的改善結果，這篇文章主要分享的則會是 在整個過程中遇到的困難與挑戰，以及寫文章的當下，預期未來要改善方向。

困難

困難有大有小，先從大的開始講起。

首先，最大的困難寞過於原本架構的複雜與混亂。在一開始介紹舊工具的時候有提到過，舊工具的其中一個缺點就是會增加架構的複雜度。而我們在 DNS Records 上某些讓人相當混淆的 routing 方式，也直接讓我迷路了一整週的時間，最後是資深前輩的開示，才讓我發現這裡因為歷史包伏而遺留下來，不為人知的某條 routing 小路。

第二個同樣相當難辦的事情則是維護模式工具的開發。因為筆者算是從頭寫了一支全新的工具，而從零開始設計一套工具本來就會花上很多時間，但卡關最久的仍然是 WAF 的 API 設計。由於 WAF 裡面的資源都有一個類似處理狀態的 token (類似 Terraform 的 state 檔案)，因此每次修改都必須先有上次修改後回傳的 token 狀態檔，才能進行下一步的修正。

另外，因為每一個 WAF ACL 的建立都會花費相當多的時間，因此我不得不在建立 WAF ACL 後，以及建立與之串接的 Rule 與 ALB 之中，先插入一段持續確認 WAF ACL 可用性的程式。最麻煩的則是，因為每次維護都會需要多個 WAF ACL ，而筆者原本建立 WAF 的流程是一組「 WAF 、 Rule 和 ALB 串接」建立完後再建立下一組，這導致每一組都會需要先等一開始的 WAF ACL 建立好後才能進行下一步，因此會花上可能十幾分鐘的時間才能進入維護模式。最後我不得不重新設計邏輯，先建立好所有 WAF ACL 後，才接著建立各別與之串接的 Rule 和 ALB。

第三個困難點則是 Load Balancer 的升級作業。我們原本某些服務仍然在使用比較舊式的 Classic Load Balancer(CLB)，而 CLB 是無法與 WAF 串接的。因此在這整個開發流程中，我也同時需要研究將 CLB 升級為 ALB 的作業。這在架構上也是一個相當具大的挑戰，請見下圖：

這張圖是筆者在處理此問題時，當下的架構以及部署工具（後續經過一連串的改善，現在已經完全不同了）。這個架構會在下一個日常維運的系列中再分享細節。圖中需要處理的對象是 CLB 升級為 ALB。在升級的過程中，除了建立新的 ALB 和 Target Group （當時是先用手建，之後才做 Terraform Import）和調整 Route 53 的設定之外，筆者也同時要處理原本透過 CloudFormation 管理以及透過OpsWorks部署的工具，以避免新的部署遇到問題。

後記

現在想想，能夠順利完成這理的改動，真的是要相當感謝各個資深前輩的協助。但實際上這個升級仍然在不久後間接導致了另一個問題。因為 ALB 所使用的是預設 HTTP/2 以上的版本，但我們原本連線 CLB 的 Client 端則還在使用 HTTP/1.1，最後導致了預期之外的問題。我們不得不先把 ALB 的 HTTP/2 給關掉，讓 ALB 在 HTTP 版本上的回應先與原本的 CLB 相同。

講完了過程，這邊也分享一些未來預期可能的改善方向。雖然目前這個工具已經可以正常運作，但因為這是一個跑在本機的 Python script，因此仍然有因為環境而導致的各種問題。為了避免這個問題，未來一種可能的改善方式，就是將整包程式打包成 Lambda function 吧。此外如果觸發 Lambda 的方式可以更簡單，比如從 Slack 之類的地方觸發，那進入維護模式的工作甚至可以交由公司任何其它有需求的人。當然這邊在權限上的管理，就又可能會是另外一個問題了。

無論如何，這邊希望分享給讀者的，主要還是「持續進步與追求改善」正是筆者所認為 SRE 所應具備的態度之一。

下一篇，將會進入與 OpsWorks 部署有關的維運工作系列。