第2章 DevOps思想_大规模组织DevOps实践-QQ阅读男生玄幻网

上QQ阅读APP看本书，新人免费读10天

设备和账号都新为新人

第2章 DevOps思想

2.1 DevOps思想与生产流水线

近年来流行的 DevOps 软件工程模式，强调生产软件过程中的几个角色（如开发、测试、运维）之间的协作，强调软件生产过程中通过自动化的工具链组成软件加工的流水线，例如自动拉取开发代码版本进行编译构建、测试、部署等。目前看来，DevOps软件工程模式是最接近软件工厂的生产流水线模式。

2.1.1 DevOps的起源

2007年，比利时的独立IT咨询师Patrick Debois开始注意开发团队（Dev）和运维团队（Ops）之间的问题。当时，他参与了比利时一个政府下属部门的大型数据中心迁移项目，在这个项目中，他负责测试和验证工作，所以他不仅要和Dev一起工作，也要和Ops一起工作。他第一天在开发团队要保持敏捷的节奏，第二天又要以传统的方式维护这些系统，这种在两种工作氛围中的切换令他十分沮丧。他意识到开发团队和运维团队的工作方式和思维方式有巨大的差异：开发团队和运维团队生活在两个不同的世界，而彼此又坚守着各自的利益，所以同时在这两种环境下工作到处都是冲突。作为一个敏捷的拥趸，他渐渐明白如何改进自己的工作。

2008年6月，在美国加州旧金山，O'Reilly出版公司举办了首届Velocity技术大会，这个大会主要围绕 Web 应用程序的性能和运维展开，分享和交换构建和运维 Web 应用的性能、稳定性和可用性上的最佳实践。大会吸引了来自Austin的几个系统管理员和开发人员，他们对大会中分享的内容十分感兴趣，于是记录了所有的演讲内容，并决定新开一个博客分享这些内容和自己的经验，他们也意识到敏捷在系统管理工作中的重要性，于是一个名为theagileadmin.com的博客诞生了。

同年8月，Patrick也在加拿大多伦多的Agile Conference 2008上遇到了知音Andrew Shafer，两人后来建立了一个叫Agile System Administration的Google讨论组。

2009年6月，第二届Velocity大会在美国圣荷西召开，当时的Flickr技术运维资深副总裁 John Allspaw 和工程总监 Paul Hammond 一起在大会上做了一个题目为“10+Deploys per Day:Dev and OpsCooperation at Flickr”的演讲，演讲轰动了业界，也有力地证明了Dev和Ops可以一起有效工作提高软件部署的可能性。

Patrick在网上也看到了这个演讲并非常激动，受此大会的启发，他在比利时也发起了名为DevOpsDays的会议，大会非常成功，以至于大家在Twitter上的讨论热情不减，由于Twitter有字符的限制，于是大家就把Twitter上的话题 #DevOpsDays简写成#DevOps,“DevOps”一词便在社区中慢慢确立了。

2.1.2 DevOps对软件工厂的启发

通过 DevOps 的发展历程我们得到了一些启发，软件工厂里有各类工种，从事各类生产要素的加工，如开发、测试、打包部署等，如果缺乏有效的沟通和协作，以及一条高效的生产流水线，将这些工种的劳动过程有效地衔接起来，生产力必然无法提升。

2.1.3 从DevOps实践原则看软件生产工艺化水平的提高

我们继续回顾一下DevOps的发展过程。

在2010年之前，DevOps主要还是在技术社区中被讨论，探讨的一些开源工具也很少受到厂商和分析师们的关注。直到2011年，DevOps 突然受到 Gartner 分析师CameronHaight和451 Research公司Jay Lyman等人的注意，他们便开始正式研究这个市场，同时，一些大厂商也开始进入DevOps领域。

DevOps的发展也离不开另一个领袖人物的推动，那就是知名公司tripwire的创始人Gene Kim先生。2012年8月，Gene在他的博客上发表了“the three way”的DevOps实践原则，分别是：思考系统的端到端流程；增加了反馈回路；培养一种不断实验，以及通过反复实践达到精通的文化。Gene为DevOps领域贡献了一个重要的理论基础。2013年年初，Gene与KevinBehr和 George Spafford三人合著的《凤凰项目》一书出版，一度被誉为DevOps的圣经。

Gene的DevOps实践原则给我们最重要的启发是：软件生产过程中人的要素很关键，通过“培养一种不断实验，以及通过反复实践达到精通的文化”，我们可以在生产软件的过程中积累大量的工艺数据，实验在不同软件规模、复杂度的条件下，生产工艺、生产工具、生产技术的优化配置。而这些实验是很难在一次合同项目、小规模作坊中进行的。

2.1.4 软件工厂模式下对生产工具发展的促进作用

DevOps被业界快速接受离不开相关技术的同步发展，特别是云计算技术和基础设施的成熟，以及新的架构范式的出现。

2013年，dotCloud公司（后更名为Docker）推出Docker项目，在容器技术的基础上引入分层式容器镜像模型、全局及本地容器注册表、精简化REST。

同年，Google推出开源项目 Kubernetes，提供了以容器为中心的部署、伸缩和运维平台。Kubernetes支持Docker、rkt及OCI等容器标准，能够实现在各种云环境中快速部署Kubernetes 集群。

2015年，基于Cloud-Native（云原生）概念的逐步成熟，Google联合其他20家公司宣布成立了开源组织CloudNative Computing Foundation（CNCF）。同年，O'Reilly出版了 pivotal 公司产品经理 Matt Stine 写的 Migratingto Cloud-Native Application Architecture一书。书中，Matt Stine对Cloud-Native关键架构特征进行补充，也融入早在2012年由Heroku创始人AdamWiggins发布的“十二要素（The Twelve-Factor）”应用宣言等重要理念。此书较为完整地描述了Cloud-Native的落地方法和实践。

至2016年，随着DevOps应用的逐步深入，行业开始关注系统的安全和合规性，出现了DevSecOps等细分探讨领域，开始倡导Security as Code、Compliance as Code等新理念。

这几年是软件工厂所需要的相关基础技术协同发展的阶段。有了Docker，软件的开发、测试、打包部署过程得以标准化；有了云技术的发展，IaaS层技术帮助软件工厂解决生产要素中的资源供给问题；PaaS层技术的发展帮助软件工厂的劳动者们更加敏捷地组装软件系统并交付使用、持续运维。

2.2 从瀑布到敏捷

DevOps思想可以认为是敏捷开发思想的延伸和扩展，所以我们再来回顾一下敏捷开发思想的发展历程，以便更好地理解DevOps和软件工厂的理念。

谈敏捷开发思想就不得不谈瀑布模型。

瀑布模型的基本谬误在于：它假设项目只经历一个过程，而且架构是优秀的、易于使用的，对于实现的设计是合理可靠的，编码实现在测试进行中是可修复的。

换句话说，瀑布模型假设错误全发生在编码实现阶段，因此它们的修复可以很顺畅地穿插在单元和系统测试中。

特别是从项目管理的角度来看，它将各种工作角色隔绝起来，人们无法看到各个职责之间的关联性，更侧重于将工作扔到“瀑布后面的”下游团队。因此，各个团队就更像“我们与他们”式的独立团队，由此带来的结果就是，“现在的”工作是“我们的”,“以后的”工作是“他们的”。

2.2.1 传统项目管理问题

在传统项目管理的思想下，存在如下隐藏的假设。

1.范围管理

□ 范围可以完整定义。

