SRE-网站可靠性工程

文章目录

1 SRE介绍
- 1.1 SRE对比Devops
2 SRE的度量标准
- 2.1 SLIs (Service Level indicators):服务级别指标
- 2.2 SLOS(Service Level Objectives):服务级别目标
- 2.3 SLAS(Service Level Agreements):服务级别协议
3 Monitoring(监控一切)
4 Troubleshooting(问题处理)
- 4.1 故障处理的两个原则
- 4.2 故障处理的基础环境和工具
- 4.3 优化之请求链路
- 4.4 优化之数据持久层
- 4.5 优化之JVM
5 Capacity Plannig(容量规划)
6 Full Link Pressure Measuring(全链路压测)
7 Chaos Mokey(捣乱的猴子)
8 Automation:自动化是王道
9 以终为始，复盘和优化

1 SRE介绍

SRE全称 Website reliability engineer(网站可靠性工程),它既是一类职业(运维)也是一种持续优化服务的工程,且并不只限定于web服务服务,所有的分布式服务都可以适配,由谷歌提出并出书SRE:Google运维解密

1.1 SRE对比Devops

DevOps是偏向看中交付以及交付过程中的自动化以及效率,而SRE偏向于上线后系统的稳定性以及监控、告警,注意:SRE并不只是运维,它包含开发、运维、测试、项目经理等一系列岗位,属于架构组、运维组的职责.

2 SRE的度量标准

2.1 SLIs (Service Level indicators):服务级别指标

System Throughput:系统吞吐量,
- QPS:queries per second,每秒请求量,底层只是select操作
- TPS:Transations Per Second,每秒数据库交互事物量,底层有增删改数据操作
- SBC:simultaneous Browser Connections,并发连接数.对于那种同时在线看直播、滴滴在线打滴等,有很重要的影响
Request Latency:请求延迟
- RT:response time,服务响应时间,从调用者调用开始到正确计算返回结束
Availability: 可用性
- Uptime:服务运行时常,指的是服务在基准测试、压力测试下不发生宕机的时间,这个时间个人觉得和发布周期有关,如果月度迭代发布,那么此时间至少是一个月
- Error Rate:错误率,正常发起的调用返回的400、500开头的服务端错误数.

2.2 SLOS(Service Level Objectives):服务级别目标

光有指标不讲究目标,则是耍流氓,以某打的平台举例:

要求客户最高峰访问PV>1亿,要求QPS>1万
订单日成交量>1000万,要求峰值TPS>1000
司机并发在线数>200万,要求SBC>200万
99%的RT<200ms
整体可用率>99.99% ,即非正常原因(系统宕机、断电、断网、电缆被挖坏、地震机房没了)导无法提供服务时间一年不能超过52分钟(这个已经很高了,阿里的支付宝是5个9,至于5个9以上,纯粹是瞎扯淡,无脑吹了)

2.3 SLAS(Service Level Agreements):服务级别协议

当有了指标去度量,有了目标去奋斗,那么就要协议去落地了,协议会落实有相关指标的度量标准,甚至有达不到该做出赔偿、惩罚的条款、员工的绩效、年终收益等.

3 Monitoring(监控一切)

有了目标后,我们需要一套系统去收集数据并监控这些指标(例如开源的硬件运维产品zabbix),大厂都是自研一套属于自己的数据采集以及监控的的平台的,如sv的warden.

