“谈故障色变”到有章可循：美图 SRE 故障应急与复盘实践

在 VUCA 时代，IT 系统日趋复杂、多变、脆弱，线上故障频发，如何快速有效地进行应急处置、保障系统的稳定性是每一位 SRE 必须直面的问题。

在 InfoQ 举办的 QCon 全球软件开发大会上，美图高级运维经理石鹏做了专题演讲“谈故障色变”到有章可循：美图 SRE 故障应急与复盘实践”，分享结合美图 SRE 团队的实践经验，深入探讨故障应急的各个环节。并由此展开，给大家呈现一个典型的“故障生命周期”。他沿着这个脉络对故障的本质和常见原因进行剖析，对可观测性建设、灾备建设、应急预案及演练、故障复盘等日常高频工作场景进行讲解。此外，他还对 AIOps、LLM Ops 等前沿的技术与现场的听众做了一些探讨和交流。这些内容对于听众，尤其是中小型企业的 SRE 同学，在提高应急响应能力、提升系统稳定性建设水平等方面会有所帮助。

预告：最好的系统不是永不崩溃的系统，而是每次崩溃都能变得更强的系统。将于 10 月 23 日 （本周四）召开的 QCon 上海站策划了「混沌工程与全链路压测」专题，本专题邀请了相关行业的专家们分享混沌工程及全链路压测的成功案例，您将获得有价值的实践经验参考以及提升系统可靠性的前沿方法。敬请关注。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

从一组灵魂拷问开始，你会不会“谈故障色变”？因为在行业里待久了，故障是绕不开的话题。面对故障和异常时，你会慌吗？我想，故障其实就像一场考试，用来检验你平时的稳定性保障工作是否到位。就像上学时考试，如果平时学习和复习做得好，有章法，自然不会慌。但如果平时没准备，考试时就只能靠运气或天赋了。当你有经验、有套路、有预案时，面对故障会更踏实、更稳。但如果平时工作没做到位，就会慌。当然，即使有经验积累，面对特别复杂或重大的故障，也可能慌。不过，如果有解决思路和方法，就会相对从容一些。

洞若观火：洞察本质，掌握规律

首先，要深刻洞察故障的本质，分析其规律并学习相应方法，以此展开工作。在这个章节，会介绍一系列方法和框架，帮助大家更好地理解和应对故障。SRE 的核心职责是保障系统的稳定性、效率，实现降本增效和安全生产，从而支持企业发展。所有工作，包括稳定性建设，都要服务于企业目标，与业务价值对齐。例如，提升系统可用性（如从三个 9 提升到四个 9）需要投入大量资源，是否值得做要根据业务价值来判断。

下图的《可靠性工程白皮书》汇集了行业优秀实践，总结出一个可靠性的框架，包括可靠性设计、研发保障、业务上线准入、发布管理、应急管理、上线后的持续优化等环节。按照这个框架开展稳定保障工作，可以按图索骥、避免跑偏，虽然这个框架不见得会覆盖所有的场景和环节，但据此实现基本的可靠性定是绰绰有余的。

故障生命周期包括故障发生前、中、后三个阶段。SRE 在故障发生前要进行建设演练和 OnCall 准备；故障发生后要应急响应、止损、恢复业务；之后要复盘改进，进入 PDCA 循环，持续提升稳定性。故障是常态，系统失效有必然性，这是自然规律。所有干预手段都有代价，如人力投入、机器扩容等。常见的故障原因包括单机故障、负载变化、人为错误、配置变更、强关联依赖、资源耗尽等。

提升稳定性需要度量，常用指标是 MTTR（平均故障恢复时间）和 MTTF（平均无故障时长）。通过细化 MTTR 的各个阶段（如识别时间、定位时间、干预恢复时间、验证时间），并缩短这些时间，可以提升整体稳定性。具体方法包括：

• 故障识别：增加监控点，覆盖端上、服务端、链路跟踪、舆情监控等。

• 定位时间：使用自动化工具和 AI 方法，关联可观测指标进行分析。

• 恢复过程：制定预案，实现自动化、一键恢复或者自愈，确保团队协作紧密、人员配备整齐、步调一致。

• 验证恢复：实现自动化感知恢复状态。

