15 如何向面试官证明你做的系统是高可用的?

我们已经用了五个模块分别讲了架构原理、分布式技术、中间件、数据库,以及缓存,这些都是面试中必考的技术领域和技术点,又因为我们处在大数据和互联网时代,所以高可用高性能这些非功能性需求的考察,也是你需要了解的,所以在最后一个模块,我会带你打卡高可用高性能的架构设计面试实战。

我在 01 讲中说过,高级研发工程师和架构师的区别不在于掌握了多少技术,而在于你所能驾驭系统的边界。这其实也反映了一个研发工程师的成长历程,起初独立负责一个功能,然后负责一个系统模块,再负责一个系统,最后负责多个系统或业务条线。

但是不管你在哪个阶段,有一个问题你肯定逃不开:怎么证明自己负责的系统是高可用的?因为任何一个系统架构初衷,最基本的诉求是要保证系统的稳定性和可用性,然后才是基于高流量的场景下,保证系统的并发承载能力。

案例背景

一般来讲,面试官在考察你系统架构的设计能力时,经常会让你说一下你在上一家公司是怎么设计系统架构的,以此了解你的设计能力和思路。

而你在讲解架构设计时,也是在向面试官逐步证明,自己负责的系统是如何做到高可用的。这会涉及一个公认的论证——SLA。服务等级协议(Service-Level Agreement,SLA)最根本的形式是协议双方(服务提供者和用户)签订的一个合约或协议。这个合约规范了双方的商务关系或部分商务关系。简单点儿说,你可以认为 SLA 是服务可用性一个重要衡量指标。

业界一般用几个 9 的 SLA 服务等级来衡量互联网应用的可用性。比如京东的可用性是 4 个 9(京东的服务 99.99% 可用):京东的服务要保证在所有的运行时间里只有 0.01% 不可用,也就是说一年大概有 52.6 分钟不可用,这个 99.99% 就叫作系统的可用性指标。

52.6 分钟是怎么计算出来的呢?

Drawing 0.png

SLA 的计算公式

从公式中可以看出, SLA 等于 4 个 9,也就是可用时长达到了 99.99% ,不可用时长则为是0.01%,一年是 365 天, 8760 个小时,一年的不可用时长就是 52.6 分钟,那么:

可以发现,用 SLA 等于 4 个9 作为参照物,少个 9 相当于小数点往后移一位,多个 9 相当于小数点往前移一位(我把系统可用性指标总结成一张表格)。

1.png

系统可用性指标

那么问题就来了: 既然 SLA 是服务可用性的一个衡量指标,那么你在面试时,怎么设置这个指标的阈值才合理呢?

在电商平台中(比如淘宝、京东、拼多多),系统可用性大多是 4 个 9。那么你在回答时,一要了解 SLA 的概念,N 个 9 代表什么含义,更要清楚互联网对于 SLA 的主流设定阈值。

讲到这儿,你可能会觉得:那我清楚了 SLA 的概念,然后也了解了 SLA 的主流设定阈值,当面试官问我“你们的系统高可用做得怎么样”时,我回答系统做到了 N 个 9 是不是就可以了?

案例分析

给你 10 秒钟的时间思考一下,当面试官听到你按照时间指标度量系统可用性,会不会满意?

要知道,任何一家互联网公司,都有流量的低峰期和高峰期,你在低峰期停机 1 分钟和高峰期停机 1 分钟,对业务影响的结果完全不同。如果认识不到这一点,面试官很容易认为你很业余,并没有实践经验。

所以,仅凭理论指标在有些情况下是不能满足实际需求的,那有没有更加科学的度量方式呢?答案就是基于一段时间(比如 1 年)的停机影响的请求量占比,进行评估,公式如下:

Drawing 2.png

这样一来,你就可以评估,业务在高峰期停机和在低峰期停机分别造成多少的损失了。所以,如果你再回答系统高可用指标的时候,我建议你可以遵循这样的套路:先摆明度量的两种方式,“N 个 9” 和 “影响请求量占比”,然后再结合实际业务场景表明第二种方式的科学性。

总的来说,作为候选人,要立足业务价值去回答问题,不是仅停留于技术概念的堆砌,这才能体现你的思考。

当然了,以上的内容基本可以满足你应聘初中级研发工程师的需求,如果你要面试高级研发工程师或者是架构师,你还要有一个思路的闭环。为了方便你的记忆,我把这个思路总结为:“可评估”“可监控”“可保证”。

