人肉運維100次后，終究還是翻車了！

人肉運維100次后，終究還是翻車了！

翻車現場

雙節(jié)前的一個晚上，我接到數據組同事的消息，要求將A用戶的磁盤快照共享給B用戶。我對這個線上運維工作早已輕車熟路，登錄線上服務器僅用了2分鐘就完成了。

我繼續(xù)忙著其他事情，3分鐘后，我正要打開新的控制臺頁面，猛然發(fā)現控制臺上的public = true。我驚慌地查看磁盤快照狀態(tài)，「發(fā)現磁盤快照已經共享給了所有用戶。任何用戶都可以在自己的快照列表中看到這個快照，并用快照創(chuàng)建新的磁盤，這意味著這些快照數據已經泄露了。這可是公司重要客戶的磁盤數據」?。。。?！

我心里明白，對于云計算行業(yè)，數據安全問題比線上bug還要嚴重！

我立刻就慌了，心臟砰砰的跳，手也開始顫抖。我心里很忐忑，一開始試圖偷偷回滾，糾結之后，最終選擇告訴了組長。

我倒吸一口氣，一邊進行回滾，一邊試圖平靜的說，“我把剛才的快照共享給了所有租戶”。瞬間，組長瞪大眼睛了看著我，“回滾了嗎，趕緊回滾……”。我顫抖地編輯SQL，手都麻木了，心臟還在怦怦跳個不停，開始擔心這件事的后果。

領導邊看我回滾，邊小聲對我說，“趕緊回滾，下次小心點”，看的出來，組長不想聲張，他想先看看影響。

”嗯，好“，我努力嗯了一聲，組長沒大聲罵我，我很感動。本以為回滾了，就沒事了。

?

（后來這家小公司黃了，這是被我干黃的第二家公司，你們干黃了幾家？）

?

然而，這遠遠沒有結束。

原本寧靜的辦公室突然變得熱鬧起來，周圍的同事們紛紛接到了報警通知。他們“興高采烈”地討論著報警的原因，我的注意力也被吸引了過去，聽起來似乎與我有關，但我卻沒有心情去理會他們。

最終，快照被共享 5 分鐘后，回滾完成，我長舒一口氣，心想幸好我多看了一眼控制臺，否則不知道被泄露多久。

與此同時，鄰居組的成員錢哥找到了我，問道：“剛才快照計費數據暴漲了，你們這邊有做過什么操作嗎？”

隨后，鄰居組的組長王哥也過來了，詢問情況如何。

我的組長苦笑著告訴他們：“剛才一個磁盤快照錯誤地被共享給了所有租戶，不過現在已經回滾了?！?/p>

鄰居組的王哥聽后驚愕地說道：“臥槽，誰干的？”他的臉上露出了一絲微笑，似乎是看熱鬧的微笑。

我實在不知道該怎么說了，苦著臉問他們：“計費數據能回滾嗎？”

鄰居組的王哥沒有回答我的問題，看了我一眼，說：“我叫上老板，先找個會議室討論一下吧。”

萬幸的是這 5分鐘里沒有用戶使用此快照創(chuàng)建磁盤，這意味快照數據沒有發(fā)生實質性泄露。

至暗時刻

接下來的兩天里，我只做了兩件事，參加復盤會議和去會議室的路上。這兩天是我人生中最難忘的時刻，我尷尬得連腳丫子都能擰成麻花。

我真希望能立刻辭職離開這個地方?！眲e再鞭尸了，老子不干了，行不行。md，不就是共享個快照嘛！“ 我的心理狀態(tài)從忐忑變得暴躁~

?

（每次造成線上故障，我都有類似的想法，我不想干了，不就是個bug嗎，不干了，還不行嗎？你們有類似想法嗎？）

?

后來我開始后悔 ，為什么不早點下班，九點多還幫同事進行高危的線上操作，我圖個啥

對，我圖個啥。我腦子被驢踢了，才提出這個人肉運維方案，一周運維十幾次，自己坑自己……

背景

2個月前，組長接到一個大客戶需求，要求在兩個租戶之間共享云磁盤數據，當時提出很多個方案，其中包括分布式存儲系統提供工具共享兩個云磁盤數據等非常復雜的方案。我當時聽到這個需求，就立馬想到， 我們的云管理系統可以實現兩個租戶的資源共享啊，通過給云磁盤打快照、共享快照等，就實現兩個云磁盤的數據共享。

當時我非常得意，雖然我對存儲并不是很了解，但是我相信我的方案比存儲團隊的底層方案更加簡單且可行性更高。經過與客戶的溝通，確定了這個方案能夠滿足他們的訴求，于是我們定下了這個方案。

由于大客戶要的比較急，我改了代碼就急匆匆上線，這個需求甚至沒有產品參與，當客戶需要共享數據時，需要我構造請求參數，在線上服務器上命令行執(zhí)行共享操作。第一版方案在線上驗證非常順利，客戶對這樣快速的交付速度非常滿意

