Darktea Home

-- James Hamilton – Windows Live Services Platform

0. 目的

本文是设计和部署易于运维的服务最佳实践的概括和总结.

先提出3个原则:

  1. Expect failures; 所依赖的任何服务都可能发生故障, 需要优雅的处理所有的故障.
  2. Keep things simple; 复杂性会引入问题; 任何一个 server 出故障不应该影响到 data center 的其他 servers;
  3. Automate everything; 引入自动化以后, 系统更可测试, 更可修复, 更可依赖;

这 3 个原则会贯穿整篇文章

接下来分 10 个方面讨论怎样设计和部署易于运维的服务.

1. Overall Application Design

80% 以上的运维事故的根源在于设计和开发. 所以 Overall Application Design 是最重要, 因为要从根源上解决这些问题的手段通常就是在设计上和开发上做改进.

而且开发团队, 测试团队, 运维团队需要尽可能的一起工作, 这样能减少运维的成本.

下面列举为了实现一个易于运维的系统, Overall Application Design 时最最重要的 5 大原则:

1) Design for failure

2) Redundancy and fault recovery

3) Commodity hardware slice

4) Single-version software

备注: 这里提到的 people-intensive 型的服务指的是: Those businesses tend to be more people intensive and more willing to run complex, customer specific configurations.

4) Multi-tenancy

除了以上的 5 大原则, 还有其他一些设计易运维服务时的 best practices:

2. Automatic Management and Provisioning

但是 Designing for automation 也会给服务 model 带来很大的限制 (例如, 数据库主从切换时可能丢数据, 要保证一致性 automation 的方式可能处理不好); 所以为了 automation, 服务质量上可能付出一定的代价;

下面列出一些 automation 设计的 best practices:

3. Dependency Management

As a general rule, dependence on small components or services doesn't save enough to justify the complexity of managing them. 两种依赖是可以被 justified 的:

假设现有的 dependencies 满足上面的那些规则, 那么 dependencies are justified.

对这些 可以被 justified 的 dependencies, 下面列举一些管理它们的 best practices:

4. Release Cycle and Testing

听起来比较危险, 但是实际上效果很好, 而且可以和灰度发布配合起来 灰度发布实际上会降低风险 (对比一下子把更新上线)

另外, 做做到了上面这些规则之后, 在白天上线比在半夜上线好:

下面列出 Release Cycle and Testing 相关的 best practices:

5. Hardware Selection and Standardization

用 services fabric 模式来进行硬件采购和管理. 使用 services fabric 模式保证了两个关键原则:

下面列举硬件选型相关的 best practices:

6. Operations and Capacity Planning

高效对 services 进行运维的关键在于: 构建一个系统来消除绝大多数的运维交互操作; 这个系统的目标就是要用 8*5 /周的人力来运维一个高可用, 7*24 的服务;

开发团队预先准备好针对紧急情况的恢复动作 (可以用脚本); 而且事先要在线上环境对这些脚本进行过测试; 如果这些脚本在线上环境测试风险太大, 那么到出现紧急情况的时候, 这些脚本也不安全, 不可用;

如果一个小问题没有按预先计划的那样被自动恢复, 在很多时候会引发大灾难

下面列举相关的 best practices:

7. Auditing, Monitoring and Alerting

对所有的线上操作进行记录. 一旦有问题, 可以从最近动了哪些东西来找原因;

Alerting is an art. 报得太多, 就会被忽略; 可以跟踪两个指标来判断报警是否合理:

下面列举一些 best practices:

8. Graceful Degradation and Admission Control

2 个 best practices:

针对这两点, 每个 services 都要度身定做; 这两点都非常重要:

9. Customer and Press Communication Plan

系统有问题时 (故障, 延迟比较大) 必须通知用户; 和用户的沟通需要有多种渠道;

有 client 的软件可以做很多有益的事情...

如果没有 client 而是 web page 的应用, 也可以有很多方式来和用户交流; 用户对系统状态了解更多, 用户的满意度就会更高 (系统的 owner 往往倾向于不告知用户系统的故障, 但我们的经验如果告诉用户, 用户满意度会高很多)

需要在平时提前准备好沟通计划; 每类事件需要提前计划好, 到时候 who to call, when to call them, and how to handle communications

10. Customer Self-Provisioning and Self-Help

用户自服务可以节约成本, 提升用户的满意度; 例如用户能登录 web page, 自己输入自己需要的数据, 然后就可以开始使用服务;