哈啰《两轮业务系统稳定性保障实践》

如何获得讲师PPT：

扫码关注公众号，后台回复「Q108」即可获得讲师PPT哟～

还能一键订阅后续精彩活动内容～

Q&A环节答疑：

1、（稳定性建设总视图）这些都是人为的吗？能自动发现并编排处理吗？ 

对，接下来我们要做的，正是之前提到的展望部分。我们的目标是构建一个全面的风险防控体系，将预防、发现、应急以及整体故障问题的优化改进等环节紧密串联起来。同时，我们也致力于实现更智能化的管理，减少人力投入，向这个方向持续演进和发展。

2、想问下风险巡检的一些思路 

Ok，目前我们的巡警平台正在建设中，并已初步完成出版。我们深知，微服务架构的核心在于服务的相互访问与调用，从而形成一个庞大的调用网络，支撑起我们整个分布式系统的业务。因此，在巡检时，我们将以服务为最小单位进行。巡检的范围将包括多个维度：首先是对静态代码的扫描，检查其中可能存在的问题；其次，关注与自愈相关的服务维度，比如熔断降级、超时限流等方面的巡检；此外，还会涉及性能和成本方面的考量。

特别值得一提的是，服务维度的巡检中，我们还会关注一些重要指标，如异常指标和必须配备的指标，确保它们都已配置妥当。这将对我们后续在变更场景中的可观测性提供极大的帮助。

简而言之，我们的巡检思路是以服务为基本单位，深入各个维度进行细致检查。接下来，我们将进一步将视野扩展到整个链路，通过服务编排，在平台上对服务风险进行组织和管理。最终，我们将从整个链路和更上层的场景角度，全面审视和评估风险。这便是我们整体风险巡检的基本思路。

3、故障这块如何做根因定位？ 怎么根据推荐方案进行编排进行自动的故障恢复保证稳定性？

这块工作，我们目前拥有专门的效能平台工具来处理。实际上，我们不会将这部分内容交由业务侧的稳定性团队负责，因为它涉及一些较为深奥的算法和专业知识，对技术要求相对较高。因此，目前这部分工作并不在我们内部团队的职责范围内。不过，如果对此有兴趣，未来我们可以邀请相关团队的同学来与大家分享这块内容。

4、核心场景变更风险防范，这块能不能重点展开下？ 

核心场景变更风险防控至关重要。首先，我们必须明确核心场景，否则防控工作无法有效落实。因此，需要牵头所有业务研发、测试和产品团队，共同评估并确定哪些是我们的核心场景。随后，基于这些核心场景，我们进一步分析哪些服务承载着这些场景。接着，我们会将这些核心场景和相关服务一一标出。标出后，我们将采取两项措施：一是针对核心场景，制定固定的强制用例，由测试团队负责编写，以确保场景的稳定性；二是针对承载核心场景的服务，我们将实施重点保障，包括依赖关系的保障和其他内部逻辑变更的保障。这些保障工作将通过公路障演练和核心用例测试两种方式相结合来实施，从而有效防范核心场景变更风险。

5、请问一下，哈啰技术风险小组在推动稳定性建设方面，是怎么和业务团队同学沟通和协作的？ 

关于沟通协作，我在之前的PPT中已经提及。要真正实现高效的沟通与协作，不能仅仅依赖人格魅力，更需要一些背后的约束机制来推动。例如，我们设有奖惩机制，如“红会”等，这些都是为了促进团队之间的积极互动。这样的机制不仅能正向激励团队主动承担技术风险，还能反向推动他们主动询问、沟通，共同探讨如何更好地完成任务。这种双向奔赴的沟通方式，使得我们的整体沟通和协作更加便捷和顺畅。除了这一点，我在PPT中已经详细阐述了其他要点，希望大家能够深入理解并应用到实际工作中。

6、（风险运营机制部分）你们风险信息是怎么及时传递和处理的？ 

