Non-intrusive cloud native fault injection method based on compilation period conditional isolation

Abstract

The invention discloses a non-intrusive cloud native fault injection method and device based on compilation period conditional isolation. The method comprises the following steps: declaring that a packet-level function variable points to real implementation in a service code, and indirectly calling through the variable; creating a fault simulation library to construct label isolation, executing a double-track construction process based on constructed labels, redirecting variables to fake implementation during test construction, and producing, constructing and eliminating a fault library; in fake implementation, atomic-scale refined fault semantics are defined based on configurable parameters; injection behaviors are controlled through a state machine model (including a fault injection state, a recovery decision point, a steady-state execution state and a process termination state); and integrating the audit logs and automatically checking the purity of the production binary system in the CI / CD. According to the method, zero residue of production codes and zero performance overhead are realized, accurate fault simulation and full-link auditing are supported, compliance and safety requirements of strong supervision scenes such as finance and government affairs are met, and an efficient scheme is provided for toughness verification of a cloud native system.

Description

Technical Field

[0001] This application relates to the fields of cloud-native software engineering, compiler technology and continuous delivery technology, and in particular to a non-intrusive cloud-native fault injection method, apparatus, computer-readable storage medium and electronic device based on compile-time conditional isolation. Background Technology

[0002] In cloud-native scenarios, fault injection technology is a key means of verifying system resilience. Existing technologies have formed three mainstream implementation paths around "fault triggering timing" and "injection level," covering the full-scenario requirements from the application layer to the infrastructure layer, as follows: 1. Runtime Interception: This approach dynamically intercepts the target system call chain by attaching runtime components (such as Sidecar proxies, bytecode enhancement proxies, and eBPF programs), injecting faults without modifying the business source code. Typical implementations include a service mesh layer (Istio / Linkerd), an application runtime layer (a partial ChaosBlade / ChaosMesh pattern combining a Java Agent with ASM / ByteBuddy), and a system kernel layer (chaos-ebpf based on eBPF hooking system calls / kernel functions). It is suitable for Java and some dynamic language applications that require rapid verification and where business code is difficult to modify.

[0003] 2. Code-embedded approach: Fault injection logic (simulating error returns, delays, and exception throwing) is hard-coded into the core business code using conditional branches, and triggered via external configuration switches (feature switches, configuration centers). Typical implementations include source code-level conditional branches (inserting `if config.InjectError` logic into business functions) and explicit API calls via framework integration SDKs. Suitable for scenarios requiring precise simulation of specific business logic (such as parameter validation failures or database query timeouts).

[0004] 3. Infrastructure Layer: This layer directly induces faults at the infrastructure resource level without intruding on application code or the runtime environment, focusing on simulating "resource unavailability" faults. Typical implementations include compute resources (Chaos Monkey randomly terminating Pods / virtual machines), network resources (NetworkPolicy / iptables / TC simulating interruptions / latency / packet loss), and storage resources (simulating disk I / O errors, read-only file systems, etc.). It is suitable for verifying the overall fault tolerance and self-healing capabilities of a system to underlying resource faults.

[0005] However, existing technologies still have many systemic shortcomings, such as difficulty in adapting to mainstream cloud-native technology stacks, difficulty in meeting the stringent compliance requirements of the financial / government sectors, and lack of feasibility for deployment in production environments. Specifically, these shortcomings are as follows: (1) High compliance risk and difficulty in ensuring code purity: The code is embedded in the production binary, violating the compliance requirement of "cleaning up debugging test code in the production environment"; runtime interception depends on eBPF kernel module, Sidecar and other components, increasing complexity and attack surface, and the approval and maintenance threshold is high.

[0006] (2) Incomplete technology stack coverage and poor cloud-native adaptation: Java Agent is limited to the JVM ecosystem and is difficult to cover statically compiled languages ​​such as Go / Rust / C++; eBPF requires deep customization for compiler optimization (such as Go 1.20+ symbol pruning), resulting in high adaptation costs and poor stability; the infrastructure layer cannot simulate complex business logic failures of the application layer.

[0007] (3) High runtime performance overhead: Interception introduces network latency / CPU overhead, becoming a bottleneck for high-concurrency core business performance; Even if the switch is turned off, the condition judgment still causes CPU branch prediction overhead.

[0008] (4) High deployment and maintenance complexity: It requires maintaining two independent configurations for testing and production, which can easily lead to distorted results; some solutions (such as JVM parameter loading Agent) change the standard build and deployment process, which is contrary to Kubernetes best practices.

[0009] (5) Insufficient fidelity of fault simulation and doubt about the effectiveness of testing: coarse-grained infrastructure / network layer faults make it difficult to accurately simulate complex anomalies at the application layer (such as specific APIs not having a 200 status code, or failure to write some records in the database); simple mock / fixed error returns for interception-based dependencies make it difficult to reproduce the extreme interactive states of real dependencies.

[0010] (6) Lack of traceability audit capability: The injected faults are similar to the logs / monitoring characteristics of real faults and lack context markers; most runtime solutions do not have unified audit logs, which does not meet the compliance requirements of "operations can be audited and responsibilities can be traced".

[0011] In summary, existing technologies face five major challenges: compliance, performance, adaptability, fidelity, and auditability. These challenges can be attributed to the following: source code-level injection of residual non-production code; poor adaptability and increased complexity of bytecode / binary interception; linker redirection (such as / / go:linkname) failing due to compiler optimization; and a lack of automated capabilities to prove the purity of production code, making it difficult to form a closed-loop verification system through manual auditing. Summary of the Invention

[0012] To address the aforementioned issues, this application proposes a novel non-intrusive cloud-native fault injection method and apparatus based on compile-time conditional isolation. More specifically, this invention provides a non-intrusive fault injection method for cloud-native platforms such as Kubernetes, which verifies the purity of production code. This method ensures that all fault injection logic is completely removed from production environment binary files through compile-time polymorphic construction and automated purity verification mechanisms, meeting the compliance requirements for production code security and auditability in highly regulated fields such as finance and government.

