鬼谷子 书摘_书摘和评论：释放它！

鬼谷子 书摘

发布！：设计和部署由迈克尔·尼加德 （ Michael Nygard） 设计的生产就绪型软件 ，该产品获得了2008年乔尔特 奖提名 ，讨论了制作生产就绪型软件所需的条件，并解释了与功能完善的软件有何不同。 Nygard在他的网站上描述了写这本书的动机：

这本书来自我在生产系统中的丰富经验。 我经常是早上三点钟醒来的人，当时某个24x7的系统出现故障。

其他有关设计和体系结构的书仅告诉您如何满足功能要求。 他们可以帮助您的软件通过质量检查。 在“发布！”中，我将向您展示如何使软件生产就绪。 如果您不想佩戴电子皮带，则需要这本书。

Nygard还从本书中摘录了一些摘录 ，包括Sample Patterns和Sample Anti-Patterns ，以及Nygard的InfoQ文章《 5 am Production Problem》是该书的改编本。

InfoQ与Nygard讨论了该书涵盖的领域，以及有关该书的哲学如何与诸如Agile之类的概念相适应的一些问题：

InfoQ： “可投入生产”的软件和功能完善的软件之间有什么区别？

迈克尔·尼加德（Michael Nygard）：首先，人们所说的“功能完整”有很多差异。 即使只是充其量，也仅表示发行版的所有指定功能都已通过功能测试。 对于敏捷团队，这还意味着所有验收测试都通过了。 但是，在某些情况下，这意味着开发人员完成了代码的初稿并将其扔给测试人员。

“生产就绪”与“功能完成”正交。 无论验收测试通过还是测试人员给它一个绿色的复选标记，都没有告诉我有关系统在日常使用中在现实世界的压力下如何保持良好的状态。 可能可怕，可能很棒。

例如，是否存在内存泄漏？ 实际上，没有人在实际负载下一次在QA环境中运行测试服务器一周或一个月。 我们很幸运，总共进行了一周的测试，更不用说一周的寿命测试了。 因此，通过质量检查并不能告诉我有关内存泄漏的任何信息。 内存泄漏很容易投入生产。 好了，这现在带来了操作问题，因为必须定期重新启动应用程序。 我见过的每一次内存泄漏都是基于流量，因此，获得的流量越多，内存泄漏的速度就越快。 这意味着您甚至无法预测何时必须重新启动应用程序。 这可能是您最忙碌一天中最忙碌的时间。 实际上，它很可能在最繁忙（即最坏）的时间发生。

生产就绪的另一个方面是对我所谓的“瞬态脉冲”的适应能力。 这些是对系统的短暂冲击。 例如，当您的网站访问Digg.com的首页时或在FatWallet.com上显示价格错误的商品时，流量激增。 许多三层Web应用程序在必须一次创建大量会话时确实表现不佳。 与数据库或另一个后端系统的连接断开是另一种瞬时冲动。 这是一个问题，当事物开始降级时，系统崩溃的速度有多快。

我住在明尼苏达州的明尼阿波利斯。 即使在最佳时期，这里的高速公路系统也很少。 它很慢，但是功能正常。 您可以在华盛顿特区或加利福尼亚州湾区附近的疯狂通勤路线中直达目的地。 但是，您知道的是明尼苏达州。 一年在这里下雪几次。 当它发生时，高速公路系统变得非常糟糕，变得非常快。 基本上，每条高速公路都会同时停滞。 您可以想象有一个更坚固的高速公路网会更好地保持住，例如一英寸的积雪意味着一切移动的速度要慢10％，而不是慢200％。

您应该问自己有关系统的相同问题。 他们只在阳光下坚持吗？ 否则，当下雪时，他们会继续工作，而某些后端服务突然需要一分钟的响应时间，而不是250毫秒。

InfoQ：试图使功能完整的软件投入生产时会遇到哪些主要问题？

Michael Nygard：我认为这始于意识。 如果您是建筑师或开发人员，则需要在系统中设计良好的故障模式，就像汽车工程师将易碎区域设计成汽车一样。 迟早，体系结构图上的每个方框和箭头都会出现问题。 保证。 因此，您有责任确保在执行此操作时可以保留尽可能多的功能。

