由思科/EMC/VMware/英特爾四方組建的VCE聯(lián)盟一直遵循著非常直觀的運(yùn)營思路：將各類硬件與軟件集中起來構(gòu)建成設(shè)備，并在對說明文檔及具體細(xì)節(jié)進(jìn)行深入測試之后以整體配置方案形式投放市場。沒錯(cuò)，VCE方面在電子郵件中明確表示“我們所交付的系統(tǒng)已經(jīng)作為整體經(jīng)過嚴(yán)格的工程調(diào)試、測試與認(rèn)證。”

VCE在技術(shù)支持方面同樣實(shí)力強(qiáng)大，神出鬼沒的系統(tǒng)管理員甚至能夠在某套管理控制臺上的某個(gè)指示燈由綠轉(zhuǎn)紅的一瞬間現(xiàn)身當(dāng)場并著手解決問題。

然而這樣的規(guī)劃并不總能實(shí)際起效，一家VCE客戶抱怨稱。該客戶曾購買了一套運(yùn)行有VCE Release Certification Matrix 4.07版本的vBlock設(shè)備。所謂Release Certification Matrix（簡稱RCM）已經(jīng)擁有二十年歷史，是VCE集硬件、軟件與說明文檔于一體的捆綁型產(chǎn)品方案。

在vBlock捆綁方案中包含有該軟件的2.2.2-17（SP2）版本以及EMC XtremIO陣列?？杀氖牵@套軟件中的一項(xiàng)漏洞讓用戶的vBlock飽受摧殘，并直接導(dǎo)致“我們的整套陣列陷入癱瘓。VCE/EMC方面花了六個(gè)多小時(shí)才使其重新上線（且處于版本降級狀態(tài)），而恢復(fù)全部功能又額外用掉了約八個(gè)小時(shí)。”

這家不愿透露名號的客戶在Reddit網(wǎng)站上公布了自己的遭遇，透露出一系列具體信息并同意我們將這段經(jīng)歷與大家分享。

“我認(rèn)為任何一家vBlock客戶都擁有同樣的怨言，即在RCM模式下進(jìn)行代碼發(fā)布時(shí)會(huì)在犧牲一定靈活性，”他們寫道。“有鑒于此，VCE方面所承諾的各組件‘順暢協(xié)作’口號無疑會(huì)在我們心中大打折扣。”

VCE迅速對此作出了回應(yīng)。在與我們的溝通當(dāng)中，該公司的一位發(fā)言人表示“當(dāng)新的組件/代碼被投放市場時(shí)，VCE會(huì)在接下來的四十五天內(nèi)對支持代碼進(jìn)行持續(xù)更新。”而這四十五天屬于斷檔期，RCM更新要在半年后“才有可能徹底取代vBlock發(fā)布時(shí)所配備的全部原有代碼”。

不過VCE一直在努力發(fā)布并支持安全性補(bǔ)丁，并承諾“在漏洞曝光的一到兩周之內(nèi)完成更新”。

但這位用戶的控訴重點(diǎn)并不在于這段斷檔期，而是對EMC的消極回應(yīng)表示不滿。因?yàn)閷Ψ奖硎?ldquo;該問題目前尚未被收錄入公共咨詢內(nèi)容當(dāng)中，且無法提供預(yù)計(jì)解決時(shí)間。”

由于缺乏相關(guān)信息，就連作為合作伙伴的VCE也很難有效解決這一難題。

“我對VCE的表現(xiàn)非常不滿，因?yàn)樗麄儗@項(xiàng)漏洞似乎一無所知。EMC至少明確知曉該問題的存在，但VCE呢？一問三不知。”這位用戶強(qiáng)調(diào)稱。

“直到現(xiàn)在我也沒能就這個(gè)問題得到確切答復(fù)。其實(shí)在使用過程中發(fā)現(xiàn)一些供應(yīng)商也沒意識到的漏洞并不是無法接受，但在溝通過程中發(fā)現(xiàn)對方早已知曉這種狀況、卻依然將其正常推出就很難讓人信服了，”這位用戶寫道，并總結(jié)稱“我希望這能讓他們得到一些教訓(xùn)，并在未來的認(rèn)證流程中進(jìn)一步加強(qiáng)合作、避免此類問題再次發(fā)生。”

此次事件對于其它開箱即用堆棧供應(yīng)商也算是很好的借鑒，希望其它更新周期較長的參考架構(gòu)廠商或者用戶也能引以為戒、以更加審慎的態(tài)度對待自己的配置方案。