Author: 金 明

About 金 明

ThoughtWorks 高级咨询师
InfoQ主编
SCJP, 系统分析师
Consultant@ThoughtWorks, Editor@InfoQ, SCJP, Certified System Analyst. Focus on Agile, PM, OO, Arichtecture, and Open Source

云计算2013~2014纵谈(下)

回顾2013,Hypervisor和Container虚拟化技术都基本尘埃落定,云计算领域的大玩家也都已经基本进场,更多的中小玩家在纷纷自立山头。这只是云计算的起点,根本不是云计算的重点。展望2014,更多的领域将等待着云计算团队们去突破,云计算更多的想象空间等待着整个市场去挖掘。笔者不才,妄自预测了2014年的云计算新趋势,可分为如下四个方面:

  • Cloud Native Application:运维从未有像今天一样这么深远地影响到软件的开发和设计。软件应用在架构上如何更好地弹性利用已有的云服务,这将成为未来一段时间的重要命题。传统的软件开发对于可扩展性和运维考虑的是各级模块的纵向扩展和HA,但Amazon AWS的CloudFront、EC2、EBS、S3、DynamoDB基本就涵盖了网站的CDN、计算、文件系统、存储和数据库,这些对于一个中大型的互联网网站已经绰绰有余,企业又有什么理由不去利用?再比如,传统的软件监控往往强调MTTF,Netflix开源的Chaos Monkey则对系统的MTTR提出了更严格的要求。
  • Cloudify OPs:传统的运维只是单机版1.0,未来的运维需要同时操作上千台机器;传统的运维只是被动地执行变更,未来的运维需要主动地提出变更。如何结合企业的运维流程和要求,从整个企业全局的角度提高运维的效率?如何即提供服务平台,同时又保障运维的合规?《Measureing IT》这本书里面提出了SPO(Servers Per Ops)指标——一个运维人员,能够支撑多少台服务器的运维、配置管理、应用部署、监控警告等。类似于互联网思维对于产品经理的思维改造一样,运维人员用云计算的思维、技术和工具对自己的日常工作进行改造。这一点对于国内的运维团队更为重要,否则,人力成本导致“人海战术”的难以为继只能阻碍运维团队为企业创造更多的价值。
  • I&PaaS:2011年,NIST定义了云计算的几种类型,但谁又规定了IaaS、PaaS和SaaS的边界不能被打破?IaaS、PaaS和SaaS都只是运维服务平台化的实现方式而已,只要有需求,就没有不能被打破的藩篱。Amazon AWS支持Beanstalk,Google除了GAE之外也推出了自己的Cloud。如今,OpenStack也加入了LXC的支持,业界涌现出来OpenStack加上CloudFoundry或OpenShift组合向外提供PaaS服务的案例。未来IaaS、PaaS两者的融合会越来越多、越来越快,也算是上文提及的IaaS厂商下沉IT服务的一类。
  • Cloud Security:随着企业的应用迁移到云计算服务厂商,视数据为生命的企业对云平台的安全性也提出更高的要求。Amazon和GMail在2012~2013的几次事故都给云平台的可用性和安全性提出了质疑。进入2014年,随着个人云、穿戴设备的兴起以及小白用户对云平台SLA的不了解,都给数据和云的安全提出了更高的挑战。如何从云的整体技术栈着手,构建全面的安全服务,不出现任何的短板;如何从租户的隔离上下手,减少租户对底层系统的突破,减少租户之间的攻击;又如何在第一时间侦测到安全的问题并采取措施修复问题,这些都是云服务厂商需要考虑并强化的点。

当然,相信2014年云计算的创新会远不止以上的四个方面。当第一块多米诺骨牌倒下,第32块多米诺骨牌可以推倒帝国大厦,谁又能完全正确地预料云计算的未来?至少据Gartner预测,随着云计算服务认可度的持续增加,云计算服务市场这种高速增长的态势将至少持续到2014年,2013年全球云计算服务市场总收入将突破1500亿美元,2015年突破1800亿美元。无论从哪个角度,这都是一块足够大和诱人的蛋糕。

