自動化審核流程最佳化變更管理

傳統的變更管理流程往往依賴繁瑣的手動審核步驟，容易造成佈署延遲、溝通成本增加等問題。本文提出的自動化審核流程，旨在解決這些瓶頸，提升整體效率。透過分析現有流程的痛點，我們可以發現，手動審核步驟的引入雖然看似解決了單一事件的問題，卻為整個系統帶來了新的挑戰。因此，本文建議採用自動化方案取代手動審核，並提供程式碼範例，說明如何設計可擴充套件且易於維護的審核系統。此外，我們也將探討如何在自動化流程中加入鎖定機制，以避免衝突動作的發生，並強調紀錄與通知機制的重要性，確保流程的透明度和可追溯性。

審視把關者：變更管理政策的副作用

在與財務部門和IT部門討論後，決定所有佈署都必須經過正式的審查流程。Stephanie和維運團隊的其他成員必須在佈署前獲得財務部門的批准。財務部門將在內部協調以批准請求的佈署視窗，但他們要求至少提前一天通知，以便獲得部門內所有成員的簽核。

Stephanie不僅僅負責支援財務系統，因此她需要能夠在自己的端進行規劃。她要求開發團隊提交佈署請求時至少在請求日期前三天提出，以確保她和她的團隊成員有足夠的時間將請求納入他們的排程中，並給予財務團隊足夠的通知時間，以便他們收集適當的簽核。

新流程的步驟

1. 開發人員向維運部門提交變更票。
2. 如果變更票沒有給維運部門至少三天的通知，則立即被拒絕，開發人員被要求重新提交新的日期。
3. 財務團隊審查他們的工作排程，如果與其他財務團隊工作存在排程衝突，則變更被拒絕，開發人員被要求重新提交新的日期。
4. 變更正式獲得批准。
5. 變更被實施。

流程的侷限性

這個流程看似能夠解決問題，但它是一個傳統的解決方案。在DevOps組織中，重點是移除這些型別的門控請求，並將重點放在高效和快速的交付上，這是透過偏好自動化解決方案而不是增加額外的瓶頸來實作的。此外，這個流程有一些微妙的副作用，將對團隊產生影響。

對佈署頻率的影響

新的流程要求至少提前三天通知，這在實踐中限制了財務應用程式只能每週佈署一次。這使得處理像錯誤修復這樣的緊急專案變得困難。緊急佈署可能會迫使你繞過新的流程。透過最佳化一個特定的問題（確保工作不會丟失的批准），你已經減慢並阻礙了整個系統，因為限制了財務應用程式快速佈署的能力。

對團隊溝通的影響

新的流程需要團隊之間進行更多的溝通。談論團隊成員通常不是壞事，但審批流程的開銷可能會使佈署流程陷入停滯，如果財務團隊沒有及時回應。這些人為的延遲會對流程產生怨恨，促使人們盡可能避免這個流程。

對使用者行為的影響

另一個無意的副作用是，使用者的不作為可能會導致佈署被取消。如果使用者在一天結束時沒有登出系統，無辜的錯誤可能會導致佈署被取消。這種取消剝奪了客戶新的功能或特性，對業務毫無益處。此外，很難向人們解釋為什麼發布被取消了。

表格：變更管理政策引入的新問題

這個過度反應助長了家長式管理的症候群。團隊沒有檢查系統及其如何導致問題，而是將精力集中在團隊成員的個人決定上。這是不生產力的，並將責任歸咎於人員而不是流程。更糟糕的是，它沒有解決問題；相反，它只是為整個工作流程增加了更多時間。

審視守門人與自動化的必要性

在匯入新的審批流程後，團隊遇到了前所未有的挑戰。新的流程要求至少三天的溝通時間，這意味著如果沒有仔細的規劃，計費應用程式的佈署將被限制為每週一次。這種延遲是由於單一事件而引入的，而在此之前，其他佈署均未出現問題。現在，團隊正在強制每次佈署都遵循這一流程。

新審批流程帶來的問題

新的審批流程不僅未能達到其預期的目標，反而主動減緩了所有未來的變更。圖2.1闡述了這一流程以及由此引發的一些問題。

流程圖示

此圖示展示了新的審批流程，以及可能出現的問題，例如使用者忘記登出導致佈署取消，以及審查過程降低了每週佈署的頻率。

人為錯誤與流程漏洞

圖2.2突顯了流程中容易出現人為錯誤的幾個關鍵點，可能導致工作遺失或中斷。即使操作人員遵循流程，仍有可能因使用者疏忽或其他因素導致工作遺失。

容易出錯的流程

內容解密：

