"伤得起"的云计算应用——对云端应用之架构的思考
2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障，导致许多商业网站的服务中断，影响非常严重。作为云计算用户，我们需要思考的是，如何保证即便在云服务不可用的情况，我们的应用架构仍然能够屹立不倒？本文正是站在云计算用户的角度试图探讨这一问题。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
路宁谈精益思想——2008北京Open Party摘录
作者 李剑 发布于 2008年1月21日
上周六（1月19日），InfoQ中文站与ThoughtWorks、BJUG、AgileChina、BPUG等社区共同举办了一场Open Party活动，场地设在ThoughtWorks北京办公室，大约四十多人参加了本次聚会。来自ThoughtWorks的咨询师路宁为参会者献上了一 场精彩演讲：Lean Thinking With Examples，详细分析了实施精益或者敏捷过程中最大的阻力，以及如何识别和消除浪费。
活动从一个简单的Stand-up meeting（站立会议）开始，之后是半个多小时的沟通交流和所有主题的票选。当天的主题包括了开源社区发展、GPE、Mingle和Erlang等众 多精彩内容。在进行分会场会议时还发生了一个有趣的小插曲，Matrix的clever pig（刘丹）和Peter Cheng（程勇）的“开源社区发展”吸引了大多数人的注意，从而导致其他两个同时进行的主题因为人数过少被迫暂时中止。
之后，路宁在分会场进行了题为“Lean Thinking With Examples”的演讲（演讲PDF文件下载）。他从丰田生产系统（Toyota Production System）和精益（Lean）的历史谈起，分析了在企业或公司实施精益或敏捷的最大阻力——大规模生产时代在人们思想中形成的那些“看似合理但实则不 然”的思维定势（量产时代后遗症）。他还谈到了丰田如何扭转思维，大刀阔斧地探索自己独特的生产体系，最终在国际竞争中脱颖而出的故事。他说道：Lean就是识别和消除浪费（不产生附加价值的活动）的技术。随后，他举例说明了如何利用精益的5个原则（注：见新闻底部附注）来识别和消除浪费，同时还列出了几个常常与浪费结对出现的典型现象：
- 库存——库存在避免供应不足的同时增加了成本，减弱了企业对市场的敏感性，隐藏了企业中各式各样的问题，在市场稍有风吹草动的时候就可能使库存商 品变为滞销品，同时还造成了供应不足的尴尬局面。库存在我们的生活和工作中可谓无处不在，想想自家的书架、冰箱、工作中还没有结果但已经停滞的工作、当 然，还包括“高等教育”。
- 批量和排队（等待）——有的银行规定在每月的固定几天内处理企业发放工资，此时批量和排队就产生了，由此引发的等待和不均衡的工作负荷会带来浪费。还有城市内那些被过分依赖的交通枢纽，“等待”是司机开车到这里后常常要体验的事情。
- 不均衡（周期性）——比如销售淡季与旺季，五一、十一黄金周。
- 复杂和繁琐——如果事情比你想象的要复杂和繁琐的多，相信自己，这里很可能有浪费产生了，繁冗的文档和流程就是一个不错的例子。
- 强调符合原则和规定——并不是所有的规定和原则的背后都有像样的理由，即使有理由，也未必都是对最终用户有价值的。
未完成的工作都涉嫌浪费。精益或敏捷就是将未完成的工作（浪费）减少到最小的技术。按照这个说法，就连所有正在编写的代码都属于浪费。乍一听真的匪夷所思，如果不编写代码，我们拿什么东西给客户交付？价值又从何而来？这又怎么能说成浪费呢？
实 际上，还没有为用户创造价值的代码，就连用户自己也不能保证这就是他需要的。上面那句话并不是鼓励大家停止编码，而是督促我们尽快把手头的工作变为可运行 的软件，并在生产环境中运行，用户会反馈给我们结果和进一步的实际需求，此时我们才知道那个工作到底完成了没有。未完成的工作越多，自己和客户的风险就越 大，可能的浪费就越多，相反，未完成的工作越少，应对变化的能力就越强，那些只有少数人能够掌握的“需求获取技术”此时也变得没那个必要了。
假设我们在这一点上统一了认识，接下来的任务该就是寻找解决方案，减少浪费。那该怎样做呢？精益的5个原则给了我们一个清晰的、循序渐进的思路；具体到软件开发领域，众多敏捷实践则组成了一个实用的工具箱，帮助解决在履行精益原则的过程中被暴露出来的一个个具体问题。
要 减少写完代码到代码被成功测试和集成的时间，就要小步前进，频繁check-in和持续集成（Continuous Integration）。要减少完成功能到功能为客户创造价值之间的时间，就要频繁交付（Frequent Delivery）。可以看到，在这一点上精益思想和敏捷开发实践得到了完美结合！
上个月在InfoQ中文站一篇名为“抛砖引玉——重构是必要的浪费”的新闻中，Amr Elssamadisy提到过：
精益定义了两种类型的浪费：“纯粹的浪费”和“必要的浪费”。“纯粹的浪费”指的是那种既不能给开发团队也不能给客户带来好处的做法。“必要的浪费”是指某些行为，即便它不能给客户创造价值，但也是在我们所知的范围内完成一项工作的最佳方式。
路宁在演讲时也针对精益所定义的浪费进行了重点论述，并且对后者进行了更为详尽的说明：在软件开发中，测试、集成、重构和管理都属于这种浪费。他还总结了为减少这种无可避免的浪费常常应用的几个有趣的Pattern：
- 积极对待，配备少而精的人——敏捷团队非常重视上面提到的几种浪费，团队中的管理人员和测试人员要比传统团队数量少而且要求高一些。
- 由个人的任务变为团队的任务——赋予团队成员清晰简单的目标，实现自我管理。团队中几乎所有人都参与到设计、测试和部分集成的工作。代码所有权共享。
- 将工作自动化，区分人和机器的职责——人工测试和自动化测试相区分，持续集成。
- 工作提前做，频繁做——测试驱动开发，在早期开始频繁的单元测试、重构和集成。早期就赋予团队成员目标，并通过各种方式确保他们及时了解项目状态。
这里是2008北京Open Party的活动详情，以及相关视频。
注：精益的五个原则
确定价值——以客户需求来定义产品的价值。
识别价值流——指从原材料转变为成品，并给它赋予价值的全部活动。
流动——精益思想要求创造价值的各个活动(步骤)流动起来，强调无间断的流动，将所有的停滞作为企业的浪费。
拉动——让客户的需求拉动生产、决定投入和产出，不把客户不需要的东西强行推给客户。
尽善尽美——不断对整个活动进行修正和完善，追求尽善尽美。
李剑 李剑──ThoughtWorks高级咨询师，在持续集成、重构等领域具有丰富的经验；多次为国内大型企业敏捷组织转型提供咨询和培训服务。
沙发
发表人
Tong James
发表于
Re: 沙发
发表人
小刀 凉粉
发表于
Re: 沙发
发表人
liu cleverpig
发表于
Re: 沙发
发表人
lu ning
发表于
Re: 沙发
发表人
Ge fenghua
发表于
Re: 沙发
发表人
lu ning
发表于
对浪费再补充几句
发表人
小刀 凉粉
发表于
精益生产不适合于软件生产
发表人
yin jinqi
发表于
Re: 精益生产不适合于软件生产
发表人
Ma Terry
发表于
-
可以评选当天互动最激烈的Topic了吧，严重延时，^-^
-
汗……这个确实没的说，被Tin同学和cleverpig催了很多次：）
-
是啊！我称之为“柏拉图式的Topic”。不过，我个人非常喜欢这种freestyle。
-
“柏拉图式的Topic”，有意思的提法，Topic中的内容确实容易让人感觉到理想与现实间存在的差距，但丰田、法拉利、CFM国际公司（航空发动机生产厂商）等企业都已经经过自己不懈的努力证实了丰田生产方式的威力，它们在一步步走进理想，并在过程中享受着市场的回报。Agile也在软件领域中也有些“柏拉图”的味道，但重要的是有一些团队或公司正在脚踏实地地实践和享受着这种逼近“极限”的感觉。
-
理想和现实还是有一定距离的，每个企业的基本环境不一样，不要想着一步到位，丰田也是经过漫长的摸索和创新才有这样的境界。
就像企业一样，如果连电脑都没有，怎么上信息化。 -
嗯，距离是一定有的，只要我们比竞争对手距离理想更近一点就好了。
-
Kent Beck在他的新书《实现模式》总结了三条编程中的价值观：沟通、简单和灵活。
而他自己也说到了在“灵活”这一点中存在有争议。该做到怎样才算灵活呢？需要去估计未来在什么地方可能发生变化么？不去估计的话，怎样保证这种设计足够灵活呢？去做了估计，又怎么可能保证你的估计会正好和未来的变化相吻合？如果不吻合的话，那这种做法就增加了代码的复杂度却没有增加价值——而这一点往往是占了很大比例的。 -
精益生产不适合于软件生产
-
应该是不适合"量产"的软件生成, 例如外包.
9 条回复
关注此讨论 回复