知行

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做一些深入的自动化工作。

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。

虚拟化技术已经飞入日常工作。很多人为了开发、测试，会在本地创建一个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）可以帮助我们达到这一点：

技术债（Technical Debt）
“技术债”指的是，团队为了更早交付软件、更快交付客户价值或者其他一些考虑，被迫放弃良好的设计和干净的代码，从而对软件未来的扩展和维护欠下了“债务”。技术债就像财务上的欠债一样，在前期债务较少的时候，投入时间和精力来解决技术债或许不如尽快交付的价值高。但随着债务的增多，必然会影响新需求的交付和既有代码的维护，反而会延迟软件的交付。而且，技术债也具有财务债的特点，就是随着时间会像“滚雪球”一样指数上升。

安装、启动Sonar：

Sonar的安装很容易，按照Sonar官方主页的安装指南解压缩即可。

Sonar默认使用derby作为数据库，你只需要在sonar.properties文件中去掉对derby数据库属性的注释，然后启动Apache derby数据库。

按照文档介绍，启动Sonar，默认的主页地址是http://localhost:9000，登录用户名和密码是sonar/sonar。

使用Sonar检查代码：

要使用Sonar检查代码，也很容易。

如果待检查项目是maven项目，则只需要安装sonar maven plugin即可；如果是非maven项目，则需要在项目根目录下创建pom.xml，内容按照文档配置。具体参见：http://docs.codehaus.org/display/SONAR/Analyzing+Java+Projects

现在只需要项目根目录下，运行mvn sonar:sonar就可以运行sonar maven plugin来检查项目中的代码了。

注意：

如果项目源文件使用的编码与系统的默认字符集不同，比如操作系统是GBK，而源文件编码为UTF-8。为了能够正常地检查代码，需要在pom.xml的properties元素下增加一项配置如:

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

否则，sonar在生成checkstyle.xml的时候，不会将正确的编码传进去，导致checkstyle在做AST分析的过程中使用了错误的字符集，从而提示字符错误：“expecting ‘xxx’, but got ‘<EOF>’”。即使是在调用mvn sonar:sonar的时候，增加参数如：

mvn -Dfile.encoding=UTF-8 -DsourceEncoding=UTF-8 sonar:sonar

也无法生效，虽然通过-e开关是可以看到系统的默认字符集已经改成了UTF-8。

好了，sonar已经安装完毕，而且也顺利地完成了代码的分析和检查。

下一步，我们就可以分析sonar输出的报告，判断代码的质量，制定改善的措施了。

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

    “体面汤、浓又黄，

盛在锅里不会凉！

说什么山珍海味，哪儿有这样儿香？

半夜起来喝面汤，体面汤！”

——刘易斯·卡罗尔（Lewis
Carroll），《爱丽丝漫游仙境》

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在如今大部分的组织里面，是否给申请技术职位的人提供工作机会——这个最终决定权属于管理部门。经理们雇人，经理们裁人：一切都天经地义。然而在某些组织里面，这些技术人员能否得到工作机会却是取决于——至少部分取决于——他们将来的同事。这种同事预审的最终结果只有一种：当经理们让技术职员拥有发言权的时候，每一个人——申请人、职员和经理——都会和盘托出自己的想法。

招聘流程的前期阶段基本上没有变化：通常由第一线经理对申请人的材料进行最初的筛选。经理也许会要技术方面的高级职员先审阅简历，把所有的申请人归为“下一步”和“不，谢谢”两类。经理也许会给那些简历看上去非常华丽的申请人拨打电话聊一聊，做一个初步审查，决定邀请哪些人过来现场参加面试。获邀的申请人会被告知他将和团队在一起呆上3到6个小时。一旦众多的同事参与到招聘的过程中，面试的当天往往非常的漫长。

在抵达公司并与经理寒暄过后，申请人就随同各位团队成员开始一系列的面试。每轮面试的会谈时间从30分钟到90分钟长短不等。

