第一章 项目管理失当

    说我“老顽固”，但我相信产品决定一切。有个好点子还不够，光努力也不够，几近完成也不够，你必须得最终让产品面市。

    微软的面试常常这样开始：“你都做过什么项目？”如果你最近没有什么成功案例，他们就会问：“为什么？”为什么？因为你不能提供产品你就不能向客户提供价值，你不把这次的任务完成，下一次你就不能接着干并不断提升水平，你没有客户你就没有客户回馈。

    人们常常抱怨他们的升职机会及回报与他们的付出不符。我说：“是的，就应该是这样。”这样会影响产品质量吗？不，你已经为产品设了最低的质量标准并成功推出了产品；那么这样会影响创新吗？不，创新者通常最初冒着低收入的风险来获得与他们成果等价的高回报。

    作者注：一些人报怨在微软对于创新思想并不给予丰厚回报。那是这些人并没有成功地使这些创新思想得以实现，能这样做的人已经成为我们机构及技术领军人物。

    一切从产品开始。这点特别适用于服务（译者注：指软件抽象层，如SOA），我也将在接下来的内容里重点讨论此类话题。评论家们声称在这一个以服务为主导的新世界中，微软已经忘了怎么去开发这些产品了。可能吧，但是确切地说比起其他公司所认知到的，微软不是忘了怎么开发，而是根本没想到要开发这些产品。我们需要一些提醒及培训，特别当IT业转而面向服务的时候。

    作者注：重在产品会导致死亡行军吗？不。相反死亡行军会拖延产品面市。就像我在“向死亡进军”中所说的：“死亡行军源于缺乏计划及勇气。”这对于理解服务的概念非常重要，在服务领域，产品要不断地推陈出新，这样才能保持长期成功。

    作者注：顺便提一下，对于这句话：“比起其他公司所认知到的，微软不是忘了怎么开发，而是根本没想到要开发这些产品。”我受到了很多批评。这句话听起来有些傲慢，往往让人感觉微软并不愿听取一些关于开发新产品的意见。确实，IMWright很自大而且为此很自豪，就像他声称的，在我们最终赶上对手之前，微软并不想听取这些意见，我们之前很多的竞争者也不认为微软有快速并反复听取这些意见的相关记录。有些人可能会说，“那是因为我们公司的规模（足够大）。”但是我们并不是总这么强大。有些人会说，“这是我们的策略。”但是策略并不是无懈可击的，你必须以正确的方法在正确的时间开发正确的产品。这需要耐心并不断学习。

    我为你提供了服务

    根据评论家的说法，就提供服务这点，微软忽视或失去了多少呢？也许还不至于让你如此确信评论家的说法，但足够引起你的疑虑。让我们带着些许欣喜来消除这种疑虑与哀叹。

    疑虑是：

    ·服务让你觉得什么都会变得不一样。

    ·服务注重数据，而套件产品注重功效。

    ·服务比起套件产品更关心安全性。

    ·服务在依赖性上存在严重问题。

    ·服务比起套件产品需要更高的质量以及更快的更新周期。

    哀叹与欣喜是：

    ·服务不是只在单个客户端上运行的，它是存在于几百台机器上的。

    ·服务必须有自我扩展功能。

    ·服务容易变换，而不像套件产品那么难。

    ·服务能即时升级以迎合人们的需求。

    ·服务是实时的，多变的。

    让我们拨开迷雾，从褐红鲱鱼开始。

    那是什么味儿

    服务面临的第一条褐红鲱鱼个头很大：“服务改变了一切。”就像我在“你的服务”（见第6章）所讲的：“完全不是那么回事。”就像其他所有产品一样，服务始终致力于帮助客户实现他们的目标，你得始终关注客户体验及他们所期望完成的目标，不然你就失败了。就是这样。

    接下来的三条褐红鲱鱼是——注重数据、安全问题以及依赖性问题。虽然之前已经花了我们不少心思去理解这些问题，但这与实现套件产品是一样的。无论在软件客户端还是服务器端，为了使数据格式的变化不被客户发现，你必须避免这种情况发生；在现今，不能说你的计算机产品或服务足够强大而不会受到攻击——你必须保证它们的安全；最后，如果你认为客户端的外部依赖性不存在问题，你就不会需要过多的驱动程序。我不是说这些不是什么真正的问题——而是说，对于服务来说这些问题不新鲜也不特别。

    最后一条褐红鲱鱼是再寻常不过的，服务实现与套件产品生产的不同之处在于其高可用性与互联网响应时间。看吧，套件产品经常会出故障或者当要正式使用它们的时候总要重启计算机，这样太糟糕了，出现像这样糟糕的事情已经有些时间了。服务同样要注重这样的质量要求，虽然很多服务产品也时常失败。

    关于互联网响应时间，在10多年前引入Windows Update后，这个问题就出现了。如果你认为这些补丁不过是修补一下安全问题，就不会引起太多关注。不管是服务还是套件产品，不断增加的客户体验问题在客户向我们提供报告之后如果能快速地得以解决，这样对于客户来说他们感觉会非常棒。

    然而，不是说逐日逐月地、渐近地提升客户体验就行了。不管服务还是套件产品都需要典型的、打包完整的升级包来为客户提供突破性的价值。Facebook不想像Vista一样逐步地升级为Windows 7，从而也使自己逐步升级为Twitter。因此，你必须关注客户真正要实现的是什么，而有些时候这些改变不是那么迅速的。

    作者注：了解发布产品的最好途径就是早发布，常发布。要让每个程序的“构建”都是可发布的“构建”，每天构建，且每星期至少对整个系统重新构建一次。定期发布技术预览版及测试版。定期发布将使产品逐步更新修复。早发布，常发布，生命在于运动。

    译者注：褐红鲱鱼，在18~19世纪的不列颠海域，鲱鱼被用做一种鱼饵，在那个年代没有冷藏技术，一般用盐腌制或烟熏后保存，烟熏后的鲱鱼就呈褐红色并有一种刺鼻的味道从而迷惑猎物。

    这里有太多问题了

    然而，并不是所有与产品实现相关的问题都适用于服务实现，还有心态、过程管理及团队协调需要你特别处理。

    首要的是，服务在分散于全球的多个数据中心上的成千上万台计算机上运行。有时候它们的功能与数据会有重复，有时候又不一样。通常，它的规模程度与可靠性亦步亦趋，这样会暴露出设计与同步性问题，很多书籍已经对此做过相关介绍（再读一次这些书也不会有什么新发现）；其次比较严重的问题是调试与部署问题。

    为什么调试一项服务这么困难？计时问题可谓是在多台机器、多个处理器的多个线程上的杀手。哎呀！然而，这还不是最要命的。

    在你调试一个问题的时候要做的第一件事是什么？分析栈，对吗？对于服务来说，栈分散在服务器与响应方之间，这使它几乎不可能跟踪一个特定的用户行为。好消息是，有一个工具可以有助于将分布于各个计算机间的行为进行关联；而坏消息是，这同样还不是最棘手的问题，最棘手的问题是你总是在一个实时的环境中调试，你得不到符号、断点或者逐步跟踪代码中每一步的能力。

    至此，让我们回顾一下。调试服务意味着在没有栈的、没符号的或在动态代码中没有断点的多台机器上调试繁琐的计时问题。只有一种解决方案——使用测试设备，有很多这样的设备，这样的设备是从一开始就针对某种服务设计好的，它预先考虑到了你以后将在一个无法进行栈跟踪、没有符号、没有断点的动态机器上调试。

    他们增长得太快了

    解决调试问题给我们带来了另一个重大困难——部署问题。部署应该是完全地自动化及轻便的。就拿安装程序时文件复制来说，要快速地复制文件，就意味着不用注册，不用用户干预，甚至不用指导用户干什么。

    为什么部署需要这么快速又简单？有两个原因：

    你正在将软件安装在运行着的、遍布全世界的成千上万的机器上。安装必须在无须人为干预的过程中进行，稍有复杂就会引致失败。记住，在1 000台机器上花五分钟就是三天半的时间。最好不要出什么问题。

    服务器的数量需要根据负载量动态增加或减少。不然，你就是为了满足高要求而在浪费硬件、浪费电源、浪费制冷以及带宽。因为你的规模决定于负载，它会随时变动。当负载变动的时候，你就需要自动且迅速地扩充系统。

    令人庆幸的是，有Azure可以为你在部署时分担重担（所以用这个就可以了，不用另外再开发类似工具），不过，你还是需要设计好你的服务以便于安装时快速复制文件。

    人生太无常

    有很多问题你可以预测，但不能预测的呢？服务在时刻不断地变化着。有些服务固定不变，它们保持着你的数据（像Facebook及eBay），而有些服务却不会（像搜索引擎及新闻）。稍稍几分钟的宕机就会让你失去数千的客户，数据损坏或丢失可能让你失去上百万的客户。他们马上会换地方，我们的竞争对手会很高兴地接受他们。这是把双刃剑，你必须努力去招揽新客户并留住他们。

    当你升级你的服务时，客户就会马上体验到最新版本的功能，而不是要过好几年。如果有一个bug在一个客户的上千次体验中发生一次，那么意味着这个bug也会在几千个客户身上发生（大数定律）。这样你就必须及时解决此类问题或者进行事务回滚。不管怎样，到星期五再更新服务绝对是个坏主意，而是应随时有个应急回滚按钮以应对不测。

    最后，应该认识到服务是实时的、变化着的事物。你可能会想，因为服务器是我的，是在我的构想中设立并配置的，那是一个可控的环境——那只是在你把机器开关打开之前。一旦服务器开始运行，这些都变了。内存使用在变动，数据及其布局在磁盘上也会变化，网络流量发生变化，系统负载也发生变化。服务像条河流而不是块石头，你不能刻舟求剑。必须随时关注它们，为使你生活得更轻松，要始终谨记五“重”自动化——重试、重新开始、重启、重新镜像、重置机器（虽然重新替换有时需要人为干预）。

    面对这些让人心烦的事，客户们很期望得到一些宽慰。一个理想的方法是建一个“点子检测”平台，因为你可以看到客户的不同看法并看看他们日常关注的是什么；同时应具备这样的能力：马上加以改进并在以后找出会间歇性诡异发生的bug（谨记五“重”方针）。

    返璞归真

    现在你明白了。围绕客户及其目标的传统的稳健代码编写方式是发人深省的。

    然而，如果缺少成果面市，这些什么也不是。要成功就要先有成果。是的，我们的质量标准已经有所提升，我们不是要王婆卖瓜，所以我们需要定期改进客户体验质量，不管是长周期还是短周期的；我们必须通过互联网、PC、电话去实践体验。我们必须服务好客户，让他们开心从而使他们更靠近我们。这是个长期的过程，但千里之行始于足下。