工程师和应用程序组的人经常拿着精确的、经过仔细审查的存储需求找到我们。他们已经研究过工作负荷、对增长情况的推测以及他们认为应用程序将会需要的容量需求，而且他们已经汇编了各种细节以及认为我们会问到的许多问题的答案。他们做了很多功课，而更为重要的，他们已经展示了他们的工作。而有些时候，会有一批一批的人找到我们，但除了知道他们的应用程序需要存储之外，他们对所需的存储基本上没什么了解。他们无法完全明确地告知需要多少存储以及什么类型的存储，而且许多情况下基本不了解存储，也不知存储是如何工作的。他们最初的需求是模糊的，但他们急着找到我们，学习并了解如何设计和定制一定大小的存储解决方案。
在我以前的一个公司，我是审查购买硬件和软件需求的委员会的成员。这个委员会包括个懂技术的公司的共同创立者、几个高管，以及一些各种基础架构核心领或的技术专家。这个委员会相当于一个详尽和系统的检查点，工程师的硬件和软件需求都要提交给该委员会进行审查，审查时会询问一些问题，并且公开地对需求进行行讨论，有时候会批准某个需求。但总的来说，最常见的结果是需求被否决，因为需求缺少适当的数据支持。
在涉及存储的需求时，很多日时候工程师并不完全理解应用对存储的需求，而且对需求什么，或者为什么需要一个托管的存储系统而不是简单地使用服务器的磁盘并没有一个清晰的定义。有的时候，他们并没有一个合理的容量计划，或者存储容量如何随着时间的推移而伸缩也没有一个模型。几乎总是不怎么注意灾难恢复或数据复制策略，或者对业务连续性是个什么样子也没有一个蓝图。基本上，工程师或者要求太多，或者要求太少，不管怎么说，对自己的需求，都没有适当的证据进行支持。
委员会要求，在审核过程的最后，工程师对自己要求的每一件硬件、软件、存储都要有合理的理由。这种要求的结果，确保了每一项采购都是经过仔细考虑的，从而是必要的，并且是由数据所支持的，这些数据精确描述了存储需求以及解决方案背后的合理性。我将这种委员会精神带到了以后工作的公司中，用这种办法确保所有的存储采购都是数据驱动的，有着有效的业务连续性规划，以及合适的容量规划。
不论你是工程师提交存储需求，还是存储专家审查工程师提交的存储需求，都要记住下面的问题及讨论要点:
● 应用是什么?
● 应用位于哪里?
● 存储的是什么类型的数据?
● 需要共享存储吗?
● 是否需要特殊的访问协议?
● 典型的文件大小是多少?
● 数据是压缩的吗?
● 如何描述工作负荷
● 需要批处理操作吗?
● 工作负荷是大部分用于读，还是大部分用于写，或者两者都有?工作负荷是大部分顺序，还是大部分随机，或者两者都有??快照是怎么安排的?
● 快照是应用一致性，还是崩溃一致性，或非一致性的?
● 存储容量在6个月、12个月、18个月的计划是什么?
● 工作负荷在6个月、12个月、18个月的计划是什么
● 复制策略是什么?
● 业务连续性规划是什么?
● 可用性需求是什么?
● 备份的频度是多少?
● 备份保持计划是什么样的
● 归档策略是什么?
● 符合性需求是什么
●网站建设加密需求是什么?
本文地址：//www.gogoparty.cc//article/3341.html
