傑瑞的旅遊日記

稍早一則 "GitLab工程師熬夜工作誤刪300GB資料"
讓我驚訝了一下,也為工程師及GitLab憂心
很多時候,大部份的人標榜與鼓勵員工犯錯,包含了我也鼓勵小朋友犯錯,
但真正能夠做到珍視犯錯價值的企業不多,包含了我也常責備小朋友.

據《The Register》報導，1月31日，一位於GitLab荷蘭的系統管理員,徹夜加班
他在疲憊不堪的狀態下,在維護資料庫時不慎誤刪了正式環境的資料
就當他回過神來時發現慘了,趕緊用-取消「rm -rf」刪除指令時，
原有300GB的資料已被刪到只剩4.5GB。

通常大公司都會有做災難復原的規劃的,GitLab也不例外且做了5個備份機制
包含每24小時執行一次的LVM快照和常規備份、S3、Azure中的磁碟快照
（只能用於NFS伺服器、而非資料庫伺服器）和同步備份

但只有電視劇才會出現的劇情,就這麼發生在GitLab，GitLab的5個備份機制都出問題了，
(贊助商廣告連結................................)
 
居然5個備份機制都有問題~

而後來,雖然幸運的是,他們在臨時伺服器發現一份事件發生前6小時前的備份,
好讓他們得以回復資料,但仍然有損害到客戶及公司的形象,
GitLab的後續處理如何呢?

後續處理尚無法完全追蹤,但是....非常值得稱讚的是GitLab的透明度，
他們在官網及其他許多的地方,像是官方Twitter、Google 等等即時更新事件說明，
而且甚至在YouTube上還直播工程師搶修的過程，並且開放提問。

最讓我眼睛一亮的事,有人問到那個肇事的工程師是否會因此被罰甚至裁員，
而GitLab回覆: 他們僅是一次工作失誤，不會因此裁掉他們。
除此之外:
他們也不隱瞞事故發生原因,將原因推託給硬體故障、
或是外部入侵等,直接公布就是人為操作失誤.

(贊助商廣告連結...............................)
GitLab主管的作為讓我非常地欣賞,這麼一家"透明處理"的好公司
也讓我連想到了IBM "錯誤的價值 一億五仟萬元"~
台灣IBM一家客戶購買供應鏈管理系統，IBM卻因一名員工的疏失進錯系統，
後來只好緊急從美國進口，加上修改成本，導致這宗生意讓IBM蒙受一億五千萬元損失。
事後追究責任，有主管主張嚴懲這名員工，
但在全球企業諮詢服務事業群總經理劉鏡清一席話力保之下被輕輕放下。
劉鏡清說，「我們IBM不是最重視從錯誤中學習嗎？
這是花了一．五億好不容易學到的經驗，我們是要把這經驗送給別人用呢？
（意指這名員工可能離職）？還是留下來自己用？」

文章來源: - See more at: http://www.cw.com.tw/article/article.action?id=5001124#sthash.QdHbvtgf.dpuf


傑瑞的文章新單字:RTO , 什麼是RTO ?
在備媛的專有名詞中有出現Recovery Time Objective (RTO，復原時間目標)
定義了最大可容忍時限，您必須在此時限內復原資料。發生災難時，
如果您希望系統必須馬上可用且允許遺失部分資料，則 RTO 為零。
然而，如果您允許有一小時的時間來復原資料，則 RTO 為一小時。