如何評論阿里云云盾負責人的這篇《危機時刻，我只心疼我們的客戶》？

11-26

在微信上看了了轉載的阿里雲安全高管的《危機時刻，我只心疼我們的客戶》後，總感覺往日的雲安全和互聯網安全給人的好感覺和創新印象，突然一下子被自己人從內部搞塌了
1 從產品角度看：另外這個雲盾的操作方式感覺和以前的360很類似啊，都是沒有詳細告知用戶，只是一個針對中端，一個針對雲主機
2 從服務角度看，這篇文章最後的百倍時間賠償+4個最新的彌補決策，對用戶的價值如何？能有效減輕用戶的憤怒和挽回部分損失嗎
3 從技術角度看，這次好像是程序員的代碼錯誤，但採用這種方式，並且用戶無法控制這種升級過程，萬一被黑客或惡意的內部人員(比如報復的角度)在雲盾的代碼里加入一些惡意代碼，那麼升級後所有的雲主機都存在被感染的可能？雲安全該不該採用這種主機agent的方式來進行呢？

《危機時刻，我只心疼我們的客戶》專欄鏈接地址危機時刻，我只心疼我們的客戶 - 道哥的黑板報 - 知乎專欄

雲盾服務犯了以下幾個錯誤：

首先ECS的目標用戶是開發/運維工程師等，而不是電腦小白（聯想一下360）。不否認確實有很多工程師是安全小白，但是強行把所有人當作安全小白來推行這個服務應該是大大傷害了用戶不斷膨脹的自尊心。
自己搶著要當保姆，把所有的責任都攬到自己身上之後，然後犯下這種不可饒恕的低級錯誤。無疑是啪啪啪的響亮自打臉。
強行把一個有風險的服務（任何程序都有bug）塞給用戶的時候，沒有給用戶知情權和選擇權。這種做法和GFW沒有什麼差別。
阿里雲的一百倍賠償其實是個笑話。賠償故障時間的100倍，是在宣傳說自己的可用性有99%嗎？那作為用戶我寧願多花點錢買好一點的服務。
手寫道歉信和負荊請罪就是轉移注意力，再次拿用戶當小白

希望阿里雲能克服困難，不斷完善，不斷進步。我想提的幾個建議：

如果真的是一行代碼引起的bug，那麼需要建立code review的流程，工程師要養成code review的習慣
發布流程要腳本化。回滾過程也要腳本化。隨便挑一個版本號，能夠做到快速發布和回滾。
建立灰度發布的機制，自己先dog food，再從小範圍起逐漸推廣，直至全網發布。

太能洗，連阿里可以改人家文件都有理由。

我的雲盾出了問題不好意思

所以我決定給你雲盾服務作為賠償

不知道我有沒有理解錯

道哥是牛逼人物，我一直是心存敬畏的。但是說實話看了這篇文章之後心裡很難受。難受不在於我受害了，而在於看到這樣一位牛人，居然領導這樣一件錯誤的產品，還犯下這樣一起愚蠢的錯誤，然後寫出這樣一篇令人氣憤的東西。我相信這是領導要求的PR作品，而非出自道哥本心。

我真的心疼道哥啊。

這樣一篇文章，開頭大段文字就是陳述了一個錯誤邏輯（網路安全情況複雜——我們有相關安全技術——我們強制用戶用我們的技術），中間渲染情懷，末尾給了一些令人氣憤的解決方案。從頭到尾都白寫了。

只回答題主的問題2吧。

所以我今天做出了以下決策：

1.對於本次故障受到影響的客戶，我們會贈予一批雲盾付費產品，包括：彈性安全網路、態勢感知、安騎士雲託管。我們會在近期擬定方案並開通服務，客戶也可以選擇不使用。

既然知道用戶可能擔心而不使用，那還提供幹啥？

如果是真的希望用戶對你們的產品的安全性不擔心，這時候唯一的出路是選擇贈送或優惠提供公認可信的第三方安全服務。

AWS等雲方案不強制提供終端內安全服務是有原因的。賺錢以外的原因。