□ 范围定义可以在项目开始前完成。

2.时间管理

□ 软件开发由截然不同的活动组成。

□ 可以对软件开发活动进行排序。

□ 总会有一种方式产生有意义的估计。

□ 项目团队的规模不会影响开发过程。

3.成本管理

□ 可以单独把团队成员分配给活动。

□ 一位开发人员等同于另一位开发人员。

□ 能够获得可接受的准确估计。

4.质量管理

指标足以用于评估软件的质量。

5.风险管理

风险可以接受、转移、避免、缓解。

2.2.2 向互联网企业学习的“敏捷”

国内传统企业（如银行、运营商等）企图通过导入敏捷项目管理模式来改变软件生产模式，但是目前看来效果不是非常理想。因为国内最先推行敏捷开发思想的互联网企业居多，而国内传统企业是从互联网企业学习，但是传统企业与互联网企业存在比较大的差异。差异体现在很多方面，例如，互联网企业可以是清一色的X86机器，而传统企业背负了很多历史包袱，有X86的机器，有小机也有大机等；互联网企业可以快速推出产品，带伤上阵找终端用户试错，而传统企业依赖第三方开发商的合同式开发，流程长、周期长、政策规范、监管严、试错成本高；互联网企业小规模团队协同，而传统企业部门众多……

这就导致传统企业向互联网企业的学习不灵了。

我们认为传统企业不能为了敏捷而敏捷，应该从敏捷的本质出发去学习和掌握敏捷。

2.2.3 敏捷的起源

大部分人所认识的“敏捷”是2001年17位方法学家在Utah-Snowbird会晤并进行了大量的讨论后所形成的“敏捷宣言”发展出来的软件工程方法。

而我们认为敏捷的缘起要追溯到20世纪20年代。

20世纪20年代，Frederick Taylor“科学管理”给每个工人发送指令卡，工人照此执行，管理者比工人更了解工作状态（这和敏捷没关系，但为后续的“知识工人”做了铺垫）。

20世纪50年代，美国国防部（DOD）和美国航空航天局（NASA）开始采用迭代式的增量方法（IID）。

20世纪60年代，科技发展，制造业岗位消减，“知识工人”产生，旧模式不再奏效，生产工具在人的头脑里，旧式的方法被提倡信息共享和劝导的新方法代替。同时，Thomas Gilb提出演化项目管理的概念（EVO方法）。

1970年，Winston Royce发表文章Managing the development of large systems，阐述瀑布方法的概念，并注解说明“是危险的并且可能导致失败”的原因，因为它将测试放到了最后。

1986年，Tankeuchi和Nonaka发表白皮书The New New Product Development Game，讨论了Scrum方法。

由此可见，很多传统企业向互联网企业学习敏捷是错误的，正统的敏捷早在互联网企业兴起之前就存在，我们不应该学习互联网式的敏捷，而应该回归正统敏捷。

真正有效的敏捷应该是自企业文化开始的敏捷，企业敏捷、组织敏捷才能使项目敏捷。互联网企业能轻易实施敏捷项目管理的根本原因是互联网企业自身的敏捷，互联网加速了人与人、企业与企业之间的沟通，为了快速应对市场变化，抢夺市场制高点，需要快速推出产品，抢占先机，在资本的推力下，甚至一个产品原型就可以推出市场，形成焦点效应，而互联网普遍面向C端客户的特点导致迭代式开发、边用边改成为可能。

2.2.4 瀑布模型

众所周知，敏捷是针对传统研发过程所采用的瀑布模型提出的，那么我们来看一看瀑布模型的起源。

在软件工程领域，Winston Royce 对于由于采用“先写了再说”的方法而造成的大型软件项目失败深感震惊，于是独立地引介了一种由7个步骤组成的瀑布模型，将流程加以整顿。事实上，Royce是将他的瀑布模型当作一个假想的批判对象提出来的，但是很多人已经引用并追随这个假想的批判对象，他提出的更为复杂精妙的模型反而被大家忽略。

什么是瀑布模型

1970年，Winston Royce提出了著名的“瀑布模型”，直到20世纪80年代早期，它一直是唯一被广泛采用的软件开发模型。

瀑布模型核心思想

瀑布模型核心思想是按工序将问题简化，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制订计划、需求分析、软件设计、程序编写、软件测试和运行维护六个基本活动，并且规定了它们相互衔接的固定次序，如同瀑布流水，逐级下落。

2.2.5 传统企业不可能全盘敏捷化

传统企业的IT形态有以下两类。

1.Mode 1——传统IT（Predictable IT）

□ 需求明确。

□ 相比追求速度，更倾向稳定性、安全性和标准化的IT。

□ 瀑布式开发模式。

□ SOR（System Of Record），记录型系统。

2.Mode 2——数字化IT（Nonlinear IT）

□ 追求和探索新业务设计、流程和模式。

□ 相比追求可靠性，更倾向速度。

□ 敏捷开发模式。

□ SOE（System Of Engagement），参与型系统。

因此，传统企业往往存在双模IT，什么叫双模IT？这是Gartner 2014年提出的概念。

一方面，传统企业为了保障业务的持续增长，安全生产运行依然是IT部门的首要工作。另一方面，云计算、移动化、社交化的技术浪潮极大地丰富了应用场景，依托于互联网架构的新应用不断出现，应用开发迭代周期从数月缩短为数天，秒杀、红包等突发性高并发应用需要更加弹性的技术架构。

如何同时运维管理这两种不同的架构，成为传统企业IT部门的一个巨大挑战。

2.2.6 从版本上线过程管理看敏捷与瀑布

从版本上线过程来看，瀑布模式的上线周期会更长，因为瀑布模式强调一次上线成功，为了最终上线成功，前面分了若干个阶段严格把控质量，如需求阶段、设计阶段、开发阶段、测试阶段。

而敏捷模式的上线周期会更短，因为敏捷模式强调多次高频率上线，每次上线周期内都或多或少包含需求分析、设计、开发、测试的内容。

传统企业，如银行的应用系统，基本上都是采用传统的开发模式。随着银行从依赖产品销售向客户服务转型，并鉴于传统模式对推出产品及服务的局限和相关内部管理问题，可以预见，在不久的将来，某些应用系统（特别是服务型系统）将会引入敏捷模式，而且这种趋势将会逐渐加快。因为随着金融行业管制和市场参与主体的开放，尤其是借助电子平台及新技术的非金融企业（如互联网金融）的崛起，行业的格局将发生重大变化，竞争将会加剧，各种金融创新将成为市场竞争的有效手段。这一变化反映在科技部门，将会是大量、迅速变化的新需求、新产品，甚至会出现对部分产品线的反复重构。

2.2.7 敏捷的前提是“不敏捷”

在传统企业，我们既会碰到RUP所强调的“每个管理过程和工艺过程都需要详尽的书面表达”，也会碰到敏捷所强调的“当面沟通”，我们需要一套新的管理方法帮助客户找到平衡。

我们尝试从银行的情况进行分析：敏捷开发的模式适用于银行应用的某些系统，由于银行是特殊的风险经营类机构，应用系统有其特殊性，还是需要因地制宜，即并非所有的银行应用系统都适合敏捷模式。一般而言，敏捷模式的优势需要建立在以下基础之上。

一是需求持续变更。

二是版本交付迅速。

三是系统适当松耦合，适于拆分，供一群小规模的团队相对独立地协同完成。