1. 變更提交與通知機制：變更提交後，計費團隊需要檢查是否滿足1天通知的條件。這一步驟至關重要，因為它決定了變更是否能進入下一步審查。

2. 使用者登入狀態檢查：在變更實施前，需要檢查使用者是否已登入。這一步驟容易出現人為錯誤，如果操作人員跳過這一步，可能會中斷正在進行的工作。

3. 變更實施與風險：變更被批准後，將被實施。在此過程中，如果沒有正確處理，可能會導致資料遺失或工作中斷。

透過自動化解決家長式管理

您可以利用技術取代流程中的大量手動審批步驟。以之前的佈署流程為例，自動化可以解決一些被提出的問題。三天的通知視窗旨在給人類足夠的時間來審查正在進行的工作，並確保佈署沒有問題。但機器可以瞬間完成這項工作，無需人類審批者所面臨的排程和優先順序衝突。

自動化的好處

• 減少審批過程中的時間花費
• 減少行政任務的時間花費
• 減少迭代時間
• 在流程中建立一致性

自動化的實施步驟

1. 組建團隊：團隊應擴大到包括工程師、守門人和其他相關人員，以確保方案的全面性。

2. 獲得共識：與團隊討論自動化的好處，重點關注改進審批流程的重要性。

3. 設計自動化流程：根據流程的性質，確定哪些部分可以輕易自動化，哪些部分需要更多的考慮。

透過自動化，可以減少人為錯誤，提高效率，並使流程更加一致。最終，這將有助於消除家長式管理的弊端，實作更高效的工作流程。

自動化流程中的父權主義症候群與程式碼結構最佳化

在自動化流程的實施過程中，團隊往往會陷入一種被稱為「父權主義症候群」的思維模式，即過度保護和控制流程中的每一步。這種思維模式可能導致過多的手動審核步驟，從而降低工作效率並增加出錯的可能性。

瞭解手動審核的目的

手動審核步驟通常是為瞭解決特定的問題或風險而設立的。然而，這些步驟往往只是問題的表象，而不是根本原因。要實作有效的自動化，首先需要了解手動審核背後的真正目的。

舉例來說，當你向銀行貸款時，銀行會詢問你的財務狀況和其他債務。這並不是因為銀行對你的個人財務狀況感興趣，而是為了評估你的還款能力。同樣地，在技術領域，手動審核可能是為了確保變更已經過同行評審、風險可控等。

自動化審核流程

要自動化審核流程，需要捕捉手動審核的核心目的。手動審核通常試圖確保以下幾點：

• 所有流程部分都處於適當狀態，以便工作繼續進行。
• 相關人員已獲悉正在進行的工作。
• 沒有衝突的操作會阻止變更的發生。
• 變更的風險對於組織來說是可接受的。

這些關注點可以透過自動化來簡化，從而減少對繁瑣的手動審核流程的依賴。

程式碼結構最佳化

繼續以本章前面的帳單佈署流程為例，該流程在佈署事件發生後引入了手動審核步驟。雖然這似乎是一種快速解決問題的方法，但它並不是最佳解決方案。團隊應該專注於使佈署流程更加智慧和安全。

自動化工作流程的結構

在嘗試自動化流程時，必須適當地構建步驟。每個自動化工作流程都需要處理一系列問題：

• 審核流程：需要哪些檢查來確保允許執行？
• 日誌記錄流程：自動化在哪裡記錄請求、審核、執行和結果？
• 通知流程：自動化在哪裡通知人們已採取的行動？
• 錯誤處理：您執行多少自動還原？

這些需求可能會隨著時間的推移而變化，因為不斷變化的需求和指導方針開始使您的原始概念變得模糊。這是應用程式設計中的常見問題。

程式碼範例與解析

以下是一個簡單的自動化工作流程範例，使用 Python 語言實作：

import logging

def check_approval(request):
    # 檢查是否允許執行
    if request['status'] == 'approved':
        return True
    else:
        return False

def log_request(request):
    # 日誌記錄請求
    logging.info('Request received: %s', request)

def notify_user(request):
    # 通知使用者已採取的行動
    print('Notification sent to user')

def execute_request(request):
    # 執行請求
    try:
        # 執行邏輯
        print('Request executed successfully')
    except Exception as e:
        # 錯誤處理
        logging.error('Error executing request: %s', e)

# 主流程
request = {'status': 'approved'}
if check_approval(request):
    log_request(request)
    execute_request(request)
    notify_user(request)
else:
    print('Request not approved')

內容解密：

