首页
美图
服务
付费
树洞
云主机
推荐
邻居
支付
开发
书单
更多
我的足迹
罗盘时钟
圈小猫
工作打分
给我留言
本站统计
推荐
M商城
欣悦云店
txt阅读器
VPS监控
证书监控
网址导航
在线工具
Search
1
docker和docker-compose一键安装脚本
5,130 阅读
2
采用Prometheus+Grafana 监控H3C交换机状态
4,600 阅读
3
WooCommerce对接第三方支付插件开发
4,224 阅读
4
grafana的Dashboard面板添加阈值报警
2,879 阅读
5
服务器(vps)性能测试脚本汇总
2,824 阅读
虚拟化
数据库
运维
基础知识
监控预警
数据展示
运维工具
web安全
系统服务
开发
python
php
java
shell
go
项目
博客
电商
工具
娱乐
综合
VPS相关
规范文档
知识总结
经验分享
读书笔记
关于
Search
标签搜索
django
python
运维工具
支付对接
电商平台
Joe主题
docker
wordpress
woocommerce
支付通道
zabbix
蓝鲸智云
运维
grafana
监控
运维知识
typecho
php
mysql
nginx
行云流水
累计撰写
324
篇文章
累计收到
362
条评论
首页
栏目
虚拟化
数据库
运维
基础知识
监控预警
数据展示
运维工具
web安全
系统服务
开发
python
php
java
shell
go
项目
博客
电商
工具
娱乐
综合
VPS相关
规范文档
知识总结
经验分享
读书笔记
关于
页面
美图
服务
树洞
云主机
邻居
支付
书单
给我留言
本站统计
推荐
M商城
txt阅读器
网址导航
搜索到
8
篇与
的结果
2023-07-17
围绕故障管理谈SRE体系建设学习总结
前言SRE是一个体系化的工程,SRE体系的建设涉及的内容繁多,比如日常需求处理、容量规划、资源部署、监控告警、预案梳理、灾备演练、OnCall值班、应急事件响应、故障处理、运维自动化建设等。故障是众多事项的一个交汇点。{card-describe title="故障考验"}SRE团队的响应速度对服务的掌控能力监控告警的覆盖是否完整配置是否合理灾备预案的体系是否完善是否充分的做了灾备演练应急预案是否有效{/card-describe}SRE的工作职责{card-default label="SRE的工作职责" width="75%"}{/card-default}{message type="success" content="核心目标:稳定性、效率和成本。"/}{callout color="#4def93"}稳定性是核心职责,这是SRE区别于SA、OP、PE的点。通过建设工具、平台、基础设施的建设来提高效率成本连同效率就是降本增效。{/callout}稳定性建设{card-default label="稳定经建设" width="80%"}{/card-default}{callout color="#bcef4d"}什么是稳定性如何度量稳定性如何设置稳定性目标如何提升稳定性{/callout}度量稳定性{message type="success" content="如果你不能度量它,你就无法改进它。--彼得.德鲁克"/}在业界我们通常用MTBF和MTTR这两个关键指标来衡量稳定性,这两个指标分别是「平均故障时间间隔」(Mean Time Between Failure)、「平均故障修复时间」(Mean Time To Repair)。{message type="warning" content="服务状态可以分为"正常态"和"异常态""/}{card-default label="严格定义" width="85%"}{/card-default}{card-describe title="计算公式"}几个关键的时间点:故障维修结束:上一次故障恢复结束的时间;故障开始:故障开始发生的时间;故障维修开始:开始介入故障,开始处理的时间。根据上面这几个时间点就把时间划分为了几个时间段:维修结束 -> 故障开始:T1故障开始 -> 维修开始:T2维修开始 -> 维修结束:T3其中T1的平均值为「平均无故障时间」,MTTF(Mean Time To Failure)T2+T3的平均值为「平均修复时间」,MTTR(Mean Time To Repair)T1+T2+T3的平均值为「平均故障间隔」,MTBF(Mean Time Between Failure){/card-describe}{message type="error" content="MTBF = MTTF + MTTR,因为MTTR通常远小于MTTF,所以MTBF近似等于MTTF;因此我们平时常用的衡量指标就是MTBF和MTTR。"/}设定稳定性目标提高MTBF,降低MTTR{message type="success" content="MTBF的提升可以看作是众多稳定性建设工作的一个结果(稳定)状态,MTTR则是我们对故障的应急处理、恢复服务的过程,是一个集中检验我们稳定性建设水平的过程。"/}{card-default label="MTTR拆解" width="75%"}{/card-default}{card-describe title="MTTI"} MTTI(Mean Time To Identify,平均故障发现时间):指的是从故障实际发生,到我们真正开始感知、识别、响应的时间。这个过程最长见的渠道可能是服务监控告警、常规巡检、用户或者同事反馈,也可能是舆情监控等。{/card-describe}{card-describe title="MTTK"} MTTK(Mean Time To Know,平均故障认知时间):也就是我们常说的平均故障定位时间。{/card-describe}{card-describe title="MTTF"} MTTF(Mean Time To Fix,平均故障恢复(解决)时间):这个时间指从我们定位到故障的原因到我们采取措施恢复业务为止。这里采用的方式可能有很多:故障隔离、容灾切换、限流、降级、熔断等,甚至是重启服务。{/card-describe}{card-describe title="MTTV"} MTTV(Mean Time To Verify,平均故障修复验证时间):即故障解决之后,我们用来验证服务是否真正恢复的时间。{/card-describe}{card-default label="目标" width="75%"}{/card-default}提升稳定性MTTR的指标被细化之后,我们的目标也就变成了降低这些细化之后的指标;我们可以分而治之、各个击破。{card-default label="提升稳定性" width="75%"}{/card-default}{callout color="#ef4d5d"}MTTI阶段多管齐下;尽可能用更多的手段来覆盖可以发现、暴露问题的通道,包括完善监控的覆盖,建设体系化的监控系统。MTTK阶段工具赋能;这个过程中需要更多的借助工具、平台的能力,建设健全运维系统,比如监控平台、日志平台、链路跟踪平台等,如果能力允许也可以去尝试建设“根因自动定位”系统。MTTF阶段完备预案、一键应急、紧密协作;这个是在故障处理过程中最核心的部分,是真正可以让服务恢复正常的阶段;这个过程有比较多的前置依赖,也就是需要我们在平时做好储备的,比如建立健全预案体系,将预案的执行手段尽可能沉淀到工具平台中,尽可能做到一键直达,缩短预案执行的路径。其次这个过程中可能还会涉及到部门内部、部门之间的协作,尤其是在处理重大故障的场景;这时候就需要有一套可以让大家紧密协作的流程或共识,让大家可以信息互通、各司其职、有条不紊。MTTV阶段自动校验;这个过程也是需要尽可能依赖自动化的手段去做。{/callout}{card-default label="全景图" width="75%"}{/card-default}{card-describe title="SRE阶段职责"}Pre-MTBF预案建设、灾备演练、OnCall值守等;MTTR应急响应;Post-MTBF故障复盘、故障改进、OnCall值守等。{/card-describe}{message type="error" content="整个过程归纳:故障预防 -> 故障发现 -> 故障定位 -> 故障恢复 -> 故障改进"/}{callout color="#f0ad4e"} 夸张一点讲,我们做的所有稳定性建设都是为「故障」服务的,SRE的稳定性建设都必须围绕“提高MTBF”和“降低MTTR”这两个目标展开。{/callout}{callout color="#4d68ef"} 「故障」其实是服务运行中的一个常态,是无法完全避免的;因此我们需要用一个积极的心态,至少是一颗平常心来看待故障,不能惧怕故障,更不要谈之色变;只有我们正视故障,分析并改进才有更可能在未来去规避它;这就需要我们辩证的看待故障,我们需要尽可能从故障中汲取正向的意义,建议把关注点聚焦在「改进」上,而不是「处罚」。{/callout}故障管理故障管理分为故障前、故障中和故障后,在每个环节都有一些核心的工作内容和目标。{card-default label="三段式分解" width="75%"}{/card-default}{callout color="#e54def"}故障前故障预防、灾备预案;目标是尽可能地做足准备工作,毕竟有背方可无患;故障中发现、定位、解决故障;目标是尽可能的提高效率,缩短故障恢复的时间;故障后故障复盘、故障改进;目标是尽可能多的从故障中吸取教训,反思和学习,完善和修复故障中暴露出来的问题。{/callout}故障前关键内容:监控覆盖、架构设计、容量评估、灾备预案、灾备演练、还有持续交付。{card-default label="故障前" width="75%"}{/card-default}监控覆盖的话比较容易理解,服务上线后,只有拥有足够的监控手段,并且尽可能多的覆盖服务的各个环节,才有可能在后面发生问题的时候,快速的感知到。{card-default label="监控体系" width="75%"}{/card-default}{message type="error" content="主要分为客户端质量监控和服务端质量监控。"/}{card-describe title="客户端质量监控"} 在移动互联网兴起之前,大部分的监控产品、监控思路都是集中在服务端的。客户端质量监控我们都使用了哪些手段呢?常规的有一些第三方的拨测、第三方的APM。除了一些商用的产品,当然也有一些免费的工具是可以用的。应对一些流媒体的应用,我们自研了一套融合CDN的监控还有流媒体的监控。这个其实也比较关键,因为现在业务体量大了之后,CDN是不可避免的会用到,但如果没有这部分监控的话,CDN质量就要依赖于用户反馈,链路就会比较长。{/card-describe}{card-describe title="服务端质量监控"}服务端的质量体系是用到了一些比较通用的,像InfluxDB套件、ELK、Prometheus、Open-Falcon、Zabbix。{/card-describe}{card-default label="基础监控" width="75%"}{/card-default}{card-default label="SLA" width="75%"}{/card-default}{card-default label="日志报表" width="75%"}{/card-default}{card-default label="客户端监控" width="75%"}{/card-default}架构设计 架构设计可能会更偏业务侧一些。我们在故障之前,要尽可能做好服务的架构设计,同时在做一些预案之前,也要把服务架构做好梳理。只有当我们把服务的架构了然于胸,才更有可能在故障发生的时候从容不迫,更好地定位问题。 要更多去加入柔性设计,也就是说你的服务要具备一些像降级熔断、故障隔离这些手段,要有这样的柔性设计在里边。这样架构可以提供这些能力,后面才能更好地去做服务的保障。 再有一点就是,要尽可能的去规避常规的风险点,比如说单点之类的;同时还要尽可能地去规避架构里面常见的坑。{card-default label="架构设计/梳理" width="75%"}{/card-default}容量评估 容量评估其实就是我们的服务在上线之前,要去对服务的承载能力做一个压测,这样我们才能更好的了解服务上线之后的状态。然后我们基于这个,再根据业务方量级的评估,去规划服务的容量。 容量评估其实是不能完全依赖于压测的。在压缩之前,要基于我们对自己服务的理解,包括每一条请求大概会耗费多少资源等,要有一个基础的认识,再基于这些认识去评估大概需要用多少后端资源、大概会用多少CPU内存,这些东西是可以用数学计算的方法来计算出来的。{card-default label="容量评估" width="75%"}{/card-default}灾备预案和灾备演练 这两点是比较关键的,跟故障会更强相关。{card-default label="灾备预案/演练" width="75%"}{/card-default}{callout color="#dd4def"}服务梳理在服务梳理阶段,要基于前面的架构图等来梳理请求链路,要分段分层地梳理请求都经历了哪些层次、有哪些阶段、经过了哪些设备、周边有哪些依赖(包括内部的服务依赖、后端的资源依赖、第三方的依赖等),然后还要梳理架构目前是不是有什么风险、流量有没有经过一个单点、有没有哪个点可能是存在瓶颈的……这些都是我们在服务梳理阶段需要去梳理清楚的。预案梳理了解各种情况后,就可以梳理相应的预案了。仔细分析应该用什么样的手段来覆盖,将风险各个击破;然后要尽可能地做多级预案,因为预案如果只有一级的话,容灾能力是不够柔性的;此外,还要借助到一些智能调度的手段;最后就是柔性设计,前面也有提到,是更偏业务侧一些,也就是说在服务里要有尽可能多的手段来做自己的一些failover,可以去做一些降级、熔断等。沙盘推演梳理出来预案后,并不是直接到做演练。要了解预案是不是真的有效,不是直接做演练,而应该是先想清楚。我的建议是去做沙盘推演。在这个过程里,我们要尽可能去发动多的部门协作起来,来看我们的预案是不是有效。毕竟人多力量大,并且不同团队的人对业务可能有不同的理解,在这种头脑风暴下,就有可能碰撞出更多的可能性。然后在这个过程里,会基于一些可能的故障场景、case等来做推演,当故障场景A出现了,梳理出了预案A’,那 A’能不能把故障A完全解决掉?在解决故障场景的时候,有没有引入一些其他的风险点或问题?在这个过程里面,我们都要想清楚,当得出一个大家都认可的推演结果后,预案才推演完了。预案落地这一步是需要做落地,包括文档输出、功能实现、架构适配、工具建设。预案演练落地之后,要通过演练的方法来验证预案是不是真的有效。无损演练和轻损演练:我们做故障演练要尽可能地做到对业务无损,但有些预案本身应对的故障场景就是会损害业务的,那这种时候我们要尽可能降低这种演练带来的损失,比如说选不同的时间段、流量的控制、灰度之类的,尽量去做轻损的演练,既然我们是通过故障演练的方式来确保预案有效,那肯定不能因为故障演练而演练出一个大的故障,这就有些得不偿失了;还有就是单点演练跟组合演练:你的演练到底是要一次演练某个模块,还是说要把一个大故障场景里所有涉及的点都演练一遍?这个也是我们在预案演练里需要考虑的。{/callout}持续交付{card-default label="持续交付" width="75%"}{/card-default}故障中故障真的发生了?去发现定位和恢复。核心手段::监控告警、日志分析、链路跟踪、故障隔离、容灾切换、降级熔断。{card-default label="故障中" width="75%"}{/card-default}{card-default label="监控告警" width="75%"}{/card-default}{callout color="#ef4d75"} 对比前面这两张文字图,文字图只是告知流量突降30%,这是一种告警方式。中间的图就是由名为“监控大盘”的机器人发送出来的,也是我们服务的架构图。放大图看,我们的业务模块、交互链路已经暴露出来了;图中有一块是红色的,红色代表标识异常,与异常关联的某个组件就变成淡绿色。由于红色这块故障引发了另外一个异常,接连引发了一个又一个的异常。通过这张告警图,收获了更多的信息:首先知道系统挂了,或者系统异常了,然后这次异常大概是由什么引起的。一张图就可以让你非常快速地感知。{/callout}{message type="success" content="实现:基于grafana的插件flowcharting基于draw.io的一个绘图,结合我们的数据填充和告警配置来实现的。"/}{card-default label="日志分析" width="75%"}{/card-default}{card-default label="链路跟踪" width="75%"}{/card-default}{card-default label="链路跟踪" width="75%"}{/card-default}日志分析、链路跟踪、预案执行都是定位手段,在已经定位问题之后,并且匹配了相应的预案,要求去执行预案。当然前提是有相应的预案应对故障场景。然后依据操作手册,分别按不同的故障层次去执行处理。{card-default label="恢复结果确认" width="75%"}{/card-default}恢复之后还要确认执行结果,看服务是否恢复正常。故障后在故障后,我们应该做好以下环节:故障复盘、故障改进、预案完善、容量压测、故障模拟、周边清查。{card-default label="故障后" width="75%"}{/card-default}{callout color="#ef4d8e"}预案完善故障发生之前有做过预案,这些预案是不是完善的?在故障处理的过程中,有没有暴露出问题?是否要完善之前的预案中做的不完善的地方等等;故障模拟意思是用某种手段模拟某些故障,提前知道该如何解决这些问题;周边清查应该具备举一反三的能力,比如A服务出故障,那么A服务周边有一些相关联的服务有可能会受到影响。举个例子,比如集群里面有N台机器,收到机器A磁盘接近100%的一条告警,只需处理机器A就可以了吗?当然不是,在处理完该异常之后,肯定要查看同集群的其他机器是否存在类似情况。{/callout}{card-default label="故障复盘-关键时间线回顾" width="80%"}{/card-default}{card-describe title="故障复盘"} 在故障复盘阶段,最核心的思想就是要回顾关键的时间点:故障是从什么时间发生的?从什么时间到什么时间结束的?在这过程里面有哪些非常关键的操作?有哪些关键的信息?从什么时间点定位到问题?在什么时候执行怎样的操作?这些时间点都是非常重要的。在故障复盘的过程中,要把这些操作的时间点一一还原回去,才能完整地回看操作是否合理有效。{/card-describe}{message type="warning" content="我们应该怎么做,才能更快地恢复业务?我们应该怎么做,才能避免再次出现类似问题?我们有哪些好的经验可以总结、提炼,并固化?"/}{card-default label="故障报告" width="75%"}{/card-default}{callout color="#ef4dda"} 故障解决后绕不开的一点,在故障发生后都会做一个报告,上图就是一个故障报告模板。在报告里面写清楚故障级别、责任人、处理过程、改进措施,将这些关键点归纳成故障报告的文档。到此做个总结,故障本质上是持续迭代的,当故障发生了,开始恢复、复盘、改进、验收,回到稳定运行的状态,再过一段时间又出现故障。同时,服务也持续地迭代,因此要不断去提升稳定性,这是我们都逃不出的一环。{/callout}{card-default label="持续迭代" width="75%"}{/card-default}故障管理体系做好故障管理,需要建设一些SRE体系提供支撑。{card-default label="管理体系" width="75%"}{/card-default}可用性体系SLI是指标,SLO是目标,SLA是我们的目标加上目标未达成的后果{card-describe title="SLA"} 通常运用在双方一些商务合约上,例如使用某云厂商的服务,对方承诺可用性不低于99.95%。一旦没有达到我的要求,处罚性的或者赔偿性的一些条款将会生效,这才是真正意义上的SLA。{/card-describe}{card-default label="可用性体系" width="75%"}{/card-default}{card-describe title="SLI的选择"}容量(Volume)服务承诺的最大容量是多少,从QPS、TPS、流量、连接数、吞吐思考;可用性(Availability)服务是否正常,看HTTP状态码2xx的占比;延迟(Latency)服务响应速度是否够快,rt是否在预期范围内;错误率(Errors)错误率有多少,看HTTP状态码5xx的占比;人工介入(Tickets)是否需要人工介入处理,考虑人工修复。{/card-describe}故障定级、定性、定责定级通用标准{card-default label="通用标准" width="75%"}{/card-default}定级个性化标准除了通用标准,还有一些没有被囊括到体系中来,比如某些电商类、商业化、广告类和金融类的业务,有可能造成资产损失,那么不同的部门会有不同的故障管理的定级策略。{card-default label="个性化标准" width="75%"}{/card-default}定性有效分类{card-describe title="定性有效分类"}{/card-describe}{callout color="#f0ad4e"}故障定性的一些有效分类,即定性故障是由什么原因引起的。是代码质量、测试质量、流程规范出了问题,还是变更操作不够规范呢?还有其他种种原因,我们要对故障做定性的分析和归类。{/callout}定责:判定原则定责任并不意味着处罚。我们整体的故障管理从原则上来说尽量不指责,但不指责不代表着可以持续犯错误。{card-default label="判定原则" width="75%"}{/card-default}{callout color="#ef4d93"}高压线原则:不能犯一些低级的错误;不能持续犯某些错误;上下游原则:根据服务的上下游依赖程度去做判断;健壮性原则:根据服务的健壮性定性。例如服务A挂掉导致服务B出问题,这时候责任不能完全划分到服务A上,还要考虑到服务B本身的健壮性;第三方默认无责:内部做故障定位时,默认第三方无责,当然该追责的还是会追责。{/callout}错误预算SRE里经常听到错误预算,如何做到实际落地?前面讲了故障的定级规则,明确定级规则之后,不同的故障被定为ABC级,按对应计分标准扣分。扣的分数来源于给出的预算。我们每半年为一个OKR考核周期,在一个考核周期里面每个BU会分到一定的故障分,允许在考核周期里由于故障被扣分,如果分数扣完了意味着错误预算用完了。{card-default label="错误预算" width="75%"}{/card-default}组织结构支撑{card-default label="结构支撑" width="75%"}{/card-default}{callout color="#ef4dd2"}故障管理特别依赖于组织结构的支撑,因为故障管理不仅仅是运营部门或者技术保障部门能单独完成的事情,需要不同团队协作。故障委员会是一个虚拟的组织,不是一个实体的组织,由BU接口人负责故障委员会故障判定和定责之类的事情、传达信息给BU内部。当故障发生了,基于判定规则给故障定级、定责。定级意味着每个级别产生对应的故障分;定责会涉及到故障的拆分,比如发生了一个故障,它由A、B两个部门共同承担。根据定责发现责任上A、B部门实际是五五开,因此A、B平分故障分,再从A、B部门的BU负责人各自的错误预算里扣除故障分。通过这种方式就能约束好BU吗?当然不是,要用行政手段来保障,那就是OKR。周期OKR里需要有服务稳定性的目标项才行,把服务稳定性写进OKR后,BU出于压力而去共同做好故障管理。在上述这种组织支撑的情况下,才能更好地推行故障管理。{/callout}SRE体系建设{card-default label="全景图" width="75%"}{/card-default}稳定性建设按照 MTBF和MTTR,把日常时间分成几段,不同时段里要做哪些事情?先是建设演练、Oncall值班,然后应急响应,最后复盘改进、再Oncall。在一个循环里面完成了SRE的工作。PPTV即PPT+V。PPT包涵了人员、流程、技术,是ITIL中的IT管理的三要素。SRE体系建设同样无法脱离这个模型,做好故障管理要有一个合适的组织结构、流程流程保障。未来展望AIOps和混沌工程Chaos Engineering
2023年07月17日
537 阅读
0 评论
0 点赞
2023-07-17
面向故障处理的可观测性体系建设学习总结
可观测性在整个商业体系中的位置和价值,如何快速发现故障,使用哪类指标告警,SRE 在谈论故障定位的时候,谈的是什么,如何找到故障直接原因,找到止损依据,如何让可观测性系统呈现观点,辅助洞察,定位故障
2023年07月17日
535 阅读
0 评论
0 点赞
2022-07-24
缓存知识体系
用户从发起一个HTTP请求开始,整个数据交互过程中涉及到的缓存加速以及关键技术
2022年07月24日
396 阅读
0 评论
1 点赞
2022-07-21
运维知识体系总结
运维知识体系总结
2022年07月21日
1,609 阅读
4 评论
4 点赞
2022-07-07
运维规范总结
关于变更、巡检、告警、预案等运维规范总结
2022年07月07日
301 阅读
0 评论
0 点赞
2022-07-06
程师成长路线
运维工程师成长路线的三个方向
2022年07月06日
349 阅读
0 评论
2 点赞
2022-02-23
运维三件宝
运维三件宝,重启应用、重启机器、重装系统重启应用重启大法好,问题解决了,如若还没好,再重启可好?针对无状态应用适用场景,代码bug,网络异常,傻逼应用重试搞死自己重启机器重启重启再重启。成功正在等着你。如果重启不成功,还需放电再重启。服务器负载过高无法进入排查,服务器假死重装系统重装重装再重装,重装路上好心伤。重装之前做备份,重装之后部备份。服务器被黑,最省力的解决办法
2022年02月23日
315 阅读
0 评论
0 点赞
2022-01-10
运维的价值
运维的价值,在保障业务稳定安全的运行的前提下,尽量的节省成本技术只是手段,适合业务的发展才是王道
2022年01月10日
513 阅读
0 评论
1 点赞