在银行内部的应用系统中，能够满足上述条件的是一些打算进入高度竞争市场的新产品，或者是原有产品线中变更和改造比较活跃的成分，再就是正在用传统模式开发但有必要被敏捷的项目。

双模IT模式下，造成了IT研发管理模式的分裂，导致某些号称采用敏捷方法的研发品质降低、管理结构混乱。因此，我们需要在面向敏捷的架构下（“冻土层”保持稳定），统一采用“工艺化+工作室”的方法，帮助客户找到平衡点，实现企业组织级敏捷。

2.3 敏捷与DevOps核心思想

2.3.1 增量开发与测试

软件开发就是调查研究。

软件开发是一个发现所选的软件是否能够扮演，以及如何扮演需要它承担的角色的过程。

毫无疑问，软件项目只是一个发现未知事物的过程：一旦未知的事物变成已知的事物，那么实际上项目就完工了。

迭代开发的定义：“需求定义、设计、实现和测试以重叠的、迭代式（而不是顺序的）方式发生，从而导致整个软件产品增量地完成的软件开发技术。”

迭代开发成了顺序的“瀑布”式开发的解药。

2.3.2 持续集成与持续交付

比较有意思的一件事情是，无论是敏捷、SAFe还是DevOps，在谈到开发过程的时候，都会强调持续集成作为一个最佳实践。

从成本效益、应对市场变化的速度来看，应用CI、CD非常有必要。

1.成本效益

一般而言，越迟发现 Bug，修复的成本越高。如果当场对刚写的代码进行测试，即使发现 Bug，查明原因并进行修改也是比较容易的。相对而言，如果不进行测试直接提交代码，3天后才发现有 Bug 会怎么样呢？两周后、1个月之后呢？那时程序员对所写的代码内容可能已经记不太清楚了，其他开发人员也可能对该代码进行过提交了，修改Bug的难度将大大增加。

实现 build 和测试的自动化，并且能够实施持续集成就能解决这个问题。通过实施CI，提交之后就能立即察觉是否有Bug 产生，修改Bug 的成本将大大降低，所以说CI的实施能大大提高成本效益。

2.市场变化的速度

如今的市场瞬息万变，特别是网站和App，一款产品的开发周期一般不足1～2年。在开发期间市场趋势很可能会发生变化，导致开发出来的产品失去作用。而且，Web之外的一些类似财务系统的业务系统，还会受到突然的政策修改等外部环境变化的影响。

如果每次都按照瀑布式的开发流程，从头开始全部实施，则很难跟上市场的变化。如果只是单纯地提早发布日期、缩短开发日程，而不在 CI 等方面下功夫，那只会造成Bug和功能退化频发，进而导致发布的产品质量下降。

3.兼顾开发速度和质量

如何才能既保持应对市场变化的开发速度，又保证高质量？CI能起到重要作用。

例如，编写能确保产品API正常运行时最低限度的测试代码并执行CI，在保证代码内容正常运行的基础上优先向市场进行发布。这个阶段代码的可读性和可维护性较差，功能添加也不方便，只是姑且能够运行并向用户提供价值而已。

确认产品能够正常使用之后，再用考虑了可读性和可维护性的代码来替代原来的代码（之前的代码牺牲了可读性和可维护性）。这是为了应对下一个阶段，即进一步添加必需的功能。

也就是说，初期速度优先，致力于尽快上市，之后再对代码进行重构来提高可维护性。而支持上述方式的正是 CI，有了 CI 上述方式才成为可能，既应对了市场的快速变化，又控制了确保可维护性所需的成本。

4.传统企业采用CI的趋势

随着企业对版本上线质量和速度的要求越来越高，迭代开发、敏捷开发模式的接受度越来越高，以互联网企业为首的企业开始广泛实践持续集成，并且结合运维前段工作向持续交付的方向发展。这一点不管是从业界讨论焦点，还是从国内外出版的书籍来看，都有比较明显的趋势。

持续集成更强调研发过程的质量控制，持续交付的范围更广，可以认为是“持续集成+自动发布”。

可以预见，互联网企业探索实践的这些方法论和相关技术，在传统IT领域会被逐渐地引入和采纳。但是传统企业与互联网企业存在比较大的差异，会导致持续交付应用方式的差异。

1.互联网企业

节奏快，版本发布频率高，上线出故障影响面广，但是一般影响度不高，通过完善的实时监控，发现故障及时发布新版本进行修复。

2.传统企业

第一类，节奏慢，版本发布频率不高，上线出故障影响面不广，影响度不高。这类企业对持续集成的需求不会太强烈。应用持续集成的目的更多的是希望开发过程规范化、透明化。

第二类，节奏相对慢，版本发布频率不算高，上线出故障影响面广，影响度高。这类企业对持续集成和自动发布都会有需求。应用持续交付的目的是希望把好版本发布的质量关，同时需要在研发过程中控制质量风险，所以需要持续集成。

第三类，节奏快，版本发布频率高，上线出故障影响面广，影响度高。这类企业一般已经在应用迭代开发、敏捷开发的模式，对持续集成、敏捷测试、自动化测试、自动发布都有强烈的需求。

2.3.3 自动化

尽量采用自动化的手段解决软件生产过程中的工作，如自动部署。“所有部署相关的作业都应该实现自动化”，诸如把WAR包上传到Tomcat等容器上的行为，这一系列的将开发代码以能够运行使用的状态放置到服务器上的行为都应该实现自动化。

自动化部署的好处有以下几点。

1.细粒度、频繁地发布可以使风险可控

部署工作本身就不是一件轻松的事情，如果几个月才能实施一次部署，程序就会有多个部分产生大量的代码修改。所有的修改都能正常运行自然最好，但现实往往并非如此。考虑到多个较大的故障同时发生所造成的严重后果，这的确是一个棘手的问题。而实现部署的自动化和简易化，就能够频繁地实施部署，对故障规模进行控制就成为可能。

2.能尽快地获得用户的反馈

部署得越早就能获得越多的用户反馈，尽快让用户体验新开发的功能，并将用户的反馈反映到下一个阶段的开发中。若能形成这样的良性循环，就能确立市场的优势地位。通过频繁地进行部署来回收开发的投资，才可能产生收益。

3.团队的规模可控

如果有10个产品，采用10种不同的方法手动实施部署会怎么样？每个产品每个月至少会有一次部署工作，那么负责部署的运维团队就需要专门的人员来实施部署。如果运维团队的人手不足，就可能发生新产品无法部署的情况。而如果实现了自动化部署，就不必担心运维团队的人手不足，就能够推出新产品并获得用户反馈。借助部署自动化，团队人员的规模变得可控，因此可以放心地增加产品数量。

2.4 规模化的敏捷

2.4.1 从敏捷项目管理到敏捷项目集群管理

纯粹的敏捷项目管理是以SCRUM等为代表的敏捷方法，适合小规模单一项目类型且偏互联网应用的项目管理。

而传统企业往往同时需要开展十几个到上百个项目的管理，并且这些项目往往是“双模”的，因此需要一套以敏捷为基础的组织级项目集群管理方法。

纵观银行内部系统，主要分为三大类：联机交易类、数据处理类、智慧银行类。

联机交易类系统关注客户资金处理和内部资金核算的准确、实时，尤其对资金安全的要求极高，因此对账户管理、资金汇划、信息服务、清算、对账、内部核算的全流程有着严格的要求，而且出于风险和业务管理的要求，银行内部部门的管理流程是另外一条主线。以资金为主的主线和以业务管理为主的主线决定了联机交易类系统是高耦合的系统，不适合全部采用敏捷的方法，可以从中选择适合的系统进行尝试。