[0013] To achieve the above objectives, the present invention employs the following technical strategies: 1. Source code-level indirect API call mechanism Core principle: In business code, key call points (such as database access and external API calls) are declared as package-level function variables, which by default point to the actual implementation, thus achieving non-intrusive instrumentation.

[0014] Key implementation: The system architecture is based on indirect interface calls and conditional compilation, integrating four technologies: "declaration of indirect interface calls in business code", "building a fake implementation library with isolated tags", "dual-track construction process" and "structured audit output".

[0015] Non-intrusive instrumentation method: Abstract function calls into package-level variables, and insert test stubs without modifying business logic through variable declaration, initialization and calling conventions.

[0016] Value: Provides a unified, compile-time replaceable abstract interface, maintaining the purity of business code.

[0017] 2. Dual-track isolation and reuse architecture during build Core principle: Utilizing build tags such as / / go:build, we achieve "one set of source code, two sets of binary code" during compilation.

[0018] Key implementation: During test builds, the indirect API calls point to a fake implementation containing fault logic; during production builds, the API calls point to a clean, real implementation, and the fake code is physically removed during compilation.

[0019] Value: The framework logic reuse and the production of absolutely pure binary data are unified.

[0020] 3. Verifiable zero-residue guarantee mechanism Core: The CI / CD pipeline integrates automated verification devices (such as binary string scanning) to enforce access control checks on production build artifacts.

[0021] Key implementation: Adopting a zero-residual fault code construction and verification method for the production environment, the compiler physically removes fault injection and audit logic by building tags, and is equipped with an automated scanning and verification process for the purity of production binary.

[0022] Value: Automated generation of objective evidence chains with "zero test code residue" to meet compliance audit requirements.

[0023] 4. Atomic task-level fine-grained semantic injection Core: Provides fine-grained control strategies within the fake implementation, such as "first call failure", "delay for the first N times", and "random error based on sequence number".

[0024] Key implementation: Employs a declaratively configurable, fine-grained fault semantic control method. The fake implementation allows for declarative configuration of context-sensitive behaviors such as call sequence, number of calls, and parameters, including trigger condition definition and evaluation logic.

[0025] Value: Simulates complex stateful fault scenarios, accurately covers edge cases, and surpasses simple "switch" injection.

[0026] 5. A fully traceable audit system Core: Injects version integration structured audit logs, automatically recording context such as operator, execution time, fault type, and scope of impact.

[0027] Key implementation: Adopt a full-chain audit tracing method for testing activities, define standardized formats for audit events, collect information in real time, and automatically generate audit reports.

[0028] Value: Enables auditable and traceable testing throughout the entire process, meeting the compliance requirements of financial and government regulatory authorities.

[0029] 6. Compile-time embedded audit identification mechanism Core: By embedding audit information such as version identifier, build time, and operator into the binary data through construction parameters and compile-time constants, an unalterable audit source is formed.

[0030] Key implementation: A fault source identification method based on compiler tags is adopted, which embeds compiler tags (such as the [INJECTED_FAULT] prefix) in the error message to distinguish between injected faults and real faults at runtime.

[0031] Value: Ensures traceability of testing activities from their source, supporting end-to-end accountability.

[0032] Specifically, this application provides the following technical solutions: The first aspect of this application provides a non-intrusive cloud-native fault injection method based on compile-time conditional isolation, such as... Figure 5 As shown, the method includes: S1. In the business code, declare the key call points as package-level function variables, which by default point to the actual business implementation function. The business logic is indirectly called through the package-level function variables. S2. Create an independent fault simulation library, physically isolate the fault simulation library from the business code library by constructing tags; execute a two-track build process based on the constructed tags: during test build, redirect the package-level function variables to the fake implementation functions in the fault simulation library; during production build, exclude the fault simulation library and the redirection logic, and the package-level function variables remain pointing to the real business implementation functions; S3. In the fake implementation functions, define atomic-level refined fault semantics based on configurable parameters, supporting conditional control of the number of faults, probability, and recovery mode; S4. When performing fault injection, control the behavior through a state machine model, including: in the fault injection state, inject faults probabilistically and record the number of times; at the recovery decision point, check the recovery configuration after reaching the maximum number of times; in the steady-state execution state, call the real function; in the process termination state, terminate the process; S5. Integrate structured audit logs to record the test context, and verify the purity of the production binary through automated verification in the CI / CD pipeline to generate an auditable evidence chain.

[0033] Furthermore, in the method of the present application, in step S1, the key call points include database access and external API calls; the package-level function variables are declared as public or private variables, and the business logic is implemented by calling variables rather than directly calling implementation functions.

[0034] Furthermore, in the method of the present application, in step S2, the build tags use the / / go:build syntax, the test build tag is chaos, and the production build does not carry tags; the redirection logic is implemented through conditional compilation files, which are included during test build and excluded during production build.

[0035] Furthermore, in the method of the present application, in step S3, the configurable parameters include: maximum number of faults (MaxFailures), fault probability (FailureProbability), recoverable or not (Recoverable), fault code (FaultCode), recovery action (RecoveryAction); the refined fault semantics support "first call fails", "delay for the first N times", and "random error based on sequence number".

[0036] Furthermore, in the method of the present application, in step S4, the state machine model includes four states: Fault injection state: when the number of calls ≤ MaxFailures and the fault count < MaxFailures, inject faults with a FailureProbability probability, and the fault count is incremented; Recovery decision point: When the failure count = MaxFailures, check the Recoverable configuration. If true, enter the steady-state execution state; if false, enter the process termination state. Steady execution state: When Recoverable=true, calling the real function will no longer inject faults; Process termination state: When Recoverable=false, a termination error is returned and a rollback is triggered.

[0037] Furthermore, in the method of this application, in step S5, the structured audit log records the operator, execution time, fault type, scope of impact, and state transition information; the automated verification includes symbol table scanning, string table checking, and metadata verification.