我看到的另一个重大挑战是测试。 其中一些问题难以测试。 我在书中讲述了一个崩溃的故事，该崩溃以一种非常公开的方式导致了一家跨国公司的破产。 巨大的后果。 它始于一些编写良好的异常处理代码与Oracle JDBC驱动程序中真正晦涩的行为之间的微小交互，该行为仅在集群故障转移和虚拟IP地址切换后才触发。 我们可以回想起来，一旦知道了要查找的内容，我们甚至可以分期复制它。 但是没有人，我的意思是_nobody_会预先预测它。 根本不可能考虑，更不用说测试任何有意义大小的系统中交互的组合多样性。

InfoQ：您能否举几个大型系统的示例，这些大型系统在尚未投入生产时就已启动，而失败是什么？

迈克尔·尼加德（Michael Nygard）：我的主要例子是一家零售商，几年前它推出了一个全新的互联网平台。 我们进行了三个月的负载测试和性能调整，以达到Marketing的预期。 我们启动了该网站，它在15分钟内崩溃了。 为什么？ 好吧，我们已经对其进行了负载测试，但是在某种意义上我们做到了“不错”。 例如，我们所有的VU都使用cookie。 我们发现，应用程序开发人员所做的某些事情使站点对于会话非常脆弱，并且任何不使用Cookie的浏览器都会创建大量会话。 我们的VU都没有尝试过每秒从同一会话中敲击同一URL六到十次，因此负载会分散在多个应用服务器上。 我们还没有准备好使用屏幕刮板和商店机器人。

假设您是新dotcom系统上的开发人员，并且有一些测试人员向您问道：“我正在记录您代码的缺陷，因为当您用相同的URL每秒访问10次相同的URL时，该缺陷会中断不要使用Cookie。” 是的，对。 幸运的是，当我们仍然不能在当月的奇数天拿美国运通卡时，优先考虑这一点。

我认为，即使测试人员确实报告了该错误，也会通过参考需求文档（即我们仅支持使用Cookie的浏览器）将其关闭。 好吧，好的，所以您只想要使用cookie的客户。 但这并不意味着如果有人将非Cookie脚本指向该站点，站点就应该崩溃。 事实证明，许多业余脚本编写者不知道如何使用Cookie，但是他们知道如何运行“ wget”或“ curl”或使用VB来访问网页，并且很多人对某些东西感兴趣像XBox360。猜猜是什么？ 无论您是否要支持他们，他们都将访问您的网站！

InfoQ：应用程序稳定性遇到哪些常见问题，如何解决？

迈克尔·尼加德（Michael Nygard）：我在书中谈到了许多具体问题，称为稳定性反模式。 为了解决这些问题，我介绍了一组稳定模式，它们非常适合解决各种问题。

如果可能的话，元问题是优美的降级。 它来自将系统视为一个单一的整体实体。 从用户的角度以及从赞助者的角度来看，“系统”实际上是一组相互关联的功能。 有些功能比其他功能更重要，因此您应该努力保留尽可能多的重要功能，同时抛弃以某种不稳定的方式出现问题的功能。

例如，如果您问：“当我们无法显示该位置的本地餐厅列表时，客户是否仍可以在酒店网站上预订房间？” 你可能会被嘲笑。 这些功能似乎没有远程连接！ 为什么只因为某些第三方本地搜索功能不起作用而停止预订？ 嗯，但是这些功能是耦合的，因为两种页面请求都由同一应用服务器中的相同请求处理线程池提供。 因此，如果该本地搜索服务变慢或完全停止响应，并且您让所有请求处理线程永远阻塞，等待响应，那么您就已经允许非必要功能破坏了企业的核心。

InfoQ：应用程序容量遇到哪些常见问题，如何解决？

迈克尔·尼加德（Michael Nygard）：我通常会看到很多具体问题，我将它们写为“容量反模式”。 他们大多来自不考虑乘数效应的建筑师和开发商。

我举一个例子。 每个零售商都有某种类别结构来组织其产品目录。 该结构通常以某种菜单的形式显示在网站的导航中。 每当看到这种情况时，我都会问几个问题：“类别结构多久更改一次？” 和“多久显示一次？” 答案总是类似“一个月一次”和“每秒四百次”。 那么为什么要动态渲染呢？ 以防万一它改变了，您需要在7纳秒后显示新结构吗？ 这没有道理。 在内容发布期间，一次将菜单呈现为HTML效果更好，而只是在每个页面显示中将其片段化掉即可。 （最好还是将其推出到Akamai中，然后让它们通过边缘脚本将其塞入您的页面中。）

因此，在您的系统花费资源的任何地方，请问自己什么是乘数效应。

