機器學習系統上線後的維護工作至關重要，它直接影響系統的穩定性、效能和長期價值。本文探討了維護機器學習系統的關鍵要素，包括明確責任歸屬、團隊效率與冗餘之間的權衡，以及如何有效的檔案協調。實務上常遇到的問題是團隊成員對各自的責任範圍認知不清，導致任務延宕或錯誤發生。為避免此類別問題，建議使用 RACI 矩陣清晰定義每個成員的角色和責任，並搭配詳盡的和執行手冊，協助值班人員快速解決常見問題。此外，還需考量團隊的「公車因子」，避免過度依賴少數成員，並透過知識分享和檔案編寫降低風險。良好的檔案記錄是系統長期維護的根本，它不僅能幫助新成員快速上手，還能減少對特定人員的依賴，並確保系統的可維護性。
建構與維護機器學習系統的關鍵：所有權與維護
在前面的章節中，我們強調了開發和訓練機器學習（ML）系統的重要性，但同樣重要的是最佳化推理過程，以確保系統在營運階段的穩定性和效能。本章將重點討論維護機器學習系統的關鍵要素，包括所有權、責任歸屬、團隊效率與冗餘之間的權衡，以及適當的檔案協調。
16.1 責任歸屬
開發和營運一個ML系統是一個複雜的過程，難免會遇到挑戰和妥協。由於人員變動或優先事項的變更，原始設計和構建的系統可能無法完全遵循最佳實踐。因此，從一開始就必須考慮所有權和維護的問題。
在任何時候，瞭解以下三點至關重要：
- 每個參與專案的人員的責任範圍是什麼？是否存在責任/所有權的空白？
- 有多少人具備特定的知識？是否具備足夠的冗餘？
- 現有的檔案在哪裡？系統的哪些元件有檔案記錄？非負責團隊的人員是否能夠執行該系統？
設計檔案有助於部分回答這些問題，因此我們必須關注這些方面，以避免未來的問題。最終，目標是建立和維護一個能夠滿足需求並帶來價值的產品。
所有權與維護的重要性
維護一個健康的機器學習系統需要多個利益相關者的參與。在專案發展過程中，隨著新輸入的加入和模型的複雜化，清晰的責任歸屬變得越來越重要。
團隊效率與冗餘之間的權衡
在團隊效率和冗餘之間取得平衡是一個挑戰。一方面，過於分散的知識可能導致效率低下；另一方面，過於集中則可能導致「巴士因子」（Bus Factor）風險，即當關鍵人員離開時，專案可能會受到嚴重影響。
檔案協調的根本重要性
適當的檔案協調對於系統的長期維護至關重要。良好的檔案可以幫助新成員快速瞭解系統，並在必要時進行修改或修復。
複雜性的誘惑
在開發過程中，避免過度複雜化是非常重要的。簡單、清晰的設計往往更具魯棒性和可維護性。
內容解密：
- 關鍵概念：本章節強調了機器學習系統維護中的所有權和責任歸屬的重要性。
- 實際挑戰：討論了在開發和營運ML系統過程中可能遇到的挑戰，如人員變動和優先事項變更。
- 解決方案：提出了需要清晰的責任歸屬、適當的檔案協調，以及在團隊效率與冗餘之間取得平衡。
- 設計原則：強調了簡單、清晰設計的重要性，以避免過度複雜化。
- 長期價值：最終目標是建立一個能夠長期穩定執行並帶來價值的機器學習系統。
明確責任歸屬與團隊協作的重要性
在任何專案或系統的開發過程中，明確責任歸屬是確保專案成功的關鍵因素之一。隨著專案的推進，新的成員會加入，有些人會在短期內參與後離開，而有些人則會成為核心團隊成員。作為專案負責人，保持與這些成員的定期聯絡或至少個人認識是非常重要的。
明確責任歸屬的必要性
瞭解每個團隊成員的責任領域以及被分配到這些角色的人是至關重要的。這不僅適用於專案負責人，也同樣適用於實際負責特定元件的團隊成員。曾經發生過這樣的情況：成員A認為成員B負責某個部分，而成員B卻認為自己不負責。這種誤解可能導致專案延遲或失敗。
圖表說明：明確與隱含的參與方式
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333
title 圖表說明：明確與隱含的參與方式
rectangle "提高效率" as node1
rectangle "減少誤解" as node2
rectangle "增加風險" as node3
rectangle "降低效率" as node4
node1 --> node2
node2 --> node3
node3 --> node4
@enduml此圖示呈現了明確責任歸屬與隱含責任歸屬對專案結果的不同影響。
使用RACI矩陣進行責任劃分
為了避免責任混淆，可以使用RACI矩陣將參與專案的人員分為四類別：
- Responsible（負責執行任務的人）：通常是ML工程師等實際執行任務的人員。
- Accountable（最終負責人）：通常是專案負責人或資深工程師，具有批准或拒絕工作的權力。
- Consulted（被諮詢的人）：通常是領域專家或具有特定利益相關者。
- Informed（被告知進展的人）：通常是需要了解專案進展但不直接參與的人員，如前端工程師。
RACI矩陣範例程式碼
class RACIMatrix:
def __init__(self):
self.roles = {
'R': 'Responsible',
'A': 'Accountable',
'C': 'Consulted',
'I': 'Informed'
}
def display_roles(self):
for key, value in self.roles.items():
print(f"{key}: {value}")
# 使用範例
raci = RACIMatrix()
raci.display_roles()
內容解密：
RACIMatrix類別被定義用於管理RACI矩陣中的角色。__init__方法初始化了一個字典roles，其中包含了RACI矩陣中的四種角色及其簡寫。display_roles方法用於列印出RACI矩陣中的角色及其對應的簡寫。- 在使用範例中，建立了一個
RACIMatrix例項並呼叫了display_roles方法來展示RACI矩陣中的角色。
結語
在專案開發過程中，明確責任歸屬和使用適當的工具（如RACI矩陣）對於確保專案的成功至關重要。透過保持團隊成員之間的溝通和明確各自的責任，可以有效避免誤解和衝突，從而提高專案的效率和成功率。
帳號維護與責任歸屬
在軟體開發和維運的世界裡，責任歸屬的明確性至關重要。無論是為了提升系統的穩定性，還是為了確保問題能夠被及時有效地解決，明確的責任歸屬都是不可或缺的。然而，在實際操作中，總是存在一些模糊地帶，這使得建立一套明確的責任升級機制變得尤為重要。
值班輪換制度
值班輪換（on-call rotation）是一種常見的實踐，旨在確保在關鍵事件發生時，有專人負責及時回應。值班人員需要在規定的時間內（通常是30到60分鐘內）對事件做出反應。這種制度通常在團隊中輪換，以避免單一人員負擔過重。
圖示：值班輪換示意圖
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333
title 圖示：值班輪換示意圖
rectangle "圖示：值班輪換示意圖" as n1
rectangle "實作" as n2
rectangle "應用" as n3
n1 --> n2
n2 --> n3
@enduml此圖示呈現了值班人員之間的輪換關係。
隨著公司規模的擴大，值班輪換制度逐漸成為必要。在初期階段，每個人都可能隨時待命，但隨著團隊規模的擴大，這種做法變得難以管理。因此，建立正式的值班輪換制度是必然的選擇。
值班輪換的挑戰與解決方案
即便建立了值班輪換制度，仍然可能面臨一些挑戰。例如，在某些情況下，問題可能無法被及時解決，因為相關人員不清楚哪些系統受到了影響。為瞭解決這些問題，Arseny曾經經歷了一個痛苦的過程，直到相關的工程師編寫了詳盡的（cookbooks），列出了常見問題的解決方案。
內容解密：
- 詳盡的重要性：編寫詳盡的有助於快速解決問題，減少值班人員的工作負擔。
- 技術債的清理：透過清理技術債，可以減少系統問題的發生頻率，從而降低值班人員的工作強度。
- 專門的值班團隊：設立專門的值班團隊（如L1/L2/L3層級）可以進一步最佳化問題處理流程。
系統設計者的責任
我們認為，系統設計者和實作者也應該負責系統的維護和支援。他們對系統的細節瞭解得最清楚，能夠預測潛在的問題，並提供修復的捷徑。因此，他們應該為值班團隊提供必要的工具和檔案。
典型工具包括
- 日誌、指標、警示和儀錶板
- 系統及相關基礎設施組態
- 系統原始碼和檔案
內容解密：
- 日誌和指標的作用：詳細的日誌和指標有助於快速定位問題根源。
- 系統組態和檔案的重要性：完整的系統組態和檔案對於理解系統行為至關重要。
- 原始碼的存取：存取原始碼有助於深入理解系統內部邏輯。
生產資料的存取
存取生產資料有時受到限制，但通常有助於調查問題和找到根本原因。如果無法存取生產資料，日誌和指標應該足夠詳細，以幫助排查問題。
執行手冊（Runbook）
執行手冊應該包含常見問題的解決方案，以及在需要時升級問題的人員列表。例如，當供應商端出現故障時，值班工程師可能需要聯絡CTO來與供應商溝通。
內容解密：
- 執行手冊的作用：執行手冊為值班人員提供了快速解決常見問題的。
- 升級機制：明確的升級機制確保了在複雜問題面前，能夠及時獲得更高層級的支援。
從失敗中學習
生產問題引發瞭解決和學習兩個導向。為了避免重複犯錯，必須建立從失敗中學習的流程。這可以透過回顧和事後分析來實作。
內容解密：
- 比例回應原則：根據故障影響的大小和未來類別似故障的可能性，採取相應的措施。
- 事後分析的重要性：事後分析有助於總結經驗，避免類別似問題再次發生。
總之，明確的責任歸屬、完善的值班輪換制度、以及從失敗中學習的機制，都是確保系統穩定性和可靠性的關鍵。透過這些實踐，可以最大限度地減少系統問題帶來的影響，提升整體團隊的工作效率。
團隊結構與公車因子：效率與冗餘的平衡
在軟體開發和維護的過程中，團隊結構的設計對於專案的成功至關重要。其中一個重要的概念是「公車因子」（Bus Factor），它衡量的是當團隊中某個成員突然離開時，專案所面臨的風險。公車因子的名稱源自於一個假設性的情景：當某位團隊成員被公車撞擊而無法繼續參與專案時，團隊將面臨的困境。
為什麼效率過高並不有益？
如果一個團隊過於高效，以至於只有少數人掌握多個關鍵領域，那麼這個團隊就存在風險。每個成員都變得不可或缺，不僅因為他們的經驗，還因為他們的工作量已經達到飽和狀態。如果其中任何一位成員發生意外，整個公司或專案就會陷入困境。要維持原有的效率，唯一的辦法是依靠不可持續的「英雄主義」，這是一種反模式。
為什麼冗餘過高並不有益？
另一方面，冗餘意味著擁有額外的資源或能力，以支援主要系統的運作。適當的冗餘可以提供可靠性、安全性和改進的空間。然而，過多的冗餘會導致鬆懈，降低團隊成員之間的信任，並驅趕表現優秀的成員，因為這會損害整體的工作氛圍和意義。
何時及如何使用公車因子？
要保持效率和冗餘之間的平衡，第一步是能夠衡量這種平衡。公車因子是一個簡單而有效的指標。計算公車因子的步驟包括：找出負責不同系統或專案部分的成員，並評估有多少其他成員對這些領域有足夠的瞭解，能夠在需要時接手。
內容解密：
- 計算公車因子：找出每位負責特定系統或部分的成員，並評估有多少其他成員能夠在需要時接替他們的工作。
- 風險評估：根據公車因子的計算結果，評估專案面臨的風險，並採取相應的措施，如徵才新成員、調整團隊結構或進行知識分享活動。
- 知識分享：透過設計審查、程式碼審查、檔案編寫和配對程式設計等方式，促進團隊成員之間的知識分享，降低專案對特定成員的依賴。
檔案的重要性
檔案編寫是知識傳承和新成員培訓的重要手段。然而，檔案編寫常常被忽視，沒有得到應有的重視。良好的檔案能夠幫助新成員快速上手，並確保系統的長期可維護性。
內容解密：
- 檔案的作用：檔案是知識傳承和新成員培訓的重要工具，有助於降低學習曲線，確保系統的長期穩定運作。
- 檔案的挑戰：檔案編寫常常被延遲或忽視，因為它不像其他任務那樣緊急。
- 解決方案：將檔案編寫納入日常工作的一部分，確保檔案的及時更新和完整性。
此圖示說明瞭團隊結構與效率、冗餘之間的關係，以及如何透過公車因子評估風險並進行知識分享和檔案編寫，以達到平衡。
檔案的重要性與系統維護
良好的檔案記錄對於系統的維護和擴充套件至關重要。檔案不僅能幫助團隊成員瞭解系統的設計、架構和實作細節，還能促進跨部門協作，提高團隊的自主性和生產力。
為何檔案如此重要？
檔案有助於減少對特定人員的依賴，避免重複工作，並降低因缺乏資訊而導致的錯誤和延遲。透過記錄流程、程式、組態和最佳實踐，團隊可以更有效地工作，並為持續改進奠定基礎。
不同的檔案型別
- 使用者手冊和：提供使用系統的逐步說明，例如資料準備、模型訓練和預測。
- 程式碼片段和範例：提供簡單的方法來達成特定目標，例如使用系統和提供程式碼片段、資料範例等。
- 技術規格和API檔案：描述ML系統的底層技術細節，並提供如何使用函式和API與系統互動的指導。
- 安裝和組態：提供安裝和微調ML環境的說明，以及解釋依賴關係、安裝步驟和軟體組態選項。
- 常見問題和故障排除：解決使用ML工具時常見的問題，並提供解決方案或變通方法。
- 版本說明：詳細說明新軟體版本中應用的變更，解釋新功能、錯誤修復、效能改進或已知問題。
- 事件調查報告：分析和記錄過去問題或故障的根本原因，分享經驗教訓和措施，以避免類別似事件並提高系統可靠性和使用者信心。
簡化複雜度
根據熱力學第二定律，孤立系統的熵隨時間而增加。同樣地，軟體和ML系統也會隨著時間而增加熵，使其變得越來越難以維護。
管理複雜度的策略
- YAGNI（你不需要它） 方法：避免不必要的複雜度。
- 抽象化：透過新增新的抽象層來隱藏複雜度，但這並不能真正降低整個堆積疊的熵。
如何有效管理檔案和複雜度
- 從一開始就優先考慮檔案記錄，而不是事後補充。
- 投資時間和精力建立和維護檔案，以降低知識差距和對特定人員的依賴所帶來的風險。
- 保持檔案的簡潔性和可讀性，避免不必要的複雜度。
簡化與複雜性的平衡：軟體開發中的 KISS 原則與 DRY 原則之爭
軟體開發領域長期以來存在著一對基本矛盾：簡化（Simplicity）與複雜性（Complexity）。這兩個看似對立的概念在不同的開發哲學中被反覆提及，例如源自美國海軍的 KISS（“Keep it simple, stupid”）原則，以及中世紀的奧卡姆剃刀（Occam’s Razor）原理，均強調簡化設計的重要性。然而，軟體工程文化卻往往傾向於另一端，推崇如 DRY（“Don’t repeat yourself”）等原則。這些原則乍看之下頗具爭議，因為遵循 DRY 原則往往意味著引入更多的抽象層，而這正是複雜性的主要來源之一。
簡化與複雜性的兩極化表現
試想一個簡單的程式碼範例，用於計算多個資料集中的某個已知指標。一般而言，這樣的程式碼可能包含三個函式：讀取資料、計算指標、以及協調執行（在迴圈中執行前兩個函式並儲存結果）。然而，這個簡單任務的實作方式卻可能走向兩個極端：一端是過於簡單直接的程式碼，另一端則是過度複雜的程式碼。
# 簡單直接的實作方式
def calculate_metric_simple(file_list):
results = []
for file in file_list:
data = read_data(file)
metric = compute_metric(data)
results.append(metric)
return results
#### 內容解密：
此實作方式直接在單一函式中完成所有操作，雖然簡單，但缺乏模組化和可重用性。
- `read_data(file)` 函式負責讀取指設定檔案的資料。
- `compute_metric(data)` 函式負責計算給定資料的指標。
- 整個過程在 `calculate_metric_simple` 函式中以迴圈方式執行。
# 過度複雜的實作方式
class MetricCalculator:
def __init__(self, file_list):
self.file_list = file_list
def read_data(self, file):
# 讀取資料的邏輯
pass
def compute_metric(self, data):
# 計算指標的邏輯
pass
def execute(self):
results = []
for file in self.file_list:
data = self.read_data(file)
metric = self.compute_metric(data)
results.append(metric)
return results
#### 內容解密：
此實作方式透過類別和物件導向程式設計引入了更多的抽象層，使得程式碼更具擴充套件性，但也更為複雜。
- `MetricCalculator` 類別封裝了資料讀取、指標計算和執行的邏輯。
- 每個方法負責特定的任務，提高了模組化程度。
- `execute` 方法協調各個步驟的執行。
這兩個範例說明瞭簡化與複雜性之間的取捨。過於簡單的程式碼可能缺乏必要的抽象和模組化，而過度複雜的設計則可能引入不必要的抽象層次，從而降低程式碼的可讀性和維護性。
大規模系統中的簡化與複雜性
同樣的原則也適用於更大規模的系統設計。例如，當企業希望幫助客戶支援團隊優先處理最緊急的案件時，常見的解決方案是使用大語言模型（Large Language Model）配合客製化的提示（Prompt）來分類別訊息的緊急程度。在此之前，傳統的方法可能是建立一個簡單的模型（如根據詞袋模型的邏輯迴歸）來進行分類別。
# 簡單模型範例
from sklearn.feature_extraction.text import CountVectorizer
from sklearn.linear_model import LogisticRegression
def simple_model(messages):
vectorizer = CountVectorizer()
X = vectorizer.fit_transform(messages)
model = LogisticRegression()
# 假設 labels 已給定
model.fit(X, labels)
return model
#### 內容解密：
此範例展示了一個簡單的文字分類別模型。
- 使用 `CountVectorizer` 將文字訊息轉換為向量表示。
- 使用 `LogisticRegression` 建立分類別模型。
- 模型訓練過程中需要給定標籤（labels）。
然而，這個任務的實作同樣可能走向兩個極端：要麼過於簡單直接，例如使用多個 if 陳述式和正規表示式來進行分類別；要麼過度複雜，例如引入多個複雜的自然語言理解模型，並進行大量工程上的最佳化。
