SHARP：自愈、自适应与高韧性的后端基础设施平台

执行摘要

在分布式计算领域，基础设施可靠性的范式正从“静态冗余”根本性地转向“动态适应”。传统后端架构依赖被动式自动扩缩容与人工故障修复，面对当今互联网规模的高波动负载与复杂的服务间依赖关系，正越来越显得不足。基于启发式控制的固有延迟经常导致亚稳态失效（metastable failure）：系统被困在降级模式中，无法在无人介入的情况下恢复。本研究提案提出一条技术路线图，旨在构建 自愈、自适应与高韧性平台（Self-Healing, Adaptive, and Resilient Platform, SHARP） ——一种下一代后端基础设施，可自主预测需求、在细粒度上隔离故障，并执行复杂的修复工作流。

本提案综合前沿学术研究与 Netflix、Uber、Amazon Web Services (AWS) 等工业实践，主张三项关键技术的融合：用于缩小爆炸半径的 Cell-Based Architecture（基于单元的架构）、用于预测性资源编排的 深度强化学习（DRL）、以及用于零额外开销、内核级洞察的 eBPF 驱动可观测性。通过将可靠性逻辑与业务逻辑解耦，并嵌入智能控制平面，系统目标是把后端从被动资源池转变为具备稳态维持（homeostasis）能力的“类生物”主动实体。报告将提供全面文献综述、可行性评估、详细架构规格与可验证的实验框架，证明 SHARP 相较标准 Kubernetes 部署可将平均恢复时间（MTTR）降低约 60%，并将资源效率提升 30%。

1. 现代分布式系统对韧性的迫切需求

1.1 从可用性到反脆弱性

数十年来，后端基础设施的首要指标是“可用性（uptime）”——系统可访问时间的百分比。但随着系统从单体演进为复杂微服务，简单的“在线/离线”二元划分被模糊化。现代分布式系统常处于持续的部分失效状态：某个微服务影响 0.1% 请求可能“宕机”，但整体系统仍“在线”。在这种背景下，目标从最大化可用性转为最大化 韧性（resilience）——吸收冲击的能力——最终进一步走向 反脆弱性（antifragility）：系统在压力暴露中改进其响应机制。1

当代系统常由 Kubernetes 编排，其复杂性引入非线性失效模式。典型病理是“惊群（thundering herd）”：短暂服务降级引发请求堆积；服务恢复后，重试洪峰立刻再次压垮服务，形成稳定的失效循环，即亚稳态失效。3 静态阈值与人工 runbook 的速度无法截获这些循环。行业需要在机器速度下运行的基础设施，利用控制理论与预测式 AI 在级联前抑制振荡。

1.2 当前最佳实践的局限

当前行业标准高度依赖事后反应机制。服务网格（如 Istio）的熔断器可切断通往故障节点的流量，但熔断器是“滞后指标”：只有在用户已遇到错误后才动作。同样，Kubernetes 的 HPA 基于 CPU/内存阈值扩缩容；因为必须等待指标越过阈值，它不可避免地存在延迟（常以分钟计），在突发流量下导致性能下降。4

学术界长期提出“自愈”系统，但早期实现多为脆弱的基于规则专家系统。6 2024-2025 年生成式 AI 与强化学习（RL）的兴起提供新机会：用概率模型替代静态规则，让系统能推理系统状态并采取主动、上下文感知的行动。7

2. 文献综述与业界实践现状

追求稳健基础设施的路径目前呈现两极：一端是超大规模云厂商务实的架构方法（隔离、削峰/降载），另一端是学术界的算法化、AI 驱动方法（预测性扩缩容、自动根因分析）。

2.1 单元隔离范式（爆炸半径收敛）

超大规模厂商如 AWS、Slack 部署的最有效稳健策略之一是 Cell-Based Architecture（基于单元的架构）（也称舱壁模式 bulkhead）。

2.1.1 行业采用与架构

不同于所有用户共享全局资源池的传统微服务架构，单元架构将整个应用栈（入口、计算与存储）切分为称为 “cells” 的独立单元。每个 cell 是系统的自包含副本，可服务一部分客户。9