InfoQ：除了稳定性和容量之外，还会发生其他什么类型的问题？

Michael Nygard：我通常还会看到另外两个问题：不透明或刚性的系统。 不透明的系统就像生病的金鱼。 它要么生存要么死亡，并且对此您无能为力。 该系统不会告诉您它的运行状况，无论它是否健康。

幸运的是，这种情况正在改变。 我看到了更多的监视意识，尤其是使用Nagios和Zenoss等免费软件。

刚性系统是无法发展的系统，或者只能在困难和停机时间内发展的系统。 需要我重新启动系统才能部署代码或内容的系统。 那些版本锁定了一半企业的人员，因此我必须安排一个大规模的“升级公司”日，随之而来的是高风险。

InfoQ：操作如何适合生产就绪软件？ 他们是否参与了开发过程，是否在规范方面提供了帮助，在产品即将发布时受到了培训等？

迈克尔·尼加德（Michael Nygard）：操作对于创建可投入生产的软件是必不可少的。 在开发和体系结构中，有一种趋势是保持太长时间抽象。 我认为，具体了解您的部署体系结构具有很大的价值，而Operations可以帮助您做到这一点。 制定您的目录结构。 您将如何以易于回滚的方式发布代码？ 如何将代码与激活代码分开推送？ 每个解决方案都有简单的解决方案，仅涉及与操作的一点沟通和协商。

作为一种可能的解决方案的示例，如果您使用的是UNIX，则可以使用为发行版命名的目录，并带有指向当前发行版的符号链接。 因此，如果商店的1.5.2版本是最新的，则可能会有一个“ store_1_5_2”目录，其中包含一个名为“ store”的符号链接。 然后，当您要推出版本1.6.0的代码时，请将其部署到“ store_1_6_0”，在此位置等待Operations更新符号链接并退回应用服务器。 不难看出如何在构建过程中直接构建该机制。

要考虑的另一件事是，Operations已经具有要启用的许多系统。 我确定他们已经有了某种监视解决方案，因此您需要使您的系统正常运行。 他们甚至可能拥有一个CMDB来跟踪应用程序之间的版本和依赖性。

最终，您对运营的支持越好，他们对系统的支持就越好。 如果您喜欢整夜睡觉，那么您真的想启用它。

InfoQ：创建可投入生产的软件所涉及的前期工作与敏捷想法之间存在一种张力，即只有在需要时才做某事，并在必要时进行重构-您对此有何想法？

迈克尔·尼加德（Michael Nygard）：作为一名敏捷开发人员，我自己为这种紧张而挣扎。 我没有解决这个问题的完美答案，但是我认为优秀的面向对象设计在这里与之相似。

一旦编写了一些代码并通过了一些单元测试（无论哪种测试通过了），都可以重构代码以改进设计。 “提高”。 那么，改进设计意味着什么？ 这不是意味着您必须对面向对象设计有一些“更好”和“更差”的概念吗？ 确实如此，这就是Martin Fowler重构中的“代码味道”出现的地方。“代码味道”是一种讨论更好和更坏设计的定性方式，而又不会完全束缚指标。

我认为该体系结构也有类似之处。 对我来说，没有超时的远程呼叫是一种“体系结构气味”。 SOAP调用或REST GET也是如此，它试图在不施加限制的情况下为客户获取所有订单。

因此，尽管我不赞成采用大型设计或“大型设计”，但我确实相信在系统中定义边界，在其中设计故障模式并消除我们遇到的“架构异味”。

InfoQ：您是否认为软件或API（例如Hibernate Shards，Puppet）有助于创建可投入生产的软件？ 如果没有，您是否认为可以创建这样的软件，或者这严格来说是体系结构或学习问题吗？

Michael Nygard：我想现在是发布产品的理想时间。 我还没有。 我认为这是正交的。 框架开发人员，产品供应商开发人员，应用程序开发人员...我们都是开发人员。 我在供应商代码和框架代码中看到的安全性变化与在应用程序代码中看到的相同。 因此，框架代码并没有自动的方法。

正确编写好的框架可以提高生产就绪性，就像Doug Lea的并发库大大改善了Java线程安全性和并发性一样。 但是，最终，我们必须对产品和框架充满信心。 事实证明，胜于闪亮，开放胜于封闭，而且在现实世界中，多样化的生产寿命比其他任何事情都要重要。

翻译自: https://www.infoq.com/articles/nygard-release-it/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

鬼谷子 书摘