基于 Kubernetes 的 Serverless PaaS 稳定性建设万字总结

作者：许成铭（竞霄）

数字经济的今天，云计算俨然已经作为基础设施融入到人们的日常生活中，稳定性作为云产品的基本要求，研发人员的技术底线，其不仅仅是文档里承诺的几个九的 SLA 数字，更是与客户切身利益乃至身家性命息息相关，稳定性压倒一切。本文将侧重于实际落地而非方法论，阐述云产品 SAE 业务侧稳定性实际建设过程中的经验和思考。

SAE（Serverless 应用引擎）作为业界首款面向应用的 Serverless PaaS 平台，全托管免运维，实现了 Web 应用，微服务应用以及定时任务的 Serverless 化。其核心优势之一在于用户可以低心智负担，零改造成本的将其应用/任务直接部署至 SAE 中。用户只需聚焦于核心的业务逻辑开发，而应用生命周期管理，微服务管理，日志，监控等功能交由 SAE 完成，无论是代码包的发布，监控调用链的集成，还是分布式调度框架的迁移，都可以在无需改动任何业务逻辑和版本依赖的情况下使用。同时 SAE 正在建设基于流量网关托管的全新架构，借助自适应弹性，闲置计费等能力进一步为用户降低使用门槛和费用成本。

SAE 产品的设计理念是将简洁易用的使用体验和交互界面呈现给用户，将底层 Kubernetes 复杂度予以屏蔽，降低用户理解成本和使用门槛。因此产品内部逻辑对用户来说相对黑盒，用户并不感知底层 Infra，不感知组件的执行逻辑和交互流程，同时作为一款 PaaS 层产品，对开发运维人员而言是使用阿里云的统一入口，为统一简化使用体验，SAE 集成，对接，依赖了 10+ 其他的云产品或者服务，这些产品属性极大的考验了 SAE 的研发人员应该如何深入理解需求以便能够把最简单的产品体验呈现给用户，应该如何确保产品功能能够符合各层级用户的使用期望，应该如何打造用户应用长期稳定，安全，高性能低成本的云上环境。

稳定性建设思路

SAE 稳定性建设将会把整个故障处理流程划分为故障预防-故障发现-故障定位-故障恢复四个阶段，从平台视角来看，故障预防会聚焦于通过 region 化改造，UT，E2E 覆盖，故障演练等方式对 SAE 自身进行架构治理与升级，保证 SAE 后端服务的高可靠和高可用，同时也会针对 agent，镜像，IaaS 层依赖等相关产品进行依赖治理，收敛因关联上下游出问题所导致的连锁故障，故障发现主要依赖于诊断引擎以及运行时可用性探针来实现平台问题的第一时间感知，主动发现，并通过统一告警中心进行问题的及时触达。在问题定位的过程中会不断完善 SAE 运维平台建设，提升内部运维效率，完善根因定界能力，便于区分问题边界与原因，并要做好潜在风险的提前预案与新功能的 feature 开关，以便出现问题时能够快速止血，快速恢复。与此同时，将通过风险量化，容错设计，质量验证，可观测，事件中心，诊断等一系列产品化手段帮助用户闭环化解决自身问题，从而实现 Serverles 全链路的稳定。

稳定性建设体系

SAE 稳定性体系自底向上分为四个部分，分别为 UT/E2E，巡检，诊断引擎和可用性探针。首先通过提升代码 UT 覆盖度，扩充核心流程 E2E case 保证代码质量，保证程序执行逻辑的正确性，提前规避问题的产生。其次通过周期性巡检程序覆盖应用生命管理的核心流程，保证对外核心 OpenApi 的可用性和 SLA。通过建设 SAE 诊断引擎，以外部视角实时监听并消费各类数据源，经过模式诊断和根因定界流程产出事件告警，先于用户主动发现异常问题，同时建设 SAE 运行时可用性探针，在真实用户环境下对实例运行时进行无差别的检测，保证应用内部的运行环境符合期望，并且借助统一告警中心完成事件流转，实现问题高效触达，借助一站式运维平台白屏化运维操作，沉淀常用运维步骤，提升问题定位效率，从而全方位，多层次，立体化的覆盖各类异常问题，保障 SAE 应用的稳定性。

Infra 诊断引擎

