自動化的雲端費用管理

當我們有一項需要經常執行的重複性任務時，自動化會消除人工的工作量並保持一致性。 FinOps 有很多實現自動化的機會。 在本文中，我們將了解一些常見的自動化 FinOps 任務以及自動化的優點與挑戰。

自動化的最終目的是甚麼?

自動化還是不自動化？ 我們可以就組織的兩個方面來確定要或不要。 首先，我們必須概述我們希望通過自動化實現的結果。 其次，我們需要將自動化與組織內人工作業的流程進行比較，並確定自動化是否是實現我們確定的預期結果的更好方法。

甚麼是我們想要達到的成果?

確定實際成果很重要，而不僅僅是自動化實現該結果的方式。 例如，我們再回頭看一下閒置資源管理，如果我們認為目標是從我們的雲端環境中刪除閒置資源，不是有意的忘了刪除是可以原諒的。 但實際上，我們想要的結果是我們想要移除這些資源，因為它們正在花費我們的錢。 這很重要，因為我們使用這些目標來衡量我們自動化的效能。 如果我們量測關閉的資源的原始數量 — — 因為它們被確定為閒置 — — 我們不會看到通過關閉這些資源來與可以避免的成本之間的比較，我們不會看到這對我們的雲端帳單的真正影響。 如果我們有一個紀律用自動化的方式來實縣，哪麼就不會有太多的雲端資源浪費使用，我們將幫助保護自己免受未來的成本高漲的衝擊。 我們還讓組織養成了思考新雲端產品中可能出現浪費的地方的良好習慣。

再舉一個例子，標籤(tag)治理旨在推動遵守我們的標籤標準。 它通過刪除資源或在標籤不符合我們的標準時提醒我們來做到這一點。 我們將通過追踪一個區間時間內不符合我們標籤標準的資源數量來衡量自動化的影響。對於有排程的資源，我們還希望通過減少在下班時間的資源使用來降低成本。

自動化作業與人工作業

從表面上看，這似乎是一種愚蠢的做法。 畢竟，不是每個人都想自動化一切嗎？

不過，從我們試圖實現的目標中退後一步並驗證自動化是正確的解決方案是有好處的。 如果我們的目標是省錢，那麼我們應該花點時間將我們提議的自動化可能產生的潛在省錢與購買或自建自動化平台的成本進行比較。 如果我們要使用第三方平台來進行自動化作業，我們應該檢查運作成本。 如果計劃中的自動化在合理的時間範圍內不會為我們的組織省錢，或者如果維護自動化的成本將超過省錢的潛力，那麼部署該自動化就沒有明顯的商業利益。

請記住，有時我們自動化的目標不是省錢。 這通常適用於標籤治理，我們希望推動我們的標籤標準的使用。 在這種情況下，我們尋求用自動化的方式驗證將幫助我們實現目標。 例如，如果對無效的標籤資源的追踪沒有對這些不合規的標籤治理的告警做出回應的公司政策相結合，那麼我們很可能會認為自動化只是給每個人的日常作業增加噪音，而沒有實現增加標籤合規的目標。

對於小規模或變化緩慢的雲端進程，部署和管理工具來自動匹配告警可能需要更多的人力與時間的投入，而不僅僅是讓某人遵循手動流程。 但隨著我們的雲端進程變得快速和(或)變得更加動態，自動化變得更加重要。 請記住，由於我們的團隊有更多作業要交付，手動流程往往會落在清單中或被完全遺忘。 在這些情況下，自動化可確保以相同的方式按時完成任務。

有時，自動化的人力與時間投入 — — 可能超過手動完成任務 — — 是值得的。 人類會犯錯誤，自動化可以用來糾正錯誤。 例如，人類可能會錯誤輸入 標籤(tag)的區分大小寫的 key/value pair。 自動化不會犯這種錯誤，而且它還具有減少團隊工作量的額外效益。 使用 FinOps 自動化來減少錯誤和工作量的一個很好的例子是添加額外的標籤數據。 團隊用一個標籤標示他們的資源，然後讓自動化添加額外的、明確的標籤。 例如，團隊可能使用映射到成本中心或環境類型的專案標識。 自動化會找到該專案標識，然後將額外的標籤添加到資源中。 這減少了團隊需要套用的標籤數量，避免了人為錯誤，並確保以一致的方式應用額外的標籤資料。

