来自 Google 的高可用架构理念与实践
Google 设计系统时,在可用性、可靠性上面,有哪些理念和思考?本文来自Coding.net 的 CTO 孙宇聪,他曾在 Google 总部担任SRE(全称是 Site Reliability Engineering ,基本相当于国内的运维,但是更偏开发)。他参与过 YouTube 的运维管理,以及 Google 的云平台团队,并担任多个项目负责人。
孙宇聪首先介绍了决定可用性的两个概念:MTBF 和 MTTR。
MTBF: Mean time between Failures。 用通俗的话讲,就是一个东西有多不可靠,多长时间坏一次。
MTTR: Mean time to recover。意思就是一旦坏了,恢复服务的时间需要多长。
一个服务的可用度,取决于 MTBF 和 MTTR 这两个因子。从这个公式出发,结合实际情况,就很好理清高可用架构的基本路数了。那就是: 要么提高 MTBF, 要么降低 MTTR。除此之外别无他法。
接下来,孙宇聪介绍了实现高可用的两个方案,每个方案各有三个必须要注意到细节:
方案一:提高冗余度,多实例运行,用资源换可用性。
- N + 2 应该是标配。
- 实例之间必须对等、独立。
- 流量控制能力非常重要。
方案二:变更管理(Change Management)
- 线下测试(Offline Test)
- 灰度发布
- 服务必须对回滚提供支持
最后,孙宇聪提供了可用性的7级图表,供读者检查自己服务的可用性级别:
- Crash with data corruption, destruction.
- Crash with new data loss.
- Crash without data loss.
- No crash, but with no or very limited service, low service quality.
- Partial or limited service, with good to medium service quality.
- Failover with significant user visible delay, near full quality of service
- Failover with minimal to none user visible delay, near full quality of service.
金句:
一般一个服务只要你不去碰他一年都不会坏一次。更新越频繁,坏的可能性就越大。凡是 Software 都有 BUG,修 BUG 的更新也会引入新的 BUG。发布新版本,新功能是 MTBF 最大的敌人。
想要提高可用性,必须要和开发团队找到一个共同目标。这里再给大家一个秘籍,那就是 error budget。跟开发团队确定一个可用度,比如说 99% 。 如果业务团队搞出来的东西很烂,各种状况,最后达不到这个标准。那么对不起,暂时别发新功能,只修 BUG。
标签:Google、可用性、架构、发布 |