日志规范 :收集指标(日志)可通过主动发送指标数据和打日志文件的两种方式,最好的方式是后者,后者是与服务解耦(只需采集进程和文件交互,当服务不稳定时时并不等保证主动发送会一定是稳定的)且是通用的解决方式,.
埋点工具: 当有了日志规范时,就需要对相应服务进行日志埋点输出,分为前端埋点(sv是前端架构提供js sdk调http发送到日志收集服务mars)和后端埋点(logback将日志输出当指定文件上)
采集和分析:sv后台采集日志用的是warndenagen程序(大吞吐量、低延迟、占用内存小需持续优化,舍弃笨重的flume),前端用的是埋点服务(mars)接收入日志请求,然后输出到日志文件,再由warndenagen采集,数据分析都是用的warden服务
数据仪表盘及可视化:使用kibana、grafana、各类BI软件、以及基于datav自研的软件对于数据进行可视化
报警参数阀值: 当有了分析结果,有了仪表盘,这时我们就可以基于这些数据做告警设置了,一般设置方式分为,事件告警(最为准确、最普遍)、基线告警阀值设置(比如9点前任务必须完成95%、结束1500个实例)、另一种就是根据AI算法动态告警进行告警阀值的设置(好处是会识别出一些靠一般经验无法确定阀值的风险、团伙诈骗识别、异常指标等等等、坏处是可能会产生漏报、误报,原则是宁愿误报也不能漏报)
报警通道: 重要级别从上到下,电话(最高级别,要求不准拉黑告警电话) -》短信 -》叮叮、企业微信 -》邮件,发的报警最好是有人应接,响应,若超过一定时间未应接,考虑提高告警级别以及发送更高级别人员
系统巡检报告: 用于系统定时发送巡检报告!

4 Troubleshooting(问题处理)

当收到问题通知时,我们需要处理问题.如下将会说到troubleshooting的原则,基础环境和工具,以及三大优化方向.

4.1 故障处理的两个原则

原则一:故障处理高于一切,停止手上正在处理的任何的工作(即使正在进行晋升答辩).系统始终有至少一个(on-call/On-site/On-line)人员,即使下班了.相应的指标有故障响应时间/故障恢复时间/故障修复率
原则二:先恢复可用,再分析问题. 恢复可用时,如果可以,先记录一下现场(系统负载、GClog、HeapDump),操作级别从低到高:重启 -》扩容 -》回滚, 回滚是最复杂、最耗时的超级重量级操作,尽量避免,或者已有的发布系统支持一键回滚操作.

4.2 故障处理的基础环境和工具

电话、网络接通:相关人员必须在任何时候能够接通来自系统的电话、网络告警
VPN、堡垒机权限: 这些权限一般是需要申请的,相关人员必须要有这些权限保证远程办公的能力
CLI终端和Shell脚本:技术人员需要数量掌握系统的常用命令、以及能看懂shell脚本,不然排错很可能是添乱
代码速查能力:开发、运维人员需要提前将负责的模块的代码checkout出来,再出现问题需要查代码时能保障能快速定位到相关代码
监控分析工具:监控分析平台不经有各个系统运行的指标工具,还要有系统如JVM、IO、磁盘等使用的信息,方便问题的快速定位

4.3 优化之请求链路

为了减少问题,需要对系统进行优化,其中请求链路优化是其中重要的的一环.