• AWS 实现： AWS 将服务组织为 cells，确保推送到某个 cell 的软件 bug 或配置错误只影响映射到该 cell 的客户。若某 cell 失败，其爆炸半径限制为 (figure omitted) 的总用户，其中 (figure omitted) 是 cell 数量。10
• 路由逻辑： 流量通过轻量“分区层”分配。Route53 或专用代理将客户 ID（或分区键）映射到特定 cell 端点。该路由层必须极度简单、避免复杂业务逻辑，以保持其可靠性。11

2.1.2 Shuffle Sharding 与数学韧性

更高级的实现使用 Shuffle Sharding。客户不再映射到单一 cell（避免单点故障），而是映射到由多个 cell 组合形成的虚拟分片（例如 100 个 cell 中选 2 个）。

• 容错： 若其中一个 cell 失效，客户仍可由其分片内的冗余 cell 提供服务。两个特定 cell 同时失效的概率远低于全局集群失效。
• 隔离： 该技术几乎消除“吵闹邻居（noisy neighbor）”问题。若恶意客户攻击其分配的 cells，仅会影响恰好共享那一组合的其他客户——统计上极小的群体。3

2.2 自适应并发控制（负载削减）

若单元架构限制失效的范围，则 **自适应并发控制（Adaptive Concurrency Control）*限制失效的深度*。

2.2.1 静态限流的失败

传统限流设置固定每秒请求数（RPS）。但“服务容量”并非静态：它会随网络延迟、数据库争用与 GC 周期变化。9:00 AM 安全的上限，可能在 9:05 AM 因下游变慢而过载。12

2.2.2 梯度控制算法

Netflix 与 Uber 将 TCP 拥塞控制（如 TCP Vegas）思想应用到应用层（Layer 7）请求上。

• 机制： 监控请求往返时间（RTT）。随着并发（in-flight 请求数）增加，RTT 在饱和前保持稳定，超过饱和点后 RTT 急剧上升。
• 算法： 基于 RTT 梯度动态调整并发上限：
  (figure omitted)
  更复杂版本采用加性增/乘性减（AIMD）反馈回路：若观测 RTT 超过最小 RTT（minRTT）的移动平均，则立即降低并发上限，快速丢弃过量流量。这可在接受请求上维持延迟 SLA，避免队列堆积导致超时与级联故障。13
• 实现： 业界前沿是在 sidecar 代理（如 Envoy）中实现该逻辑，与应用代码解耦。Envoy 的 adaptive_concurrency 过滤器持续采样延迟并调整允许请求窗口。15

2.3 自主资源管理（预测性自动扩缩容）

让基础设施与需求匹配，是云效率的核心挑战。

2.3.1 被动陷阱

Kubernetes HPA/VPA 等工具是被动的：在控制循环（通常 15-30 秒）中检查指标（如 CPU）是否超过阈值。这引入两个失效模式：

1. 滞后： 扩缩容响应到来时系统可能已过载。
2. 抖动（振荡）： 负载在阈值附近波动时，扩缩容会频繁增删 pod，造成不稳定与算力浪费。17

2.3.2 系统控制中的强化学习（RL）

为解决这一问题，研究者应用 深度强化学习（DRL）：让 RL 智能体与 Kubernetes 集群交互，将“资源分配”视为一个博弈，其奖励函数由低延迟与高利用率共同定义。

• 方法：
  • Q-Learning 与 DQN： 早期使用离散动作空间（扩容/缩容），但难以处理云负载的连续性。19
  • Actor-Critic（PPO/A3C）： 近期研究更偏好 Proximal Policy Optimization (PPO) 等更稳定算法。“Actor” 提议扩缩容动作，“Critic” 评估其价值，从而学习更平滑的策略。20
• 预测能力： 与 PID 控制器不同，使用 LSTM 或 Transformer 的 RL 智能体可学习时间模式（如“每天 9 点流量必增”），从而实现预扩容。21
• 元学习： 主要难题是“冷启动”：训练 RL 智能体需要时间。Meta-Reinforcement Learning（如 AWARE 框架）使智能体能离线学习通用策略，并用少量样本快速适配某个微服务。22

2.4 深度可观测性与 eBPF 革命

无法观测就无法控制。eBPF（Extended Berkeley Packet Filter） 的出现重塑了可观测性。

