应用云平台的可用性——从新浪SAE看云平台设计
云计算平台的可用性,相比传统互联网服务而言,更加复杂和困难,也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台,以及对云计算的用户提出了建议。
该内容已经被标记书签!
标记书签错误,请重试!
作者 Kurt Christensen 译者 乔梁 发布于 2007年11月11日
实效营销是科技领域的一种产品管理方法论,和那些敏捷软件开发方法相似,它追求价值与原则。所以,当实效营销者遇到了敏捷开发者,会发生什么呢?最近,Stacey Weber在一篇文章中写道:“文化间的啮合通常是不完美的”。
“严苛”一词是很多公司应用敏捷开发之经验的准确描述,这种方法等于是向快速变化的需求屈服。实际上,我相信正是因为工程师们要处理那些来自执行经理和产品经理的不断变动、又自相矛盾的需求变化,所以产生了敏捷方法。这些工程师与无法决定需求优先级的执行经理一同工作,还有那个忙于想需求而不做市场调研了解真正需求的产品经理……对于工程师来说,敏捷好象就是他们要找的答案,因为他们的团队只关注很少的需求就行啦。他们基本上可以忽略执行经理和产品经理……几个星期后的任何需求变化都可以不管。
先把错误的立论前提先放一边,有一件事是可以肯定的,即敏捷方法并不能解决业务中的根本性问题,尤其是当业务本身不能决定如何做,或无法决定优先级时,敏捷方法根本帮不上忙。Barbara Nelson和Stacey Mentzel在一篇名为《极限项目管理》文章中详细阐述了这一问题。
如果敏捷方法本身可以解决“构建那些大家想要的产品”这一问题的话,那我们就不用写这篇文章了。我们就说“用敏捷吧!”可是,我们一次又一次地听到敏捷方法可以很快交付成果,但如果没有计划和全面蓝图,那所交付的东西(让我们先叫它用户故事吧)可能无法帮助我们卖出更多的软件。
当认识到敏捷方法的这一缺点以后,他们做出下面的反应,即提倡“敏捷瀑布方法”。这一方法实际上是较为强调长期计划的敏捷软件开发方法。一方面,这好象合理且必要的,因为可以让业务人员能够制定长期计划和承诺来销售产品,“有助于创造人们想买的产品”——这是实效营销的口号。然而,业务人员如果过分强调长期计划的话,就不能根据增量开发并实际运行的软件提供的反馈,及时地进行适当调整。毕竟,做产品应该是帮助业务人员更好地理解做什么样的产品,怎么做更好。有点讽刺意味的是,实效营销的应用领域是技术硬件和软件,而真正的技术革新不仅仅是要听市场的呼声;它还要展现市场需要而尚不自知的东西。单凭对营销模拟客户的调查可能发明不出iPhone。
然而,实效营销应该还是敏捷方法的倡导者,因为它不但展现了敏捷方法的价值观和原则可以成功地应用在业务方面,而且更重要的是,某种意义上,它还试图说明,在什么情况下敏捷开发实践不起作用。这是为什么呢?我们能做些什么呢?
英文原文链接:Agile Meets Pragmatic Marketing译者 乔梁 有十多年软件开发及项目管理经验,专注于提高软件企业提高交付能力。现任百度项目管理部高级架构师。
或者说得更准确些,对于产品研发,只有敏捷是不足够的。敏捷能做出你想要的,但没办法保证做出好的或者正确的或者受欢迎的。而且作为从内部IT项目衍生而来的敏捷方法,它本身有一种趋势:把功能做到能用而非完美。对于内部IT项目,这很好,两个能用的功能往往能提供比一个完美的功能多得多的价值;但对于面向公共用户的产品,你麻烦了,因为不完美的功能很可能根本就没人用。
交互设计是改进的办法之一。但很多敏捷的组织对此认识并不充分,他们只是在项目进行中让交互设计师来做一次评估和设计。这是不足够的,就好像在软件项目的交付之前才进行QA工作是不足够的一样。质量来自整个流程,同样好的交互设计也来自整个流程。有了敏捷方法,还要有一套全流程的产品设计方法支持,才可能做出好的产品。
同意。
客户定制项目与产品项目有着不同的出发点。客户定制项目需求相对实际,而产品规划要有前瞻性。
在软件开发过程中,使用TDD、持续集成等开发实践是有意义的。但在敏捷方法论中的需求决定论用于产品开发似乎不太有效。比如,客户还没有意识到他真正需要什么的时候,开发人员就不知道该干什么了。
在Xiaoming的blog中也提及相关的话题。
从实践上讲,个人认为,敏捷过程中的BA角色应当更加多的参与甚至融入到marketing的团队中。从一开始的Marketing segment就开始。事实上,市场划分实践和交互设计中的persona方法有很多相似之处,很大程度上可以融合到一起。
而从逻辑上说,这样的实践并不能保证市场划分的正确或产品定位的准确。市场调查研究和市场策略依然是一个产品最重要的一环。
但这并不是说是敏捷开发实践不起作用,而是因为这是另外的一门学科,本来就不是开发实践应该在的地方。
不知道该说些啥好,敬仰一下楼上的三位吧……
项目,功能完成就可以交付用户使用了。如果有什么问题,接着修改,再交付。客户也欢迎这样的方式。但是,做产品是完全不同的。如果我们开发出不完美的产品交付给消费者,消费者一旦不满意是没有耐心等着升级的,他们最直接的反应是:删除这个垃圾软件!
产品不一定就要交给消费者啊,也是可以“有什么问题,接着修改,再交付”的。办法比如focus froup、不要脸地老是beta/CTP/体验版/泄露版……各有各的招。
云计算平台的可用性,相比传统互联网服务而言,更加复杂和困难,也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台,以及对云计算的用户提出了建议。
淘宝高度重视Java平台的健康发展,组建了一个团队专注于Java平台的底层部分的性能、功能与稳定性改进;工作主要基于OpenJDK中的HotSpot VM开展,其中一些通用的功能随后也会逐渐反馈给OpenJDK社区。希望能与使用Java平台开发应用的大家交流经验。
本次演讲视频录制于QCon杭州2011。
2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障,导致许多商业网站的服务中断,影响非常严重。作为云计算用户,我们需要思考的是,如何保证即便在云服务不可用的情况,我们的应用架构仍然能够屹立不倒?本文正是站在云计算用户的角度试图探讨这一问题。
12人的技术团队,4组刀片服务器,每月20亿的访问量,每日1次准时部署,99.9%的可用性。这可能吗?当然。想知道如何做的吗?百姓网将与您分享他们在DevOps实践过程中的经验和技巧。
本次演讲视频录制于QCon杭州2011。
篱笆作为一家起源于社区的电子商务公司,反映到技术层面就是同时要面对产品和业务,以及经营战略的变化调整。如何在产品和业务的夹缝之间完成技术架构的抽象与平衡,寻找更有效的价值定位,这当中有些经验教训和个人感悟愿与众人分享。
本次演讲视频录制于QCon杭州2011。
本文将对特性注入以及相关方法做一个扫盲性的介绍。我们会解释这个框架的关键要素,并附上实例来证实它们。为了让文章保持相对较短,我们不会深入到某个工具或方法中,而是会给出一些参考资料,以便大家做进一步的研究。
随着JDK 7的发布,字节码指令集终于迎来了第一位新成员——invokedynamic指令。这条新增加的指令是JDK 7实现“动态类型语言(Dynamically Typed Language)”支持而进行的改进之一,也是为JDK 8可以顺利实现Lambda表达式做技术准备。在这篇文章中,我们将去了解JDK 7这项新特性的出现前因后果和它的意义。
随着互联网应用的发展,Java分布式远程服务技术受到越来越多的关注,本文将对各种相关实现以示例的形式逐一介绍,并总结其中的优缺点,使读者能够在技术选型时有所准备。这是文章的下篇。
6 条回复
关注此讨论 回复