傑出作業

絕佳的 Salesforce 解決方案不會建立一次,會持續精簡。透過監視解決方案的執行方式並精簡其運作方式,將卓越的營運功能內嵌在您的系統中,使其能夠以預測的方式提供業務價值,並在發生故障時快速復原。

忽略卓越營運會對解決方案造成可預測的後果。手動部署程序會變成瓶頸,使功能傳遞速度變慢並增加錯誤風險。監視不足會使事件偵測延遲,直到使用者回報問題為止,延長影響持續時間並破壞 Trust。缺少自動化會要求作業小組依解決方案複雜度比例成長,進而建立不可持續的成本趨勢。監視不良且失敗的批次工作可能會損毀資料或下游程序,而不會有人注意到。

針對卓越營運而設計的解決方案可讓小組透過全方位監視觀察系統行為、使用自動化管道安全部署變更、使用預先定義的程序有效回應事件,並透過無罪審查從營運體驗中學習。這些功能會隨著時間複雜。早期投資於營運基礎的小組提供功能的速度更快且更可靠,相較於延後營運疑慮的小組,直到生產問題迫使反應性投資為止。

卓越的作業可直接與其他結構支柱連線。可靠性取決於偵測失敗的監視和可快速復原的自動化。Trust 需要安全的開發週期作法,以及作業變更的稽核追蹤。資源最佳化受益於由作業遠程測量所通知的持續改善。成本最佳化需要部署效率和自動化,以防止營運費用增加。這些支柱共同建立可透過永續營運投資提供持續業務價值的解決方案。

Salesforce 會操作基礎結構—伺服器、資料庫、執行階段和網路。您所操作的是建立在其中的一切—定義您解決方案的中繼資料、管理其行為的組態、經由其流動的資料、連接該解決方案的整合,以及在其中採取動作的工作人員。

此分部會塑造您所做的每個作業決策。雖然 Salesforce 可確保平台可用、效能高且安全,但您必須設計可觀察、可部署、可自動化和可復原的解決方案。平台的多租戶結構表示解決方案中的作業問題可能會觸發個別交易失敗的管理員限制,以及在整個組織中串聯的列鎖或資源爭用。您無法在實際情況後專注於可觀察性、部署安全性或事件整備,而無須額外努力或重新工作。

在此指南中,您將瞭解如何設計和實作可將 Salesforce 解決方案轉為可靠、永續系統的作業作法 (監視、部署自動化、事件回應和持續改善)。

使用這些原則來引導您的結構決策,以在平台上獲得傑出作業。

• **以可觀察性進化。**設計初始版本的全方位可觀察性,而不是在出現問題後反應地重新調整儀器。可觀察的系統會顯示它們在實際狀況下如何運作,以啟用資料驅動的結構改善和快速問題診斷。可觀察性是一種結構性考量事項,從一開始就塑造解決方案設計—儀器、監視和遠程測量收集決策會影響資料模型、整合模式和元件邊界。

• **標準化作業程序。**來源中的版本組態和作業程序會與應用程式程式碼一起控制。編碼作業可啟用自動 Salesforce DX 部署、Sandbox 重新整理自動化,以及跨環境一致執行的中繼資料部署。組織組態的相關Knowledge會轉換為任何小組成員可執行的可執行指令檔。當程序在版本控制中生效時,其會透過與應用程式功能相同的檢閱和改善週期進行演進,建立可重現的作業模式,以大幅減少組態漂移。實作卓越中心。

• **採用 DevOps 文化。**破壞開發、作業和業務小組之間的組織孤立區。解決方案成果的共用責任會取代將工作移到牆上。DevOps 文化可減少摩擦、加速回饋意見迴圈,並建立對營運影響的責任。結構設計師可透過支援協同合作的技術選擇,以及移除共用責任結構阻礙的組織倡議來啟用 DevOps。

• **自動化以提高效率。**自動化重複的作業工作,以免除手動工作、減少人力錯誤,並讓作業調整規模,同時最佳化成本和資源用量。經常重複的手動作業是自動化的良好候選項目。透過已儲存的小時、錯誤減少和已建立的作業容量來測量自動化值。

• **從所有作業事件中學習。**從事件、效能異常、近乎失敗和成功作業中提取組織學習。無罪的死後工作專注於系統改善,而非個別錯誤,為誠實評估建立心理安全。作業遠端測試會顯示跨事件的模式,以啟用主動預防。學習文化會將營運體驗轉換為隨著時間複雜的組織能力。

瞭解 Salesforce 作業的內容可協助您將作業設計工作專注在您控制的項目上。此平台會處理在傳統 IT 環境中需要專屬的小組的基礎結構疑慮:

• **基礎架構的可靠性與效能:**Salesforce 會監視和維護所有例項中的伺服器容量、資料庫效能、網路可用性和儲存系統。平台狀態會顯示在 status.salesforce.com 中,其中包含即時事件更新和計畫維護期間。
• **平台更新與修補程式:**每年有三個主要版本 (Spring、Summer 和 Winter) 提供新功能、安全性修補程式和效能改善。Salesforce 會管理版本時間、API 版本支援和淘汰,以及平台層級變更的變更管理。您在生產部署前,在 Sandbox 環境中針對版本測試您的解決方案。
• **多租戶資源管理:**管理員的限制存在於維持共用基礎結構的公平性,因為您在與其他客戶相同的資源上執行,因此 Salesforce 會對如 CPU 時間、堆疊大小、Salesforce 物件查詢語言 (SOQL) 查詢、資料操作語言 (DML) 陳述式和 API 呼叫等項目強制執行限制,因此任何單一租戶都無法過度耗用容量。雖然 Salesforce 會透過授權層級追蹤整體使用狀況,並讓客戶針對某些限制 (例如 API 呼叫) 要求更高的配置,但各個交易 Apex 管理員限制本身是固定的,並以相同的方式對每個人強制執行。
• **核心平台安全性作業:**Salesforce 安全性小組可監視威脅、管理漏洞揭露和修補程式、維護安全性認證,以及回應平台級安全性事件。此基本安全性會建立您建立解決方案特定安全性控制項的基準。
• **災害復原與業務連續性:**Salesforce 會維護地理散佈的資料中心、測試災害復原程序,並維護可在沒有客戶動作的情況下啟用故障切換的冗餘系統。基礎結構失敗期間,平台級復原會以透明的方式發生。

這些平台作業會建立您建立的基礎。您不為基礎結構佈建伺服器、修補程式資料庫或設計災害復原。不過,您仍會對您在基礎上建立和設定的所有內容負責。

「共用責任模型」表示您擁有 Salesforce 中所建立所有項目的最佳營運能力。平台作業可啟用您的工作,但無法加以取代。您的作業責任涵蓋五個相互連線的區域:

可觀察性是從外部輸出瞭解內部系統狀態的能力。可觀察的 Salesforce 解決方案可讓運算子回答有關系統行為的問題、診斷失敗,並驗證假設,而無須為每個調查部署新儀器。監視 (使用預先定義的顯示面板回答已知問題) 和可觀察性 (使用全方位測量回答任意問題) 之間的區別很重要,因為生產系統會產生超出您設計期間預期的非預期行為。