数据处理类系统主要指报表、数据集市、数据分析（含数据仓库）类应用，这类系统基于联机交易类系统的过程数据，典型处理流程是：数据抽取、数据加载、数据处理、数据分析，这些关键步骤之间通过数据字典进行定义及关联，涉及系统之间体现的是松耦合关系，而且这类应用大部分属于非标准化功能，用户经常会提出较多的需求，是典型的敏捷模式特征。这类系统推广敏捷模式的最大制约因素在于缺少实时、统一、稳定的数据字典信息。

智慧银行类系统基于开放平台，面向新技术和新商业模式，对市场及客户群体的需求反应较快，始终关注客户体验，因此持续的迭代成为常态，并且这类应用与银行联机交易系统实现了适度隔离，与相关系统之间的耦合度较低，是最适合采取敏捷模式的。

2.4.2 企业规模化敏捷思想

关于“组织级敏捷项目群管理”，也就是“规模化敏捷”的话题，业界近几年已经有了积极的探索和实践。

现在的企业需要的不单是开发的敏捷，更是企业的敏捷。

敏捷开发的概念在过去十年间已经得到了广泛应用，也使软件开发团队能够开发出更好的软件。之所以能取得这样的效果，主要是敏捷开发的方法能够提高项目进展的透明度，同时用户还可以很早就预见产品的雏形，并与开发团队进行交流。然而，要达到商业目的远远不是开发出好软件这么简单，如果期望规模化敏捷必须先关注以下几个方面。

1.团队规模

试想一下，敏捷开发的方法应用在超过100人的开发团队中会有什么效果？当这支开发团队需要与其他部门在质检、集成、项目管理、市场运营等方面进行合作和沟通，以保证产品顺利交付时又会有怎样的问题？通常极限编程这类的敏捷开发方法只适用于7～10人的小型团队，而大型团队则需要分为几个小团队，同时需要和一些非开发的人员进行配合。目前已经有人在研究如何更好地解决团队规模所带来的协作问题了。

2.系统复杂程度

在通常情况下，大型系统会包括较多的特性和新技术，还要与其他系统进行通信和集成，并且要照顾不同用户群的需求。因此需要搞清楚是否有实时性、可靠性和安全性的要求，以及相关利益者是谁。通常复杂系统都需要经过严格的验证，这就使得敏捷开发中的快速迭代变得复杂化了。

3.项目规划

有多长时间用于系统开发？系统维护的周期是多长？通常大型系统所需的开发和维护时间都比敏捷开发适用的系统长一些，而且需要关注可能的更改和重新设计，还可能会被要求交付不同的版本，弄清楚这些有助于决定衡量项目成功的重要指标。

2.4.3 规模化敏捷方法——SAFe

传统行业从CMMI等重流程模式转向敏捷后，发现了敏捷的好处，同时也发现了在规模化应用敏捷时存在的不足。下面以金融行业应用 SAFe 为例看一下规模化敏捷实践应该如何开展。

当前，“互联网+”快速发展，对金融行业产生巨大冲击。互联网金融的到来，更是使传统银行业面临如何尽快占领互联网金融市场的挑战。在互联网金融新特性的驱使下，实现传统银行业务电子化的科技手段成为先导及载体，其是否能快、好、准地实现业务价值，将是市场竞争的重要因素。

另外，软件开发方法从17世纪培根提出“假设、实验、评估”的迭代雏形，到1971年的瀑布开发方法，再到21世纪Agile的诞生，根据其自身的需要经历着不断优化与创新。到2000年年初，敏捷思想逐渐进入中国，给中国的软件开发产业尤其是互联网相关的软件开发产业注入了新鲜血液。人们不断注意到 Agile 在应对市场的灵活性及客户的高满意度方面表现出来的强大优势，面临着软件开发方法的不断变革，软件行业内部势必也要不断优化。

在如此内、外部压力下，传统领域的软件行业均迅速反应并做出应对，在如何快速实现业务价值、不断优化自身开发方法等方面进行着Agile尝试及创新。但银行业的软件开发也有其特殊性，原有大型组织架构也是敏捷转型的一大障碍，如何在现有银行体系下进行本地化敏捷导入，以及进行敏捷适应性调整，将是转型及长久应用的关键。

1.SAFe是什么

1）整体框架

SAFe框架提供了三层管理模型，分别由项目组合、项目集、实施团队构成。

□ 项目组合级别：主要通过EPIC看板系统进行企业级业务、架构等战略决策的集中处理，并通过多趟发布火车进行分布式实施，此过程通过投资主题为各个版本的发布火车提供运营预算。

□ 项目群级别：将关注同一个基本产品、解决方案或价值主题目标的产品，或团队工作的特性和组件之间有高度的相互依赖关系的产品放在一辆发布火车中，通过项目集层面的节拍与同步化，多个团队在进度、范围方面产生对齐，帮助管理风险，并与组织价值流保持一致，实现企业级愿景。

□ 团队级别：各实施团队利用现有的SCRUM、XP实践实现增量交付，创建项目群的愿景、架构和用户体验。

2）需求管理模型

大型复杂需求在企业中是很常见的，这些需求特性可能来自多个产品团队，很多特性相互依赖，也存在优先级的冲突，这样拥有共同商业价值的需求会被放进一个共同的计划中，由多个团队紧密合作来实现。SAFe框架为这个挑战提出了三层管理模型的解决方案。那么现在再来审视这个框架，这里对需求进行了层次化管理，从投资主题到篇章，再从篇章到特性，最后到故事及任务。

从项目组合开始，通过企业级的投资场景看板提取符合企业发展愿景的高优先级EPIC，传递给项目集的产品管理团队来产生特性，以及通过优先级排序的特性待办列表。项目集的产品管理团队由项目集的产品管理人员和各个项目团队的产品负责人组成，最终由各个团队实现相关的故事，因此能够保证产品管理的一致性。

3）架构管理模型

需求与架构是硬币的两面，反映在需求表达中的“系统必须做什么”，以及反映在架构结构中的“为了满足需求，系统将如何构建”，因此它们不是孤立的。对于架构方面来讲，也应像需求一样存在组织级大规模企业架构到项目集架构最终到团队开发层级可控的架构层次。同时，系统本身也存在纯架构方面的大型调整，比如影响多种产品和服务的技术变化、公共架构治理、通过基础设施与避免重复工作而进行的通用架构调整、结构创新等。虽然敏捷中未定义架构师这类角色，认为设计架构是涌现的，是全权由团队负责的，但面对如上所述的全局或企业级、多产品级架构时，架构师或技术委员会必不可少。参考SAFe中提到的看板制度，具体如下。

□ 由架构管理部门识别所有的大型架构需求，将满足决策准则的内容提升到待办事项队列中。

□ 对投入待办事项队列的大型架构内容需要进一步评估，包括成本、价值、技术层面的调查。随着投入的增加，队列需要有WIP限制，以便限制过程中的活动条目数量。

□ 到达分析阶段需要进一步分析架构内容，此时需要架构师负责并启动与开发部门的积极协作，在WIP限制下进行替代方案设计、建模或确定采购、内部开发之类的工作。

□ 从分析到实现是一个重要的经济决策，因此需要产品/技术进行审批把控，最终到达实现层级的架构内容，需要架构师辅助团队直到其对所需完成的工作充分理解。

