昨天說到第一個假設是因地區差異造成的，除了地區以外，我們跟用戶之前可能還有哪些差異呢？有沒有可能是電腦本身的差異？我們在辦公室使用的電腦，因為工作需求，配備一定比較好，所以有沒有可能是因為基本配備的差異造成用戶覺得慢呢？再繼續動腦看看，還有什麼可能？會不會是設備異常造成的？有沒有可能是程式本身造成的慢呢？

都是有可能的，各種假設在還沒有驗證之前，都應該被視為一個可能造成用戶體驗不佳的潛藏因子，我自己滿喜歡先發散在收斂的，因為真的有時候查了很久，才發現問題真的是發生在一開始覺得不可能的地方！這次分享的例子，其實最後我們查到整個系統瓶頸之一是在設備上。

為什麼說之一呢？其實我們認為問題因素是複合的，只是最近先被找出並解決的是在設備面上，老實說我們也不是一開始就想到要對設備做測試，而是主管在客戶不斷地反映問題後，不知哪來的靈感，覺得很有可能是設備負荷到達瓶頸，所以嘗試把部分用戶從設備面上做拆分，我們把少量的服務分到實驗組，再觀察看看。

以往觀察看看都是透過人工，或是等待客戶反應，但這次延續之前做實驗的精神，我們便提議針對拆分前後的設備去做測試，用科學數據來佐證，在第一次的時間，我們發現原設備與實驗組設備的模擬請求(request)，都會有一定頻率的慢秒情況，第一階段的實驗可能會讓人覺得這樣的結論，問題應該不會是出在設備。

但我們在跟管理設備的溝通討論後，發現這個會被反應慢的產品，因為服務量大，所以架構上跟其他產品不一樣，雖然都是使用相同設備，但其他產品是一個設備通吃多種服務，但被反應的產品是透過兩三組設備，每一組設備提供一種服務，來達到需求。

這樣一討論，我們就想到還有可以做其他測試，我們使用相同的測試方式，去測試其他產品，發現其他產品的服務皆正常，我們便決定再做一組實驗，我們在拆一小部分的服務到第三組設備，第三組用的架構與其他產品相同，一測之下，就發現問題真的是出現架構面上。

說到這裡，大家不知道還記得我們主題是 DevOps ，這樣的大膽架設小心實驗跟 DevOps 有關嗎？有的，在上述的處理過程中，跨過了開發團隊、設備管理部門跟維運夥伴。整體的實驗方向與假設是由大家共同商討的，設備管理部門負責準備實驗用的環境，並與維運部門共同把服務從原設備分開，透過開發部門則負責撰寫程式來驗證，這樣的跨部合作也是 DevOps 重要的精神之一。