一個企業級的應用，即使是諸葛亮級別的設計人員，最初的考慮都不可能盡善盡美，會存在設計不夠或者設計過頭的情況。加上業務的發展可能與當初的推想不一致，這樣就使得上線初期穩穩當當的一個系統，在若干輪的需求驅動下，就變成了補丁之上打補丁，活成自己討厭的樣子。當然，我們也可以把鍋往最初的設計和開發上面扔，但還是解決不了系統維護越來越困難的事實，“累了，毀滅吧”想推倒重構的想法其實是大家喜聞樂見的。
然而對于企業級的應用，系統的重構，不管是對軟件供應商，還是對企業本身，還都是個痛苦的過程。重構不僅要需要考慮眾多的技術、業務因素，也需要考驗甲乙雙方的管理水平，協調能力等等。如果涉及到軟件供應商的更換，那么這個事情就難上加難了。
大家所期待的，是重構后系統更加適應現在的業務，使新的需求、新的業務開發更加絲滑，大家所擔心的，其實是傷筋動骨后，系統如何能夠保證業務的穩定性和準確性，大家對于重構的態度其實是：像一個少女等待他的男朋友，既怕他不來，又怕他亂來。
對于喜歡的部分，主要靠設計和開發的大牛們來實現，而對于害怕的部分，就主要看我們交付的兄弟們了。
雖然如此，但是現在如果去百度一下，如何確保系統重構時的業務準確性，甚至你去問chatgpt（沒錯，我問過了），得到的答案絕大部分與設計和開發有關，卻很少有測試和實施的部分。
主要原因是實施方面與業務相關性太強了，要總結這方面的共性，無非就是數據遷移要準確、回歸測試要充分之類的，至于如何保證，那就要開始說業務特性，但說業務，有點無從下嘴的感覺。
當然，今日份的骨頭，我啃了。
電信運營商的計費系統可能是最不敢在重構時亂來的企業級應用了，“計費”這兩個字就說明需要極強的準確性。在計費系統的重構實施中，對于如何確保業務準確性，形成了自己固定的一個自己固定的套路，也就是對賬。計費系統的工程實施人員，很多從事的第一項工作就是對賬。當然，對于發量充足的新手，這時候自然要發出靈魂三問：
我是誰？你是計費系統實施人員。
我從哪兒來？剛從公司總部出差而來。
要到哪兒去？你要對賬。什么是對賬？
（頭發絲落在了地上，沒聽見一點聲響，憂傷的悲傷的音樂響起）。
本文的目的，首先是介紹一下計費對賬的這個套路，給新手一些指引，也順便讓計費專業的同學更好地理解計費系統的實施過程。當然，高度還是要有，也想對給企業級應用重構實施的準確性保證提供一點方法論，給其他專業的同學一點點那種“他山之石”的感覺。
對于被這么硬核強扯到“對賬”這個名詞一臉無辜的同學，還是要先給對賬做個定義，這個詞源頭應該來自于會計專業（可能與計費系統的前身與財會有很大關系有關），在計費專業，對賬這個詞的意思一般是，對重構前（老系統）和重構后（新系統）的系統運行的結果，進行差異比對的過程。只有這個比對的差異到了足夠小，一般是一致率到99.99%，才說明新系統的計費結果是準確的。你可能認為這種手段比較極端，但是本著我能崩潰，程序不能崩潰的原則，這種手段其實是很必要的，不然計費系統永遠沒底氣上線。
聰明如你，其實已經發現，對賬其實是一種回歸測試手段，因為如果對任何程序：“輸入 + 程序處理 = 輸出”的話，那么對賬就是對輸出的比對，用來確認新的程序是否存在不能兼容老的程序的問題。
也就是說，對賬其實就是使用相同的數據源輸入（有時候未必能做到，可以使用盡可能一致），經過不同的程序處理（老系統和新系統）后，通過比對輸出，來對新程序的正確性進行判斷，并且通過修改程序來糾正新程序的錯誤的一個過程。當然，對于一個大的系統重構，這個程序處理應該替換為系統處理，因為整個大的系統處理的流程、配置、資料結構都可能出現大的修改，差異的原因，也往往需要從程序、流程、資料、配置等幾個大的方面去尋找。
計費對賬在計費系統重構時，非常重要，甚至可以說，工程實施的很多工作，都是圍繞對賬來進行的?；旧?，計費系統的所有工程實施人員，從事的第一項工作就是對賬，其實這并不是因為對賬是個簡單的工作，恰恰相反，對賬是所有工程實施工作中最難的，它需要有扎實的業務功底，也需要非常熟悉新老系統。
那為什么基本上所有的工程實施人員第一課都是對賬呢？原因很簡單，從業務學習的角度來說，對賬是一個最好的切入方式，也是一個相對容易上手的方式。但是，也因為這個工作要做好，實際比其他任何的工程實施工作要復雜，要難，所以基本上所有的新手壓力都非常巨大。
首先要說個無用的廢話，對賬的準備最重要的是，對于計費系統的重構實施的進度，到了能夠對賬的程度。這其實也是實施中一個重要的里程碑點：
研發方面，至少已經到了大部分需求都已經開發完成并測試通過。
部署方面，程序已經在新的部署環境下部署完成并且穩定運行。
數據遷移方面，基本的靜態資料（批價配置）和用戶資料數據遷移已經可以完成。
當然，大家都懂這些事情不卷是不可能的，不能指望所有的料都準備好了再下鍋，所以如果沒有完成的部分，要留下遺留問題列表，免得對賬的兄弟在這些坑下面越挖越深。
除了項目進度已經到了可以對賬的程度，對賬本身還需要如下準備：
這個可能很多人存在疑問，老系統的程序輸出結果（清單、賬單等）在老系統就有，而新系統既然已經能夠部署完成，準生產環境已經具備，那么環境還存在問題嗎？主要需要說明的是，我們盡量不要使用老系統程序歷史的輸出結果（生產環境的輸出結果）來比對。因為我們要保證系統的輸入是相同的，這個輸入，不僅僅包含計費系統要處理的數據源（話單），也包括計費系統的用戶資料，套餐的配置資料，其實還包括一些更加動態的資料（如累積量）這些都要保持穩定，而生產系統的這些資料，都是在不停的變化中，如果使用生產系統的結果，那么就需要有可靠的手段來能夠排除這些變化的部分，這就加大的對賬的難度。所以，新老系統的環境我們還是需要準備的。
前面已經說到，計費的數據源不僅僅包含了我們要處理的數據（原始話單），也包括了處理數據過程中要用到的用戶資料、配置等。對于老系統，直接使用生產的備份數據即可，對于新系統，需要將這份數據遷移到新的對賬環境中。
對賬的人員往往是一個團隊，人數看項目的大小，大的項目可能多達十多人。內部還要分組，一般來說，我們按照模塊分組，比如租費、語音、流量等等。除了對賬人員以外，配合對賬的角色也不能缺：
系統運行：熟悉新系統、老系統的運行人員都需要有，負責新老系統的跑賬。
業務專家：熟悉新系統、老系統的業務處理流程和邏輯的專家，參與差異結果分析和確認。
資料割接人員：參與資料割接的人員擔任，負責解釋資料遷移的邏輯，參與差異結果分析和確認。
對賬腳本的作用是從新老系統的對賬環境抽取輸出結果，然后對輸出結果進行比對，生成差異。這個當然要提前準備好（現在我們有專門的工具來做）。對于腳本如何編寫，這涉及到對賬的方法，在下文討論。
之所以認為對賬這個事情，對于其他的系統有借鑒的意義，也是因為這個過程，有很多共通的地方，比如差異的生成，其實很多系統都有類似的方法來比對兩邊數據的一致性，大家的方法也都差不多。
要生成兩個系統的差異，首先要確定的是，對于處理的結果，我們如何確定是來自于同一個輸入的數據源，這就是數據比對唯一字段，一般而言是字段的組合。在計費系統中，比如語音業務（電話撥打），一般就是用計費號碼、開始時間、結束時間標記是否同一條話單（同一個數據源），在差異生成前，應該先確定這三個字段（話單屬性）是否可以做為唯一字段。
在選擇唯一字段的時候，需要盡可能的選用不是程序產生的屬性，而要選用話單數據源中就有的屬性，比如對于某些交換機產生的話單，結束時間并不會填，由開始時間+時長計算出來，這時候，就最好使用開始時間和時長做為唯一字段。當然，如果確定一個屬性新老系統都絕對不會存在算法差異，作為唯一字段也是可行的，現在計費對于語音業務，計費號碼一般也是通過話單類型（主被叫、呼轉等）和主被叫號碼判斷而來，不會存在差異，也可以作為唯一字段使用。
比對字段確定哪些輸出的結果需要和老系統一致。比如對于計費，金額是最敏感的字段，肯定需要參與比對，同樣，一般參與比對的還有賬務科目（涉及到賬單展示和財務列收），這就能夠確定金額和賬務科目是比對字段。
參考字段的意思就是對賬分析原因時，可能會用到的字段，比如新老系統的批價的費率標記，計費時長等等，這些字段只用來做參考而放入對賬結果中。
確定這三類字段后，對賬腳本或者程序使用唯一字段，生成如下四種記錄：
很多剛開始接觸對賬的新手，會不明白為何有新有老無或者老有新無的差異。這種差異產生的原因，一方面是因為我們的程序，不僅會輸出正常有處理結果的話單，也會輸出一些因各種原因無法處理的錯單，而實際上，計費的整個流程中，有多個程序在處理，如預處理、批價、合賬、入庫等流程，在每一步，都可能產生錯單。如果某條原始記錄，在某個流程中處理成了錯單，那么在結果中就無法找到，這就造成了新有老無或者老有新無的情況。當然還有一種可能，就是因為新系統的業務處理規則與老系統不同，故意拋棄了一些話單不進行處理，比如一些原始話單的時長為0的話單，就可能存在老系統不處理，新系統處理的情況，這種情況下，也會造成老有新無和新有老無的情況。
輸出差異結果后，就開始對差異的結果進行分析。分析結果，了解新老系統的處理流程和處理邏輯是非常必要的。
前面提到的，輸入+程序處理=輸出。這對于一個程序，實際是明確的，但是，其實這兒的程序處理，并不是指單個程序， 這中間會有很多個程序，實際上，是多個程序。程序的輸出，也不可能只包括一種，肯定有多個的輸出。舉實際的例子，比如語音話單：
輸入 = 聯采話單。
程序A = 預處理 輸入=聯采話單 正常輸出= 預處理正常話單 過濾輸出 = 預處理過濾話單 錯單輸出= 預處理錯誤話單
程序B = 撿重 輸入=預處理正常話單 正常輸出 撿重正常話單 錯單輸出= 撿重錯誤話單
程序C = 批價 輸入= 撿重正常話單 正常輸出 = 批價正常話單 錯單輸出 = 批價錯誤話單
程序D = 合賬入庫 輸入= 批價正常話單 正常輸出 = 合賬正常話單 錯單輸出 = 合賬錯誤話單。
甚至在老系統或者新系統，可能將程序A分拆成A1，A2，這些都是很正常的情況。而實際上我們比對的結果，一般來說，是合賬后的正常話單，所以，產生差異，在期間任何一個環節都可能出現問題。
這些話單主要是因為在中間這么多程序中，都會因為各種無法處理（無法找到費率、無法找到用戶資料等等）而丟掉一些話單（錯單），或因為處理規則不同，過濾一些話單（過濾單）。造成比對中存在老有新無和新有老無的情況。所以分析的要點是：
對于結果不一致的話單，則更加復雜。對于計費，結果的不一致往往因為找到了不同的費率引起，前面提到的參考字段有有了大的用處。
對于計費，一般來說，不一致的差異一般都是這三種情況造成：
我們的比對的第一步，是從資料開始，首先，就是比較資料割接的對不對，原來老系統，用戶有ABC三個銷售品，而在新系統只有AB兩個，老系統用C銷售品進行了批價，這時候你就要去質疑資料割接的人員，為何C銷售品在系統中沒有體現，是否存在問題。
面對上面同樣的問題，你先去找了銷售品割接人員，銷售品割接人員告訴你，已經跟配置約定好，原來的BC銷售品，目前都對應到B銷售品，那么，你就要去檢查，是否B銷售品涵蓋了原來BC銷售品所有的批價邏輯？如果檢查到有資費缺失，那就要去聯系配置人員，為何這條資費沒有被配置。
如果檢查到配置是有的，條件也符合，那最終的懷疑對象是程序邏輯，程序為何沒有按照配置進行批價？這時候去找研發人員，跟配置人員與資料割接人員一起討論。
如果系統重構的新老系統廠家不一樣，那么對于新系統廠家而言，老系統的程序方面的黑盒子很多，甚至于對部分對賬的新手，新系統都可以叫做黑盒子，正因為這樣所以在對賬之前，需要請教新老系統的業務專家，至少熟悉兩邊的處理流程，清楚流程中每一個程序的輸入輸出，對大概的處理邏輯也需要做一個大致的了解。另外，也需要請教用戶資料、靜態資料（資費配置）的割接人員，新老系統的模型差異以及割接邏輯。當然這些問題也基本上都有文檔輸出，比如前期的流程調研文檔，用于數據割接的模型差異文檔，用戶某些單獨需求的專題設計文檔等等，這些文檔都需要一一看過先有個整體的印象。
在對賬期間，不管是新老系統的業務專家還是程序研發人員還是數據割接人員，他們都會很煩．因為對賬的團隊人會非常之多，但是，作為對賬人員的你肯定需要不停的是騷擾他們，你的目的是，不管是新系統還是老系統，不管是程序還是資料還是配置，這中間的黑盒子越來越少?！?/span>
對于新老系統的對賬環境，有時候硬件環境并不能與生產等同，所以運行大量的數據還是需要很多的時間，所以，對賬中一般會采用這樣的原則：從小到多，從代表業務到全業務這種方式．所謂從小到多，是指先對小的業務量，比如一天，從代表業務到全業務，是指先完成某類業務（如語音），確認資料割接和配置割接沒有大的問題后,再進行其他業務的對賬。這樣做的好處一個是不需要把大量的時間放在運行上，另外也不會被海量的數據搞得對賬無從下手。當然，一般在對賬之初，就會列出一個對賬的計劃，會包含這個部分的內容。這是一個典型的例子：
對賬開始的時候，初始的差異肯定是非常大的，首先還是不要被巨大的差異嚇倒，因為大的差異，完全可能就是那么幾個原因引起。
找差異時，首先要找共性最多的去分析（比如按照參考字段的差異去分析）。
找到差異后，要把同類錯誤的話單更新原因，再找下一類沒有更新原因的差異，也要盡量找共性最多的。
切記前期對賬時，如果某條話單找不到原因，不要鉆牛角尖，因為這種話單，可能被多個原因覆蓋，非常難于分析。當你一個個原因找到后，可能問題就解決了。