[0038] Furthermore, the method of this application also includes: a fault recovery strategy configuration step: setting the number of faults, retry behavior, recovery mode parameters, verifying the fault tolerance capability of the workflow, and supporting fully recoverable, conditionally recoverable, unrecoverable, and skip recovery modes.

[0039] A second aspect of this application provides a non-intrusive cloud-native fault injection device based on compile-time conditional isolation. When the device operates, it implements the steps of the aforementioned non-intrusive cloud-native fault injection method based on compile-time conditional isolation, such as... Figure 6 As shown, this device includes: The indirect call interface module is used to declare key call points as package-level function variables in business code. By default, these variables point to the actual business implementation functions, and the business logic calls them indirectly through these package-level function variables. A tag control module is built to create an independent fault simulation library. The fault simulation library is physically isolated from the business code library by building tags. A dual-track build process is executed based on the building tags: during test build, the package-level function variables are redirected to fake implementation functions in the fault simulation library; during production build, the fault simulation library and redirection logic are excluded, and the package-level function variables continue to point to the real business implementation functions. The fault injection module is used to define atomic-level fine-grained fault semantics based on configurable parameters in the fake implementation function, and supports conditional control of fault count, probability, and recovery mode. The state machine control module is used to control behavior through a state machine model when performing fault injection, including: fault injection state injecting faults according to probability and recording the number of times; checking the recovery configuration after the recovery decision point reaches the maximum number of times; steady-state execution state calling the real function; and process termination state terminating the process. The audit and verification module is used to integrate structured audit logs to record test contexts and automatically verify the purity of production binary data in the CI / CD pipeline, generating an auditable chain of evidence.

[0040] A third aspect of this application provides an electronic device, including: a memory and a processor; Memory: Used to store computer programs; Processor: Used to execute the computer program to implement the steps of the aforementioned non-intrusive cloud-native fault injection method based on compile-time conditional isolation.

[0041] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the steps of the aforementioned non-intrusive cloud-native fault injection method based on compile-time conditional isolation.

[0042] In summary, compared with the prior art, the solution of the present invention has the following technical advantages: I. Core Technology Value 1. Production environment security assurance: Through the physical isolation mechanism during compilation, fault injection code is completely eliminated during production build, and there are no test logic residues in the production binary, achieving binary-level purity and addressing core compliance concerns from the technical root.

[0043] 2. Stable and lossless performance: The production version eliminates conditional branches and runtime interception, ensuring a pure execution path and zero performance loss, making it suitable for high-performance and sensitive scenarios such as financial transactions and government services.

[0044] 3. High accuracy of fault simulation: Supports atomic-level fault semantics such as "failure only on the first time", "delay of the first N times", and "parameterized failure", accurately simulates application layer business logic errors, reproduces real anomalies, and has high fidelity of test results.

[0045] 4. Unified development and operation experience: Adopting a single-repository dual-track build mode, version generation is controlled by build tags, eliminating the need to maintain multiple code branches, avoiding merge conflicts and version synchronization issues, and reducing management complexity.

[0046] II. Operation and Economic Benefits 1. Significantly reduced operational complexity: A codebase can be versioned by building tags, reducing operational complexity by 40%-60%.

[0047] 2. Production risks are fundamentally eliminated: fault logic is physically removed during compilation, there is no test code in the production version, and the risk of accidental triggering is reduced by more than 80%.

[0048] 3. Comprehensive improvement in R&D efficiency: High-fidelity simulation helps in early defect discovery, atomic-level injection supports rapid problem reproduction, the entire process is optimized, and the average problem repair time is shortened.

[0049] III. Security and Compliance Advantages 1. Independent and controllable technology stack: It does not rely on third-party components such as eBPF kernel module and Sidecar proxy, avoids external security risks, and meets the independent and controllable requirements of key industries.

[0050] 2. Automated compliance verification system: Automatically verifies code purity through binary string scanning, integrates CI / CD pipeline, and generates an auditable chain of evidence with each build.

[0051] 3. Full traceability of testing activities: Structured audit logs record the testing context (operator, time, fault type, etc.), meeting regulatory traceability requirements.

[0052] 4. Clear and well-defined permission boundaries: Build engineer-controlled injection capabilities, operation and maintenance engineers-controlled deployment, and separation of responsibilities to reduce internal risks.

[0053] IV. Architecture and Engineering Extension Value 1. Non-intrusive architecture design: Business code has no test branches / annotations, maintaining purity and readability, and reducing maintenance costs and technical debt.

[0054] 2. Broad technology compatibility: Based on the compiler's tagging mechanism, it is naturally compatible with statically compiled languages ​​such as Go, Rust, and C / C++, covering the mainstream cloud-native technology stack.

[0055] 3. Platform-based reusability: Encapsulated as standardized SDK modules or build plugins, it is plug-and-play and supports reuse by multiple teams and the accumulation of technical assets.

[0056] 4. Support modern engineering practices: Deeply integrates the DevSecOps concept, aligning with cloud-native evolution directions such as immutable infrastructure and continuous verification.

[0057] V. Industry Application Value It provides feasible resilience verification solutions for strictly regulated industries such as finance, government affairs, and telecommunications, supporting digital transformation while balancing high security and compliance with engineering practicality. Attached Figure Description

[0058] To more clearly illustrate the technical solution of this application, the accompanying drawings involved in the description of this invention will be briefly introduced below.

[0059] Figure 1 This is a flowchart illustrating the system architecture and polymorphic construction of the embodiments of this application.

[0060] Figure 2This is a schematic diagram illustrating the compiler-time function variable redirection principle of the embodiment of this application.

[0061] Figure 3 is a closed-loop diagram of the CI / CD pipeline integrating automated purity verification in the embodiments of this application, including: Figure 3a - Working principle of the core detection engine (technical principle diagram); Figure 3b - Closed-loop CI / CD pipeline with integrated compliant access control (process implementation diagram); Figure 3c - End-to-end automated compliance governance framework (architecture overview).

