iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 28
0

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

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

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

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

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

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

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


上一篇
大膽假設小心實驗(1/2)
下一篇
從系統架構透明度來看 DevOps
系列文
誤入 Ops 叢林的 Dev 小白兔30

尚未有邦友留言

立即登入留言