# The lex records whose category is self-healing-recovery-deployment-safety

This index as JSON: https://banes-lab.com/json/api/facets/lex/category/self-healing-recovery-deployment-safety

## Entries

- [Automation Risk](https://banes-lab.com/records/lex/automation-risk.md): The degree to which automated self-healing may take incorrect corrective actions without human oversight.
- [Manual-Only Recovery](https://banes-lab.com/records/lex/manual-only-recovery.md): Depending entirely on human operators to detect and recover from every failure, so recovery is slow and unreliable.
- [False Recovery Actions](https://banes-lab.com/records/lex/false-recovery-actions.md): The degree to which acting on faulty signals leads automated recovery to take wrong or harmful corrective actions.
- [Health Signal](https://banes-lab.com/records/lex/health-signal.md): A machine-readable signal that reports whether a component is currently healthy.
- [Manual Intervention Dependency](https://banes-lab.com/records/lex/manual-intervention-dependency.md): Requiring a human to step in for recovery to proceed, so the system cannot heal on its own.
- [Reduced Mean Time to Recovery](https://banes-lab.com/records/lex/reduced-mean-time-to-recovery.md): The ability to shorten the mean time to recover from a failure by acting automatically.
- [Remediation Action](https://banes-lab.com/records/lex/remediation-action.md): A corrective action executed to return a system to a healthy state after a fault is detected.
- [Blind Routing](https://banes-lab.com/records/lex/blind-routing.md): Routing traffic to instances without checking their health, so requests hit dead or degraded nodes.
- [Observable Health Criteria](https://banes-lab.com/records/lex/observable-health-criteria.md): The requirement that explicit, observable criteria define when a component counts as healthy.
- [Readiness/Liveness Routing](https://banes-lab.com/records/lex/readiness-liveness-routing.md): The ability to route traffic only to instances that report themselves ready and alive.
- [Continuity During Failure](https://banes-lab.com/records/lex/continuity-during-failure.md): The ability to keep serving requests by switching to a standby when the primary fails.
- [Health Detection](https://banes-lab.com/records/lex/health-detection.md): The ability to detect that a component has failed so a switchover can be triggered.
- [Single Instance Dependency](https://banes-lab.com/records/lex/single-instance-dependency.md): Depending on a single instance with no standby, so its failure takes down the whole service.
- [Replication or Alternate Capacity](https://banes-lab.com/records/lex/replication-or-alternate-capacity.md): The requirement that duplicate copies or spare capacity exist to take over when a component fails.
- [Consistency Lag](https://banes-lab.com/records/lex/consistency-lag.md): The degree to which replicas trail the primary, so reads served from them may return stale data.
- [Consistency Policy](https://banes-lab.com/records/lex/consistency-policy.md): The requirement that a defined policy specify how and when replicas converge to a consistent state.
- [Read Scaling](https://banes-lab.com/records/lex/read-scaling.md): The ability to serve more read traffic by distributing it across replicas.
- [Single Copy State](https://banes-lab.com/records/lex/single-copy-state.md): Keeping only one copy of state, so its loss or unavailability takes down the whole system.
- [Cost/Cold Start](https://banes-lab.com/records/lex/cost-cold-start.md): The degree to which scaling capacity up and down incurs added cost and cold-start latency.
- [Demand-Based Capacity](https://banes-lab.com/records/lex/demand-based-capacity.md): The ability to match provisioned capacity to current demand automatically.
- [Fixed Capacity](https://banes-lab.com/records/lex/fixed-capacity.md): Provisioning a fixed, preset amount of capacity, rather than adapting it to demand.
- [Horizontal Scalability](https://banes-lab.com/records/lex/horizontal-scalability.md): The degree to which a system can grow by adding more interchangeable instances rather than enlarging one.
- [Detection Signal](https://banes-lab.com/records/lex/detection-signal.md): A machine-readable signal indicating that a fault or anomaly has been detected.
- [Incident Reduction](https://banes-lab.com/records/lex/incident-reduction.md): The ability to reduce the number of incidents that reach human responders by fixing them automatically.
- [Manual Remediation](https://banes-lab.com/records/lex/manual-remediation.md): Recovering from incidents through human-operated fixes, rather than automated remediation.
- [Remediation Workflow](https://banes-lab.com/records/lex/remediation-workflow.md): A defined sequence of steps carried out to remediate a detected incident.
- [Unsafe Automation](https://banes-lab.com/records/lex/unsafe-automation.md): The degree to which automating remediation risks taking harmful actions faster than a human can intervene.
- [Data Migration Compatibility](https://banes-lab.com/records/lex/data-migration-compatibility.md): The degree to which reverting code is constrained by forward data migrations that cannot easily be undone.
- [Fast Failure Recovery](https://banes-lab.com/records/lex/fast-failure-recovery.md): The ability to recover quickly from a bad release by reverting to the last good version.
- [Irreversible Deployment](https://banes-lab.com/records/lex/irreversible-deployment.md): Deploying in a way that cannot be undone, so a bad release cannot be rolled back.
- [Reversible Deployment](https://banes-lab.com/records/lex/reversible-deployment.md): The requirement that a deployment be structured so it can be safely reverted to a prior version.
- [Versioned Artifact](https://banes-lab.com/records/lex/versioned-artifact.md): A build artifact tagged with a distinct version so a prior one can be redeployed.
- [In-Place Mutation Only](https://banes-lab.com/records/lex/in-place-mutation-only.md): Upgrading by mutating the running environment in place, with no parallel target to cut over to or fall back from.
- [Infrastructure Cost](https://banes-lab.com/records/lex/infrastructure-cost.md): The degree to which running two full parallel environments doubles infrastructure cost during a cutover.
- [Low-Risk Cutover](https://banes-lab.com/records/lex/low-risk-cutover.md): The ability to switch traffic to a new version with low risk by keeping the old one ready to fall back to.
- [Parallel Environments](https://banes-lab.com/records/lex/parallel-environments.md): The requirement that two full production-equivalent environments run side by side for cutover.
- [Big-Bang Deployment](https://banes-lab.com/records/lex/big-bang-deployment.md): Releasing a change to all users at once with no gradual exposure, so a defect reaches all of them.
- [Controlled Exposure](https://banes-lab.com/records/lex/controlled-exposure.md): The ability to expose a new version to a small, controlled fraction of traffic first.
- [Progressive Delivery](https://banes-lab.com/records/lex/progressive-delivery.md): A release strategy that rolls out changes gradually to widening audiences while monitoring for regressions.
- [Rollout Complexity](https://banes-lab.com/records/lex/rollout-complexity.md): The degree to which staging a release in gradual increments adds orchestration complexity.
- [Traffic Splitting](https://banes-lab.com/records/lex/traffic-splitting.md): A facility that routes a configurable proportion of traffic to different versions of a service.
- [Empirical Resilience Verification](https://banes-lab.com/records/lex/empirical-resilience-verification.md): The ability to verify a system's resilience empirically by injecting faults and observing recovery.
- [Production Risk](https://banes-lab.com/records/lex/production-risk.md): The degree to which deliberately injecting faults in production risks causing user-facing incidents.
- [Untested Failure Assumptions](https://banes-lab.com/records/lex/untested-failure-assumptions.md): Assuming a system will survive failures without ever testing those assumptions against injected faults.
- [Connection Cleanup](https://banes-lab.com/records/lex/connection-cleanup.md): The ability to close open connections cleanly when a process shuts down.
- [Hard Process Kill](https://banes-lab.com/records/lex/hard-process-kill.md): Terminating a process abruptly without draining work, dropping in-flight requests and risking corrupt state.
- [In-Flight Work Drain](https://banes-lab.com/records/lex/in-flight-work-drain.md): The ability to finish or safely hand off in-progress work before a process exits.
- [Lifecycle Signals](https://banes-lab.com/records/lex/lifecycle-signals.md): The requirement that a process receive lifecycle signals telling it when to start draining and stop.
- [Shutdown Latency](https://banes-lab.com/records/lex/shutdown-latency.md): The degree to which draining in-flight work before exit lengthens the time a shutdown takes.
- [Disk-Failure Survival](https://banes-lab.com/records/lex/disk-failure-survival.md): The ability to keep serving data after one or more disks fail, by reconstructing from redundancy.
- [Multiple Physical Disks](https://banes-lab.com/records/lex/multiple-physical-disks.md): The requirement that data span several physical disks so redundancy can survive a single-disk loss.
- [Parity-Based Recovery](https://banes-lab.com/records/lex/parity-based-recovery.md): The ability to reconstruct lost data from parity information stored across the disk array.
- [Single-Disk Point of Failure](https://banes-lab.com/records/lex/single-disk-point-of-failure.md): Storing data on a single disk with no redundancy, so that one disk's failure loses everything.
- [Write Amplification](https://banes-lab.com/records/lex/write-amplification.md): The degree to which maintaining parity on writes multiplies the underlying disk writes for each logical write.