容量规划问题列表，期待专家深入交流

liangjz

沙龙交流前自己准备的容量规划方面的问题列表，呵呵，也期待业界这方面的专家指点。

1 瓶颈资源到达75%以后，容量预测偏差难以衡量，预测准确率陡降。
现有容量规划软件包容这种情况？或者如何做能提升这个区域的预测准确度

2 SAP 的容量规划工具可容忍偏差范围多大？
3 SAP 内部有自己的监控软件么？包括应用级别的监控。

现在的软件更多针对应用服务器、web server和os层面的监控，但对应用本身的监控是缺乏的

假如没有这些细粒度的监控数据，SAP 如何更好为用户行为建模？

4 SAP 容量规划软件建模算法是什么？是否为排队网络？

可以调整客户到达分布与服务时间分布等参数？

5 BELL实验室网络测试发现，用长相关或自相似随机模型比排队网络模型更符合web 网站客户到达分布? SAP 容量规划软件针对更合适的模型做调整么？

6 SAP 容量规划软件内部有what-if 假设分析么？直接支持针对内存或者硬盘的what-if分析？

7 SAP 针对跨机型的容量规划如何做?

尤其是sun公司不参加TPCC评估后的机型 。

8 如何做容量规划效果的反馈

9 做容量规划的团队组员有几个，都是怎么样的专业背景（数学？计算机?)

10 开源容量建模工具要求手工采集非常多数据，必然引入较大的误差？对于这种状况，有何建议


   经过和SAP 工程师交流。负责容量规划的工程师和负责测试的不属于同一个部门，容量规划工程师面对咨询公司，提供硬件建议。

  国内的SAP工程师更多是规划软件的应用者。SAP 软件相对成熟，且部署的机型相对单一。目前容量规划结果满足需求。
  
  SAP有商业逻辑的监控。SAP容量规划软件采集生产系统数据建模，在web页面上输入参数，降低建模门槛。目前SAP容量规划软件建模依赖经验值，而非各种复杂的数学模型。当下没有必要研究开源建模工具。

  SAP软件用内部开发的语言开发的。有很好的扩展性。
   
  由于上述背景，我自己碰到的一些问题就没有很深入交流。

  目前阿里巴巴需要自己建立模型，并需要长期校准模型，另外由于需求、应用的多变，容量规划的门槛依然需要具备较高的数学建模与计算机性能分析方面的背景。

shen1936

顶起 关注！

liangjz

偶蛮想有更多的同行一起探讨下这些话题 ：）

liangjz

关于容量规划，阿里巴巴集团内也讨论很热烈，哈哈，偶想把它告知更多的业界朋友
梁指偶。


wcj: 1.这位师先生是位工程师，不是很专业的讲师
2.他所在的部门是提供应用解决方案的，容量规划只是他们工作的一小部分
3.SAP的容量规划建立在自有的经验模型基础之上，工具是其中很重要的一环
4.他所做的容量规划工作主要是部门配合协作来获取有效性能数据，然后模型工具解决问题；所以必须具备很多先决条件
5.SAP有自己的ABAP，.我想大概他们的编译器和运行环境已经是经过多代进化得到成熟性能模型了
6.他也写代码，不过是ABAP代码，所以更强调业务而不是代码本身；所以他也说，他们工程师也是看谁对业务的理解更透彻，而不是编码本身的水平有多高；事实上像SAP这样有数十年积累的公司，规范应该早已弱化了人的能力差异表现了
wcj: 根据晚上与他的交谈得出以上结论
郭芙: 如果是这样，他们的容量规划其实是他们整体工作环节中一个必须的但是对执行者来说是easy的一个过程，公司的整体过程和数据模型已经非常规范了。不像我们，很多东西还在探索和建设中。
wcj: bingo
梁剑钊: 是这样的
郭芙: 每当他提到他们的一些算法时，他就一带而过，但是这个算法的建立方法对我们才是最有用的。
林彦: 有用的东西需要花钱去买的
梁剑钊: 经过和SAP 工程师交流。负责容量规划的工程师和负责测试的不属于同一个部门，容量规划工程师面对咨询公司，提供硬件建议。

  国内的SAP工程师更多是规划软件的应用者。SAP 软件相对成熟，且部署的机型相对单一。目前容量规划结果满足需求。
  
  SAP有商业逻辑的监控。SAP容量规划软件采集生产系统数据建模，在web页面上输入参数，降低建模门槛。目前SAP容量规划软件建模依赖经验值，而非各种复杂的数学模型。当下没有必要研究开源建模工具。

  SAP软件用内部开发的语言开发的。有很好的扩展性。
   

