作者：許成銘（競霄）
數字經濟的今天，雲端計算儼然已經作為基礎設施融入到人們的日常生活中，穩定性作為雲產品的基本要求，研發人員的技術底線，其不僅僅是文件裡承諾的幾個九的 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