1. check_approval函式：檢查請求是否獲得批准。這是審核流程的一部分，用於確保請求符合特定的條件或標準。
2. log_request函式：記錄請求的日誌。這是日誌記錄流程的一部分，用於跟蹤和記錄系統中的重要事件。
3. notify_user函式：通知使用者已採取的行動。這是通知流程的一部分，用於及時告知使用者系統的狀態變化。
4. execute_request函式：執行請求。這是核心的業務邏輯，用於處理請求並傳回結果。同時，它包含了錯誤處理機制，用於捕捉和處理執行過程中可能出現的異常。
5. 主流程：整合了上述所有步驟，形成一個完整的自動化工作流程。首先檢查請求是否獲得批准，然後記錄請求，執行請求，並通知使用者。如果請求未獲得批准，則輸出相應的提示資訊。

這個範例展示瞭如何透過結構化的程式碼實作自動化工作流程，並簡化手動審核步驟，從而提高效率並降低錯誤率。

自動化流程的結構化思維

在進行流程自動化時，開發者常將其視為一系列簡單指令碼的組合，但這種做法可能導致自動化流程缺乏彈性、容易出錯且難以維護。就像海軍上將阿克巴所說的「這是一個陷阱！」一樣，若不對自動化任務給予足夠的重視，最終會導致難以管理的自動化結果。因此，即使是最簡單的指令碼，也應該以開發完整應用程式的思維來進行結構化設計，將不同的關注點分離成可管理和可維護的程式碼。

審核流程的重要性

在實作審核流程時，需要思考手動審核流程存在的原因。審核流程至少試圖減輕四個方面的疑慮：

1. 所有流程部分都處於適當的狀態，以便工作能夠繼續進行。
2. 相關人員被告知工作正在進行。
3. 沒有衝突的動作會阻止變更的發生。
4. 變更的風險對於組織來說是可接受的。

工作狀態的確認

在審核過程中，審核者可能需要驗證工作步驟是否已經就緒，以便團隊能夠繼續推進。這是審核者關注的重要事項，也是自動化過程中需要實作的檢查之一。這可能包括簡單的驗證，例如確保請求已經透過同行評審，或者更複雜的檢查，例如確保資料函式庫在執行前處於正確狀態。

風險評估與標準變更

在自動化審核流程時，需要將變更分為兩類別：標準變更和非標準變更。根據IT服務管理（ITSM）的定義，「標準變更是指對服務或基礎設施進行變更，其方法已獲得變更管理的預先授權，並具有既定的程式。」簡而言之，標準變更是指那些經過預先授權且具有明確程式的變更。

自動化審核檢查

透過詢問審核者，瞭解他們在審核過程中關注的事項，可以獲得自動化所需的詳細資訊。可以提出以下問題：

• 有哪些因素會導致您自動拒絕審核請求？
• 有哪些因素會讓您對請求產生疑問？
• 每個您批准的請求都必須具備哪些條件？

這些問題能夠幫助我們瞭解審核者的決策過程，並將這些條件轉化為自動化的布林測試（Boolean tests）。如果這些測試都成功透過，請求就會被批准，等待審核的工作可以繼續進行。

程式碼結構與鎖定機制

在處理具有人為參與的流程時，協調和協調可能會變得困難，但可以藉助鎖定機制（locking mechanism）來解決衝突動作的問題。在程式碼中，通常會使用鎖定機制或訊號量（semaphore）來保護資源的獨佔性。同樣的原理也可以應用於具有人為參與的流程中，以確保不會發生衝突。

import threading

# 使用鎖定機制保護資源
lock = threading.Lock()

def execute_task(task):
    with lock:  # 取得鎖定
        # 執行任務
        print(f"執行任務：{task}")
        # 任務完成後釋放鎖定
    return True

# 測試鎖定機制
task1 = threading.Thread(target=execute_task, args=("任務1",))
task2 = threading.Thread(target=execute_task, args=("任務2",))

task1.start()
task2.start()

task1.join()
task2.join()

內容解密：

這段程式碼展示瞭如何使用Python中的threading.Lock()來實作鎖定機制，以保護資源免受並發存取的影響。execute_task函式在執行任務前取得鎖定，任務完成後釋放鎖定，從而確保同一時間只有一個任務能夠執行。這種機制可以用於解決自動化流程中的衝突問題。

自動化審核流程的結構化程式碼設計

在自動化審核流程中，程式碼的結構設計至關重要。本章節將探討如何設計一個可擴充套件、易於維護的審核系統。

審核流程的自動化

自動化審核流程需要考慮四個主要因素：工作狀態、通知相關人員、避免衝突工作以及接受組織風險。透過程式設計實作這些檢查，可以大大減少人工審核的工作量。

設計審核系統

設計審核系統需要將自動化分為兩個部分：一部分處理實際的審核，另一部分處理執行命令（如果審核透過）。本章節將重點介紹實際的審核程式碼。

建立基礎審核類別