所以,当你向面试官证明系统高可用时,其实是在回答这样几个问题:

接下来,我们继续学习“如何监控系统高可用”至于“如何保证系统高可用”我将在下一讲中为你解答。

案例解答

我们以设计一个保证系统服务 SLA 等于 4 个 9 的监控报警体系为例。监控系统包括三个部分:基础设施监控报警、系统应用监控报警,以及存储服务监控报警。 接下来,我就围绕这三个最核心的框架带你设计一个监控系统,并基于监控系统的设计,让你了解到系统哪些环节会影响系统整体的可用性,从而在面试中对系统高可用设计有更加清晰的掌握。

基础设施监控由三个部分组成:监控报警指标、监控工具以及报警策略。

监控报警指标分为两种类型。

  1. 系统要素指标:主要有 CPU、内存,和磁盘。
  2. 网络要素指标:主要有带宽、网络 I/O、CDN、DNS、安全策略、和负载策略。

为什么我们要监控这些指标?因为它们是判断系统的基础环境是否为高可用的重要核心指标。

2.png

监控报警指标

监控工具常用的有ZABBIX(Alexei Vladishev 开源的监控系统,覆盖市场最多的老牌监控系统,资料很多)、Open-Falcon(小米开源的监控系统,小米、滴滴、美团等公司内部都在用)、Prometheus(SoundCloud 开源监控系统,对 K8S 的监控支持更好)。这些工具基本都能监控所有系统的 CPU、内存、磁盘、网络带宽、网络 I/O 等基础关键指标,再结合一些运营商提供的监控平台,就可以覆盖整个基础设施监控。

监控报警策略一般由时间维度报警级别阈值设定三部分组成

3.png

监控报警策略

为了方便你理解监控报警策略,我举个例子。假设系统的监控指标有CPU、内存和磁盘,监控的时间维度是分钟级,监控的阈值设置为占比。那么你可以定义出如下的监控报警策略:

4.png

为了第一时间监测到指标的健康度,报警级别可以分为紧急、重要,以及一般。当 CPU、内存,以及磁盘使用率这三项指标的每分钟采集的指标达到 90% 使用率时,就触发“紧急报警”;达到 80% 触发“重要报警”;70% 触发“一般报警”。

业务状态监控报警,关注点在于系统自身状态的监控报警。和基础设施监控一样,它也是由监控指标,监控工具,报警策略组成,不同的是,系统应用监控报警的核心监控指标主要有流量、耗时、错误、心跳、客户端数、连接数等 6 个核心指标,监控工具有 CAT、SkyWalking、Pinpoint、Zipkin 等。

5.png

系统应用监控

一般来讲,常用的第三方存储有 DB、ES、Redis、MQ 等。

对于存储服务的监控,除了基础指标监控之外,还有一些比如集群节点、分片信息、存储数据信息等相关特有存储指标的监控。

对于存储服务监的内容细节,我这里就不再一一介绍,在面试中,你只需要基于监控系统的三个核心组成部分(基础设施监控、系统应用监控、存储服务监控)来回答问题即可,比如,你可以回答:我为了确保系统的健康可靠,设计了一套监控体系,用于在生产环境对系统的可用性进行监控,具体的指标细节可以结合业务场景进行裁剪,比如你们是游戏领域,所以很关注流量和客户端连接数。

总的来说,让面试官认可你有一个全局的监控视角,比掌握很多监控指标更为重要。

当然,很多互联网公司都很重视系统服务稳定性的工作,因为服务的稳定性直接影响用户的体验和口碑,线上服务稳定性是研发工程师必须要重点关注的问题。所以当你回答完上述问题后,有的面试官为了考察候选人的责任意识,一般还会追问:“如果线上出现告警,你作为核心研发,该怎么做呢?”

对于线上故障,要有应急响应机制,我总结以下几点供你参考:

6.png

总结

我们来回顾一下今天的重点内容。

为了在面试中更好地回答怎么评估系统高可用,我们讲解了 SLA 的概念以及评估方法,并得出“以停机时间影响的系统请求量作为评估指标”比较科学。

为了确保线上服务的稳定运行,在设计监控系统时,要考虑三个核心点,基础设施监控、系统应用监控,以及存储服务监控。

另外,我强调了故障处理是研发工程师在进阶过程中必须经历的,而故障处理能力也是面试官最为看重的能力之一,所以对于怎么处理各类故障,你要形成一套体系化的知识框架。

为了方便你的记忆,我将今天的内容总结如下。

Drawing 7.png