“这是一个最好的年代,也是一个最坏的年代”,狄更斯在《双城记》中的开场白吐尽了无限的沧桑。电影《这个男人来自地球》的主角从山顶洞人时代一路走到现代,看尽风月通晓古今,却谓叹无法突破时代的局限,只能追随时代的弄潮儿。时代的弄潮儿已然登场,我们是台下的观众,抑或后台等待,又抑或门外的路人?当2014流逝,我们未来回顾的时候,又会以什么样的心情来看待自己在其中的位置呢?

—Done—

云计算2013~2014纵谈(上)

“旧时王谢堂前燕,飞入寻常百姓家”,在2013已然逝去、2014徐徐展开的时间节点,用这句话来描述云计算是再合适不过了。曾经被视为小众的云计算,正式成为市场的主流,传统的重量级厂商纷纷投靠唯恐落后;曾经处庙堂之高的云计算,已然走下神坛,大量的小厂商和产品如雨后春笋;曾经遥不可及的云计算,已经来到身边,深刻地影响着国内广大的公司和开发人员。行云流水间吉光片羽,除了不胜唏嘘之外,更令人深思和激动。

2013年12月18日,Amazon宣布推出中国区域云计算服务,取道宁夏而屯兵北京。“银瓶乍破水浆迸”,消息传出,阿里云推出“12.18新起点再起航”部分免单活动,全线产品降价;IBM宣布与世纪互联合作将其云计算基础架构服务SCE+(SmartCloud Enterprise+)正式引入中国;微软也正式宣布联想成为中国首家微软Cloud OS战略合作伙伴;腾讯云的年终大促也拉开大幕……一时间山雨欲来,溪云压城。

只是这一次,Wintel的美谈已成历史,微软也早不复当年之勇。且不论Windows 8、Windows Phone和Surface的评论与销售双双滑铁卢,Windows Azure挣扎这么多年,仍然无法成为市场主流。虽然亲生的Hyper-V虚拟技术对Windows系统的支持最好,但始终不温不火。只有深度依赖微软技术栈的客户,还保持对微软技术的不离不弃,倒也不负恩泽。

廉颇老矣,何论冯唐?百年IBM在给宣传SmartCloud时自豪地宣称专注虚拟化40年,一口气将自己的虚拟化寻根到上世纪70年代的System/360,俨然一副“蓝色巨人”的风范。只是2013年6月当NASA宣布放弃IBM而选择Amazon AWS的时候,不知道40岁的SmartCloud是否老泪纵横?

屋漏偏逢连阴雨,过去的一年中国内云计算界在淘宝的带领下也掀起了对“巨人的进击”——“去IOE”的声音越发响亮。在云计算的时代,IBM的小型机、Oracle的商业数据库、EMC的存储在X86的廉价集群前溃下阵来。淘宝在2005年以蚂蚁大军击败eBay大象,如今“蚂蚁缠斗大象”的一幕似乎将在IT基础设施的领域再一次上演。2013年5月17日,阿里最后一台IBM小型机在支付宝下线。那张照片是这次“去IOE”革命的最好注脚。

无怪乎RedHat、Canonical、VMware、Intel等厂商也纷纷追随RackSpace和NASA,进入以OpenStack为代表的开源云计算社区,或以产品、或以资助、或以资源等方式试图在廉价云计算市场占得先机。除了收购DynamicOps和Nicira,VMware组建了一支专门的开发团队向OpenStack代码库提交针对vsphere Hypervisor的代码。Intel从2012年起,就开始深度参与到OpenStack的开发中去,其上海的测试团队就一直对OpenStack的各个版本提供测试。在移动市场失掉先机之后,Intel在云计算、大数据和穿戴式设备领域终于找回了感觉。

“三十年河东,三十年河西”,在过去的一年中,开源社区和中小型厂商迎来了属于它们的机会。我们不仅看到了基于容器的虚拟化技术的兴起,也看到诸多新鲜血液加入到云计算的市场。

Joyent在收编了Solaris的一批开发骨干之后推出了SmartOS,不仅进一步完善了Solaris的Container/Zone以及ZFS,而且将Linux下的虚拟化Hypervisor KVM移植过来。于是,以NodeStack和Fengqi.Asia为代表的部分公有云厂商选择了SmartOS作为云平台底层虚拟化的核心组件。除了Unix,在Google的大力推动下,基于cgroups技术的LXC在2013年也是在Linux社区得到了极大的重视和发展。腾讯基于LXC推出游戏云,为QQ游戏提供更弹性的资源配给和资源隔离服务。与此同时,以Docker为例的工具在过去的一年内也夺取了很多眼球,甚至进入到商业市场。百度在它的BAE(Baidu App Engine)中就使用Docker来管理底层的资源。

