有一種客人，有問題來找你時，早晚問候，噓寒問暖。每封信的開頭不忘提及他對你的關心以及你對他的付出，每封信的結尾都是道不盡的感謝與期盼你的回信。

等到他從你身上得到他想要的東西或是答案，你再多的呼喚也換不回他的一聲答應。

事情的經過是發生在多年以前，有個客人使用VMware vSAN的服務搭配穩當當公司的伺服器，但是突然發現最近有2、3台機器的硬碟會隨機發生問題，但是只要機器一重開，問題就會消失一段時間，隨後某一天又會再出現。他們連絡我們的目的是確認一下是不是有實際上的disk error或是VMware的誤報。

這次是倒霉的客服工程師D收到這個案子，從客人提供的HW log來看，一共有三份log來自不同的機器，數一數每台機器的HDD都乖乖的出現，完全沒有提到任何的disk error。於是立馬建議客人提供這三台機器上詳細的HW規格以及客人從何觀察到disk error。

可能是情況真的很緊急的原因吧，一小時內立馬就收到了客人更詳細的回覆。

啊？這次怎麼給了四份log，看了下主機名稱，竟然只有兩台跟之前的主機名稱相符。看來是越來越多機器遇到問題了是吧。打開這些log一看，各自都分別有1到2個disk有回報一些錯誤代碼，不過log中並沒有指出是什麼錯誤，而且也無法一眼看出是對映到機器上的那些實體HDD。

vm149 vmkernel: cpu71:2098487)ScsiDeviceIO: 3449: Cmd(0x45a70296d0c0) 0x28, CmdSN 0x2b06 from world 0 to dev "naa.55cd33456783a7c" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x3 0x11 0x0.
vm149 vmkernel: cpu71:2098487)ScsiDeviceIO: 3449: Cmd(0x45a7028aebc0) 0x28, CmdSN 0x2196 from world 0 to dev "naa.55cd33456788f43" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x3 0x11 0x0.

信的最後，也許是客人從其他廠商那邊拿到比較完整的分析結果，結論就是medium error/unrecovered。

同時順便恐嚇一下，由於這是個vSAN cluster的環境，如果有更多的機器回報類似問題，可能會導致cluster失效。

幸好D也不是吃素的，立馬把手上僅有的資料做個整理，在比對HDD資料的時候，突然發現同一台機器上的HDD型號雖然相同，但是FW卻有兩種，憑藉著之前的工作經驗，大膽給出了讓客人也同步向VMware確認是不是混用HDD FW導致的vSAN相容性錯誤，為自己的RD爭取一些troubleshooting的時間。

	Line  237: Firmware Revision = 0100
	Line  324: Firmware Revision = 0100
	Line  411: Firmware Revision = 0100
	Line  498: Firmware Revision = 0110
	Line  585: Firmware Revision = 0110
	Line  672: Firmware Revision = 0110
	Line  759: Firmware Revision = 0100
	Line  846: Firmware Revision = 0100
	Line  933: Firmware Revision = 0110
	Line 1020: Firmware Revision = 0100

只是在客服工程師D正在為自己的經驗老到自滿的同時，客人立馬提了桶水來潑。

客人表示，他們早就已經開了ticket給VMware，VMware表示這是真真切切的HW issue，不要想把鍋甩到他們頭上，但是客人最後還是很客氣的說，他們會再多和VMware"討論討論"。

球最後還是留在了自家，D帶著給的球去找RD們開作戰會議的同時，不免俗的也越來越多人關切了，從客人的業務到自家的業務，客人的PM到自家的PM，RD最後在會議上只能允諾試著連絡HDD廠商看看，畢竟中間牽扯到很多大家不熟悉的技術與錯誤訊息。

客人方面當然也不會閒著，除了各方施壓，問候D的信當然也不會少。

接踵而來的信裡，開宗明義的便表示，如果你們目前沒有方向的話，要不要我退幾顆HDD回去給你們分析分析？

當然，是要寫很多報告的那種分析。

這下可頭大了，深深體會到，在客人面臨問題壓力的同時，讓他們閒下來絕對不是件好事！

因此，D決定反客為主，主動提出了不然我們來玩一下填表遊戲吧！整理一下客人之前給過的主機名稱一共有五台，反正客人給的資料也不是很齊全，順便請他補齊，然後把發生問題的HDD標示在表格中好了！