SAE 底层为多租 Kubernetes，通过安全隔离机制将所有用户的应用部署在同一 Kubernetes 集群中，这么做便于集中管理，有利于提高整体集群水位，提升商业化溢价和资源超卖，但弊端也很明显，整个集群爆炸半径增加，集群的小范围异常或抖动都将可能会导致大面积用户应用的异常。与此同时产品功能在不断的演进与迭代，用户的应用实例规模在不断的扩张，这使得每一次底层变更和运维操作都需要慎之又慎，避免不兼容，非预期的异常行为产生。且 Kubernetes 自身组件众多，依赖众多，配置众多，组件间，服务间异步交互链路长，使得整体的复杂度进一步提高。面对如此复杂的分布式系统，如何及时感知，有效定位故障显得尤为重要。

SAE 通过结合实际业务场景以及对历史问题分析排查的领域经验制定了 Infra 主动发现诊断规则，并将其总结归纳，提炼出场景范式，转义为通用的诊断 DSL，并构建了基于 Kubernetes 资源状态变化的主动发现引擎。研发人员可以在运维平台白屏化配置诊断 DSL，引擎会监听 Kubernetes 各种资源的变更事件，并实时热加载 DSL 触发诊断流程。诊断过程会将对应的对象状态与诊断规则进行通用的模式匹配，并对资源，联级资源，结合时效性，频率等因素进行分析，校验其是否符合规则定义，然后在此基础上通过特征分析插件实现问题的根因定界，产出最终的诊断事件。通过这套机制可以支持 Infra 中任意资源的异常状态主动发现，且对于采用 Kubernetes 作为技术底座的场景均普遍适用。

状态监听

SAE 主动发现引擎将 Kubernetes 资源状态作为诊断的事件源，每次状态变化都会触发全流程的问题诊断，与此同时将会保留资源运行状态快照至 SLS 中持久化，以便于历史问题回溯与时间线追踪。状态监听的关键在于如何在满足实时性的条件下保证事件的不重不漏。

控制器模式作为 Kubernetes 的核心机制，借助控制循环保证了集群的当前状态无限趋近于期望的目标状态，其包括对当前状态的感知（infromer）和对状态的处理（controller）两部分。Infromer 作为控制器与 apiserver 交互的媒介，会监听 Kubernetes 资源状态变化并触发事件回调，在此过程中会将 list 到的资源对象缓存到本地 cache 中作为查询缓存，减少后续读操作对 apiserver 的压力。相比于周期性轮询等查询方式，infromer 机制构建的事件源可以高性能，实时，可靠的处理事件通知。

在 SAE 场景下如果直接使用原生 infromer 机制，由于集群中资源种类数量较多，并且会随着业务规模的增长而不断增长，将会占据大量的内存资源，存在较高的内存溢出风险。与此同时，当 SAE 主动发现引擎重启或者切主时会重新触发 list 流程，存量资源的大量事件会对引擎造成较大压力，并导致资源对象的重复诊断。且重启过程中若存在资源被删除，其 deleted 事件也无法在启动后再次获取，造成事件丢失。

针对上述痛点，SAE 主动发现引擎对原生 infromer 机制进行了诸多修改和增强：

• 压缩资源占用： 移除 cache 模块，触发事件回调时直接将对象临时存储于 workqueue 中，事件处理完毕后从队列中删除。同时在原生 workqueue 中，若 controller 处理消息失败会通过 backoff 机制重新将事件入队，这会导致队列中将存在同一资源对象的多个版本，由于 SAE 主动发现引擎只关注资源最新的状态，修改了 workqueue 逻辑，通过对比 resourceversion 只保留最新版本对象，进一步精简冗余对象。

• bookmark 机制： 引擎会从处理的对象和 watch 到的 bookmark 事件中获取最新的 resourceversion，当实例退出时会将其作为进度信息进行持久化存储，新实例启动后将会读取并在指定的 resourceversion 处执行 list 操作，保证了不会因为重启而消费冗余的 sync 事件。

• finalizer 动态管理： 通过对 pod，job 等资源对象添加 finalizer，只用当主动发现引擎处理完毕后才会移除该 finalizer，保证了高并发以及组件重启场景下的事件连续性。

该状态监听机制已经覆盖了 SAE 集群中 100% 的 Kubernetes 核心资源，未出现事件丢失，状态过时等问题，并基于此构建了 Kubernetes 资源视图，以应用维度展示其关联的 Kubernetes 资源对象在任意时间的状态变化。组件常态内存占用不到百 MB。

模式诊断

Kubernetes 资源对象众多，异常问题十分发散，如果人肉对每一种异常 case 都配置告警策略，既低效，又无法做到全面覆盖，通过对历史问题的总结归纳，SAE 抽象出以下场景范式：

