记录阿里巴巴QA架构组成长点滴。2008年关键词为效率,技术,影响力!QA/测试架构师定义:开发和设计测试框架测试库;纵横全局的考虑产品的功能,设计复杂的测试系统;负责研发某一项特定的测试技术;为公司考虑如何提高测试效率。领导公司测试技术的发展和测试策略上的方向,关注整个公司的测试部门的问题,前瞻性的考虑未来的版本的测试策略和技术。测试架构师计划/设计测试平台,关注着产品的测试过程,提供咨询服务,影响到公司内的测试机构测试社区,以及开发机构等,对产品各个方面施加深远而正确的影响,最终提高整体软件质量。

容量规划沙龙4原则以及个人理解

上一篇 / 下一篇  2008-06-15 01:08:29 / 个人分类:性能测试与容量规划


 个人觉得今天容量规划沙龙最核心内容即4原则

1)经过良好调优的系统才容量规划
2)可扩展性好的系统才做容量规划
3)人人有容量规划意识。执行T-shirt sizing是一个巨大进步
4) 最关键的事情是测量

其他的还有
5) 用真实的产品数据做容量规划
6) 特别区分对待的容量规划场景
7) 追求响应时间与成本间平衡

  欢迎其他朋友补充。

以上的点说得都很实在。
根据自己的实践做一个发散说明

1)容量规划有一个难点:在系统扩容和调优之间取得平衡。
就是停止调优的标准是什么?

目前我是根据经验值判断特定的硬件、配置参数支撑一定的访问模式、数据量、并发数、吞吐率且满足响应时间等SLA指标。 另外,检查系统不存在core dump或者大量连接超时,日志无异常等。
有较大的主观性。

2) 系统扩展性良好。

根据了解,SAP 没有结合性能测试做系统的可扩展性判断。呵呵,也许SAP架构很多年稳定了,没有必要做这个事情。

我们实践中,会设置多个场景执行性能测试或者了解系统架构判断。
如是否采用多线程技术?集群是否采用session技术?

建模采用的数学模型一般有很多的假设,就是公式成立有很多前提条件。性能测试需要判断结果是否违背了假设。同样预测时,也需要判断是否背离假设

3) 人人容量规划意识

从阿里巴巴的角度看,应该是从架构设计权衡系统扩展性、开发加入代码性能探针、性能测试判断是否该停止调优、运维部门长期跟踪反馈性能监控数据以及采购规划、数据仓库平台采集PV、运营部门预测下一年业务增长速度等多个环节。

据目前看,要走的路还很长。
对阿里巴巴而言,在网站购买的大量便宜的PC server背景下,容量规划的收益与成本不是足够一目了然,以及资源紧缺是最头大的问题。

与前同事聊天,目前广东电信研究院的容量规划的驱动力不足是当下最头痛的事情。


4) 第四个观点:测量是最关键的。

 
这个论点放到阿里巴巴。我个人有不同的看法。
测量是很重要。个人认为借助测量到的数据,如何构造一个合理的容量模型、如何校准模型负荷实际情况更关键,否则预测的偏差过大导致没有太多的参考价值。

另外,目前的商业工具或者开源工具都存一些不足,如何对工具做二次开发完善,也是一件很有挑战性的工作

 

 


TAG: 容量规划 扩容 调优 扩展性 测量 性能测试与容量规划

最后一公里 引用 删除 rcpp   /   2008-06-16 11:54:47
根据晚上与他的交谈得出以上结论
最后一公里 引用 删除 rcpp   /   2008-06-16 11:54:10
1.这位师先生是位工程师,不是很专业的讲师
2.他所在的部门是提供应用解决方案的,容量规划只是他们工作的一小部分
3.SAP的容量规划建立在自有的经验模型基础之上,工具是其中很重要的一环
4.他所做的容量规划工作主要是部门配合协作来获取有效性能数据,然后模型工具解决问题;所以必须具备很多先决条件
5.SAP有自己的ABAP,.我想大概他们的编译器和运行环境已经是经过多代进化得到成熟性能模型了
6.他也写代码,不过是ABAP代码,所以更强调业务而不是代码本身;所以他也说,他们工程师也是看谁对业务的理解更透彻,而不是编码本身的水平有多高;事实上像SAP这样有数十年积累的公司,规范应该早已弱化了人的能力差异表现了
 

评分:0

我来说两句

日历

« 2024-03-25  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 153144
  • 日志数: 163
  • 文件数: 1
  • 建立时间: 2008-02-26
  • 更新时间: 2008-12-10

RSS订阅

Open Toolbar