SLO（服务水平目标）设立要合理分级、差异化，与业务价值对齐，考虑业务场景、核心旅程、分级矩阵等。业务方（如业务老板）要参与 SLO 设立，明确营收指标与系统稳定性要求的关系，量化 SLO 不达标对业务的损失。同时，要建立快速响应和处理机制，避免过度投入，确保投入与收益平衡。SLO 指标要可衡量、可观测，可能需要多个指标组合来定义稳定性目标。此外，要引入平衡机制，如错误预算，鼓励业务创新。

SRE 的文化建设与团队协作很重要，业务团队和技术团队都要参与 SLO 设立并对其负责。业务研发与 SRE 的协作也很关键，好的架构设计和前置工作可以极大提升服务质量。整个体系要持续迭代，适应业务和技术的发展，始终与核心价值对齐。

业界常用的两种可用性定义方法是基于不可用时间（或可用时间）和基于可用请求占比。不同的业务场景选择不同的方法，如云服务通常按不可用时长计算，SaaS 服务按成功率计算。我们内部 SLO 通常按请求数占比制定。

未雨绸缪：体系建设，主动出击

我们要做到未雨绸缪，提前规划工作，这样才能在面对故障时从容不迫，并且工作要有体系化和方法论，不能盲目尝试各种技术，否则难以发挥真正的价值。根据建设难度和能力要求等级，可以将工作划分为不同阶段，虽然划分的矩阵可能不完整，但能体现发展阶段和未来目标方向。其中，浅色部分是 SRE 必须做到位的基础工作，否则难以立足；稍深色部分是进阶工作，做好了可用性不会太差；再往下需要具备更多自动化能力和 AI 增强能力。

下图中的清单比较适用于中小型公司，不依赖大规模成熟开发团队，而是通过体系化流程制度和组织内部共识，将工作提升到及格水平。例如，常规的 OnCall 轮值、巡检和节假日重点保障是日常工作。今年还筹划成立公司内部的稳定性保障虚拟组织，把全年节假日和重点保障节点列出，匹配相应动作，根据节假日流量特点和保障级别勾选需要执行的事项，实现资源与稳定性目标的平衡。

稳定性运营机制也很重要，从三四年前开始，运维向运营转变，核心在于主动和被动的区别。运维是被动解决问题，运营则是主动做好日常工作。例如，每天自动化巡检，OnCall 的 SRE 查看核心指标和业务 SLO，每周发布稳定性运营报告，同步稳定性事件、响应情况和建设计划，达成共识并持续运营。

可观测体系方面，不同等级有不同的要求，更好的话要实现拓扑关联分析和故障根因关联推荐。高可用体系需要有意识去做，包括容量规划和柔性架构设计，后者需要研发重点参与，SRE 只能提供框架和方法推荐。后续还有故障自愈、流量智能切换调度和故障自动转移系统等。应急系统虽然标为中等难度，但实际上基础等级也应覆盖，至少要有预案并进行演练，最好能一键触发。再往上有混沌工程、智能推荐等，最高阶的是类似庞大智慧调度系统的功能，可能涉及多个周边系统和资源调度，结合 Multi-Agent 等技术，但这可能需要一两年时间才能实现。

稳定性运营体系建设

稳定性运营体系涉及多个方面，包括 Oncall 轮值、巡检和重点保障等，核心在于信息对齐和目标对齐。实际工作中，业务流量突然增加且原因不明的情况时有发生，比如业务团队增加了推广或推送。这种情况下，需要建立机制，提前收集可能影响稳定性的信息，做好准备。

举个小例子，我们的业务既有 ToC 也有 ToB，在某些 ToB 业务场景中，售前团队为客户做 Demo 演示是一个关键环节。如果演示现场出现问题，则可能会影响演示效果甚至影响最终成单。虽然从技术侧看问题本身可能不并大，比如只是因为做了某些后台变更或 (轻微、合理的) 有损操作。因此，需要提前对齐信息，明确演示时间、重点功能等，确保资源和服务响应到位。

此外，我们还有例行分析和巡检报告。巡检报告不仅记录数据，还会加上专家经验的批注。例如，网络基础设施的日常水位如果在巡检时发现过高，我们会分析原因并批注，指出潜在的不合理使用或隐患。如果不及时解决，这些问题可能会引发更大问题。

