”學而不思則罔,思而不學則殆“，本文記錄了作者在錦禮側工作1年間遇到的思考與成長、挑戰與困難，也是對過去工作的總結與反思，分享出來，希望對大家有所幫助。
本文約10000字
如果覺得頁面很長
那是因爲截圖和留言很多，哈哈
00引言
光陰似箭，來到錦禮產品線已滿一年了，這期間深刻的瞭解到B端不同解決方案之間的巨大差別，當然也遇到過很多挑戰與困難，有業務團隊認可的成就感，有眼高手低造成系統BUG的挫敗感，有擔任救火隊長處理線上問題的緊迫感... 回顧這一年，感慨很多。本篇文章沒有高屋建瓴地對整個錦禮商城的交易體系進行分析，只從一位一線開發的角度，寫了寫自己在這一年的工作開發中的思考和感受，以及技術上的總結反思。
我將其分爲三大部分，一、關於成長 二、關於技術 三、關於溝通，歡迎指教討論。
【京東錦禮】以京東供應鏈爲基礎整合京東集團優質服務資源，面向企業客戶提供的員工福利模式的服務及採購平臺，主要以服務企業員工福利場景（企業客戶向其員工發放福利額度，員工自主兌換採購）、市場營銷場景（品牌客戶向其會員營銷激勵，會員積分兌換採購）等多元化業務場景。歡迎集團各業務線夥伴前來合作。同時京東集團員工使用的福粒也是出自錦禮。
01關於成長
說到成長，我們每個人都在不斷變化，而成長就是其變化的積極面，它不單單是技能、知識等方面的提升，更多的是價值觀、人生觀的一些演變。這些改變會“潤物細無聲”般的影響我們的行爲和決策，從而改變我們的生活和工作，以下我將以四個標題總結我對去年成長的一些思考總結，供大家參考。
自我革新的開始
我相信和很多同學有這一樣的困惑，在同一條產品線較長時間後的得心應手，但又覺得內心空空。畢竟在我個人看來，技術的提升，一定程度上源於其場景（不同的產品，不同的系統）的限制，如果沒有場景上的改變和突破，會進入逆水行舟的狀態。就像羅翔老師說的：其實無論多麼高大上的工作，時間一長，都會滋生無聊的感覺，都會覺得工作不過是一種重複的機械勞動。
因此在23年初，我主動向我的直屬leader溝通是否可以進行工作職責的一些調整。十分慶幸和感謝，我的直屬 leader不僅僅與我談心這個想法，更是站在他的經驗之上，給我提供了行之有效的職業規劃建議。最後在去年3月底確認從VOP產品線調整到目前的錦禮產品線，當時我的核心考慮是希望自身能從深度到廣度的瞭解我們爲企業客戶提供的其他系列綜合解決方案，瞭解更多的系統，進一步完身自己的技術體系，跳出舒適圈給自己一些新的挑戰。
避免”我思故我在“
在GPT3.5和4.0發佈期間，我和其他業界的同學在一個技術羣中溝通，其中有一個同學的回覆讓我印象深刻。“獲取知識的成本越來越低，也就體現出思考的重要性越來越高”。在我看來，還要加上一句，行動的重要性更高。
因爲我相信大家或多或少都思考過很多東西，特別在技術領域，我們能接觸到更多的先進的觀點和技術，但是是否可以付諸行動，賦能業務？是否可以將思考轉化爲行動，這就需要我們有強大的自控力，能夠堅持不懈。同時我們也需要有效管理我們的時間和精力，避免在無關緊要的事情上浪費時間。
或許有同學會挑戰，那意思就是我們不要思考了？如果方向錯了，也不撞南牆不回頭嗎？當然不是，避免“我思故我在”，這裏的思更多指的是分散精力&質量低下的思考。我們需要的是時刻保持清醒的頭腦，專注於重要的、有價值的事務，而非大量的次要或者無關緊要的事務，同時對我們的行動也要進行批判性的思考，以確保我們的行動是有目的、有計劃的，而不是盲目的。
真正的大師永遠懷着一顆學徒的心
之前我閱讀過這樣一段話，對於技術同學來說，要時刻思考：抽離掉技術底座和業務後，你的價值是否歸零。
細細品嚐，何嘗不是，我們搭建的服務都是依託當前已經成型的平臺進行的，逃脫了平臺加成，剩下的纔是我們自己，所以不要生出膨脹的心理。畢竟每個人的知識和經驗都是有限的，我們都會有自己不擅長或者不瞭解的領域，不固步自封，敢於正視自己的侷限性，承認自己不可能知道所有事情，這也是成長需要具備的心態之一。這裏也引用一下蘇格拉里的一句話，承認自己的無知，乃是開啓智慧的大門。
真正的大師永遠懷着一顆學徒的心，這句話在我看來，不單單是謙虛，更多的還有要求我們保持開放、持續學習並接受新的觀點和知識。這裏的學習，不單單是關注技術本身的進步，更多的是要密切關注客戶的需求和市場的變化，因爲淘汰技術的永遠不是技術本身，而是市場是否還需要這份技術。
做團隊的建設者，而非旁觀者
我們從去年Q4到現在一直面臨着老平臺遷移新平臺的過程，衆所周知，大家對於新事物的接觸肯定是牴觸的，畢竟需要付出額外的學習和熟悉的成本，在切換週期中的陣痛感，是難以避免的。我之前和一個區域的業務同學進行溝通，瞭解我們新產品使用的體驗和一些痛點問題，說實話，他滔滔不絕，當然不少問題源於我剛纔提到的遷移陣痛。但是同時我又問了他一個問題，“爲什麼不把這些你覺得痛點的問題提到產品側轉化爲優化需求呢？我們每個版本迭代也在針對用戶體驗的專項進行優化的“。 他回答到：“太麻煩了，還要寫BRD，還有成本等等”。我不予置評。
當然我個人也是有同類的問題，比如技術評審階段，大多時候太專注個人，雖然不至於“各掃門前雪”的狀態，但是我針對團隊其他人的技術設計確實沒有做到百分百的關注。以至於上線後，某位同事的方案出了問題，緊急進行救火處理。“救火英雄”固然很牛，但是帶來的都是嚴重的教訓，針對系統建設，我個人認爲，如何從“救火英雄”到“防火衛士”也是需要我們爲之努力的。
以及各種各樣我們每天遇到的不同問題，彷彿世界上永遠有不完美的事情，永遠有麻煩，但是唯一解決之道就是面對它，解決它。做實實在在的事情，改變我們不滿的現狀。當然問題可以是解決 80%，也可以是 100% 解決，這就取決於個人工匠精神和極致的追求。
02關於技術
上面總結了一些自己的成長，那麼聊聊關於技術，這一年裏，通過不斷深入瞭解錦禮平臺，根據和VOP系統的共性及差異點，不僅將在VOP系統中優秀的經驗和案例進行引入，另外也在符合錦禮業務場景下做了一些技術創新和業務賦能。在詳細介紹之前，這裏分享一個對於技術規劃本質的一個說法，其實無論團隊還是個人，我們在設定技術目標與規劃技術體系時，大多都會按照體驗、穩定性、效率（降本增效）等等維度去拆分，但是每個人或者說每個團隊的精力和資源又都是有限的，所以如何選擇，如何判斷事情的輕重緩急，要回歸到產品和商業本身，畢竟技術存在的價值是以實現業務價值爲前提的。
針對關於技術，我大致總結了三個方面，分別爲積分資產防護、技術風險規避、客戶體驗升級，歡迎各位技術大佬留言交流。
積分資產防護
錦禮商城作爲企業業務唯一的BBC商城，也是唯一以個人消費積分（自身積分臺賬），企業付款進行結算的平臺，積分臺賬中的個人賬和企業賬數據的一致性&準確性，以及多場景活動（主商城模式、套餐模式、單次模式、不同定價規則等）下，多樣的積分結算方式，大幅的增加了資金損失的風險等級。積分的背後本身就是資金，所以無論多付少付，還是多退少退，都是涉及企業客戶對於我們京東的信任問題。因此秉着做當時環境最需要的事情，我針對性的提出積分資產防護的專題。
其中主要包括：
-
如何評估整個積分生命週期中出現資損的可能性以及應對設計，如何保障積分臺賬中的個人賬和企業賬數據的一致性&準確性。
-
如何快速檢查是否有資損事件的發生，做到及時報警快速止血，最終達到資損防控的目的。
-
如何滿足存量業務的同時，兼容低成本和未來增量業務的可擴展能力。
基於此，我以提單支付流程爲起點，積分臺賬數據爲依據，全面梳理積分資產生命週期中各個環節的異常情況（發放錯誤、消費錯誤、返還錯誤等），增加更爲嚴格的事前規則校驗、積分平衡覈對。
如：增加多層級的商品數據校驗，價格變動攔截，異常積分限制，平賬任務併發控制，個人支付等。
另外調研中臺能力（RC規則中心，大數據平臺），結合業務場景，快速落地不同層次不同維度不同時間延遲的積分對賬，以此通過（京密、郵箱、鯨盤文件等方式）及時感知資損問題的產生。
實現邏輯：
消費環節以JMQ爲觸發媒介，規則中心爲驅動，匹配不同的校驗規則，觸發旁支校驗來覈對線上邏輯。主要採用基線覈對、兩兩覈對、離線覈對（T+1）快速發現異常，定位問題，同時全鏈路的過程數據通過VOP日誌組件進行持久化和冗餘備份，方便不同場景下的核對以及基於過程數據進行數據修復等，同時對於高資損風險項預置必要的應急預案，在緊急情況發生時可以及時熔斷止血以保障積分資產安全。（如交易消息可選擇性回放和基於冪等原則的重新消費）。
基線覈對：將本地數據（本地訂單快照、訂單商品快照）作爲預期，進行對比，可快速發現重大的資金問題。
兩兩覈對：將上游數據（B中臺數據）作爲預期，進行對比，雙重保險，準確度高。
離線覈對：採用大數據平臺任務驅動的方式通過基線以及兩兩覈對的方式兜底來保障資金安全。
當前整個專題已經完全落地，事前規則校驗天維度攔截140+次，旁支校驗有效攔截和預警了70+次積分少付&多退的風險，其中還包括，春節期間檢測客戶賬號轉售的風控問題。後續積分資產防護會隨着每次業務功能開發進行增量式規則配置即可，比如近期我們計劃的限購規則的防護&兌換碼超期的防護，防止客戶提單突破限購規則或者超期的限制，我側無及時感知的情況。
技術風險規避
在保險行業有一個著名的法則，叫做“海因裏希法則”，是美國著名安全工程師海因裏希提出的300∶29∶1法則。通過分析工傷事故的發生概率，爲保險公司的經營提出的法則。這個法則意思是說，當一個企業有300個隱患或違章，必然要發生29起輕傷或故障，在這29起輕傷事故或故障當中，必然包含有一起重傷、死亡或重大事故。
放到我們系統中，同樣適用。系統日常過程中的報警，我們需要排除無效報警的噪音干擾，針對隱患問題究其根因，按照優先級進行優化處理。當一件重大線上問題發生後，大概率往往是我們當初已經定位過或者計劃處理的問題。事實證明我們一定要敬畏墨菲定律，特別在錦禮這種節日類特點的複雜場景下，已經有太多的案例來證明，如果覺得一個點隱約存在問題，那麼它早晚一定會變成問題。
錦禮商城其節日類特點的場景，也造成在比如端午、中秋、春節等傳統節日中，流量激增的情況，企業客戶正常開放活動無問題，但是節日類期間，部分企業爲提升員工幸福感，會進行一些類秒殺的活動開放，類似場景（上萬人活動秒殺）的流量高峯對我們系統的穩定性就有了更高的考驗。
在充分了解我們現有架構及問題後，我在技術風險規避方面，做了三個方向上的設計和實踐。
限流能力建設
通過調研實踐，在過去一年我們所有對外系統全面接入輕量級、標準化的限流熔斷平臺—泰山小盾龍，並進行活動維度限流，以此隔離每個活動之間不會互相影響，並增加ip維度限流，避免異常流量的攻擊。另外通過小盾龍實時的觀測告警手段和靈活的配置策略，可快速發現異常流量的活動，並根據系統現狀進行快速調整。
另外畢竟涉及企業下大量C端客戶的使用情況，所以我們也協同前端同學通過有效的交互設計，降低由於系統限制造成的客訴問題。
至今已支持企業客戶類秒殺活動80+次，無客訴產生，其中多次萬人活動。
流量治理
“熵增定律”大家肯定都清楚， 在一個孤立的系統裏，如果沒有外力做功，其總混亂度會不斷地增大，最後達到一個無序的狀態。對於軟件系統來說，“熵增”是無處不在的。比如：團隊在爲快速實現各種新項目，新需求，煙囪式架構，整個鏈路存在大量重複調用，無效調用等等，既浪費系統資源，又會在流量高峯期導致系統及底層存儲穩定性問題。或許我們很多情況，首想首選的都是擴容處理，既快捷，又有效。但是我們很多時候更應該認真思考的是，如何在資源的有限性中，來解決系統的穩定性問題。
因此在這一年裏，我們協同團隊所有同學，在需求迭代的同時，根據現有需求，梳理鏈路，採用提出無效調用，重複調用合併、緩存化、單條轉批量等等舉措進行優化，在過去一年裏，我們優化涉及20+核心接口，以活動查詢爲例通過技術手段消除重複調用、消除不合理調用，提高流量的有效率，接口調用量降低80%。間接提升系統穩定性，規避技術風險。
業務異常水位值報警
這個專題方向的來源背景是，我們的上游某接口出現問題返回對應異常，但是該異常本身屬於業務異常，日常也會有偶發的情況，源於客戶本身的屬性。但是由於上游系統上線故障問題，把不該命中的客戶也命中了，系統又由於其屬於業務異常導致未檢測到，直到客戶產生客訴，我們才得知。看過我之前文章的同學，在TOB領域，本身就存在大客戶的口碑效應，如果恰好頭部客戶碰到該問題，那麼極易被放大和激化。不過所幸當時不是一個某大客戶的投訴，不過也讓我們開始反思類似問題如何及時發現，優先於客訴前處理。
就於此，我們優先以提單爲標杆，設計了業務異常水位值報警，通過DUCC配置中心、ConcurrentHashMap和Scheduled 設計了一個業務異常水位報警的配置化實現。
截止目前有效監控10+起相關技術風險問題（活動配置異常、上游接口異常等），通過專人跟進報警，在未產生客訴前解決問題。
另外值得一提的是，過程中，爲進行不同業務異常的水位值設置，我梳理提單異常數據進行分析，發現提單收貨地址有誤異常天維度佔比較高，並通過專項優化（智能解析地址&異步調整和刪除不合規地址），提單收貨地址有誤異常下降95%（3000次/天下降至140次/天 ），有效提升了客戶體驗。
客戶體驗升級
過去一年，針對在客戶體驗上，整個團隊也做了大量的努力，比如上面剛提到的提單地址問題等等。客戶體驗升級，在我看來是一個持久性的話題，需要團隊更多的建設者一起添磚加瓦。這裏只列舉一個例子，針對商城可見不可售情況的優化方案——重定位技術的二次過濾組件。
一句話描述一下背景，由於我們系統涉及B 端控制檯和商城，企業採購員客戶在我們控制檯進行商品的增刪操作，其企業下的 C 端使用者在商城端進行積分消費和商品購買，但是往往由於多個系統間的異步同步問題，導致商城端頁面偶發出現可見不可售情況，產生客訴。
該重定向技術的二次過濾組件是爲了在商城端的“最後一公里“（異步同步的時延問題各團隊也在升級，提升吞吐量，保障儘可能的實時性，最後一公里指客戶真實看到的頁面）解決可見不可售情況，以此給予客戶可見即可售的優質體驗。其背後的原理是非常簡單，在搜索推薦的底層嵌入二次過濾工具，該工具適用於瀑布流式的列表請求過濾。主要原理是提前拉取後續數據進行過濾和寄存，並自動補齊缺失數據，下次請求直接從寄存器中獲取。通過自定義調整請求深度和步長倍數，保證接口查詢的性能，減少不必要的請求次數，提高系統的響應速度和穩定性。
通過過濾組件我們合併了 5處的過濾邏輯，其中主要流量入口屏蔽可見不可售商品，平均每天過濾585w次以上，根本上規避了可見不可售問題。效果圖如下：
一寫到技術相關，不好剎車了，綜上，就此停一下，其他的案例和故事，我後面再分享大家，比如我們是如何使用設計模式重構我們的價格服務，從而實現了一套可擴展性的架構，應對靈活多變的積分價格需求；如何梳理我們的任務平臺架構並優化，實現降低核心庫cpu30%+ -> 10%+；如何重構積分賬單相關代碼，來將積分逆向模塊解耦，在後續項目中實現0成本開發的；如何計劃引入 AIGC 能力賦能業務 等等。
如大家所見，一個技術的價值，不在於你的方案多先進，框架多厲害，而是是否可以更好的滿足業務需求，創造出新的東西。
03關於溝通
我本身是比較糾結這個話題總結的，因爲有時候我的溝通也是一地稀碎。我也有看到工作工程中，不少由於無效的溝通或者無謂的衝突導致事情沒有完美做好的。因此糾結再三，我還是寫下了，希望也是自己爲之努力的目標，可以以這些準則來進行律己，與各位共勉。
默認對方是友善的，用合作的姿態去溝通
我們在各種評審會或者日常溝通中上，比如PRD評審、技術評審、測試用例評審等，每每遇到一些不客氣的言論，就很容易上頭，認爲對方是在故意擡槓、針對自己，從而很容易情緒失控。要麼，演變成雙方的爭吵；要麼，自己在心裏生悶氣。
這時，一個更好的思考方式可能是：與其默認對方帶着惡意，不如默認對方只是單純的溝通不暢。
也就是說：不如試着告訴自己：對方也許並沒有惡意，這就是他一向的說法習慣，或許只是他的無心之語，不要太在意，儘量冷靜、平和的方式跟他溝通，把事情講清楚。謹防言者無心聽者有意，一來二往，導致原本正常的交流開始帶着火藥味，變成脣舌之爭，這完全沒必要。
當然這並不代表很多情況下我們要妥協，因爲並不排除對方確實就是故意找碴。如果你反覆表達善意，換來的還是惡語相向，那麼就可以考慮果斷停止溝通了，做會議過程中的“終結者”。
表達時多用數據和事實，少用模糊的印象和臆測
無論是和同事，還是領導，討論問題的時候，儘量使用客觀的、嚴謹的數據和事實，少用模糊不清的我記得、我覺得、大概是，等等。事實證明大多情況下我們也確實是栽在了這模糊的的印象和臆測中。
這包括哪些呢？比如某個技術方案的設計、統計數據、ROI設定、結果驗證，等等。儘量做到每個斷言都有出處，都可以溯源。如果忘了具體數據怎麼辦？那就先查證，再發言，絕不妄加揣測。
可能很多時候我們會覺得這很困難。實際上，這與其說是一種溝通方式，不如說是一種思維方式：當你要求自己在溝通中多使用數據和事實時，它就會倒逼你在生活中，有意識地多去積累數據和事實。換句話說：這是一種系統性的改變。你對自己輸出的要求越寬鬆，那麼你攝入和處理信息就會越隨便；你對自己輸出的要求越嚴格，那麼你攝入和處理信息，就會更加嚴謹。
闡述觀點時講清自己的理由和證據，謹慎對待沒有理由的觀點
當表達一個觀點的時候，儘可能的加上一句：因爲...，來闡明得出這個觀點的理由和證據。它們可能不是那麼嚴謹，可能不夠全面，但必須要有。如果沒有，是否大家可以認爲，這個觀點是一廂情願，或者在轉述別人的看法？如果我們自己都沒有辦法爲自己的觀點進行辯護，又如何讓別人信服它呢？
比如我們在技術改造和業務需求之間的需求排期矛盾中，如果一個版本我將較多的精力放在了技術改造上，我就需要講清這一塊計劃改造的理由和並在改造中做好數據上的埋點記錄，不單單爲了分析功能的效果，更多的是有一個充分的支點支撐你技術改造的價值。
總之，要對自己的發言負責，讓自己講出去的話，都有理有據。這樣，你的話纔會有分量。這也是對於個人品牌的一個積累，畢竟靠譜的同學無論做什麼業務會搶手受歡迎。
溝通時簡要複述對方的重點，確保自己聽懂了
很多情況，特別在跨團隊跨部門的會議中，以及特別在面臨不同工種的時候，隔行如隔山，再加上技術人員的一點點的小清高以及表達容易進入晦澀的領域。往往交流時容易陷入一個誤區，那就是各說各話：你在重複你的觀點，我在重複我的觀點。看起來討論得很熱烈，但其實一直對不到同一個點上。
爲什麼會出現這個問題呢？因爲人都有旺盛的表達欲。相比起聆聽，我們往往更喜歡錶達。因此，經常是你的話還沒說完，對方就以爲自己已經聽明白了，開始迫不及待地輸出他的觀點。
解決這個問題的一個方法就是：在表達你的觀點之前，先簡要概括對方的觀點，向對方確認：你想表達的是……嗎？我的理解有沒有問題？以此達到對齊和校準的作用，讓對話雙方能夠基於同一個共識和目的進行交流，而不是把時間空耗在自說自話上。這是一個非常有效地把話題引導向正規，避免它轉向細枝末節或鑽牛角尖的方法。
擁護他人意見不同的權利，不追求輸贏，不做口舌之爭
許多人容易犯一個錯誤：總是喜歡把討論變成爭論。在我這個領域，我覺得特別是在方案的討論上，有跨部門中因爲方案中某個模塊因爲界限模糊，或者其他原因導致無法確定由那個團隊進行落地的爭論，有本部門中技術方案想法不一致的爭論，有是否應該遵循一些規範的爭論等等。
每個人都有自己的立場和看法，人與人之間看法不同，實在是再正常不過的事情了。但當許多人發現對方跟自己看法不同時，他們往往就會變得十分激動，非要爭一個輸贏。彷彿只要說得對方啞口無言，自己就贏了，就成功捍衛了自己的立場。
但這是沒有意義的。有效的討論是什麼？是爲了達成共識，找到一個雙方都認可的結論，而不是爭一個輸贏 —— 它除了給你一個虛幻的滿足感之外，毫無價值。討論的本質，是信息的交換，是讓你知道除了我的看法之外，原來還可以有別的看法，它是一種對你的視角和認知的補全。
不要以自己爲中心去思考問題，要考慮“共贏”、“利他”，以團隊和合作視角全方面立體地思考問題。我們更多的目的都應該是如何幫着一起把產品做好，要多給建議，而不是處處挑戰。
求同存異，想必不用我多說了吧。當然，如果當你和同事進行方案溝通中，你也拿出了上面說的的數據/理由/態度盡最大的努力去說服他，但是充分溝通還形不成共識，那麼可以進行升級溝通，讓領導參與最後的拍板。但是如果你和領導也發生了分歧，並且充分溝通還形不成共識時，那就先聽他的。一定程度上，這不是一種媚上，而是“在必須達成一致的前提下，相信更有概率做出正確決定的那個人”。
多詢問對方的感受，不自作主張，不妄自”換位思考“
特別在於產品設計以及用戶體驗上，我們總是覺得自己可以站在客戶和業務的角度進行換位思考，以前我也是很傾向“換位思考”這個概念，總覺得我都站在你的角度幫你想這個事情了，還要我怎樣？後來我就完全否定了，原因很簡單：我們永遠無法想象自己不知道的事物。因此，所謂的“換位思考”，本質上，還是在用我們過往的經驗和框架去思考，並沒有能夠真正地代入別人的角色，體會別人的感受、想法和邏輯。這種做法是沒有用的。它其實是一種傲慢，是一種認爲我能替代你去思考，替代你去感受的自以爲是。
更好的做法是：坦誠相對，直接詢問對方的想法、感受和意見。做一個學徒，放低自己的姿態，去跟別人溝通，去接受別人的表達和傾訴。不要自以爲是，不要越俎代庖，不要自作主張，而是聆聽，接受，包容，在根據對方的想法、感受和意見進行有效的設計和開發。
04結語
以上，無論成長、技術、溝通，大多都攜帶我個人的一些想法，文筆有限，無法完全描述，如有問題，歡迎交流斧正。
談不上洋洋灑灑，在編寫這篇文章的同時，我也在不斷的反思和展望，反思過去一年的自己，展望即將邁入錦禮的第二年，需要如何提升自己，如何提升系統的穩定性，如何提升產品的使用體驗？你看又要面臨迷茫了，不過誰的“青春”又不迷茫呢？ 歡迎志同道合的朋友交流討論，一起打破迷茫，一同在這個充滿挑戰的新徵程裏，勇往直前。