[0062] Figure 4 is a flowchart of the fault injection decision and fault recovery execution process of the embodiment of this application, including: Figure 4a - Fault injection phase (before reaching the maximum number of faults); Figure 4b - Fault recovery and termination decision-making process (after reaching the maximum number of faults).

[0063] Figure 5 This is a flowchart illustrating the overall implementation process of the cloud-native fault injection method in this application.

[0064] Figure 6 This is a structural diagram of the cloud-native fault injection device of this application. Detailed Implementation

[0065] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0066] In this document, the term "including" and any variations thereof (such as "including," "including," etc.) are open-ended expressions and should be understood as "including but not limited to," meaning that the listed content is not an exhaustive list and may include other content not explicitly mentioned. The term "based on" should be understood as "at least partially based on," meaning that the basis or condition referred to may not be the only factor and may involve other relevant factors.

[0067] A non-intrusive cloud-native fault injection method based on compile-time conditional isolation The core of this invention lies in the combination of "compile-time polymorphic construction" and "indirect interface calling", and introduces a configurable fault recovery strategy mechanism to support the resilience of testing complex workflows.

[0068] The overall design includes: 1. Non-intrusive instrumentation: In the business code, key call points are abstracted into package-level function variables, and the business logic is always indirectly called through these variables.

[0069] 2. Conditional isolation fault injection implementation: Create an independent fault simulation library and mark it with custom build tags.

[0070] 3. Configurable fault recovery strategy: Introduces fault recovery strategy configuration, supports setting parameters such as the number of failures, retry behavior, and recovery mode for each task, and verifies the fault tolerance capability of the workflow.

[0071] 4. Polymorphic compilation output: Production build: No fault injection tags are used; the compiler excludes all faulty library code.

[0072] Injection Build: Use the Fault Injection tag to generate test binaries with precise fault injection capabilities.

[0073] 5. Workflow resilience verification: Supports testing the fault recovery capability of the task chain, including the continuation of execution for recoverable faults and the termination of the process for unrecoverable faults.

[0074] 6. Automated Purity Verification: Perform automated scanning and verification of production build products in the CI / CD pipeline.

[0075] This invention employs an enhanced fault recovery strategy model, which, by introducing configurable fault recovery strategies, supports testing the complete resilience of the workflow.

[0076] Recovery mode classification: Fully recoverable: After the maximum number of failures is reached, normal execution resumes and downstream tasks continue.

[0077] Conditions are recoverable: Whether to recover depends on the type of failure and the context.

[0078] Unrecoverable: The entire workflow is terminated and a rollback mechanism is triggered when the failure reaches the threshold.

[0079] Skip recovery: After a failure, skip the current task and continue executing downstream tasks.

[0080] Four-state model for fault injection:

[0081] Parameter definition:

[0082] Technical advantages: 1. Zero business intrusion, transparent development Without modifying business code or embedding test branches, developers can code in the usual way, while testers can inject faults at compile time through build tags, achieving complete decoupling between testing and business logic.

[0083] 2. Production is absolutely pure and safe. Fault injection code is physically removed through compile-time build tags, resulting in zero residual code in the generated binary. Combined with automated verification methods such as symbol table scanning and string checking, a chain of technical evidence is formed, completely eliminating the risk of accidental triggering of test logic.

[0084] 3. The test scenarios are refined and comprehensive. It supports simulation of complex modes such as recoverable faults and condition-dependent faults, covering resilience verification from atomic tasks to the entire chain. Structured audit logs record the fault lifecycle, providing detailed traceability of test results.

[0085] 4. Compliance-friendly, meeting stringent regulatory requirements. Automated verification technology replaces manual auditing, generating reproducible compliance evidence and ensuring auditable operations and traceable accountability. Verification access control within the CI / CD pipeline forms a closed-loop quality control system, adapting to the requirements of highly regulated sectors such as finance and government.

[0086] 5. Zero performance overhead at runtime The production environment has no residual test logic, eliminating all conditional statements and proxy calls. A pure compile-time decision-making mechanism ensures full performance of core business logic without any runtime overhead.

[0087] Overall application value:

[0088] Through its core innovation of compile-time conditional isolation, this invention achieves the seemingly contradictory technical goal of "providing comprehensive fault injection testing capabilities while ensuring absolute production safety." Fault code is physically isolated at compile time, precise fault simulation is provided at runtime, and complete resilience verification is completed at the workflow level. Ultimately, this ensures that the production environment obtains absolutely clean binary files, providing a completely new technical paradigm for the secure evolution of cloud-native systems under highly regulated environments.

[0089] To more clearly illustrate the technical solution of this application, the following will provide further explanation through specific scenario embodiments.

[0090] Example: Fault Injection Deployment Instance for Hive Cluster Based on Compile-Time Condition Isolation 1. Core Architecture and Fault Injection Principles 1.1 Non-intrusive indirect call design The core idea is that business logic calls functions indirectly through function variables, rather than directly calling the specific implementation functions. This provides a unified "instrumentation point" for compile-time redirection.

[0091] / / dao / dao.go - Production code (never includes test logic) package dao / / Explicit package declaration to ensure that variables in dao_inject.go are accessible within the same package import "fmt" / / Publicly available actual business functions (first letter capitalized) func CreateMysqlDatabaseReal() error { fmt.Println("[PROD] MySQL database created successfully") return nil } func CreateDatabaseUserReal() error { fmt.Println("[PROD] Database user created successfully") return nil } func InitHiveMetastoreReal() error { fmt.Println("[PROD] Initialization of Hive Metastore successful") return nil } / / Indirectly call the interface (in production environments, this defaults to the publicly available implementation). / / Declare as a package-level variable, with the first letter capitalized for export (if cross-package access is required), or lowercase to keep it private within the package.