链路追踪TranceID:我们从浏览器发送一个请求后,该请求被代理多少次,后台又调用db的很多层,这时我们就需要链路追踪TranceID,无论在后续的全链路流量分析还是问题快速定位都是非常有用的(定位到具体哪一层出现了问题)
网络接入层优化:ngix、linux、atmos等都属于接入层
- 内核参数优化: linux内核在使用时,需要先进行优化,如其连接数信息是存储为文件的,而文件数是有限制的,故需要合理调节文件数;对于访问量大的Web Server，会存在大量的TIME_WAIT状态,对于对方连接关闭之后，程序里没有检测到，或者程序压根就忘记了这个时候需要关闭连接就会产生大量的CLOSE_WAIT状态,过多的这些TCP状态最终很大可能使得服务器出现异常,需要进行特定的优化(tcp状态统计命令:netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’);以及设置哪些端口需要用用弱账号启动.
- 4层/7层转发代理: 这里的层是OSI 7层网络模型，OSI 模型是从上往下的，越底层越接近硬件，越往上越接近软件，这七层模型分别是物理层、数据链路层、网络层、传输层(TCP)、会话层、表示层、应用层,4层指的是传输层的tcp/udp,7层指的是应用层,通常是http/ws,4成转发是指请求进来的时候，nginx修改数据包里面的目标IP、源IP和源端口，然后把数据包发向目标服务器，服务器处理完成后，nginx再做一次修改，返回给请求的客户端。7层代理指的是需要读取并解析http请求内容，然后根据具体内容(url, 参数, cookie, 请求头)然后转发到相应的服务器。4层代理由于不需要解析数据包中的内容(无需耗费CPU),故性能更高,7层优点是1)动态代理(不同的url转发到不同服务器) 2)风控:屏蔽外网IP请求某些敏感url；根据参数屏蔽某些刷单用户 3)审计:在nginx层记录请求日志等. 结论:由于现在机器cpu性能都很好，4层代理并没有明显的性能优势，而7层代理在业务层面优势明显，所以一般直接选择7层代理就OK了。
- SSL卸载:如果整个通信链路每个环节都使用HTTPS进行加解密传输数据,会使得网站访问速度变“慢”，其次导致服务器CPU消耗变高,故再认为非常重要链路点才开启https,其它部分只需要开启http就行了,应卸载对应机器的SSL证书的卸载
同步VS异步:同步的特点是吞吐量低但是响应高,异步是吞吐量高但是响应低, 而我们针对业务的高峰低谷时段程序,适当的进行异步处理,进行消峰填谷.
超时、重试、幂等性: 当出现业务高峰时,服务端处理需要花费更多的时间,如果中间某个环节的网络的设置的超时时间小于处理时间时就会出现超时,这时就需要适当的调整时间了,原则是外围设置的超时时间应略小于内围,当出现超时时,最友好的方式是进行重试、对于重试、异步、等程序都需要保证其幂等性,不然问题就很大的.
过载保护
- 熔断:熔断是用于保护调用方的,调用方发起某个请求,服务端处理超过一定资源后进行停止并告知调用方,防止调用方耗费太多时间在等待服务端的响应上,比如5秒内20次调用失败.
- 限流: 保护被调用方,防止过载导致服务崩溃
- 降级: 当业务高峰时,降低无关紧要的服务等级甚至是关闭,以保证重要服务高峰期稳定运行.

4.4 优化之数据持久层

数据持久层即数据存储层,如:MySQL、Oracle、HDFS、HBase、CK、KUDU等等,其是系统稳定性容易出问题的高灾难区

SQL级别:慢查询分析、索引和执行计划、关联查询、子查询
长事物、锁类型、锁范围 :尽量代码里避免长事物(一个事物处理很长、涉及很几十项动作、涉及数据本地耗时处理,严重影响TPS和RT)、为保证操作数据库操作数据一致性需要对相应的数据进行加锁,悲观锁(排它锁,select … for update;update … 对select查询的结果集涉及到的数据进行加锁,别的涉及该数据的增删改事物无法再操作了,会堵住,for update在中InnoDB默认是行级别的锁，当有明确指定的主键时候，是行级锁，否则是表级别,仅适用于InnoDB，并且必须开启事务，在begin与commit之间才生效。)、乐观锁(select …;update …where xxxx and current = odl).悲观锁分为排它锁(X锁)和共享锁(S锁),排他锁就是不能与其他锁并存，如果一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁,共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。生产操作数据库尽量减少排它锁的使用(影响效率),禁止锁全表操作(严禁),应使用乐观锁(只有很容易触发锁动作时,采用悲观锁)
连接数/连接池优化: 一个数据库的jdbc连接数是有限的,当一个微服务实例的连接数有50时,那200个服务就有1万个连接了,mysql默认的连接数是100,而最大值可设置为16384(实际若并发有5000连接对同一个数据库进行操作,数据库已经接近压力上线了,生产都是根据数据库配置,业务场景逐步调大连接数的), 所以一个微服务应用要合理设置连接数(8个及其以下). 其次使用更加好用以及先进的连接池druid(阿里开源、功能丰富、国内用的多)、HiKariCP(springboot2.0上默认,代码量低,国外用的多),弃用c3p0、tomcatcp、DBCP、BoneCP等过时且性能低下的连接池
本地缓存、分布式缓存:当数据库读取过于耗时,第一反应是加缓层(尤其是正对大量QPS型的查询),单机(按网上性能从高到底排序)缓层有caffeine、ehcache、guavaCache以及分布式缓层memcached、redis(虽然性能略低,但是它拥有丰富的功能以及数据结构),注意缓层一定要控制好缓层和数据库存储的一致性级别,不然是个大坑,有的服务可以容忍缓层一段时间和数据库存储不一致,而有的服务需要缓层和数据库强一致性
读写分离、分库分表、弱一致性:读写分离指的是为了缓解数据库压力Master机器用于增删改操作,slave机器用于查询操作,slave可以是多台,降低master的压力,而分库分表是建立的业务的数据量达到了几千万以上,已有的单实例已经完全无法满足快速增长的操作需求,首先进行垂直切分(将不同业务切分到不同库,如商品数据数据、订单数据、用户数据分别存储不同的库中)、其次进行水平切分(如订单数据根据某个列的一定规则将数据分布到多个数据库中以数据库尾部编号不同区分)、若是分库分表则要求程序支持多数据源操作以及设置分库分表规则.分布式系统架构的CAP理论(一致性（Consistency），可用性（Availability），P代表分区容错性（Partition Tolerance)市面上是没有哪家系统能够都保障CAP三个强特性的,对于我们的web网站的后台的分布式数据库存储(跨实例),我们不可能让其丢失可用性(停服)以及分区容错性(容灾),故只能牺牲点了一致性,要求其弱一致性(市面上的分布式RDS都很难做到低资源消耗情况下能保证分布式事物,很多都是都是吹的,或者资源消耗巨大),一个完整的业务活动由一个主业务服务与若干从业务服务组成,故需要业务自己具有检查、补偿、幂等的能力,而去保证最终一致.(若以后某人说CAP一定不能共存,可以捶它,很多系统都能做到二强一弱,弱的在有使用方自己代码逻辑完善)

