What should be protected first, and where can you save money?

Trying to make everything equally reliable is the quickest way to exhaust the budget without increasing reliability where it matters. When a team proposes moving the entire infrastructure to a cluster with automatic failover, it’s thinking in terms of technology. The business thinks in terms of consequences, and the consequences of different failures differ by two orders of magnitude.

A dependency map shows what depends on what. The next step is to turn it into a financial document: determine how much each failure costs, and allocate the budget proportionally.

Classify functions, not servers

The first common mistake is to classify servers and services by criticality. The correct unit is a business function: “customer places an order”, “customer logs into their account”, “accounting exports closing documents”.

The difference is fundamental. The same server can serve both critical and non-critical functions at once — and then you discover that heavy report generation, which nobody considered important, lives on the same database as order placement and can take it down. Such things are visible only when classifying by functions.

Three classes

In a healthy system the proportion is usually: a minority of functions belong to class A — on average five to fifteen percent. If after classification more than a third are in class A, the analysis was done formally. Typically, this means every manager defended their area as critical, and the exercise degenerated into status negotiation.

Five questions for each function

To prevent classification from turning into a debate about department importance, run each function through the same checklist. Record the answers — they’ll be useful at the next review.

1. Does the failure stop revenue from coming in right now? If yes — it’s class A, and no further discussion is needed.

2. Are there contractual obligations for the availability of this specific function? Contractual penalties turn a technical question into a legal one and often raise the class by one level.

3. Can the user achieve their goal by another means? If, when address autofill fails, it can be entered manually — the function degrades but does not block. If without it an order cannot be placed — it blocks.

4. How long can the function be down without irreversible consequences? The difference between “an hour” and “a day” determines whether automation is needed or a person on duty with instructions is sufficient.

5. Is there a manual workaround and who owns it? Manually issuing an invoice while the accounting integration is down is a workable solution that lowers the class. But only if such a procedure is documented and has been tested at least once, not improvised during the incident.

Class — not fixed

Seasonality. For retail, the pre-New Year weeks change the whole picture: a function that was class B all year becomes class A for that period. A sensible approach is to predefine a “peak load mode”: what is strengthened, what is temporarily disabled to relieve critical services, and who is on duty.

Product growth. A function added as an experiment can become a main revenue source in a year while keeping experimental-level infrastructure. Such things are discovered only through regular review.

Regulatory changes. The introduction of mandatory reporting can turn what was yesterday a background export into a function with strict deadlines.

Where money is actually saved

Classification is useful not because it strengthens class A, but because it provides grounds not to strengthen the rest.

Test environments are not made redundant. A test environment that fails on Saturday can calmly wait until Monday. Duplicating it is a pure expense.

Archives are kept in cold storage. Closing documents three years old don’t need to be in a replicated storage with instant access: the cost difference is an order of magnitude, and the requirement is “retrieve within a day on request.”

Secondary functions are turned off instead of being made redundant. Sometimes the right decision is not to bring the service back faster, but to learn to operate without it. An application that continues to work correctly when the recommendation engine is unavailable is cheaper and more reliable than a fault-tolerant recommendation service.

Heavy background tasks are isolated. Moving report generation to a separate database replica is cheaper than scaling the primary database for the load that accounting generates once a month.

What this looks like in the end

The result should be a one-page table: function, class, acceptable downtime, acceptable data loss, owner. Not a forty-page document — nobody will open that during an incident.

This table answers the question that would otherwise be resolved by argument: why do we spend so much on payments and nothing on recommendations. It also protects the budget when the next proposal to “make everything highly reliable” comes without calculations.

Related analyses: how much does an hour of downtime cost — how to get the numbers for the right-hand side, and four levels of fault tolerance — which measures are appropriate for each class.