針對 Salesforce 解決方案,觀察性會跨越三種適合平台多租戶模型的互補訊號類型:

• 記錄 - 使用完整的內容資訊來捕捉離散事件。「事件監視」提供「事件記錄檔案」,以使用要求內容 (包括使用者身分、時間戳記、持續時間和成果) 來捕捉 API 呼叫、登入事件、Apex 執行、SOQL 查詢、Visualforce 頁面、Lightning 頁面和報告執行。記錄回答問題,例如「哪些使用者遇到此錯誤?」和「成功與失敗之間的變化為何?」
• 度量 - 一段時間彙總的數值度量,顯示趨勢與模式。度量包括 API 耗用率、Apex CPU 時間散佈、批次工作成功率、整合延遲百分位,以及使用者流程完成率。度量會回答如「效能是否隨著時間降級?」的問題。和「我們是否接近管理員限制?」
• 追蹤 - 透過分散式系統顯示要求路徑,顯示延遲來源和失敗點。針對 Salesforce 解決方案,追蹤可將同步 API 呼叫連線至非同步處理鏈、平台事件連線至訂閱者執行,以及將整合要求連線至外部系統回應。追蹤如「延遲在此流程中累積於何處」等問題的回答。和「此多步驟流程中的哪個元件失敗?」

針對初始結構可觀察的設計。關於要啟用哪些「事件監視」事件類型、如何建構平台事件裝載以取得營運可視性的決定、將整合檢查點放置在何處,以及要實作哪些自訂記錄,都會塑造解決方案的長期作業能力。若要將可觀察性重新調整為現有解決方案,則需要對大多數元件進行儀器變更,並在作業改善工作期間造成錯誤的風險。

Salesforce 提供專為目的而建置的監視功能,結構設計師應從一開始就進行設計。

「事件監視」 會在整個您的組織中收集詳細的作業資料。事件類型包括 API 用量、登入活動、登出事件、Apex 執行、SOQL 查詢、Visualforce 頁面載入、Lightning 頁面檢視、報告執行、文件附件、內容轉移,以及您定義的自訂事件。「事件監視」提供安全性分析、效能最佳化、產能規劃和合規性報告的基礎。

針對生產環境啟用「事件監視」,並建立「事件記錄檔」的自動匯出至外部彙總平台。大多數事件類型的原生保留受到限制,不適用於趨勢分析、產能規劃和合規性需求。外部彙總可啟用歷程記錄分析、與其他系統的企業遠距測量關聯、進階分析,以及符合法規需求的保留期間。

Proactive Monitoring 會持續評估您組織的效能和延展性風險,並在預先定義的訊號變成使用者可見的事件之前警示。Proactive Monitoring 會偵測模式,包括接近每日配置的 API 要求限制高峰、指出共用資源爭用之同時 Apex 執行失敗、接近管理員值的 SOQL 列限制,以及建議改善設計之列鎖定爭用。

Proactive Monitoring 使用 Salesforce 管理的一組預先定義的警告與警示值。針對需要更深入的效能可視性且想要調查基準與趨勢的組織,「規模中心」提供詳細的執行階段分析,涵蓋 CPU 逾時、同時和列鎖定、管理員限制錯誤和資料庫效能。

資料偵測 (需要 Salesforce Shield) 會掃描標準和自訂物件欄位,以識別、分類和修復文字、Rich Text 和加密欄位中的敏感資料,例如個人可識別資訊 (PII)。其使用原生平台處理與模式比對和自訂規則運算式,以將假陽性降到最低。針對新記錄或修改的記錄執行循環掃描 (每週或每月),並排除已分類或淘汰的欄位。

使用發現結果來驅動下游管理更新合規性分類、強制執行 Shield Platform Encryption、觸發「事件監視」安全性原則,或套用 Sandbox 資料遮蔽。

規模中心提供長時間執行作業、輸出模式、例外熱點和管理員限制耗用的交易層級可視性。「刻度中心」會顯示哪些作業耗用最多資源、哪些交易接近逾時值,以及最佳化投資將在哪些地方產生最大的營運影響。

在解決方案穩定化期間建立「刻度中心」基準,並在每個主要版本後重新造訪基準。沒有內容的效能難以解譯。基準比較會顯示變更是否改善或降低效能,以引導進一步的最佳化決策。

• **設定稽核追蹤:**追蹤組態變更,包括權限修改、中繼資料部署、管理動作和安全性設定更新,原生保留最多 180 天。「設定稽核追蹤」會透過顯示誰變更了什麼組態以及何時,來支援安全性調查、合規性驗證和事件死亡後測試。匯出「設定稽核追蹤」項目,以在規範或合約需求需要較長的歷程記錄時保留超過 180 天。
• 欄位稽核追蹤:(需要 Salesforce Shield) 追蹤歷程記錄欄位值的變更。針對包含敏感資料的欄位、需要變更歷程記錄的監管資料,或瞭解歷程記錄值有助於作業和合規性報告的重要業務資料,選擇性啟用「欄位稽核追蹤」。
• **健康檢查:**提供自動安全性組態評估,將目前設定與 Salesforce 安全性基準建議進行比較。根據您環境的風險優先順序排程,排程每季「健康檢查」檢閱和補救發現結果。如果您擁有薪水控制項或與預設建議不同的風險容忍,則並非所有發現都需要補救,但每個發現都應謹慎檢閱。

平台監視會顯示組織層級健康狀況,但會忽略應用程式特有的問題。透過儀表重要業務旅程,從使用者觀點監視應用程式健康狀況:

根據業務影響定義重要使用者流程,並監視端對端成功率、完成時間、捨棄點數和錯誤率。重要流程通常包括產生收入的活動 (訂單提交、契約執行、機會結束)、大量活動 (使用者登入、搜尋作業、記錄建立),以及必要的合規性活動 (同意收集、資料主題權利履行、敏感稽核工作流程)。

具有里程碑標記的儀器流程會在每個重要步驟中指出開始、完成、捨棄和失敗。當流程成功率低於可接受的值或持續時間超過延遲目標時,會發出警示。流程級監視會顯示在元件級監視中不可見的問題,因為觸及多個 Apex 類別、數個流程、三個平台事件和兩個外部整合的使用者旅程可能會在任何轉換點失敗。

雙向監視整合健康狀況。追蹤對外部系統的輸出呼叫成功率、延遲、重試模式和錯誤類型。追蹤外部系統的輸入通話,以瞭解流量模式、驗證失敗、資料驗證錯誤和處理持續時間。整合監視通常會在操作員偵測到外部系統問題之前顯示,進而啟用主動升級。

與外部合作夥伴建立整合 SLA,並根據認可的目標監視實際績效。發生服務層級協定 (SLA) 缺口時,遠端測試會區分問題來自於 Salesforce、整合層、網路路徑或外部系統。在事件升級和契約協商期間,此差異十分重要。