2.SAFe带来什么

规模化敏捷SAFe能给我们带来什么？

首先，其引入了大型需求、架构如何从愿景到实施团队的层次化管理。

其次，业务师、架构师、PMO、质量管理等人员可以考虑在各层级如何介入，比如在项目组合级别、项目群级别如何介入；考虑需求及架构的识别、评估、分析、分割、排优等。

最后，对传统项目、传统管理方法的启发。比如，利用精益敏捷方法对传统需求价值评估、从“项目管理”到“持续内容管理”的转变、对传统单项目管理思维的优化、从里程碑治理到基于事实的治理等。

2.4.4 规模化敏捷开发的最佳实践

各个企业的情况有所不同，所以如何应用这些最佳实践需要判断它是否能够使企业获益。特别需要注意企业的商业目的、现有的流程和企业文化，因为所有的实践都有局限性，不可能存在所谓的“万金油”。选择这些最佳实践时最好能让它们互相配合，而且要根据企业的实际情况做出一定的调整。

1.“团队协作”乃第一要务

Scrum是目前使用范围最广的敏捷项目管理方法。简单来说，Scrum开发环境只需要一个Scrum团队。这个团队需要具备需求分析、架构设计、编码及测试所需的知识和能力。

然而，在项目的规模和复杂程度增加之后，单一的Scrum团队可能就不能满足开发的需求了，这时就要根据系统特性和服务来划分不同的小团队。对于一个已经决定了要使用Scrum方法的项目，可以对各个Scrum小团队也使用Scrum方法进行管理。这就需要一个额外的协作团队，这个协作团队有以下两个责任：

一是确定团队之间所需交换的信息，解决团队之间的依赖性和沟通问题。

二是对团队之间的协作问题和潜在的风险进行分析并解决。

协作团队的成员通常来自各个开发团队，他们能够了解整个项目所有的功能，也可能有一些用户界面设计、系统架构、测试和部署的专业人员参与。这一协作团队可以帮助各个开发团队实现目标、问题和风险的交流与共享。

2.使用“Architectural Runway”来管理技术复杂性

严格的安全要求和任务关键需求会增加技术上的复杂性及风险。如果一项任务在一次迭代中无法完成，同时也无法分解成较小的任务交给多个小组并行，这就说明这项任务有着技术上的复杂性。要解决技术复杂性问题，管理员必须在项目早期就完成最重要的软件架构特性，有时甚至要将这个问题提升到整个企业的高度。在敏捷开发中把其叫作“Architectural Runway”，为以后的迭代提供一个相对稳定的基础，这对多个团队来说是很重要的。软件的架构可以决定系统特性的重要性，从而决定它们在开发中的优先级。通过定义“Architectural Runway”并在系统开发过程中对其进行扩展，开发团队可以优先开发“架构跑道”中的特性以满足用户的需求。

“Architectural Runway”也可以帮助开发团队在项目早期发现技术上的风险，并避免技术复杂性问题。此外，系统质量上的要求如安全性、可用性和性能也是越早确定越好，否则很有可能有大的改动，或者造成项目延期。开发系统功能时如果所需要的基础设施已经就位，也能增加需交付功能的确定性。

3.基于“特性开发与系统分解”的结合

敏捷团队通常的做法是在系统的所有组件中实现一个特性，这使得开发人员能够专注于完成对用户有意义的特性，而不必等待其他人开发完才能进行，这个途径被称为“Vertical Alignment”。因为系统中每个实现这个特性的组件都在各个团队中独立开发，但系统的分解可以是水平的，这主要基于系统的架构。这种方法主要被用于一些通用服务商，因为它们可以被更多地复用。

无论是针对特性进行开发，还是对系统进行水平分解，其目的都是根据系统的分解来安排开发团队，并且解耦，以便保持进度。当需要在敏捷稳定性和进度上保持平衡时，可以采用的策略是先开发一个通用服务平台，再在此基础上以插件的方式快速进行基于特性的开发。

4.使用“质量评估”决定架构上的需求

Scrum注重的是解决用户面对的特性问题，这确实也对系统成功与否起到重要作用。但当注意力完全放在功能特性上的时候，往往就会忽略架构上的需求。

建议在开发“Architectural Runway”时，收集、记录、沟通和确认潜在的系统质量上的要求。而对大型系统来说，其维护周期都比较长，所以这点尤为重要。在项目早期就应该对质量上的要求进行评估，以便决定哪些架构上的需求应该尽快满足，或者有哪些交付用户需求的捷径。

例如，一个系统要满足100万个用户的使用，那它是立刻就要满足100万个用户使用呢？还是它其实只是一个测试产品。再如，系统一般都会使用一些框架，理解系统质量要求可以帮助开发人员确定哪些架构上的需求已经被框架解决了。当需要解决安全和部署环境方面的需求变化时，架构上的需求必须给予最高的优先级。

5.在整个生命周期中使用“测试驱动”理念

用一句话来概括就是：“开发之前先写好测试。”如果开发的过程中只考虑正常情况，那么后期就会过度依赖测试来找出开发中忽略的情况。为了避免这种情况，在开发过程中就要考虑到异常情况。如果能够先写好测试，再使用测试驱动开发或验收测试驱动开发的方法，将使我们推荐的其他实践变得更有成效。

2.5 企业规模化敏捷与软件工厂

如同敏捷开发一样，DevOps在过去几年也是备受IT业关注的方法论。DevOps是针对Development和Operations之间的协作矛盾提出来的，但是如果引入敏捷开发，看起来矛盾会进一步加深，因为敏捷的一个重点是满足需求频繁变更，强调持续交付，即多版本交付，减少大版本带来的风险和不灵活性。

所以，DevOps应该实现企业从愿景开始，完成业务计划和需求到开发、测试、运维的端到端的企业敏捷，这样才能有效兼容敏捷开发的实践，发挥敏捷能效。

软件工厂采用标准化生产线的软件制作模式，企业规模化敏捷思想得以落地实施，是大规模集约化软件制造的必然之路。

2.5.1 软件生产环境

1.传统软件制作模式下的环境管理

传统模式下的软件生产环境，也就是通常所指的开发测试环境，往往与发布上线的生产运维环境存在比较大的差异。这将导致很多隐蔽的问题（如配置问题）引起生产运行故障，因为在差异化的开发、测试环境中，这些问题往往由于被忽略、无法模拟等原因而植入。

2.云开发测试环境

随着虚拟化技术的逐步普及，很多企业的运维部门开始采用虚拟化技术进行生产环境的管理，借助OpenStack等平台技术将X86机器组成的资源池，也可以开辟一个区域作为开发测试的环境。

我们来看一个例子：

国内一家核心金融机构的测试中心部门，随着公司新业务的开展，以及大数据时代的到来，金融软件系统逐步趋向于分布式、高稳定性、高可用的架构。软件测试工作不再像过去只需完成传统的系统测试即可，而是越来越趋于高度自动化、快速反馈、环境真实及非功能测试。

由于先前主要采用VMware为公司提供虚拟化软件服务，随着虚拟机数量的增多及部门的扩张，企业内部需要一个私有云环境来更好地规划、计算、存储网络等资源。通过对比VMware和OpenStack，该公司决定采用OpenStack来搭建该私有云平台。

这就是一个典型的基于虚拟化技术发展出来的开发测试云。云测试平台主要有两个目标：

（1）为开发测试提供虚拟资源弹性管理。

（2）集成现有测试工具提供云端的测试服务。