2.4.1 内核级洞察

eBPF 允许在不修改内核源码、不加载内核模块的情况下，在 Linux 内核中运行沙箱化程序。

• 相对 Agent 的优势： 传统 APM agent（如 Java agent）引入开销且需要改代码；eBPF 探针挂载到 syscall/tracepoint，可透明采集数据。
• 能力： Pixie、Cilium 等工具使用 eBPF 直接从内核网络包解析 HTTP、gRPC、SQL 协议，以零埋点开销提供“黄金信号”（延迟、错误率、吞吐量）。24
• 能耗监控： Kepler 项目使用 eBPF 将内核 CPU 指令与硬件功耗模型（RAPL）关联，可按 pod 报告能耗，支持碳感知扩缩容决策——“绿色计算”需求正在上升。27

2.5 AI 驱动根因分析（AIOps）

最后一根支柱是故障诊断。

2.5.1 运维中的 LLM 与 RAG

2024-2025 年，LLM 在 IT 运维中的应用从聊天界面走向集成工作流。

• 挑战： 直接把日志喂给 LLM 容易产生幻觉：模型可能编造错误码或误解时间戳。
• 检索增强生成（RAG）： 前沿做法是 Graph-Augmented RAG。如 SynergyRCA 这类工具构建系统拓扑知识图（A 调用 B）。当告警触发时，系统检索相关日志与指标、映射到图结构，并把结构化上下文提供给 LLM，从而显著提升根因定位准确性。8
• 自动化调查： 新兴框架设想“虚拟 SRE”：自治智能体不仅能诊断，还能查询系统（如运行 kubectl describe pod）收集更多证据后再提出修复建议。30

---

3. 可行性评估

将这些先进技术整合为统一平台挑战巨大，但潜力同样具有变革性。

3.1 技术成熟度评估（TRL）

各组件可行性不一。我们按技术成熟度等级（TRL）评估如下：

3.2 实施风险与缓解

1. RL 的“黑箱”问题：
   • 风险： RL 智能体可能以危险方式最大化奖励（例如为省成本把副本缩到 0）。
   • 缓解： 实现 Guardian Module（守护模块）：确定性的规则层对 AI 决策做合理性检查。若 AI 请求 0 副本，Guardian 将其覆盖为配置的最小值（如 2）。
2. 单元内数据碎片化：
   • 风险： 单元架构使数据分散，难以训练全局 RL 模型。
   • 缓解： 使用 联邦学习（Federated Learning）：在每个 cell 内训练本地模型，周期性聚合权重为全局模型，在保持隔离的同时利用全体经验。31
3. AI 计算成本：
   • 风险： RL 与 LLM 推理消耗大量 GPU/CPU，可能抵消效率收益。
   • 缓解： 使用轻量模型（如量化 Llama-3-8B），并仅在触发事件（告警）时推理，而非持续运行。

3.3 成本收益建模

• 基础设施成本： 研究显示预测性扩缩容可通过消除被动扩缩容所需的“安全缓冲”将云资源消耗降低 20-30%。32
• 宕机成本： 企业系统平均宕机成本超过每分钟 9,000 美元。若 SHARP 每年仅避免一次重大事故（例如将级联故障限制在单一 cell），ROI 立刻成立。
• 运维成本： 降低 SRE 的认知负担（toil）可让工程团队专注功能开发而非救火。

---

4. 拟议架构：SHARP（自愈、自适应与高韧性平台）

我们将 SHARP 定义为一套统一数据平面（流量处理）与控制平面（可靠性逻辑）的综合架构标准。

4.1 架构概览

SHARP 由四层组成：

1. Cellular Data Plane（单元数据平面）： 通过物理隔离控制故障范围。
2. Semantic Observability Layer（语义可观测层）： 以 eBPF 提供高保真信号。
3. Intelligent Control Plane（智能控制平面）： 决策大脑（RL 智能体与自适应逻辑）。
4. Immune System（免疫系统）： 持续验证机制（混沌工程）。

4.2 单元数据平面

SHARP 的基础是严格隔离。