后续我们将通过正在建设的风险巡检平台，每天实时运行风险检测，遵循既定的巡检思路，将潜在风险一一排查出来。之后，我们将通过常态化的实时触达机制，如钉钉通知和邮件提醒等方式，及时将风险情况传达给相关人员。此外，我们还将定期发布风险数据通报，包括周报、月报等，以便大家更全面地了解风险状况。目前，由于巡检平台尚在建设阶段，部分风险发现工作可能仍需人工参与，但随着平台的逐步完善，这种情况将逐渐改善。

7、标准架构是指什么 ? 

我们刚刚提及的谷歌的SIA金字塔，其核心便是稳定性。而稳定性的最高境界，其实源于两大核心要素：架构设计与产品设计。这两者对于提升系统稳定性的上限至关重要。接下来，我来详细阐述一下标准架构的相关内容。

在标准架构的构建中，我们注重横向和通用性的整合。为此，我们的系统底座必须遵循一系列标准，无论是规范、架构规范，还是日志、数据采集、包结构、接口等，都需要进行统一的约束。这种约束基于我们的共识，确保各项工作能够有序进行。

同时，我们也关注业务架构层面。在推动架构治理的过程中，我们致力于将一些通用能力进行沉淀，并明确上层业务的边界，实现良好的解耦和边界清晰。这样做不仅有助于提升系统的稳定性和可维护性，也能为后续的工作奠定坚实的基础。

从技术风险的角度来看，标准架构更偏向于技术架构的规范。只有当我们拥有一套完善的规范体系，其他诸如巡检工具、流程规范等才能顺利落地。否则，面对各不相同的系统，我们可能需要进行大量的定制化工作，这不仅会消耗大量的人力物力，而且最终的效果也可能不尽如人意。

因此，标准统计架构的核心在于确保系统的一致性和规范性，为后续的稳定性工作提供有力的支撑。

8、线上演练怎么模拟弱依赖和强依赖的故障场景的？

关于如何模拟或调整强依赖，我首先要澄清，我们目前并不模拟强依赖。实际上，我们更侧重于在线上实际操作。而关于你提到的故障平台，它是我们用来进行故障演练的重要工具。至于它的技术实现原理，是基于我们熟知的ChaosBlade技术。

目前，我们正在线上进行故障演练，通过直接注入故障来测试系统的表现。在此过程中，我们特别注重控制影响范围，也就是所谓的“爆炸半径”。为此，我们采取流量打标的方式，确保故障只影响我们内部的部分流量，避免对外部用户造成不必要的干扰。

在具体操作时，我们并非对整个服务集群注入故障，而是选择特定的节点进行。这样做的好处是，即使故障触发了熔断降级等机制，其影响也仅限于我们内部，不会对整个线上支持造成严重影响。

至于强依赖方面，我们目前主要关注基础设施的建设和演练。通过模拟和测试，我们希望能够提升基建的HHA能力以及其他关键能力，以确保系统的稳定性和可靠性。

9、生产环境会进行哪些故障注入场景？

我们目前关注的场景主要聚焦于应用层以及与之相关的底层因素。在应用层面，我们已经模拟了多种故障场景，包括提升CPU负载、填满内存，以及模拟接口返回非超时和超时类错误等。这些模拟测试旨在检验系统在各种异常情况下的表现。同时，我们的业务团队和基建测试团队都在积极参与，业务团队主要关注业务层面的故障模拟，而基建测试团队则专注于基建内部的故障演练，以确保整个系统的稳定性和可靠性。通过这些模拟测试，我们能够更好地了解系统的性能表现，为未来的优化和改进提供有力支持。

10、你们目前建设的平台，支持实时风险预警和动态调整风险防控策略吗？ 

目前，我们已具备支持能力，并会进行相应的调整。目前主要支持实时的预警功能以及实时防控策略的调整。我们将持续优化和完善这些功能，以更好地满足需求。

11、风险大盘包括哪些重点内容呢？

