工程師和應(yīng)用程序組的人經(jīng)常拿著精確的、經(jīng)過仔細(xì)審查的存儲(chǔ)需求找到我們。他們已經(jīng)研究過工作負(fù)荷、對增長情況的推測以及他們認(rèn)為應(yīng)用程序?qū)?huì)需要的容量需求,而且他們已經(jīng)匯編了各種細(xì)節(jié)以及認(rèn)為我們會(huì)問到的許多問題的答案。他們做了很多功課,而更為重要的,他們已經(jīng)展示了他們的工作。而有些時(shí)候,會(huì)有一批一批的人找到我們,但除了知道他們的應(yīng)用程序需要存儲(chǔ)之外,他們對所需的存儲(chǔ)基本上沒什么了解。他們無法完全明確地告知需要多少存儲(chǔ)以及什么類型的存儲(chǔ),而且許多情況下基本不了解存儲(chǔ),也不知存儲(chǔ)是如何工作的。他們最初的需求是模糊的,但他們急著找到我們,學(xué)習(xí)并了解如何設(shè)計(jì)和定制一定大小的存儲(chǔ)解決方案。
在我以前的一個(gè)公司,我是審查購買硬件和軟件需求的委員會(huì)的成員。這個(gè)委員會(huì)包括個(gè)懂技術(shù)的公司的共同創(chuàng)立者、幾個(gè)高管,以及一些各種基礎(chǔ)架構(gòu)核心領(lǐng)或的技術(shù)專家。這個(gè)委員會(huì)相當(dāng)于一個(gè)詳盡和系統(tǒng)的檢查點(diǎn),工程師的硬件和軟件需求都要提交給該委員會(huì)進(jìn)行審查,審查時(shí)會(huì)詢問一些問題,并且公開地對需求進(jìn)行行討論,有時(shí)候會(huì)批準(zhǔn)某個(gè)需求。但總的來說,最常見的結(jié)果是需求被否決,因?yàn)樾枨笕鄙龠m當(dāng)?shù)臄?shù)據(jù)支持。
在涉及存儲(chǔ)的需求時(shí),很多日時(shí)候工程師并不完全理解應(yīng)用對存儲(chǔ)的需求,而且對需求什么,或者為什么需要一個(gè)托管的存儲(chǔ)系統(tǒng)而不是簡單地使用服務(wù)器的磁盤并沒有一個(gè)清晰的定義。有的時(shí)候,他們并沒有一個(gè)合理的容量計(jì)劃,或者存儲(chǔ)容量如何隨著時(shí)間的推移而伸縮也沒有一個(gè)模型。幾乎總是不怎么注意災(zāi)難恢復(fù)或數(shù)據(jù)復(fù)制策略,或者對業(yè)務(wù)連續(xù)性是個(gè)什么樣子也沒有一個(gè)藍(lán)圖?;旧?,工程師或者要求太多,或者要求太少,不管怎么說,對自己的需求,都沒有適當(dāng)?shù)淖C據(jù)進(jìn)行支持。
委員會(huì)要求,在審核過程的最后,工程師對自己要求的每一件硬件、軟件、存儲(chǔ)都要有合理的理由。這種要求的結(jié)果,確保了每一項(xiàng)采購都是經(jīng)過仔細(xì)考慮的,從而是必要的,并且是由數(shù)據(jù)所支持的,這些數(shù)據(jù)精確描述了存儲(chǔ)需求以及解決方案背后的合理性。我將這種委員會(huì)精神帶到了以后工作的公司中,用這種辦法確保所有的存儲(chǔ)采購都是數(shù)據(jù)驅(qū)動(dòng)的,有著有效的業(yè)務(wù)連續(xù)性規(guī)劃,以及合適的容量規(guī)劃。
不論你是工程師提交存儲(chǔ)需求,還是存儲(chǔ)專家審查工程師提交的存儲(chǔ)需求,都要記住下面的問題及討論要點(diǎn):
● 應(yīng)用是什么?
● 應(yīng)用位于哪里?
● 存儲(chǔ)的是什么類型的數(shù)據(jù)?
● 需要共享存儲(chǔ)嗎?
● 是否需要特殊的訪問協(xié)議?
● 典型的文件大小是多少?
● 數(shù)據(jù)是壓縮的嗎?
● 如何描述工作負(fù)荷
● 需要批處理操作嗎?
● 工作負(fù)荷是大部分用于讀,還是大部分用于寫,或者兩者都有?工作負(fù)荷是大部分順序,還是大部分隨機(jī),或者兩者都有??快照是怎么安排的?
● 快照是應(yīng)用一致性,還是崩潰一致性,或非一致性的?
● 存儲(chǔ)容量在6個(gè)月、12個(gè)月、18個(gè)月的計(jì)劃是什么?
● 工作負(fù)荷在6個(gè)月、12個(gè)月、18個(gè)月的計(jì)劃是什么
● 復(fù)制策略是什么?
● 業(yè)務(wù)連續(xù)性規(guī)劃是什么?
● 可用性需求是什么?
● 備份的頻度是多少?
● 備份保持計(jì)劃是什么樣的
● 歸檔策略是什么?
● 符合性需求是什么
●網(wǎng)站建設(shè)加密需求是什么?
本文地址:http://m.blackside-inc.com//article/3341.html