虽然每位参加同事预审的面试官从申请人身上得到的信息相同，但每个人都会使用不同的方式调查。很显然，每个人都希望对申请人的知识、技术和能力做出评估。所以，针对招聘职位的类型不同，从团队的角度出发也许会要求申请人编写一些代码，或者创建一组测试。但是，每个面试官都会再以个人的角度去评估申请人，他会问自己：“我能和这个人一起工作吗？”“他能适合我们这个团队吗？”“他会让我们团队变得更强，还是更弱？”

此外，每个面试官将以自己在团队之中担当的角色去评价申请人。举个例子，如果申请人是一名开发人员，相较于团队里的开发人员，身为测试人员的面试官就会提出不一样的问题，以挖掘申请人的个性特征。

每个面试官也会根据自己的以往经验去评价申请人，问自己这样一些问题：“这个人展现出的技能与解决问题的方式，是我最为欣赏的吗？”“这个人在多大程度上让我回想起曾经合作愉快的同事，又在多大程度上让我回想起无法合作顺畅的同事？”“这个人是不是像他表现出来的那般优异，又抑或他是在假装如此？”面试官背景的多样性，使得团队可以从多个视角和价值取向来甄别将来的同事。

在把申请人交给下一轮的面试官之后，这一轮的面试官向经理——或者面对面地交谈、或者通过邮件，又或者拨打电话——就他对申请人的印象和意见发表个人的观点。每位职员都需要针对“假如由我来裁决是否雇用这个人”这个议题投下自己的一票。

如果面试一切进展顺利，申请人最终会回到经理这里，而此时经理也已经知晓了所有面试官对该申请人的看法。经理现在要从他自己的角度出发来面试申请人，然后告诉申请人是否得到了工作机会。即使其他的面试官都表示认可这名申请人，经理也可能会由于某些原因决定不对其提供工作机会。但是，如果团队的大部分成员都对该申请人倒竖起了大拇指，那肯定是没有理由再雇用此人了。

当团队在招聘过程中真正拥有话语权的时候，此时就出现了多赢的局面：

• 当前的团队成员是赢，因为新员工加入团队的时候，大部分的团队成员都已经跟他见过面——实际上已经接受了他；不被职员接受的那些人是绝对不可能跨过那道门槛的。

• 申请人也是赢，因为他处在了更有利的位置来决定是否要加入这支团队。他可以接触到未来的同事，而不仅仅是老板。他可以询问工作的真实情况，同时也可以感知公司的文化。

• 经理是赢，因为他可以借鉴整支团队在技术方面对申请人做出的评价，而不是仅仅凭借自己的揣测。他也知道团队在一定程度上已经接受了这个“新员工”，而且团队对他个人的成功也非常重要。

• 最终，团队作为一个整体也是赢，因为团队成员在参与同事预审的过程中，可以向其他人学习。在阅读其他人对申请人的评价时，团队成员能发现其他人使用的问题和标准，而他们可以在以后的面试中把这些派上用场。经理也能对自己团队成员的思维方式有更深的了解。

从经理的角度上讲，同事预审在雇用团队领袖的问题上面同样有效。为什么不邀请团队里的一些成员去面试未来可能成为他们老大的人呢？

不管申请人是开发人员、测试人员，抑或是经理，寻找到一位真正合适的人选从来都不简单，但往往又很重要。这是团队参与的项目。

“只有完成本垒打或者击球成功，管理才值得嘉许。”

——卡西·史丹格（Casey
Stengel）

（一）
与客户吃饭。客户抱怨，“我司人员流失大，无法建设团队文化。”我说，“以你司推行的工具为例，其思路就是把团队定位于低级、傻瓜式的水平。那么，超出这个水平的人离去、不足这个水平的人加入，不正是延续并巩固了这种傻瓜式的团队文化么？”

（二）
工具或许无关好坏，但要警惕的是工具传递的创建者的价值观。推广工具遭遇困境，原因就在于推广者的价值观与接受者不合，双方价值观上面的认同没有到位。如果以外力强制推行，甚至上升为价值标准，孔夫子曰：始作俑者，其无后乎？