最近我们发现一个案例，安全团队有一个流量拷贝组件，运行在一台没有公网 IP 的机器上，需要通过 NAT 网关进行扫描。每次扫描时，机器会建立大量连接，虽然未达到 NAT 网关的告警阈值，但巡检时会发现连接数突然上升。如果这些连接不及时释放，会导致 NAT 网关连接表一直维持高水位，等待老化时间。如果不主动解决，长期积累可能会在业务高峰期引发问题。通过巡检，我们可以识别潜在风险，尤其是趋势性风险。单独看某一天的数据可能正常，但拉长时间维度（如一周或一个月）来看，就能发现潜在问题，从而提前投入资源解决。

可观测建设

可观测性常规的要点包括 Metrics（指标）、Trace（链路跟踪）和 Log（日志），以及系统事件、变更事件等内容。Metrics 用于监控告警，帮助判断是否有故障发生，是常规巡检中常用的手段。Trace 用于确定故障发生的位置和范围，而 log 和事件则能提供故障的具体原因。

在实际工作中，我们不仅有手动绘制的拓扑图，还有自动化的拓扑生成工具。这些拓扑图会包含容器化业务中的 K8S 服务、Pod、Deployment 等关联信息。但由于 Pod 频繁创建和删除，这些信息可能冗余、失效，导致数据量很大。我们还会从 CMDB 中提取人为标注的更精确数据，并抓取机器间网络连接信息，通过 eBPF 方式获取实体间的连接关系。虽然这样获取的数据看似完整可用，但实际使用起来较为复杂。

我们 (之前) 基于 Flow Charting 插件手绘了业务逻辑图，将每个模块与核心指标绑定，作为北极星指标图或“灭火图”。在双 AB 架构中，当一侧出现问题变黄或变红时，收到告警查看此图，能快速了解整体情况，比在大量告警中查询更高效。此外，我们还有全域 SLO 和 HTTP 域名 SLO 大盘，当基础设施出现大面积故障时，这些大盘能帮助我们了解整体情况并进行故障恢复。同时，我们需要关注事件，尤其是变更事件，因为业界数据显示，70% 到 80% 的线上异常和故障是由变更引起的。查看问题时间点前后的事件，有助于快速定位问题。在告警实践中，我们尝试在告警中附带结构化的拓扑图，而不仅是传统的文字告警。例如，当业务系统发生告警时，告警消息中携带的拓扑图会将问题模块的颜色自动标红，方便我们快速定位异常位置、提高定位效率。

应急预案及预案演练

应急预案和预案演练的方法梳理特别适合中小型公司，如果尚未开展相关工作，可以参考以下内容进行实践。首先要进行服务梳理和预案梳理。梳理请求链路时，需采用分层分段的方法，明确系统模块间的依赖关系，识别强依赖和弱依赖模块，以及潜在风险点，例如单点故障、容量风险等。基于这些识别结果，制定一系列预案来应对潜在风险，比如将单点改造成高可用架构，从单 AZ 扩展到多 AZ，甚至考虑异地多活等。

有了预案后，不要急于投入建设，而是要先进行沙盘推演和论证。针对每个潜在风险和预设的解决方案，组织跨部门、多角色的团队进行头脑风暴和相互挑战，确保预案的有效性。通过这种相互磋商的过程，达成组织内部共识后再投入建设也不迟。

在落地实践方面，要关注文档功能、架构匹配以及长期的工具建设，例如基础调度平台和开发框架等。同时，演练工作要循序渐进，不要急于求成。可以先从无损、轻损的单点演练开始，逐步过渡到组合演练，逐步释放风险，确保整个过程更加稳健。

SRE 工具箱建设

我们公司目前正在进行 SRE 工具箱建设。过去两年，公司投入大量时间和精力在 AIGC 业务上，但在稳定性建设方面的投入相对不足。这个工具箱建设的思路是基于故障生命周期，明确每个阶段需要做什么，以及平台需要具备哪些工具和能力来支撑这些工作。

在建设初期，我们计划与业务团队达成共识，明确业务的 SLO。这包括确认业务的测试是否到位、服务的 SLO 要求是什么，以及哪些是核心业务。通过这个共识过程，确保 SRE 的人力投入是有效的，并与业务目标相匹配。后续，我们还计划对业务进行评分，根据其稳定性表现给出量化评分。例如，如果业务在架构设计、高可用性、预案完备性等方面都做到位，就会得到高分；反之则得分较低。这种评分机制有助于在组织内部进行多业务之间的横向比较和对标，形成一种内部竞争的动力。此外，我们还在设计故障报告的自动生成等功能。这个平台预计今年会逐步完善 (截止发稿，平台的一期功能已经上线)。

