本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
技術基礎工作流
此工作流涉及的決策在發生變更時需要大量返工,因此工作流強調審慎的設計、廣泛的諮詢以及對 DevOps 流程和測試的前期投資。
技術基礎工作流包含五個階段:探索和路線圖、設計、建置、測試、部署和上線支援。
探索和路線圖
在此階段中,您會收集以下資訊並安排研討會:
-
原樣映射 – 檢查系統和功能,收集資料並與 SME 會面,以了解聯絡中心的當前狀態。
-
待設計項和差距評定 – 確定所有聯絡中心客服人員和客戶的理想體驗,以確定專案範圍。
-
差距彌補計畫 – 概述建立和部署聯絡中心未來狀態的路線圖。
研討會與會者:
-
專案經理
-
業務、解決方案、技術和安全架構師
-
基礎設施平台擁有者
設計
在此階段中,您會產生設計文件。您可能有自己的慣例或程序來建立設計成品。建議在設計文件中至少包含三個部分:Amazon Connect 組態、聯網和安全性。每個部分可能會有不同的專門利益相關者群組,以確保有效的審查和簽署,因此為這三個領域建立單獨的文件可能會更加實用。利益相關者應包括架構師、安全性與合規團隊以及平台擁有者。
組建
在此階段中,可以透過使用 DevOps 工具來標準化和管理穩定版本,從而遵循基礎設施即程式碼 (IaC) 原則。避免採用手動構建流程,即使它可以協助您更快地開始,因為這可能會增加穩定性和錯誤數量的風險,因為構建變得更加複雜且會提升到測試和生產環境。如果您沒有自己的 DevOps 工具,建議您使用 AWS CodePipeline 和 等工具 AWS CodeBuild,這些 AWS 工具可以快速開啟。將設定這些工具的工作量納入專案範圍;這些工具在長期來看會有益,並可讓您遵循 DevOps 原則。建議您至少建立三個獨立 AWS 帳戶進行開發、測試和生產。DevOps 工具和自動化可協助您在這些環境中移動程式碼。
測試
測試階段由三個順序子階段組成:
-
單元測試 – 測試個別基礎設施元件,以確保其正確無誤且符合設計規格。執行者:開發人員
-
整合測試 – 測試形成整合界限的項目,例如 Microsoft Active Directory (AD) 身分識別管理服務。執行者:開發人員
-
產品測試 – 對整個基礎設施的功能旅程進行端對端測試;例如,測試每個客服人員事件是否記錄在安全監控工具中、接聽呼叫,以及通話記錄位於正確的 Amazon Simple Storage Service (Amazon S3) 儲存貯體中。執行者:功能測試團隊
部署
當使用者旅程排定上線時,基礎設施必須準備好處理即時流量。部署階段的重點是確保 AWS 服務配額符合預期的通話量,以及並行客服人員的數量、號碼移植或免付費電話號碼服務 (TFNS) 重新指向已完成,而且後端系統的運作狀態會隨著即時流量增加而受到監控。安全性和合規性團隊也應從他們的角度確認平台已準備好傳輸即時流量。
上線後支援 (PGLS)
在新聯絡中心上線後的頭幾週內,專案團隊仍然與照常營業 (BAU) 團隊和最終使用者保持合作關係。專案團隊可協助使用者開始使用新系統、與 BAU 支援團隊一起進行問題疑難排解,並根據意見回饋改善支援文件。