SRE核心实践-CSDN博客

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

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

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开头的服务端错误数.

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

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

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

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

日志规范 :收集指标(日志)可通过主动发送指标数据和打日志文件的两种方式,最好的方式是后者,后者是与服务解耦(只需采集进程和文件交互,当服务不稳定时时并不等保证主动发送会一定是稳定的)且是通用的解决方式,.
埋点工具: 当有了日志规范时,就需要对相应服务进行日志埋点输出,分为前端埋点(sv是前端架构提供js sdk调http发送到日志收集服务mars)和后端埋点(logback将日志输出当指定文件上)
采集和分析:sv后台采集日志用的是warndenagen程序(大吞吐量、低延迟、占用内存小需持续优化,舍弃笨重的flume),前端用的是埋点服务(mars)接收入日志请求,然后输出到日志文件,再由warndenagen采集,数据分析都是用的warden服务
数据仪表盘及可视化:使用kibana、grafana、各类BI软件、以及基于datav自研的软件对于数据进行可视化
报警参数阀值: 当有了分析结果,有了仪表盘,这时我们就可以基于这些数据做告警设置了,一般设置方式分为,事件告警(最为准确、最普遍)、基线告警阀值设置(比如9点前任务必须完成95%、结束1500个实例)、另一种就是根据AI算法动态告警进行告警阀值的设置(好处是会