[0092] var ( CreateMysqlDatabaseFunc func() error = CreateMysqlDatabaseReal CreateDatabaseUserFunc func() error = CreateDatabaseUserReal InitHiveMetastoreFunc func() error = InitHiveMetastoreReal ) / / Business logic code always calls API variables: / / err := dao.CreateMysqlDatabaseFunc() / / I don't care about the specific implementation 1.2 Compile-time conditional redirection mechanism Key file: dao / dao_inject.go (compiles only for test builds) / / go:build chaos / / Build tag: This file is only included in test builds package dao import "hive-cluster / inject" func init() { / / Redirect the production interface to the fault injection implementation CreateMysqlDatabaseFunc = inject.CreateMysqlDatabaseFake CreateDatabaseUserFunc = inject.CreateDatabaseUserFake InitHiveMetastoreFunc = inject.InitHiveMetastoreFake } Compilation behavior: Production build: `go build -tags""` or `go build → dao_inject.go` is physically excluded by the compiler, and the interface variable continues to point to the `Real` function.

[0093] Test build: go build -tags chaos → Includes redirection logic, and the interface variable points to the function in the inject package.

[0094] 1.3 Polymorphic Behavior of Fault Injection Functions Each fault injection function in inject / faults.go implements the same pattern: / / go:build chaos / / This file is only included in builds tagged with "chaos". package inject import “your-project / dao” func CreateMysqlDatabaseFake() error { return executeWithFault("CreateMysqlDatabase", func() error { / / Call the actual public function return dao.CreateMysqlDatabaseReal() }) } func CreateDatabaseUserFake() error { return executeWithFault("CreateDatabaseUser", func() error { return dao.CreateDatabaseUserReal() }) } func InitHiveMetastoreFake() error { return executeWithFault("InitHiveMetastore", func() error { return dao.InitHiveMetastoreReal() }) } During production builds (without the `chaos` tag), the entire inject package is not compiled, therefore a `stub_prod.go` placeholder file is unnecessary. The compiler only processes code that is directly or indirectly referenced; unreferenced inject packages are naturally ignored, conforming to Go compilation standards.