• Cell 定义： 一个 “Cell” 是包含完整应用栈独立副本的 Kubernetes Namespace 或 Cluster，包括 Ingress Controller、完整微服务调用图与本地缓存（Redis）。
• 数据分片： 每个 cell 与数据库的专用分区（或 cell 本地副本）通信，保证 Cell A 的锁争用不会影响 Cell B。
• 路由与 Shuffle Sharding：
  • 外部路由器（AWS Route53 或全球 NGINX 层）处理流量入口。
  • Shuffle Sharding 逻辑： 为每位客户分配由两个 cell ID 组成的“票据”（如 Cell 4 与 Cell 9）。
  • 流量在两者之间负载均衡；若 Cell 4 失败，流量完全切到 Cell 9。
  • 数学保证： 100 个 cell 且每个客户分配 2 个 cell，则有 (figure omitted) 种组合；攻击者若攻击其分片，仅影响共享该 cell 对的用户——总用户中极小的一部分。3

4.3 智能控制平面（RL 智能体）

SHARP 用强化学习扩缩容替代 HPA 的静态配置，通过自定义 Kubernetes Operator 管理扩缩容。

• RL 智能体设计：
  • 算法： Proximal Policy Optimization (PPO)，因其样本效率与避免剧烈策略更新的稳定性。
  • 观测空间（输入）： 向量 (figure omitted)，包含：
    • CPU/内存利用率（Metrics Server）。
    • 请求速率（RPS）与错误率（Envoy/Prometheus）。
    • p99 延迟（Pixie）。
    • 时间特征（时段/星期，用周期编码）。
    • 队列深度（lag）。
  • 动作空间（输出）： 离散动作 (figure omitted)，表示增减副本数。
  • 奖励函数： 多目标奖励：
    (figure omitted)
    • 第一项奖励满足 SLA。
    • 第二项惩罚资源成本。
    • 第三项惩罚不必要的扩缩容抖动以保证稳定。34
• 安全约束： 输出 (figure omitted) 经过 “Safety Filter”，强制最小/最大副本数与最大扩缩容速率（如“1 分钟内不得翻倍”）。33

4.4 语义可观测层（eBPF + LLM）

SHARP 采用“零埋点”哲学。

• Pixie： 以 DaemonSet 部署，使用 eBPF 追踪所有 HTTP/gRPC 流量。
  • 收益： 对失败事务捕获请求体内容，帮助 LLM RCA 智能体理解失败原因（例如触发崩溃的特定 JSON 字段）。26
• Kepler： 每个节点运行 Kepler，导出能耗 Prometheus 指标。
  • 绿色扩缩容： 在 RL 奖励函数中加入能耗惩罚，让系统倾向于在能效更优硬件或更低电网碳强度时扩容。28
• LLM-RCA 智能体： 将本地 LLM（如通过 vLLM 提供的 Llama-3-8B）集成到告警流水线。
  • 流程： Alert Fired (figure omitted) Retrieve Topology (Graph) (figure omitted) Retrieve Logs/Traces (Loki/Pixie) (figure omitted) Vectorize & Search (figure omitted) LLM Prompt (figure omitted) Root Cause Hypothesis.
  • 该智能体作为 SRE 的“副驾驶”，在每个 PagerDuty 告警中附上摘要诊断。8

4.5 免疫系统（持续混沌）

为防止系统“漂移”至失效，SHARP 主动注入故障。

• Chaos Mesh： 使用 Chaos Mesh 编排实验。
• 持续背景辐射： 在生产环境（特别是 canary cell）运行低强度背景混沌：
  • 随机杀 pod（验证重启逻辑）。
  • 注入 20ms 延迟（验证自适应并发触发）。
  • 丢弃 1% 包（验证重试逻辑）。
• 这确保防御机制持续演练、不至于“萎缩”。38

---

5. 实施策略与实验设计

为严格验证 SHARP，我们将与标准行业基线进行对比研究。

5.1 实验框架

• 测试床： us-east-1 三个可用区（AZ）的 Kubernetes (EKS) 集群。
• 应用： Google Microservices Demo (Online Boutique)，修改以引入人工资源泄露与延迟瓶颈。
• 压测： Locust 分布式负载测试，模拟用户行为。

5.2 指标与 KPI

从四个维度评估：

5.3 负载模拟与混沌场景

实验包含三类场景，分别压测不同子系统：