3.云原生应用开发测试环境

企业应用正在从单体向服务化架构演进，云原生应用开发逐渐成为主流。相应地，基于 X86虚拟化技术的云开发测试环境也在逐渐演进为云原生应用开发测试环境，以“Infrastructure as Code（基础设施即代码）”为口号的敏捷基础设施相关技术逐步成为采纳趋势，以SaltStack、容器等面向应用层的基础设施管理技术为代表。

在此敏捷基础设施的基础上，可以发展出更多适用于企业规模化敏捷的环境架构技术，如基于镜像封装应用的持续快速部署模式、弹性测试资源池、整合环境仿真等。

4.软件工厂生产环境

由于软件工厂模式下生产的软件形态大部分是云端生态应用，也就是以云原生应用为基础面向行业生态的应用，而云原生应用开发依赖云底座，很多开发行为是依赖云端生态基础架构进行的，开发过程的协同也是基于云通信（CC,Cloud Communication）进行的，如需求的沟通、源代码管理、测试环境管理等。因此，云底座、整合环境仿真、DevOps 生产流水线、项目管理平台、需求表达与管理平台、CC，甚至是云桌面等诸多技术，共同构成了软件工厂的生产环境。

2.5.2 软件工厂生产环境管理——开发测试云

1.基于虚拟化技术搭建开发测试云

下表是某金融机构基于OpenStack等开源技术搭建的开发测试云。

由下图可以看到，IaaS 层主要解决开发测试过程中的资源问题，在此之上还发展出TaaS层，主要用于解决开发测试过程中的配套服务，如测试环境申请、测试工具服务等。

2.基于容器技术搭建开发测试云

Docker是PaaS供应商dotCloud开源的一个基于LXC的高级容器引擎，Docker项目始于2013年3月，尽管Docker项目很年轻，然而它的发展势头如此之猛已经让很多人感叹不已了。

Docker的容器技术本身并不奇特，但是它所具有的一些特性，如轻量级虚拟化、秒级启动、镜像分层等，促使这样一个技术可以应用在研发和运维的诸多场景中，并有效地推动DevOps、持续集成等敏捷开发的发展与实施落地。

目前来看，Docker至少有以下应用场景。

（1）测试：Docker 很适合用于测试发布，将 Docker 封装后可以直接提供给测试人员运行，不再需要测试人员与运维、开发进行配合，进行环境搭建与部署。

（2）测试数据分离：在测试中，经常由于测试场景变换而修改依赖的数据库数据，或者清空变动 Memcache、Redis 中的缓存数据。Docker相较于传统的虚拟机，更轻量与方便，可以很容易地将这些数据分离到不同的镜像中，根据不同需要随时进行切换。

（3）开发：开发人员使用同一个Docker镜像，同时修改的源代码都被挂载到本地磁盘中。不再因为环境不同而造成不同程序行为而伤透脑筋，同时新人到岗时也能迅速建立开发、编译环境。

（4）PaaS云服务：Docker可以支持命令行封装与编程，通过自动加载与服务自发现，可以很方便地将封装于Docker镜像中的服务扩展成云服务。类似Doc转换预览这样的服务被封装于镜像中，根据业务请求的情况随时增加或减少容器的运行数量，随需应变。

Docker技术在测试领域的应用，可以体现在以下方面。

（1）快速搭建兼容性测试环境。从Docker的镜像与容器技术特点可以预见，当被测应用要求在各类Web服务器、中间件、数据库的组合环境中得到充分验证时，可以快速利用基础Docker镜像创建各类容器，装载相应的技术组件并快速启动运行，测试人员省去了大量花在测试环境搭建上的时间。

（2）快速搭建复杂分布式测试环境。Docker 的轻量虚拟化特点决定了它可以在一台机器上（甚至是测试人员的一台笔记本电脑上）轻松搭建成百上千个分布式节点的容器环境，从而模拟以前需要耗费大量时间和机器资源才能搭建出来的分布式复杂测试环境。

（3）持续集成。Docker可以快速创建和撤销容器，在持续集成的环境中，可以频繁和快速地进行部署和验证工作。

既然Docker可以给测试工作带来诸多便利，那么引入了Docker之后，测试的方式与传统模式会有哪些差异呢？

下面基于Docker的测试场景进行分析。

在开始测试之前，测试工程师需要确保自己的测试机上已经安装了Docker并处于运行状态，必要时需保证Docker的版本与最终生产环境一致。

测试环境搭建好之后，根据测试请求说明的镜像地址拉取镜像，并且按要求运行，根据镜像的目的测试所实现的业务。

如果在测试过程中发现 Bug 或不符合需求，应先尽快反馈给开发人员。开发人员修正后，重新将镜像推送到注册服务器，测试人员从镜像库拉取最新的镜像继续测试。反复进行操作直到能够发布。最后，测试人员发布测试合格报告，并注明最终的镜像版本。

如果多个测试工程师同时测试，各自使用自己的测试容器，Docker还能保证测试之间不被干扰。

另外，引入Docker之后，开发、测试、运维的协作模式也发生改变。

下面以一个简单的应用开发、测试和发布来说明Docker在阿里云ECS上的运用。

（1）运维人员在ECS上搭建私有Docker Registry。

（2）开发人员在开发ECS上从阿里云或私有Docker Registry获取应用需要的基础镜像。

（3）开发人员在开发ECS上构造应用容器，自测后交容器为新的镜像并推送到私有Docker Registry，通知QA测试。

（4）QA 在自己的测试ECS上启动容器并测试，有问题则通知开发人员修复，没有问题则交到私有Docker Registry，准备发布。

（5）发布人员下载最新版本镜像并在生产ECS上启动容器。

Docker的引入给传统的开发、测试、运维模式带来一些改变，对测试方式和测试工程师的技能也会带来一些影响。

（1）容器级测试。以后测试人员做的更多的测试都将基于容器进行，因此对容器的一些技术特性必须了解和掌握，如容器的创建、使用、监控等。

（2）测试前移。在传统开发测试模式下，开发通常将整体系统版本提交给测试进行验证，通常到项目周期的后期才能开展测试工作。现在基于Docker采用微服务设计、功能模块的容器化实现，可以开发一个容器（功能），测试一个容器（功能），所以测试得以前移，跟上开发的节奏，更符合敏捷开发的思想。

（3）集成测试。基于容器开发后，系统功能隔离到一个个容器，那么容器间的联系和功能交互就会变得复杂，测试工程师需要重点关注容器间集成的验证。由此带来的必然是容器级的打桩、模拟等技术的引入，目前还没有看到太多这方面的实践。

（4）自动化测试。给自动化测试带来的挑战则是容器层面的自动化控制（启停）、数据的验证方式、非界面层的自动化测试方式。

当然，由于容器的天然隔离性和环境搭建的快速高效、资源优势，使得自动化测试的并行执行得以更方便地实施。

（5）可扩展性测试。基于容器的部署发布带来的问题是：从运维角度，希望在测试环境充分验证系统的可扩展性，尤其是系统性能—容器资源的扩展曲线，以便后续实施容量规划。

2.5.3 整合环境仿真

随着敏捷的采用和发布周期的缩短，测试变成了瓶颈，而测试的瓶颈往往在于缺乏自动化测试及合适的测试环境。

目前来看，测试环境相关的问题包括：

□ 被测系统需要通过REST APIs等接口访问第三方在线服务（依赖第三方服务）。

□ 测试需要集成各类Web Services组件。