• 资源 A 有无 x 字段

• 资源 A 处于 x 状态

• 资源 A 处于 x 状态并持续 s min

• 资源 A 有无 x 字段的同时有无 y 字段

• 资源 A 有无 x 字段的同时处于 y 状态

• 资源 A 有无 x 字段的同时处于 y 状态并持续 s min

• 资源 A 引用资源 B,但 B 不存在

• 资源 A 引用资源 B,A 处于 x 状态，但 B 处于 y 状态

• 资源 A 引用资源 B,A 处于 x 状态，但 B 处于 y 状态并持续 s min

将上述场景范式转义为通用 DSL，Sidecar Container 处于 Not Ready 状态 300s 可配置为（精简后）：

{  "PodSidecarNotReady": {    "duration": 300,    "resource": "Pod",    "filterField": [{      "field": ["status", "phase"],      "equalValue": ["Running"]    }, {      "field": ["metadata", "labels", "sae.component"],      "equalValue": ["app"]    }, {      "field": ["metadata", "deletionTimestamp"],      "nilValue": true    }],    "checkField": [{      "field": ["status", "containerStatuses"],      "equalValue": ["false"],      "subIdentifierName": "name",      "subIdentifierValue": ["sidecar"],      "subField": ["ready"]    }]
  }}

Service 处于 Deleting 状态 300s 可表示为（精简后）：

{  "ServiceDeleting": {    "duration": 300,    "resource": "Service",    "filterField": [{      "field": ["metadata", "labels", "sae-domain"],      "equalValue": ["sae-domain"]    }],    "checkField": [{      "field": ["metadata", "deletionTimestamp"],      "notEqualValue": [""]    }]  }}

诊断引擎将实时处理状态监听中获取到的 Kubernetes Unstructured 对象，匹配对应资源的 DSL 规则，借助语法树动态解析获取字段信息进行模式匹配，支持从 Unstructured 对象中获取任意字段，字段数组，字段数组中指定子字段进行精准匹配或模糊匹配。若经分析后命中诊断规则，则会放入 DelayQueue 中，根据所配置的持续时间进行延时告警，告警时会填充目标时刻的状态字段和 Warning 事件信息，补充诊断上下文。

与此同时若后续监听到该对象并发现其未命中诊断规则，则会从 DelayQueue 中删除，表明问题已经恢复，无需触发告警。除事件驱动模式外，对于某些需要周期性执行的诊断项，如验证 Service 对应 SLB 后端虚拟服务器组，监听是否存在，Ingress 对应 ALB 路由规则是否生效，顺序是否一致等，其本质是 Kubernetes 中 Service，Ingress 等对象资源所暴漏的状态信息过少，只有通过不断访问对应云产品，DB 等外部资源的方式才能进行判断，对于此类场景 DelayQueue 中会维持最新版本的资源对象，对象出队校验后将会重新入队，只有其被删除时才会从 DelayQueue 中删除，同时延时时间上加入随机偏移进行打散，避免同一时刻触发诊断造成访问限流。

SAE 主动发现引擎可对资源进行通用的处理逻辑，支持任意 CRD 的规则配置，实现了完备的资源/联级资源校验，资源缺失/泄露判断，时效性频率检查等功能，研发人员可以通过运维平台实时变更 DSL，生效诊断规则。

根因定界

对于资源对象中有直接状态或者对应 Kubernetes 事件中有明确原因的异常，模式匹配的方式已经具备较好的诊断效果，但对于存在依赖关系，多组件交互的复杂问题则存在较多的误报，需要研发人员根据问题的表象进一步分析，区分问题产生是由于用户错误操作还是平台内部故障所致，定位问题的根因。

借助 Infra 诊断引擎的根因定界能力，通过将专家经验沉淀为自动化诊断流，可有效减少告警误报的产生，收敛对用户侧异常的感知。根因定界能力的核心是对问题表象进行多维度的拆分和下钻并结合特征项进行结构化，自动化分析，找出问题的根本原因。以拉取镜像失败为例，其根因定界的问题分析树为（精简后）：

