用戶報告故障。技術支持16點到達現場。現場是兩臺S9609做堆疊，跨設備鏈路聚合。聚合鏈路有丟包。有的終端ping完全不同。17點定位出來是S9609上一個光模塊有問題，更換光模塊後通信就正常了。和堆疊和鏈路聚合的關係在於。鏈路聚合是根據報文的SMAC地址來進行hash計算，決定走那條成員鏈路。被hash到問題成員鏈路上的報文就會丟失。有的終端ping完全不通。說明它的報文被hash到問題成員鏈路上了。但是需要明確，跨設備鏈路聚合與故障原因沒有關係，它只是受影響者。
故障定位出來了，故障也已經解除了。但是用戶不太相信就是單純的光模塊問題。按道理，我們可以嘗試從以下兩個方面做進一步處理。
- 對比試驗。把這個光模塊放到其它能正常工作的鏈路中，也會出現這個問題。來佐證確實是光模塊有問題。比如兩臺設備直接相連，其中一臺使用了問題光模塊，這樣互相ping，就發現大量丟包，甚至徹底。但是用戶目前不願意將光模塊交給我們。沒有條件做試驗。後續取出光模塊後做試驗。
- 技術分析：查看光模塊的內部工作狀態，說明內部出了什麼問題，導致光模塊收到的光信號強度正常，爲-13dbm，但是收包不正常。但是這個需要專業的檢測。就算取出光模塊，時間也來不及。只能後期去做。
更遠期的防禦性的，需要確認這個品牌、這個型號和批次的光模塊，質量情況如何。
用戶要求我司在模擬環境中重現類似的現象。並且第二天早晨10點之前提交報告給他們。
真正有效的兩個技術方法，都沒有辦法執行。導致這個問題短期來看不再是一個技術問題，而主要是一個溝通問題。就是如何讓用戶相信，是單純的光模塊的問題。更換光模塊之後，我們的設備能夠穩定運行。並且讓用戶允許我們帶走問題光模塊，讓我司進行做進一步的試驗和檢測。
技術支持暫時沒有條件搭建環境，領導安排我們產品測試部搭建類似環境重現類似現象。雖然我很清楚實際上現在要求做的是在另外一套環境中來重現這個問題。邏輯上來說。這其實和原本要解釋的故障現象已經沒有什麼關係了。但是因爲目前技術支持已經答應客戶公司裏會做這個試驗。領導也已經安排。就只能去做了。即使只是增加了技術支持和用戶溝通的素材。但卻是對用戶承諾的履行。就有效性的差異，我和領導和技術支持做了溝通。防止他們對驗證的有效性產生誤解。
最終重現的目標變成了弄出這樣一種現象，接口link up，但是不收發包或者大量丟包。
用好的光模塊來模擬不知道具體出了什麼問題的光模塊的行爲，本身並不可行。我們只能想辦法使光信號的質量變差、光強度變低。我需要再次強調，就算重現了故障現象，和現場的故障原因也是完全不同的。不過我還是需要堅決執行領導的安排。
我查看光模塊的參數文檔。發現LOS alert的光強度遠小於receiver要求的最小光強度。所以邏輯上只要光強度大於LOS alert光強度，小於receiver要求的最小光強度，那麼就可以出現link up但是不收包的情況。
這是一個非常規任務。所以我親自制定了試驗思路，然後安排人去執行。能夠使用的手段有拔松光模塊、拔松光纖、使用光衰減器、單模模塊（現場是單模）錯配多模光纖。光功率計作爲檢測手段備用。
需要說明的是：光衰減器只有5dbm和10dbm兩種，無法靈活調整光衰減程度。另外，拔松光纖、光模塊，這種操作精確度很低，可控性非常低，有可能拔松一點就link down，插緊一點就完全不丟包了。
所以無法明確預期可以很有把握重現類似的故障現象。就這一點我同領導和技術支持做了溝通。以免他們期望太高，導致不必要的失望。
17點30分任務到達產品測試部，18點完成溝通，開始尋找資源、搭建環境、執行任務。
最終21點發現在使用光衰減器的情況下，拔松光纖會出現類似現象。接口link up，但是數據流不管收還是發。都有大量丟包、有時甚至完全不轉發。測試儀接收端收到的流量速率在不斷波動。
我指導執行人做了相關的對比測試，寫出報告。21點30分將報告發給技術支持。
第二天9點我通過微信語音通話召集技術支持、領導一起開了多人會議。將試驗結果進行了溝通。