□ 使用到的测试数据不容易提供或不存在。

□ 开发和测试不能访问生产环境的大机服务。

□ 不容易访问已有的ERP等应用（不具备测试环境和测试数据）。

□ ……

对于当前充满竞争力的业务环境来说，推出市场时间和客户使用体验是业务成功的关键。我们需要在软件生产环境中通过整合环境仿真技术，对传统虚拟化技术无法涉及的受约束系统，或者无法任意使用的系统进行模拟。

在开发测试过程中，通过自动捕获服务、主机、云或基于SaaS的Web应用类受约束系统，并且对其进行建模、仿真不可用或不完整系统的行为与数据，在整个软件生命周期中作为替代物，并且消除约束。

整合环境仿真平台有助于降低用于开发和测试的相关IT资源所带来的时延、成本和风险。通过采用整合环境仿真平台，多个团队可以进行并行开发，更好地管理测试数据和用例，并减少所需的实时环境数量。这种方案不仅可显著降低成本和风险，大幅缩短周期，降低实验室在软、硬件方面的必要开销，还可加快向客户交付关键功能的进程。

1.测试环境虚拟化的需求分析

在传统企业，如银行，其业务信息系统需要随时追踪市场变化，不断创新和及时维护更新，每年会有数百个应用系统开发或更新项目，需要相对独立完整的开发和测试环境，面临着以下难题。

□ 有限资源下的充分真实测试：在有限的测试资源环境条件和有限时间范围内，如何尽可能为每个开发和测试项目独立真实地模仿实际生产系统环境，进行充分测试。

□ 测试资源的有效管理和高效利用：合理安排和分配有限的测试环境资源，避免特定开发或测试项目长期占用有限的IT设施资源，测试环境按需分配领用，快速准确部署、及时备份环境数据信息，为下轮次类似目的的进一步测试按需调出，迅速部署到新的测试环境中，实现测试环境和数据资产的高效复用，每次用完测试环境和数据及时备份后释放回收资源，提高资源利用率。

□ 搭建虚拟环境，以节省IT资源和工作量并减少相互影响：通常每个开发及测试项目都需要部署多个应用系统及配套数据，构成完整测试环境，如果100个项目平均每个需要部署3个应用及数据，完全独享测试环境模式总共需要300个应用系统和数据部署工作量及对应的IT环境资源。这无疑是不现实的。传统的做法是，有相同应用环境需求的开发或测试项目尽量共享一套多应用测试环境资源和数据，各测试项目之间相互干扰影响只能错时分批分区使用，常常导致项目延期，或者必须削减一些原本必要的测试。事实上，并非每个项目都需要真实的多应用测试环境，有些基于SOA架构的应用可采用虚拟仿真技术实现接口报文的服务模拟即可开展前期测试。因此，如果能有一整套方便、快速生成应用仿真虚拟服务的工具，就可以节省很多被仿真的后台应用IT设施资源，为每个项目独立构造有虚拟应用服务的测试环境。

□ 测试环境资产的积累和复用：每次测试环境的应用部署、仿真环境搭建、测试数据准备等实施和维护工作都非常琐碎、重复、易错，而且工作量极大，需要较高的技术水平和技能。通常的仿真应用开发缺少统一的规范，由各开发商自主开发实现。仿真水平和完成时间因人而异，需要局部修改或重复使用时协调难度大、时间周期长、维护成本高，大量重复相似的环境部署和仿真工作没有形成银行自身的知识资产并被积累下来。能否制定一套统一的仿真环境构建规范，把仿真定制的请求服务和服务响应配对报文作为银行测试环境资产予以记录备份和保留，不断积累、补充、修正，并形成不同目的需求的版本予以管理和调度，再根据不同测试场景环境需求高效准确地部署和复用，对于提高测试环境搭建准确性、加快部署进度、节约搭建维护成本，都是具有很高价值的最新需求和挑战。

2.银行开发测试环境场景分析

场景一：内部系统数量庞大，多个团队并行工作，工作环境相互干扰，业务测试环境不完整。

□ 内部系统之间连接关系复杂，一个完整的业务需要多个系统协同，多个开发测试团队并行工作，各个团队之间对环境相互干扰，使得开发测试团队在上线以前很难得到一个稳定的开发测试环境，一些缺陷在上线之后才会出现。

□ 内部系统由上百个子系统构成，彼此盘根错节，连接关系非常复杂。

□ 多个开发测试团队并行工作，环境难以完全隔离，程序调试、压力测试等对数据环境的不可控，造成共享环境各团队之间的相互干扰。

□ 数据环境的重置只能由开发团队重新构建数据，不能继承或重用以前的成果。

□ 为避免干扰，不许在共享测试环境为某应用做专项测试（如性能测试、连续跳日跑批等）。

□ 共享一套测试环境容易相互干扰和等待，常常影响测试质量，拖延测试进度。

□ 一个完整的业务需要多个系统同时正确存在才可以正常流转，各个系统的开发是并行存在的，测试环境中始终有不稳定的子系统存在，不稳定的测试环境造成有一些缺陷只有在上线后才被发现，造成损失。

场景二：测试环境搭建难、效率低、质量差、不可控，相互牵制影响。

某银行数百个应用测试项目同时展开，只能共享有限的几套测试环境。每个应用都需要与多个行内应用或行外应用（如人民银行、银联、财税、保险、水、电、气、通信商户等）联调测试，无论是IT设施资源需求量，还是环境搭建工作量、时间、成本方面，都很难为每个开发或测试团队独立准备一套测试环境，只能共享少量几套测试环境，有些应用只能用仿真环境模拟代替。因此常常遇到以下令人头疼的问题，致使测试环境管理成本很高。

□ 搭建不同应用仿真环境需要协调多家开发商，没有统一规范需求，质量效率很低，成果在各开发商个人手中，容易丢失散落，银行没有积累，难以复用，质量、时间因人而异，很难控制。

□ 多个测试小组共享一套测试环境和数据，容易相互干扰和等待，常常影响测试质量，拖延测试进度。

□ 应用变更或仿真需求调整，测试环境或仿真环境不能同步跟进，受制于开发商。

□ 协调开发商多次准备仿真环境，每次都很费事。

□ 为避免干扰，不许在共享测试环境为某应用做专项测试（如性能测试、连续跳日跑批等）。

□ 几套测试环境都需要同样的应用仿真，可能略有差别，缺少可复用、可定制工具。

场景三：专项测试环境IT资源独占需求太高，难实现。

为构造专项测试环境（如性能测试、日终结息批处理、某应用紧急变更上线前回归测试等）需部署多个应用，每个应用占用大量IT设施资源，常常产生以下问题。

□ 往往因资源不足，或者成本、时间等原因，不得不放弃此类测试，或者减少测试内容，或者降低仿真程度，其结果是加大了上线后才暴露严重缺陷的风险。

□ 有限IT资源难以安排环境做此类专项测试，轮流等待，进度必受影响。

□ 满足专项测试需求的代价是IT资源的大量投入和占用。

□ 频繁变换测试环境及仿真部署，缺乏统一规范、准确、快捷的手段工具，大量重复工作只能手工操作，质量、时间因人而异，效率低、易出错、成本高、不及时、经验知识很难积累和复用。

场景四：联调测试需要各应用都开发完成才能开始，不能提前用仿真环境来测试。

某应用A联调测试需要其他应用B仿真环境，但B应用发生变更未开发完，A应用联调测试就无法开展，带来以下问题。