服務層級指標 (SLI) 是精確選取的度量,代表使用者認知的品質。「服務層級目標」(SLO) 是 SLI 的目標值,可平衡使用者期望與營運投資。針對 Salesforce 解決方案,有效的 SLI 包括:

• **可用性:**解決方案成功回應使用者要求的時間百分比。從使用者觀點測量可用性,而不是從基礎結構觀點測量。無論平台執行時間為何,平台可供使用但使用者因為單一登入 (SSO) 設定錯誤而無法登入的解決方案都無法使用。
• **延遲:**從使用者動作起始到可見回應的時間。定義特定百分位數 (p50、p90、p99) 的延遲目標,而非平均值,因為平均值會隱藏受慢速要求影響的可怕體驗。p99 延遲 8 秒表示 100 個要求中的 1 個花費 8 秒以上的時間,這可能代表高流量解決方案中每天有數千個不良體驗。
• **成功率:**未顯示使用者可見錯誤的作業完成百分比。區分使用者造成的錯誤 (輸入無效、權限不足) 和系統造成的錯誤 (管理員限制失敗、整合逾時、未處理的例外狀況)。只有系統導致的錯誤會計入成功率 SLO。
• **輸出:**每時間單位完成的作業量。批次處理、資料匯入、排程工作和大量作業的輸出量十分重要,其中符合業務期限取決於處理容量。

根據使用者需求設定 SLO,而非技術功能。問題不是「我們可以這麼做多快?」但「使用者必須以多快的速度完成其目標?」如果使用者可以容忍兩秒,則 200 毫秒的頁面載入目標沒有意義。相反地,如果使用者在 500 秒之後放棄,則兩秒的目標沒有意義。使用者研究、工作階段分析和業務需求會告知實際的 SLO 目標。

監視 SLI 燃燒率,以偵測累積的 SLO 違規何時耗用錯誤預算。錯誤預算代表可接受的失敗率,以平衡使用者體驗與營運投資。當燃燒率超過永續性層級時,請停止功能工作並專注於可靠性改善,直到 SLO 恢復為止。此規範可防止小組忽略降低可靠性的常見模式,同時追蹤功能期限,直到災難性失敗強制執行緊急應變為止。

當自動系統偵測到需要人類判斷或動作的問題時,警示會通知人類。有效警示可將涵蓋範圍 (偵測到實際問題) 與精確度 (避免假警示) 平衡。警示不足會錯過事件 (警示過少、值太高),或會導致警示疲勞 (警示過多、值太低),以便運算子學習忽略通知。

設計可操作性的警示。每個警示應回答三個問題:

1. 問題為何?
2. 此項目為何重要?
3. 我應該做什麼?

缺少明確回答的警示會訓練運算子忽略警示。例如,警示表示「API 呼叫超過 80% 的限制」,但沒有關於哪些 API、哪些整合或要採取的動作的內容,則提供的回應資訊不足。

實作符合作業升級程序的警示嚴重性層級:

• **重要警示:**表示無論當天何時,都需要立即回應的使用者面向服務降級。通話工程師的重要警示頁面。範例包括超過設定的上限的登入失敗、低於可用性 SLO 的收入產生流程,或資料遺失偵測。
• **警示:**表示在沒有介入的情況下會變為嚴重但尚未影響使用者的問題。警告會產生營業時間調查的票證。範例包括 API 耗用趨勢達到每日限制、完成但遺漏 SLA 目標的批次工作,或整合錯誤增加但仍低於失敗值。
• **資訊警示:**無須採取動作即可讓您瞭解作業變更。資訊警示會顯示在監視顯示面板中,但不會產生通知。範例包括成功部署、排程維護完成或組態變更。

建立警示檢閱步調,以評估警示品質,並根據實際事件模式調整門值。追蹤警示度量,包括真陽性率 (指出實際問題的警示)、假陽性率 (沒有問題的警示),以及解決時間 (警示解決事件的速度)。高假陽性率表示需要調整才能還原運算子Trust的敏感度過高。

DevOps 文化結合了統一小組的開發和作業責任,這些小組從初始程式碼認可到生產作業擁有解決方案成果。與傳統的隔離組織相比,DevOps 可提供更快的傳遞、更高品質和更佳的營運成果,開發人員將工作交給缺乏有效執行內容的營運小組。

來源驅動的開發會將所有解決方案成品 (中繼資料、組態、程式碼、文件) 視為版本控制的來源檔案,而非僅存在於組織中的點選設定。來源控制可啟用可重複的建立、協同合作開發、變更追蹤和自動部署管道。

Salesforce DX 提供來源驅動開發的工具鏈。中繼資料 API 會將組織組態公開為 XML 檔案。臨時組織提供從來源控制建立的可處理開發環境。CLI 工具可啟用指令檔部署和組織操作。版本控制系統 (包括 Git) 可追蹤變更並啟用協同合作工作流程。

刻意建構中繼資料以啟用小組協同合作。模組化封裝結構可讓小組獨立工作,而不會發生合併衝突。將共用元件 (版面配置、權限集和自訂欄位) 與功能特定的元件 (Apex 類別、流程和 Lightning 元件) 分開。清除擁有權界限可防止所有人變更一切的混亂。

在變更進入生產環境之前,程式碼審查可提供品質控制、Knowledge 共用和學習機會。有效的程式碼檢閱會平衡完整性和速度,提供有意義的回饋意見,而不會變成部署瓶頸。

建立清楚的檢閱條件。檢閱者檢查:

• 正確性 - 程式碼是否遵循其宣告?
• 維護性 - 未來開發人員可以瞭解並修改此項嗎?
• 績效 - 此方法是否調整適當?
• 安全性 - 是否有注射風險或權限略過?
• 一致性 - 此項目是否符合專案模式與標準?

若沒有明確的條件,則檢閱會變為主觀或概觀。

需要兩個批准才能進行繫結的變更。單一檢閱者批准會建立 Knowledge 孤島,並忽略替代透視圖會抓到的問題。雙檢閱者需求會散佈 Knowledge、將總流程係數保持在一以上,並找出更多瑕疵。根據小組數量平衡批准需求—在五人小組中要求三次批准會造成瓶頸。

將提取要求 (PR) 保持小。具有數百個變更線條的 PR 會收到短暫審查,因為檢閱者會面臨巨大的認知負載。在 200-400 行內變更一個功能的 PR 會收到完整審查,並找出細微的問題。將大型功能拆分為可檢閱的區塊,以增量方式提供。

自動化機器檢查。程式碼格式化、命名慣例合規性、測試涵蓋範圍需求和靜態分析檢查應自動執行,而非耗用檢閱者注意。檢閱者應專注於需要人類判斷的邏輯、設計和維護性問題。

測試可確保解決方案正確運作,並在變更累積時繼續運作。有效測試會將涵蓋範圍 (程式碼和功能測試的執行量) 與執行速度 (測試套件完成的速度) 和維護負擔 (維護測試所需的工作量) 平衡。

