【Go 专场｜回顾】Google SRE在B站的落地实践
文案：叶寒晨
排版：钟伊婧
由Google发起，全世界各地谷歌开发者社区组织运营的盛大活动DevFest正在世界各地如火如荼的展开。除了9月25日线下的主会场、以及三个分会场外，GDG Shanghai还为各位开发者以及互联网从业者们打造了若干主题的线上早鸟专场技术分享。
上周三8月31日Google DevFest 2022 上海站成功举办了第一个线上早鸟技术分享，此次技术分享GDG Shanghai邀请到了哔哩哔哩SRE体系负责人刘昊，刘昊老师围绕站点可靠性为大家带来了Google SRE在B站的落地实践的分享！
下面就跟着小编一起来回顾下嘉宾老师的精彩分享吧！
主题
Google SRE在B站的落地实践
回放链接请戳👇
刘昊老师围绕站点可靠性，为大家带来了《Google SRE 在B站的落地实践》的专题分享。
此次分享主要从以下几个方面展开介绍：
案例剖析：为什么我们要做稳定性这件事
从事件切入看运营核心要素有哪些，如何把控这些要素
事件运营的关键实践落地、过程中的曲折教训和总结
案例剖析：为什么我们要做稳定性这件事
案例1：午夜惊魂
暴露问题：
报警触达研发，但未触达对应上下游；
报警未能被职能性处理；
研发同学沉迷查问题，但未及时切换预案止损，防止影响面扩大；
案例2：重大事故
暴露问题：
当一个影响面较大的故障产生的时候，没有统一的故障进展同步方式，通过传播容易失真；
对于大型故障的处理，缺少有效的协调人，了解全貌，知晓进展，统筹协调下游各资源；
缺乏对故障的关联分析，难以产生定论；
故障处理后的复盘成本过高；
案例剖析
通过上述两个案例，我们可以发现，对业务的稳定性及可靠性造成影响的，往往是一个故障。而根据时间段来划分，我们会分为事前、事中和事后。而每个阶段都有它所面临的问题(如上图所示)。
由此可见，在质量运营上，当时B站所面临的现状：
SOP有效执行的执行覆盖率、故障的实际召回率的数字有待考究；
处理链路上的指标，其时效性和真实性无法推敲；
故障牵涉的业务部门广，导致运营成本过高；
因此，对于质量运营的稳定性做建设便有了其必要性。
从事件切入看运营核心要素有哪些，如何把控这些要素
对于稳定性做运行，我们需要有一个核心点抓手，即故障事件。而围绕事件的核心，有：人、流程和工具。
人：是应急响应过程中要参与和执行的一个具体角色；
流程：按照一定的顺序和规章制度，对于故障的响应能够起到有效推进、快速收敛；
工具：保障人和流程的高效顺利的进行，有效度量响应的各个阶段。
核心要素：事件
事件的生命周期
事件可能由人工录入/平台产生；而发生的渠道，可能是告警/变更/客诉导致；在产生事件之后，我们需要有人去响应事件。此时，一个真正的事件就此形成。
当事件的影响范围逐渐扩散，往往会伴随着大量用户和业务受到影响，此时我们就需要将一个普通类型的事件/风险 ，去升级成一个故障，并触发故障的应急协同。触发应急协同之后，通过一系列的定位与止损，最终去达到故障恢复/故障收敛的目标。
故障结束之后，需要对这个故障进行复盘，并且基于复盘去产生一系列的改进项，在改进项完成之后对其进行验收。
事件的阶段度量
我们在前文提到的事件的三个阶段，是比较笼统的阶段。那我们能否有更具体，更精细的阶段去描述这个事件和故障的链路指标呢？那这个肯定是有的，如上图左侧部分，描述了事件的阶段度量：从故障的预防、故障发现，再到故障定位以及故障恢复，到最后故障改进。
整体上，我们从专业指标上分为两大阶段：MTBF(平均无故障工作时间)，MTTR(平均故障恢复时间)。
针对这两大阶段，我们进行进一步的拆分：
MTBF 可细分为 Pre-MTBF(发生前的故障预防阶段) 和 Post-MTBF(发生后的故障改进阶段) ；
MTTR 可细分为 MTTI(平均故障发现时间) ，MTTK(平均故障认知时间) ，MTTF(平均故障解决时间) ，MTTV(平均故障修复验证时间)。
通过上述的阶段度量图，我们能够得出：事件基于时间的不同阶段有不同的形态，以及事件之间有不同的关键节点。
在事件的生命周期中，事件的处理会发生形态的变化，按照前面的三阶段的划分：
当一个事件产生的时候，它可能只是一个告警/客诉/变更/反馈/网络舆情；
在处理中，事件可能会因为影响面的扩大变成一个故障；
在故障结束后，事件的形态又变成了一个复盘存在，并会形成一系列的改进。
基于事件在不同阶段的变化，事件和故障也有一系列的关键时间点，即基于 MTBF 和 MTTR 的时间打点。事件分为：事件发生时间、事件响应时间、事件处置时间、事件升级时间和时间完成时间。而当事件升级为故障后，时间打点更多也更复杂。
通过拆分这么多的时间打点，形成点与点之间的时间间隔。评估支撑某些团队和业务，在周期性内对不同阶段的时间，是否有提升或者下降？并为提供支撑的运维团队，佐证稳定性的提升，提供坚实的数据基础。
核心要素：人
人，作为事件处理的主题，需要去具备一个良好的意识和心态，熟练响应执行的经验，负责参与响应升级和处置等一系列操作。具体的参与方式是通过OnCall能够及时地参与和介入。
核心要素：流程
公司内部制定一系列应急响应的白皮书，明确响应流程。基于事件的大小，明确所要参与的角色和角色对应的职责，以及各个周边子系统的标准规范框架，针对应急过程中的对外通告内容的模板，明确故障过程中的升级策略。对于内部各部门和新同学的入职培训进行周期性宣讲。最后是故障演练，保证实操，避免手生。
核心要素：工具(即事件运营的关键落地实践)
事件运营的关键落地实践
关键实践-OnCall系统
【定位】通过平台来实现人员业务和职能关系的关联，以便去提供一个便捷、精准的人员值班和人员负载的管理。
【目标】对于职能的清晰定位，实现现有人员的合理排班；通过排班系统快速地找到负责人，而不是口口相传。
【必要性】想必大家在工作中经常会遇到以下这些问题：通常问题反馈，我们容易找相熟的同学，即使他当日不值班，这样的行为会打乱他的工作节奏；新来的同学在碰到问题时，不知道内部找哪位值班的同事对接；流程工单的派发对象可能不在当前值班范围内，以及告警信息的泛滥，便会形成一种骚扰。
由此得出了OnCall设计平台的目标：我们希望在正确的时间，能够做正确的事，找到正确的人。
首先，明确了：人、团队、职能、业务的四大核心概念，基于这四个概念构建起一个三维合一的一个模型。由业务和服务、职能和能力的对应关系会产生一个交叉点，团队人员会通过排班小队的方式落在这个交叉点上。同时，平台提供了一个双视角的设计，用以区分一个职能型和业务型的不同值班方式和关注点。
基于上述的核心概念和关联，实现内部的OnCall排班系统，分别走两条线：管理业务-职能-人，管理职能-业务-服务；同时提供角色设置、丰富的排班功能、灵活的通知方式。另外，OnCall系统的能力体现，其实完全依赖于周边的系统接入，基于时段的排班计划，才能确保系统的告警和流程，只能去通知OnCall的人，而不会形成一定的的骚扰。通过排班系统的落地，为某项业务提供某项职能的值班响应，同时通过前端的可视化，可以一目了然地找到值班同事。
关键实践-事件运营中心
【定位】作为一站式的SRE的事件运营平台，能够具备数字化运营业务连续性的能力。
【目标】提升MTBF，降低MTTR，最终实现业务SLA的提高。
围绕事件的三大阶段：事前、事中、事后，能够覆盖到我们事件的产生响应，复盘，改进的全生命周期。
对事前，进行四大类型的拆分：告警/变更/客诉/舆情，通过设计标准化的通用事件上报事件，通过集成的方式，将内部的各个系统打通，实现事件信息的统一收归。在收集的过程中进行一个二次处理，将事件进行结构化的转储。
在事中，通过预定义的规则，对接入的前置四大类型事件的信息进行转化，对事件进行降噪/报警。在这个过程中，如果我们判断一个事件是影响业务的，就会把它给升级成一个故障，触发故障的应急响应的流程。进入到故障响应处理过程，就会产生一系列的角色，例如故障指挥官等。相关人员会先认领角色，再参与故障的止损，从而达到合理分工。通过记录簿来实现故障信息的传递记录，避免复盘时的信息丢失。
故障结束后，也就进入到了事后改进阶段。平台会自动前置专家数据进入到复盘数据中，避免人工二次处理。同时提供了一些预制的故障复盘的问答模板，用来明确团队的各个阶段是否按照预设的目标推进，如果存在问题，则提供辅助性的开放性的问答，对问题进行更深入的挖掘。复盘之后，往往就会产生代办。对于待办列表，平台会定期地去进行状态提醒和处理进度跟进。最终，这些信息都会以知识的形式沉淀在知识库中，去帮助日常的OnCall问答和公司内部的员工培训。
通过这样一整套的平台流程下来，实现把一些日常高频的非结构化的事务驱动因素，去通过统一的接入精准的人员平台的触达，以及事件的闭环管理和持续改进等环节，转化成了一个低频的结构化的，数据驱动的方式去解决。
【系统生态集约化】
平台在场景的覆盖方面，首先主要是针对事件产生的上游来源进行集约化的管理。通过队列订阅/植入提供预置的sdk，将这些监控都通过前面定义的四大类型收归到一起，统一的进行通知的触达。
为了实现各个渠道消息的结构化规约，设计了一个标准化的事件模型。通过这个事件模型把周边的各个系统工具平台的数据信息进行收集和关联。这个标准化的事件模型主要分为五大块：base(事件的基础信息字段)、who(事件从哪儿来以及干预方)、when(事件何时发生，在何时造成影响)、where(事件的来源业务和影响业务)、what(事件是什么、操作对象是什么)。如此一来，我们就建立起来了对事件的关联分析，我们就能够去进一步对事件的告警进行降噪和聚类。
在聚类的执行上，主要分为两大块。第一块儿是横向的意志，支持针对单个来源的事件告警，通过定义好的规则进行收敛。另一块是纵向的意志，因为底层故障发生，它往往会伴随着从下往上所有的受影响的服务都会被波及。基于纵向的一个收敛，就能够把底层的故障在发生之后进行收敛，防止依赖底层的上层被波及产生大量告警。
【协同在线】
通过事件详情页，将整个事件当下的处理人、关联业务、组件和系统信息汇总到一个面板上，进行统一展示。在协同方面，则提供了一键创建应急协同群，组织与职能及业务相关的同学，并彻底解决使用电话、面对面聊天等原始的协同方式。
最终，通过平台功能，覆盖到故障的全生命周期，让全阶段都是通过平台能力去承载。
事件运营落地实践中的挑战
大家知道稳定性其实是个很大的话题，并且这个话题可能大的有点空洞。大家都知道服务不炸就是稳定，但是往往服务肯定会炸。尽管随着我们这么多年来的工程技术越来越完善，在落地这套体系的时候仍会发现，这个体系涉及的太大，依赖的上下游系统过多。
首先是各个系统的元数据不统一。平台之间相互独立，依赖人工。而为了确保底层关联信息的准确性，理顺当中的关系就相当耗时。在落地初期，很难形成一个阶段性的进展和成果。这是一套系统，只有整体都上才能够顺利的运转起来。如果说只是中间的某几环上了，反而是增加了团队的负担。
其次则是工作模式的改变。通过平台驱动使得稳定性的保障工作从无序走向有序；将之前只能定性的指标转变为能够度量的定量指标；在质量保障过程中的一些凭感觉，凭经验的事情，变成了平台上靠具体的流程驱动去完善这件事。
案例总结
通过一系列的基于SRE的稳定性的实践，以及基于这个实践的模型梳理和相关平台的落地，实现了在组织层面，流程层面和平台层面的一个强效联合。能够通过平台的数字化运营能力去保障业务的稳定性。基于沉淀下来的数据，建立了一个科学有效的稳定性评估和提升量化的标准。将之前依靠人工驱动的应急响应，变成现在靠系统去驱动，人工参与进去即可。对于质量的一个运营成本前移，使得运营负载大幅度下降。对于漏报率和召回率等数据也能够进行考究。
【Q&A】
Q1：SRE是一个可以合并运维和QA的工作的角色吗？
QA聚焦于研发的过程和研发的结果阶段；对于SRE或者说传统的运维来说，更关注的是业务对用户的一个大的阶段，除了研发之外的基础设施的关注，比如说我们的机房，基建，中间件，各个服务之间的稳定性。虽然都是质量，但在落地时仍然是两件独立的事情。
Q2：故障复盘的时候总是可能会变成一个批斗大会，遇到这种情况该如何处理？
首先，在公司文化层面，确认对事不对人，我们应更多地挖掘问题，而不是谁写的bug就通报谁。
其次，明确公司红线，对于一些低级的，不遵守制度的，破坏科技的问题，需要严肃处理。
总之，还是需要从事情和技术本身去讨论，因为大家都是为了把事做好。
Q3 如何说服老板来推我们这个这个SRE的体系？怎么去协调这些部门之间的协作？
这其实是一个如何提高老板对于业务稳定性的重视程度的问题。我们在和老板去聊这个事的时候，更多的还是得从业务的质量角度去出发。
首先得和他说清楚质量的重要性。我们公司面临质量的问题很严重，我们需要去提升它。而把这件事做好，对公司、团队和个人都有帮助。例如，在有限的人力情况下，我们把本职工作已经做好了，需要去关注业务的稳定性。当业务稳定性受损的时候，公司的会有资损，会有社会层面的一个影响。
其次是我们有方法论，有手段去把这件事做好，把这个质量管理的过程做到可控。
第三是说清楚，我们是否有额外的人员投入。
相信老板一定会采纳你、认同你把这事给做掉。
Q4 校招的同学想投SRE的岗位，他需要具备哪些技术能力？
学校学习的研发技能是一定不要丢的，常规的这种数据结构算法是程序组成的两大块儿，需要去把它学好。
对运维具有一定的认知，《SRE Google 运维解密》《Google工作手册》《Google系统架构解密：构建安全可靠的系统》是一定要去了解的。
关注业界动态，像阿里的安全生产，华为的确定性运维等，了解稳定性保障的方法论和平台，对于求职会有帮助。
对于网络、操作系统的掌握也是必不可少的。
Q5 比如说我们收到一些客诉，需要将客诉升级到故障的话，一般来说是会制定什么样的标准？
当前我们的一个做法是把客服系统和事件运营中心打通，打通之后会基于打的业务域和业务标识去明确区分问题从属。标准的制定，第一，需要和客服团队去认定。因为客服的职责是反馈问题，而我们要做的第一时间是识别和区分，如果短时间内收到大量客诉，则大概率需要升级成故障，这还是得依赖OnCall系统的配合。第二，基于业务的不同等级，划定某个时间段内，客诉的数量达到多少，升级成怎样的一个故障。
Q6 DevOps和SRE有什么区别？
目前，DevOps的第一个广义的定义是会研发的运维，第二个是指从事这种CI/CD，有持续集成持续交付系统的人员，更关注交付链路的快速和质量。而SRE的关注点则是整个系统对于用户，对于业务的质量和稳定性，围绕稳定性保障框架的生命周期，上下游应该做哪些系统，做哪些平台，制定哪些制度。
Q7 用Go语言开发云原生应用或者一些相关的应用有什么优势吗？SRE跟Go语言有什么必然的联系吗？
B站主要用Golang，对于运维转型SRE的同学来讲，Go语言很简单，没有很多冗长的一些标准规范，原生支持并发，周边的工具链也很完善，性能又足够好，学习曲线很低。和SRE的关系，其实更多是因为Go和SRE都是Google家的。
本期活动资料可通过在公众号回复关键字【Go语言】获取
9月25日，Google DevFest 2022 上海站等你来参加，前期还特别设置了若干个预热场，涵盖Go、Flutter、Android主题。
感兴趣的朋友动动手指，戳戳以下链接👇：
下方阅读原文链接为Devfest2022报名链接，感兴趣的小伙伴们请不要吝惜分享给身边的朋友，一起参加线下或线上活动吧！
悄悄告诉你：活动开始前可以通过转发推文集赞的方式获取礼品！
福利： 转发Google DevFest 2022上海站报名推文（直接点击此链接即可跳转）到你的朋友圈、Github、博客、知乎、anywhere you like，配文中提及 #GDG#，获得10名朋友的点赞，就可以获得 Google 限量款贴纸一张，如果有超过20名小伙伴为你狂点赞， Google 定制眼镜就是你的了！
领取：仅限本人于 9 月 25 日活动现场直接领取，不支持邮寄！
想了解上海 GDG 的其他活动分享内容？请持续关注微信公众号【GDG】和 B站up主【上海GDG】，获取最新录播或内容总结信息。
Google Developer Groups 谷歌开发者社区，是谷歌开发者部门发起的全球项目，面向对 Google 和开源技术感兴趣的人群而存在的公益性开发者社区。GDG Shanghai 创立于 2009 年，是全球 GDG 社区中最活跃和知名的技术社区之一，每年举办 30 – 50 场大大小小的科技活动，每年影响十几万以上海为中心辐射长三角地带的开发者及科技从业人员。
社区中的各位组织者均是来自各个行业有着本职工作的互联网从业者，我们需要更多新鲜血液的加入！如果你对谷歌技术感兴趣，业余时间可调配，认同社区的价值观，愿意为社区做出贡献，欢迎加入我们成为社区志愿者！
志愿者加入方式：关注上海 GDG 公众号：GDG_Shanghai，回复：志愿者。
社区成员加入方式：请发邮件至以下邮箱
gdg-shanghai+subscribe@googlegroups.com