根因定界中的每一个节点都是针对某个具体诊断 case 的业务逻辑，具有频繁变更的属性，若都添加在主动发现引擎中会导致任何改动都需要走线上发布流程，开发运维成本高昂，同时也无法做到资源隔离和故障隔离，增加了整个引擎的复杂度和安全风险。因此在主动发现引擎设计中采用了微内核架构，保留组件核心逻辑，提取诊断项作为一个个轻量化的特征插件，通过适配器模式与主动发现引擎进行 RPC 通信，通过反射机制实现插件的动态路由与触发。引擎通过解析插件 DSL 生成有向无环图，编排整个调用流程，对目标诊断项进行根因定界。特征插件部署运行在阿里云函数计算中，触发毫秒级别冷启动延时，插件单独分配运行资源，且支持代码的实时修改与热更新。

采用插件化改造的方式实现根因定界具有以下价值：

• 敏捷开发：有利于关注点分离，工程解耦，将编码、调试和维护的过程简单化，提升了开发部署效率。

• 动态可扩展：通过修改声明式 DSL 即可实时对插件进行运行时动态插拔，灵活定制修改诊断流程。

• 故障隔离：减少爆炸半径，避免因单个插件异常导致整个主动发现引擎异常，使得影响面仅局限于插件本身。

• 组合和编排：借助原子化插件能力，通过统一的状态机执行机制，对插件的输入输出进行处理和流转，更易于实现更为复杂的诊断逻辑。

除图中镜像相关的特征插件外，还有监控飙高，发布单执行情况，应用实例异常分布，实例标准输出，运行环境快照等通用特征插件辅助问题的定位与排查。

运行时可用性探针

通过基于 Kubernetes 资源状态变化的主动发现已经可以覆盖绝大部分稳定性问题，但是其缺失内部视角，无法全面反映实例运行环境的健康情况，无法及时有效感知因用户启动时依赖以及运行时实例环境的差异所导致的异常问题，无法有效界定因应用程序自身运行异常所造成的运行时问题的边界归属。

通过建设 SAE 运行时可用性探针，在用户实例内部进行可用性指标的实时探测与汇报，从而语言应用无关的保证了在真实用户环境下的实例维度部署态和运行态的健康状态，并以此代表整个实例的真实运行情况，排除用户自身应用异常的影响，进而有效暴露疑难隐蔽问题，实现运行时可用性的根因界定，提升稳定性覆盖度。

从图中可以看到，SAE 运行时可用性探针作为 sidecar 运行在用户实例中，其架构分为以下几个部分：

• 配置中心：用于配置探针灰度版本及依赖检测项的是否生效，支持用户维度和应用维度。

• 守护进程：负责通用的进程管理功能：版本热更新，配置热加载，健康检查，命令通道，进程保活，信号透传，水位监控。

• 工作进程：承担计算任务，负责执行具体的依赖检测逻辑和并附加元数据上报心跳信息至持久化存储单元。

• 持久化存储单元：存储心跳信息，便于诊断引擎进一步消费处理，同时提供可视化大盘展示。

• 诊断引擎：消费持久化存储单元中的探针心跳数据，完善诊断根因定界能力，访问配置中心更新探针配置信息，并对探针行为进行管控与运维操作。

依赖检测

SAE 对应用部署态和运行态相关依赖项进行全面梳理，其中会严重影响应用实例运行的因素主要有以下几类：

心跳上报方式上，由于 SAE 采用单网卡模式，实例仅绑定用户 ENI 网卡，平台网络不具备访问远端用户实例的能力，无法采用 pull 模型获取心跳信息，反之通过 push 模型天然支持水平扩展，且不占用用户端口避免了潜在的端口冲突和数据泄露风险，所以探针选用 push 模型进行端侧主动上报。

对于每一个依赖项 SAE 运行时可用性探针都会执行周期性检测逻辑，生成结果状态码，经元数据填充和关联项压缩后上报心跳至持久化存储单元。SAE 主动发现引擎实时消费心跳数据，获取心跳状态码判定实例运行时情况，触发异常告警，同时心跳数据经过汇总可视化后可绘制实例的全生命周期轨迹，构建可用性 SLA 大盘供 SAE 内部进行参考。

运维管理

由于 SAE 运行时可用性探针运行在用户实例中,探针自身的健壮性显得尤为重要。为实现精细化版本控制和实时热更新，保障探针可以及时修复问题和持续迭代，SAE 探针采用了守护进程+工作进程的运行模式。守护进程负责配置的拉取，工作进程的保活与更新，信号量的捕获与透传等通用逻辑，确保工作进程可以正常退出与异常自动恢复，而工作进程则负责任务的调度，执行具体的依赖项校验逻辑和心跳生成与上报。SAE 主动发现引擎通过心跳中的版本号识别并控制灰度更新进度。通过双进程解耦，将易变的逻辑移至工作进程，分布式自更新的方式，相比采用单进程处理，每次依赖集中式触发 CloneSet 原地升级更新镜像的方式进行版本升级，保证了更新的实时性，且不经过 Kubernetes 链路，减少更新过程对集群访问的压力和对用户业务容器流量的影响。