• **單元測試:**以個別方式驗證個別元件。Apex 單元測試會隔離現有組織資料和外部相依性,來驗證方法和類別。Lightning Web 元件測試會驗證元件邏輯和不含後端 API 的呈現。設計良好的單元測試會以秒為單位執行,在開發期間提供即時的回饋意見。僅單元測試的最低需求代碼涵蓋範圍目標高於 75%,將涵蓋範圍視為下限而非上限。
• **整合測試:**驗證元件之間的互動。整合測試會執行實際資料庫作業、實際呼叫模擬的外部系統,以及驗證管理員限制行為。整合測試會抓出單元測試遺漏的假設—非預期的資料狀態、權限問題、大量作業限制,以及觸發順序相依性。每個測試會以秒到分鐘為單位執行整合測試。
• **端對端 (E2E) 測試:**驗證從登入到工作完成的完整使用者旅程。E2E 測試會針對完整 Sandbox 環境執行,執行 UI 互動、後端程序、非同步作業和整合接觸點。E2E 測試會抓住只有在完整系統執行時出現的問題—競爭狀況、非預期的使用者工作流程,以及環境組態問題。針對全方位套件,E2E 測試會以分鐘為單位執行。
• **效能測試:**驗證載入中的解決方案行為。效能測試會根據實際的流量模式測量回應時間、輸送量、資源消耗及管理員的鄰近度。效能測試會防止發佈效能降低的變更、在生產前抓取 N+1 查詢模式,以及在高季之前驗證容量標題。效能測試需要類似生產的資料量,並在專屬測試環境中執行。

實作測試金字塔圖策略:許多快速單元測試、較少的整合測試、選擇性 E2E 測試以及在裝載下個別驗證的效能測試。此平衡可啟用快速迭代 (快速單元測試可提供立即的回饋意見),同時確保整合點正確運作 (整合測試會抓住跨元件的問題),且使用者體驗仍可接受 (E2E 測試會驗證完成的旅程)。

在 CI 銷售管道中自動化測試執行。請勿在認可之前手動執行測試套件,而是讓 CI 在每次認可之前自動執行測試套件。自動測試會立即抓住迴歸,持續強制執行品質標準,並防止手動測試在期限壓力期間變為選用時發生的漸進式品質衰退。

持續整合 (CI) 和持續部署 (CD) 管道會自動化從程式碼認可到生產部署的路徑。CI/CD 可減少人為錯誤、加速回饋意見、提供一致的品質檢查,並啟用快速的發行步調。

• 連續整合會自動建立、測試和驗證每個程式碼認可。當開發人員將認可推送至版本控制時,CI 系統會開發新的組織、部署變更、執行自動化測試套件、執行靜態程式碼分析、檢查測試涵蓋範圍需求,並在幾分鐘內報告結果。快速回饋意見可讓開發人員在內容新增時修正問題,而不是在手動整合測試期間稍後發現問題。

請先要求 CI 成功,才能允許合併至主要分支。此規則 (通常稱為「protect main」) 可防止損壞的程式碼在共用分支中累積,進而封鎖其他開發人員。具有 CI 門的受保護分支可讓主要分支隨時保持可供部署,從而啟用隨選發行,而非當主要發生時發行。

• 連續部署會自動透過環境將驗證的變更部署至生產環境。在 CI 驗證隔離環境中的變更後,CD 管道會部署至整合 Sandbox、執行額外的測試、部署至暫存、執行最後驗證,並選擇性地將部署至自動或手動批准門之後的生產。

在生產部署期間實作限制爆炸半徑的漸進式部署策略:

• **藍綠色部署:**維護兩個相同的生產環境。流量會路由至藍色環境,而綠色環境會收到新的部署。驗證後,流量會切換至綠色環境。藍色環境會保持為立即回復目標執行。
• **Canary 部署:**會在完整部署前發行對小型使用者子集的變更。初始 Canary 會收到少量流量,同時監視錯誤率、延遲和使用者行為。成功的 Canary 會漸進式擴展 (例如,從 5% 擴展到 25%、接著 50%,接著 100%)。在標準部署期間偵測到的問題會中止版本,然後再影響所有使用者。標準部署適用於 Salesforce 解決方案,其外部路由圖層或功能標記可啟用選用的功能曝光。
• **功能標記:**啟用功能可視性的執行階段控制,無論部署時間為何。新功能會部署至生產環境中,但會在標記後保持隱藏,直到明確啟用為止。功能標記透過切換標記而非部署程式碼,支援標準部署、A/B 測試、漸進式首展和立即回復。

備註:藍色與藍色綠色部署模式適用於透過資源配置和流量散佈控制在 CloudHub 2.0 上所部署 Heroku 或 MuleSoft 應用程式上主控的自訂應用程式。核心 Salesforce Platform 中繼資料部署是所有或無項交易。

Infrastructure as Code (IaC) 會將環境的定義 (組織形狀、中繼資料、相依性,以及使其運作的組態和種子資料) 視為版本控制的來源,而非每個組織中手動進行的設定。在 Salesforce 上,沒有要佈建的伺服器,因此 IaC 會管理環境的組合方式,而非其下的硬體。編碼的環境可複製、可比較和可處理,這正是讓環境無法漂移的原因。

環境是由來源而非手動組態所定義。臨時組織定義檔案會指定版本、啟用的功能和設定,因此任何人 (或管道) 都可以依需求開發相同且可處理的組織。Sandbox 採用不同的路徑:其會從命名複製類型與範本的定義中佈建,然後從其複製的生產組織繼承組態,為整合與暫存提供更高的忠誠度環境。封裝定義會宣告解決方案的元件和相依性,使組建可從來源複製,而非依賴長期組織的累積狀態。

每個環境都假定的基準也會經過版本化。自訂中繼資料、已命名認證組態和自訂設定定義會作為中繼資料部署,同時設定值和參照記錄會從版本化種子資料中載入。同時將兩者保持在來源控制中,表示每個環境皆從已知且一致的基準開始,而非手動設定的基準。

以此方式編碼環境會攻擊其來源的組態漂移。當環境的定義位於版本控制中時,環境之間的差異會顯示為可見的差異,而非無訊息的差異,且重新建立乾淨的環境比除錯已漂移的環境更快。從來源重新佈建會在環境損毀時縮短復原時間,並讓管道在無手動設定的情況下,為每個變更做好處理。

Sandbox 提供開發、測試和訓練的隔離環境,而不會造成生產資料或組態的風險。有效的 Sandbox 策略會平衡環境忠誠度 (Sandbox 與生產的相符程度) 與成本和重新整理頻率。