2.安騎士將儘快提供方便快捷的一鍵關閉功能。

這個服務不是Opt-In的我已經大吃一驚，這話的意思是Opt-Out也是個Vaporware。就這樣的安全設計讓用戶怎麼放心？我如果此時相信你們提供的一鍵關閉功能我就是傻逼。我會要求提供Opt-In。

3.我們會給受影響的客戶寫一封手寫的道歉信。

……

一句話評論：手寫道歉信是用來騙傻逼的。用身體的辛苦來代替策略和商譽的損失，是一種逃避責任的做法。這個方法用來對付持股人可以，對付你的客戶…如果我是客戶我看到這樣一封信我會感到受了侮辱。

4.對於影響較大的客戶，我們會即刻出發登門拜訪負荊請罪，直面你的怒火和建議。

別。麻煩。趕緊把Opt-In做出來。這和手寫道歉信一樣，如果客戶找到你了，你道歉是負責的。你主動去道歉，是一種逃避責任，是不去做你該做的事。

我寧可看到道哥寫篇文章說最近忙、工程管理上做出了什麼什麼改進、為了解決用戶的後顧之憂免費贈送Near-line backup之類的東西。

客觀地說，這篇文章如果作為官方回應，則個人情感成分太多，事實分析及改進措施不足。

文中把事故原因歸結到某工程師的粗心大意，這是不夠深入透徹的。作為一個程序員，寫錯一行代碼是再正常不過的事情了，要能夠造成這麼大的影響，那麼在流程和工具上必然是有很大不足的。而在這方面文中有點一筆帶過了，並不透明。例如：

為什麼code review沒有阻止工程師的粗心大意？
為什麼自動化測試沒有找到這個bug？
上了生產線之後為什麼不能立刻回滾？
如何改進？

文中寫了很多為什麼要默認opt in雲盾功能，這個倒是見仁見智的。我也相信做這個決定的本意是好的，但這其實和事故本身沒多大關係。

另外，賠償裡面並沒有說到直接退款這一條，這可能也是中國特色吧。一般國際上的雲服務，基本就講個SLA，一個時間周期內達到幾個9的availability，沒達到就賠錢啊。

為什麼之前阿里想把安全全部自己搞，一方面是對傳統安全廠商的產品功能、響應反饋不信任，另一方面是花大價錢挖來了一幫大牛，覺得自己搞出的服務nb，想自己賺錢了。不過正應了那句話，B2B和B2C還真不是同一種玩法。

比如這次事件，阿里說補償故障時間的百倍時間，這相當於是用金錢補償可用性和隱私性遭受的破壞，但問題是有真正業務的客戶關心的不是錢，而是安全。畢竟阿里在拉的政務雲和農商行並不缺錢，缺的是對雲的信任，這一搞反而有點弄巧成拙。

解決方法是什麼？很簡單，理清權利和義務，阿里雲是CSP，提供雲計算資源，安全雖然可以是免費，但不可以是免責的。如果你擔不了責，自然有公司能擔。amazon其實已經很成熟了，不妨參考一下他們的在線商店，裡面有不少安全產品。

其實阿里這件事情，對第三方網路安全廠商是利好。原因有兩點：
1 主機安全對用戶的干擾過大，網路安全（尤其旁路部署）相對來說更好一些
2 用戶的信任度，應該將雲業務（計算、存儲和網路）與安全分離，這也是企業it系統運維目前的思路，安全由專業的第三方安全廠商提供解決方案或安全產品，CSP只需要提供在線商店和集成支持即可。這樣安全由安全廠商背書，無論是對用戶還是對CSP都更容易接受。

事實上，我也看到阿里在安全這塊也在變得越來越開放，這是件好事。希望能在雲計算這個生態鏈中各方都收益。

道哥很久不寫文章，文筆功力下降不少。所以寫作這個東西，還是要練。
當然可以說是秘書代筆。

