Resiliency — Term Reference

A system design approach where all redundant components are continuously powered on and actively serving, so that the failure of any single component causes no service interruption. The key distinction from simple redundancy: in HA, there is no "switchover" delay because everything is already running. HA typically uses active/active configurations where multiple systems share the workload simultaneously — if one fails, the others absorb its traffic immediately. HA requires higher investment: duplicate hardware, upgraded power systems, enterprise-grade components, and licensing for all running systems simultaneously. The design tradeoff is how much additional availability is worth how much additional cost.

A high availability architecture in which all system components are simultaneously active and processing real production traffic at the same time. Multiple servers handle actual requests concurrently; the load is distributed across all of them. If one component fails, the remaining active components absorb its share of the load — there is no waiting for a standby system to activate. Active/active also provides scalability: adding another active node increases total capacity. Contrast with active/passive (active/standby): only one component handles traffic at a time; the other waits idle and activates only if the primary fails. Active/active is more efficient (no idle standby) but requires all components to be capable of handling peak load when another member fails.

A configuration in which multiple physical or virtual servers are combined to operate as a single logical server from the user and application perspective. Users send requests to the cluster; the cluster management software distributes work across member nodes transparently. Key characteristics: (1) users see one server, not individual nodes; (2) nodes typically use shared storage so all cluster members always access the same current data; (3) nodes are added or removed without disrupting the cluster; (4) clustering is typically implemented at the OS level and most implementations require all nodes to run the same operating system for compatibility. When a node fails, the cluster redistributes workload to the remaining nodes — availability is maintained without manual intervention.

A distribution mechanism that uses a central load balancer device to route incoming requests across a pool of backend servers. Unlike clustering, load-balanced servers have no knowledge of each other — the load balancer is the only component that knows all servers in the pool. Each backend server operates independently. Advantages: servers can run different operating systems; adding capacity requires only adding a server to the pool; the load balancer auto-detects failed servers via health checks and removes them from rotation; the remaining servers absorb traffic automatically. Load balancers also typically handle SSL/TLS termination, session persistence (sticky sessions), content-based routing, and health monitoring. The load balancer itself is a potential single point of failure — production deployments typically include redundant load balancers.

A secondary processing location prepared to assume an organization's operations if the primary site becomes unavailable due to a disaster, major infrastructure failure, or other facility-level event. Site resiliency addresses scenarios where high availability within a single data center is insufficient — when the entire facility is unavailable. Recovery sites are classified by readiness: hot (fully operational duplicate), warm (partially equipped), or cold (empty facility, maximum lead time). Key lifecycle: prepare the recovery site (data sync, hardware maintenance) → disaster declared → failover to recovery site → primary restored → fail back to primary. Both failover and failback must be documented and tested before a disaster occurs.

A disaster recovery site that is a fully operational, continuously updated duplicate of the primary data center. Characteristics: all hardware is installed and running (or immediately startable); applications are kept current with the same versions as the primary; data is continuously replicated in real time or near-real time; staff can be transitioned quickly. Recovery time objective (RTO) is minimal — failover can happen within hours (operationally described as "flipping a switch," though it involves redirecting DNS, network traffic, and application configuration). Cost: the highest of the three site types — you effectively operate two data centers simultaneously, buy everything twice, and maintain both continuously. Best for organizations where downtime is extremely costly and RTO requirements are measured in minutes to hours.

A disaster recovery site consisting only of a physical facility with power and basic infrastructure — no hardware, no software, no synchronized data, and no personnel on-site. When a disaster is declared, the organization must: transport equipment to the cold site (or procure new equipment), install and configure operating systems and applications, restore data from the most recent backups, and get personnel on-site. Recovery time is the longest of the three site types — potentially days to weeks. Cost is the lowest — ongoing expense is just the facility lease and basic utilities. Cold sites are appropriate for organizations with a high tolerance for recovery time and where disaster events requiring site activation are extremely rare. Also, any organization that can afford neither a hot nor warm site uses cold as the minimum viable disaster recovery option.

A disaster recovery site between hot and cold — partially equipped and ready but not fully operational. Typically includes: rack space and physical infrastructure, some hardware already installed (servers, networking equipment), basic network connectivity. What it typically lacks: current data (must be restored from backup or transported), final software configuration, and possibly some additional hardware. Recovery time is between cold and hot — hours rather than days or weeks (for cold) or minutes to hours (for hot). Cost is proportionally between cold and hot. Most common practical choice for organizations that need meaningful disaster recovery capability without the expense of duplicating the entire data center. The "just enough to get going" site that requires final preparation steps before becoming operational.

The security design principle that recovery and backup sites should be physically located far enough from the primary site that a single regional disaster cannot affect both simultaneously. Large-scale events — hurricanes, regional floods, major earthquakes, tornados — can affect an entire metropolitan area or region. A recovery site in the same city as the primary data center provides little protection against such events. Geographic dispersion means placing recovery sites in a different metropolitan area, region, or state so that a regional disaster affects only one location. Operational challenges: equipment transport, staff relocation, maintaining connectivity between dispersed sites, and the process of returning to the primary site when the disaster resolves. All must be planned and documented in advance.

A resiliency strategy of intentionally using multiple different operating systems, application frameworks, or hardware architectures across an organization's infrastructure, so that a vulnerability specific to one platform cannot compromise the entire infrastructure simultaneously. Most security vulnerabilities are platform-specific: a critical Windows kernel vulnerability typically does not affect Linux or macOS systems. By running a mix of platforms, the organization ensures that a platform-specific vulnerability or exploit has limited blast radius — it can compromise one category of systems but leaves others unaffected and available to continue serving critical functions. Tradeoff: managing multiple platforms increases operational complexity and requires staff expertise across different systems.

An architecture where an organization distributes workloads and data across multiple cloud providers (e.g., AWS, Microsoft Azure, Google Cloud Platform) rather than relying on a single provider. Benefits: if one provider experiences an outage or security incident, services on other providers remain unaffected; data is geographically dispersed across different physical infrastructure; vendor lock-in is reduced. The strategy applies both geographic dispersion (different providers use different physical data centers) and provider dispersion (an outage or breach specific to one provider's systems does not affect others). Challenges: managing multiple cloud environments requires expertise across platforms, consistent security configurations across providers, and handling data synchronization complexity. Most organizations adopt a two-provider approach to balance resilience benefits against operational overhead.

A planning framework that ensures essential organizational functions can continue during and after disruptions, including when technology systems are completely unavailable. COOP acknowledges that organizations have become deeply dependent on technology and may be unable to function when systems are down — unless non-technical alternatives are designed in advance. COOP procedures replace digital processes with manual ones: paper forms instead of electronic workflows, physical signatures instead of digital approvals, phone calls to processors instead of automated payment network connections, paper receipts instead of electronic POS receipts. Critical requirement: COOP procedures must be documented, distributed to staff, and regularly tested before a disruption — not improvised during one. An untested COOP plan is likely to fail when needed.