大规模服务设计部署经验谈（上）.pdfVIP

大规模服务设计部署经验谈 (上) 本文中提出的最佳实践，来自于作者多年大规模服务设计和部署的经验，为设计、开发对运营友好的 服务提供了一系列良好的解决方案。 ● 文／James HamiIton 译 ／赖翥翔 引言 本文的十个小节涵盖了设计和部 性约束，是降低管理成本和提高服务 本文就设计和开发运营友好的服 署运营友好服务所必须做到的各个方 可靠性的强心针。 务的话题进行总结，得出一系列最佳 面。它们是：整体服务设计；以自动 在运营友好的基础原则中，为整 实践。设计和部署大规模服务是一个 化和预置 (Provisioning)为目标进行 体服务设计带来最大影响的几条包括： 高速发展的领域，因而随着时间的流 设计；依赖关系管理；发布周期及测 ◆ 设计时为故障做好准备 逝，任何最佳实践集合都可能成熟并 试；硬件的选择和标准化；运营和容 (Design forfailure)。在开发包含多 完善。我们的目的是为了帮助人们： 量规划；审核、监控和警报；体面降 个协同运作的组件的大型服务时，这 ◆快速交付运营友好的服务； 级和管理控制；客户及媒体沟通计划； 是一条核心概念。这些组件会有故障 ◆避免清早电话铃声的骚扰，帮 以及客户自我预置和自我帮助。 发生，而且故障的产生很频繁。它 助备受运营不友好的服务侵扰的客户 们之间不会总是稳定地协作，也不会 尽量摆脱窘境。 整体服务设计 单独出现故障。一旦服务的规模达到 这篇论文是我们在过去的2O年中 一 直以来，人们都相信80％的运 10，000台以上的服务器和50，000块以 在大规模以数据为中心的软件系统和 营问题源于设计和开发，因此本节关 上的磁盘，每天就会有多次故障发生。 互联网级大规模服务的智慧结晶，包 于整体服务设计的内容篇幅最长，也 如果一有硬件故障产生就得采取紧急 括Exchange Hosted Services团 队、 最重要。系统出故障时，人们很自然 措施来应对，那么服务就无法以合理 Microsoft GIobal Foundation Services 倾向于首先去审视运营工作，因为这 的成本可靠地伸缩。整个服务必须有 Operations团队以及Windows Live r平 是问题实际产生的地方。不过，绝大 承受故障而无须人工干预的能力。故 台多个团队的经验。这些贡献经验的 多数运营问题都可以归因于设计和开 障恢复的步骤必须非常简单，而且这 服务中，有不少规模已经增长到拥有 发，或者最适合在设计和开发中解决。 些步骤应当进行频繁测试。斯坦福大 超过二亿五千万名用户。同时，本论 随后的内容凸显一个共识，即在 学的Armando Fox主张说，对故障恢 文也大量吸取了加州大学伯克利分校 服务领域，将开发、测试和运营严格 复步骤进行测试的最佳方法，就是绝 在面向恢复计算 (Recovery Oriented 分离不是最有效的方式。在环顾众多 对不要用正常方式使服务停机，用粗 Computing)方面取得的成果和斯坦 服务之后，我们发现了这样一个趋 暴的方式让它停转就可以了。乍听起 福大学在只崩溃软件 (Crash．Only 势——管理的低成本与开发、测试和 来怎么做是违背直觉的，但是如果没 Software)方面的研究经验。 运营团队间协作的紧密程度密切相关。 有频繁使用故障步骤，那么它们在真 _Jr] u uL 霎 Bill Hoffman为本论文贡献许多最 除了在这里讨论的服务设计最佳 正临阵时就可能溃不成军。 佳实践。此外，他还提出三条简单原则， 实践以外，随后一节 “以自动化管理