Systems, Infrastructure and Network Operations
Availability is engineered, not promised
Core knowledge: availability and resilience design (redundancy, failover, load balancing), disaster recovery versus business continuity, RTO versus RPO, backup versus replication, capacity and performance management, patch and vulnerability management, change/incident/problem management, and monitoring that produces actionable alerts. In healthcare, add clinical downtime procedures, segmentation of medical-device networks, wireless coverage for point-of-care devices, and criticality tiering of systems.
Traps: treating high availability as disaster recovery - HA absorbs component failure inside a site, DR addresses loss of the site; reversing RTO and RPO (RTO is time to restore service, RPO is tolerable data loss measured in time); assuming backups are good because the job reports success; and segmenting networks with no clinical exception process, so devices get blocked at the bedside.
Rule of thumb: classify each system by clinical criticality first, then derive the targets. A system whose outage halts patient care needs a short RTO, tested failover, and a paper workaround that staff have actually rehearsed - not merely a server in a second rack. Untested recovery is a hypothesis, not a capability.
Expect questions on change discipline as well: emergency changes still require retrospective documentation and review, because the audit trail matters as much as the fix.