[0095] 2. Injection logic for three fault scenarios 2.1 Task 1: CreateMysqlDatabase() - Database creation failure Fault configuration: { TaskName: "CreateMysqlDatabase", MaxFailures: 1, / / Maximum of 1 failure Recoverable: true, / / Recoverable FailureProbability: 100, / / 100% trigger rate (for testing purposes) FaultCode: "CHAOS_DB_CONNECTION", RecoveryAction: "retry_connection", } Injection logic: Execution flow (MaxFailures=1, Recoverable=true) First call (fault injection state): Fault count = 0, not reached the upper limit (1) 100% probability of triggering a fault → Injecting a "database connection failed" error. The fault count increased to 1 Return: CHAOS_DB_CONNECTION Second call (restoring the decision point → steady-state execution state): Fault count = 1, upper limit reached (1) Checking Recoverable=true → Entering steady-state execution state Call the actual CreateMysqlDatabaseReal() function Return: Success (or genuine error) Subsequent calls (steady-state execution): The fault count remains at 1, having reached the upper limit. Calling the actual function → Normal execution Simulated scenario: Database connection pool full Network temporarily unavailable Permission verification failed (can be fixed) 2.2 Task Two: CreateDatabaseUser() - User Permission Failure Fault configuration: { TaskName: "CreateDatabaseUser", MaxFailures: 2, / / Maximum of 2 failures Recoverable: false, / / Unrecoverable FailureProbability: 100, / / 100% chance of triggering a failure on every call (up to the limit) FaultCode: "CHAOS_USER_PERM_DENIED", } Injection logic: Execution flow (MaxFailures=2, Recoverable=false) First call (fault injection state): Fault count = 0, not reached the upper limit (2) 100% probability of triggering a fault → Injecting an "Insufficient user privileges" error. The fault count increased to 1 Returns: CHAOS_USER_PERM_DENIED Second call (fault injection state): Fault count = 1, not reached the upper limit (2) 100% probability of triggering a fault → Injecting an "Insufficient user privileges" error. The fault count has increased to 2. Returns: CHAOS_USER_PERM_DENIED Third call (Restoring decision point → Process termination state): Fault count = 2, the upper limit has been reached (2). Checking Recoverable=false → Entering process termination state Return: Retry limit exceeded, process interrupted (2 retries reached). Trigger workflow rollback mechanism Simulated scenario: The user already exists and cannot be overwritten. Access control policy conflict Password policy violation 2.3 Task 3: InitHiveMetastore() - Dependency initialization failure Fault configuration: { TaskName: "InitHiveMetastore", MaxFailures: 1, Recoverable: true, FailureProbability: 50, / / 50% probability of failure FaultCode: "CHAOS_METASTORE_CONNECT_FAIL", RecoveryCondition: "database_ready&&user_ready", / / Depends on the first two tasks RecoveryAction: "retry_connection", SimulatedScenario: "Hive Metastore service startup delay or connection timeout" } Injection logic: Execution flow (MaxFailures=1, Recoverable=true) First call: ↓ Fault count = 0, not reached the upper limit (1) ↓ Check RecoveryCondition: database_ready&&user_ready ├─ Condition not met → Returns "Prerequisites not ready" error └─ Conditions met → 50% probability decision ├─ Triggering a fault → Injecting a "Metastore connection timeout" error │ ↓ Fault count increased to 1 │ ↓ Returns: CHAOS_METASTORE_CONNECT_FAIL └─ No fault triggered → Call the real InitHiveMetastoreReal() Second call (if the first call fails and the service retryes): ↓ Fault count = 1, upper limit reached (1) ↓ Check Recoverable=true → Perform recovery ↓ Check RecoveryCondition: database_ready&&user_ready ├─ Condition not met → Returns "Prerequisites not ready" error └─ Condition met → Call the actual InitHiveMetastoreReal() function Simulated scenario: Metastore service starts slowly, connection times out. Network temporarily unavailable, port not ready. The service process is starting. 3. Execution paths of the three workflows Process 1: Ideal Success Path (Production Version) Production build (untagged) → Compile to exclude all injected code and dao_inject.go ↓ CreateMysqlDatabaseFunc → points to CreateMysqlDatabaseReal() → successful ↓ CreateDatabaseUserFunc → points to CreateDatabaseUserReal() → successful ↓ InitHiveMetastoreFunc → points to InitHiveMetastoreReal() → succeeded ↓ Hive cluster deployment completed. Features: All function calls are actually implemented. No fault logic The binary file is clean and verifiable. Process 2: Recoverable Fault Path (Test Scenario A) Test build → Includes fault injection logic ↓ CreateMysqlDatabaseFunc → CreateMysqlDatabaseFake() Fault 1: Database connection failed (recoverable) ↓ Business retry → Second call ↓ Recovery: Calling the actual CreateMysqlDatabaseReal() function → Success ↓ CreateDatabaseUserFunc → CreateDatabaseUserFake() ↓ Fault-free configuration → Directly call the actual CreateDatabaseUserReal() → Success ↓ InitHiveMetastoreFunc → InitHiveMetastoreFake() ↓ 50% chance of failure: Not triggered → Call the actual InitHiveMetastoreReal() → Success ↓ Deployment complete, retry mechanism verified. Verification point: Retry capability for temporary failures Continue execution after the fault is resolved Downstream tasks are unaffected Process 3: Unrecoverable Interrupted Path (Test Scenario B) Test build → Includes fault injection logic ↓ CreateMysqlDatabaseFunc → CreateMysqlDatabaseFake() ↓ Configuration: MaxFailures=0 → No failures ↓ Calling the actual CreateMysqlDatabaseReal() function → Success ↓ Log: Database created (requires rollback) ↓ CreateDatabaseUserFunc → CreateDatabaseUserFake() ↓ Configuration: Recoverable=false, MaxFailures=2 Fault 1: Insufficient permissions (first call) ↓ Business retry → Second call Fault 2: Insufficient permissions (second call, reaching the MaxFailures limit) ↓ The service retried again → Third call ↓ Based on the Recoverable=false configuration, a "Retry limit exceeded" error is returned. ↓ Triggering the rollback process ↓ Clean up: Delete the databases that have been created. ↓ Log: Rollback complete ↓ The process terminates and InitHiveMetastoreFunc is not executed. ↓ Verify the integrity of the rollback mechanism Verification point: Identification of unrecoverable faults Workflow safety interruption Resource cleanup (no residue) Rollback integrity Process 4: Conditional Dependency Path (Test Scenario C) Test build → Includes fault injection logic ↓ CreateMysqlDatabaseFunc → CreateMysqlDatabaseFake() ↓ Configuration: Recoverable=true, MaxFailures=1 Fault 1: Database connection timed out ↓ Business retry → Second call ↓ Fault limit reached → Resume execution → Success ↓ Set status: database_ready = true ↓ CreateDatabaseUserFunc → CreateDatabaseUserFake() ↓ Configuration: Recoverable=true, MaxFailures=1, RecoveryCondition="database_ready==true" ↓ Check condition: database_ready == true ✓ Fault 1: User creation conflict ↓ Business retry → Second call ↓ Fault limit reached → Resume execution → Success ↓ Set status: user_ready = true ↓ InitHiveMetastoreFunc → InitHiveMetastoreFake() ↓ Configuration: Recoverable=true, MaxFailures=1, RecoveryCondition="database_ready&&user_ready" ↓ Check conditions: database_ready && user_ready ✓ Fault 1: Metastore connection timed out ↓ Business retry → Second call ↓ Fault limit reached → Execute recovery action: retry_connect ↓ Calling the actual implementation → Success ↓ Verify the recovery capability of the complete dependency chain. Verification point: Transitive dependencies between tasks Conditional recovery mechanism Complex link failure propagation Intelligent recovery strategy 4. Fault Injection State Machine Model Each fault injection function internally implements the same state machine: State machine: Task execution → Fault decision → Recovery processing Execution process: Start execution ↓ Read task configuration ↓ Have you reached the maximum number of fault checks? ├─ Yes → Enter the recovery decision point │ ↓ │ Check Recoverable configuration │ ├─ true → Enter steady-state execution state → Call the actual function │ └─ false → Enter process termination state → Return interruption error │ └─ No → Enter fault injection state ↓ Whether to inject faults is determined by probability. ├─ Injection failure → Record number of failures → Return error message └─ No fault injection → Call the actual function Key features: Atomicity: Using atomic operations ensures concurrency safety. Configurability: Each task can be configured independently. Persistent state: The number of failures accumulates over the task's lifecycle. Recovery Intelligence: Determines recovery behavior based on configuration. 5. Technical Implementation of Compile-Time Isolation 5.1 The Magic of Creating Tags / / inject / faults.go (and all files under the inject package) / / go:build chaos package inject / / ... Fault injection implementation Compilation result: `go build` or `go build -tags""` → excludes the entire inject package and `dao_inject.go`.

[0096] `go build -tags inject` → This command includes the inject package and `dao_inject.go`.