我们还有一个应急响应平台，英文名称叫 FAF，意为“Fight Against Failure”。该平台将对服务干预的手段抽象成一个个动作，并将这些动作注册到平台中。然后，通过编排这些动作，形成一个个预案。预案可以支持串行、并行、前后依赖等多种执行方式。最后，预设一些场景，根据场景匹配相应的预案。预案的执行方式可能有损、无损，可以通过卡片推送等方式手动或自动执行。未来，这个应急响应平台将整合到前面提到的 SRE 工具箱平台中。

指挥若定：有章可循，有条不紊

当故障真正发生时，我们需要迅速采取行动。通常，每个公司都会有一个应急响应组织，比如“消防群”或“消防队”，用于快速应对故障。在处理故障时，要遵循几条原则。首先，统一目标，优先恢复业务。在故障处理过程中，止损和定界问题的优先级高于定位问题的根本原因。线上调试是严格禁止的，如果有快速恢复的手段，必须优先使用。这是处理故障的基本原则。其次，SRE 团队必须保持冷静，不要慌乱。SRE 的职责就是应对这类问题，而且团队已经做了大量准备工作，应该有信心。即使面对未曾经历的故障模式，之前积累的方法和经验也能帮助获取信息、做出判断，并组合现有的干预手段来解决问题。

总之，保持冷静是关键。此外，流程机制必须明确。如果没有事先约定，故障处理过程可能会陷入混乱，决策机制也可能失效。因此，需要提前明确故障现场的角色分工，包括谁负责故障通知、谁负责指挥调度、技术模块由谁负责更高效等。同时，还需要有故障升级机制，例如一键进入“作战室”，以及在故障未恢复时如何升级等。通过这些原则和机制，可以确保在故障发生时能够高效、有序地进行处理。

机制流程约定

在故障处理过程中，机制流程的约定至关重要。常规流程是 OnCall 人员接到告警后开始响应，初步判断故障的影响范围。如果已有预案可以直接解决问题，则直接执行；否则，需要将信息告知更多人，进行初步排查。必要时，拉起“作战室”（War Room），进行更大范围的响应。在故障恢复过程中，如果故障仍未恢复，需要将信息告知更广泛的团队，召集更多人共同处理。此外，无论故障是否恢复，定期通报都是必需的；尤其是需要要让管理层了解进展，避免因长时间无反馈导致管理层焦虑；必要时也需要周知到客服、公关等对外部门，以便开展相应的工作。

这种机制流程的设定有其理论支撑，是一种结构化的事件响应机制，旨在实现标准化和流程化。如果能通过平台覆盖整个事件响应和处理过程，甚至可以实现自动化。同时，需要形成制度，有效降低故障恢复时间，提高处理效率。这种机制还能在组织内部达成共识，便于在处理故障时整合更多资源，避免资源瓶颈和响应真空地带，减少因流程不合理带来的二次影响。

现场指挥

现场指挥时，需要明确角色分工，包括指挥官、业务 OnCall、SRE OnCall、DBA OnCall、Infra 平台 OnCall 等人员。这些角色可能会随着故障升级、范围扩大或人员临时变动而调整，需要灵活应对。在处理过程中，要保持信息畅通，决策要理性、客观，识别并消除噪声，避免因错误信息导致故障扩大。同时，要区分指标变化中的原因和结果，这在某些场景中可能并不清晰，需要仔细甄别。

这种机制的建立基于对体系方法论的提炼和归纳，分为组织结构和体系、指挥灵活性和适用性等方面。组织结构和体系确保每个人定位清晰，资源在故障处理场景中配置到位。指挥灵活性和适用性参考了美国空军的 OODA（观察、判断、决策、行动）循环，强调快速迭代，以应对不确定和复杂的场景，避免因流程固化导致的响应延迟或失效。此外，还要注意认知管理，避免思维惯性、认知偏差和噪声的误导，并建立明确的决策机制，确保在高压场景下系统能够有效运转，避免决策机制瘫痪。

常见故障场景及常见手段