• 開發人員 Sandbox 提供輕量型隔離環境供個別功能開發使用。開發人員使用開發人員 Sandbox 來從來源控制建立臨時組織,以與共用相依性整合測試。Developer Sandbox 與臨時組織會經常重新整理,讓組態與生產環境同步。
• 整合 Sandbox (開發人員專業或部分複本) 提供多個功能整合與互動的共用環境。整合 Sandbox 包含足夠的生產資料,以測試實際的工作流程,而不需要完全資料複本的成本和複雜性。整合測試會在升級至暫存之前,針對整合 Sandbox 執行。
• 暫存 Sandbox (完整複本) 會反映生產組態與資料,並在生產部署前提供最後驗證。暫存 Sandbox 會在生產之前接收版本,讓部署程序、效能特性和資料移轉指令檔類似於生產環境的測試功能。暫存 Sandbox 每季重新整理一次,或在主要版本之前重新整理一次。
• 訓練 Sandbox 提供實際的使用者訓練和示範環境,而無須公開實際的客戶資料。訓練 Sandbox 可能包含已同步化的資料或匿名化的生產資料。訓練環境長時間保持穩定,以支援一致的訓練資料和認證流程。

自動化 Sandbox 重新整理和資料載入。手動 Sandbox 重新整理會變成瓶頸,以防止使用類似生產的資料進行頻繁測試。自動重新整理程序結合資料載入指令檔可啟用隨選環境重設,同時支援連續整合銷售管道和手動測試需求。

注意:「Sandbox」在代理企業中有兩個不同的意義。上述 Sandbox 是環境:小組在變更到達生產環境前建立與測試之組織的隔離複本。Sandbox 工作人員的動作不同。這是限制自動動作執行位置和方式的執行階段邊界,透過範圍權限、受限制的物件和整合存取權,以及受控制的執行,因此工作人員無法超出其預期的範圍。這兩者互相補充:Developer Sandbox 是您針對非生產資料驗證工作人員動作的位置,而動作 Sandbox 是生產環境中包含這些動作的部分。

即使使用自動化管道,部署仍會帶來風險。安全部署作法透過驗證、監視和控制執行來降低風險:

• **部署驗證:**將部署作為實作執行,而不認可變更。驗證會在實際部署前抓出部署錯誤—遺失相依性、元件衝突、無效參照。Salesforce 透過 UI 和 CLI 支援驗證部署,即使實際部署等待維護期間,仍可在營業時間內在生產環境中啟用驗證。
• **部署監視:**監視部署期間和之後的主要度量。監視錯誤率、效能度量、使用者流程成功率和 API 耗用。部署後突然變更表示需要調查和可能回復的迴歸。自動監視會比較預先部署與後續部署度量,並在統計差超過值時警示。
• **部署執行手冊:**文件部署程序,包括先決條件、執行步驟、驗證檢查、回復程序和通訊計畫。執行手冊會將部署從繁重的部落 Knowledge 儀式轉換為任何人都可以執行的例行程序。執行手冊會透過部署追溯觀察來進行演進,這些觀察結果會收集學到的經驗,並防止重複發生問題。
• **回復功能:**提供部署失敗時的逸出路徑。Salesforce 中繼資料結轉需要重新部署先前版本,而非原生結轉指令,因此版本控制十分重要。針對每個生產版本維護部署封裝,以啟用快速重新部署。針對資料變更,請維護可啟用還原的預先部署備份。如需組態變更,請在「設定稽核追蹤」中追蹤先前的值。

排程在部署影響較少使用者的低流量期間進行部署。週末和夜間部署可將業務風險降到最低,但會增加營運負擔。平衡使用者影響與小組永續性。具有強大部署作法和全方位監視的解決方案可以在營業時間內安全部署,但未經驗證的解決方案可從暫時部署中獲益,直到建立信任為止。

組態是管理解決方案行為 (組織設定、功能、權限、整合和自訂) 的中繼資料。組態變更會立即影響在沒有程式碼部署的情況下執行的解決方案,讓組態管理對作業穩定性而言至關重要。

來源控制程式碼中的版本組態。設定檔定義、權限集指派、自訂設定、平台事件定義、已命名認證和遠端網站設定皆屬於版本控制。版本化組態可啟用部署自動化、變更追蹤、環境一致性和回復功能。

偵測並修復組態漂移。隨著時間的推移,當管理員進行直接變更時,生產組織會從記錄的組態中漂移、熱門修正程式會略過一般部署流程,且未記錄的因應措施會累積。生產組態與版本控制之間的自動比較會顯示漂移。排程每季漂移偵測和補救措施,以防止組態債務累積到部署變得無法預測的程度。

文件組態決策及其原因。未來維護者不僅需要瞭解設定的項目,還需要瞭解原因。將組織範圍預設值設定為「帳戶專用」,但「連絡人公用」,需要說明推動此決策的業務需求的文件。若沒有記錄的理由,未來變更會破壞在業務流程中所隱藏的風險假設。

自動化可免除重複的手動工作、減少人為的錯誤,並讓作業擴大,而不會使人數比例增加。針對 Salesforce 解決方案,自動化機會可跨越陳述性平台功能、程式設計自動化和作業程序。

Salesforce 的陳述性自動化工具 Flow Builder、公式欄位、驗證規則、批准流程—讓非開發人員無須程式碼即可實作複雜的業務邏輯。宣告自動化提供管理優點 (管理員無須部署即可修改)、透明度 (視覺設計文件本身),以及平台最佳化 (宣告作業的執行效率通常高於相等程式碼)。

• **Flow Builder:**自動化結合使用者互動、資料操作、業務邏輯和整合的複雜流程。流程會處理常見模式,包括使用從屬對應建立記錄、條件式批准路由、多步驟資料匯入、排程的清除工作,以及錯誤通知工作流程。自動啟動流程會在記錄變更、排程間隔或從程式碼明確叫用時執行。畫面流程會根據使用者輸入,使用分支邏輯引導使用者完成多步驟流程。

設計可重複使用與維護的流程。子流程會壓縮多個父系流程重複使用的常見模式 (例如錯誤處理或記錄鎖定邏輯)。具名的流程變數和明確的描述會建立可讓未來維護者瞭解的自助式文件邏輯。模組化流程設計可在整合前測試個別元件。

• **公式欄位:**從沒有程式碼或資料庫更新的其他欄位動態計算值。公式支援複雜計算、條件邏輯、日期算數和文字操作。公式欄位可在報告、清單檢視、驗證規則和流程中運作,提供跨不同內容的一致計算。公式執行效率高,因為它們不會耗用資料庫儲存空間,且在記錄存取期間會隨時進行計算。
• **驗證規則:**以節省時間強制執行資料品質。驗證規則會抓住資料輸入錯誤、強制執行業務規則,並防止無效狀態轉換。將驗證規則放置在標準和自訂物件上,以找出錯誤,無論資料來源為何—UI、API、Data Loader 或整合。經過精心設計的驗證規則錯誤訊息會引導使用者修正問題,而非使用密碼技術訊息讓使用者感到挫折。
• **批准流程:**將記錄路由至狀態進階前的必要批准。批准流程會實作簽署授權機構階層、規範審查、法律批准和多方同意工作流程。批准流程會自動提供稽核追蹤,記錄誰批准了哪些項目和何時,而不需要自訂開發。

