By Anil Desai
published: Friday, October 19 2007
Our story begins in Cost Wars: IT Fights Back…
It all starts innocently enough: IT and business leaders hear about how virtualization technology can magically reduce costs, reduce deployment times, and generally make everyone feel a lot happier. But, after you implement virtualization, you find yourself trying to address another set of importance issues. You’ve traded “server sprawl” for “VM sprawl.” End-users expect new deployments to occur within minutes rather than days.
Like a howling Wookie at an all-you-can eat buffet, virtual machines start gobbling up everything in sight: disk space, network resources, physical memory, and CPU cycles. And things can get even hairier (yes, hairier than said Wookie). Poor systems administrators are tasked with tracking a wildly heterogeneous set of VMs, armed with tools that were designed only for physical machines. How can IT departments help manage expectations while containing costs? One answer is through the Power of SLAs and by charging back.
Defining Service Level Agreements (SLAs)
IT departments and the organizations they support often find a lack of communication and coordination in their objectives. The purpose of an SLA is to create and document a set of standards that are agreed upon by business and technical staff. When executed properly, SLAs help manage expectations and ensure that IT departments remain aligned with the organizations that they support. Figure 1 provides an overview of the general steps that are part of an overall SLA process.
Perhaps the most important point to remember is that the SLA process is a continuous one. As organizations’ needs change, so too should their SLAs.
Defining SLA Terms
Creating an SLA is a negotiation process (and should rarely devolve into “aggressive negotiations,” the kind that are resolved with a light saber). For example, when asked about how much data loss and downtime is acceptable for a particular application, the first answer is typically “zero.” Add in information about costs of high-availability and continuous data protection options, however, and you’ll probably get a more reasonable response.
The goal here is to focus on what’s important for the business and for end-users, rather than on technology. Defining what needs to be done is the goal of the SLA development process. How these goals are best met is the job of IT. If you’re talking about clustering or real-time replication with a pointy-haired boss, you’ve missed the point. Typical goals are based on metrics that are useful to the business. Figure 2 provides some examples.
Developing Metrics
Once the high-level goals for SLAs have been defined, it’s time to get into the details. Organizations should develop metrics and targets based on business requirements. It is important to include meaningful numbers so you can track the performance of the IT department. Table 1 provides some examples of SLA goals and metrics.
|
SLA Area
|
Metrics
|
Goal
|
Notes / Terms
|
|
Service Desk: Level 1 Issue Resolution
|
Issue Resolution Time
|
4 business hours
|
Status will be communicated at least once
per hour
|
|
Service Desk: Level 2 Issue Resolution
|
Issue Resolution Time
|
8 business hours
|
Time is measured from original submission
of issue to the Service Desk
|
|
New Physical Server Deployments
|
Time to deployment
|
7 business days
|
Time is measured from when final approval
is obtained.
|
|
New VM Deployments (Basic Configuration)
|
Time to deployment
|
2 hours
|
Virtual machines must use on of the three
standard configuration profiles
|
|
New VM Deployments (Unapproved OS
or applications)
|
Time to deployment
|
2 business days
|
Additional time may be required based on
specific OS and application requirements
|
|
Intranet Server Availability
|
Uptime
|
99.9% availability during business hours
|
Excludes planned maintenance windows
|
Table 1: Examples of SLA Metrics and Goals
Using SLAs to Reduce Costs
One of the reasons that IT departments tend to shy away from defining SLAs is the fear of missing goals. This is an important risk, but it should be understood that it is the entire organization’s responsibility to provide adequate funding and resources to meet those goals. High-availability, redundancy, load-balancing, and rapid deployment technology can be expensive. Based on costs, it’s typical to review and revise some of the goals.
Once an IT department truly understands what’s important to the organization as a whole, it can start to look at areas for improvement. Here’s where SLA details can help reduce costs and improve service levels for the areas that really matter.
|
Product or Service
|
Proposed Improvement
|
Current Cost or Service Level
|
New Cost or Service Level
|
Benefit(s)
|
|
VM Deployment
|
Investment in automated deployment tools
|
$150 / VM
|
$60 / VM
|
- Reduced VM deployment time
- $90 savings per VM deployed.
|
|
Physical Server Deployment
|
Automated server deployment tools
|
$450 / server
|
$125 / server
|
- Reduced physical server deployment time
- $325 savings per server deployed.
|
|
VM Performance Management
|
Automated host/VM monitoring tools
|
40% reserved capacity on host servers
|
20% reserved capacity on host servers
|
- Fewer performance problems
- Reduced costs through increased server utilization
|
|
Support Desk Issue Resolution Times
|
Implementing an automated Service Desk application
|
~4 hours (for Sev. 1 issues)
|
~1.25 hours
|
- Better tracking of all VMs
- Quicker resolution of problems
|
Table 2: Possible cost reductions based on SLA terms
In addition to the tangible cost and time savings, investing in management tools can free up system administrators’ time for working on more important tasks. Of course, the most important point is for everyone (business and IT management) to agree that these investments are worthwhile.
Reviewing and Revising SLAs
SLA terms and metrics should evolve along with business needs. Ideally, organizations will regularly review the current terms, metrics, and priorities and update them based on current requirements. As mentioned earlier, IT specialists should focus on those items that provide the greatest benefit or impact to their users.
Implementing Charge-Backs
Like it or not, many IT departments are seen as cost centers. They provide mission-critical IT infrastructure, but they’re always asking for more money. A good solution would help distribute costs based on the areas of the business that require specific technology.
When using charge-backs, IT departments “bill” their internal “customers” for services that are provided. Does a new VM deployment need to be expedited because no one told IT about the need two weeks ago? There would be an additional charge for that. Does a department have a pressing need to support Windows Me on a product host server? Since it’s not part of a default supported configuration, there are additional deployment and administration costs. IT departments should work as if they were service providers and treat their internal users as customers. The success of this “internal business” is dependent upon providing high levels of service.
Implementing charge-backs will certainly involve some level of overhead. In many cases, however, the additional effort is justified by making the entire organization responsible for containing costs. And, from an accounting standpoint, you can easily identify potential areas for cost reductions.
Summary and Conclusion
Whether your organization grows plants on Dagobah, provides hosting services to the Sith Lords, or builds Death Stars, virtualization can help improve overall operations. The key concern is retaining manageability of the environment. SLAs and charge-backs can help ensure that IT organizations remain in a strategic role within an organization and that they remain aligned with users’ needs.
While the deployment of virtual machines can provide your IT organization with A New Hope, The Phantom Menace of managing costs can be even more complicated when you’re dealing with virtualization. In some ways, you’re faced with fighting an Attack of the [Virtual] Clones. SLAs and charge-backs can provide you with A New Hope. When The Empire Strikes Back, use the powers of IT management to improve service levels for everyone.
Notes
Biography
Anil Desai is an independent consultant based in Austin, TX. He specializes in evaluating, implementing, and managing solutions based on Microsoft technologies. He has worked extensively with Microsoft's Server products and the .NET development platform and has managed environments that support thousands of virtual machines. Anil is an MCITP, MCSE, MCSD, MCDBA, and a Microsoft MVP (Windows Server – Management Infrastructure).
Anil is the author of numerous technical books focusing on the Windows Server Platform, Virtualization, Active Directory, SQL Server, and IT management. He has made dozens of conference presentations and is also a frequent contributor to online and print publications. For more information, please see http://AnilDesai.net, or e-mail
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
.
|