在故障处理中，常见的故障场景及应对手段可分为常规和非常规两类。常规故障包括服务 SLA 下降、超时、资源连接失败、内外部依赖异常等，尤其是业务重度依赖外部 API（如大语言模型、SaaS 服务）时，依赖异常可能导致服务问题。此外，单 Pod 异常、系统资源抖动等也是常见情况。应对这些常规故障的手段包括监控日志、告警、链路跟踪、预案匹配执行、故障隔离、流量切换，以及重启、扩容、回滚等较为直接的方法。

非常规模式及处置方法

非常规故障场景则更为严重，例如大规模雪崩效应、基础设施（如云服务的 AZ 或 Region 级别）故障、硬件失效、稀缺资源耗尽等。以 AIGC 业务为例，GPU 资源消耗巨大，春节期间资源需求激增五六倍，这种情况下资源获取困难，需要内部和外部多方协调解决。此外，还有可能出现安全攻击，应对手段可能包括更强力的降级、限流、熔断、重启、回滚、重建等，甚至涉及硬件设备的替换和容灾切换。

在处理故障时，应遵循以下原则：首先，保持冷静，不慌乱。其次，迅速判定故障影响范围，明确当前情况和可操作的预案，确定应对手段的优先级，识别核心业务和前后依赖关系。在处理大规模雪崩等复杂故障时，要控制恢复节奏，先确保后端服务就绪，再逐步恢复前端业务流量，并及时寻求外部资源支持。

血泪案例分享：吃瓜看戏

人为操作导致的大面积故障案例

故事发生在大约 4 年之前，当时我们在进行容器集群升级之后的旧节点批量退订操作。原计划是新建集群，将业务迁移到新集群后，释放老集群中的节点。为此，我们编写了脚本进行批量退订操作，但在节点筛选条件设置上出现失误，误将在线服务的多组负载均衡节点选入，并且操作也没有被当时的规则拦截到，最终导致服务大面积故障。在这个故障过程中，我们有一些值得吸取和分享的经验和教训。

首先，我们之前设计有逃生通道。我们的流量管控和容器调度平台的链路没有经过运行在其上的容器服务，而是有单独的通道，这个设计在关键时刻救了我们。此外，我们还预设了一些紧急场景和预案，比如临时紧急绕过内网认证（相关操作也均有严格审计），这让我们能够在认证系统失效时可以快速进入容器平台操作界面进行修复。

此外，在恢复过程中，我们要注意流量恢复的节奏，由于是负载均衡故障，流量无法正常进入系统，导致后端服务因缺少流量而缩容。恢复时，我们首先尝试一键锁定资源，但锁定时已经有很多资源缩容了。因此，在恢复之前，我们需要有节奏地逐步恢复业务，先做好预扩容及预热，再逐步放入流量。不能一开始就把全部流量接入，否则可能会因为某些服务没有预热或扩容到位，导致二次雪崩。

复盘改进：吃堑长智，举一反三

在复盘改进环节，我们需要进行详细分析，彻查故障根因。虽然在故障处理过程中可能没有时间追究根因，但事后必须解决。此外，还需进行常规的定性、定级、定责，以及优化改进和举一反三。通过案例研究和周期性回顾，总结经验教训并固化到流程或工具平台中，组织全员学习，确保经验教训被充分吸取。不仅要复盘内部故障，也要学习外部典型、知名案例。

故障复盘时，可以采用“黄金三问”：如何更快恢复业务？如何避免类似问题再次出现？有哪些经验可以总结并固化？同时，要跳出思维定式，避免陷入框架而错失更有价值的改进点。

故障定级需要有明确的规则和标准，提前约定并分为若干维度，不同维度有不同的权重和等级。公司有通用的定级标准，同时鼓励各业务方基于模板制定个性化定级模板，但最终需与建议模板对齐，避免不合理定级。经过评审后，组织内部会据此执行。

故障定性是对故障进行有效分类，如代码质量、测试质量、流程规范等。周期性回顾时，这些分类有助于分析哪种类型的故障是高频的，以及原因是什么，从而指导后续改进。

故障定责过程中，有几条原则：

1. 高压线原则：企业内部有红线，触发红线的故障要严厉定级。

2. 健壮性原则：故障可能涉及前后依赖，要自纠自查，确保功能模块健壮，与分段判定相关。默认所有依赖方都可能失效。

3. 第三方默认无责原则：复盘时不能将所有责任推给第三方厂商，要向内复盘，查找自身改进空间。但这不影响向第三方索赔。