雖然陳述性自動化處理許多案例,但複雜的需求或效能限制有時需要 Apex 中的程式設計自動化。有效的 Apex 自動化可將強大功能與彈性與可維護性和管治挑戰平衡。

• 觸發架構提供資料庫觸發邏輯的一致結構。設計良好的觸發架構會區分疑慮 (邏輯何時執行、執行的邏輯、相依性順序的方式)、啟用/停用個別處理常式而不變更程式碼,並透過內容追蹤防止遞迴問題。觸發架構可防止「單一大觸發」反模式,讓 Apex 自動化變得更容易維護,其中不相關的邏輯會累積成無法維護的單一元素。
• 批次 Apex 會以區塊的方式非同步處理大型資料,同時遵循管理員限制,同時執行同步執行時會逾時的作業。批次工作會處理資料清除、大量更新超過物件邊界、複雜計算需要每個記錄多次查詢,以及資料移轉作業。針對 idempotency 設計批次工作—執行相同工作兩次應產生相同的結果,而不會重複工作或損毀。
• 可排列 Apex 會透過明確的工作序列來鏈結非同步工作。若未來方法會變得難以忘記,則 Queueable Apex 會啟用結構化序列,其中一個工作完成會觸發下一個工作。可排列工作支援複雜協調流程,包括 API 呼叫,後面接著是資料處理、多階段資料轉換,以及具有指數反向的重試邏輯。
• 排程的 Apex 會以固定間隔執行工作。排程工作會處理定期清除、每晚資料同步、每小時整合投票和一天結束處理。在低流量期間排程工作,並實作監視以偵測錯過的執行。請考慮排程間隔是否真正滿足業務需求,或以事件為導向的觸發是否會加速回應。

設計程式設計自動化以取得營運可視性。記錄開始/結束時間、已處理的記錄計數、發生錯誤,以及效能度量。當批次工作無訊息失敗時,通常會被忽略,直到使用者在幾天後注意到資料問題為止。主動記錄和警示會將無訊息失敗轉換為可診斷的事件。

「平台事件」可啟用以事件為導向的結構,讓生產人員發佈事件而不瞭解消費者,而消費者訂閱事件而不依賴產生者。以事件為導向的結構可將元件分離、啟用非同步處理,並支援多國語言整合模式。

• **平台事件發佈:**通知感興趣的訂閱者有關重要業務事件。訂單下單、付款處理、履行完成、SLA 缺口和錯誤條件皆代表值得發佈的事件。事件裝載包含足夠的內容,讓訂閱者能夠適當回應,而無須額外查詢。從觸發、流程、Apex 或 API 呼叫發佈事件,提供事件來源的彈性。
• **平台事件訂閱:**透過 Apex 觸發、流程或外部整合平台回應已發佈事件。訂閱者以非同步方式處理事件,這表示發行者不會等待訂閱者完成。以事件為導向的處理會透過跨個別執行內容散佈工作,而非在大量同步交易中耗用限制來遵循管理員限制。
• **事件重新執行:**讓訂閱者可以處理歷程記錄事件。使用「平台事件重新執行識別碼」從特定點重新執行事件。外部訂閱者必須管理自己的「重新執行識別碼」狀態。由於傳送至少為一次,因此可能會重複處理,以訂閱者邏輯處理。根據訂閱者復原需求設定事件保留—大量平台事件 72 小時,舊版標準事件 24 小時足以快速復原,較長的保留支援災害復原案例。

設計事件以確保穩定性。事件結構描述會成為產生者和消費者之間的契約。結構描述變更需要跨多個小組與系統的協調。展開事件時新增欄位,而非修改現有欄位。當中斷變更變得無法避免時明確版本事件。

事件是服務的非預定中斷或降級,需要回應才能還原正常作業。有效的事件管理可快速偵測問題、將其路由至合格的回應者、有效解決問題,並汲取學習以避免重複。

• **偵測速度:**決定事件影響持續時間。您偵測到問題的速度愈快,在回應開始之前累積的損害愈少。偵測機制包括自動監視警示 (來自可觀察性系統)、使用者報告 (支援票證和直接升級),以及外部監視 (從網路外部檢查合成交易和執行時間服務)。

依使用者影響而非技術嚴重性排定事件的優先順序。例如,影響內部批次工作的 API 錯誤的緊急程度與阻止所有使用者存取的登入失敗不同。

事件嚴重性會引導回應時間和升級路徑:

建立清楚的事件回應程序,包括回應者、如何升級、要維護的通訊步調,以及如何跨小組協調。在高壓力事件期間,隨選工程師可遵循的執行手冊中記錄程序。未記錄的部落 Knowledge 會造成回應延遲,同時人們會找出要打電話給誰以及要採取哪些步驟。

• **通話輪換:**將作業負擔分配給小組成員,而非消耗一些回應每個事件的英雄。通話輪換平衡涵蓋要求 (永遠有人可用)、公平 (每個人都共用負擔) 和永續性 (人員需要強烈事件後的復原時間)。

使用明確的處理方式和已記錄的責任來建構通話輪換。主要通話處理初始回應,次要通話在主要需要協助時提供升級,或在主要無法使用時接管。通話排班大小應正確。例如,從一週開始,且不超過兩週—更短的排班會建立不斷的內容切換,而較長的排班會增加耗損風險。排程輪換,允許事先規劃個人義務。

• **升級路徑:**定義參與其他資源的時機和方式。清除升級條件可防止兩種失敗模式:過早升級會浪費資深工程師的時間處理資深工程師可以處理的問題,以及延遲升級會讓資深工程師在專家協助閒置時面臨超出其經驗的問題。升級條件通常分為三個種類—以時間為基礎的觸發,例如沒有進度的 30 分鐘;複雜性觸發,例如需要專業知識的問題,目前尚未呼叫;以及嚴重性觸發,例如嚴重性 1 事件,一律升級至領導階層。

為通話工程師提供必要的存取權、工具和資訊。沒有生產存取權的呼叫狀態會造成挫折,並在人員等候存取時延長事件持續時間。通話工具組包含生產存取認證、執行手冊存取、監視顯示面板連結、升級連絡人、廠商支援程序和通訊範本。

公平地補償通話服務。通話工作會中斷個人時間並造成壓力。薪水方法包括額外的薪資、暫時休假,或輪替信用減少其他責任。若沒有公平的薪水,則隨選輪換會造成不滿,且品質工程師會為尊重工作與生活平衡的組織放棄。

• **無罪後置詞:**從事件中獲取最大程度的學習,而不會產生阻止誠實討論的恐懼。無罪的文化承認人們在複雜的系統中犯錯,並專注於防止未來事件的系統改善,而不是對過去事件的個人進行懲罰。

針對所有「嚴重性 1」與「嚴重性 2」事件,以及任何顯示新模式或系統問題的事件,執行死後測試。死後時間點非常重要:執行過早檢閱會造成資訊不完整的風險,而執行過晚會造成記憶淡化的風險。在事件解決後的合理時段 (24-48 個小時) 內排程死亡後,讓資料收集時間維持最新狀態。