能夠與組織的業務進行協同作業，而不僅僅是實施和維護自動化的成本。隨著時間的推移，重新評估自動化的效益很重要。 隨著我們的雲端運算的規模增長，隨著免費和開源工具變得更廣泛可用，或者由於其他原因，我們實施工具提供了一些自動化作為軟體包的一部分，我們可能會發現成本效益分析有利於增加自動化。

自動化工具

當涉及到任何有關進行組織業務工具時，不可避免的爭論就開始了：購買與自建。 對於 FinOps，會建議從第三方工具開始。 當我們開始進入 FinOps 自動化之旅時，我們可能會重複許多人遵循的相同學習過程。 通過使用成熟的第三方工具，我們可以避免一些常見的陷阱，加快自動化的交付時間，然後了解什麼對組織有效，什麼無效。

成本

在考慮成本與效益時，“我們不知道我們不知道什麼”的古老道理絕對適用。 有很多顧問公司和承包商可以分享他們關於需要圍繞 FinOps 自動化實施哪些實踐和流程的見解。 事實上，他們可以指導我們整個組織實現他們提供的工具的最大好處。

當我們考慮自建或是購買第三方軟體，現實一點也很重要。 我們很容易陷入完成任務所需自建工具的最小值的陷阱。 但是，這使我們無法獲得足夠的資訊來了解我們構建的工具將如何運作，以及當事情沒有按預期進行時它會產生什麼影響。 第三方工具很可能會準備好展示它的優勢和價值，並且它會有一個主要關注維護和改進工具的團隊 — — 所以我們的團隊不必這樣做。

其他考量

成本不是，也不應該是。 買現成或自建的整個重點，它可能存在著安全隱患的。 此外，我們可能會發現工具提供的功能與我們的環境不兼容，或者無法與我們之前使用的東西整合再一起（例如用於告警和通知的監控系統和工單系統)。 一些產業甚至有特定的合規性要求，例如 HIPAA、SOC2 或 PCI-DSS，而第三方工具供應商目前沒有獲得這些認證。

能夠稽核自動化的運作是關鍵，尤其是當自動化與生產環境交互時。 這種知識建立透明度.

第三方自動化工具通常都有很好的文件記錄，並為員工提供培訓文件，因此當我們僱用新員工時，他們更有可能已經熟悉這些工具。 如果我們自己建立自動化工具，我們需要願意並且能夠為現有和新的團隊成員提供持續的訓練，並且我們冒著負責建立和維護工具的人可能離職的風險。 除非有不少員工熟悉工具及其運作，否則我們會遇到“關鍵人物風險”。

當我們決定自建自動化工具而不是購買現成的產品時，我們應該進行仔細的分析比較。 我們必須始終將構建所有必需功能的投入資源(人力成本/時間成本)與我們購買的解決方案進行比較 — 包括衡量我們工具的效果、持續維護和我們需要實施的升級的方法。 我們應該小心識別任何第三方工具的缺失功能或合規性要求。

工具部署的選項

與大多數軟體一樣，有關如何部署自動化工具的一些考量因素將對方案的選擇過程產生影響。

雲原生
通過在雲端帳號中運行的自動化，腳本(scripts)可以由 CSP 或更廣泛的社群提供。 這些在我們的雲端帳號中的 Function as a service執行(如AWS Lambda或 GCP的cloud function).

自建
這是我們自己的員工建立和運行的軟體。 功能開發由內部團隊負責。 如果我們的組織周圍有許多不同的 DevOps 團隊。 我們可能會發現他們每個人都使用自己的自動化版本解決了相同的問題。 但最好是一個集中的團隊運行一個為我們整個雲端環境服務的自動化工具。 工具的集中管理將減少組織內的重複工作，但這也意味著我們需要一個萬能的解決方案。

