Sharing IT Best Practices with youSharing IT Best Practices with you
This article describes how to define a SLA within a DevOps Plan approach.
A Service Level Agreement (SLA) is an agreement between a IT-service provider and a customer. The content of a SLA is about quality norms that are assigned to products, processes and services. An example of a SLA norm for an application is: availability of 99,9% with maximum 3 incidents per year and maximum 3 hours outage. In this article, the meaning of the term service includes the product. All in the DevOps Plan perspective.
An important concept for SLAs is that service norms must be derived from the objectives of the business processes, see Figure 1.
The business processes (3) use products and services (5). The SLA norms (6) make the CSF (4) measurable by the use of KPIs (4).
It is important to realize that the CSF’s (4) are the countermeasures of the risks that business targets (1) are not met. Partly the business risks can be mitigated by the implementation of technical products and services (16) and in the service management processes (14).
In fact, an SLA is an agreement on the effectiveness of counter measures of the supplier to mitigate business risks of the customer.
This article explains the role of a SLA in a DevOps context. First the business case of a SLA is drawn up. Secondly the influence of the SLA in each phase of the DevOps process is defined.
If a new method is adopted by the market, many existing controls will also be abolished. And so, unfortunately, it is also true with the introduction of DevOps. Many organizations have experienced a SLA as an expensive document that does not make any difference in the quality of service delivery. As indicated in Figure 1, this is a very distorted view of the actual intention of the SLA.
A SLA can be used as a test basis to determine to what extent the service organization is able to deliver quality. If an SLA is only a means to address quality that is never met, then it says more about the competencies of the service level manager involved and the maturity of the service organization than about the usefulness and necessity of a SLA. If the SLA does not contain any quality norms, then this says something about the customer needs and the maturity of the governance of the business processes or the ignorance of the supplier to fulfill the customers’ demand.
So, a SLA is nothing more but a document incorporating Non-Functional Requirements (NFR) from a business perspective made during DevOps Plan. Therefore there is no justification to state that a SLA has no right of existence. It could only be said that the information carrier (a document) is no longer of this time.
Service norms such as availability, capacity, performance, security and continuity have an impact on the entire design of a service. These service norms and the needed measures to achieve these norms must be part of the business case determination in the funnel (see article DevOps Plan – deliverables). It is often said that there is no view on the NFR at that time. However, this argument must be strongly rejected, as stated in Figure 1. A NFR is a question from the business to control risks. Taking action requires additional functionality, which greatly reduces the business case of the idea in the funnel. However, the high level NFR’s will be included in the idea.
Within ITIL ®, the service strategy phase provides an excellent framework in the form of Patterns of Business Activities (PBA) and User Profiles (UP). The architect should identify with the stakeholders and the product owner who will use the service and what is the expected use (PBA). Thus, an operational employee (UP) will generally show high frequency use of a service and a tactical employee (UP) a lower frequency of use. In particular, the service footprint on the infrastructure must be considered more closely in order to determine the impact on the infrastructure of the usage of the service. With the arrival of cloud services, these effects are quickly muted. Nevertheless, it is advisable to look closely at this. Particular aspects such as security are an ongoing theme.
Very obvious, is that often the infrastructural changes necessary for proper rollout are forgotten. For organizations, the infrastructure is part of the DevOps teams (infrastructure as code). The central infrastructure team often works through a waterfall approach due to the nature of the services. The infrastructure team must be involved timely and not three days before GO-live.
A commonly used remark of a programmer is that the SLA is for the OPS team and does not have any positive or negative impact on their work as a programmer. Of course, this is not true. The architect must pay close attention to each of the DevOps cycles, or have a positive impact on the performance of the service. A least there must be made use of a simple checklist like:
In the build phase, unit test cases can check whether the Standard Rules and Guidelines (SRG) that relate to the optimal utilization of physical resources are adhered to. For example, memory leaks can be checked, but also dead wood in the code. Checking for performance will only take place after the build. It should not be forgotten that the build server should also offer a good performance in order to realise the time to market. A golden standard is that a build may not take more than 5 minutes. There are still organizations that have an overnight build with all the consequences of that.
The test phase is of course important for testing the NFR. For example, by determining whether all events on the blacklist event are perceived by the monitor device as it is in production. In particular, regression tests are important. Intelligent monitoring facilities are increasingly being used in the test phase (more: DevOps Architecture – Monitoring)
The deployment pipeline should be quick and repeatable. Certainly, the demand for recoverability of the production environment in case of severe disturbance requires that the deployment pipeline must meet high standards. Here too, there is a role for architecture to ensure that wrong construction mechanisms are not used and tools are properly linked.
The proof of the pudding is in the eating. But hopefully, for the SLA norms, they have been evaluated during the funnel and tested in the test phase. The feedback from operations should lead to regular adjustment throughout the flow of idea to deployment.
All SLA standards should be observable through the monitor facility. This imposes high demands on the monitor facility. What cannot be monitored must also not be agreed on.
So, the SLA has an effect on all phases in the DevOps process. In fact it is very wise to ask the DevOps team to write an Operational Level Agreement (OLA) in which they state how they as a team will guarantee the SLA norms by defining countermeasures in the processes, products and services as depicted in figure 1.
Discuss with us about this article on LinkedIn.
DevOps Best Practices, ISBN: 9789492618078
Agile Service Management with Scrum, ISBN: 9789071501807
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.