SAE 实例中的 sidecar 容器和用户业务容器共享资源规格，防止探针资源消耗过多，与业务容器发生资源抢占影响其正常运行十分必要，通过对 SAE 运行时可用性探针的代码进行性能分析和优化，并将计算逻辑外推至 SAE 主动发现引擎进行处理，确保探针足够轻量，经上线后对比资源消耗，SAE 探针 cpu 几乎无占用，内存仅占数 MB。同时为避免极端情况下资源占用过多，SAE 探针也增加了组件自监控能力，定时采集当前进程的资源消耗，并与配置的预期目标阀值进行比较，若消耗过多则会触发熔断逻辑自动退出。

工具容器

由于 SAE 运行时可用性探针先于用户业务容器启动且常驻于所有用户实例中，可预先安装 ossutils，wget，iproute，procps，arthas 等常用工具，命令和脚本，并配置阿里云内网软件源，避免因用户容器不断崩溃或者采用 Alpine 等裁减镜像导致相关工具无法安装，命令无法正常执行，从而提升问题排查过程中的运维效率和运维体验。同时由于二者位于同一网络平面内，可将 SAE 探针作为跳板机对网络连通性，网络延时，资源是否存在等问题进行检测。倘若集中式的通过 exec 执行命令的方式进行批量运维，由于 exec 调用过程中需要经过 apiserver，对于多租集群需要合理评估访问并发与数据包大小，存在一定稳定性风险，而通过把探针作为命令通道，可以将 SAE 集群中管控流量与数据流量隔离，安全可靠的支持各类命令与脚本的执行上报。SAE 主动发现引擎中的诸多插件就是利用 SAE 运行时可用性探针作为命令通道实现的。

后续 SAE 也将探索将运行时可用性探针与 ebpf 技术相结合，提供对内核调用，网络数据包抓取，性能追踪等方面的更为深入的调试排查手段。

统一告警中心

SAE 的告警产生源十分分散，既有来自诊断引擎的诊断事件，又有来自可用性探针的心跳信息，同时还有 Kubernetes 事件，Runtime 组件日志，DB 数据，云监控，Prometheus 监控等等，且各个告警源的数据格式不一致，所在平台间告警能力存在差异，无法结合业务自身需求进行自定义配置。

为保证各类稳定性问题可以及时，有效触达到研发人员，SAE 内部构建了统一的告警中心，制定了统一的事件模型规范，通过集成并消费各类告警源，将异构数据转化为 SAE 事件进行统一处理，经过对事件进行黑白名单过滤，去重压缩，对元数据进行丰富，对上下文信息进行关联产出最终完整事件上报至 ARMS。借助 ARMS 的告警联系人管理，多渠道分发，动态排班等产品化能力实现了端到端的告警流程。并在此基础上完善告警分级机制和告警升级能力，用于及时有效处理紧急严重问题，提升告警处理效率，构建事件中心将内部事件对外透出供用户订阅，同时支持产出可视化大盘，核心指标和历史告警的审计明细，实现对告警的全流程一站式的管理。

告警分级

随着主动发现能力的提升，诊断覆盖面的增强，不同种类的告警呈发散事态糅杂在一起，研发人员如果仍采用一视同仁的方式进行告警核实和排查，经常会有告警处理不及时，告警 miss 的情况发生，导致明明诊断引擎已经将问题检测出来，但是由于内部告警处理不得当，导致仍有客诉产生。

有效处理告警既依赖告警本身的准确性，需要减少误报，漏报，收敛无效告警，同时又依赖对告警进行分流，将不同种类，不同影响的告警采取不同形式的处理方式，把有限的精力进行更为合理的分配，确保问题能够得到有效解决。

通过结合阿里云故障等级分层与 SAE 自身业务特点，SAE 内部将告警划分为四个等级:

SAE 以产品核心 SLA 和 SLO 指标作为牵引，对全部存量告警和新增告警进行梳理并配置默认告警等级，同时实现了告警升级机制，在发出告警时统一告警中心将会对在产生告警与解决告警两者间的时间窗口内的所有同类型告警所影响的应用数，用户数，告警同环比增量进行统计，并根据升级策略判断是否应该升级告警。升级策略如下：

