亲。求支招：如何构建高可用性健壮系统。

shenopkss 2012-02-01 07:13:44

去年6月到现在一直在开发一个项目，前后出了3个release版本。并已上线运行。
项目技术难度不大，但是业务复杂，但是由于项目牵涉到4个部门和多种平台技术(.Net/PHP/Java/Python)，各部门的沟通问题就不说了，最纠结在于多方连调测试，Bug查找，异常重试/恢复处理。
感慨，构建高性能高可用性健壮的系统确实不易。还望高手支招，谈谈实际开发中对于上述问题有什么解决方案。

关键词：项目管理异常处理日志技巧软件测试系统健壮性

...全文

174 13 打赏收藏转发到动态举报

写回复

用AI写文章

13 条回复

切换为时间正序

请发表友善的回复…

发表回复

shenopkss 2012-02-06

打赏
举报

[Quote=引用 11 楼 microtry 的回复:]

[/Quote]
感谢您的建议。谢谢。

shenopkss 2012-02-06

打赏
举报

[Quote=引用 7 楼 sp1234 的回复:]

[/Quote]
谢谢您的帮助，非常感谢。

缪军 2012-02-06

打赏
举报

换个说法,如果你在.net上实现了所有的业务,
那么,你们应该可以快速重建java版的程序,
而不需要程序员再写什么代码

所以,我经常说,OOAD给生产创造的价值远远大于OOPL

缪军 2012-02-06

打赏
举报

[Quote=引用楼主 shenopkss 的回复:]
[/Quote]
你们的开发方式和你们承接的项目相比,过于落后,
应该改变生产方式,用统一的开发工具,然后根据客户要求,生成或重建基于特定PL的应用

项目的大部分时间用于设计,而不是写代码,否则的话你们对客户需求变化的响应会很慢,成本也很难控制
如果客户不能给你们很高的开发费用,连挣钱都难

缪军 2012-02-06

打赏
举报

[Quote=引用 6 楼 sp1234 的回复:]
不要搞过度文档驱动式的开发
[/Quote]
过度不是"过多",而是不恰当地意思,也就是说,很多团队没有文档驱动开发的能力,
他们的文档在项目启动之后很快过期变质,所以他们的文档反而成为累赘;
TDD是在团队没有能力管理设计文档的前提下,提出的方案,
无论是ISO9000还是CMMI5,质量控制体系要求的都是文档驱动,当然还有一种叫法:行为驱动,但究其工作方式的实质也是通过统一描述的方式简化设计文档接口,使得设计需求的表述能够和客户达成高度的一致

以专业开发人员为伍 2012-02-04

打赏
举报

实际上你所列出的“关键词”，全部，我都是在一个开发习惯中去不经意地完成的。而不是靠学什么PMBOK之类的给建筑工地上的项目管理者写的悲催的文档来学到的。

软件开发工程管理，当然是敏捷的。因为软件开发过程不是民工级的工作过程，不是靠在时间上压榨一帮民工就能设计出产品软件的。

这需要克服一些看似很有“道理”的误区。例如有人说“UI无法自动测试”，这往往就是一种借口。假设要用silverlight最一款gis，我就可以舒服地坐在电脑桌前边拼着香茶，看着电脑屏幕上不断翻飞的测试页面，看着它如何自动展现地图、如何移动中心点、如何自动缩放、如何模拟用户改变鹰眼中的焦点、如何模拟用户在地图上某个具体的经纬度的地方去画一些路径、如何随机地组合某几个分层，等等。同样地，假设做一个web页面应用，我也时也看着页面上如何上下翻飞地去模拟成千上万页面的不断展现、模拟用户操作。对于asp.net服务器端的自动测试也是一样。当然对于服务器端就更为简单，因为使用一个console程序就足够了。

对于系统维护当然也是一样，而且系统维护往往需要你有7x24小时一直在运行着的测试程序，去检测网络上各个服务器的状态，以及各种端口的服务的基本工作状态，如果有一点性能问题就应该提前报警。

以专业开发人员为伍 2012-02-04

打赏
举报

你说了很多问题，但是这些负债积累了多长时间？我的容忍习惯是：服务器端1小时左右，客户端3小时左右。而许多人比我的容忍习惯多100倍！

假设我怀疑一个跨5个服务器的简单的领导查询接口可能有某个功能问题，花5分钟写一个可执行的测试用例就可以了。假设改天有担心其有另外一个功能问题，再花5分钟时间再写一个可执行的测试用例就可以了。假设运行完整的测试（中午或者晚上）的时候报告了一个bug，而这个bug不是3天之内写的测试用例，那么为其加上一个[Reopen]标签使其可以自动加入3天以内的测试用例组里好了，这样每一个程序员几乎每隔几分钟就会运行它一次。当你有50个这种程序，每一个人不经意地都从他自己的机器上帮你每隔十分钟就测试几遍的时候，你自然就对这50个测试所可能已经涉及到的部分不会发出什么“最纠结在于多方连调测试，Bug查找，异常重试/恢复处理”这类悲剧的感叹。相反地你做出架构的调整时总是很有勇气、完全胸有成竹。因为你可以一步一步小步、以极限速度去突破技术问题。

以专业开发人员为伍 2012-02-04

打赏
举报

不要搞过度文档驱动式的开发，也不要搞Scrum那种没有多少技术含量而靠行政手段贴标签式地开发（因为这最终其实还会回归为逐级分解八股文式的文档驱动开发）。举个简单例子，假设一个系统只有一个服务器、两个客户端，你在中午吃饭去的时候就会让它们开始测试，然后吃饭回来就可以看到服务器上200个测试用例已经运行了3000遍，两个客户端系统600个测试用例已经运行了10000遍，这就是很简单的一次举手之劳事情，我说这种事情时总是非常平淡的。

昨天我告诉以为刚刚加入我们的程序员：你应该每隔十几分钟就频繁提交一次代码到svn，但是每一次提交前都要运行一次测试程序（默认地只是把运行最近3天的测试用例以随机次序运行几遍）。

实际上越是外行看起来的“乱”的管理，可能越是有自己的工程技术。而那些看起来很“规范”的管理，很可能最多只是一个出处追求平庸、人人互相牵制、谁也不敢有太多创造性的团队。

.NET快速开发框架 2012-02-02

打赏
举报

专业协调，可考虑建立项目管理办公室。PMO

shenopkss 2012-02-02

打赏
举报

[Quote=引用 1 楼 caozhy 的回复:]

我想软件开发最关键的是不要徒增复杂度。比如说为什么要4种语言，为什么要多个部门。
《人月神话》在30年前就指出，当项目到一定规模，往团队里面增加人手，产生的生产率增益反而是负的。
[/Quote]

首先确实是个不得不跨部门的项目，并且每个部们都有自己成熟的产品，所以是在所难免的。有的甚至10年前的成熟项目。