作者：许成铭（竞霄）
数字经济的明天，云计算俨然曾经作为基础设施融入到人们的日常生活中，稳定性作为云产品的根本要求，研发人员的技术底线，其不仅仅是文档里承诺的几个九的 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 平台。
Serverless 利用引擎 SAE 测评征集令
https://developer.aliyun.com/topic/sae2023