數字經濟的今天，雲計算儼然已經作爲基礎設施融入到人們的日常生活中，穩定性作爲雲產品的基本要求，研發人員的技術底線，其不僅僅是文檔裏承諾的幾個九的 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 平臺。
許成銘（競霄）
點擊立即免費試用雲產品 開啓雲上實踐之旅！
本文爲阿里雲原創內容，未經允許不得轉載。