公司会定期（如每年、每半年）为各业务部门（BU）设置故障预算。当故障发生并定责后，责任部门需抵扣相应分数，最终考核其目标达成情况。预算扣完后，各 BU 需有接口人参与组织，解决争端，达成共识。目标是通过这套机制提升稳定性。

周期回顾时，会基于线上实际数据进行分析。例如，下图的 2023 年的年度 OKR 复盘中，会看总分、达成情况、达成率高低等。比如，可以发现 CDN 厂商和云厂的故障预算大幅超标，下半年故障高发，与节假日多、流量大以及某些“黑天鹅”事件有关；在故障原因分类的统计中，产品质量是主要因素，不过，一个故障可能涉及多种原因和类型，需全面关联，以便后续分析改进。

补充总结 ＆ 未来展望

我们多年来在故障管理方面的经验提炼总结如下：首先，常规工作是一个大循环，包括故障的发生、处理、改进、稳定运行，再到周期性回顾，持续进行改进。此外，补充说明可用性体系，包括 SLI、SLO 和 SLA 等内容。

进一步扩展 PPTV（规划设计、技术流程、组织联动、目标对齐）的理念，适用于所有场景，确保工作不重不漏。PPTV 源于项目管理中的技术流程组织理念，强调目标对齐，以此展开各方面建设。内部采用 OKR 进行管理，技术方面可能涉及多个平台联动，组织方面则采用虚拟组织形式。

感悟与思考

丹尼尔·卡尼曼的《思考 快与慢》和《噪声》对我们故障管理工作有启发。卡尼曼将人类判断的错误分为偏差（Bias）和噪声（Noise）两大类。《思考 快与慢》让我们认识到由系统 1（快思考）主导的认知偏差，而在故障决策中，快思考能保证效率，但遇到超出既有设计模式的情况时，需要启动慢思考来规避偏差、深入分析，尤其是预案缺失时。 另一方面，《噪声》则揭示了判断的不稳定性问题。书中通过公式 “系统噪声² = 水平噪声² + 稳定的模式噪声² + 情境噪声²” 将噪声分为三种类型：水平噪声指人与人之间的差异，稳定的模式噪声指个人偏好差异，情境噪声指不同场合情况下判断的不同。在故障管理中，这些噪声会导致不同工程师对同一事件的处理出现巨大差异，噪声也会导致同一名工程师在不同情境下的处理也会有差异，破坏了稳定性。因此，我们需要建立明确的流程机制，最好将这些机制内置到系统中，以此作为’决策卫生’手段，系统性地排除噪声和偏差的干扰。

未来趋势

我们正身处一个技术浪潮汹涌澎湃的时代。云原生深化为基石，AI Agent 崭露头角，系统正朝着更智能、更自治的方向演进。

面对层出不穷的技术热点，我们该如何自处？答案或许就在这十二个字里：“看清本质，拥抱变化，顺势而为；做好定位，葆有价值，泰然自若。”

看清本质，意味着要始终以价值为导向。任何新技术的引入，都应回归到它是否能真正解决问题，提升效率、增强稳定、降低成本抑或加固安全。这是我们做出一切技术决策的锚点。

做好定位，则要求我们主动进化。与其焦虑是否会被取代，不如思考如何利用新工具放大自身价值。AI 的到来，恰恰是促使我们从具体的执行者，转变为驾驭工具、开发 AI Agent 的赋能者的契机。

归根结底，真正的定力，来源于我们为企业与社会创造的价值。只要我们能立足于此，便足以从容自信地驾驭技术浪潮，行稳致远、共创未来。

演讲嘉宾介绍

石鹏（东方德胜），从业十余年，一直从事运维相关的工作。 2016 年加入美图公司，现任美图 SRE 负责人，目前整体负责美图公司线上服务的稳定性保障工作。 曾多次参与或主导过美图公司多项基础设施、运维架构的调整和改造，在监控、灾备、故障管理、稳定性运营等方面有一定的经验积累和行业输出。 致力于推广 SRE、稳定性运营相关的理念及实践，编著有「SRE 系统建设指南」图谱，参与过业界多个 SRE、DevOps 相关案例集 / 期刊 / 标准 / 白皮书的编纂或供稿。 业界多个技术峰会的分享嘉宾、金牌讲师或出品人，SRE 精英联盟成员，中国信通院「稳定性保障实验室」认证专家、关键技术工作组 - 技术监督委员会委员兼应急工作组组长。