假设你是某公司的IT员工。你所在的公司面向中高端市场，有1000名左右的员工，有十二个分公司。你负责运行产品交易系统以及分布式的Windows原始信息库。你有大容量的SAN和文档服务器，有灾难恢复系统和原始信息库。
每个公司都有测试和改进的操作，大部分操作情况如下：
1）测试和改进是用来确保被大量生产之前，内部和外部软件应用、新的基础架构以及升级工作以假定状态正常运行。
2）为了执行步骤1，完成测试和改进过程，必须首先获得完整的当前实际数据，这些数据来自他们自身的生产系统。
3）为了执行步骤2，测试和改进过程非常复杂。这需要时间、计划，甚至需要祈祷运行过程中不出问题。应用软件通常会出问题，而数据库因此必然会停止运行；基础架构的专家旋转摇柄、按下按钮，数据库重新开始运行。
4）一旦完成了步骤2，事实上测试就可以开始了。通常，进行测试和改进需要增加附加数据设置（而这些设置在被采用的时候通常已经过时了）的复本以进行不同的测试。
现在我们来讨论刚才这些步骤中出现的低效问题。首先，产品系统最可能在数据库上端运行部分应用软件。你趋向于认为你的产品数据非常重要，因此你通常至少会创建两个数据复本。你趋向于将你的产品数据放在非常昂贵的，容量最大的，能耗很高的基础结构中。你在基础架构里创建数据，接着将这些数据存放其中。然后你会创建很多数据备份，将这些数据备份也存放在基础架构中。你可能有两个、三个、四个或者更多不同时间点或者相同时间点的相同数据复本。这意味着你存放这些数据的支出是只存放一份数据的二倍、三倍、四倍或更多倍，而这不仅仅是资金消耗的问题，也将导致能源、冷却系统消耗，追踪系统等等的消耗也随之提高。
当你创建测试复本时，你趋向于将这些复本创建之后也保存在产品系统中。有时你会删除这些数据，但有时这些数据会被存放很长时间。有时你甚至会完全忘记这些数据的存在。这些复本占据了很大空间，耗费了过多能量和人力。这些备份数据将会与目标导向的产品系统中其他数据一起被再次备份。这意味着在一次文件备份中，你可能会对23个相同的数据复本进行再次备份。如果你每周进行一次完整的数据备份，你将在以前23个相同数据备份的基础上继续创建新的数据备份。
事情已经变的很糟。不仅仅是数据复本众多而耗费了资金和人力，更严重的是众多分散的现实产品的数据――这些数据被存放在产品系统、测试系统、备份系统、灾难恢复系统中以及Iron Mountain的磁带中，这都会引发潜在安全性问题。
[1] [2] 下一页 |
