一半以上的新項目，都始于交接。交接期有長有短，交接形式多種多樣。不管怎樣，從客戶關(guān)系、團隊工作方式等各方面，交接期都奠定了項目進入穩(wěn)定交付或維護期的基調(diào)。

2020年10月，Thoughtworks的C團隊從客戶團隊交接了一個有近20年歷史的支付網(wǎng)關(guān)系統(tǒng)。這個支付網(wǎng)關(guān)主要向英語系地區(qū)的企業(yè)提供信用卡支付，儲蓄卡支付等支付相關(guān)的功能，每個月的交易額過億。

2021年1月起，C團隊正式接手該項目的日常運維工作。不僅需要保證系統(tǒng)穩(wěn)定運行，提供7×24小時On Call支持，還要響應(yīng)日常業(yè)務(wù)的需求，同時保證整個支付網(wǎng)關(guān)符合支付卡行業(yè)數(shù)據(jù)安全標準(Payment Card Industry Data Security Standard，縮寫為 PCI-DSS)。

在交接的過程中，團隊面臨很多的挑戰(zhàn)，嘗試了很多辦法，同時沉淀了一些經(jīng)驗。我們將通過這篇文章將經(jīng)驗和實踐分享出來，希望幫助到更多人。

挑戰(zhàn)

作為一個歷史悠久的“大齡”支付網(wǎng)關(guān)，在交接過程中我們遇到了一系列的挑戰(zhàn)，大致可以分為下面兩類：

1. 業(yè)務(wù)復(fù)雜度高

業(yè)務(wù)上，這個支付網(wǎng)關(guān)光是在卡支付的場景下就同時支持8種技術(shù)，還有信用卡相關(guān)的安全功能，數(shù)不清的報表和各種增值服務(wù)。

技術(shù)上，總共有100多個服務(wù)和300多個代碼庫，部署在超過200個EC2上;服務(wù)之間耦合嚴重;許多服務(wù)沒有部署流水線、沒有測試環(huán)境甚至沒有源代碼;經(jīng)常需要手工操作生產(chǎn)環(huán)境數(shù)據(jù)庫來解決問題;操作系統(tǒng)和軟件包版本非常陳舊等。

項目管理上，沒有總結(jié)和沉淀出完整而清晰的業(yè)務(wù)和技術(shù)文檔。

2. 交接內(nèi)容多、時間短、范圍不明確

交接開始前，團隊接受到的信息只有100多個服務(wù)的名字，內(nèi)容非常有限;交接的時間周期比較緊張(初步計劃只有30個工作日)，沒有足夠的時間去了解到系統(tǒng)的所有功能。

實踐

1. 分階段制定目標、建立重點

我們一般如何衡量一個遺留項目維護的質(zhì)量呢?

• 短期：至少做到跟前團隊一樣。也就是說，在客戶團隊成員離開時，團隊能具備足夠的知識和技能來處理線上事故和日常業(yè)務(wù)工作。
• 長期：體現(xiàn)Thoughtworks不一樣的地方。對項目的業(yè)務(wù)、技術(shù)和發(fā)展歷史有足夠了解，足以給出一個改進計劃，在未來一個比較長的時間里落地、給客戶帶來更大價值。

鑒于項目的復(fù)雜度，在有限的交接期內(nèi)達到這個目標基本是不可能的。但是如果將時間軸拉長，分階段來實施，就比較容易做出一個切實可行的計劃;同時，也能最大化交接期的價值，讓團隊從第一天起就朝著一個方向努力。

基于此，團隊從實際情況出發(fā)，將項目分為三階段：

通過對項目不同階段目標的一致認識，減少了一些團隊在交接期的焦慮與慌亂，從而想出更多創(chuàng)造性的點子，并勇敢的嘗試、反饋、迭代，達到各個階段的目標。

2. 利用C4模型梳理系統(tǒng)架構(gòu)

通常處理的問題都是業(yè)務(wù)問題，如果不能把一個個服務(wù)放在業(yè)務(wù)流程中去理解就沒有意義。因此，我們在交接完一個獨立服務(wù)或者若干個有關(guān)聯(lián)的服務(wù)后，都會試圖用C4模型畫出他們的C1(System Context Diagram)和 C2(Container Diagram)兩個高級別的圖，以可視化的方式展示出系統(tǒng)輸入、輸出和各服務(wù)的依賴關(guān)系。