[0097] 5.2 The role of production placeholder files During production builds, dao_inject.go is excluded, and these functions are not called. However, these function declarations must exist to meet compiler requirements. Compiler optimizations remove these empty functions that will never be called. / / go:build !chaos package inject / / Empty implementation, meets compilation requirements but has no practical function. func CreateMysqlDatabaseFake() error { return nil} func CreateDatabaseUserFake() error { return nil} func InitHiveMetastoreFake() error { return nil} 6. Audit and Compliance Verification 6.1 Structured Audit Output Each fault injection function generates standardized audit logs: { "task": "CreateMysqlDatabase", "phase": "fault_injection", / / Fault injection phase "result": "injected", / / Injection result "fault_code": "CHAOS_DB_CONNECTION", "attempt": 1, / / Number of attempts "failures": 1, / / Cumulative failures "max_failures": 1, / / Maximum allowed "recoverable": true, / / Whether it can be recovered "timestamp": "2024-01-15T10:30:01Z" } 6.2 Purity Verification Techniques Production build verification script: # 1. Symbol table scan: Ensure no injected function symbols are present. go tool nm hive-prod 2> / dev / null | grep –E "CreateMysqlDatabaseFake|CreateDatabaseUserFake|InitHiveMetastoreFake|inject" # 2. String table check: Ensure no error codes are found. strings hive-prod | grep "CHAOS_" # 3. Build metadata validation: Ensure no chaos tags are present go version -m hive-prod | grep chaos # 4. Runtime verification: Execution confirms no test output. . / hive-prod | grep -i "inject\|chaos\|fake" 7. Code organization suggestions project / ├── dao / │ ├── dao.go # Production code (exposing real functions + interface variables) │ └── dao_inject.go # Conditional compilation file ( / / go:build inject) ├── inject / # Fault injection package │ └── faults.go # Fault injection implementation ( / / go:build inject) │ └── config.go # Fault configuration loading logic ( / / go:build inject) │ └── executor.go # Implementation of the executeWithFault state machine ( / / go:buildinject) ├── config / │ └── faults.yaml # Fault configuration file (JSON / YAML, embedded at build time or read at runtime) └── cmd / └── main.go # Main program entry point, calls functions through dao package interface variables Figure 1 This is a system architecture and polymorphic construction flowchart for the solution in this embodiment. The diagram clearly shows the architecture centered around a single code repository. The repository contains three types of modules: Core business module: using default tags, containing business logic and declarations of indirect API calls.

[0098] Redirecting modules: Use the `chaos` tag to include only during test builds.

[0099] Fault injection implementation module: using the chaos tag, it contains all fault simulation logic.

[0100] During the build process, depending on whether the `-tags chaos` parameter is passed in, the Go toolchain selects different compilation paths, ultimately producing production and test binaries with drastically different behaviors.

[0101] Figure 2 This is a diagram illustrating the principle of function variable redirection during compilation in this embodiment. The diagram dynamically shows... Figure 1 The core process in this process. When the business code calls dao.CreateMysqlUserFunc(), its actual execution path is determined at compile time: Production build path: Variables are directly bound to the actual createMysqlUserReal function. Execution is successful, and business operations continue.

[0102] Test build path: Variables are redirected to the inject.CreateMysqlUserFake function, which makes intelligent decisions based on configurable fault policies (such as counters, probabilities, etc.): it may return simulated errors to trigger the system's fault tolerance mechanisms such as retry, degradation, or rollback, or it may directly call the real implementation to verify the continuity of normal processes, thereby comprehensively verifying the system's resilience.

[0103] Figure 3 is a closed-loop diagram of the CI / CD pipeline integrating automated purity verification in this embodiment, which includes three parts: Figure 3a Working principle of the core detection engine (technical principle diagram) This diagram reveals the core technical principle of this solution—the multi-dimensional intelligent detection engine. This engine performs deep static detection on the completed production environment binary files according to a four-stage serial analysis process: first, static feature scanning (pattern matching); then, symbol and metadata analysis (parsing the binary format); next, control flow graph verification (analyzing the logical flow); and finally, tag verification (checking compiled metadata). The quantitative results of each stage (such as string confidence and symbol contamination index) converge to an intelligent aggregation decision engine for comprehensive judgment, ultimately outputting a conclusion: if all stages pass, a digital compliance certificate is generated; if any stage is abnormal, an alarm is triggered and a diagnostic report accurately locating the problem is generated. This engine is the key technological foundation of the entire automated compliance pipeline, ensuring the comprehensiveness and accuracy of the detection through rigorous serial analysis.

[0104] Figure 3b: Closed-loop CI / CD pipeline integrating compliant access control (flow diagram) This diagram illustrates how to... Figure 3a The detection engine is seamlessly integrated into the CI / CD process, forming a mandatory quality control closed loop. The process begins with a "dual-track parallel build" triggered by code commits, simultaneously producing production and test versions. Subsequently, mandatory compliance gatekeeping (i.e., calling...) is implemented on the production binary. Figure 3a (Engine). Access control results directly drive intelligent decision-making: if successful, automatic deployment and generation of audit evidence chains; if unsuccessful, the pipeline is immediately halted and an alarm is triggered, initiating a cycle of manual investigation and repair. Simultaneously, the test version is used for chaos engineering verification, forming a feedback loop for resilience optimization. This diagram represents the "Compliance Architecture Panorama" (…). Figure 3c The specific implementation and detailed explanation of the "Automated Production Line" module in the document.

[0105] Figure 3c End-to-end automated compliance and governance framework (architecture overview) This diagram presents a modern software delivery compliance governance framework for highly regulated environments such as finance and government, from a top-level design perspective. The architecture consists of three core modules forming an organic whole: the policy definition module transforms external regulations and internal control standards into executable rules; the automated pipeline module (its process is detailed in...) Figure 3b As the technical execution engine, it handles building, detection, deployment, and blocking; the audit and supervision module monitors, analyzes, and continuously improves the entire process. These three modules form a data-driven closed loop of "strategy -> execution -> monitoring -> optimization," and provide transparent and credible compliance evidence through standardized interfaces. This architecture achieves end-to-end, automated compliance governance from code submission to production deployment, significantly improving R&D and operations efficiency while ensuring strict control.

[0106] Figure 4 is a flowchart of the fault injection decision and fault recovery execution process in this embodiment, which includes two parts: Figure 4a Fault injection phase (before reaching the maximum number of faults) This diagram illustrates the core decision-making and execution process of the fault injection mechanism. The system first checks if the current fault count has reached the configured maximum number of faults (MaxFailures). If not, it enters the fault injection state, randomly deciding whether to inject a fault based on the preset fault probability (FailureProbability). If a fault is injected, the fault count is incremented and a fault error code is returned; otherwise, the actual business function is called normally. This process continues until the fault count reaches the MaxFailures limit, at which point the system enters the recovery decision point.