除了上面的重量级厂商和公司,国内的中小、创业公司也是捷报频传。先是2013年8月金山云宣布2000万美元的融资,接着上海的UCloud宣布获得1000万美元的A轮投资。最近,想做中国AWS的QingCloud又在2014年元旦之际宣布2000万美元的B轮融资。风投资本再一次投出了自己的一票,用赤裸裸的金钱证明了他们对于国内云计算市场的看好。

上述都是针对基础设施的厂商,他们结合底层的各种Hypervisor和Container将面向IT的服务固化到他们的云平台之中。与之对应的是,传统意义上位于运维上层、离一线运维人员更近的配置管理、任务编排、日志监控以及日常运维等领域也是英雄迭起、精彩纷呈。很多厂商将不同层次的技术结合起来,以期在IaaS上提供更多的增值服务。RightScale将IaaS和Chef结合,提供跨越不同云平台的虚拟机镜像服务,甚至支持企业内部的vSphere;Travis-CI将Vagrant和VirtualBox结合,向GitHub这类的代码托管厂商提供持续集成的服务;ScaleWorks将vSphere、OpenStack和Chef结合,向企业提供针对已有虚拟化技术的云化方案;Modern.IE则把眼光放在了Windows IE版本兼容性测试的领域,结合VirtualBox、VMware和Parallels提供标准的虚拟机镜像服务……更别说Chef背后的OpsCode、Puppet背后的PuppetLab和Ansible后面的AnsibleWorks了。大量的运维人员将自己的最佳实践转化为开源或商业产品,守得云开见月明。

实质上,云计算从来都不是目的,背后的CapEX、OpEX以及Productivity才是真正的诉求。而这,是永远不变的主题。云计算通过虚拟化和标准化,将精通运维的团队与个人的生产力池化而后量化、再服务化,使得大量的非运维人员可以以很低的价格享受优质而有SLA保障的运维服务。因此,云计算可以算得上是技术挑战商业的又一次成功案例。

—TBC—

OVA(VMX)化Vagrant box

Vagrant是一款针对本地虚拟机的管理工具,使用起来非常方便。然而,虽然Vagrant是基于OVF与VMDK格式标准,但Vagrant box却并不是合法的OVF压缩包,而且本身也没有声明对VMWare的支持,所以,我们不能够直接将Vagrant box直接导入到VMWare产品如Fusion里面。但是,Vagrant box与VMWare VMX的鸿沟也并非那么大,我们可以通过修改Vagrant box的OVF描述文件以及压缩打包方式,将Vagrant box转为OVA或者VMX格式的压缩文件。
Vagrant box不是合法的OVF压缩包,主要的问题在于Vagrant box中文件的顺序不符合OVF压缩包(OVF Archive)规范。OVF压缩包对文件顺序的要求是:OVF必须是第一个,然后是虚拟机镜像文件(如VMDK),接着是MF文件,再接下来是其他的可选文件(如证书、I18N等)。但是,Vagrant box里面的顺序则是VMDK、MF、OVF、Vagrantfile,如下图。

 

 

 

我们可以用OVF工具去验证一下Vagrant box,比如VMWare的ovftool会提示如下的错误信息:

 

 

既然知道了问题的原因,那解决起来就好办多了。我们只需要将Vagrant box重新按照一定的顺序压缩即可。比如,我们可以直接用tar,如下图:

 

 

 

 

 

 

 

 

 

当然,我们也可以使用VMWare的ovftool来实现同样的目的:

ovftool box.ovf lucid32.ova

这样,我们就解决了Vagrant box不是合法OVF压缩包的问题。然而,通过上图可以看到,虽然Vagrant box里面是VMDK文件,而且VMDK同时被VirtualBox和VMWare支持,但是由于Vagrant box在box.ovf的Family里面只声明了virtualbox-2.2,故而也没有办法被VMWare打开。我们也可以使用VMWare的ovftool验证一番:

 

 

 