场景 A：“闪电人潮（Flash Crowd）”（扩缩容测试）

• 刺激： 60 秒内从 1,000 RPS 增至 10,000 RPS（模拟营销活动）。
• 基线行为： HPA 等待 CPU > 70%，约 2 分钟后扩容；滞后期用户看到 503 错误。
• SHARP 行为： RL 智能体检测请求数变化率（一阶导），在 CPU 饱和前积极扩容。Envoy 自适应并发立即拒绝超额请求以保护数据库，使已接受请求的 p99 延迟保持稳定。

场景 B：“灰色失效（Grey Failure）”（可观测性测试）

• 刺激： Chaos Mesh 在 CheckoutService 与 PaymentService 的链路注入 5% 丢包。
• 基线行为： 重试风暴冲击网络；指标只显示“超时”而无明确原因，SRE 需数小时排查。
• SHARP 行为： Pixie 的 eBPF 探针检测 TCP 重传；LLM-RCA 将“高重传”与 PaymentService 关联，并在告警中建议“网络质量问题”。

场景 C：“级联失效（Cascading Failure）”（单元测试）

• 刺激： 一个“毒丸（poison pill）”请求导致 RecommendationService 崩溃并在重启时占满内存。
• 基线行为： 崩溃循环；等待 Recommendations 的其他服务耗尽线程池，整个集群无响应。
• SHARP 行为： 故障被限制在 Cell 1。路由器检测到 Cell 1 健康检查失败后，将流量切到用户的备用 cell（Cell 2）。仅约 2%（映射到 Cell 1）的用户短暂出错后完成切换，98% 用户不受影响。

---

6. 项目时间线与路线图

SHARP 实施预计 12 个月，分四阶段：

阶段 1：基础（第 1-3 个月）

• 目标： 建立单元控制平面与可观测基线。
• 任务：
  • 设计 cell 分区策略与 Route53/Envoy 路由层。
  • 部署启用 eBPF 支持的 EKS。
  • 安装 Pixie 与 Kepler，开始采集黄金信号与能耗数据用于训练集。
  • 在 staging 实现基础 Chaos Mesh 流水线。

阶段 2：智能（第 4-7 个月）

• 目标： 开发并训练 AI 组件。
• 任务：
  • 开发 RL Autoscaler（PPO），用阶段 1 数据离线训练（Sim-to-Real 迁移）。
  • 实现并调参 Envoy Adaptive Concurrency 过滤器。
  • 用开源模型（如 Llama-3）与图数据库（Neo4j）原型化 LLM-RCA。

阶段 3：可靠性与集成（第 8-10 个月）

• 目标： 集成子系统并用混沌验证。
• 任务：
  • RL Autoscaler 以 “Shadow Mode” 部署（只记录动作不执行）验证安全性。
  • 执行“Game Days”（A/B/C 场景）。
  • 基于结果改进奖励函数（如提高延迟违约惩罚）。

阶段 4：生产发布（第 11-12 个月）

• 目标： 渐进式迁移至 SHARP。
• 任务：
  • 金丝雀发布： 在单个 cell（内部流量）部署。
  • 评估： 与基线集群对比 KPI。
  • 全面发布： 在所有 cells 启用 SHARP。
  • 交付： 完成文档与 SRE 培训，指导 AI 控制平面运维。

---

7. 预期结果与战略影响

成功交付 SHARP 将推动从“管理服务器”到“管理目标”的转变。

1. 运维不朽性： 通过 Shuffle Sharding 与单元架构在数学上隔离故障，系统可免疫于整体崩溃。预计可为全球用户实现 99.999% 可用性，因为单点失效无法跨 cell 传播。
2. 自主经济性： RL 扩缩容将成本与峰值容量解耦。通过实时资源匹配与 Kepler 能耗指标，组织不仅可将云支出降低约 30%，还可将技术运营与 **可持续（ESG）**目标对齐。
3. “虚拟 SRE”革命： 将 LLM 融入调试回路可民主化系统知识。初级工程师在 RCA 智能体指导下即可处理复杂事故，减少知识孤岛与 on-call 压力/倦怠。
4. 面向未来： SHARP 为 Level 5 Autonomy 奠基。随着 AI 智能体成熟，控制平面可升级以处理更复杂任务（如自动回滚代码或优化数据库 schema），而无需重构底层平台。