第三方托管
對於已經做好的自動化解決方案，有很多的免費和開源工具，以及商用軟體的選項。 使用這種部署模型，團隊使用第三方軟體，但在他們自己的環境中運行它，自己維護和管理服務。 在開源領域，一個普遍推薦的工具是由 Capital One 團隊創建的 Cloud Custodian 應用程序。 我們需要考量的事運營成本和可能由第三方幫我們託管的成本。

第三方的SaaS
這個選項完全消除了infrastructure運作和管理軟體的作業。 SaaS服務為我們提供最簡單的設置和最快的自動化時間。 我們通常是支付月費，這很容易衡量工具本身的效益。 這個模型確實會帶來安全影響，我們後面會提及。

自動化協同作業

當我們可以有兩個自動化工具時，為什麼只需要一個自動化工具？

整合性

工具之間的整合可能是非常強大的，這是我們應該尋找和利用的東西。例如，如果組織中有一個現有的工單系統，我們最好實施 FinOps 工具，該工具將為現有系統中的操作項產生工單，而不是建立單獨的任務追踪系統。

如果我們選擇的自動化工具沒有與我們的其他軟體工具直接整合，那麼自動化工具仍有可能支援可延伸的事件處理。然後，我們可以接收有關自動化工具內部產生的事件通知，並可以建立一個延伸，將事件連接到我們其他一些軟體。這是擴展功能的好方法 — — 例如，向我們的chat bot發送特定任務已完成的通知，在我們的工單系統中為必要的後續任務產生工單，或根據偵測到的實施我們自己的自動修復任務。

自動化的衝突

當我們部署多個自動化工具時，我們需要確保它們不會相互衝突。如果一個工具試圖啟動Server，而另一個工具試圖關閉它，我們最終可能會導致自動化之間的操作產生衝突。如果我們正在為特定功能部署自動化工具，並且該工具具有我們不打算使用的另一個功能，我們可以考慮是否可以禁用該功能的服務權限防止對我們的雲端帳號執行變更。

有很多公司對不同功能部署了不同的自動化工具，卻發現這兩種工具都試圖控制相同的資源。或者一個團隊將實施與現有自動化衝突到自己的自動化。

這是一個更難解決的問題。為了防止這種情況發生，我們需要對整個組織進行有關自動化的教育，並讓團隊合作以確保他們了解其雲端帳號中任何計劃的自動化可能產生的影響。

理想情況下，自動化應該在與外部事物發生衝突時通知我們。例如，如果自動化在短時間內停止server insatcne超過設定的次數，它應該發送告警並防止任何進一步的變更。

有時，自動化服務的衝突不是與其他工具，而是跟人發生衝突。當我們的團隊成員之一需要訪問該服務器時，自動化可能已經停止server insatnce。這可能導致團隊成員啟動insatnce，卻看到自動化停止它。再一次，我們應該確保我們的團隊受過良好的訓練，包括如何從自動化中排除資源。

安全性(Safety)與資訊安全(Security)

資訊安全是任何 FinOps 自動化工具的首要的關注點。通常，FinOps 自動化需要對我們的端環境有非常高的權限，無論是描述帳號中所有內容的配置方式(configuration)，還是變更（資源的啟動/停止/刪除）的能力。此類的權限可能直接導致DoS、資料遺失、損壞或機密性資料洩露。

資訊安全通常被認為是組織內部不使用第三方工具的主要原因。讓資安團隊同意使用需要很高權限的第三方工具是可以理解的。但是，僅僅因為我們自己的團隊編寫軟體並不一定意味著它會非常安全。我們必須確保我們部署的所有自動化工具都擁有盡可能少的權限來執行所需的任務，同時保護軟體免受外部威脅。

成功的第三方軟體商也很有可能在其資訊安全上花費了大量時間和精力。閱讀他們的文件和他們之前發布的任何安全公告將幫助我們衡量該供應商將資安作為其產品的一部分的認真程度。