一致格式的記錄死亡後記錄:

• **時間表:**從初始偵測到解析之間的事件依照時間先後順序排列。包含時間戳記、採取的動作、觀察的成果,以及所做的決策。時程表重建會顯示回應的成效並識別延遲。
• **根本原因:**允許發生事件的基礎系統弱點。將近端原因 (立即觸發) 移至系統原因 (造成觸發後果的設計或流程缺口)。「工程師部署的程式碼錯誤」是直屬原因。「部署管道缺少自動測試以找出此錯誤類別」是系統原因。
• **影響:**使用者影響持續時間、受影響的使用者計數、收入影響、資料完整性疑慮和聲譽損害。量化影響會引導預防工作的優先順序:預防影響 $100,000 的事件需要比預防影響 $1,000 的事件更多投資。
• **預防:**防止循環的特定動作項目。有效的預防項目是具體的,且包含動作、指派對象和排程完成。例如,將整合煙霧測試新增至 CI 管道,擁有者:Jane,並完成方式為:下一個衝刺。系統會忽略如「改善測試」等模糊的預防項目,因為沒有人知道要採取什麼動作。
• **偵測改善方式:**如何更快偵測類似事件。透過使用者報告發現的事件表示有監視差距。改善項目可能包含新的警示、更好的儀器處理或關鍵路徑的綜合監視。

廣泛分享死亡後發現。組織學習需要直接小組以外的共用。Postmortems 在公司範圍中共用有關系統行為、常見失敗模式和有效回應程序的 Knowledge。公用報名 (於外部發佈) 可示範透明度,並協助客戶瞭解服務品質承諾。

卓越營運是一種持續的作法,需要持續投資於測量、學習和改善。將作業視為一次性設定的小組會隨著時間的變化而降低系統的複雜性,而作業 Knowledge 會消散。採用持續改善的小組會強化營運能力,並透過永續努力提供增加的價值。

DORA 度量 (來自 DevOps Research and Assessment (DORA) 計畫,根據 2025 年 AI 輔助軟體開發報告) 提供經研究驗證的軟體傳送和作業效能度量。具有優良傳送績效的小組在下列五個主要度量之間顯示可測量的更佳成果:

DORA 將這五個度量組織為兩個因素:輸送量與不穩定性。輸出量包含變更前置時間、部署頻率和失敗的部署復原時間,可測量將多少變更移至生產環境。不穩定性具有剩餘變更失敗率和重試率度量,可測量這些部署的執行狀況。

• **部署頻率:**測量您發佈至生產的頻率。最快速移動的小組依需求部署,通常每天多次部署。頻繁部署可啟用快速回饋意見、透過更小的變更減少部署風險,並與更快的功能傳遞相關聯。低部署頻率表示小組避免的部署難題,從而建立一個惡劣的循環,而不常進行部署會使每個部署變得更有風險。
• **變更的前置時間:**測量從認可程式碼到生產部署的時間。子日前置時間是績效優良傳送的強大訊號,且子小時前置時間表示傳送能力優異。短前置時間可讓使用者快速回應使用者需求、競爭威脅和安全性漏洞。長前置時間表示流程額外負擔、自動化不足或組織功能錯誤。
• **變更失敗率:**測量造成需要補救的生產事件之部署百分比。最可靠的小組會持續保持此率低,這是所有部署的一小部分。高變更失敗率表示測試不足、部署驗證不足,或在沒有適當品質檢查的情況下快速變更。
• **失敗的部署復原時間 (FDRT):**測量您從需要立即介入的失敗部署復原的速度。復原少於一小時是傳送成熟度的強大訊號。較短的復原時間表示已成熟的事件回應、有效的回復功能,以及經過良好的執行手冊。復原時間過長表示部署驗證不足、缺少自動回復,或生產事件的擁有權不明確。
• **部署重試率:**測量由於生產事件而導致非預定部署的發生頻率。低的重新處理率表示不會產生下游補救工作的穩定且經過測試的版本。高的重新處理率表示生產事件會定期推動緊急部署,表示在生產前測試、版本驗證或變更管理作法中有缺口。

持續測量 DORA 度量並隨著時間趨勢。改善趨勢比絕對值更重要。小組從每月到每週的部署改善,同時維持品質,顯示進度。在整個組織可看見的作業顯示面板中追蹤度量,以建立有關營運績效和改善目標進度的透明度。

• **Sprint 追溯:**從最近的工作 (包括營運事件、部署挑戰、流程摩擦和小組動態) 中提取學習。追溯應定期發生 (每個衝刺或每月),以建立持續反應的節奏,而不是等待危機。

使用結構化格式執行追蹤,以鼓勵參與和可運作的成果。常見格式包括:

• 開始/停止/繼續—我們應該開始做什麼、停止做什麼、繼續做什麼?
• Mad/Sad/Glad - 對最近體驗的情感反應
• 時程表 - 重建衝刺事件並識別模式)。

使用擁有者和完成日期,將追溯洞察轉換為具體的動作項目。追溯會產生長時間的討論,但沒有動作會浪費時間並產生疑惑。有效的追蹤會為每個工作階段產生 2-3 個可運作的改善方式。追蹤追溯的動作項目完成度,讓小組負責追蹤。請務必輪替參與者來防止單一人主控討論。

• **營運審查:**透過每季或每月業務檢閱來評估彙總營運狀況。作業審查會檢查趨勢資料、對照目標進行比較、識別改善機會,以及配置改善投資。這些檢閱也會參與領導階層,為競爭功能開發的作業改善工作保護資源。

在檢閱中包含作業度量:

• **可用性:**實際與目標,依使用者旅程與整體
• **效能:**延遲趨勢 (依百分位和重要流程)
• **事件:**依嚴重性計數、平均偵測時間、平均解決時間
• **部署狀況:**頻率、成功率、回復頻率
• **營運負載:**通話頁面、手動介入、工作時間

檢閱會建立卓越營運的責任,而非將作業視為隱藏的背景工作,僅在危機期間才會受到關注。定期營運審查表示組織對永續營運的承諾。

追溯回顧的是最近工作發生的狀況,而營運審查報告會將狀況彙總至領導階層。工程審查是小組將作業訊號轉換為傳送決策的循環步調。他們會在其中,將顯示面板、事件趨勢和系統產生的錯誤預算連接至小組承諾的版本計畫和待處理優先順序。執行此檢閱可讓執行工作的人員擁有運作狀況,使其成為規劃的內建部分,而非後續的考量。

• **發行規劃:**將作業整備視為功能範圍、順序變更以限制爆炸半徑,以及在錯誤預算耗盡時保留版本等一類的輸入。如此一來,部署規則與業務優先順序會刻意協調,而不會受到期限壓力。
• **待處理分級:**將作業工作 (例如事件動作項目、預防工作、技術債務、監視缺口) 放置在與功能工作相同的待處理項目中,以競爭產能。定期分級會指派擁有者和優先順序,從死亡後結束至認可工作結束迴圈。