该提案不仅是技术升级，更是对长期敏捷与韧性的战略投资。通过用单元隔离的严谨对抗现代系统复杂性，并以 AI 的智能加以调度，我们可以构建不仅能在故障中存活、而且能在故障中持续进化的基础设施。

References

1. State of the Art in Parallel and Distributed Systems: Emerging Trends and Challenges, accessed January 25, 2026, https://www.mdpi.com/2079-9292/14/4/677
2. State of the Art in Parallel and Distributed Systems: Emerging Trends and Challenges, accessed January 25, 2026, https://www.preprints.org/manuscript/202412.1361
3. Reliability, constant work, and a good cup of coffee - AWS, accessed January 25, 2026, https://aws.amazon.com/builders-library/reliability-and-constant-work/
4. AI Powered Kubernetes Autoscaler. Efficient resource management is… | by Shivangx | Medium, accessed January 25, 2026, https://medium.com/@shivangx27/ai-powered-kubernetes-autoscaler-1590a5207b4e
5. Kubernetes Autoscaling Showdown: HPA vs. VPA vs. Karpenter vs. KEDA - DEV Community, accessed January 25, 2026, https://dev.to/mechcloud_academy/kubernetes-autoscaling-showdown-hpa-vs-vpa-vs-karpenter-vs-keda-9b1
6. [2403.00455] A Survey on Self-healing Software System - arXiv, accessed January 25, 2026, https://arxiv.org/abs/2403.00455
7. Self-Healing in Knowledge-Driven Autonomous Networks: Context, Challenges, and Future Directions - IEEE Xplore, accessed January 25, 2026, https://ieeexplore.ieee.org/iel8/65/7593428/10562327.pdf
8. Simplifying Root Cause Analysis in Kubernetes with StateGraph and LLM - arXiv, accessed January 25, 2026, https://arxiv.org/html/2506.02490v1
9. Cell-Based Architecture on AWS - Rackspace Technology, accessed January 25, 2026, https://www.rackspace.com/blog/cell-based-architecture-aws
10. Guidance for Cell-Based Architecture on AWS, accessed January 25, 2026, https://aws.amazon.com/solutions/guidance/cell-based-architecture-on-aws/
11. Implementing a cell-based architecture - AWS Documentation, accessed January 25, 2026, https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/implementing-a-cell-based-architecture.html
12. Adaptive Concurrency Control for Mixed Analytical Workloads - USENIX, accessed January 25, 2026, https://www.usenix.org/sites/default/files/conference/protected-files/sre23amer_slides_kleiman.pdf
13. Performance Under Load. Adaptive Concurrency Limits @ Netflix, accessed January 25, 2026, https://netflixtechblog.medium.com/performance-under-load-3e6fa9a60581
14. Cinnamon Auto-Tuner: Adaptive Concurrency in the Wild | Uber Blog, accessed January 25, 2026, https://www.uber.com/blog/cinnamon-auto-tuner-adaptive-concurrency-in-the-wild/
15. Adaptive Concurrency — envoy 1.38.0-dev-b9521c documentation, accessed January 25, 2026, https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/adaptive_concurrency_filter
16. Brief Analysis of Envoy Adaptive-Concurrency Filter - Alibaba Cloud Community, accessed January 25, 2026, https://www.alibabacloud.com/blog/brief-analysis-of-envoy-adaptive-concurrency-filter_600658
17. Autoscaling cloud resources with real-time metrics, accessed January 25, 2026, https://journalwjarr.com/sites/default/files/fulltext_pdf/WJARR-2025-1660.pdf
18. Archetype-Aware Predictive Autoscaling with Uncertainty Quantification for Serverless Workloads on Kubernetes - arXiv, accessed January 25, 2026, https://arxiv.org/html/2507.05653v1
19. Reinforcement Learning Based Serverless Container Autoscaler, accessed January 25, 2026, https://math.mit.edu/research/highschool/primes/materials/2023/Ning-Lazarev-Gohil.pdf
20. Intelligent autoscaling in Kubernetes: the impact of container performance indicators in model-free DRL methods - kth .diva, accessed January 25, 2026, https://kth.diva-portal.org/smash/get/diva2:1845017/FULLTEXT01.pdf
21. Proactive Auto-Scaling for Service Function Chains in Cloud Computing Based on Deep Learning - IEEE Xplore, accessed January 25, 2026, https://ieeexplore.ieee.org/iel7/6287639/10380310/10464297.pdf
22. MSARS: A Meta-Learning and Reinforcement Learning Framework for SLO Resource Allocation and Adaptive Scaling for Microservices - arXiv, accessed January 25, 2026, https://arxiv.org/html/2409.14953v1
23. AWARE: Automate Workload Autoscaling with Reinforcement Learning in Production Cloud Systems | USENIX, accessed January 25, 2026, https://www.usenix.org/system/files/atc23-qiu-haoran.pdf
24. Exploring eBPF and and its uses in Observability | Learn - Tracetest, accessed January 25, 2026, https://tracetest.io/learn/exploring-ebpf-and-and-its-uses-in-observability
25. EBPF Real-Time Monitoring Systems Creation - Meegle, accessed January 25, 2026, https://www.meegle.com/en_us/topics/ebpf/ebpf-real-time-monitoring-systems-creation
26. About Pixie | How Pixie uses eBPF, accessed January 25, 2026, https://docs.px.dev/about-pixie/pixie-ebpf/
27. How the Kepler project is working to advance environmentally-conscious efforts - Red Hat, accessed January 25, 2026, https://www.redhat.com/en/blog/how-kepler-project-working-advance-environmentally-conscious-efforts
28. Kepler Tutorial: Monitoring Kubernetes Energy with eBPF | Cloudatler, accessed January 25, 2026, https://cloudatler.com/blog/kepler-tutorial-monitoring-kubernetes-energy-with-ebpf
29. OpenRCA: Can Large Language Models Locate the Root Cause of Software Failures? | OpenReview, accessed January 25, 2026, https://openreview.net/forum?id=M4qNIzQYpd
30. We Tried Using LLMs for Root Cause Analysis. It Flopped — Until This. | by Gupta Anshul, accessed January 25, 2026, https://medium.com/@gupta.anshul87/we-tried-using-llms-for-root-cause-analysis-it-flopped-until-this-a2dc4c5a32dc
31. FedMon: Federated eBPF Monitoring for Distributed Anomaly Detection in Multi-Cluster Cloud Environments - arXiv, accessed January 25, 2026, https://arxiv.org/html/2510.10126v1
32. [2412.02610] AI-Driven Resource Allocation Framework for Microservices in Hybrid Cloud Platforms - arXiv, accessed January 25, 2026, https://arxiv.org/abs/2412.02610
33. An SLO Driven and Cost-Aware Autoscaling Framework for Kubernetes - arXiv, accessed January 25, 2026, https://arxiv.org/html/2512.23415v1
34. Reinforcement Learning-Based Autoscaling for Cost and Performance Optimization in Kubernetes Clusters | springerprofessional.de, accessed January 25, 2026, https://www.springerprofessional.de/en/reinforcement-learning-based-autoscaling-for-cost-and-performanc/51704622
35. gym-hpa: Efficient Auto-Scaling via Reinforcement Learning for Complex Microservice-based Applications in Kubernetes - Biblio, accessed January 25, 2026, https://backoffice.biblio.ugent.be/download/01H0J37FFRP38GXQPE89DZHMVH/01H0J3A4KV2N2CWWJKZKBF7T48
36. Debugging Kubernetes in Real-Time: Why DevOps Teams Are Turning to Pixie - Medium, accessed January 25, 2026, https://medium.com/@StackGpu/debugging-kubernetes-in-real-time-why-devops-teams-are-turning-to-pixie-6250f07f6d4a
37. Kepler, accessed January 25, 2026, https://sustainable-computing.io/
38. Simulate Network Faults - Chaos Mesh, accessed January 25, 2026, https://chaos-mesh.org/docs/simulate-network-chaos-on-kubernetes/
39. Chaos Mesh - Your Chaos Engineering Solution for System Resiliency on Kubernetes, accessed January 25, 2026, https://chaos-mesh.org/blog/chaos_mesh_your_chaos_engineering_solution/