下午提問的時候草草寫了幾個自己關注的方面，傍晚自己梳理了下想法，這裡自己回答自己的提問，沒有任何攻擊誰的想法，對與不對權當開展一些探討

1 經過這麼些年一些公司對大眾的免費、情懷的轟炸，現在很多人對這些都產生了免疫和反感，所以我覺的這篇文章從標題到內容挺失敗的，客戶不需要你心疼，而是拿出實際的解決方法，拿出有誠意的賠償方案！在出了問題的時候講情懷只能引起客戶和旁觀用戶的反感！

2 文中提到的解決對策，其中有幾點:贈與一批雲盾付費產品,和給受影響的客戶寫一封手寫的道歉信；實在讓人無語；一封手寫的道歉信能表明什麼誠意？雲盾產品出的問題，再送你一批雲盾的付費產品免費用，問題是客戶關注的是自身在雲主機上跑的業務，你就是送再多的安全產品也不是用戶的關注點啊，如果說免費將雲主機內存和CPU升級，這或許用戶更好接受一些！更何況安全產品出了安全問題，我再送你一批安全產品，有了這次的經驗教訓，誰用心裡不犯個嘀咕啊

3 倒是文中「對於影響較大的客戶，我們會即刻出發登門拜訪負荊請罪，直面你的怒火和建議」，這點我從商業角度會有效果；因為這意味著不會出一個普遍的公開賠償方案，而是直面重要的大客戶怎麼賠償咱們私下談，至於中小客戶，那就不是關注重點了

4 傳言阿里有公關，的確在網上很少能看見此事的更多報道，但更讓我感覺不可思議的是，平常關注的FreeBuf、91ri等，平常一有安全事件立馬報道，還不斷跟進，比如剛剛還看到freebuf報道說國內的華為、聯想等手機被預裝間諜應用的的消息；如果這次事件不是發生在阿里雲，而是諸如symantec客戶端等傳統安全廠商客戶端產品由於升級導致客戶電腦發生故障，估計各大媒體早就報道成風；結果相反，FreeBuf、91ri一字未提，就當沒有發生過一樣，除了可能有公關之外，感覺也有可能這是互聯網安全同業小圈子之間的互相包容；

5 互聯網安全這幾年很火，而且陸陸續續的確出了一些讓人耳目一新方案和思路，例如烏雲的安全眾測、知道創宇的鐘馗之眼等等，當時了解之後真是有一種讓人拍案叫絕的感覺。但是，現在慢慢有一種風氣，大有一種傳統安全行業解決不了安全的問題，只有互聯網安全才有希望；事實上，不論傳統安全還是互聯網安全，應該是不同解決思路的互補，沒有絕對的優劣，本質都是要解決客戶安全的問題，同樣，不管你是互聯網安全還是傳統安全，產品自身也都會面臨安全的風險；像這次阿里雲的問題，從公布的信息來看，應該是程序變更測試和發布過程疏忽導致的問題，應用系統安全開發生命周期的模型安全行業自02年就提出來，哪個安全行業的從業人員不了解一點SDLC？用戶網站一出問題，都會說幾句要求用戶開發管理應當遵循應用安全開發生命周期管理，問題是說起來簡單做起來難，如果阿里雲這麼技術雄厚、資金充足的公司都難以做好開發的安全測試與變更管控，其他公司估計更難以控制了