因此,为了Vagrant box也能够在VMWare里面打开和配置,我们需要修改Vagrant box里面box.ovf的一些配置,增加对VMWare的支持,并将其中一些VirtualBox特定的配置修改为VMWare兼容的。
为此,笔者开发了一个vagrant插件叫vagrant-ovf,可以很方便、自动地修改box.ovf以及box.mf(因为每次修改了box.ovf,都需要重新计算box.ovf文件的SHA1值)。

  • 为了使用该插件,首先安装vagrant-ovf,如gem install vagrant-ovf
  • 然后,通过vagrant ovf [boxname]就会修改指定Vagrant box里面的box.ovf以及box.mf,使之增加对VMWare的支持。
  • 接着,我们可以通过上面的步骤将Vagrant box重新压缩为OVF压缩包,例如lucid32.ova
  • 最后,我们可以用ovftool将刚才得到的lucid32.ova再转化为VMX文件,ovftool lucid32.ova lucid32.vmx

这样,我们刚才得到的OVF压缩包就转化为VMWare Fusion可以直接打开、导入的VMX文件。进一步,我们可以借助于VMWare提供的vapprun做一些深入的自动化工作。

Vagrant初窥(二)

Box
box是Vagrant用以创建、分发虚拟机镜像的压缩文件。例如,对于本文例子中的lucid32.box,其内部结构如下:

基本上,Vagrant的box文件是一个OVF压缩包(为什么说基本上呢?大家可以移步我的这篇博文,这里不深入探究)。OVF(Open Virtualization Format,开放虚拟化格式)是由HP、VMWare、XenSource等公司或团体组成的DMTF(Distributed Management Task Force)组织提出的虚拟化格式标准,于2008年9月发布v1.0,截至本文为止的最新版本是v1.1.0。OVF描述了虚拟机打包与分发的各种配置和扩展点,其目的在于提供一种开放、安全、可移植和可扩展的格式,而不需要依赖于特定的超管理程序(hypervisor)或者处理器架构。目前,OVF已经被业界广泛接受,主要的虚拟化厂商与组织,如VMWare、IBM或者VirtualBox都已经提供了支持。OVF的详细格式可参阅OVF规范,这里不多做分析。

OVF压缩包(OVF Archive,OVA)是OVF打包与分发的基本单元,由一个或者多个虚拟机镜像以及其他的一些元数据文件组成。一个OVA压缩包通常会包括一个OVF描述文件、一个或者多个虚拟机镜像文件、一组本地化文件、一个manifest文件和一个证书文件,其中只有OVF描述文件和虚拟机镜像文件是必须的,其他都是可选的。

