Paper deep dive
E2E-REME: Towards End-to-End Microservices Auto-Remediation via Experience-Simulation Reinforcement Fine-Tuning
Lingzhe Zhang, Yunpeng Zhai, Tong Jia, Minghua He, Chiming Duan, Zhaoyang Liu, Bolin Ding, Ying Li
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 95%
Last extracted: 4/14/2026, 2:30:33 AM
Summary
The paper introduces E2E-REME, an end-to-end auto-remediation model for microservices that uses experience-simulation reinforcement fine-tuning. It also presents MicroRemed, a benchmark for evaluating LLM-based remediation by automating failure injection, playbook generation, and verification.
Entities (5)
Relation Signals (3)
E2E-REME → addresses → E2E-MR
confidence 95% · To address the challenges of E2E-MR, we propose E2E-REME, an end-to-end auto-remediation model for microservices.
MicroRemed → evaluates → E2E-REME
confidence 95% · We evaluate E2E-REME using MicroRemed, integrated with two widely adopted microservice systems.
ThinkRemed → ispartof → E2E-REME
confidence 95% · E2E-REME operates within a lightweight multi-agent workflow, ThinkRemed.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Contemporary microservice systems continue to grow in scale and complexity, leading to increasingly frequent and costly failures. While recent LLM-based auto-remediation approaches have emerged, they primarily translate textual instructions into executable Ansible playbooks and rely on expert-crafted prompts, lacking runtime knowledge guidance and depending on large-scale general-purpose LLMs, which limits their accuracy and efficiency. We introduce \textit{End-to-End Microservice Remediation} (E2E-MR), a new task that requires directly generating executable playbooks from diagnosis reports to autonomously restore faulty systems. To enable rigorous evaluation, we build \textit{MicroRemed}, a benchmark that automates microservice deployment, failure injection, playbook execution, and post-repair verification. We further propose \textit{E2E-REME}, an end-to-end auto-remediation model trained via experience-simulation reinforcement fine-tuning. Experiments on public and industrial microservice platforms, compared with nine representative LLMs, show that E2E-REME achieves superior accuracy and efficiency.
Tags
Links
- Source: https://arxiv.org/abs/2604.11094v1
- Canonical: https://arxiv.org/abs/2604.11094v1
Trouble viewing inline? Open PDF directly →
Full Text
72,450 characters extracted from source content.
Expand or collapse full text
E2E-REME: Towards End-to-End Microservices Auto-Remediation via Experience-Simulation Reinforcement Fine-Tuning Lingzhe Zhang † Peking University; Key Laboratory of Data Intelligence and Security Beijing, China zhang.lingzhe@stu.pku.edu.cn Yunpeng Zhai † Alibaba Group China zhaiyunpeng.zyp@alibaba-inc.com Tong Jia ∗ Peking University; Key Laboratory of Data Space Technology and System Beijing, China jia.tong@pku.edu.cn Minghua He Peking University; Key Laboratory of Data Intelligence and Security Beijing, China hemh2120@stu.pku.edu.cn Chiming Duan Peking University; Key Laboratory of Data Intelligence and Security Beijing, China duanchiming@stu.pku.edu.cn Zhaoyang Liu Alibaba Group China jingmu.lzy@alibaba-inc.com Bolin Ding Alibaba Group China bolin.ding@alibaba-inc.com Ying Li ∗ Peking University; Key Laboratory of Data Intelligence and Security Beijing, China li.ying@pku.edu.cn Abstract Contemporary microservice systems continue to grow in scale and complexity, leading to increasingly frequent and costly fail- ures. While recent LLM-based auto-remediation approaches have emerged, they primarily translate textual instructions into exe- cutable Ansible playbooks and rely on expert-crafted prompts, lack- ing runtime knowledge guidance and depending on large-scale general-purpose LLMs, which limits their accuracy and efficiency. We introduce End-to-End Microservice Remediation (E2E-MR), a new task that requires directly generating executable playbooks from diagnosis reports to autonomously restore faulty systems. To enable rigorous evaluation, we build MicroRemed, a bench- mark that automates microservice deployment, failure injection, playbook execution, and post-repair verification. We further pro- pose E2E-REME, an end-to-end auto-remediation model trained via experience-simulation reinforcement fine-tuning. Experiments on public and industrial microservice platforms, compared with nine representative LLMs, show that E2E-REME achieves superior accuracy and efficiency. CCS Concepts • Software and its engineering→ Maintaining software. † Equal contribution. ∗ Corresponding author. This work is licensed under a Creative Commons Attribution 4.0 International License. FSE Companion ’26, Montreal, QC, Canada © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2636-1/26/07 https://doi.org/10.1145/3803437.3805206 Keywords Auto-Remediation, Reinforcement Fine-Tuning, Microservices ACM Reference Format: Lingzhe Zhang † , Yunpeng Zhai † , Tong Jia ∗ , Minghua He, Chiming Duan, Zhaoyang Liu, Bolin Ding, and Ying Li ∗ . 2026. E2E-REME: Towards End- to-End Microservices Auto-Remediation via Experience-Simulation Rein- forcement Fine-Tuning. In 34th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (FSE Companion ’26), July 5–9, 2026, Montreal, QC, Canada. ACM, New York, NY, USA, 12 pages. https://doi.org/10.1145/3803437.3805206 1 Introduction Modern microservice systems have become increasingly complex due to dynamic interactions and rapidly evolving runtime envi- ronments [68]. This rising complexity inevitably leads to more frequent and harder-to-predict system failures. Such failures can be extremely costly: according to industry analysis, large enterprises experience an average direct loss of exceed $1,000,000 for every hour of IT downtime [16]. Given the substantial operational and financial impact, mod- ern cloud-native systems urgently require the capability not only to detect failures but also to automatically remediate them in a timely and reliable manner [5,12,23,39,61,67]. As a result, auto- remediation—which autonomously identifies appropriate corrective actions and executes them with minimal human intervention—has become a critical component for ensuring resilient and cost-efficient operations at scale [11, 15, 19, 22, 53, 59, 62–64]. With the rapid advancement of large language models (LLMs), researchers have increasingly explored leveraging their strong rea- soning and code-generation capabilities [14,18,34,35,44,52,60,65, 66,71] for microservice remediation [56]. A practical and industry- adoptable approach to address microservice auto-remediation is to use LLMs to generate ansible playbooks that can be automatically arXiv:2604.11094v1 [cs.SE] 13 Apr 2026 FSE Companion ’26, July 5–9, 2026, Montreal, QC, CanadaLingzhe Zhang et al. executed to repair faulty services [40]. Compared with traditional shell scripts, Ansible playbooks serve as structured, declarative specifications for operational procedures and offer a higher-level abstraction with clearer structure, stronger readability, and im- proved reusability and maintainability [13]. These advantages have made playbooks a widely adopted mechanism for implementing au- tomated operational procedures in large-scale microservice systems, and thus a natural target for LLM-driven auto-remediation [41]. Following this trend, existing work on LLM-driven microservice remediation can be broadly categorized into two groups: methods and benchmarks. Methods focus on generating executable ansible playbooks from human-written instructions. For example, Wisdom- Ansible [36] fine-tunes CodeGen to produce remediation scripts, MAPE-Ansible [41] leverages GPT-4 and LLaMa-2 70B in a MAPE- K loop architecture, and WCA-Ansible [40] is pre-trained from scratch on natural language, source code, and Ansible data. Bench- marks support these studies by providing curated collections of prompts and playbook templates for automation tasks. KubePlay- book [31] contains 130 natural language prompts for generating automation-focused remediation scripts, while Andromeda [32] pro- vides structural representations of over 125,000 Ansible roles, along with more than 800,000 concrete changes between role versions extracted from the underlying Git repositories. However, existing methods and benchmarks still face key limitations when applied in real-world scenarios: • Task-level: These approaches typically rely on human-crafted prompts authored by experienced SREs, where the LLM only translates textual instructions into executable code. Such designs depend heavily on manual intervention, lack iterative feedback from the runtime environment, and fail to achieve end-to-end automation from failure diagnosis to system recovery. •Method-level: The generation of Ansible playbooks critically depends on the current runtime state of the microservice system. Without accurate and up-to-date system state guidance, the gen- erated remediation scripts may be suboptimal or even incorrect. Moreover, representative methods such as MAPE-Ansible [41] rely on very large, closed-source models (e.g., GPT-4 and LLaMa- 2 70B), which require substantial computational resources and time for inference, limiting both scalability and efficiency. Toaddressthetask-levelchallenge,weproposeanewtask, End-to-EndMicroserviceRemediation(E2E-MR). E2E-MR aims to directly generate executable ansible playbooks from a given di- agnosis report and autonomously recover the faulty system. As illustrated in Figure 1, unlike previous approaches that rely on human-crafted prompts authored by experienced SREs based on diagnostic reports, E2E-MR establishes a closed-loop remediation pipeline, in which LLMs translate diagnostic insights into concrete repair actions that can be automatically executed within the mi- croservice environment. For evaluation and structured comparison of this challenging new task, we introduce MicroRemed 1 , a benchmark designed to assess LLMs’ capabilities in end-to-end microservice remediation. MicroRemed automatically deploys a real microservice system and continuously injects diverse failures. For each injected failure, it generates a corresponding diagnosis report based on the target 1 The benchmark is available at https://github.com/LLM4AIOps/MicroRemed. Microservice Systems Ansible PlayBook Failure Diagnosis Report The CartService is suffering from high CPU load. Failure Diagnosis SREs Execute Remediation LLM Write an ansible playbook ...: 1) Get a list of deployments ... 2) Use kubectl command ... 3) Use ... to ... output of step 2 ... - name: Remediate CPU load with ... hosts: k8s_nodes tasks: - name: Get all deployments with ... shell: | kubectl get deployments ... Diagnosis Report The CartService is suffering from high CPU load. E2E- REME Ansible PlayBook Failure Diagnosis Figure 1: Previous microservice remediation workflow com- pared with the end-to-end microservice remediation pipeline proposed in this paper. component and failure type, which is then provided to the LLM under evaluation. The LLM produces an Ansible playbook, which is executed automatically, and the system subsequently verifies whether the injected failure has been successfully repaired. Mi- croRemed supports unlimited rounds of random failure injection and verification, allowing for extensive stress testing and iterative evaluation. Moreover, to facilitate fair and structured comparison, we categorize remediation targets into three difficulty levels—easy, medium, and hard—based on the complexity and interdependency of the underlying failure scenarios. Toaddressthemethod-levelchallenges,weproposeE2E-REME, anend-to-endauto-remediationmodelformicroservicesvia Experience-SimulationReinforcementTraining. E2E-REME 2 is designed to mirror how human SREs handle failures: continuously acquiring fresh runtime signals, reasoning over candidate repair strategies, and refining their decisions before executing a final remediation plan. To operationalize this process, E2E-REME em- ploys a lightweight multi-agent workflow, which we refer to as ThinkRemed. It serves as an architectural scaffold that structures re- mediation into probing, executing, and verifying-refinement steps. Training E2E-REME for the end-to-end microservice remedia- tion task is accomplished via an Experience-Simulation Reinforce- ment Training pipeline tailored to microservice operations. The pipeline consists of three stages: (1) Expert-Guided Supervised Fine-Tuning (SFT), which provides foundational remediation be- haviors; (2) Simulation-Based RFT, which exposes the model to synthetic failure scenarios and teaches it to act within simulated en- vironments; and (3) Reality-Anchored RFT, which further optimizes the model using feedback collected from real remediations. We evaluate E2E-REME using MicroRemed, integrated with two widely adopted microservice systems—Train-Ticket [72] and Online-Boutique [7]—as well as a self-developed lightweight system, Simple-Micro. Experimental results show that E2E-REME surpasses nine representative LLMs, achieving up to an average 49.32% higher accuracy while maintaining competitive inference efficiency. We 2 The model is available at https://modelscope.cn/models/ZhangLingzhe/E2E-REME. E2E-REMEFSE Companion ’26, July 5–9, 2026, Montreal, QC, Canada further validate its performance under realistic industrial work- loads and microservice environments, which similarly confirm the effectiveness and robustness of E2E-REME. In summary, the contributions of our work are as follows: •We introduce the task of end-to-end microservice remediation (E2E-MR), which requires LLMs to directly generate executable Ansible playbooks from diagnosis reports and autonomously repair faulty systems. To support systematic evaluation, we build MicroRemed, a challenging benchmark that automates microservice deployment, failure injection, playbook execution, and post-repair verification. •To address the challenges of E2E-MR, we propose E2E-REME, an end-to-end auto-remediation model for microservices. E2E- REME operates within a lightweight multi-agent workflow, ThinkRemed, which structures the remediation process into prob- ing, execution, and verification–refinement steps. The model is trained via a tailored Experience-Simulation Reinforcement Training pipeline. •We conduct extensive experiments on three microservice systems and compare E2E-REME against nine representative LLMs. Re- sults demonstrate its superior accuracy and efficiency. Additional validation under realistic industrial-style workloads further con- firms the effectiveness and robustness of E2E-REME. 2 Background 2.1 Microservice Auto-Remediation Modern microservice architectures decompose applications into large numbers of loosely coupled services that interact through lightweight APIs. While this design improves scalability and de- velopment agility, it also increases operational complexity: faults may arise from configuration errors, resource contention, cascad- ing failures, or inconsistent service states. As a result, automated remediation has become essential for maintaining system reliability. Auto-remediation refers to the process of automatically gener- ating a repair plan, and executing the necessary actions to restore system health. In practice, these repair actions often involve opera- tions such as restarting services, modifying configurations, cleaning corrupted state, or redeploying components. Ansible is widely used for such tasks because it provides a declarative automation frame- work that can execute system-level and application-level operations across distributed environments. Its playbook-based design enables LLMs or automation agents to produce actionable repair procedures that can be directly executed without human intervention. An Ansible playbook is a YAML-based script defining hosts, tasks, and their execution conditions. Figure 2 is a simplified example illustrating how a remediation workflow can handle high CPU load by automatically scaling a service. This example shows how Ansible playbook operationalizes auto- remediation by providing a structured, declarative interface that bridges diagnosis and repair—allowing LLM-based systems to gen- erate actionable and directly executable recovery procedures. 2.2 Reinforcement Fine-Tuning Reinforcement Fine-Tuning (RFT) adapts language models to decision-making tasks by optimizing model behavior using reward 1 --- 2 - name: Mitigate high CPU load 3 hosts: microservice_nodes 4 become: yes 5 tasks: 6 - name: Check CPU usage 7 shell: "top -bn1 | awk -F'[, ]+′/Cpu/ print $3+$5'" 8 register: cpu 9 10 - name: Scale service if CPU > 80% 11 shell: kubectl scale deploy my -service --replicas =4 12 when: cpu.stdout | float > 80 13 14 - name: Notify monitoring 15 shell: "curl http :// monitor/api/notify -d'scaled'" Figure 2: An Ansible Playbook for CPU scaling or preference feedback, rather than relying solely on supervised instruction–response pairs [3,73]. Unlike supervised fine-tuning (SFT), which teaches models to imitate expert demonstrations, RFT enables models to explore action spaces, evaluate long-term con- sequences, and self-correct through iterative interaction with an environment. RFT methods can be broadly categorized into two families: (1) Reward-based policy optimization. These approaches assign scalar rewards to model-generated actions or trajectories and optimize the policy to maximize expected reward. Group-based variants, such as Group Relative Policy Optimization (GRPO) [42], enhance stability by comparing multiple model completions under the same context, enabling the model to learn nuanced distinctions among candidate actions. Such methods are particularly effective for structured reasoning and tool-use scenarios where reward signals derive from execution correctness, efficiency, or safety. (2) Preference-based optimization. In many real-world decision-making tasks, explicit numeric rewards are difficult to define, while human operators can reliably express preferences between paired model outputs. Direct Preference Optimization (DPO) [37] provides a scalable solution by learning directly from such pairwise preferences, aligning model behavior with human judgments without requiring reinforcement learning rollouts or handcrafted reward models. Both families offer complementary strengths: reward-based methods facilitate exploration and environment-driven learning, whereas preference-based methods enable fine-grained alignment with human operational expertise. Despite rapid progress, the application of RFT to system oper- ations—particularly microservice auto-remediation—remains lim- ited. Compared with static preference or tool-use settings, auto- remediation introduces uniquely challenging characteristics: dy- namic runtime states, multi-step causal dependencies, safety-critical actions, and scarce human supervision. These factors motivate a combined RFT strategy in E2E-REME, leveraging reward-driven exploration in simulated environments together with preference- driven alignment using real-world operator corrections. 3 Benchmark Construction We present the construction of the MicroRemed benchmark in this section. We begin with an overview of the task definition and the underlying design principles (§3.1), followed by the architecture FSE Companion ’26, July 5–9, 2026, Montreal, QC, CanadaLingzhe Zhang et al. Target Service Failure Type Runtime Envs Action Constraint Status Verification Auxiliary Context ChaosConfig Failure Injection Failure Report Ansible PlayBook Candidate Remediation LLM Microservice Systems Failure Generate Execute Remediate Evaluation Execution Engine Recovery Microservice Systems Figure 3: MicroRemed Benchmark Pipeline: the benchmark launches a real microservice; Failure Injection injects faults and produces a Failure Report; the Failure Report together with Auxiliary Context is provided to the Candidate Remediation LLM which generates an Ansible Playbook; the Execution Engine executes the playbook; Status Verification checks remediation success; Evaluation and Recovery restores the system for the next run. of the MicroRemed benchmark (§3.2) and the evaluation protocol (§3.3). Finally, we describe the overall composition of MicroRemed (§3.4). 3.1 Design Principles Existing microservice remediation approaches typically depend on human-crafted prompts designed by experienced SREs, where LLMs merely translate natural language instructions into executable scripts such as Ansible playbooks. This paradigm lacks autonomy and generalization, as it relies heavily on explicit human reasoning rather than the model’s understanding of the system state. To address this limitation, we introduce the task of End-to-End Microservice Remediation (E2E-MR), which aims to evaluate an LLM’s ability to autonomously generate executable remedia- tion plans given only structured diagnostic information. Unlike conventional prompt-based generation, E2E-MR emphasizes a di- rect remediation process that transforms diagnostic reports into actionable repair operations. 푓 휃 : (S 푡푎푟푔푒푡 ,T 푓 푎푖푙 ,C 푎푢푥 ) → 푝 ∗ , 푝 ∗ = arg max 푝∈P U E(푝,S 푓 푎푖푙 )=S 푛표푟푚푎푙 (1) Formally, the E2E-MR task can be formulated as Equation 1, where푓 휃 is the candidate remediation LLM parameterized by휃, S 푡푎푟푔푒푡 denotes the failed microservice,T 푓 푎푖푙 the failure type, and C 푎푢푥 auxiliary contextual information.Pis the space of executable playbooks,Erepresents the execution environment, andU(·)mea- sures the utility of successful recovery. The goal is to generate an optimal playbook푝 ∗ that maximizes the likelihood of recovering the system stateS 푓 푎푖푙 toS 푛표푟푚푎푙 . Therefore, to design a benchmark for the E2E-MR task, we adhere to the following design principles: •Dynamic Execution Benchmark. Unlike most LLM bench- marks that collect static data to form fixed datasets, the proposed benchmark is designed as a live and interactive execution envi- ronment. It actively launches real microservice systems, injects controlled failures, and interacts dynamically with running ser- vices. This design enables the benchmark to capture real-time behaviors, system dynamics, and contextual dependencies that static datasets cannot represent. •Execution-based Evaluation. Evaluation is not determined by linguistic or structural similarity of generated outputs, but by execution outcomes. Each generated playbook is executed within the microservice environment, and the benchmark verifies success by assessing whether the system has been fully recovered to its normal operational state. •Comprehensive Scalability. Built on these foundations, the benchmark is designed to be method-scalable, LLM-scalable, failure-scalable, and system-scalable. It supports diverse LLM- based remediation methods, allows plug-and-play replacement of remediation models, accommodates various failure scenarios, and can be easily extended to new microservice systems with minimal configuration effort. 3.2 Architecture Based on the above design principles, we develop MicroRemed. The overall architecture of MicroRemed is illustrated in Figure 3. MicroRemed actively launches real microservice systems and per- forms Failure Injection to introduce controlled faults. According to the injected target service and failure type, it generates a Fail- ure Report, which—together with a set of Auxiliary Contexts—is provided to the Candidate Remediation LLM to produce an exe- cutable Ansible Playbook. The playbook is then executed by an Execution Engine to carry out automated remediation. After exe- cution, a Status Cerification module checks whether the issue has been successfully resolved. Finally, the Evaluation and Recovery stage assesses the remediation outcome and restores the microser- vice system to its original state, thereby enabling reproducible and iterative experimentation. The Failure Injection module introduces faults into the system through two complementary approaches: chaos injection and con- figuration injection. For resource-related or runtime failures (e.g., CPU stress, memory pressure, or network latency), MicroRemed E2E-REMEFSE Companion ’26, July 5–9, 2026, Montreal, QC, Canada Microservice Systems Failure Root Cause Service Root Cause Analysis Failure Category Time Time Window E2E-REME (Coordinator) Ansible PlayBook Generate Execution Agent Remediate Runtime Envs Action Constraint Verification Agent Probe Agent Normal? Y Judge N Think Experience Pool Experience- Simulation RFT Auxiliary Context Figure 4: Runtime pipeline of E2E-REME. The model acts as a coordinator within a multi-agent workflow, ThinkRemed, which organizes the remediation process through the coordination of probing, execution, and verification agents. adopts chaos injection, which dynamically perturbs the runtime environment using Chaos Mesh [30] to emulate realistic fault condi- tions. For configuration-related failures (e.g., incorrect environment variables or service dependency misconfigurations), the system applies configuration injection, which directly modifies specific configuration files or environment settings to trigger controlled failures. The Status Verification module resembles traditional anomaly de- tection in purpose but differs fundamentally in mechanism. While anomaly detection infers abnormality from large volumes of com- plex runtime data, status verification performs targeted validation of whether a specific injected failure has been fully remediated. For example, if a CPU-stress failure was injected into service A, status verification will exclusively inspect the CPU metrics of service A to confirm recovery. This targeted design ensures 100% verifica- tion accuracy, a level of precision unattainable by general anomaly detection approaches. 3.3 Evaluation Protocol MicroRemed supports comprehensive evaluation from multiple perspectives, including performance, efficiency, and resource uti- lization. Specifically, we adopt the following metrics to quantify the effectiveness of candidate remediation LLMs: Remediation Accuracy (RA) — measures the proportion of failures that are successfully repaired, reflecting the overall perfor- mance of the model. Average Remediation Latency (ARL) — evaluates the tempo- ral efficiency of each successful remediation cycle, encompassing both reasoning and execution delays. Average Token Consumption (ATC) — quantifies the language-model cost efficiency, representing the average number of tokens consumed to achieve a successful remediation. 3.4 Benchmark Composition Although MicroRemed is designed with comprehensive scalability and supports extensible failure types and microservice systems, in our benchmark we include seven representative types of failures and three real-world microservice systems. Failure Types. As shown in Table 1, MicroRemed includes seven representative failures across three categories: resource-level (CPU, memory, I/O saturation), network-level (network loss, network delay), and application-level (pod failure, configuration error). No.CategoryFailure Types 1 Resource-Level CPU Saturation 2Memory Saturation 3IO Saturation 4 Network-Level Network Loss 5Network Delay 6 Application-Level Pod Failure 7Configuration Error Table 1: Benchmark statistics on failure types Microservice Systems. MicroRemed integrates three microser- vice systems. Among them, two widely used benchmarks—Train- Ticket [72] and Online-Boutique [7]—are well recognized for emu- lating realistic production environments. In addition, we include a self-developed lightweight system, Simple-Micro, designed to enable controlled experiments and facilitate fine-grained analysis. Difficulty Levels. Although MicroRemed supports arbitrary combinations of injected failures, we define three standardized difficulty levels—easy (23 cases), medium (49 cases), and hard (80 cases)—to enable fair and structured comparison across remedia- tion methods. Each level corresponds to a curated set of failure combinations that vary in fault diversity, dependency complexity, and recovery difficulty. 4 E2E-REME To address the end-to-end microservice auto-remediation task, we propose E2E-REME, a model designed to emulate how human SREs diagnose and repair failures. As shown in Figure 4, E2E-REME op- erates by continuously gathering fresh runtime signals, reasoning FSE Companion ’26, July 5–9, 2026, Montreal, QC, CanadaLingzhe Zhang et al. over potential repair strategies, and iteratively refining decisions before executing a final remediation plan. To operationalize this workflow, E2E-REME adopts a lightweight multi-agent framework, ThinkRemed, which structures the remediation process into three agents: probing (collecting runtime evidence), execution (applying candidate repairs), and verification–refinement (validating and ad- justing actions based on system feedback). Built on top of this frame- work, we further train E2E-REME using a tailored Experience- Simulation Reinforcement Training (RFT) pipeline, enabling the model to learn robust, action-oriented remediation behaviors aligned with real microservice operational dynamics. 4.1 ThinkRemed: A Multi-Agent Microservice Auto-Remediation Framework Figure 4 illustrates the operational workflow of ThinkRemed. When a microservice system experiences a failure, a state-of-the- art root cause analysis identifies the faulty service and the corre- sponding failure category. This information, together with auxiliary context (e.g., runtime environment and action constraints), is pro- vided as input to E2E-REME, which acts as the Coordinator within ThinkRemed. The Coordinator first receives the auxiliary contextC 0 and failure reportR 0 , and adaptively determines whether to invoke the Probe Agent to gather additional runtime information from the system. The probe agent executes a series of system state queries and returns the corresponding results. Once sufficient information is collected, the Coordinator synthesizes a candidate Ansible playbook 푝 푡 . The generated playbook푝 푡 is then sent to the Execution Agent, which attempts to remediate the faulty microservice system and records the execution outcomes for subsequent reflection. After execution, the Verification Agent evaluates the remediation result, producing a binary outcome푣 푡 ∈ 0,1indicating success or failure. It is important to note that this Verification Agent differs from the Status Verification used in the benchmark. In the benchmark’s sim- ulated failure environment, Status Verification can directly access low-level system information to determine the repair outcome. In contrast, the Verification Agent operates in a live system setting and relies on state-of-the-art anomaly detection methods to assess whether the remediation was successful. If the remediation fails, the system enters a reflection phase, and control returns to the Co- ordinator for iterative refinement based on the feedback. To ensure timely remediation and accommodate LLM context limitations, the iteration loop is bounded by a maximum trial budget 푇 max . 푝 푡 = 푓 휃 (R 푡 ,C 푡 ,I 푡 ), 푠 푡+1 =E(푝 푡 ,푠 푡 ), 푣 푡 =V(푠 푡+1 ), (R 푡+1 ,C 푡+1 )=U(R 푡 ,C 푡 ,푠 푡+1 ) if 푣 푡 = 0 and 푡< 푇 max (2) In summary, the iterative process of ThinkRemed can be formal- ized as Equation 2, where푓 휃 denotes the Coordinator’s reasoning policy,E the execution operator, andV the verification predicate. This multi-agent, iterative workflow enables E2E-REME to contin- uously reason, act, and refine its remediation strategies in response to dynamic microservice system states. Oracle Teacher E2E-REME Real-World Deployment Experience Replay Buffer MicroRemed Benchmark ① Expert-Guided SFT SREs f real areal f syn a syn t syn ✓ Remed fsyn freal freal a real MicroRemed Benchmark f sim Rollouts asimtsim Multi-Criteria Remed Grader ③ Reality-Anchored RFT ② Simulation-Based RFT f sim t sim a sim r sim Verification Safety-Aware Action Penalizer Offline Online - a real + + a real - Figure 5: Overall framework of Experience-Simulation RFT 4.2 Experience-Simulation RFT Experience-Simulation RFT consists of three stages: (1) Expert- Guided SFT, (2) Simulation-Based RFT, and (3) Reality-Anchored RFT. The first two stages—Expert-Guided SFT and Simulation-Based RFT—are used to train E2E-REME in an offline setting, while Reality- Anchored RFT continuously fine-tunes the model after it is deployed online. 4.2.1 Expert-Guided SFT. Given that lightweight models exhibit limited reasoning ability, weak tool-use proficiency, and difficulty in directly generating executable Ansible playbooks, the goal of this stage is to teach the model the fundamentals of (i) structured rea- soning, (i) tool-calling behaviors, and (i) valid Ansible playbook construction. To achieve this, we employ an Oracle Teacher Model and run it on the MicroRemed Benchmark. For each synthetic failure instance 푓 푠푦푛 , the teacher model is allowed to interact with the environment. If the remediation attempt succeeds, we extract the reasoning trace 푡 푠푦푛 , and the final executable Ansible playbook푎 푠푦푛 . These elements, paired with the original failure description, form the supervision tuples푓 푠푦푛 ,푡 푠푦푛 , 푎 푠푦푛 . L SFT = E (푓 syn ,푡 syn ,푎 syn ) − log 휋 휃 (푡 syn , 푎 syn | 푓 syn ) (3) The Expert-Guided SFT phase thus optimizes the model to repro- duce both the teacher’s reasoning process and its generated repair actions. Formally, the SFT objective can be expressed as Equation 3, where denotes the policy of E2E-REME. 4.2.2 Simulation-Based RFT. While SFT enables the model to imi- tate expert behaviors and acquire essential formatting and tool-use patterns, it cannot teach the model to reason, explore, or self-correct beyond the expert demonstrations. To equip E2E-REME with these capabilities, we design a Simulation-Based RFT stage. In this stage, the SFT-initialized E2E-REME is deployed on the Mi- croRemed benchmark to generate full rollouts. For each simulated episode, the model produces a reasoning trace푡 sim , an Ansible play- book푎 sim , and receives a remediation outcome indicating whether the system has been successfully repaired. A reward is then as- signed to the rollout using a combination of (1) a Multi-Criteria Remediation Grader and (2) a Safety-Aware Action Penalizer. The Multi-Criteria Remediation Grader provides the primary re- ward signal. It assigns a high reward for successful remediation and further incorporates several auxiliary criteria, including: structural E2E-REMEFSE Companion ’26, July 5–9, 2026, Montreal, QC, Canada correctness of the generated playbook, successful execution of indi- vidual tasks, absence of execution errors, and token-efficiency of the reasoning trace (encouraging concise reasoning when remediation succeeds). Complementing this, the Safety-Aware Action Penalizer imposes substantial penalties for unsafe actions. Even though action con- straints are provided as auxiliary context, lightweight models occa- sionally generate playbooks that may lead to harmful system-wide side effects. To prevent such behaviors, any playbook containing unsafe operations receives a large negative penalty, regardless of whether the remediation happens to succeed. 푅= 훼·I[success] + 훽·푟 struct + 훾·푟 exec + 훿·푟 eff − 휆·I[unsafe] (4) In summary, the overall reward for a simulated rollout can be defined as Equation 4, whereI[·]is the indicator function,푟 struct measures playbook structural validity,푟 exec evaluates execution correctness,푟 eff encourages concise reasoning, andI[unsafe]flags unsafe or system-risky actions. The coefficients훼, 훽,훾,훿, 휆control the relative influence of each signal. To optimize E2E-REME under this reward model, we adopt Group Relative Policy Optimization (GRPO), which stabilizes credit assign- ment across long reasoning–action traces. Given a batch of rollouts (푓 푖 , 푎 푖 , 푅 푖 ), GRPO updates the policy by maximizing advantage- weighted likelihood ratios within each rollout group. Formally, the optimization objective of this stage is given in Equation 5. Here,휋 휃 denotes the parametrized policy of E2E-REME after SFT initialization,G(푖)denotes the group of rollouts origi- nating from the same simulated failure instance, and the term in parentheses introduces a group-wise baseline to reduce gradient variance and stabilize training. L GRPO =− ∑︁ 푖 log 휋 휃 (푎 푖 | 푓 푖 )· © « 푅 푖 − 1 |G(푖)| ∑︁ 푗∈G(푖) 푅 푗 ª ® ¬ (5) Through Simulation-Based RFT, E2E-REME learns to explore, self-correct, and refine its reasoning strategies beyond expert demonstrations, enabling more robust and autonomous remedi- ation behaviors. 4.2.3 Reality-Anchored RFT. During real-world deployment, each encountered failure instance푓 real is first handled by E2E-REME, producing a model-generated remediation playbook푎 − real . If the model-generated action does not successfully remediate the system, the failure is escalated to human operators. Site Reliability Engi- neers (SREs) then provide a corrective playbook푎 + real , which reflects an expert-preferred remediation strategy under the same condi- tions. This naturally yields a pairwise preference signal:푎 + real ≻ 푎 − real , indicating that the SRE action should be preferred over the model’s attempt. Rather than relying on manually engineered scalar rewards or heuristic scoring functions, Reality-Anchored RFT employs Direct Preference Optimization (DPO) to directly align E2E-REME with the remediation preferences demonstrated by SREs. Formally, let휋 휃 denote the policy of E2E-REME. The DPO objective encourages the model to increase the likelihood of generating the expert-preferred action푎 + real while decreasing the likelihood of the model-generated action 푎 − real . ( L DPO =− log휎 훽 Δ 휃 (푎 + real )−Δ 휃 (푎 − real ) Δ 휃 (푎) ≜ log 휋 휃 (푎 | 푓 real )− log 휋 ref (푎 | 푓 real ) (6) Formally, this preference-driven learning process is captured in Equation 6. Here,휋 ref denotes a frozen reference policy (typically the model obtained after Simulation-Based RFT),훽controls the sharpness of preference separation, and휎(·)is the logistic sigmoid function. This stage enables E2E-REME to continuously internalize hu- man expertise, ensuring that the model not only improves after deployment but also conforms to real-world safety conventions, operational best practices, and implicit SRE decision criteria. 5 Evaluation In this section, we first introduce the implementation of E2E-REME, followed by the experimental setup. We then evaluate E2E-REME in terms of the following four research questions: •RQ1: How accurately does E2E-REME perform microservice remediation compared to baseline LLMs? • RQ2: What is the inference efficiency of E2E-REME—measured by runtime and token consumption? •RQ3: How does each component in E2E-REME contribute to the final remediation accuracy? • RQ4: How well does E2E-REME perform under realistic indus- trial workloads and microservice environments? 5.1 Implementation & Setting 5.1.1 Implementation. We implement our algorithm using Agen- tEvolver [50], a self-evolving agent reinforcement-learning frame- work proposed by Alibaba Tongyi Lab. Unless otherwise stated, we set the training reward parameters to훼=1,훽=0.1,훾=0.1, 훿=0.5, and휆=2. The maximum retry number of ThinkRemed is set to푇 max =1. We adopt Qwen3-8B as the backbone LLM for all fine-tuning stages. 5.1.2 Experimental Setup. E2E-REME is trained on a CentOS 8 server equipped with 24 Intel(R) Xeon(R) CPUs (2.90GHz), 400GB RAM, and four NVIDIA A800 GPUs, each with 80GB of memory. The MicroRemed benchmark microservices are deployed across three machines, each equipped with 16 Intel(R) Xeon(R) CPUs (2.50GHz) and 64GB RAM. To comprehensively evaluate the end-to-end microservice re- mediation capability of current LLMs, we examine a total of nine representative models, encompassing both closed-source and open- source variants. For fairness and consistency, all LLMs are executed within the ThinkRemed framework. Closed-Source LLMs: Qwen3-Plus, Qwen3-Max, and Qwen3- Flash [47]. Open-Source LLMs: QwQ-32B, Qwen3-Next-80B-A3V, Qwen3- 235B-A22B, DeepSeek-V3.2-Exp [21], Kimi-K2 [45], and GLM- 4.5 [49]. FSE Companion ’26, July 5–9, 2026, Montreal, QC, CanadaLingzhe Zhang et al. LLM Backbone Train-TicketOnline-BoutiqueSimple-Micro Accuracy (%)Latency (s)Accuracy (%)Latency (s)Accuracy (%)Latency (s) EasyMedHardEasyMedHardEasyMedHardEasyMedHardEasyMedHardEasyMedHard Closed-Sourced LLMs Qwen3-Plus47.8330.6131.1779.8377.4481.2243.4843.7531.5853.3583.7759.3547.8336.1738.0371.2675.7978.18 Qwen3-Max 47.8328.5730.7769.8786.3812.3639.1337.5025.3234.8246.4948.2030.4322.9217.9137.0239.7352.43 Qwen3-Flash21.7416.3313.1643.2484.96290.734.7830.6121.3342.3377.2698.6422.7214.588.8650.5261.1265.33 Open-Sourced LLMs QwQ-32B17.3910.207.89157.4194.1183.226.0922.4515.58109.9137.3155.517.398.336.76141.5188.7195.7 Qwen3-Next 13.046.125.0623.3320.4129.7617.3917.0217.7222.5722.7326.6421.7428.5719.3524.8334.5832.83 Qwen3-235B39.1334.6933.7883.3492.2073.5439.1334.6933.3374.5755.5274.2734.7836.7332.3982.4966.6573.20 DeepSeek-V3.28.7016.3311.54148.3155.1121.531.8221.2822.7863.163.160.121.7429.1720.00129.6106.498.6 Kimi-K2 21.7420.0029.4990.8481.56101.122.7326.5330.3875.8779.0783.8547.8344.8943.7590.8279.2876.84 GLM-4.521.7420.4127.63189.2112.1108.143.4843.7539.47135.1126.1130.843.4836.7330.38127.8126.3132.8 E2E-REME82.6177.7870.8339.6542.3341.5295.6589.8078.7539.4438.3140.5691.3087.5072.1549.6553.4255.33 Table 2: Remediation Accuracy (left columns) and Latency (right columns) across closed-source and open-source LLM backbones 5.2 RQ1: Remediation Accuracy We first compare the remediation accuracy of E2E-REME against other LLMs on the E2E-MR task. As illustrated in Table 2, the light- blue columns on the left summarize the accuracy under the easy, medium, and hard level settings for each microservice environment. Overall, except for E2E-REME, Qwen3-Plus achieves the strongest performance among all evaluated models, followed by Qwen3-235B. At the microservice level, Train-Ticket emerges as the most challenging environment, followed by Simple-Micro. Notably, even under the easiest difficulty level, all standalone LLMs fail to exceed 50% accuracy, underscoring the difficulty and rigor of the MicroRemed benchmark. In contrast, E2E-REME consistently outperforms the best base- line, Qwen3-Plus, by 56.48%, 48.50%, and 42.97% across the three microservice environments, demonstrating its clear superiority in end-to-end microservice remediation. 5.3 RQ2: Inference Efficiency We next compare the remediation latency of E2E-REME with other LLMs. As shown in the light-gray columns of Table 2, the latency reflects the end-to-end time of a full remediation cycle, including model reasoning, system probing, action execution, and recovery verification. Overall, Qwen3-Next exhibits consistently low latency across all environments, indicating a lightweight reasoning pipeline and efficient prompt handling. However, when considered together with its accuracy, this speed advantage comes at the expense of insufficient reasoning depth and unstable remediation performance, rendering it largely impractical for real-world use. In contrast, E2E- REME achieves the second-lowest latency among all evaluated Figure 6: Latency–accuracy trade-off of various large lan- guage models on the Online-Boutique microservice models—incurring only modest overhead compared to Qwen3-Next (higher by 40.48%, 39.19%, and 41.76% across the three microservices, respectively), while remaining substantially faster than Qwen3- Flash (lower by 70.52%, 45.79%, and 10.49%). More importantly, E2E-REME delivers consistently high accuracy, striking a favorable balance between efficiency and effectiveness and making it suitable for practical end-to-end microservice remediation. To provide a clearer comparison, we further plot the la- tency–accuracy trade-off in Figure 6, where both latency and accu- racy are averaged over the three difficulty levels (Easy, Medium, and Hard) on the Online-Boutique microservice. Each point represents E2E-REMEFSE Companion ’26, July 5–9, 2026, Montreal, QC, Canada Backbone Train-TicketOnline-Boutique Easy Medium HardEasy Medium Hard Closed-Sourced LLMs Qwen3-Plus33634988435918822 127299 108053 Qwen3-Max 358321453256482153665758 Qwen3-Flash294836513891349030033378 Open-Sourced LLMs QwQ-32B414759185936200337842951 Qwen3-Next14490 13267 1309112190938724385 Qwen3-235B48588369666910624 1574930381 DeepSeek-V3.2519572957785585560046454 Kimi-K2 645249646728481063147793 GLM-4.51126494921065211270 1199110692 E2E-REME(ours)1715 1844 17351552 2223 1648 Table 3: Average Token Consumption per remediation results a model, where the x-axis denotes average inference latency (lower is better) and the y-axis indicates accuracy. The plot highlights the superiority of E2E-REME, which lies closest to the upper-left region. Relative to the second-best model, Qwen3-Max, E2E-REME achieves 57.71% higher accuracy while reducing latency by 8.65%, respectively. We further compare the average token consumption of each model, as shown in Table 3. The reported values include both in- put and output tokens, thereby reflecting the total reasoning and generation workload for each remediation process. The results align with the latency findings, though a few exceptions provide additional insight. For example, Qwen3-Plus and Qwen3-Next con- sume significantly more tokens without proportional increases in latency—mainly due to unnecessary probing steps that generate overly long command outputs. Aside from these cases, the results further corroborate the efficiency of E2E-REME: compared with the second most efficient model, Qwen3-Flash, its token consumption is lower by 49.53% and 45.06%, respectively. 5.4 RQ3: Ablation Study To assess the contribution of each training stage in E2E-REME, we conduct an ablation study on the Online-Boutique microservice. The results are summarized in Table 4. Starting from the raw Qwen3- 8B backbone, the model achieves only 30.43 %, 20.83%, and 15.56% accuracy across the three difficulty levels, confirming that the base model lacks the specialized knowledge required for effective end- to-end remediation. Method Accuracy (%)Latency (s) EasyMediumHardEasyMediumHard Qwen3-8B30.4320.8315.56359.35319.24343.13 +SFT34.7824.4922.50263.72250.08285.43 +Sim-RFT86.9685.7169.6236.3750.4751.84 +Real-RFT95.6589.8078.7539.4438.3140.56 Table 4: Ablation study on the Online-Boutique microservice Introducing SFT yields a substantial improvement, boosting accu- racy by 3.66%–6.94% across different levels. This demonstrates that supervised instruction tuning on high-quality remediation trajecto- ries provides essential task grounding and significantly enhances the model’s action planning ability, while also reducing inference latency by 21.78% due to fewer unnecessary probing steps. Adding Sim-RFT yields the largest performance gain, delivering an additional 53.61% improvement. The gains indicate that synthetic experience simulation effectively enriches the model’s exposure to diverse failure-recovery patterns, enabling more robust reasoning in unseen scenarios. Finally, Real-RFT provides an additional but smaller improvement of +7.24% on accuracy. The modest gain is primarily because the failure types and microservices used in Real- RFT training differ from those in the Online-Boutique evaluation environment. Nevertheless, even with this mismatch, Real-RFT still contributes to more consistent decision-making and a small reduction in execution time (-14.69%). We further validate the effectiveness of each component in ThinkRemed. To isolate the impact of our training pipeline, we perform this analysis using Qwen3-Plus—the strongest LLM back- bone aside from E2E-REME—instead of our trained model. Method Train-TicketOnline-Boutique Easy Medium HardEasy Medium Hard ThinkRemed47.8330.61 31.1743.48 43.75 31.58 w/o Probe43.4834.6930.3839.1340.4330.38 w/o Reflection43.4828.5726.9234.7836.1725.32 w/o P. & R. 39.1333.3320.5130.4335.4220.51 Table 5: ThinkRemed’s ablation study As shown in Table 5, we evaluate three variants: removing the probe agent, removing reflection, and removing both. Overall, both components contribute positively. For example, in the Train-Ticket microservice (easy level), removing either probe or reflection re- duces accuracy by 13.05%. Across all settings, reflection plays a more critical role than probing: removing reflection results in an average 5.53% accuracy drop, whereas removing the probe agent decreases accuracy by only 1.66%. 5.5 RQ4: Industrial Evaluation To assess the practical effectiveness of E2E-REME under realistic industrial workloads and microservice environments, we conduct an evaluation on three production microservices paired with their real operational traffic. Unlike the benchmark experiments—which directly measure accuracy and latency—this study focuses on reme- diation time reduction, a metric that more faithfully captures the efficiency gains experienced by Site Reliability Engineers (SREs). For each incident, SREs manually recorded the time required to complete remediation both with and without E2E-REME, and the relative reduction was used as the final metric. We compare E2E-REME against two representative industrial automation systems, MAPE-Ansible [41] and WCA-Ansible [40]. As shown in Table 6, E2E-REME consistently achieves the largest reduction in remediation time across all three microservices. While MAPE-Ansible (powered by GPT-5) achieves reductions between FSE Companion ’26, July 5–9, 2026, Montreal, QC, CanadaLingzhe Zhang et al. Method Remediation Time Reduction (%) Microservice A Microservice B Microservice C MAPE-Ansible67.2155.8348.95 WCA-Ansible 73.7660.9056.74 E2E-REME(ours)81.3379.5876.03 Table 6: Evaluation on 3 realistic industrial workloads and microservices: Percentage reduction in remediation time 48.95% and 67.21%, and WCA-Ansible provides moderate improve- ments of up to 73.76%, E2E-REME delivers substantially stronger reductions—improving over the second-best WCA-Ansible by 7.57%, 18.68%, and 19.29%, respectively. These findings indicate that even without being explicitly fine- tuned on the target industrial system, E2E-REME can generate robust and reliable remediation strategies that meaningfully acceler- ate human operational workflows. This demonstrates the method’s strong potential for practical adoption in production environments. That said, fully realizing the vision of end-to-end microservice reme- diation—ideally reducing SRE intervention by 99%—will require fu- ture work on broader environment robustness, safety mechanisms, and tighter integration with production automation pipelines. 6 Threats to Validity We discuss the limitations of our work from two perspectives: the benchmark and the methodology. Benchmark. Although the MicroRemed benchmark provides suf- ficient challenges for evaluating end-to-end microservice remedia- tion, the currently supported failure types remain limited—covering only seven of the most common categories. In real-world sys- tems, failure modes are far more diverse and continuously evolv- ing [46,54,55]. Nevertheless, the design of MicroRemed inherently supports extensibility; new failure types can be integrated seam- lessly. The main challenge lies in the need to implement correspond- ing fault injection and detection mechanisms when introducing additional failure types. Methodology. While E2E-REME demonstrates strong performance on the end-to-end microservice auto-remediation task, its long-term stability and generalization still warrant further investigation. Al- though we include evaluations in realistic industrial environments, the inherent unpredictability of LLMs means that there is always a non-negligible risk of generating incorrect actions that could destabilize or even break the cluster. Therefore, fully deploying such systems in production requires additional safeguard mecha- nisms—such as action verification, safety filters, or fail-safe rejection modules—to ensure robust and reliable operation. 7 Related Work 7.1 Software Remediation Software remediation, as the next step beyond failure diagnosis, has long been studied as a generation problem. Existing work can be broadly grouped into two categories: mitigation solution generation and remediation script generation. Mitigation Solution Generation. These approaches focus on gen- erating actionable mitigation strategies for detected anomalies, of- ten leveraging large corpora of historical incident reports. Toufique et al. [1] conduct the first large-scale study evaluating LLMs for root-cause analysis and mitigation in production incidents. Drishti et al. [6] integrate signals from the entire software development life- cycle and apply retrieval-augmented in-context learning to enhance mitigation quality. Pouya et al. [9] model the natural workflow of on-call engineers using three LLM agents—hypothesis formation, hypothesis testing, and mitigation planning. Remediation Script Generation. These methods aim to produce executable scripts or code snippets that directly automate repair ac- tions. Xpert [17] generates tailored KQL queries for incident investi- gation. ShellGPT [43] fine-tunes GPT models for shell command rec- ommendation. Wisdom-Ansible [36] and MAPE-Ansible [41] gen- erate Ansible playbooks using fine-tuned or GPT-4-based MAPE-K architectures. WCA-Ansible [40] further pretrains a domain-specific model on natural language, source code, and Ansible data to en- hance playbook generation. Our work falls into this category, but differs in aiming for end-to-end microservice remediation without relying on human-written playbooks or static domain knowledge. 7.2 LLM-based Failure Management Large language models have recently been applied to enhance anomaly detection, failure diagnosis, and automated remediation in complex systems [56,57]. Existing efforts can be broadly grouped into foundation models, fine-tuning-based approaches, and prompt- driven methods. Foundation models for system data. A number of works aim to build LLM-style foundation models for time-series or log data. Representative examples include Lag-Llama [38], Timer [29], and TimesFM [4], which unify forecasting, imputation, and detection un- der transformer architectures. PreLog [20] and KAD-Disformer [48] extend this line to log parsing and multivariate anomaly detection. These models provide domain-specialized priors but are typically limited to a single modality. Fine-tuning general LLMs. Another line of work fine-tunes general-purpose LLMs for IT operations. Examples include UniTime [26], AnomalyLLM [25], and LogLM [27], which adapt GPT/LLaMA-style architectures for time-series forecasting, anom- aly detection, and log analytics. RAG4ITOps [69] and OWL [8] further incorporate retrieval or adapter tuning for interactive di- agnosis. These methods improve task specialization, but require extensive labeled data or careful adaptation. Our E2E-REME also falls into this category, but differs by integrating multi-stage rein- forcement fine-tuning for end-to-end remediation. Prompt-based methods. Prompt-based solutions avoid heavy fine-tuning by leveraging instruction design, chain-of-thought reasoning, or retrieval. RCACopilot [2], Xpert [17], and Las- RCA [10] design multi-step prompts for diagnosis and anomaly detection. LogGPT [28], LSTPrompt [24], and LM-PACE [51] im- prove interpretability through CoT or task decomposition. Retrieval- augmented approaches such as RAGLog [33], LogRAG [70] and XRAGLog [58] enhance log reasoning through case retrieval. While flexible, prompt-based methods often suffer from unstable genera- tion and limited end-to-end automation. E2E-REMEFSE Companion ’26, July 5–9, 2026, Montreal, QC, Canada 8 Conclusion In this paper, we introduce the task of end-to-end microservice remediation. To enable systematic evaluation, we construct Mi- croRemed, a challenging benchmark that automates microservice deployment, failure injection, playbook execution, and post-repair verification. To tackle this task, we propose E2E-REME, an end-to- end auto-remediation model for microservices based on experience- simulation reinforcement fine-tuning. Experimental results show that MicroRemed presents substantial challenges for existing LLMs, while E2E-REME achieves superior accuracy and efficiency on both MicroRemed and realistic industrial microservice environments. Acknowledgments This work is supported by Key RD Project of Guangdong Province, China (No.2020B010164003). References [1] Toufique Ahmed, Supriyo Ghosh, Chetan Bansal, Thomas Zimmermann, Xuchao Zhang, and Saravan Rajmohan. 2023. Recommending root-cause and mitigation steps for cloud incidents using large language models. In2023IEEE/ACM45th InternationalConferenceonSoftwareEngineering(ICSE). IEEE, 1737–1749. [2]Yinfang Chen, Huaibing Xie, Minghua Ma, Yu Kang, Xin Gao, Liu Shi, Yunjie Cao, Xuedong Gao, Hao Fan, Ming Wen, et al.2024. Automatic root cause analysis via large language models for cloud incidents. InProceedingsoftheNineteenth EuropeanConferenceonComputerSystems. 674–688. [3]Paul F Christiano, Jan Leike, Tom Brown, Miljan Martic, Shane Legg, and Dario Amodei. 2017. Deep reinforcement learning from human preferences.Advances inneuralinformationprocessingsystems 30 (2017). [4]Abhimanyu Das, Weihao Kong, Rajat Sen, and Yichen Zhou. 2024. A decoder- only foundation model for time-series forecasting. InForty-firstInternational ConferenceonMachineLearning. [5]Chiming Duan, Minghua He, Pei Xiao, Tong Jia, Xin Zhang, Zhewei Zhong, Xiang Luo, Yan Niu, Lingzhe Zhang, Yifan Wu, et al.2025. LogAction: Consistent Cross- system Anomaly Detection through Logs via Active Domain.arXivpreprint arXiv:2510.03288 (2025). [6]Drishti Goel, Fiza Husain, Aditya Singh, Supriyo Ghosh, Anjaly Parayil, Chetan Bansal, Xuchao Zhang, and Saravan Rajmohan. 2024. X-lifecycle Learning for Cloud Incident Management using LLMs.arXivpreprintarXiv:2404.03662(2024). [7]Google Cloud Platform. 2025. Online Boutique: A Cloud-First Microservices Demo Application. https://github.com/GoogleCloudPlatform/microservices- demo. Accessed: October 15, 2025. [8] Hongcheng Guo, Jian Yang, Jiaheng Liu, Liqun Yang, Linzheng Chai, Jiaqi Bai, Junran Peng, Xiaorong Hu, Chao Chen, Dongfeng Zhang, et al.2023. Owl: A large language model for it operations.arXivpreprintarXiv:2309.09298(2023). [9]Pouya Hamadanian, Behnaz Arzani, Sadjad Fouladi, Siva Kesava Reddy Kakarla, Rodrigo Fonseca, Denizcan Billor, Ahmad Cheema, Edet Nkposong, and Ranveer Chandra. 2023. A Holistic View of AI-driven Network Incident Management. In Proceedingsofthe22ndACMWorkshoponHotTopicsinNetworks. 180–188. [10] Yongqi Han, Qingfeng Du, Ying Huang, Jiaqi Wu, Fulong Tian, and Cheng He. 2024. The Potential of One-Shot Failure Root Cause Analysis: Collaboration of the Large Language Model and Small Classifier. InProceedingsofthe39th IEEE/ACMInternationalConferenceonAutomatedSoftwareEngineering. 931– 943. [11]Minghua He, Chiming Duan, Pei Xiao, Tong Jia, Siyu Yu, Lingzhe Zhang, Weijie Hong, Jin Han, Yifan Wu, Ying Li, et al.2025. United we stand: Towards end-to- end log-based fault diagnosis via interactive multi-task learning.arXivpreprint arXiv:2509.24364 (2025). [12]Minghua He, Tong Jia, Chiming Duan, Pei Xiao, Lingzhe Zhang, Kangjin Wang, Yifan Wu, Ying Li, and Gang Huang. 2025.Walk the Talk: Is Your Log- based Software Reliability Maintenance System Really Reliable?arXivpreprint arXiv:2509.24352 (2025). [13] Lorin Hochstein and Rene Moser. 2017.Ansible:UpandRunning:Automating configurationmanagementanddeploymenttheeasyway. " O’Reilly Media, Inc.". [14]Weijie Hong, Yifan Wu, Lingzhe Zhang, Chiming Duan, Pei Xiao, Minghua He, Xixuan Yang, and Ying Li. 2025. CSLParser: A Collaborative Framework Using Small and Large Language Models for Log Parsing. In2025IEEE36th InternationalSymposiumonSoftwareReliabilityEngineering(ISSRE). IEEE, 61– 72. [15]Xiaosong Huang, Hongyi Liu, Yifan Wu, Lingzhe Zhang, Tong Jia, Ying Li, and Zhonghai Wu. 2025. UDA-RCL: Unsupervised Domain Adaptation for Microser- vice Root Cause Localization Utilizing Multimodal Data.IEEETransactionson ServicesComputing (2025). [16] Information Technology Intelligence Consulting (ITIC). 2024.ITIC2024Global ServerHardware,ServerOSReliabilityReport. Annual Report. ITIC. [17] Yuxuan Jiang, Chaoyun Zhang, Shilin He, Zhihao Yang, Minghua Ma, Si Qin, Yu Kang, Yingnong Dang, Saravan Rajmohan, Qingwei Lin, et al.2024. Xpert: Empowering incident management with query recommendations via large lan- guage models. InProceedingsoftheIEEE/ACM46thInternationalConference onSoftwareEngineering. 1–13. [18] Sathvik Joel, Jie Wu, and Fatemeh Fard. 2024. A survey on llm-based code generation for low-resource and domain-specific programming languages.ACM TransactionsonSoftwareEngineeringandMethodology (2024). [19]Yuyuan Kang, Xiangdong Huang, Shaoxu Song, Lingzhe Zhang, Jialin Qiao, Chen Wang, Jianmin Wang, and Julian Feinauer. 2022. Separation or not: On handing out-of-order time-series data in leveled lsm-tree. In2022IEEE38thInternational ConferenceonDataEngineering(ICDE). IEEE, 3340–3352. [20]Van-Hoang Le and Hongyu Zhang. 2024. Prelog: A pre-trained model for log analytics.ProceedingsoftheACMonManagementofData 2, 3 (2024), 1–28. [21] Aixin Liu, Bei Feng, Bing Xue, Bingxuan Wang, Bochao Wu, Chengda Lu, Cheng- gang Zhao, Chengqi Deng, Chenyu Zhang, Chong Ruan, et al.2024. Deepseek-v3 technical report.arXivpreprintarXiv:2412.19437 (2024). [22]Hongyi Liu, Xiaosong Huang, Mengxi Jia, Lingzhe Zhang, Tong Jia, Zhonghai Wu, and Ying Li. 2025. AAAD: Asynchronous Inter-Variable Relationship-Aware Anomaly Detection for Multivariate Time Series. In2025IEEEInternational ConferenceonMultimediaandExpo(ICME). IEEE, 1–6. [23]Hongyi Liu, Yinping Ma, Xiaosong Huang, Lingzhe Zhang, Tong Jia, and Ying Li. 2025. ORA: Job Runtime Prediction for High-Performance Computing Platforms Using the Online Retrieval-Augmented Language Model. InProceedingsofthe 39thACMInternationalConferenceonSupercomputing. 884–894. [24]Haoxin Liu, Zhiyuan Zhao, Jindong Wang, Harshavardhan Kamarthi, and B Aditya Prakash. 2024. LSTPrompt: Large Language Models as Zero-Shot Time Series Forecasters by Long-Short-Term Prompting. InFindingsoftheAssociation forComputationalLinguisticsACL2024. 7832–7840. [25]Shuo Liu, Di Yao, Lanting Fang, Zhetao Li, Wenbin Li, Kaiyu Feng, XiaoWen Ji, and Jingping Bi. 2024. Anomalyllm: Few-shot anomaly edge detection for dynamic graphs using large language models.arXivpreprintarXiv:2405.07626 (2024). [26] Xu Liu, Junfeng Hu, Yuan Li, Shizhe Diao, Yuxuan Liang, Bryan Hooi, and Roger Zimmermann. 2024. Unitime: A language-empowered unified model for cross- domain time series forecasting. InProceedingsoftheACMWebConference2024. 4095–4106. [27] Yilun Liu, Yuhe Ji, Shimin Tao, Minggui He, Weibin Meng, Shenglin Zhang, Yongqian Sun, Yuming Xie, Boxing Chen, and Hao Yang. 2024.Loglm: From task-based to instruction-based automated log analysis.arXivpreprint arXiv:2410.09352 (2024). [28]Yilun Liu, Shimin Tao, Weibin Meng, Jingyu Wang, Wenbing Ma, Yuhang Chen, Yanqing Zhao, Hao Yang, and Yanfei Jiang. 2024. Interpretable online log analysis using large language models with prompt strategies. InProceedingsofthe32nd IEEE/ACMInternationalConferenceonProgramComprehension. 35–46. [29] Yong Liu, Haoran Zhang, Chenyu Li, Xiangdong Huang, Jianmin Wang, and Mingsheng Long. 2024. Timer: generative pre-trained transformers are large time series models. InProceedingsofthe41stInternationalConferenceonMachine Learning. 32369–32399. [30]Chaos Mesh. 2025. A powerful chaos engineering platform for kubernetes.URL: https://chaos-mesh.org (2025). [31]Zakeya Namrud, Komal Sarda, Marin Litoiu, Larisa Shwartz, and Ian Watts. 2024. Kubeplaybook: A repository of ansible playbooks for kubernetes auto- remediation with llms. InCompanionofthe15thACM/SPECInternational ConferenceonPerformanceEngineering. 57–61. [32]Ruben Opdebeeck, Ahmed Zerouali, and Coen De Roover. 2021. Andromeda: A dataset of Ansible Galaxy roles and their evolution. In2021IEEE/ACM18th InternationalConferenceonMiningSoftwareRepositories(MSR). IEEE, 580– 584. [33]Jonathan Pan, Wong Swee Liang, and Yuan Yidi. 2024. Raglog: Log anomaly detection using retrieval augmented generation. In2024IEEEWorldForumon PublicSafetyTechnology(WFPST). IEEE, 169–174. [34]Leyi Pan, Zheyu Fu, Yunpeng Zhai, Shuchang Tao, Sheng Guan, Shiyu Huang, Lingzhe Zhang, Zhaoyang Liu, Bolin Ding, Felix Henry, et al.2025. Omni- SafetyBench: A Benchmark for Safety Evaluation of Audio-Visual Large Language Models.arXivpreprintarXiv:2508.07173 (2025). [35] Leyi Pan, Shuchang Tao, Yunpeng Zhai, Zheyu Fu, Liancheng Fang, Minghua He, Lingzhe Zhang, Zhaoyang Liu, Bolin Ding, Aiwei Liu, et al.2025. d-TreeRPO: Towards More Reliable Policy Optimization for Diffusion Language Models.arXiv preprintarXiv:2512.09675 (2025). [36]Saurabh Pujar, Luca Buratti, Xiaojie Guo, Nicolas Dupuis, Burn Lewis, Sahil Suneja, Atin Sood, Ganesh Nalawade, Matt Jones, Alessandro Morari, et al.2023. Automated code generation for information technology tasks in yaml through FSE Companion ’26, July 5–9, 2026, Montreal, QC, CanadaLingzhe Zhang et al. large language models. In202360thACM/IEEEDesignAutomationConference (DAC). IEEE, 1–4. [37]Rafael Rafailov, Archit Sharma, Eric Mitchell, Christopher D Manning, Stefano Ermon, and Chelsea Finn. 2023. Direct preference optimization: Your language model is secretly a reward model.AdvancesinNeuralInformationProcessing Systems 36 (2023), 53728–53741. [38] Kashif Rasul, Arjun Ashok, Andrew Robert Williams, Arian Khorasani, George Adamopoulos, Rishika Bhagwatkar, Marin Biloš, Hena Ghonia, Nadhir Hassen, Anderson Schneider, et al.2023. Lag-llama: Towards foundation models for time series forecasting. InR0-FoMo:RobustnessofFew-shotandZero-shotLearning inLargeFoundationModels. [39]Youcef Remil, Anes Bendimerad, Romain Mathonat, and Mehdi Kaytoue. 2024. Aiops solutions for incident management: Technical guidelines and a compre- hensive literature review.arXivpreprintarXiv:2404.01363 (2024). [40]Priyam Sahoo, Saurabh Pujar, Ganesh Nalawade, Richard Genhardt, Louis Mandel, and Luca Buratti. 2024. Ansible lightspeed: A code generation service for it automation. InProceedingsofthe39thIEEE/ACMInternationalConferenceon AutomatedSoftwareEngineering. 2148–2158. [41]Komal Sarda, Zakeya Namrud, Marin Litoiu, Larisa Shwartz, and Ian Watts. 2024. Leveraging large language models for the auto-remediation of microservice ap- plications: An experimental study. InCompanionProceedingsofthe32ndACM InternationalConferenceontheFoundationsofSoftwareEngineering. 358–369. [42]Zhihong Shao, Peiyi Wang, Qihao Zhu, Runxin Xu, Junxiao Song, Xiao Bi, Haowei Zhang, Mingchuan Zhang, YK Li, Y Wu, et al.2024. Deepseekmath: Pushing the limits of mathematical reasoning in open language models.arXivpreprint arXiv:2402.03300 (2024). [43]Jie Shi, Sihang Jiang, Bo Xu, Jiaqing Liang, Yanghua Xiao, and Wei Wang. 2023. ShellGPT: Generative Pre-trained Transformer Model for Shell Language Un- derstanding. In2023IEEE34thInternationalSymposiumonSoftwareReliability Engineering(ISSRE). IEEE, 671–682. [44]Aditi Singh, Abul Ehtesham, Saket Kumar, and Tala Talaei Khoei. 2025. Agen- tic retrieval-augmented generation: A survey on agentic rag.arXivpreprint arXiv:2501.09136 (2025). [45]Kimi Team, Yifan Bai, Yiping Bao, Guanduo Chen, Jiahao Chen, Ningxin Chen, Ruijue Chen, Yanru Chen, Yuankun Chen, Yutian Chen, et al.2025. Kimi k2: Open agentic intelligence.arXivpreprintarXiv:2507.20534 (2025). [46] Zexin Wang, Jingjing Li, Quan Zhou, Haotian Si, Yuanhao Liu, Jianhui Li, Gaogang Xie, Fei Sun, Dan Pei, and Changhua Pei. 2025. A Survey on AgentOps: Cate- gorization, Challenges, and Future Directions.arXivpreprintarXiv:2508.02121 (2025). [47] An Yang, Anfeng Li, Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chang Gao, Chengen Huang, Chenxu Lv, et al.2025. Qwen3 technical report.arXivpreprintarXiv:2505.09388 (2025). [48] Zhaoyang Yu, Changhua Pei, Xin Wang, Minghua Ma, Chetan Bansal, Saravan Rajmohan, Qingwei Lin, Dongmei Zhang, Xidao Wen, Jianhui Li, et al.2024. Pre-trained kpi anomaly detection model through disentangled transformer. In Proceedingsofthe30thACMSIGKDDConferenceonKnowledgeDiscoveryand DataMining. 6190–6201. [49] Aohan Zeng, Xin Lv, Qinkai Zheng, Zhenyu Hou, Bin Chen, Chengxing Xie, Cunxiang Wang, Da Yin, Hao Zeng, Jiajie Zhang, et al.2025. Glm-4.5: Agentic, reasoning, and coding (arc) foundation models.arXivpreprintarXiv:2508.06471 (2025). [50]Yunpeng Zhai, Shuchang Tao, Cheng Chen, Anni Zou, Ziqian Chen, Qingxu Fu, Shinji Mai, Li Yu, Jiaji Deng, Zouying Cao, et al.2025. AgentEvolver: Towards Efficient Self-Evolving Agent System.arXivpreprintarXiv:2511.10395 (2025). [51] Dylan Zhang, Xuchao Zhang, Chetan Bansal, Pedro Las-Casas, Rodrigo Fon- seca, and Saravan Rajmohan. 2024. LM-PACE: Confidence estimation by large language models for effective root causing of cloud incidents. InCompanion Proceedingsofthe32ndACMInternationalConferenceontheFoundationsof SoftwareEngineering. 388–398. [52]Lingzhe Zhang, Liancheng Fang, Chiming Duan, Minghua He, Leyi Pan, Pei Xiao, Shiyu Huang, Yunpeng Zhai, Xuming Hu, Philip S Yu, et al.2025. A survey on parallel text generation: From parallel decoding to diffusion language models. arXivpreprintarXiv:2508.08712 (2025). [53]Lingzhe Zhang, Tong Jia, Weijie Hong, Mingyu Wang, Chiming Duan, Minghua He, Rongqian Wang, Xi Peng, Meiling Wang, Gong Zhang, et al.2026. RuntimeS- licer: Towards Generalizable Unified Runtime State Representation for Failure Management.arXivpreprintarXiv:2603.21495 (2026). [54] Lingzhe Zhang, Tong Jia, Mengxi Jia, Ying Li, Yong Yang, and Zhonghai Wu. 2024. Multivariate log-based anomaly detection for distributed database. In Proceedingsofthe30thACMSIGKDDConferenceonKnowledgeDiscovery andDataMining. 4256–4267. [55] Lingzhe Zhang, Tong Jia, Mengxi Jia, Hongyi Liu, Yong Yang, Zhonghai Wu, and Ying Li. 2024. Towards close-to-zero runtime collection overhead: Raft- based anomaly diagnosis on system faults for distributed storage system.IEEE TransactionsonServicesComputing (2024). [56]Lingzhe Zhang, Tong Jia, Mengxi Jia, Yifan Wu, Aiwei Liu, Yong Yang, Zhonghai Wu, Xuming Hu, Philip Yu, and Ying Li. 2025. A Survey of AIOps in the Era of Large Language Models.Comput.Surveys (2025). [57]Lingzhe Zhang, Tong Jia, Mengxi Jia, Yifan Wu, Hongyi Liu, and Ying Li. 2025. ScalaLog: Scalable Log-Based Failure Diagnosis Using LLM. InICASSP2025-2025 IEEEInternationalConferenceonAcoustics,SpeechandSignalProcessing (ICASSP). IEEE, 1–5. [58]Lingzhe Zhang, Tong Jia, Mengxi Jia, Yifan Wu, Hongyi Liu, and Ying Li. 2025. XRAGLog: A resource-efficient and context-aware log-based anomaly detec- tion method using retrieval-augmented generation. InAAAI2025Workshopon PreventingandDetectingLLMMisinformation(PDLM). [59] Lingzhe Zhang, Tong Jia, Xinyu Tan, Xiangdong Huang, Mengxi Jia, Hongyi Liu, Zhonghai Wu, and Ying Li. 2025. E-log: Fine-grained elastic log-based anomaly detection and diagnosis for databases.IEEETransactionsonServicesComputing (2025). [60] Lingzhe Zhang, Tong Jia, Kangjin Wang, Weijie Hong, Chiming Duan, Minghua He, and Ying Li. 2025. Adaptive Root Cause Localization for Microservice Systems with Multi-Agent Recursion-of-Thought.arXivpreprintarXiv:2508.20370(2025). [61]Lingzhe Zhang, Tong Jia, Kangjin Wang, Mengxi Jia, Yong Yang, and Ying Li. 2024. Reducing events to augment log-based anomaly detection models: An empirical study. InProceedingsofthe18thACM/IEEEInternationalSymposium onEmpiricalSoftwareEngineeringandMeasurement. 538–548. [62]Lingzhe Zhang, Tong Jia, Mingyu Wang, Weijie Hong, Chiming Duan, Minghua He, Rongqian Wang, Xi Peng, Meiling Wang, Gong Zhang, et al.2026. Efficient Failure Management for Multi-Agent Systems with Reasoning Trace Representa- tion.arXivpreprintarXiv:2603.21522 (2026). [63] Lingzhe Zhang, Tong Jia, Yunpeng Zhai, Leyi Pan, Chiming Duan, Minghua He, Mengxi Jia, and Ying Li. 2026. Agentic Memory Enhanced Recursive Reasoning for Root Cause Localization in Microservices.arXivpreprintarXiv:2601.02732 (2026). [64] Lingzhe Zhang, Tong Jia, Yunpeng Zhai, Leyi Pan, Chiming Duan, Minghua He, Pei Xiao, and Ying Li. 2026. Hypothesize-Then-Verify: Speculative Root Cause Analysis for Microservices with Pathwise Parallelism.arXivpreprint arXiv:2601.02736 (2026). [65]Lingzhe Zhang, Yunpeng Zhai, Tong Jia, Chiming Duan, Siyu Yu, Jinyang Gao, Bolin Ding, Zhonghai Wu, and Ying Li. 2025. ThinkFL: Self-Refining Failure Localization for Microservice Systems via Reinforcement Fine-Tuning.arXiv preprintarXiv:2504.18776 (2025). [66] Lingzhe Zhang, Yunpeng Zhai, Tong Jia, Xiaosong Huang, Chiming Duan, and Ying Li. 2025. Agentfm: Role-aware failure management for distributed databases with llm-driven multi-agents. InProceedingsofthe33rdACMInternational ConferenceontheFoundationsofSoftwareEngineering. 525–529. [67] Ling-Zhe Zhang, Xiang-Dong Huang, Yan-Kai Wang, Jia-Lin Qiao, Shao-Xu Song, and Jian-Min Wang. 2024. Time-tired compaction: An elastic compaction scheme for LSM-tree based time-series database.AdvancedEngineeringInformatics59 (2024), 102224. [68]Shenglin Zhang, Sibo Xia, Wenzhao Fan, Binpeng Shi, Xiao Xiong, Zhenyu Zhong, Minghua Ma, Yongqian Sun, and Dan Pei. 2024. Failure diagnosis in microservice systems: A comprehensive survey and analysis.ACMTransactionsonSoftware EngineeringandMethodology (2024). [69]Tianyang Zhang, Zhuoxuan Jiang, Shengguang Bai, Tianrui Zhang, Lin Lin, Yang Liu, and Jiawei Ren. 2024. RAG4ITOps: A Supervised Fine-Tunable and Com- prehensive RAG Framework for IT Operations and Maintenance. InProceedings ofthe2024ConferenceonEmpiricalMethodsinNaturalLanguageProcessing: IndustryTrack. 738–754. [70]Wanhao Zhang, Qianli Zhang, Enyu Yu, Yuxiang Ren, Yeqing Meng, Mingxi Qiu, and Jilong Wang. 2024. LogRAG: Semi-Supervised Log-based Anomaly Detection with Retrieval-Augmented Generation. In2024IEEEInternationalConference onWebServices(ICWS). IEEE, 1100–1102. [71]Zeyu Zhang, Quanyu Dai, Xiaohe Bo, Chen Ma, Rui Li, Xu Chen, Jieming Zhu, Zhenhua Dong, and Ji-Rong Wen. 2025. A survey on the memory mechanism of large language model-based agents.ACMTransactionsonInformationSystems 43, 6 (2025), 1–47. [72]Xiang Zhou, Xin Peng, Tao Xie, Jun Sun, Chao Ji, Wenhai Li, and Dan Ding. 2018. Fault analysis and debugging of microservice systems: Industrial survey, bench- mark system, and empirical study.IEEETransactionsonSoftwareEngineering 47, 2 (2018), 243–260. [73]Daniel M Ziegler, Nisan Stiennon, Jeffrey Wu, Tom B Brown, Alec Radford, Dario Amodei, Paul Christiano, and Geoffrey Irving. 2019. Fine-tuning language models from human preferences.arXivpreprintarXiv:1909.08593 (2019).