Let's take a look at availability, capacity, and service‑level management.
It really is that the availability and the capacity management should be key
aspects measurable underneath a service‑level agreement.
It's really important to understand that when we're
talking about a service‑level agreement,
these are always designed from the perspective of the cloud service providers,
not the cloud consumer.
It's what the provider is saying that they can provide.
The service‑level requirement that the consumer may have,
could be a specific need that is actually not covered inside of the SLA.
And depending on your size and the amount that you pay,
the provider may not be willing to adjust the boilerplate SLA in your behalf.
Also,
it's important to note that the service‑level agreement
is not designed for service assurance.
An audit will give the highest degree of assurance of the services expected.
If the expected services are not rendered,
then the consumer is due credits for services not rendered.
So primarily,
it's a tool to manage and measure compensation for
successful and unsuccessful service.
Which term would you say serves the business more readily,
uptime or availability?
While the measurement of uptime is still relevant to
current technology components and systems, keep in mind
that the cloud continuously evolves.
So the focus should be on the availability of the service,
the extraction of the technology, so not the uptime of the
technology or system. As has always been the case,
it's possible for a system to be up while a service
on that system is unavailable.
Check the language of the SLA. You will see a plentiful distribution of uptime
versus the term availability. If you use ISO/IEC's Cloud SLA Framework from ISO
19086, you'll find that it has three parts to it.
The first part is an overview and a concept of how to make sure that the SLA
for your cloud consumption is meeting business requirements.
Part two goes into the metrics. When you say SLA, you're almost
automatically thinking about the fact that there are measurable
services that you are paying for. And part three deals with the core
requirements an organization needs to be ready to communicate to the
cloud service provider given the boilerplate SLA doesn't meet their
service‑level requirements.
The primary elements of an SLA would include the
accessibility to the service and also from an audit
standpoint, the availability of that service,
the capacity span of a particular service, along with its elasticity,
the ability to continue to grow or to diminish based upon demand. Service
monitoring, so some type of intelligent capability that allows you to know
that you are getting what you paid for and then the roles and responsibility
in the shared cloud responsibility model should also be delineated to some
degree in the SLA, although to greater detail, you may find that in
contractual language. Service resilience and fault tolerance should also be
part of the SLA.
The specificity of the audits, certifications from ISO,
attestations from service organization controls from the AICPA
organization may also be relevant here.
What changes there are to features that the cloud service provider
actually recommends or allows you to pull from them.
How long does it take for them to respond if you have a particular
problem, and here is an important one that may also span into the
contract. Is the termination of services, is it stated unilaterally that
without reason or fault the cloud service provider could have you leave
their system? These are things that you should know. From a service‑level
management perspective, you should be looking at target alignment.
So this is what is it that my business needs versus what is being provided.
There should be a transparent and shared view of what is entailed
in a service and a corresponding target level.
You should ensure that there is evidence‑based
satisfaction of a defined service being met,
not based upon assumptions or based upon feelings.
There should be the capability that your organization performs
frequent and continuous reviews to ensure service requirements
of the consumer are being met.
The document of record that drives the service is a service‑level
agreement. Catalog alignment should have something that conforms to
what it is that has been agreed upon from the actual service element
that you're consuming and what you're consuming. The documents that
prove out who the sponsors are, who the subproviders,
the subprocessors, the subcontrollers, may be.
And then also,
there should be metrics that allow you to know at what point are credits do,
and what does it mean for a satisfactory service to be delivered based upon
the promises stated by the cloud service provider.