对于本文例子中的lucid32.box,里面除了box.ovf文件,还包括了一个box-disk1.vmdk、一个box.mf文件以及一个Vagrantfile文件。box-disk1.vmdk是基于VMWare提出的vmdk虚拟镜像文件格式,它为VMWare和VirtualBox等工具支持。其中的box.ovf是对该虚拟机镜像文件的OVF描述。box.mf里面放的是box-disk1.vmdk和box.ovf的SHA1值。有时候,你可能需要修改虚拟机镜像的配置,你可以手工修改box.ovf的内容,再重新生成它们的SHA1值(如,最后用新的SHA1值替换box.mf里面的内容即可。

由于Vagrant box就是OVF压缩包,同时,vmdk也是一种较为通用的虚拟镜像文件格式。所以在原理上,所有兼容OVF格式的超管理程序(hypervisor)和虚拟工具(VirtualBox、Oracle VM或者VMWare等)都能很好的解析和支持Vagrant box。

Vagrant的子命令vagrant box提供了管理box的所有功能,如add、list、remove、repackage等。这些子命令都非常自解释,如list是列出本地的Vagrant box,remove是删除指定的Vagrant box,repackage是重新打包本地的Vagrant box等。Vagrant box add会将指定的box文件(同时支持http、file协议)添加到本地——即把该box文件下载到本地,并解压缩为~/.vagrant.d/boxes下的同名文件夹。比如,你可以在~/.vagrant.d/boxes/lucid32文件夹下面找到上面所有的文件。这样,Vagrant就将box添加到本地,接下来就可以基于Vagrant box创建、启动、配置虚拟机实例了。

接下来,让我们看第二条命令:
$ vagrant init lucid32
执行完这条命令之后,Vagrant会在当前目录创建一个Vagrantfile文件。这是我们要接触的第二个概念——Vagrantfile。

Vagrant初窥(一)

虚拟化技术已经飞入日常工作。很多人为了开发、测试,会在本地创建一个VirtualBox或者VMWare虚拟机,以模拟某个特定的目标环境(如Windows XP、IE7等)。为了实现这个目标,人们往往需要手工去安装所需的操作系统或者软件,手工配置一些环境变量,再手工将打好的部署包拷贝过去,并且手工部署应用程序。整个过程基本上都是手工操作,而且需要确保每个步骤都配置正确——耗时,且容易出错。有没有什么工具可以帮助我们将这些工作自动化,省去繁琐的手工操作,确保可靠地、可重复地执行这个过程?

Vagrant就是这样一款非常优秀的工具,它很好地封装了虚拟文件镜像、VirtualBox API以及配置工具(如puppet、chef等)等成熟工具的使用,从而能够帮助开发人员很方便地、可复用地创建、配置和分发虚拟机的工具。借助于Vagrant,开发团队可以自动化应用环境的创建、配置以及应用程序的部署,甚至进一步将环境的集成纳入到构建流水线、持续集成。本文将介绍Vagrant的基本用法、概念模型、内部机制以及veewee插件,带着大家一窥Vagrant的神秘之处。

引子

在开始之前,首先请确保本地已经安装了VirtualBox,可以正常地创建、管理虚拟机,而且本地已经安装了Vagrant。您可以通过在命令行执行vagrant -v来查看当前安装的vagrant版本。

如果这两者都已准备妥当,下面就让我们看一个简单的例子:
$ vagrant box add lucid32 http://files.vagrantup.com/lucid32.box
$ vagrant init lucid32
$ vagrant up


在经过一系列的步骤之后,vagrant提示虚拟机已经完成了创建。让我们来试试这台刚创建的虚拟机,ssh登陆到虚拟机上面去:
$ vagrant ssh

可以看到,经过这样简单的几步,我们就拥有了一台完全可用的Linux机器。接下来,我们可以在虚拟机上面安装软件、配置环境——就象操作本地机器一样。这一切是怎么做到的呢?我们一步步来分析上面的步骤,看看Vagrant在其中做了些什么。
首先,我们是执行了box add命令:
$ vagrant box add lucid32 http://files.vagrantup.com/lucid32.box
这里,我们先执行vagrant box list,命令行控制台会输出如下的box列表:

centos-6.2-64bit_4.1.8
centos6-32
debian64_chef
lucid32

我们可以发现在执行完vagrant box add之后,本地的Vagrant box会增加一个名为lucid32的新box。这是我们接触的第一个概念——box。

扫去彩云的乌云边

随着新年钟声的敲响,2012终于来到我们面前。回首2011,经济危机的阴影仍未散去,欧元区和美国经济的疲软让更多的企业选择捂紧钱包过冬。在这样的情形下,“按需使用,计量付费”的云服务日益成为企业IT的主流。越来越多的CIO/CTO开始思考、着手将自己的基础设施与应用迁移到云上。然而,2011年发生的几起云服务事故却给这一锦绣蓝图镶上了乌云边。云服务的可用性如何保证?如何开发可靠的云应用?成为很多人心中迫切需要解开的疑虑。

2011年4月份,Amazon EC2美国东部数据中心发生故障,众多应用变得无法访问;2011年10月份,RIM黑莓服务的“宕机”事件,让重度依赖的企业用户们损失惨重;再联想此前2011年3月份,Google邮件服务与企业套件的不可用……这一桩桩、一件件,是否意味着云服务遭遇了“滑铁卢”?云服务提供厂商采取了哪些措施来提高自身服务的可用性和可靠性?他们是否采取了有效的监控与报警措施?假如云服务宕机,云服务提供厂商又有哪些措施来确保数据的不丢失与回滚?从运维中积累了丰富经验的云服务提供厂商显然胸有成竹。

正如硬币的两面,一方面云服务提供厂商在确保基础设施与服务上面投入了大量的精力,另一方面,为了让自己的应用能够屹立不倒,云应用开发商也是有大量的工作要做。如何在满足业务功能的前提下,预防可能的云服务不可用风险?云应用的架构如何应对可能的风险?如何让“捣乱猴”等基础设施帮助自己及早发现系统抵抗云服务不可用的能力?另外,对于底层的云基础设施和存储,如何备份以及提高回滚、恢复能力?这些问题,云应用开发商必然需要深思和采取行动。

“太阳底下无新雪”,网络、系统、服务等运维积攒下的丰富经验与知识,正是新时代云服务需要借鉴与汲取的。云服务的可用性问题并非无解:云服务提供商与云应用开发商都需要及早考虑、规避、预警服务不可用的风险,并及时妥善做好恢复工作。两者各司其职,“上帝的归上帝,凯撒的归凯撒”,又需要紧密合作、双向共赢。

在这个商业创新越来越快的时代,DevOps、持续交付是必然的趋势,开发与运维、服务商与开发商的合作、交流越来越紧密。晴空依旧,彩云涌起,何处有乌云?

http://www.infoq.com/cn/minibooks/architect-jan-10-2012

让非技术人员理解设计

作为技术人员,我们经常需要跟客户、业务分析人员等非技术人员沟通软件设计方面的问题。如何比较直观地向这些非技术人员解释设计、软件质量对项目的影响,解释糟糕设计、不干净代码给项目带来的风险,解释我们必须开始关注软家设计问题?这里有两个概念(metaphor)可以帮助我们达到这一点。

Continue reading

浮潜与水肺潜水

不同形式的分析活动贯穿于项目的整个生命周期:自上而下、自下而上以及先中间后两边。


浮潜潜水员游弋于海水表层,看鱼戏浅滩,望影掠深海。水肺潜水员可以潜过海水表层的深度;他能潜到更深的地方,在一定的区域内研究那些影子以发现鱼类、沉船残骸以及珊瑚的细节。在相同的时间内,浮潜潜水员可以游历更宽阔的水域;而水肺潜水员则在潜游深度上占据优势。成功的项目团队在项目的整个过程中会把浮潜和水肺潜水这两种方式结合起来使用,在特定的时刻明智地选择合适的方法,从而有效地利用了时间。

浮潜是一项很好的技术,项目团队可以用来弄清楚需要研究多少领域,以理解问题和达成目标。往往在项目或者子项目的起始阶段,团队通过浮潜识别出研究范围、目标、利害相干人、研究边界、已知事实以及需要进一步水肺潜水的地方。

当潜水员感觉到一些有趣的东西、陌生的事物或者更深的细节信息需要考察时,他会进行较深的水肺潜水。深度潜水的发现常常会改变浮潜阶段所设定的假设。假如我们发现了某种海产生物,而此前我们并未预料到能在这片水域找到这种生物;那么,我们就需要调查更宽更广的范围,以找出这种生物的繁衍区。

本模式的迹象之一是团队在做广度(浮潜)考察的同时,也会——而不是忽略——针对特定问题进行具体的(水肺潜水)工作。关键是团队在项目的整个过程中应用广度深度究技巧的能力。研究的广度范围识别出可能会对项目产生影响的人、组织、硬件和软件系统。在广度上知晓得越多,就能识别出高风险与高收益的领域,以及如果辅以进一步的深度研究可能大有裨益的领域。

掌握浮潜与水肺潜水技能的项目团队不会因问题域之宽而气馁。团队成员知道自己不需要对整个问题域都进行同样深度的研究。例如,如果他们决定针对问题的某一部分购买已有的解决方案,那么他们的研究只需要深入到足以验证解决方案是否适用于工作情形即可。当他们决定开发自己的解决方案,则他们需要判断这项变动要求多深的研究。他们同样知道某些更深入的研究可以推迟到以后某个更为合适的时间。面对较宽问题域的项目团队在响应变化上面更胜一筹,因为他们可以预见改动所引发的影响。他们对于哪些是自己所知道的、哪些是自己所不知道的、哪些是需要加以探索的以及哪些是可以放在一边的,都是心中有数。他们能够计划如何使用资源以获得最佳效果。

引入浮潜与水肺潜水技术的项目很可能把软件原型、模拟物与上下文建模联合在一起使用。他们也可能使用增量式的交付方法,在项目早期交付价值最高的功能。同样,他们也能够只用一页的篇幅就清晰地解释项目的范围和目标。

本模式的反例是团队要么沉迷于细节(“我们只做水肺潜水——懦弱无用的浮潜免谈”),要么惧怕细节(“我们是浮潜潜水员——换句话而言,大海深处有怪物”)。并且,当人们谈论“更高层次”和“细节”就好像它们互不相关、了无牵连的时候,也属于本模式的反例。

优秀的开发人员不会画地为牢:他们既可以浮潜,也能水肺潜水。他们依据自己需要考察的对象来选择技术。侦察的时候,浅层潜水就已足够;但如果审察,就需要更深的潜水了。

有时,仅仅用脚趾探探水就足以知道不能跳下水。

浓浓的特性汤

    “体面汤、浓又黄,

盛在锅里不会凉!

说什么山珍海味,哪儿有这样儿香?

半夜起来喝面汤,体面汤!

——刘易斯·卡罗尔(Lewis
Carroll
),《爱丽丝漫游仙境

产品夸耀自己繁多的零碎特性,其中很多对于解决客户真正的业务需求几乎毫无帮助。

在一开始的时候,一切都显得那么美好。市场部有一个来自于客户的请求——添加额外的下拉菜单。然后,在产品中添加一个输出接口的需求来了,产品经理想要加上一份新的分析报表,DBA要求在数据库里增加一个新字段以改变背景的颜色。所有这些需求以及其他更多的需求,都交由开发人员负责加进到产品里面。随着需求的不断添加,产品的特性集不断增长,但过了一段时间之后,每个人——市场部、客户和开发团队——对如何将所有这些碎片整合在一起、这些碎片如何帮助实现业务目标,失去了理解。曾经带着明确目标出发的项目变成了难以下咽的、由各种无关特性炖成的一锅汤。

情况变得更加汤汁淋漓,因为感兴趣的各方都从不同的角度来看待产品的需求,根本不存在共同的、连通的思路。市场部从营销的角度把需求打包成一组一组的特性集合,也不管它们在功能上是否内聚。开发人员则按照自己所使用的实现技术对需求进行归类。各个客户也只是从他个人工作的角度出发单独地对需求进行考虑。这些离散的需求所带来的影响就是各人谈论进度或者对变更做出决定的方式都不一致。按照产品版本的主题再取折衷已不可能,因为根本就不存在一致的主题;相反,产品变成了混杂着各种玄机的大杂烩。

为什么如此多的产品最后以沦为特性汤收场呢?这一切都始于需求的源头——人们。

人们很自然而然地会认为自己的需求才是最重要的。同一个组织中的不同部门,或者不同的客户,都想获得属于自己的、与众不同的特性,于是提出的需求根本不顾及产品在整体业务上的一致性也就不足为奇。而这,就是分析师的工作了。

当零散的需求来了之后,分析师需要将它们与受之影响的业务流程映射起来。这种映射提供了一种方法——向不同的人们展示建议的变更对他们的工作可能产生的影响(有时非常令人惊讶)。这种分析让分析师获得了基本的理解,从而进一步发现人们真正需要的——以及变更是否提供了真正的好处,抑或仅仅是另一个滴入汤中的特性。

特性汤的另一个来源是设计人员在面对一项新需求的时候,不去追究其与既有产品在整体上的关联,就将其加入进来。设计人员应该发问,“它是否属于已声明的范围?”“与既有产品的接口是什么?”“它是否重复或者搞乱了已经存在的东西?”

在解决这些问题上的重复失败导致产品变成了一堆离散碎片的组合。需求是基于离散的特性,从本质上这意味着项目对于“什么是属于范围内的”以及“什么是超出范围的”没有客观的定义。因此,额外的需求就很容易从不同的来源渗透进产品里面——事实也确实如此。产品变得越发分离崩析,它也就越发难以评估,做出的变更就越发难以前后一致;一路螺旋直下,回天无术。

避开特性汤的组织有着很多的共同点:

  • 尽可能不留余地、尽可能早地定义项目目标和非项目目标。

  • 声明项目范围,并以精确定义输入/输出数据的形式时刻保持更新(参阅第24项模式,“白线”)。

  • 拒绝那些对声明的目标没有积极效应、而又明显超出项目范围的需求——进一步锤炼、巩固了钢铁般的意志。

  • 新需求的添加遵照被核准的、可追溯的变更管理流程进行,同时使用项目声明的目标对它们进行评估。

避免特性汤得靠纪律。时刻牢记着是你们——整个项目团队,而不是零散特性的请求者——将会身陷浓汤:这绝对划算。