第二章 过程改进，没有灵丹妙药

    我是这么深爱着微软，我们拥有这么多的优越条件，这个公司拥有着一群充满智慧的人，更拥有富有生命力的产品及独到的视角，但时常还是有人那么无知——微软是一个海纳百川的公司，但这些无知足以让你发狂。

    再看我们的服务环境，这里有个我们自己的例子。目前我的团队已将服务环境分成软件开发、签入测试、情景测试、压力测试、跨部门整合、合作者整合、认证及生产等8个不同的环境——我们还计划在明年增建一个产前环境。但是一句给你泼冷水的黑色幽默是：即使拥有所有这些环境，仍然会有大量的毛病及意外只在生产环境中才被发现。

    为什么我们会这样挥霍无度？因为我们够资本（这很好但不是很好的借口），还因为还有很多老古董的企业工程师不明白服务的真谛：生产第一。这些工程师妄想万事俱备再行测试并奢望有一个难得的商业软件集成环境，他们仍这样执迷不悟。闭上眼，一起按下Ctrl+Alt+Delete键三次，好好反思：“生产第一，生产第一，生产第一。”

    作者注：虽然这是我最近才写的一篇专栏，但其已是我在微软所写专栏中最有影响力并被引用最多的一篇。我已收到多个管理级别部门的电子邮件，在其中详尽讨论了这个想法或直言说：“生产第一。”这让人倍感温馨。

    这事怎么就成了

    哪些傻瓜创建并维护着这些没用的服务环境？这些人毁了企业级软件开发。

    大型商业企业依赖于企业级软件——它们必须运行正常，否则他们不会购买。一旦他们购买了软件，他们就是所有者。企业级软件不是你想改就改的。是的，即使是打个安全补丁。

    记住，企业的支票是视软件运行是否顺畅而定的。软件的所有改动都直接给企业商务带来风险。如果软件出问题或运行欠佳或不能保持持久稳定，企业是不会买的。他们会跟你说：“打个补丁？这鬼主意不错。”

    微软所有的工程师都明白了这艰深的道理：在代码未经全部测试之前，你是不能发布软件的。企业级软件是不容许“重试”的。

    未经在生产环境中检测就发布软件，这是企业级工程师想都不敢想的。如果他们理解了服务的真谛，他们是该幸灾乐祸了。

    拜托，你不能认真一点吗

    软件服务的真谛是什么？生产第一位。让我们逐个击破这些关于测试与集成环境的神话：

    如果签入测试系统在某种环境中通过，那么它们在所有环境中都会通过。好的，这明显是错误的，但这里还有更糟糕的问题。写一些除了在生产环境而在其他地方都会失败的严谨的登录测试系统并不难（像广播测试及数据库镜像测试）。不要自欺欺人了，还是在开发人员登录之前，写一些完整的自动登录系统，使它们在其开发环境中快速运行。

    在将代码与合作方整合之前，你需要一个独立的环境测试各种情况。人们相信这一点有两个原因：他们不希望不稳定的代码破坏合作方的代码，以及他们不希望合作方不稳定的代码来妨碍测试。第一个理由很有道理——你需要一个测试环境来做一些验收及压力测试，特别是对一些关键组件。第二个理由就很可笑了——就好像，无论在什么状况下，你的合作伙伴都将确保你的测试环境无恙。他们不会，也不能（以下将详细说明）。

    你不想在生产环境中进行压力测试。为什么不？你担心生产过程会出意外？你不想知道为什么吗？这不是真正的目的吗？明白什么东西在可控情况下出问题并在必要时回退，这不很好吗？你还好吧？

    你需要在发布之前通过集成环境对跨部门情况进行测试，并提供产前环境对外部合作方进行访问。假设在进入生产环境前，跨部门运作良好；再假设，发布前外部合作方在另一个环境中已完工。你现在敢保证质量吗？不，都不敢。在生产阶段诸事难料，那时有更多的机器，不一样的负载条件，不同的路由及负载平衡，不同的配置，不同的设置，不同的数据及认证，不同的操作系统及补丁，不同的网路及不同的硬件。你会发现一些集成问题，但并不能说明这样庞大的开销是值得的。

    作者注：一个虚拟的云环境，就像Azure，会有这样的问题吗？不，它仅仅解决了不同的操作系统设置与补丁以及不同硬件问题。它对于其他问题来说也小有益处，但生产就是生产，不可替代。

    你需要一个受保护的认证环境。为什么你事先要验证一下产品？因为你想确定他们在生产环境中运行正常。哦，等会儿。

    我们来回顾一下，生产第一。你需要一个开发环境运行一些自动签入测试系统，一个测试环境来做验收及压力测试以防灾难性错误，以及一个生产环境。再多无益。

    作者注：最好是你的合作伙伴为你提供一个oneboxes为你的开发及测试环境所用，oneboxes是一些事先配置好的虚拟机，以其来运行这些你所需要的服务，这些虚拟机是一些压缩镜像。当然，oneboxes跟生产环境完全不同。