Establishing agreed upon services levels for database applications is of the utmost importance for assuring that performance meets required criteria. Without pre-determined, negotiated service level agreements in place, database and application performance can become a never-ending game of blind man's bluff, where DBAs blindly and constantly seek an unspoken goal. Instead, active service level management should be the standard.
Service-level management (SLM) is the methodology and procedures used to ensure appropriate levels of service are delivered to all IT users in accordance with business priorities, and at acceptable cost. In order to effectively manage service levels, a business must prioritize its applications and identify the amount of time, effort, and capital that can be expended to deliver service for those applications.
A service level is a measure of operational behavior. SLM ensures that applications behave accordingly by applying resources to those applications based on their importance to the organization. Depending on the needs of the organization, SLM can focus on availability, performance, or both. In terms of availability, the service level might be defined as something like, “99.95%uptime from 9:00 a.m. to 10:00 p.m. on weekdays.” Of course, a service level can be more specific, stating that “average response time for transactions will be 2 seconds or less for workloads of 500 or fewer users.”
For an SLA to be successful, all parties involved must agree on stated objectives for availability and performance. The end users must be satisfied with the performance of their applications, the DBAs and technicians must be content with their ability to manage the system to the objectives, and the executives must agree to the required cost of satisfying the service level. In other words, compromise is essential to reach a useful SLA.
In practice, though, many organizations do not institutionalize SLM. When new applications are delivered, there may be vague requirements and promises of subsecond response time, but the prioritization and budgeting required to assure such service levels are rarely tackled unless the IT function is outsourced. Internal IT organizations are loath to sign SLAs because any SLA worth pursuing will be difficult to achieve. Furthermore, once the difficulties of negotiating an SLA are completed, the business could very well turn around and outsource the SLA to a lower-cost provider than the internal IT group.
But do not misunderstand; The failure of SLM within most businesses lies with both IT organizations and business users. The business users frequently desire better service but are not willing to make the effort to prioritize their needs correctly or to pay additional cash to achieve better service.
Another potential problem with SLM is the context of the service being discussed. Most IT professionals view service levels on an element-by-element basis. In other words, the DBA views performance based on the DBMS, the SA views performance based on the operating system or the transaction processing system, and so on. SLM properly views service for an entire application. However, it can be difficult to assign responsibility within the typical IT structure. IT usually operates as a group of silos that do not work together very well. Frequently, the application teams operate independently from the DBAs, who operate independently from the SAs. These fractured silos make cooperation toward a common application service level difficult. Breaking down these silos and encouraging team behaviors is one of the reasons for the burgeoning success of DevOps.
To achieve end-to-end SLM, these silos need to be broken down. The various departments within the IT infrastructure need to communicate effectively and cooperate with one another. Failing this, end-to-end SLM will be difficult, if not impossible, to implement.
SLM is a beneficial practice: A robust SLM discipline makes performance management predictable. SLM manages the expectations of all involved. Without an SLA, how will the DBA and the end users know whether an application is performing adequately? Not every application can, or needs to, deliver subsecond response time. Without an SLA, business users and DBAs may have different expectations, resulting in unsatisfied business executives and frustrated DBAs—not a good situation.
With SLM in place, DBAs can adjust resources by applying them to the most-mission-critical applications as defined in the SLA. Costs will be controlled, and capital will be expended on the portions of the business that are most important to the business. Without SLM in place, an acceptable performance environment will be ever elusive. Think about it; without an SLA in place, if the end user calls up and complains to the DBA about poor performance, there is no way to measure the veracity of the claim or to gauge the possibility of improvement within the allotted budget.
Another way to look at it is that applications that access relational databases are only as good as the performance they achieve. Wise organizations will implement a comprehensive performance, tuning, and management environment based on service level agreements to ensure that the expectations of all parties are met.