前言

之前的文章中帶到了 3 個大型的維運工作，接下來緩口氣，來分享一些比較單純的日常維運工作，帶給各位更日常的感受，也同時為接下來即將進入的 P0 事件系列暖個身。

主文

CDN 報表自動生產

這裡想先介紹的主題，簡單來說，就是將平常需要定期手動生產的系統報表，透過自動化的程式來完成。

說來簡單，不過定期生產系統報表給客戶，其實是維運中相當重要的環節。其實我們也可以換個說法來說，只要今天交出去的東西與客戶直接相關，那這個工作就會是一個不能忽視的重要工作。在第一個大型維運工作，也就是棒球賽的定期加開機器中，工作本身非常重要的理由，就是因為客戶相當重視這件事情的關係。

這個自動化工具的架構如下圖：

我們主要的服務是架設在一個 AWS 帳號中(圖中的 Account B )，透過 CloudFront 建立的 CDN 會把存取資料傳送到 S3 儲存。在過去的時代，我們必須要手動下載 S3 的資料並將資料重新整理到一個新的 Google Sheet 檔中。客戶會存取該檔案來獲得他們想要的資訊。

在自動化的工具中，我們透過存放在另一個 AWS 帳號的 Lambda 工具來撈取，處理該資料後再傳到原本的 Google Sheet 裡面。觸發的方式則從 Slack ，透過串接 AWS Chatbot 的方式來觸發該 Lambda 。可以參考 AWS Chatbot 在 Slack 中的樣子：

上圖是 Chatbot 實際收到指令後執行的回饋訊息。明確的指令則一開始就會先在 Slack 的 shortcut 中設定好。因此操作人員只需要在指定的時間，在 Slack 上面稍微點一點就可以完成每個月的報表生產工作了。

在整個過程裡，對筆者而有四個比較具大的挑戰：

• Google Sheet 的串接
• 跨帳號存取服務的串接
• Slack 與 AWS Chatbot
• 部署工具

串接本身所遇到的問題，大多是權限設定的問題。比如 Google Sheet 在權限上似乎在不同時代有不同的做法； AWS 跨帳號則要透過 assume role； Slack 在 Chatbot 上的串接上則要額外注意該頻道的組成成員，以避免某些成員做出預期之外的行動。

另外，部署工具所使用的 Terraform 本身沒有什麼太大的問題。但由於這是筆者人生第一次真正意義上地接觸 Terraform 的部署，因此實際上花了非常多時間處理很多基礎問題。事實上，筆者一開始甚至不小心把 Terraform state 給刪掉了，雖然反而因此學會了 Terraform import 的功能就是了。

比較幸運的是，筆者當時接手時，製作 Google Sheet 本身的 Python script 已經完成得差不多了。在下一節中，則會提到我與 Google Sheet API 的奮鬥，而我也是在那次維運工作中才意識到，這次工作中不用接觸這一塊，其實已經省下了我非常大量的時間了。

IAM user 定期盤點

上一段分享了自動生產 CDN 報表的工作。這裡則是另一個將手動作業透過程式來自動化的工作。由於自動化本身與上一篇沒有太大的差別，這篇應該就會重點分享任務本身。

敝公司使用了 AWS Organization 來管理各個AWS帳號，並透過 AWS IAM Identity Center (前身為 AWS SSO )來管理各帳號的使用者權限(permission set)。比較特別的是，我們是由 SRE 來負責管理這一塊的業務。而為了確保最低權限的發放規定，我們針對每次權限的申請都會要求申請者提出使用期限，一旦到了有效期限且沒有展延的需求，就會將刪除該權限。

然而，各個帳號基於不同的需求與一些歷史演進的關係，也會存在一些大家可能更熟悉的 IAM user，比如外部廠商要透過該 user 來存取某些S3的資源等等。這個部分的管理由於沒有像 IAM Identity Center 那樣有系統，因此我們採用了每半年手動盤點一次，如果超過一定期限沒有活動的 IAM user，向該帳號的業務單位確認欲刪除或保留。

在這個工作中最為繁瑣的部分，就是從各個帳號下載整個帳號的 IAM user 活動狀態，以及將這些活動狀態手動建立成一個供全公司其他同仁觀看的 Google Sheet 了。雖然這是一個半年才執行一次的任務，但最後筆者衡量了一下手邊的工作，還是決定投入自動化的工作。

事實上，一開始是先透過 AWS CLI Command 來簡化整個作業流程(半手動半自動化)。這樣試做了一次之後，才決定要將其全自動化。而最後的結果也相當不錯，特別是看到自己的自動化工具成功將報表生產出來之後，著實有一種歡以言喻的喜悅感吧。

在這整個自動化的工作裡，主要遇到了以下兩個筆者認為值得分享的事情。

第一個是帳號與權限問題。因為這個工具的目的是為了到公司的全部帳號中取得該帳號的 IAM user 權限，因此就會需要每一個帳號的權限。權限本身當然是在工作前先一個一個申請的，但在執行程式的當下，程式並不清楚我們所使用的權限，因此在主程式啟動之前，就會需要先增加一連串的錯誤處理，或說是權限確認機制。

此外，由於理想的自動化應該是要自動掃描過公司的所有帳號，再加上公司帳號可能會有增減的情況，因此程式設計上，也會需要保有讓使用者能夠動態調整帳號的功能。這個是在一開始設計程式時所沒有預期到的，也是一邊開發才一邊想到的需求。

第二個則聽起來有點荒謬，但筆者其實只是想要抱怨 Google Sheet API 實在有夠難找，或是說文件寫得，恩，很特殊。這特別在 sheet 的格式調整上，比如調整字型大小或表格顏色的部分，有些功能一直到最後都沒有發現做法或相對應的 API，因此最後只好直接捨棄這些功能了。

後記

無論如何，透過這兩個相對單純的日常維運工作，筆者希望能夠分享給讀者的是，雖然維運工作常常既繁雜又細瑣，會讓人做起來很沒有成就感，但將這些繁瑣的工作都透過工具自動化，筆者認為也會是 SRE 的精神之一喔。

提個外話，這個工作在筆者所負責的專案中特別重要，與該專案要導入 ISO 27001 有很大的關係。如同之前文章提到過的，後面文章會再針對這個主題進行相關的介紹。

下一篇會進入日常維運系列的總結篇，也同樣是一篇非常有趣的主題。