直播问答丨保障业务稳定性的SRE落地实践，这17个问题不要错过 - 运维 - dbaplus社群：...

刘昊 2022-05-23 11:23:51

4月27日，哔哩哔哩-基础架构部-SRE体系负责人刘昊老师在deeplus带来了《B站保障业务稳定性的SRE落地实践》线上直播分享，同时将直播内容整理成文《B站崩的那晚，连夜谋划了这场稳定性保障SRE升级之战……》分享给大家。

在直播过程中，刘昊老师也在线回答了观众提问，解答了观众团队职能划分、系统选型、故障处理方式等方向的疑惑，本文精选出17个问题和解答与大家分享：

Q&A

Q1：咱们SRE团队从模块划分岗位职能，比例是怎样的？

A1：B站SRE隶属于基础架构部，按照不同的岗位职责，拆分了像在线业务SRE、大数据和AI SRE、基础设施SRE、数据库SRE和SRE体系等团队。

Q2：B站的SRE团队，开发工作量占日常的多少？

A2：B站SRE相关团队同学都需要参与开发工作。不同SRE团队之间的区别在于所参与到的开发项目规模、复杂度以及参与时间投入上。以我所负责的SRE体系团队为例，开发工作量基本占到日常工作时间的80%（相比运维工作）。而在线业务SRE团队，开发工作量可能只占到日常工作的40-50%。

Q3：在Trace系统选型和实践，有哪些建议吗？你们通常选用哪些？

A3：B站在Trace系统的实践上，一直紧跟业界开源技术方向。从最早的dapper到jeager，再到如今的opentelemetry体系。建议想要在公司实践Trace系统的同学，可以多多关注opentelemetry社区，一起参与共建。

Q4：目前你们有在做可观测性实践这块了吗？

A4：可观测性是我们目前比较关注的一点，从之前的漫谈监控到如今的可观测性。我们从一个更加科学、更加体系的方向去构建服务的观察、度量体系方案。我们构建了统一的跨语言标准规范、标准化各类型采集器和SDK、打通接入处理链路和可视化平台，围绕tarcing、metrics和logging三大块形成数据串联，对内提供了一套统一的观测平台。

Q5：on call 有没有"故障"问题维度的分层？例如warning？error？

A5：关于问题维度的分层，首先我们通过服务级别、指标阈值等定义将问题分为了事件和故障，诸如非目标阈值我们会形成事件，由对应业务、职能的oncall同学处理。当事件的影响范围扩散时，会被升级到故障。这两个是大的分层概念。在具体到单个事件、故障里面，我们会通过影响程度和紧急程度评级进行优先级分层。

Q6：oncall 值班人员，是轮询业务人员吗？故障报告官需指定业务ower来负责吗？

A6：目前，在我们的实践中oncall的值班人员分为业务和职能两块。业务oncall人员更多是业务线研发同学，职能oncall人员更多为SRE、DBA、基础架构相关同学。

故障上报人员，没有明确指定，谁先发现谁先上报，对应业务SRE同学会作为兜底。故障指挥官，一般采用上报同学为故障指挥官。鉴于上报同学需要聚焦处理问题，我们内部有专门的故障指挥IC虚拟团队，会在中大型故障发生时，接管故障指挥工作。该虚拟团队的构成以业务owner和team leader为主，定期会在内部培训选拔同学加入。

Q7：针对故障的发现有什么好的方式？

A7：故障的发现，目前我们有如下4种渠道：

• 各层监控告警：如基建、系统、服务、业务、用户体验和端到端等监控，适合发现指标不符合设定阈值的告警；

• 基线告警：通过算法对历史数据分析，生成精确的基线数据，适合发现指标缓慢下跌的故障场景；

• 故障自报：通过代码review、服务日志分析、数据分析等手段发现的故障；

• 用户反馈&舆情：内外部用户在日常使用中遇到的问题，或者舆情系统从各社交媒体发现的故障。

Q8：故障的恢复方式是系统自愈还是人工处置？

A8：故障的恢复方式，目前大多数还是以人工处置为主。在部分比较固化的场景下，实现了局部自愈，比如磁盘故障场景，我们实现了服务自动切换-\>故障盘自动剔除-\>报修-\>修复后自动加入集群等一系列流程的自动化闭环。