實踐證明，畫圖的過程可以幫助大家更好地吸收碎片化知識，有利于整個團隊將知識匯總和沉淀。同時，相比于反復(fù)的解釋說明，圖是一種更有效的語言。

有些比較獨立的模塊相對比較容易畫，但是涉及到不同版本API的支付流程，就需要不斷地獲取更多的信息來完善，反復(fù)跟客戶確認。有些環(huán)節(jié)甚至在交接結(jié)束后依舊沒能打通或者沒時間梳理，只能在交接后，作為深入理解期的目標繼續(xù)完善。

支付系統(tǒng)C1簡化圖(簡化版)

3. 通過結(jié)對在團隊內(nèi)部分享上下文

在第一階段交接的過程中，我們和客戶團隊是“1+1”的模式進行知識交接，業(yè)務(wù)知識是像孤島一樣分散在各個成員那里。另外，我們團隊又因為每個人加入項目的時間和技能背景的不同，對一些背景信息、業(yè)務(wù)上下文、技術(shù)實現(xiàn)的掌握有一些差距。

因此，在進入項目交接的第二階段開始，對于大部分的工作內(nèi)容，我們都通過結(jié)對的方式來進行。根據(jù)不同的業(yè)務(wù)和優(yōu)先級，我們劃分了幾個重要的主題，比如：日常需求相關(guān)的任務(wù)，PCI 相關(guān)的任務(wù)和生產(chǎn)環(huán)境的變更等。我們會通過專長和對服務(wù)的熟悉程度分工結(jié)對，讓這兩個人可以成為團隊內(nèi)相應(yīng)領(lǐng)域的專家。

這樣的好處有主要有：保證對應(yīng)的知識能在團隊中傳播開來，消除知識孤島;避免某個成員因為請假導(dǎo)致重要的任務(wù)不能進行;重要的線上操作可以多一個人幫忙檢查。

在安排 Primary On Call 和 Secondary On Call 的時候，采取“Dev + DevOps”的組合，保證有足夠的技能應(yīng)對線上事故。在線上事故發(fā)生的時候，兩個人一起結(jié)對配合處理。

雖然結(jié)對在前期會影響效率，但能確保團隊中至少兩個人熟悉特定的業(yè)務(wù)，最終可以讓整個團隊擁有響應(yīng)事故的能力。從現(xiàn)在的結(jié)果來看，正是這種結(jié)對的形式，保證了整個團隊的“高可用”。

4. 通過線上事故演練提升團隊On Call的信心

7 × 24 小時 On Call 對團隊來說，無疑會是一個非常大的挑戰(zhàn)。在正式接手系統(tǒng)之前，團隊感受到了比較大的壓力。這些壓力一方面是因為大部分項目成員缺少 On Call 的實戰(zhàn)經(jīng)驗，另外一方面因為在交接的第一階段里，我們?nèi)鄙賹I(yè)務(wù)實現(xiàn)細節(jié)和系統(tǒng)的深入了解。

On Call工程師不僅要參照標準處理流程，還需要在短時間內(nèi)評估線上問題造成的影響并精準地解決，那么用以前發(fā)生過的事故來演練就成了我們在深入理解期的最好的學(xué)習(xí)方式。

在正式承擔(dān)On Call的職責(zé)前，我們每個迭代都會有一個模擬線上事故處理的活動，主要流程為：

• 組織者會去從過去的線上故障里挑選一個有代表性的事故來模擬，比如是某一個與其他網(wǎng)關(guān)集成服務(wù)的事故;
• 團隊約定2個小時來模擬線上事故，組織者還原當(dāng)時場景，其他成員在不知情的情況下按照自己的理解進行適當(dāng)?shù)淖穯?
• 分成兩個小組，根據(jù)現(xiàn)有的情況定位問題，并給出解決方案;
• 組織者進行復(fù)盤，梳理相關(guān)知識點。

通過以上方式，我們得以快速適應(yīng)On Call的節(jié)奏。到現(xiàn)在為止，我們團隊的每個成員都有作為Primary On Call的經(jīng)驗了。

結(jié)語

在交接的三個月里，我們持續(xù)地改進交接方式，最終將項目成功地從客戶團隊手中接過。無論是交付主管，還是和我們合作的客戶團隊都對我們的工作提出了稱贊。在摸索交接的過程中，我們嘗試了不同的方式讓我們的交接平滑順利，并將對交接有幫助的實踐分享出來，希望對大家有所幫助。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文