10+ 個項目的打磨，「數據遷移」逐漸被打造為標準化的服務。
給客戶帶來價值之餘，客戶也在幫助我們成長。
把事情做到極致，讓自己超越自己！
——策小編
近期發布上線的神策「數據遷移服務」可以助力客戶平滑、高效地完成多環境的數據遷移，全面保障客戶系統穩定運行。而在迎戰雲遷移難題過程中，深度參與其中的大力清楚記得項目的每個關鍵點和攻破的過程，經此一役，大力對「把事情做到極致」有了更深的體悟，以下是大力的自述。
我是大力，剛來神策時從事的是實施交付經理，主要負責項目交付和客戶生命周期經營，後來我開始協助進行遷移項目支持，從初始上手到推進遷移服務標準化，中間遇到不少難題與挑戰。
「像點了外賣，卻不知送到哪兒」
遷移項目剛開始並不順利，第一個項目做下來，整體協作不太順暢，項目期間在群里幫客戶解決問題時，有的自己解決不了，還需要請運維同學接入。第二個項目完成後，內部溝通感覺順暢了一些，但整體效率仍然不高。再加上，從客戶視角看，他們對相關項目缺乏整體的掌控感，就像是點了外賣，卻不知道已經送到哪兒了。
有了前兩個項目的洞察和思考，從第三個項目開始，本著優化客戶體驗，提升協作效率的目標，我把「梳理遷移方案文檔」作為高優先級的事情引入到項目中，希望通過遷移方案文檔和客戶做好溝通，同時和運維同學做到信息對齊。
10+ 項目打磨，打造為標準化服務
想法很美好，落地起來卻沒有那麼容易。剛開始，遷移方案有很多考慮不周全的地方，經歷了近六個項目的磨合，經過各種調整和修改，「遷移方案模版」才基本定型。
這時，Hannon 建議最好梳理出「標準遷移流程」方便協作，從效率和風險的角度看，確實很有必要，於是我們一起著手梳理遷移流程，其中流程的核心還是遷移方案。我在過往的經歷中曾經接觸過遷移工作，內心清楚遷移是一個相對高風險的動作，稍有不慎，就可能造成數據丟失。提前具備了這層風險意識後，在撰寫遷移後的驗證文檔時，我格外注意和小心，先是參考過往已有的文檔，同時諮詢了很多資深同學，提煉總結出更全面的驗證文檔。
為了更完整和準確地驗證前後的環境配置和數據，我們總結出具體方法，並主動為客戶提供驗證服務，前期還需要分析師同事幫忙提供支持，為了提升效率，我們開發了腳本，可以自動化運行。
在為客戶提供服務的過程中，我們發現雖然大家都在使用神策分析，但其實每家的使用情況各有不同，比如有的用 Kafka 訂閱、有的則用神策導入工具。由於之前了解的信息不夠全面，導致對遷移後的運維資源評估不準確，針對這種情況我開始製作「信息採集表」，對客戶使用神策產品的特性進行統計，和遷移方案一樣，「信息採集表」也經歷了多次疊代才趨於完善。有了「信息採集表」，運維同學的工作評估更方便、更準確，同時也確保遷移方案更全面。
在和客戶的真實接觸中，我真實感受到他們對神策產品的信賴，為了回饋這份信賴，遷移數據的完整性必須重點保障，遷移風險管理成為項目管理中的重要環節。一方面從遷移過程到結果，最基礎的數據總量驗證工作由運維同學保障；另一方面，切流量等關鍵環節由客戶配合，我們觀察並反饋。
在經歷了十餘個項目後，遷移流程、遷移方案、信息採集表、驗證文檔等關鍵文檔都已具雛形。接下來我與項目組其他同學逐漸將數據遷移服務梳理為標準流程，從遷移信息收集、方案和資源評估、遷移準備、實施遷移、遷移驗證及資源回收等，保障客戶數據安全與遷移可控。數據遷移逐步被打造成一項標準化的服務提供給客戶。
「有時候客戶在幫助我們成長」
記得曾經遇到一個客戶，原本已溝通好進行遷移準備，結果客戶反饋需要再次溝通，原來客戶想進一步了解不同集群及架構的具體差異。基於客戶的真實需求，我們通過詳細資料向客戶說明為什麼推薦相應的集群配置，客戶充分了解後開始準備資源遷移。後來我將整個情況反饋給運維同學，運維同學及時在官網更新了 Mini 集群和標準集群的說明，這樣客戶看起來會更清晰明了。
按照約定，早上 10 點開始實施遷移，但第一次遷移客戶流量切換失敗，為了減少風險，我們建議客戶找到具體原因後再做遷移。當天晚上 7 點左右客戶反饋已經找到原因，希望當晚遷移。於是我緊急聯繫項目運維同學協助配合，一起配合客戶進行遷移，當晚流量切換順利，運維同學工作整整一宿，終於在周一客戶使用前完成了遷移和驗證。周一下午客戶對我們表達了感謝，那一刻感覺價值感滿滿。
相信看過《壽司之神》紀錄片的同學都知道，主人公小野二郎生動詮釋了「把事情做到極致」的精神，讓壽司超越壽司。在神策，我們的企業文化中強調「把事情做到極致」，從遷移這件事來看，不管是遷移的流程還是方案，未來仍有疊代和優化的空間，加上我們的產品還會不斷升級，客戶需求也會逐步變化，不能用一成不變的流程或方案滿足客戶動態變化的需求，這需要我們永遠在路上，讓自己不斷超越自己！