信一寄出，就收到了不錯的效果。此舉明著能夠給出讓客人感到積極的分析方向，私底下又能為我方爭取多一點的時間跟內部與廠商之間做溝通連繫。大家也得到了四天的緩衝時間，然後收到了客人初步的回報。

面對複雜的問題，讓客人做太多工作的下場就是你只能期望有50%的完成率就很好了。

客人給出了以下回覆：

D一打開這封信，心裡還真的是忍不住想吐嘈，一開始右邊兩台的資料就不齊全，沒想到四天過後這兩台還是沒有下落呀…

不過，隨著仔細的觀看客人標示紅字的部分，突然有了個意外的發現！

標上紅字的部分，怎麼剛好都是FW 0100的版本呢？雖然不見得所有FW 0100的版本都有發生問題(標上紅字)

但是這也太奇怪了，立馬找RD一起來討論下。

隨著大家一邊討論，有人一邊上網google，還真的給他找到了個其他軟體廠商針對此款HDD給出的bug report。

問題會在該款HDD運作一定時數之後發生頻率變高，並建議使用者更新到FW 0110的版本。

因此大家看到這裡都鬆了一口氣，剩下的就只剩協助客人更新並針對有嚴重失效的HDD做更換了。

在整理了我們的發現與參考的連結給客人後，大家又開始忙自己手邊的其他工作，因為客人後來也沒有再回信與跟進，這件事也慢慢的被大家淡忘。

直到半年過後...

這次的主角又是我們的客服工程師D，收到了一封寫著VMware HDD fail的信。

恩？怎麼覺得聽起來有點熟悉，信裡寫著VMware report HDD SMART health已經異常，請考慮更換HDD。

一共六台機器，這次還大手筆給了數GB的log，陣仗之大。

半年前的訓練讓D反射的便先檢查一下HDD model & FW revision。

	Line  237: Firmware Revision = 0148
	Line  324: Firmware Revision = 0148
	Line  411: Firmware Revision = 0148
	Line  498: Firmware Revision = 0148
	Line  585: Firmware Revision = 0148
	Line  672: Firmware Revision = 0148
	Line  759: Firmware Revision = 0148
	Line  846: Firmware Revision = 0148
	Line  933: Firmware Revision = 0148
	Line 1020: Firmware Revision = 0148

恩？HDD model符合，但是FW revision已經超新的了？由於有了半年前的經驗，這次的反應非常迅速。

RD直接找上了HDD廠商，他們表示如果更新FW後還是有相同狀況的話，那就直接RMA，沒救了。

客人表示RMA沒有問題，但是有些更新到FW 0148的機器有vSAN效能上的問題想和我們進一步釐清。

聽到這裡我們就有點不知所措了，只好表示我們需要從HDD廠商那邊得到進一步的指示再給出清楚的做法。

HDD廠商雖然得知客人有效能的問題，但是表示不排除還是之前的FW問題留下的遺毒，因此還是從基本上的HDD SMART data來做檢查比較踏實，省得在錯的基礎上做troubleshooting。

因此最後還是給出了讓客人收集HDD SMART data這樣的建議，雖然這聽起來也不是什麼太難的事，偏偏smartctl在當時VMware的OS中就是沒有，因此又經歷了一段客人想拿VMware裡的資料來比對但是HDD廠商看不懂，以及HDD廠商想讓客人裝他們的tool，但是客人不允許的漫漫長路。

最後花了很多力氣才說服客人用live linux image來收集HDD SMART data，結果....

半年前的那個case，客人突然回信了，說vSAN現在的效能問題似乎跟機器上的網卡有關，想讓我們進一步找網卡廠商分析。

WTF！現在是要開新戰場就對了，因此客服工程師D一方面繼續將HDD SMART data的資料收集結果做收尾，一方面找RD和網卡廠商來應付新的戰場。

最後SMART data顯示沒有任何HDD異常，網卡廠商經過數次的log 收集與電話會議後也看不出網卡和他們聲稱的vSAN效能異常有何種關係。

客人似乎也發現從眾廠商間拿不到什麼明顯的證據來支持某個論點而慢慢的開始延長回信與討論的間隔。

這個問題也在半年後的死灰復燃，又多燒了三個月之後又漸漸的趨於平淡。

會不會那天，過了半年一年之後又來舊情復燃，往事重提呢？這大概也只有渣男的心裡才明白了。