• 營運整備檢閱 (ORR) 會在生產開始前評估新功能或系統是否符合營運需求。ORR 透過在修正比啟動後修復更便宜時,在開發期間抓住營運缺口來防止營運災害。

在生產啟動具有營運影響的新解決方案、主要功能或結構變更之前,執行 ORR。ORR 時間點很重要—過早且實作保持不完整、過晚且營運上的疑慮看起來像是部署封鎖者造成略過修正的壓力。

以下是執行 ORR 時必須記住的疑慮與問題:

• **監視和警示:**是否已分析足夠的度量?系統是否存在失敗情況的警示?是否已設定顯示面板顯示健康狀態?
• **文件:**執行手冊是否適用於一般作業?是否已記錄結構,讓回應者瞭解系統?升級程序是否清楚?
• **部署與回復:**部署是否可靠執行?是否存在回復程序?部署是否在暫存中驗證?
• **效能與延展性:**效能目標是否在實際的載入中驗證?是否有成長的空間?管理員限制是否有風險?
• **安全性和合規性:**安全性檢閱是否已完成?是否符合稽核需求?存取控制是否符合需求?
• **相依性:**是否已識別外部相依性?整合合作夥伴是否有 SLA?相依性失敗是否有回復行為?

ORR 完成時的門生產開始。當小組將營運疑慮視為部署需求而非精心策劃時,小組會將其視為嚴重。ORR 門會防止營運債務累積,進而使未來的卓越營運變得越來越困難。

學習的組織會系統捕捉作業體驗,並將其轉換為改善的作法。學習文化取決於:心理安全性,讓人們無須擔心就能報告問題;測量,讓資料能夠顯示模式;以及承諾,讓領導階層分配時間來改善。

• **心理安全:**讓您能誠實地討論問題、錯誤和幾乎錯誤,而不必擔心受到懲罰。缺乏心理安全性的小組會隱藏問題,直到這些問題變成災難,進而防止早期介入。透過討論自己的錯誤來建立心理安全、慶祝問題發現,以及建立領導階層模型化漏洞。
• **測量:**可顯示作業狀態。作業度量、事件趨勢、DORA 指標和使用者滿意度分數會顯示作業實際的執行與所需效能的比較。度量可根據影響來設定改善工作的目標優先順序,而非根據最嚴重的抱怨或最近的事件。
• **改善時間:**確認傑出營運需要投資。針對功能花費 100% 的容量的小組沒有時間進行營運改善,從而造成技術和營運負債,進而強制執行危機回應。刻意保留工程產能以進行營運改善、減少技術債務、工具和自動化投資。此規則可避免長期降級,同時啟用永續的功能速度。

建立回饋意見迴圈,將作業體驗連線至設計決策。當事件顯示結構劣勢時,請優先處理防止類似事件的結構改善。當監視顯示效能降級時,請排定最佳化工作的優先順序。當部署失敗顯示測試缺口時,請排定測試涵蓋範圍的優先順序。回饋意見迴圈會建立虛實循環,其中作業會持續改善,而非漸進式降級。

「傑出作業」需要設計可觀察性的解決方案、透過自動化管道部署、有效回應事件,以及持續從作業體驗中學習。檢閱此檢查清單以評估您的營運成熟度:

觀察性與監視

• 解決方案包含全方位記錄,用於用於散佈追蹤。
• 已啟用「事件監視」,且「事件記錄檔」會匯出至外部平台以保留超出原生限制
• 設定為已調整為組織基準值的 Proactive Monitoring
• 在每個版本之後建立並檢閱的「刻度中心」基準
• 設定「稽核追蹤」匯出以保留超過 180 天
• 已針對敏感和受監管的資料欄位啟用欄位稽核追蹤]
• 資料偵測掃描可識別和分類欄位中的敏感資料,發現結果可推動規範分類和補救措施
• 根據安全性基準每季檢閱健康檢查,且依風險優先順序補救的發現結果
• 使用里程碑標記和成功率監視所儀器化的重要使用者流程
• 整合監視會追蹤所有外部相依性的雙向健康狀況
• 針對可用性、延遲、成功率和輸送量定義的服務層級目標
• 警示結構包含嚴重性層級、可操作內容和清除升級

DevOps 作法

• 所有中繼資料版本皆受控制,可從來源啟用可複製組建
• 臨時組織或開發人員 Sandbox 支援隔離開發
• 組態變更遵循與程式碼變更相同的檢閱流程
• 組態漂移偵測每季執行一次,並包含記錄的補救措施
• Sandbox 策略包括開發人員、整合、暫存和訓練環境
• 自動化 Sandbox 重新整理與資料載入
• CI 銷售管道會使用自動測試驗證每個認可
• 受保護的主要分支在合併前需要 CI 成功
• 透過透過漸進式驗證的環境部署 CD 銷售管道
• 生產部署之前執行的部署驗證
• 部署監視會在部署期間和之後追蹤主要度量
• 部署執行手冊文件程序、驗證和回復
• 測試金字塔包含單元測試、整合測試和端對端測試
• 在 CI 管道中自動化測試執行
• 程式碼審查需要兩個含明確審查條件的批准
• 提取要求保持小型 (200-400 行) 以供完整檢閱

自動化與效率

• 在適用的情況下使用宣告自動化 (流程、公式、驗證、批准)
• 使用可重複使用子流程以模組方式設計的流程
• 觸發架構提供 Apex 自動化的一致結構
• 批次工作實作 idempotency 與全方位記錄
• 透過監視在低流量期間執行的排程工作
• 「平台事件」可啟用非同步處理的事件驅動結構
• 使用版本化策略為穩定性設計的事件結構描述
• 自動化作業可視性包括記錄、監視和警示

事件管理

• 自動監視提供主要事件偵測
• 使用明確回應時間需求定義的事件嚴重性層級
• 在執行手冊中記錄的事件回應程序
• 呼叫輪替可公平地分配整個小組的作業負擔
• 使用時間型與複雜性型觸發來清除升級路徑
• 通話工程師擁有必要的存取權、工具和資訊
• 公平補償的通話服務
• 針對所有「嚴重性 1」與「嚴重性 2」事件執行無罪的死後測試
• Postmortems 文件時間表、根本原因、影響、偵測改善和特定預防動作
• 針對組織學習廣泛共用的死後發現

持續改善

• 持續追蹤 DORA 度量 (部署頻率、前置時間、變更失敗率、還原時間、重試率)
• 經結構化格式和可運作成果的衝刺追溯定期發生
• 營運審查每季或每月評估彙總健康狀況
• 新功能的營運整備檢閱門生產啟動
• 心理安全性可實現對問題和錯誤的誠實討論
• 工程容量刻意保留供作業改善之用
• 回饋意見迴圈會將作業體驗連線至設計改善方式
• 將傑出作業視為每個人的責任,而不只是作業小組

分享您對良好架構的回饋意見。