SAE 统一告警中心借助 ARMS 告警大盘对业界标准的应急响应指标 MTTD，MTTA，MTTR 进行量化，衡量告警处理的质量。目前通过细粒度的告警分级制度与告警升级机制，告警问题得以高效分流，研发人员可以更加有的放矢的解决紧急问题，有效提升告警的触达率和处理效率。

事件中心

SAE 统一告警中心除了将主动发现的平台侧问题告警给内部研发人员外，还将以产品化事件中心的形式对事件进行统一管理、存储、分析和展示，将所诊断的用户侧问题和需要关注的通知透传给客户，便于客户及时响应故障，执行运维操作，避免问题进一步恶化。

当前 SAE 事件中心将事件划分为以下几类：

• 运行时事件，应用运行过程中所产生的事件，需用户主动订阅。

• 如健康检查失败，实例 OOM，弹性扩缩触发，任务执行情况，实例重启，java 程序死锁，流量不均，QPS/RT 突增，微服务优雅上下线等。

• 变更时事件，用户执行变更运维操作时所产生的事件，需用户主动订阅。

• 如应用各变更操作状态，批量启停状态，镜像拉取失败，交换机 ip 不足等

• 系统事件，SAE 系统内部定义事件，无需用户主动订阅，默认启用，事件发生时将通过云鸽通知给用户主账号。

• 如宿主机节点异常，实例内部迁移。

与此同时 SAE 作为应用托管类 PaaS 平台，集成了诸多阿里云云产品，提供了统一管理视图方便用户使用，但这种模式的弊端在于用户经常会反馈其他云产品的问题，SAE 也需鉴别和界定异常应该归属于哪一方云产品，同时也经常因为 SAE 这种弱托管模式导致用户操作和平台操作冲突，相互覆盖或者失效。

面对此类问题，事件中心除对自身平台事件加以透出外，也将对 SAE 关联云产品进行覆盖，以云产品事件的形式加以透出，具体将会分为以下四类问题：

• 指标异常（依赖云监控）：SLB 监听丢包，EIP 出入方向限速丢包，带宽打满等。

• 配额满（依赖配额中心）：SLB 保有实例数，保有监听数，后端挂载的服务器数，EIP 个数超限等。

• 配置冲突：SLB，ALB 产品间配置冲突，网关路由产品间配置冲突。

• 资源被删：NAS 文件系统，挂载源，挂载目录，OSS bucket，AK/SK，挂载目录，SLS project，logstore 等。

用户在控制台上可以按照应用，命名空间，地域维度选择需要订阅的事件项，并配置检测周期，触发阈值，联系人方式等通知策略，即可完成对自身关注问题的实时触达。

一键运维

当告警产生时，SAE 研发人员的一般处理步骤为：登录运维平台，找到告警对应的应用或实例，分析判断异常产生原因，执行对应的运维操作。整个问题处理流程前置操作步骤较多，导致问题解决效率下降，同时研发人员不可能无时无刻守在电脑旁，运维平台也没有专门对移动端进行适配，上下班途中或者周末如果身旁没有电脑，处理告警会十分不便。

参考 ChatOps 理念，在实时通信工具中基于对话驱动自动完成相应动作，SAE 通过自定义钉钉卡片样式，在展示告警内容的同时丰富诊断上下文，并将常用操作（删除实例，游离实例，重启应用，停止诊断，临时停止告警等）固定于卡片底部，便于研发人员随时随地，第一时间在手机钉钉上一键运维，提升整体运维效率和研发幸福感体验。

后续一键运维将会演进为自动化运维，在诸如资源长时间未清理，磁盘满，任务堆积，节点实例迁移等告警产生时执行确定性的运维操作，实现自动的故障隔离与故障自愈。

稳定性建设总结

稳定性建设没有银弹，是一场没有硝烟的持久战，也是一个必须长期投入且值得重点投入的方向。 我们应该推崇并成为晴天修屋顶的人，而非所谓的救火英雄，以更加系统化体系化的视角设计系统与架构，发现并解决那些隐蔽的 corner case 也是技术人的实力所在。SAE 将会持续优化，完善，深入建设稳定性的全流程，实现问题故障的提前预防，主动发现，精确定位与快速恢复。以用户价值为核心，紧贴用户诉求，持续为用户打造开源开放，极简体验，技术领先的 Serverless PaaS 平台。