PIXNET大地震事件,談產品經理如何面對升級或改版

這次Mr PM的部落格,也是PIXNET改版大地震的受災戶。其實很明顯的,PIXNET的站方群,雖然是WEB方面技術的長才,可是卻沒有受過正確的服務規劃訓練。

PIXNET這次服務大地震,在一般在業界有規模的公司,幾乎是不可能發生的。為什麼呢?因為在服務改版或升級前,他們有幾個非常重要的原則會遵守。

  • Roll back機制,萬一系統掛掉,還可以馬上Roll back到原本的系統。
  • Test Bed的建置,Test bed是一個和現在正式商轉的環境一模一樣的環境,然後再利用Test bed進行升級或改版,然後公司內部的同仁,會對這個Test bed進行Fied Test(就是亂玩亂測),來發掘Bug。一般來說,Test bed建置是很麻煩的,又非常花錢;所以系統開發者都不太願意弄個Test bed,他們會比較喜歡用Roll back的方式進行。
  • 絕對不可能有一邊在使用者還在用的時候,還一邊在改版,這次PIXNET就是一邊讓使用者用,一邊改版。一般業界會寧願服務下線一個禮拜,也不會讓服務殘破的在線上跑一個禮拜。

之前或許有不少WEB2.0的忠實粉絲會認為,WEB2.0就是要由使用者參予,不必自己debug,弄個beta版上線,讓使用者來回報bug就好。至於Test bed,那種觀念已經過時啦!不過當使用者真的感受到使用不便後,倒楣的絕對是服務提供商,誰還管它是WEB1.0還是2.0,該認真做的還是得做,不能因為麻煩或討厭就跳過這一步。

希望這次PIXNET的大地震事件,可以給站方一點教訓,該2.0的部分2.0,該腳踏實地的部分,還是老老實實做吧。

(tempo網友回了很不錯的回應,大家請看回應。大意是說,PIXNET應該讓舊版與新版同時運作,一邊讓大家debug,一方面用戶也可以選擇比較穩定的舊版。)

留言