[0107] Figure 4bFault recovery and termination decision-making process (after reaching the maximum number of faults) This diagram illustrates the recovery and termination decision process after the failure count reaches the maximum limit (MaxFailures). At the recovery decision point, the system checks the Recoverable configuration attribute of the failure: if it is configured as a recoverable failure (true), it enters a steady-state execution state, always calling the real function, no longer making failure injection decisions, verifying the system's recovery capability, and continuing to execute subsequent workflow tasks; if it is configured as an unrecoverable failure (false), it enters a process termination state, returns a termination error message, triggers the workflow rollback mechanism to clean up created resources, and finally safely terminates the process and generates audit logs.

[0108] Embodiments of this application also disclose an electronic device, including: a processor, a communication interface, a memory for storing a processor-executable computer program, and a communication bus. The processor, communication interface, and memory communicate with each other via the communication bus. The processor executes the executable computer program to implement the steps of the aforementioned non-intrusive cloud-native fault injection method based on compile-time conditional isolation.

[0109] Furthermore, this application also discloses a computer-readable storage medium that, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform the various steps of the non-intrusive cloud-native fault injection method based on compile-time conditional isolation disclosed in this application.

[0110] Specifically, according to embodiments of this application, the processes described in the flowcharts can be implemented as computer software programs. For example, embodiments of this application relate to a computer program product comprising a computer program carried on a non-transitory computer-readable medium. This computer program contains program code for executing the non-intrusive cloud-native fault injection method based on compile-time conditional isolation disclosed in this application. When the computer program is executed by a processing device, it can achieve the functions defined in the embodiments of this application.

[0111] Those skilled in the art should understand that this application also covers other technical solutions formed by any combination of the above-described technical features or their equivalent features without departing from the above-disclosed concept.

Claims

1. A non-intrusive cloud-native fault injection method based on compile-time conditional isolation, characterized in that, The method includes: S1. In the business code, declare the key call points as package-level function variables, which default to point to the real business implementation functions, and the business logic indirectly calls through the package-level function variables. S2. Create an independent fault simulation library, and physically isolate the fault simulation library from the business code library by constructing tags; execute a two-track build process based on the constructed tags: during test build, redirect the package-level function variables to the fake implementation functions in the fault simulation library; during production build, exclude the fault simulation library and the redirection logic, and the package-level function variables remain pointing to the real business implementation functions. S3. In the fake implementation functions, define atomic-level refined fault semantics based on configurable parameters, supporting conditional control of the number of faults, probability, and recovery mode. S4. When performing fault injection, control the behavior through a state machine model, including: in the fault injection state, inject faults according to the probability and record the number of times; after the recovery decision point reaches the maximum number of times, check the recovery configuration; in the steady-state execution state, call the real function; in the process termination state, terminate the process. S5. Integrate structured audit logs to record the test context, and verify the purity of the production binary through automated verification in the CI / CD pipeline to generate an auditable evidence chain.

2. The method according to claim 1, characterized in that, In step S1, the key call points include database access and external API calls; the package-level function variables are declared as public or private variables, and the business logic calls the implementation functions through the variables instead of directly calling.

3. The method according to claim 1, characterized in that, In step S2, the build tags use the / / go:build syntax, the test build tag is chaos, and the production build does not carry tags; the redirection logic is implemented through conditional compilation files, which are included during test build and excluded during production build.

4. The method according to claim 1, characterized in that, In step S3, the configurable parameters include: the maximum number of faults, fault probability, recoverability, fault code, and recovery action; the refined fault semantics support "first call fails", "first N calls delayed", and "random error based on sequence number".

5. The method according to claim 1, characterized in that, In step S4, the state machine model includes four states: Fault injection state: When the number of calls ≤ MaxFailures and the fault count < MaxFailures, inject faults according to the FailureProbability probability, and the fault count is incremented. Recovery decision point: When the fault count = MaxFailures, check the Recoverable configuration, enter the steady-state execution state if true, and enter the process termination state if false. Steady-state execution state: When Recoverable = true, call the real function without injecting faults. Process termination state: When Recoverable = false, return a termination error and trigger a rollback.

6. The method according to claim 1, characterized in that, In step S5, the structured audit logs record the operator, execution time, fault type, impact scope, and state transition information; the automated verification includes symbol table scanning, string table checking, and build metadata verification.

7. The method according to claim 1, characterized in that, The method also includes: fault recovery strategy configuration steps: setting the number of faults, retry behavior, recovery mode parameters, verifying the fault tolerance capability of the workflow, and supporting fully recoverable, conditionally recoverable, unrecoverable, and skip recovery modes.

8. A non-intrusive cloud-native fault injection device based on compile-time conditional isolation, characterized in that, The apparatus, when running, implements the steps of the non-intrusive cloud-native fault injection method based on compile-time conditional isolation as described in any one of claims 1-7, and the apparatus comprises: The indirect call interface module is used to declare key call points as package-level function variables in business code. By default, these variables point to the actual business implementation functions, and the business logic calls them indirectly through these package-level function variables. A tag control module is built to create an independent fault simulation library. The fault simulation library is physically isolated from the business code library by building tags. A dual-track build process is executed based on the building tags: during test build, the package-level function variables are redirected to fake implementation functions in the fault simulation library; during production build, the fault simulation library and redirection logic are excluded, and the package-level function variables continue to point to the real business implementation functions. The fault injection module is used to define atomic-level fine-grained fault semantics based on configurable parameters in the fake implementation function, and supports conditional control of fault count, probability, and recovery mode. The state machine control module is used to control behavior through a state machine model when performing fault injection, including: fault injection state injecting faults according to probability and recording the number of times; checking the recovery configuration after the recovery decision point reaches the maximum number of times; steady-state execution state calling the real function; and process termination state terminating the process. The audit and verification module is used to integrate structured audit logs to record test contexts and automatically verify the purity of production binary data in the CI / CD pipeline, generating an auditable chain of evidence.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the non-intrusive cloud-native fault injection method based on compile-time conditional isolation as described in any one of claims 1-7.

10. An electronic device, characterized in that, include: Memory and processor; Memory: Used to store computer programs; Processor: for executing the computer program to implement the steps of the non-intrusive cloud-native fault injection method based on compile-time conditional isolation as described in any one of claims 1-7.

Images