6 伺服器上部署agent也聽說過不少，例如zabbix(雖然是網路監控，但也可以擴展一些安全功能)、tsm等等，騰訊好像也有一套自己的內部伺服器安全Agent叫什麼洋蔥來著，但真的是第一次聽說本機Agent執行Web掃描，web掃描本身就會耗費不少伺服器資源，印象中客戶請安全公司做掃描之前，安全公司都是列出一堆掃描風險須知、應急處置措施等等，這種本機agent掃描，並且從相關網站鏈接上看，不敢說全部，至少大部分用戶之前壓根不知道雲主機上的一個進程還在對自己的系統執行web安全掃描，這種思路是好是壞我覺的可以探討，但這種可能會影響用戶業務，或者讓用戶自身產生困惑的舉動(用戶如果分析自己的web伺服器日誌，就能看到伺服器自己對自己在進行攻擊)的行為，不應該主動告知用戶了解嗎？而且大部分應用安全掃描軟體最起碼要讓用戶知道開啟了哪些掃描策略，啟用幾個掃描進程，爬蟲最大爬取深度，哪些區域不要進行掃描等等以減低掃描風險，現在倒好，用戶完全不知道，如果這是一款PC上的軟體或企業內網的伺服器安全產品的行為，簡直是不敢想像的，從這個角度，我覺的雲盾的web掃描作為一種安全思路可以探討，但默認開啟，沒有向用戶告知風險、用戶自身無法精細化控制這種掃描行為，是一種錯誤的思路，或者說壓根就沒有顧忌到客戶感受的思路；

UCloud當初在這方面的抉擇時，曾有過激烈的討論，最終還是決定放棄使用agent，主要還是為用戶的安全。對於企業級用戶來說，其實他們最關注的就是安全沒有第二了。阿里雲的問題不在於用了agent，而是沒給用戶選擇權。

我第一次聽說這種事故可以通過寫信和登門拜訪解決。我看完以後，很感動，真是活到老學到老。

強制使用，規則不明，出事補點情懷。客戶敢放心用？只會認為雲服務確實不可靠。

道哥的這篇危機時刻，我只心疼我們的客戶 - 道哥的黑板報 - 知乎專欄我看了遍，滿滿的都是我們認為用戶希望如何如何，我們認為你很在乎安全服務，我們認為我們的保姆模式就是為你們好，我們認為我們的產品全家桶都是正確且有益的這種一隅偏見，根本就不像一個成熟的產品經理人該有的態度，卻像極了我國那獨有的「為人民服務」的高尚情懷。

道哥還是刺的時候，是個技術人，在那幾年算得上是業內翹楚的人物。但自從刺成了道哥，開了黑板報，味道完全不一樣了。當年去aqb時躊躇滿志的「這是公司的時代，創業者才是時代弄潮兒」，到aqb瀕臨ICU時倒戈回阿里時的「互聯網行業里有個很不好的風氣就是鼓吹創業」，我們看到的是一個投機分子為自己自圓其說樹立高大理由的道哥，而不是那個熱血青年的刺了。

所以，道哥的黑板報上的軟文就不必信了，而這塊黑板報也像極了我國特色的宣傳。

我覺得默認啟用雲盾這種激進的「保姆模式」不太可能是工程師主推甚至是內心認可的，但同在一條船上，只能做好自己了，所謂「常在湖邊走，哪能不濕鞋」。

1 區別就是360面對小白用戶，阿里雲面對比較專業的用戶（所以真的有必要那麼主動當「保姆」嗎？）
2 得問當事人，或許得先計算損失要現金賠償，時間賠償對許多企業反而無所謂）
3 所以當保姆不好嘛，無限責任啊！當然，阿里的技術和管理比起咱大陸大部分公司還是很有優勢的，但折騰這幾次後普通人對阿里的信心大概會比其他大牌差許多。

我特別不喜歡這種自己產品出了問題以後作為道歉補償的還是這個產品的做法。

就好比我去餐廳吃飯老闆給我上了一坨屎我投訴後他說不好意思我再給您補一坨。

不過我還是挺喜歡道哥的。

呵呵，不好意思，我們不是傻×。

他心疼客戶，我心疼那個工程師。

這麼嚴重的Bug能上生產環境，應該反思的團隊和流程太多了。把原因歸結於某名工程師的一行代碼？那這肯定不會是最後一次。

當時我正在用，體驗就是你運行哪個命令，哪個命令就被刪除，連ssh，scp都被幹掉了。
第一反應大驚失色，GFW已經在阿里雲內置啦，他咋知道我在從google拉代碼呢？

阿里雲 100 倍賠償已經到賬各位收到了嗎？

來自：https://www.v2ex.com/t/218169#reply73

還是用azure吧

任何時刻，我只心疼我自己