Why traditional SLA is insufficient for business operability
A traditional SLA, which focuses exclusively on Uptime, often fails to reflect the system's true business value. ITIL 4 defines availability as the ability of an IT service to perform its agreed function when required. However, a high uptime metric (e.g., 99.9%) does not always guarantee successful business transactions, as a system might be technically available but fail to perform critical business functions, for example, due to slow or failed transactions. This creates tension between technical availability and actual business operability, demanding a more detailed approach to defining an SLA.
Availability metrics: A technical perspective
Technical availability focuses on infrastructure components and their ability to function. Key metrics include:
- Uptime/Downtime: The percentage of time the system is available. Often expressed as "number of nines" (e.g., 99.9%).
- MTTR (Mean Time To Recovery): The average time to recover after a failure.
- MTBF (Mean Time Between Failures): The average time between failures.
These metrics are directly related to architectural decisions such as redundancy, Fault Tolerance, and Load Balancing. For example, using High Availability patterns like Active-Passive or Active-Active helps eliminate single points of failure and ensure continuous operation.
Business operability metrics: End-user value
Business operability measures how effectively a system performs critical business functions. Google SRE uses SLI (Service Level Indicators) and SLO (Service Level Objectives) to measure business operability, focusing on metrics such as:
- Percentage of successful business transactions: For example, successful orders, registrations, payments.
- Response time for critical operations: For example, product page load time, request processing time.
- Throughput: The number of transactions the system can process per unit of time.
These metrics require Monitoring at the application and business process levels, not just infrastructure. For example, a Microservices architecture can provide better fault isolation compared to monolithic systems, impacting the measurement and maintenance of business operability.
Architectural patterns for ensuring availability and operability
Various architectural patterns are applied to achieve desired levels of availability and business operability:
- High Availability: Active-Passive (primary/standby) and Active-Active (active duplicate systems) patterns are used to ensure continuous operation by eliminating single points of failure.
- Fault Tolerance: Patterns like Circuit Breaker help isolate failures in distributed systems, preventing cascading failures and maintaining business operability.
- Scalability: Horizontal (adding more machines) and vertical (increasing the power of a single machine) scaling allow the system to handle increasing loads and maintain the desired level of operability.
The choice of patterns depends on the business criticality of functions and the acceptable trade-offs between cost and reliability levels.
Operational implications and risk management
Distinguishing availability and business operability in an SLA has significant operational implications. SRE principles, particularly the concept of an "Error Budget," allow balancing service reliability and innovation speed. If the error budget is exhausted, new feature development may be paused to prioritize reliability work. Monitoring business processes becomes critically important for early detection of problems affecting business operability, even if technical availability remains high. The cost of business downtime can reach significant sums per hour, justifying investments in highly available architectures when downtime costs exceed a threshold.
Architectural decision matrix for SLA
This matrix will help IT leaders make architectural decisions, considering both technical availability and business operability.
| Criterion | Low business criticality | Medium business criticality | High business criticality |
|---|---|---|---|
| Business criticality of function | Auxiliary functions, internal tools | Non-core but important business processes | Core, revenue-generating business processes |
| Expected availability level (99.x%) | 99.0% - 99.5% | 99.5% - 99.9% | 99.9% - 99.999% |
| Expected business operability level (SLI) | >95% successful transactions, response time up to 5 sec | >98% successful transactions, response time up to 2 sec | >99.5% successful transactions, response time up to 0.5 sec |
| Cost of architectural solution implementation | Low (monolith, minimal redundancy) | Medium (partial redundancy, horizontal scaling) | High (distributed systems, Active-Active, Microservices) |
| Complexity of monitoring and support | Low (basic infrastructure Monitoring) | Medium (transaction monitoring, APM) | High (advanced Monitoring of distributed systems, SRE approaches) |
| Risks of SLA non-compliance | Low financial losses, minor reputational impact | Medium financial losses, moderate reputational impact | High financial losses, significant reputational impact and legal consequences |
How to apply the matrix:
- Determine business criticality: For each application system or its key function, determine its business criticality on a scale from low to high.
- Set expected levels: Based on business criticality, set target indicators for technical availability (uptime) and business operability (SLI).
- Evaluate architectural solutions: Compare different architectural patterns (e.g., monolith vs. Microservices, different redundancy schemes) in terms of their cost, monitoring complexity, and support.
- Analyze risks: Assess potential risks and consequences of SLA non-compliance for each option.
- Make a decision: Choose the architectural solution that best balances business requirements, technical capabilities, and acceptable risks.
DMIG, as a leading B2B knowledge base, provides IT leaders with tools and insights to make informed architectural decisions that directly impact operational efficiency and business outcomes. For more information on Intecracy Group solutions, visit Intecracy solutions and inbase.com.ua solutions.
A clear distinction between availability and business operability in an SLA is fundamental for successful IT service management. It allows not only ensuring technical stability but also guaranteeing that systems effectively support business goals, minimizing risks and optimizing investments in IT infrastructure.
Перелік джерел
Author