林彦: 而不是白送的
wcj: 事实上我们的网站目前很难把容量规划作为重要环节来看待；产品开发更倾向“软件快速消费品”，真要向他们学习也很难
梁剑钊: 呵呵，中国区的SAP工程师不清楚内部算法的。更多是应用
梁剑钊: SAP产品相对成熟，即使经验估算，误差也不会很大
wcj: 是的，ABAP的存在使得中国区的工程师可以也仅可以更多的关注业务模型
郭芙: 其实我们是重视的，但是我们还没有形成很好的模式来操作。完全是凭个人能力。
wcj: 并非不重视
梁剑钊: 目前是这样的。需要我们有很好的计算机性能分析和数学背景
梁剑钊: 另外，SAP的容量规划过程基本上不能移植到阿里巴巴
wcj: 是我们面向的网站开发，更偏重于快速应对市场，而且没有SAP的强势应用条件，“不用我的，没有好的给你用”
wcj: 我们就没有时间去细细的研究。而且这种研究短期内看不到收益
梁剑钊: 快速变化也导致模型也需要快速更新
郭芙: 还要具备商业上的判断。
wcj: SA如此重要，也体现了一件事，宁可冗余服务器，也比做容量规划来得效益快得多，而且眼下就是这么做的
梁剑钊: 预测本身就要考虑业务变更，应用，硬件，数据等非常多的参数。
王晓聪: 模型的更新的成本就大了，除非这个模型覆盖度足够大
郭芙: yahoo也有专业的容量规划部门的。
wcj: 缺乏长期数据积累也是一个问题
wcj: 容量规划在国外已经是一个成熟课题
wcj: 但在国内处处碰壁
hyf: 其实我们应从容量测试角度考虑，规划是dba的职责吧～
wcj: 简单一句话就是投入产出比，回报周期的问题
梁剑钊: 不局限于
郭芙: yahoo的容量规划连电力的规划都考虑在内的，我们差距太大了。
wcj: 容量测试是性能测试的一种类型，对于容量规划，还只是前提条件而已
mikeyond: 我觉得涉及到应用服务器,数据库和存储吧,不单是DBA的事情
梁剑钊: 我们正打算和运维合作。他们需要我们提供性能测试的数据
梁剑钊: 对于容量规划领域的知识，我们还是有些积累的。  
wcj: SAP采用的是经验模型，利用数据积累获得模型建立的依据
hyf: 有些时候容量规划不仅仅是性能，还有功能性的
wcj: 我们怎么做？也学吗？
梁剑钊: 哈哈,在我的蓝图里面涉及的部门架构设计权衡系统扩展性、开发加入代码性能探针、性能测试判断是否该停止调优、运维部门长期跟踪反馈性能监控数据以及采购规划、数据仓库平台采集PV、运营部门预测下一年业务增长速度等多个环节。

wcj: 功能性？怎么理解？
郭芙: by the way，各位能否在群名片中加上自己的中文名啊？我都不知道谁是谁，liangjianzhao还能拼得出来。
梁剑钊: 作容量规划本身要求软件功能OK，性能也OK，可扩展性也OK 〉。。。
hyf: 数据库容量，build数据，没规划好，直接会影响功能，我是指这个意思
hyf: 举个例子～
wcj: 这不是包含在容量规划中的，只是结果
梁剑钊: 数据库这个层面的规划，我们的DBA no ploblem
林彦: 性能最终结果也是功能无法实现
wcj: 要说影响面，容量规划有问题，可能导致的太多了，业务故障，性能故障，安全故障……
林彦: 慢慢来，一下子太多是实现不了的
hyf: 规划我觉得还不是我们的职责，呵呵，我们的职责在于测出容量规划的问题
wcj: 容量规划本身可以是依赖沟通协调的数学问题
wcj: 不是任何一个个人或部门能够做的
wcj: 在SAP也是多部门协同的一个任务
王晓聪: 如果仅局限于测试出规划的问题，就蜕变成性能测试了。
宝驹: 可以把我们这里碰到的问题例举一些，然后讨论下怎么解决
宝驹: 上面讲了这么多，好像太泛了
wcj: 1.要做容量规划，需要哪些部门哪些人配合？
2.配合的人需要做些什么？输出是什么？
3.QA可以做什么？
梁剑钊: 问题有：http://bbs.51testing.com/thread-117555-1-1.html
wcj: 我们需要做的就是问题3了
梁剑钊: 大家可以参考下
梁剑钊: 这个容量规划设计的蓝图我有发给B2B的同学勒  
wcj: 嗯，每个都可以做研究课题的
宝驹: 嗯，好，QA可以做什么，可不可以再细化一些，这个问题有点太大了
wcj: 就是梁在帖子里写的那些
宝驹: 正好梁最近有个性能测试的沙龙吧，哈哈

henry__gz

SAP公司的容量规划做法简洁明了，方便使用，可以作为直接参考应用于电信的容量规划落地。例如业务压力的单位制定、跨硬件平台的推算公式、标准化的扩容处理技术文档等。
本次交流的简要总结：

1、主要活动是SAP公司工程师对SAP产品容量规划方法的介绍（见附件），SAP产品有较稳定的架构和较深厚的技术积累，故可以较好实现容量规划，不见得可直接应用于电信软件（架构繁杂、开发/测试合作不力）
2、演讲的SAP工程师不见得有多深的技术功底，但依靠公司的容量规划平台及知识管理，可以大体清晰地说出总体过程和原则，过程见附件第18~62页，可分为对新建系统、对生产系统的两种处理过程；
3、SAP工程师对容量规划的原则是：未经优化、不可扩展的系统不值得作容量规划，容量规划的最核心步骤是对系统的测量（业务负载、主机负载）
4、对新建系统，依赖quick-sizing平台输入若干变量，输入业务负载，得出平台无关的SAPS（SAP Application-Benchmark Performance Standard）指标值，再换算至各硬件平台的推荐配置；
5、对生产系统，有一系列的标准处理文档来处理软/硬件升级迁移、业务负载变化的情况（delta sizing, upgrade sizing, special system landscape），类似TQ的what-if功能，但更贴切真实生产系统的变化可能；

tacy_lee

这方面的东西每次都想做，但是一直觉得没有理论和数据支持，这个东西是个持续的东西，我的想法是先有这个意识：多关注这方面的内容，然后在平时工作中多收集数据

你们应该可以多对现有数据做充分挖掘，sap有他的特殊性，不知道yahoo他们怎么做的，可否介绍一下

liangjz

据说yahoo也有自己的容量规划部门，包括电力规划都有 。
呵呵，偶还没有和他们接触过。

改天找些渠道了解下