因為我們使用了開源的框架，資源共享能力是現成的，所以改動起來很快。只不過有一個核彈級feature，我忽略了它的風險。

public = true時，資源將共享給全部用戶?！爸灰辉O置這個參數就不會有什么問題?！?這是我的想法，我沒有考慮誤操作的可能，更沒有想到自己會犯下這個錯誤。

本以為只是低頻的一次性操作，沒想到后來客戶經常性使用。我不得不一次次在線上執(zhí)行高危操作，剛開始我非常小心謹慎，仔細的檢查每個參數，反復確認后才執(zhí)行命令。

然而，后來我感到這個工作太過枯燥乏味，于是開始集中處理，一次性執(zhí)行一批操作。隨著時間的推移，我越來越熟悉這件事。這種運維操作我兩分鐘就能完成……之所以這么快，是因為我不再仔細檢查參數，只是機械地構造參數，隨手執(zhí)行。正是我松懈的態(tài)度導致闖下了大禍，在那個日常性加班的晚上。

后來我開始反思，從需求提出到故障發(fā)生前，我有哪些做的不對的地方。我認為有如下問題。

1. 技術方案不能僅限于提供基本的資源共享能力，還要提供可視頁面，提供產品化能力。
2. 高危接口，一定要嚴格隔離成 單獨的接口，不能和其他接口混合在一起，即使功能類似
3. 線上重要操作要提供審核能力！或者有double check 的機制！

深刻的反思

任何工作都是有風險的，尤其是程序員無時無刻都在擔心發(fā)生線上問題，如果不學會保護自己，那么多干一件事就多增加很多風險，增加背鍋的風險。

拿我來說，本來這個需求不需要我參與，我提出了一個更簡單的方案，高效的響應了大客戶需求，是給自己長臉的事情。然而，我犯了一個巨大的錯誤，之前所做的努力都付之一炬。大領導根本不知道我提出的方案更簡潔高效，他只認為我辦事不可靠。在復盤會議上，我給大領導留下了非常糟糕的印象。

話說回來，在這個事情上如何保護自己呢？

1. 技術方案一定要避免人肉運維，對于高危運維操作要求產品提供可視化頁面運維。一定要盡全力爭取，雖然很多時候，因為排期不足，前端資源不足等原因無法做到。

2. 如果沒有運維頁面，等基礎能力上線后，繼續(xù)尋求組長幫助，協調產品提供操作頁面，避免一直依賴自己人肉運維去執(zhí)行高危操作。

3. 在還沒有產品化之前，要求客戶或上游同事將所有的需求整理到文檔上，使用文檔進行溝通交流，記錄自己的工作量，留存一份自己的”苦勞“。

4. 在低頻操作，變?yōu)楦哳l操作時，不應該壓迫自己更加“高效運維”，而是將壓力和風險再次傳達給產品和組長，讓他們意識到我的人肉運維存在極大危險，需要要盡快提供產品化能力。讓他們明白：“如果不盡快排期，他們也會承擔風險！”

5. 任何時候，對于線上高危操作，一定要小心謹慎。萬萬不可麻痹大意！

總之，千萬不要獨自承擔所有的壓力和風險。在工作中，我們可以付出辛勤努力，承受一定的風險，但是必須得到相應的回報。

就這個事情來說，每天我都要執(zhí)行高風險的運維操作，是一種辛苦而不太受重視的工作。盡管如此，我卻必須承擔著巨大的風險，并自愿地讓自己不斷追求更高效的人工運維方式。然而結果卻讓人啼笑皆非，我終究翻車了。實在是可笑。

?

掙著賣白菜的錢，操著賣白粉的心，這是我的真實寫照。

?

吾日三省吾身、這事能不能不干、這事能不能明天干、這事能不能推給別人干。

程序員不善于溝通，往往通過加班、忍一忍等方式默默地承擔了很多苦活、臟活、累活。但是我們要明白，苦活可以，臟活等高風險的活 千萬不要自己扛。

你干好十件事不一定傳到大領導耳朵里，但是你出了一次線上大事故，他肯定第一時間知道。

?

好事不出門，壞事傳千里。

?

我們一定要對 高危的人工運維，勇敢說不！

程序員在溝通方面存在著不足，經常通過加班、忍耐等方式默默地承擔許多辛苦、臟亂累的工作。然而，我們必須認識到，我們可以承擔辛苦的工作，但是決不能獨自承擔風險高的臟亂累的工作。

你可能做了十件好事，但不一定會傳達到更高層領導的耳朵里；但是一旦發(fā)生了線上重大事故，他肯定會第一時間得知。好事不出門，壞事傳千里。

因此，我們一定要勇敢地對高風險的人肉運維說不！

這是多么痛的領悟！