我们主要关注几个方面的巡检内容。首先，是我们变更的一些具体内容。其次，是线上告警的详情，包括告警的内容和线上报错的信息。此外，我们还要检查与自愈相关的配置，如熔断降级、超时、限流等，确认它们是否配置得当。目前，大部分风险都集中在这些方向上。实际上，这些巡检内容与我刚刚提到的巡检思路紧密相关，都是围绕我们整体服务层面进行的。

12、摸高压测的时候，容量标准是怎么定的？ 

关于容量标准的问题，首先，我们需要明确为何需要设定这一标准。这主要是因为在我们这边，当进行数据压缩时，涉及到数据构造的过程。目前，我们的数据尚未实现循环使用，因此在实际操作中，我们主要考虑两个因素。

第一，我们会考虑目前可用的压缩数据情况。这些数据是我们设定容量标准的重要依据。

第二，我们设定的标准还需要根据我们的业务形态进行调整。两轮业务本身不会出现突发性的需求，除非是一些特殊情况，如工具的使用，这时我们可能会通过限流等方式来应对。但在正常的业务形态下，两轮业务是持续在高水位运行的。

基于上述考虑，我们有一个判断标准，即选取某一年历史数据中的最高峰值，并以此为基础，设定承载量为最高峰值的两倍，以此作为我们的容量标准。这样，我们就能确保系统在高负载情况下仍能稳定运行，并将其作为一个摸高的参考。

13、评估模型都是根据已知的情况做的，但是未知的如何预防，比如不可逆的变更操作导致故障产生，如何快速消除故障？ 

我理解你的意思，同学们可能更关心的是在极端情况下，我们如何设定和应对RPU和RTU的问题。确实，想要完全避免线上出现问题是不可能的，我们只能尽力降低故障的影响。在这方面，我们确实有一些可做的措施。

首先，在变更管控方面，我们需要加大力度。在前期阶段，我们不能允许一次性将所有变更都直接上线，必须强制进行灰度验证。这样，我们可以逐步放开流量，尽量减少对线上服务的影响。

其次，当故障发生时，快速恢复是关键。预案的制定和执行是非常重要的，其中数据恢复是一个关键环节。但除了技术层面的处理，我们还需要考虑应急场景的联动。这可能需要公关部门、运营部门等其他部门的介入，共同制定一个全面的业务连续性方案。

在整个应急过程中，我们需要从业务侧到公关侧的所有部门都联动起来。因为应急不仅仅是技术团队的事情，它是整个公司的事情。我们需要共同协作，确保在出现问题时能够迅速、有效地应对。

最后，关于你提到的不可逆的变更，确实，有些问题可能无法提前预防。但我们可以通过严格的变更控制和应急机制，将影响控制到最小。在应急过程中，我们需要全面考虑，确保所有相关部门都能够迅速响应，共同应对挑战。

总的来说，我们需要从技术、流程、团队协作等多个方面入手，确保在面临各种挑战时，我们都能够迅速、有效地应对，保障服务的稳定性和连续性。

14、排障平台是怎么还原用户行为的？ 

目前我们的主要工作是设置数据收集点。我们会将一些唯一的标识，比如ID等，嵌入到这些收集点中。这样，当用户进行一系列操作时，我们就可以通过我们的排练平台大致还原出他们的行为。

之前我们也遇到过一些挑战，比如当请求到达后端时，我们需要确保能够准确地还原用户的行为。幸运的是，我们有一套分布式的链路追踪系统，这使得还原工作变得相对简单。

然而，有些情况可能会比较棘手，比如当用户在前端中断操作时。为了应对这种情况，我们开发了一个平台，它可以同时采集前端和后端的数据，包括后端的一些关键信息点。通过这个平台，我们可以更全面地还原用户的行为。

总的来说，我们的目标是通过这种方式，对用户的行为进行全方位的追踪和还原，以便更好地理解和优化用户体验。