4.5 优化之JVM

JVM优化也是我们优化的重点方向之一

ThreadDump :我们可以通过ThreadDump查找内存泄露(load大量数据到缓存、无上线创建新的线程)、发现死锁线程等,一般当服务器挂起,崩溃或者性能底下时,就需要抓取服务器的线程堆栈(Thread Dump)用于后续的分析,在实际运行中，往往一次 dump的信息，还不足以确认问题。为了反映线程状态的动态变化，需要接连多次做threaddump(jstack -l 7946 | tee -a jstack.log 或者 kill -3 pid顺时线程信息会打印到nohup输出文件(控制台))，每次间隔10-20s，建议至少产生三次 dump信息，如果每次 dump都指向同一个问题，我们才确定问题的典型性,ThreadDump分析.
HeadpDump: 通过Heapdump+Arthas+Jprofiler我们可以分析大对象、内存泄漏等信息,注意有时一个多个G的Heap会很大,我们可以选择只dump部分内容分析,不然很容易将服务弄夯死,只有架构师以及PE才能有权进行HeadpDump操作,其次直接使用Jprofiler连接JVM，可以获得更多的信息.条件允许建议如此使用
启动参数 : JVM启动参数对于JVM有很大影响,最终结果就两个要求,一个是一天不能超过10个Full GC、另一个是yarn gc,但是yarn gc时间占比不能超过一定上限,不做次数严格要求次数过少很大可能导致sw时间过长,显的卡顿不平滑)
GC优化: 服务必须要开启gc log,且开启滚动,不然一重启就冲掉了要分析的gclog信息,gc log分析的好时有时并不需要分析 heapdump
多线程优化:禁止使用线程池工厂类Executors方式进行创建线程池,需使ThreadPoolExecutor方式创建线程,需配置见名知其意的线程名字,阻塞队列、拒绝策略. 针对IO密集型的线程,线程池最大可以设置为 10~20倍核数,对于计算密集型的线程,线程池最大设置为2*core+1
死锁排查: 通过ThreadDump搜索dealock,查看在程序那一块儿形成了死锁,Java死锁排查和Java CPU 100% 排查的步骤整理
死循环排查: 滥用递归方法或者使用不安全的线程对象(如HashMap)最终造成死循环

5 Capacity Plannig(容量规划)

当我们监控到了服务指标、对服务稳定性做了一定的优化,但是那不是长期的处理方案,我们需要一定时间(来年一年)内的容量规划、以及特定业务场景：双11、大促销、大征期容量规划