Q9：人工处置效率的提升有哪些好的措施？

A9：人工处置效率的提升，依赖于从人工操作到自动化的转变。在传统人工处置模式下，效率提升依赖于SOP的丰富和人员的熟练操作，例如：让SOP覆盖的场景足够多、SOP内容足够清晰简约、人员日常定期演练操作SOP内容等。基于此，我们可以通过将SOP的内容转化到内部的作业平台、预案平台形成对应场景的自动化预案，进而人工处置时，只需要匹配场景预案点击执行即可，即可以提升处置效率又可以保障处置过程的高可靠。

Q10：请问业务全流程是怎么监控起来的？如一个系统故障，怎么能够迅速展示会有哪些别的系统受到影响？

A10：业务全流程监控依赖于可观测性系统的构建，比如其中的trace系统。这里有几种情况，当一个业务服务故障时，我们可以通过trace系统，及时发现业务的上下游关联，迅速判断影响范围。当一个基础服务故障时，我们会通过服务在服务树的拓扑关系来判断影响程度，比如一台k8s的物理机宕机，我们可以通过该服务器所归属的k8s集群，查询服务器上有多少容器服务，这些容器服务都归属哪些业务服务，从而获取可能造成的影响范围。

Q11：事件事中处置的优先级是按照紧急度还是影响度？还是两者结合？现实中事件的影响度人工如何判断？

A11：针对事件的级别构成，是有两个指标：影响程度和紧急程度。在日常判定中，我们一般以影响程度为主要参考。在一些特殊case上，会以紧急程度为重要参考，比如在一些涉政及低俗内容等问题处理上，这两者比较独立，在处理过程中，也没有发生过影响现场处置的冲突问题。

Q12：前面事件处置阶段，感觉根因定位跟故障恢复还是有些冲突，按照前面案例说的，应该是先执行预案后定位根因吧？

A12：在事件处置过程中，不建议进行根因定位。需要注意的是，这里是指根因定位，不是指故障的定位。这两者的区别在于，一个是定点、一个是定界。举个例子，当一个业务受损时，故障处置同学需要知道是哪个服务（定界）出现了问题，才能够执行对应的止损预案。此时并不需要知道是服务的具体哪一行代码（定点）出了问题。

Q13：B站有实践提升资源利用率来节约成本？B站的资源利用率大概多少？

A13：提升资源利用率是B站基础架构部门的核心目标之一。在实践中，一方面我们从各个基础架构服务自身，通过技术手段降低资源消耗，提升资源利用率；另一方面，我们通过数据化和可视化的运营手段，持续推动基础架构服务和业务团队对资源进行合理有效的使用。

Q14：预案的执行维护是怎么做的，是有专门的预案平台吗？

A14：目前在产品侧还没有比较通用的预案平台，正计划研发。现状是内部的一些关键系统会基于作业系统和APIGateway在自己平台内构建预案功能。

Q15：B站的基础资源监控有使用动态阈值吗？收效如何？

A15：B站的基础资源监控在一些常见指标上进行了动态阈值监控，比如cpu、mem、流量等。通过动态阈值，极大简化人工的配置压力和准确度，减少了大量误报，提高了准召率。

Q16：你们每个接口都有SLO吗？还是只有关键的服务接口？

A16：目前，我们仅针对一些高Level的服务制定了SLO，选取指标均是服务的一些关键接口。

Q17：容器等新技术投入是否能提升SLA指标？

A17：我认为，新技术引入和提升SLA没有必然关联。这里需要辩证去看这个问题，一方面新技术的引入，短期可能还会增加产线的不稳定性；另一方面引入新技术往往是因为现有技术无法很好满足业务或技术等层面的需求，选择引入它必然是做了大量调研和测试工作，认定它的引入能带来改变，比如提升SLA，降低Cost等。

热点话题征集

在数据库、运维、大数据、架构等技术落地过程中，以及在技术管理、个人转型提升等过程中，你还存在着哪些疑惑？扫描下方二维码，提出你的疑惑，我们将会有针对性地邀请业内大咖为你排忧解难~

ps：问题被收录解答，

并在dbaplus社群公众号发布后，

将可免费获取技术书籍一本
点击此处回看当期直播