What Are Some of the Reliability Metrics That Innovartus Should

Include in the SLA?

The Service Level Agreements or (SLAs) are contracts which get used

to defining the overall quality of service as well as guaranteeing to the

provision of the required service. For an SLA to be useful as well as being

set, the Service Level Agreement needs to be able to fulfill the expectations

of both parties and should also have the ability to provide metrics which are

to be used to measure the performance along with guaranteeing the service

level. The parameters are typically used in order to detect violations during

the monitoring phase to ensure that the promised service levels are going to

be provided the way it was supposed to be. As a result, these metrics are to

be defined based solely on the discipline as well as the organization in which

its involved with. Some of, if not the most crucial parameters are to be

included in the agreement. That is to add: response time, availability,

throughput and downtime.

To start off with, service availability is to be defined as an amount of

time in which a service is available for use. Then there is high response

time; this results in a decrease of availability in said system. Especially since

it can be measured through a time slot, for instance, 99.8% obtainability

between the times of 7:00 AM to 7:00 PM. On the other hand, the defect

rate counts the number of errors that manifest during the series of

deliverables. As such, successful deliverables get measured as the

throughput. Then there are the failures which can appear in the forms of

failed backups or even coding errors for that matter. Methodological quality

along with security are able to be measured too. However, there is a poor

choice of these metrics and result in trouble in enforcement and can also

encourage a variety of dangerous behavior from some members involved in

the contract. Afterward, the parameters are able to be retrieved from some

of the managed resources, a quick example of this would be a server, that is

not to say that we cannot create a managed resource. Overall, the process

of creating metrics will involve the combination of right parameters into

compound metrics, which by the way, are of a higher level. Some examples

of direct settings that are able to be retrieved from various resources include

outage period, system uptime as well as the number of invocations. Then

there is composite metrics, which on the other hand are designed from

functions that an average one or more parameters. Examples of composite

parameters include the average availability, the maximum response time

along with the minimum throughput. On another note, the metrics are also

able to get classified conferring to the service object which is to be

measured. There are other important objects that Innovartus ought to

ensure which can become clearly defined. Some of these objects will include

software, hardware, storage, network as well as service desk. Just as

importantly, these metrics should be able to be kept as unpretentious as

possible in order to avoid any form of confusion.

 What Was the Purpose of the Switch from a Cold-Standby High

Availability Model to a Hot-Standby? What Is the Difference Between

the Two?

A means in order to deal with the ever-increasing demand for high

availability and dependability in relation to the overall cost of redundancy;

standby redundancy gets used as a means to guarantee the quality as well

as the value. The aim of which we desire to having a standby redundancy is

used in order to improve the overall reliability and availability of the

systems. When it comes to standby redundancy, it also gets referred to as

backup redundancy, and it gets achieved when one has an identical

secondary unit that is used to backup the primary unit. While there is a

secondary unit, the secondary group will not be active but will act as a spare

in the event the primary one gets damaged or becomes inoperable. In a

cold-standby, the secondary unit gets powered off and is configured only to

be used when the primary unit is damaged to an extent or breaks down. As

a result, when such a situation arises, the secondary unit gets turned on and

the data is restored to it. As usual, the primary unit’s data gets backed up

thanks to a storage system and the secondary unit will receive the data

when it needs to. Most notably, the cold-standby will have a recovery time

for more than a few hours. However, in a hot-standby, software systems get

installed and are configured in both the primary as well as the secondary

units. In the secondary unit, the systems are to be powered up but are not
configured to process certain requests. The data in question is available in

real-time on both units and as a result of this, they both have identical

pieces of information (data). Interestingly enough, the recovery time in this

specific system is only a mere few seconds. Innovartus chose to switch from

the cold-standby to hot-standby due to a means of reducing the overall

recovery time, considering the fact that cold-standby will provide a recovery

time of several hours whereas the hot-standby will be able to provide

recovery in only a few seconds time. The huge recovery time in cold-standby

introduces bumps into the switchover, by doing so this makes it more of a

challenge to solve a variety of sync issues. Overall, by reducing recovery

time, we have the ability to ensure there is an increase in availability time of

that particular system.

In a Revised SLA the Average Availability Is 99.98% What Is the Total

Downtime in a Month?

The availability gets defined as the percentage time inside a quantified

time interlude for which a server or service system can get used for the

purpose for which it was designed for (made). The overall means is

calculated as follows “Availability (%) = Uptime ÷ Total time,” and “Total

time = Uptime + Downtime.” As a result, through using the calculations

available by Pavlos Ratis and with the availability of 99.98% the downtime is

calculated to 8.77 seconds which is made to 526.2 seconds per month. On

another note, this downtime gets calculated with a high assumption that a

Gregorian year is strictly 365.24 days a year.