业务容量规划:在做技术容量规划规划前先也必须灵魂拷问业务人员，问他们他们业务增长量预估是多少，而不是技术人员自己凭经验来进行判断，承担不起这个责任
技术容量规划: 包括服务起的扩容、升级服务起的配置(cpu、内存、宽带、磁盘等)！
基准容量测试：技术容量规划前需要对单个服务尽心基准服务压测，最终要得到扩容的机器的数据（数量 = 容量/基准）
木桶效应：全链路压测: 然而一个系统往往不止一个服务，服务之间很大可能是依赖的调用关系，这是只做服务自身的基准测试是不准确的，需要全链路压测，逐渐提高请求量，直至达到想要的系统吞吐量水平，期间正对出现的短板服务作出相应的处理。
容量水位监控: 进一步，做到更加智能，监控系统自动监控整个系统的各个服务的容量使用情况，通过仪表盘展示，告警通道告警。
扩缩容方案:如果被监控的服务具有很强的易横向扩展性，则继续可以做到系统自动扩缩容，这个很多云厂商都是如此做的，可以根据业务量合理分配资源，减少资源浪费，是非常流弊的，对于非云厂商公司，大多都是通过k8s来实现线下服务自动扩缩容。

6 Full Link Pressure Measuring(全链路压测)

这是一个顶流成熟的系统必须要做的事儿，在我们预估了系统吞吐量后，需对系统进行全链路压测，生成一份专业的测试报告

核心链路梳理 :非核心业务可以不用做全链路压测，比如记录登录的次数服务，这个如果高峰期做不来，完全可以服务降级
- 流程和边界 : 需要梳理核心业务链路的流程以及边界
基础中间件支持
- 流量标识与隔离: 测试数据染色、打标，监控，方便追踪定位，
- 第三方服务隔离: 可能把第三服务搞挂了，要背锅的，压测是需隔断第三方服务
压测流量mock:直接拿生产的流量进行测试是需要隔了同时要处理各种账号问题，非常麻烦，所及最好的分析生产的流量情况是自己mock测试数据，更加
逐步加压:一下将流量压到顶峰是个很傻的操作
监控与分析:压测时，需实时能监控系统情况并分析
测试报告:最终生成一份系统的压测报告

7 Chaos Mokey(捣乱的猴子)

专业的词叫做混沌工程（Chaos Engineering）,2012年，Netflix开源Chaos Monkey，使用该工具可以在整个系统中在随机位置引发故障，阿里电商域在2010年左右开始尝试故障注入测试的工作，希望解决微服务架构带来的强弱依赖问题。

前提: 重要、重要、重要，已经建立起系统性可靠性保障方案，生成满足既定业务量的全链路压测报告，否则白扯
目的: 验证系统抵御失控条件的能力以及信心，它目的不是解决问题，阿里支付宝光纤被断了，照样也是提供不了服务的
实践原则
- 建立一个围绕稳定状态行为的假说
- 多样化真实世界的事件
- 在生产环境中运行实验
- 持续自动化运行实验
- 最小化爆炸半径
实施步骤
- 定义并测量系统的稳定状态
- 创建实验假设
- 模拟真实世界中可能发生的事件
- 证明或证伪实验假设

8 Automation:自动化是王道

SRE工程，工作的过程最终追求的是自动化

SRE中有大量手动的、重复的、战术性的工作，称做琐事（Toil）
琐事的增长与服务的增长，线性关系
减少琐事和扩大服务规模的工作，就是SRE中的Engineering
自动化的具体价值：
- 效率：比手动要快（低延时）
- 性能：比手动要多（高吞吐）
- 一致性：可重复、且比手动可靠
- 可扩展：成本低，可集中化、规模化处理问题
全自动VS半自动？: 不要过于迷信全自动化（AI）测试，很难控制，最好是半自动，甚至人工干预测试

9 以终为始，复盘和优化

SRE是个系统的不断迭代的工程，不是做一次就会发现所有问题(会有隐藏BOSS)、不是做一次就会发现就能解决未来任何时刻系统稳定性问题。谷歌提出的SRE工程，其搜索服务不还是崩溃了4小时。

故障回顾报告
应急恢复！=根因修复
触因！=根因
流程、规范的持续补充完善
指标、目标的持续补充完善
自动化、系统化的持续完善