Critical IT Infrastructure Services
Critical IT infrastructure services for Gauteng enterprise. Server and database platforms, virtualisation, continuity, resilience and incident recovery.
Discuss your infrastructure →Which systems are actually critical
Most organisations have a list and most lists are wrong in the same direction. Everything important to somebody ends up on it, which makes it useless for prioritising spend.
The question that produces a usable list is not “is this important” but “how long can the business operate without it, and what does it cost per hour after that”. That is the business impact analysis described on business continuity planning, and it is the input to everything on this page.
Run properly it usually finds three or four genuinely critical systems and thirty that are not, which is what makes the architecture affordable. Protecting forty systems to a one-hour recovery objective is how infrastructure budgets become indefensible and get cut.
It also finds the surprises, which are consistent: the licence server nobody knew about, the scheduled task on a workstation under a desk, the integration that runs through a service account whose password nobody holds, and the single supplier with no alternative.
The services
Infrastructure health check
A point-in-time assessment of the estate: capacity, performance, resilience, currency, configuration and the gap between stated recovery objectives and actual capability. Usually the first engagement. Covered on infrastructure health check.
Server and database infrastructure
Physical and virtual servers, storage, operating systems and the database platforms underneath your business applications. Design, deployment, patching, performance and capacity. Covered on server and database infrastructure.
Virtualisation
Hypervisor platforms, cluster design, resource management, snapshot hygiene and the licensing decisions that follow. Covered on virtualisation.
Business continuity
The planning layer: impact analysis, recovery objectives, workarounds and exercised plans. Covered on business continuity planning.
Cyber resilience
The ability to keep operating through and recover from a security incident, which is a different discipline from preventing one. Covered on cyber resilience.
Critical incident recovery
Coordinated recovery when a major incident is running, and the readiness work that makes it survivable. Covered on critical incident recovery.
Backup and recovery sits under Managed rather than here, because it is a standing operational service rather than an architecture discipline. Covered on backup and recovery.
Resilience, priced honestly
Resilience is a spectrum and every step up costs more. Deciding where each system sits is the whole exercise.
| Level | What it means | Recovery time | Relative cost |
|---|---|---|---|
| Backup only | Restore onto replacement or cloud infrastructure | 24 to 72 hours | Baseline |
| Warm standby | Infrastructure pre-provisioned, restore from replicated backup | 4 to 24 hours | 2 to 3× |
| Replicated standby | Standby environment kept current, failover tested | 1 to 4 hours | 4 to 6× |
| Active-active | Both sites live, automated failover | Minutes | 8× and upward |
The mistake is applying one level to everything. The right shape for most mid-market estates is replicated standby for the two or three systems that stop the business, warm standby for a handful more, and backup-only for the rest.
Resilience adds complexity, and complexity has its own failure modes. A badly implemented cluster fails more often than a well-maintained single server. Where the operational maturity to run a complex arrangement is not there, a simpler design with a tested restore is the better answer and we will say so.
What tends to be wrong
Recovery objectives on paper with no evidence behind them. Four hours in the document, eleven in practice, discovered during the first real event.
Single points of failure nobody chose
A cluster on one storage array. Two hosts on one power feed. Redundant network paths through one switch.
Snapshot sprawl
Virtual machine snapshots taken for a change and never removed. They grow, they degrade performance and they are a routine cause of datastore exhaustion.
Capacity managed reactively
Storage growth, memory and licence consumption discovered at the limit rather than tracked to a projection.
End-of-support platforms in production
Operating systems, database versions and hypervisors past support, usually because a business application requires them, usually with no exception record or compensating control.
No documented recovery sequence
Systems come back in the wrong order, dependencies surface during recovery, and the person who knows is unavailable.
What Namandla delivers
Assessment. Capacity, performance, resilience, currency, configuration and the gap between stated and actual recovery capability.
Design. Compute, storage, virtualisation and resilience matched to recovery objectives derived from the business rather than assumed.
Deployment and migration, phased, with fallback.
Managed operation. Patching, monitoring, capacity management, performance, snapshot hygiene, firmware and version currency, under the response commitments on managed IT services.
Recovery runbooks, written so someone who did not build the environment can follow them, and exercised rather than filed.
Lifecycle planning. Hardware refresh, support expiry and licence renewal tracked with enough lead time to be planned rather than urgent.
Onsite work is Gauteng. Design, remote operation and recovery coordination run nationally.
Common questions about Critical Infrastructure
What counts as critical infrastructure?
The systems where an outage stops the business rather than inconveniencing it. Which ones those are comes from a business impact analysis rather than from an opinion, and it is usually a much shorter list than people expect.
The useful question is how long the business can operate without a system and what it costs per hour after that. Answering it properly typically produces three or four genuinely critical systems out of thirty or forty, which is what makes protecting them affordable.
How do we decide how much resilience to buy?
Per system, from the recovery objectives the business impact analysis produced. Backup-only for most, warm standby for a few, replicated standby for the two or three that stop the business.
Applying one level to everything is how these programmes become unaffordable. The cost curve is steep: moving a system from a twenty-four hour recovery objective to a one-hour objective typically multiplies the cost of protecting it several times over.
Is more redundancy always better?
No. Redundancy adds complexity and complexity has its own failure modes. A badly implemented cluster fails more often than a well-maintained single server.
The question is whether you have the operational maturity to run the more complex arrangement, meaning monitoring, patching, testing and someone who understands it. Where that is not there, a simpler design with a tested restore delivers better real availability than a sophisticated one nobody maintains.
We have virtual machine snapshots. Are those backups?
No. A snapshot is a point-in-time state on the same storage as the running machine, and it shares that storage’s fate. It is also a performance and capacity problem if it is left in place.
Snapshots are excellent for rolling back a change within hours. They are not a backup strategy, and snapshot sprawl is one of the most common causes of datastore exhaustion we find. Backup is covered on backup and recovery.
What do we do about systems running unsupported software?
Record them as exceptions with a reason, a compensating control, an owner and a review date, and plan the remediation with a realistic timeline.
The most common case is a business application certified only against an older operating system or database version. The compensating control that works is network isolation, restricted access and increased monitoring on that specific system. Pretending the exposure is not there is the only genuinely wrong answer.
How often should infrastructure be assessed?
A full health check annually, with capacity and currency tracked continuously as part of the managed service.
The continuous part matters more. An annual assessment finds a storage array at ninety percent, where trend reporting would have flagged it three months earlier with time to plan. The annual check is for the structural questions rather than the numbers.
Can you work with our existing hardware?
Almost always. The findings are usually configuration, capacity management and resilience decisions rather than inadequate equipment.
Where hardware is genuinely at end of support, out of capacity or unable to meet a recovery objective, we say so and quote it separately with the reasoning. We would rather get more out of what you own, and where a refresh is genuinely due we would rather you knew about it a year in advance than at failure.
When is a simpler approach enough?
On a single-site environment with a handful of servers, no recovery commitment to customers and a tolerance for a day of downtime, tested backups and a documented recovery sequence cover most realistic exposure.
Those two things are worth doing at any size and they are cheap. The case for more grows with multi-site operations, contractual or regulatory recovery commitments, or systems where an hour of downtime has a number attached to it. We will tell you which of those apply to you.