自動化在提升軟體交付效率和可靠性方面至關重要，然而許多組織在實施自動化時卻面臨重重阻礙。這些阻礙並非單純來自技術層面，更深層的原因與組織文化、團隊技能，以及軟體設計息息相關。缺乏明確的自動化文化，團隊成員的技能同質化，以及未將自動化納入軟體設計考量，都會導致自動化難以推行。Windows 環境的發展歷程也展現了系統設計如何影響自動化的採用速度，從早期 GUI 介面限制到 PowerShell 的出現，都突顯了合適工具的重要性。
為什麼組織不願意自動化？
自動化帶來的好處顯而易見，但令人驚訝的是，許多團隊並沒有進行更多的自動化。原因並不僅僅是高層長官宣佈暫時不關注自動化。推動自動化的關鍵在於對自身價值有清晰的理解，並將這些價值透過行動體現出來。
大多數人會同意，鍛煉和健康飲食很重要，但當問及為什麼不這麼做時，人們會說有其他更重要的事情要優先處理，結果導致不良的飲食習慣和缺乏鍛煉。我希望每天早上都能鍛煉，但由於晚上幫孩子們做作業、與妻子共度時光、再加上自己的個人時間，這些選擇讓我在晚上11:45才睡覺，第二天早上6:30才起床。這樣一來，鍛煉的時間就被擠掉了。從未有人有意識地說：「我今天早上不鍛煉了」，但透過行動，人們創造了一個環境，使得鍛煉變得不可行。組織在自動化和工具開發上也經常如此，優先順序的錯置發生在兩個關鍵領域：組織文化和徵才。
將自動化設為文化優先事項
當討論組織的價值觀時，你正在描述組織認為重要的事情。如果自動化和工具開發不在討論之列，那麼它們就不被視為優先事項。組織的文化決定了什麼是重要的，而自動化正是透過文化優先事項來推動的。
自動化的益處
自動化帶來了多個方面的好處，包括：
- 減少佇列時間：任務和活動在Pipeline中移動得更快，從而實作更快的業務成果。
- 提高執行效率：能夠快速執行任務，而無需等待交接，從而提高工程師的工作效率。
- 增加執行頻率：某些任務可以更頻繁地執行，從而獲得額外的價值。
- 減少效能差異：確保相同的任務每次都以相同的方式執行，這是稽核人員所喜愛的。
透過內部工具和自動化的工作，將推動這四個領域的業務效率，不僅如此，還能使更多的員工能夠執行以前受限於存取許可權和知識傳遞的任務。將專業知識編碼成工具或指令碼，可以讓組織將原本由高成本員工執行的任務下放給其他人。
自動化流程範例
rollback_payments.sh –transaction-id 115
內容解密：
此指令碼用於回復特定的付款交易。其中，rollback_payments.sh 是指令碼名稱，–transaction-id 115 是引數，用於指定要回復的交易ID為115。這種自動化指令碼允許非開發人員執行原本需要開發人員知識的任務，從而節省了開發人員的時間，並提高了整體的工作效率。
自動化的未來
圖7.2展示了在自動化環境下，流程可能呈現的樣子。透過自動化和工具開發，能夠在每個階段賦予流程更多的能力，這也是它們成為DevOps旅程中至關重要的組成部分的原因。自動化涵蓋了賦能、速度和可重複性。
為什麼組織不願意自動化？
考慮到自動化帶來的明顯好處，令人驚訝的是，為什麼更多的團隊不進行更多的自動化。原因從來都不像高層長官宣佈暫時不關注自動化那麼簡單。推動自動化的動力更多地來自於對自身價值的清晰理解，並透過行動來表達這些價值。
此圖示展示了在自動化環境下的流程變化。透過簡化流程和減少交接時間，能夠顯著提高工作效率和客戶滿意度。自動化使得原本需要多個步驟和多個角色參與的任務變得更加簡單直接，從而減少了延遲和提高了回應速度。
為何組織難以推動自動化
在許多組織中，自動化的重要性常常被忽略或延後處理。自動化工具和流程的缺乏會導致效率低下、資源浪費和生產力下降。本章將探討組織難以推動自動化的原因，並分析如何克服這些挑戰。
組織文化與自動化
組織的文化對自動化的採用有著深遠的影響。一個組織的文化決定了它對某些行為的容忍度。例如，在一些組織中，在辦公桌上喝酒可能是被允許的，而在其他組織中，這可能是嚴格禁止的。同樣地，組織的文化也可以影響它對自動化的態度。如果一個組織重視自動化，那麼員工就會被鼓勵去開發和實施自動化工具和流程。
時間不足與優先順序
許多組織面臨的一個共同挑戰是時間不足。員工常常覺得沒有足夠的時間來開發和實施自動化工具和流程。這是因為自動化的好處往往需要一段時間才能顯現，而短期內可能看不到明顯的效果。此外，自動化專案往往需要大量的前期投資，這可能會讓員工感到猶豫。
另一個相關的問題是優先順序的設定。自動化專案往往被排在其他更緊急的任務之後。這是因為組織通常優先考慮短期目標，而不是長期效益。因此，自動化專案往往被延後或忽略。
程式碼範例：優先順序設定的影響
import time
def manual_task():
# 模擬手動任務
time.sleep(1) # 假設任務需要1秒鐘
print("手動任務完成")
def automated_task():
# 模擬自動化任務
print("自動化任務完成")
# 手動任務
start_time = time.time()
for _ in range(4): # 每週執行一次，共4週
manual_task()
print(f"手動任務總耗時：{time.time() - start_time}秒")
# 自動化任務
start_time = time.time()
automated_task() # 只需執行一次自動化任務
print(f"自動化任務總耗時：{time.time() - start_time}秒")
內容解密：
- 模擬手動任務：
manual_task函式模擬了一個耗時1秒的手動任務。 - 模擬自動化任務：
automated_task函式代表自動化任務，只需執行一次。 - 比較耗時：透過比較手動任務和自動化任務的總耗時，可以看出自動化的效益。
- 優先順序的影響：如果組織優先考慮短期目標，手動任務可能會被重複執行，而自動化任務則被延後。
緊急需求與正確性
在許多情況下，緊急需求會壓倒正確性。員工可能會被要求快速完成任務，而不考慮長期的可持續性。這種做法可能會導致短期內看似節省時間，但長遠來看卻會造成更多的問題和資源浪費。
自動化人才的缺乏
另一個挑戰是組織可能缺乏專門的自動化人才。公司在初期階段通常根據其優先事項進行徵才。如果自動化不是優先事項，那麼相關人才的徵才可能會被延後。因此，組織需要重新評估其徵才策略，以確保有足夠的人才來支援自動化工作。
為何組織難以深化自動化：團隊技能侷限與環境設計的影響
在組織追求自動化的過程中，兩個關鍵因素常常被忽視：團隊成員的技能同質化以及軟體設計對可支援性的影響。這些因素不僅限制了自動化的實施，也對團隊的技能發展產生了深遠的影響。
單一技能組合的團隊
在招募新成員時，團隊往往傾向於尋找與現有成員相似的候選人。這種做法導致團隊成員之間的技能高度相似，同時也意味著相同的技能缺口被複製。這種現象在幾乎所有團隊中都很普遍。
若要推動自動化與工具開發，必須招募具備相關技能的人才，尤其是當團隊內部缺乏這類別專長時。這種招募策略可能意味著新成員在其他方面相對缺乏經驗。例如，若團隊主要由前端工程師組成，那麼負責內部工具和自動化的候選人可能前端經驗不足，但後端經驗豐富。在評估候選人時，必須權衡當前需求與過往累積的專業知識。
這種多元化的招募策略最初可能令人感到不適，因為業界對徵才往往抱持不切實際的期待。我們難以找到全能型的開發者，於是需要透過團隊技能的多元化來彌補，以集體實力達成所需目標。
內容解密：
- 團隊同質化問題：團隊招募傾向於與現有成員相似的候選人，導致技能重複。
- 自動化人才需求：需要具備特定技能的人才來推動自動化。
- 多元化招募：需要平衡不同技能領域的候選人，以滿足當前與長期的需求。
環境設計對自動化的影響
軟體設計直接影響其可支援性與自動化潛力。以一個需要透過圖形介面（GUI）上傳多個檔案的應用程式為例。若使用者希望透過指令碼自動化此過程，卻因應用程式設計限制而無法實作，最終只能透過模擬滑鼠點選等方式來達成自動化。此過程極為脆弱，容易出現錯誤、逾時等問題。
可支援性如同穩定性、效能和安全性一樣，是系統或產品的一項重要特徵。若未在設計階段納入考量，最終將被視為事後追加的功能，從而受到既有設計限制。
環境設計對自動化的影響還會進一步加劇技能落差。隨著工具環境不斷發展，若缺乏可自動化的設計，相關技能需求將逐漸萎縮。久而久之，環境本身成為阻礙自動化的因素。
內容解密：
- 軟體設計影響自動化：GUI設計限制了自動化指令碼的實施。
- 可支援性的重要性：需在設計階段考慮可支援性，避免事後追加的困境。
- 環境與技能的惡性迴圈：缺乏自動化設計會導致相關技能需求下降，形成惡性迴圈。
Windows 環境中自動化的緩慢採用
曾與一家顧問公司的徵才經理共進午餐，該公司專注於將DevOps原則與實踐引入大型企業。他面臨的問題是難以找到具備DevOps技能的Windows工程師。經過討論，我發現Windows系統設計對自動化的影響是一個關鍵因素。
早期的Windows版本（NT、2000、2003）大多陣列態和管理工作依賴圖形介面，使用者透過導航選單來完成任務。這使得管理Windows系統變得更加容易，但卻缺乏可靠的自動化途徑。因此，Windows社群的自動化技能發展相對緩慢。
隨著PowerShell在2006年的推出，Windows逐漸擁抱命令列管理方式，越來越多的管理功能可透過命令列存取。因此，Windows管理員的自動化技能開始增長。這是一個典型的例子，說明系統設計不僅影響了平台的支援能力，也塑造了團隊的技能組合。
內容解密：
- Windows早期版本對自動化的限制：GUI設計限制了自動化的發展。
- PowerShell的引入：提升了Windows環境下的自動化能力。
- 系統設計對技能發展的長期影響：命令列工具的使用促進了自動化技能的成長。
文化自動化問題的解決方案
在環境中持續成功地建立工具和自動化，必須制定改變自動化文化的計劃。無論投入多少精力進行大規模的自動化推進，如果沒有改變文化，既有的工具將會逐漸失效，新的流程也會受到相同的問題和藉口的困擾。就像幾乎所有DevOps實踐一樣，自動化始於文化。
不允許手動任務
這聽起來非常明顯，但卻是改變文化最簡單的方法之一：在團隊中停止接受手動解決方案。當有人提出一個不支援的手動流程時，直接拒絕並說明轉換過程中的期望。
你可能會想到無數理由說明拒絕是不切實際的。你可能會認為某些任務被視為最高優先順序的請求。你覺得僅僅說不就無法獲得長官層的支援或認同。如果長官層已經表明自動化和工具是優先事項，你可以強調這一點作為拒絕手動任務的理由。「我認為這個流程不完整，我更願意拒絕不完整的工作。」指出請求者需要改進或指令碼化的部分。不能僅僅以「不」作為最終答案。
支援「不」作為答案
準備好一份清單，列出你希望看到流程中改變的部分。甚至可以根據本章前面討論的四個領域：佇列時間、執行時間、執行頻率和執行變異性來提出投訴。
使用這些作為指導方針，闡述你的工作量將如何受到影響。在審視流程時，特別注意具有合理不確定性或錯誤可能性的部分。如果出現錯誤，重試流程的還原時間將受到什麼影響？流程需要在團隊或部門之間進行多少次交接？任務需要執行的頻率是多少？頻率的驅動因素是什麼？這是一個重要的考慮因素，因為在某些情況下，增長成為頻率的驅動因素。如果任務的增長與其他指標（如活躍使用者數量）相關，你應該記住這一點，因為它讓你瞭解流程最終可能變得多麼痛苦。
同樣重要的是任務的模式：不要陷入任務的具體細節，而是要了解它解決的通用問題。執行一次性的SQL查詢可能是針對特定SQL查詢的一次性需求。但不久之後，執行一次性的SQL查詢就成為瞭解決某些型別問題的模式。「哦，如果你需要重置使用者的登入次數，只需登入資料函式庫並執行這個SQL查詢。」這些模式會耗盡團隊資源，容易出錯，通常是非功能性需求的證據。評估任務的模式，而不僅僅是具體任務本身。
一旦瞭解了手動執行活動的整體工作量，就可以用它來瞭解自動化相同任務的整體工作量。請記住，手動任務所涉及的工作量通常是持續的。很少有任務只需要執行一次，這意味著手動任務的成本會隨著時間不斷支付。當你詳細闡述所有這些領域時，你就有了一個拒絕回應的理由。稍後在本章中，我將討論為手動流程與自動化工作量賦予實際美元價值。
手動與自動化的折衷方案
有時說「不」是不可行的。出於某種原因，任務太重要，或者自動化太繁重而無法完成。這時，我選擇保留一個記分卡。
記分卡列出了你或你的團隊必須執行的所有手動任務，但你希望以某種方式實作自動化。每個任務都有一個相關的分數：1、3或9。分數反映了手動任務的負擔程度；任務越繁重，分數越高。
然後，記分卡應該有一個最高值。這可能是在個人、團隊或組織層面設定的。最終取決於你在組織中的哪個層級跟蹤此事。
現在你有了記分卡，當新的手動任務被請求你或你的團隊時，根據它將對你的團隊造成的負擔進行評分。一旦評分完成，請檢視額外的分數是否會使你的團隊超過記分卡的最大值。如果記分卡的最大值已經達到，則不能在未透過自動化刪除某些任務的情況下，將新的手動任務分配給團隊。
這不是按專案比例計算，而是總分——所以如果你的最大值是20，而你已經達到20，想要新增一個被評估為3的任務，你不能簡單地自動化一個1來騰出空間。你需要自動化三個被評為1的任務，或者一個被評為3的任務，或一個被評為9的任務。表7.1顯示了一個示例記分卡可能是什麼樣子。
表7.1 團隊必須執行的所有手動任務的統計，分數評級
| 任務 | 分數 |
|---|---|
| 上傳財務報告資料 | 1 |
| 從資料倉儲匯出第一層客戶訂單 | 9 |
| 清理已取消的訂單 | 9 |
| 按客戶建立功能組 | 3 |
| 總計——最大值設為20 | 22 |
內容解密：
此表格展示了一個示例記分卡，用於跟蹤團隊的手動任務及其對應的分數。每個任務根據其負擔程度被賦予1、3或9的分數。總分超過了設定的最大值20，表明需要透過自動化來減少手動任務的工作量，以騰出空間接受新的任務請求。
- 上傳財務報告資料（分數1）：這是一個相對簡單的手動任務，對團隊的負擔較小。
- 從資料倉儲匯出第一層客戶訂單（分數9）：這是一個繁重的手動任務，對團隊造成了很大的負擔。
- 清理已取消的訂單（分數9）：同樣，這也是一個非常繁重的手動任務，需要大量的工作量。
- 按客戶建立功能組（分數3）：這個任務有一定的複雜度，但相對於前兩個繁重的任務來說，負擔較小。 總分達到22，超過了設定的最大值20。這意味著團隊需要透過自動化一些高分任務來降低總分，從而能夠接受新的手動任務請求。
圖表說明：記分卡示例
此圖示展示了記分卡管理的流程。當有新的手動任務請求時，會評估該任務的分數並檢查總分是否超過設定的最大值。如果超過，則需要透過自動化現有的高分任務來降低總分；如果未超過，則可以接受新的任務並更新記分卡。
自動化評估與手動作業成本分析
在組織中追蹤手動作業的工作量及其所帶來的壓力是一項基本但重要的任務。為了達成這一點，可以採用一種簡單的記分卡方法來記錄和追蹤手動任務的難度。這種方法能夠幫助團隊瞭解組織中手動作業的狀況，並找出需要自動化的工作。
記分卡方法的優勢
記分卡方法提供了一種簡單的方式來記錄和追蹤手動任務的難度。它能夠幫助團隊瞭解組織中手動作業的工作量及其所帶來的壓力。透過這種方法，團隊可以快速評估目前的手動流程狀況，並決定是否需要進行自動化。
手動作業的成本
每個組織都需要處理財務問題。即使是非營利組織，也需要考慮資金的使用效益。技術人員通常難以將技術上的取捨轉化為財務語言。然而，使用數字（無論是記分卡的分數還是預算金額）能夠幫助人們更好地理解問題。
瞭解流程
要評估手動作業與自動化的成本，首先需要將流程分解為高層次的步驟，並估計每個步驟所消耗的時間和資源。由於資料的不確定性，估計時間範圍比給出單一數字更為合理。這裡使用的是統計學中的置信區間概念，即給出一個具有90%可能性包含正確答案的時間範圍。
時間範圍估計
例如，若要估計一個工單在佇列中等待的時間，可以估計90%的情況下，工單等待時間在2小時到96小時（四天）之間。需要注意的是，這個範圍不應該過於寬泛，否則就失去了意義。一個好的估計應該是，如果對任務進行多次抽樣，90%的情況下，實際時間會落在這個範圍內。
圖表分析
圖7.3展示了一個帶有時間估計的工作流程圖。在這個圖表中，每個步驟都被賦予了一個時間範圍，而不是固定的數值。這樣能夠更好地反映出實際執行中的變異性。
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title 組織自動化匯入障礙與解決方案
package "Linux Shell 操作" {
package "檔案操作" {
component [ls/cd/pwd] as nav
component [cp/mv/rm] as file
component [chmod/chown] as perm
}
package "文字處理" {
component [grep] as grep
component [sed] as sed
component [awk] as awk
component [cut/sort/uniq] as text
}
package "系統管理" {
component [ps/top/htop] as process
component [systemctl] as service
component [cron] as cron
}
package "管線與重導向" {
component [| 管線] as pipe
component [> >> 輸出] as redirect
component [$() 命令替換] as subst
}
}
nav --> file : 檔案管理
file --> perm : 權限設定
grep --> sed : 過濾處理
sed --> awk : 欄位處理
pipe --> redirect : 串接命令
process --> service : 服務管理
note right of pipe
命令1 | 命令2
前者輸出作為後者輸入
end note
@enduml此圖示說明瞭手動作業流程中的時間變異性
在這個流程中，每個步驟的時間範圍都反映了實際執行中的不確定性。例如，工單在佇列中等待的時間可能在2小時到48小時之間，而執行任務的時間可能在10分鐘到65分鐘之間。這種表示方法能夠更真實地反映出實際情況中的變異性。
內容解密：
- 提交工單（5-15 分鐘）：這個步驟代表了初始任務提交所需的時間範圍。
- 佇列等待（2-48 小時）：工單在佇列中等待處理的時間範圍，這取決於工作負載和處理速度。
- 執行任務（10-65 分鐘）：實際執行任務所需的時間範圍，這受到任務複雜度和工程師熟練度的影響。
- 報告結果（1-10 分鐘）：完成任務後報告結果所需的時間範圍。
透過這種方法，可以更準確地評估手動作業的成本，並找出自動化的潛在機會，從而提高組織的效率和生產力。