使用基礎類別（Base Class）來定義審核的結構是一個好方法。基礎類別可以要求所有繼承的審核類別遵循相似的結構。

class BaseApproval:
    def is_approved(self):
        raise NotImplementedError()
    def error_message(self):
        raise NotImplementedError()

繼承基礎類別建立個別審核類別

個別審核類別繼承自基礎類別，並實作 is_approved 方法。例如，PeerApproval 類別檢查請求是否已透過同儕審查。

class PeerApproval(BaseApproval):
    def is_approved(self):
        # 實作同儕審查邏輯
        pass
    def error_message(self):
        # 實作錯誤訊息
        pass

使用多型性檢查多個審核條件

透過使用多型性，可以輕鬆檢查多個審核條件。建立一個審核物件列表，並遍歷列表檢查每個物件的 is_approved 方法。

approvals = [PeerApproval(), OtherApproval()]
for approval in approvals:
    if not approval.is_approved():
        print(approval.error_message())

內容解密：

1. 基礎類別的定義：BaseApproval 類別定義了 is_approved 和 error_message 兩個方法，要求繼承類別實作這些方法。
2. 個別審核類別的實作：PeerApproval 類別繼承自 BaseApproval，並實作 is_approved 和 error_message 方法。
3. 多型性的應用：透過建立審核物件列表，並遍歷列表檢查每個物件的 is_approved 方法，實作了多型性。
4. 錯誤處理：如果某個審核條件未透過，則輸出錯誤訊息。

本章節介紹瞭如何設計一個可擴充套件、易於維護的審核系統。透過使用基礎類別和多型性，可以輕鬆新增新的審核條件，並提高程式碼的可讀性和可維護性。

自動化中的核準流程結構化

在自動化過程中，核准機制是確保變更正確性和可控性的關鍵步驟。透過將不同的核準需求封裝到獨立的類別中，可以提高程式碼的可維護性和擴充性。

核准類別的設計與實作

以下是一個簡單的 PeerApproval 類別範例，該類別繼承自 BaseApproval：

class PeerApproval(BaseApproval):
    def is_approved(self):
        approvers = self.check_approvers()
        if len(approvers) > 0:
            return (True, "")
        else:
            return (False, "No approvals submitted")

內容解密：

• is_approved 方法用於檢查核準狀態，傳回一個包含布林值和錯誤訊息的元組。
• check_approvers 是一個輔助方法，用於取得核准者列表。
• 當核准者列表不為空時，傳回 (True, "")，表示核准透過；否則傳回 (False, "No approvals submitted")，表示核准失敗並附帶錯誤訊息。

多重核准類別的管理

為了管理多個核准類別，可以將它們放入一個列表中，並透過迴圈逐一檢查：

import sys

def main():
    approval_classes = [PeerApproval, SessionApproval, LedgerApproval]
    for approval_class in approval_classes:
        result = approval_class().is_approved()
        if result[0] == False:
            sys.exit(result[1])

內容解密：

• approval_classes 列表包含了所有需要執行的核準類別。
• 透過迴圈例項化每個類別並呼叫 is_approved 方法檢查核準狀態。
• 若任何一個核准檢查失敗，則立即離開程式並傳回錯誤訊息。

核准流程的組成

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 自動化審核流程最佳化變更管理

package "系統架構" {
    package "前端層" {
        component [使用者介面] as ui
        component [API 客戶端] as client
    }

    package "後端層" {
        component [API 服務] as api
        component [業務邏輯] as logic
        component [資料存取] as dao
    }

    package "資料層" {
        database [主資料庫] as db
        database [快取] as cache
    }
}

ui --> client : 使用者操作
client --> api : HTTP 請求
api --> logic : 處理邏輯
logic --> dao : 資料操作
dao --> db : 持久化
dao --> cache : 快取

note right of api
  RESTful API
  或 GraphQL
end note

@enduml

此圖示展示了 BaseApproval 類別與其子類別之間的繼承關係，以及如何將多個核准類別集合在一起進行管理。

紀錄與通知機制

除了核准流程外，紀錄和通知機制也是自動化流程中不可或缺的一部分。透過將自動化過程的日誌記錄到中央位置，可以方便後續的稽核和故障排除。同時，通知機制確保相關人員在流程執行或出錯時能夠及時獲知。

紀錄流程的重要性

紀錄流程有助於提高透明度和可追溯性，特別是在自動化任務的執行過程中。將紀錄與票務系統（如 Jira）整合，可以實作變更的自動追蹤和報告。

通知流程的必要性

雖然通知流程在初期看似多餘，但當出現問題時，它能提供即時的警示。隨著自動化流程的穩定執行，通知的頻率可能會降低，但其重要性依然不減。