□ A应用联调测试进度计划受制于B应用变更开发进度，或者B开发商是否有时间，是否愿意为A应用开发变更的B应用仿真版本。

□ 仿真测试环境数据不合理，只能协调B开发商，A测试不能自行调整，很不灵活。

□ 直接部署B应用还需要专门的IT设施，应用B资源需求如果太高、太多就难以实现。

3.整合环境仿真技术的典型应用场景

以上描述的传统企业，如银行，所存在的测试环境问题和场景，在软件工厂开发模式下也存在，通过整合环境仿真技术的应用可以解决这些问题。

1）提供完整、稳定、相互独立的测试开发环境

使用虚拟技术，在平时积累自学习真实的系统环境，积累完成后，在有环境需求的时候，可以快速高效地进行环境的复制，为每个开发与测试团队提供相互不干扰的独立的环境，即使是上百个内部系统也可以在一台机器上轻松虚拟，为开发测试提供一套完整的工作环境。

2）优化软件开发、测试流程

在软件开发设计和编码的前期，可以根据相关设计文档虚拟出尚未完成的需要交互的所有接口（环境），让各开发小组在开发的过程中就可以进行测试，更早地测试可以更早地发现问题，修复的成本也更低。由于在开发前期就进行了测试，因此在系统联调的阶段就会更加快速，进而可以更加有效地保证系统的上线时间。

3）提高功能测试的效率

通常的情况是多个开发、测试团队要并行进行测试，但是基础测试环境却远远不能满足这个要求，这样就出现了测试资源竞争的情况，极大地影响了开发、测试团队的工作效率。LISA可以快速虚拟出各个层面各种不同的应用，让每个开发、测试团队都有自己独享的测试环境，这样就可以做到并行测试，提高效率。

4）完成完整的性能测试

性能测试经常要和内部核心应用、尚未开发完成的应用、无法把控的第三方应用进行交互，而这些应用根本无法在同一时间提供，第三方（如银联）通常也不允许做性能测试，在这样的情况下是无法做到完整的性能测试的。LISA可以快速模拟上述难以把控的应用系统，让应用可以快速完成完整的性能测试，在上线前就可以掌握应用的实际性能情况。

5）有效管理测试数据

通常在多个应用要和同一套核心应用交互的时候，核心应用要为不同的应用准备不同的测试数据。即使同一套应用，每次升级做回归测试的时候也要把数据恢复到初始状态，这些工作就占用了很大的工作量。使用 LISA 构建的虚拟化实例里面都可以配置独立的数据，这些数据也是稳定的，这就极大地减少了测试数据准备的工作量，增强了测试数据的管理性。

2.5.4 不可忽略的办公环境因素

Tom DeMarco在《人件》这本书中提到“也许……软件系统的主要问题不在于技术，而在于社会性因素”，耐人寻味。

在大多数项目中，社会性的复杂度远比技术上的挑战要难处理得多。而且，不可避免地，我们还要面临一个更加严峻的问题：即使我们意识到社会性因素比技术上的因素重要得多，也从来没有用这样的思维观念管理过团队。虽然我们也会不时地改善团队的协作环境，或者缓解团队的紧张情绪，但这些事情从来没有成为我们工作的核心。

如果我们早就知道人的因素重于技术因素，我们的管理方式会有什么不同呢？

《人件》第二部分专门讲述了“办公环境”的问题。如家具警察：

“你应该不会感到诧异，管理你公司工作环境（特别是大型企业）的人不会花费太多时间来考虑上述问题。他们不收集任何原始数据，不花力气去理解产能这样的复杂问题。部分原因在于他们自己不会置身于这样糟糕的环境去开展工作。他们通常会组建家具警察（Furniture Police），采用的解决方案与你做的几乎背道而驰。”

家具警察的头儿会在员工进场前徘徊在新的办公环境里，边走边想：“看看这整齐划一的美丽环境！你都没法区分五层和六层！但是等员工进场了，一切都会被破坏。他们会在墙上挂照片，让自己在的那块空间变得更有个性，于是环境变得一团糟。他们可能想在我喜爱的地毯上喝咖啡，甚至在这里吃午餐（颤抖）。我的天哪，天哪，天哪……”这个家伙会规定大家到了晚上要清理每张桌子，除了公司日历什么都不允许挂。我们获知，有一家公司的家具警察甚至把咖啡洒出后的紧急处理号码印在每部电话机上。我们在那里时，从来不曾见过有人拨过那个号码。但你或许可以想象，一个穿戴如白领般的维护工开着电动清洁车，伴随着闪光灯和警报器的嗡嗡声在走廊做清洁。

Tom DeMarco倡导企业要关注人文环境、工作环境，研究人们怎么使用空间、需要的桌子空间多大、花多少小时独立工作、又花多少时间跟别人一起工作，调查噪声会在多大程度上影响大家的工作效率，毕竟大家都是脑力劳动者——需要大脑正常运转来完成工作，噪声会使大家不能集中精力。

人们更喜欢在自然光下工作，靠窗户感觉会更好一些，这种良好的感觉能直接转换为更高质量的工作。

具有警察思维的规划者设计出来的工作环境就跟设计监狱一样：用最小的成本达到最好的封闭性。

IBM 通过观察和研究程序员、工程技术人员、质量控制人员和管理者的日常活动，得出了最小标准的安置计划：

□ 每人100平方英尺的独立空间。

□ 每人30平方英尺的工作平面。

□ 封闭的办公室或6尺高的隔断来隔离噪声（他们的设计结果是，让超过一半的专业人士能工作在1～2人空间的办公室里）。

选择按照最低标准来建设办公场地的道理很简单：这些人需要这样的空间和安静的环境来高效工作。若因节省成本而造成办公环境达不到最低标准，将会导致工作效率降低，从而抵消节省的成本。

瞥一眼会议室，你可能会发现有三个人在里边静悄悄地工作。倘若你在下午早些时候经过食堂，可能看到大家一人一桌地坐着，桌面上摊着他们的各种东西。有些人你压根儿就找不到，都躲起来完成工作去了。假如你的组织发生了上述现象，就是在对工作环境进行控诉。虽然在环境上省了钱，却可能在其他方面浪费一笔不小的财富。

2.5.5 软件工厂质量检测——深度自动化测试装置

前面讲到软件工厂生产环境需要一套开发测试云，而开发测试云除了提供测试资源的管理，还提供测试服务（TaaS）。在软件工厂的模式下，我们探索出一套深度自动化测试装置，可以满足DevOps的需求，通过自动化的快速完整检测，实现软件出厂前的严格验证。

1.人工测试的弊端

传统模式下的测试需要一轮一轮地进行人工检查，费时又费力，容易遗漏、容易出错，明显不满足DevOps消除浪费及尽量自动化的原则，也不符合敏捷测试的要求。

2.传统自动化测试

传统模式的自动化测试通常借助商业或开源的自动化测试工具，如QTP、Selenium，通过模拟人工测试的方式操作GUI界面，控制应用程序按测试用例执行并检查功能是否正常。这种方式存在一定的弊端，包括GUI对象识别问题、稳定性问题、脚本维护问题等。虽然除了录制回放的简单模式，还发展出了模块化、数据驱动、关键字驱动，甚至是模型驱动的自动化测试框架和平台，但是都没有从根本上解决上述问题。这类自动化测试方式下，维护成本高、覆盖率不高，不能跟上敏捷迭代的速度。

3.分层自动化测试

谷歌早些年提出了分层测试的理念。