如果從FinOps的 爬、走、跑 模型中尋找靈感，我們可能會選擇最初以read-only模式與第三方 SaaS 工具整合。然後，我們可以從該工具得到通知，並使用我們自己的工具自動執行修復操作。當我們對廠商商更有信心時，我們可以開始允許逐步執行更多的操作，直到我們啟用所需的所有功能為止。

如何開始

我們不應該嘗試一次到位的自動化。 這將不可避免地產生問題，並讓我們努力確保我們部署的自動化是有效的。 以下是一些提示：

首先在通知模式下使用它：
以通知模式啟動初始自動化，讓我們知道如果啟用變更之後會執行些什麼．

在自動化上建立中信心：
了解啟用自動化後會在哪些區域進行的操作。 通過與團隊分享結果來建立信心，以確保他們對導入自動化感到滿意。

做很多的測試：
一旦我們對自動化建立了信心，首先開始在開發/測試帳號中執行操作，然後在對更多的user group之前先在較小的群組進行測試。

不要全部都是自建：
依賴商用或開源工具，這不僅可以節省時間，還可以確保我們獲得經過實戰考驗的最新解決方案。

衡量效能：
應該衡量自動化以確保它具有預期的效果。 隨著自動化在整個業務中的擴展，衡量效能是否下降至關重要。

什麼應該自動化

成功的 FinOps 專家可以使用許多自動化工具。 一些自動化必須非常具體的針對組織的運作方式。 但是，已經有一些具有成功 FinOps 實踐的組織一遍又一遍地實施了一些常見的自動化解決方案。

標籤治理

一旦我們的組織定義了下標籤的標準，我們就可以使用自動化來確保它被正確的執行。 我們首先識別缺少標籤或錯誤套用標籤的資源，然後讓負責這個資源的人解決標籤不合規問題。 然後，我們stop/(或)block資源以強制所有者採取行動，並可能為這些資源制定remove/delete的政策。 但是，刪除資源是一種影響很大的自動化，所以很多公司都無法達到這個等級。 建議在我們還沒完成較早期的且影響較小的自動化等級之前就直接刪除不合規的資源。

資源定期的開啟跟關閉

自動化使我們能夠安排資源在不使用時停止（例如，當我們離開辦公室時），然後在我們需要再次使用它們時讓它們重新上線。 這種自動化的目標是最大限度地減少對團隊的影響，同時在他們的資源被關閉的幾個小時內實現大量的省錢。 這種自動化通常部署到開發和測試環境中，在工作時間之外不會注意到沒有資源可用。 我們應該確保讓團隊團隊成員可跳過計畫內資源異動，以防萬一他們需要在工作到很晚時保持服務器處於活動狀態。 此外，取消預期中的作業不應完全從自動化中刪除資源，而是應跳過當前執行動作。

減少使用量

我們在雲端資源的優化 — 用得更少文章中，我們介紹了資源大小調整和閒置資源偵測等。 自動化消除了這種浪費，或者至少向當責的員工發送告警，以推動更好的成本優化。 自動從 Trusted Advisor（如 AWS）等服務、第三方成本優化平台或資源指標中擷取資源資料，讓我們很容易的向負責資源的團隊成員發送告警，或者， 在某些環境中，自動停止或調整資源大小。

結論

自動化為我們提供了提高了在FinOps 流程與實踐的可靠性和一致性、檢查和告警 可能性。 了解我們試圖通過自動化實現的真正目標並意識到自動化不是免費的，這一點很重要。

總結一下：

• 自動化的成本來自購買軟體或自建；自動化本身消耗的資源； 以及任何管理、維護和監控自動化的人力/時間的投入。
• 通過設定一我們希望用自動化工作實現的明確目標，我們可以衡量自動化的成本與潛在的商業利益。
• 如果要從零開始得自建自動化軟體之前，我們應該始終考慮從第三方 SaaS 或商用軟體購買備受推崇的解決方案。
• 但是，在實施外部解決方案之前，我們必須考慮對雲端環境的安全性功能的影響。