Best Practice for Establishing Policy and Metric Baselines


If you first begin defining policies regarding desired service levels and objectives, the resulting procedures are more easily created and implemented. Essentially, policies and procedures define how the system is supposed to be used ”establishing guidelines to help users understand that the system can't be used in any way they see fit. Many benefits are derived from these policies and procedures. For example, in an environment where policies and procedures are working successfully and where network performance becomes sluggish , it would be safer to assume that groups of people aren't playing a multiuser network game, that several individuals aren't sending enormous e-mail attachments to everyone in the global address list, or that a rogue Web or FTP server wasn't placed on the network.

Network performance is a combination of both individual uses of the system just as well as IT department optimization. Therefore, it's equally important to gain an understanding of user expectations and requirements through interviews, questionnaires, surveys, and more. Some examples of operational policies that can be implemented in a networking environment pertaining to end users could be the following:

  • Only certain applications will be supported and allowed on the network.

  • E-mail message size can't exceed 2MB.

  • Beta software can be installed only on lab equipment (that is, not on client machines or servers in the production environment).

  • All computing resources are for business use only (in other words, no gaming or personal use of computers is allowed).

  • All home directories will be limited to 300MB per user.

  • Users must request assistance through a managed helpdesk rather than try to apply patches, fixes, or conduct system repairs on their own.

Policies and procedures, however, aren't just for end users. They can also be established and applied to IT personnel. In this scenario, policies and procedures can serve as guidelines for technical issues, rules of engagement, or simply an internal set of rules. The following list provides some examples of policies and procedures that might be applied to the IT personnel:

  • System backups must include System State data and should be completed by 5 a.m. each workday .

  • Routine system maintenance should be performed only on Saturday mornings between 5 and 8 a.m.

  • Basic technical support requests should be attended to within two business days.

  • Priority technical support requests should be attended to within four hours of the request.

  • Technical support staff should use Remote Desktop on client machines first before attempting to solve the problem locally.

  • Any planned downtime for servers must be approved by the IT management at least one week in advance.

Benchmark Baselines

If you've begun defining policies and procedures, you're already cutting down the number of immeasurable variables and amount of empirical data that challenge your decision-making process. The next step to prepare for capacity analysis is to begin gathering baseline performance values.

Baselines give you a starting point against which to compare results. For the most part, determining baseline performance levels involves working with hard numbers that represent the health of a system. On the other hand, a few variables coincide with the statistical representations such as workload characterization, vendor requirements or recommendations, industry-recognized benchmarks, and the data that you collect.

Workload Characterization

It is unlikely that each system in your environment is a separate entity that has its own workload characterization. Most, if not all, network environments have systems that depend on other systems or are even intertwined among different workloads. This makes workload characterization difficult at best.

Workloads are defined by how processes or tasks are grouped, the resources they require, and the type of work being performed. Departmental functions, time of day, the type of processing required (batch or real-time), companywide functions (such as payroll), volume of work, and much more can be characterized as examples of workloads.

So why is workload characterization so important? Identifying system workloads enables you to determine the appropriate resource requirements for each of them. This way, you can properly plan the resources according to the performance levels the workloads expect and demand.

Benchmarks for Performance Analysis

Benchmarks are a means to measure the performance of a variety of products, including operating systems, virtually all computer components , and even entire systems. Many companies rely on benchmarks to gain competitive advantage because so many professionals rely on them to help determine what's appropriate for their network environment.

As you would suspect, sales and marketing departments often exploit the benchmark results to exaggerate the performance or benefit of a technology solution. For this reason, it's important to investigate the benchmark results and the companies or organizations that produced the results. Check to make sure that the benchmarks are consistent with other benchmarks produced by third-party organizations (such as magazines, benchmark organizations, and in-house testing labs). If none are available, you should try to gain insight from other IT professionals or run benchmarks on the product yourself before implementing it in production.

Although some suspicion might arise from benchmarks because of the sales and marketing techniques, the real purpose of benchmarks is to point out the performance levels that you can expect when using the product. Benchmarks can be extremely beneficial for decision-making, but they shouldn't be your sole source for evaluating and measuring performance. Use the benchmark results only as a guideline or starting point when consulting benchmark results during capacity analysis. You should also pay close attention to their interpretation.

A list of companies or organizations that provide benchmark statistics and benchmark- related information along with some tools for evaluating product performance include

  • Transaction Processing Performance Council (http://www.tpc.org/)

  • eTesting Labs (http://www.etestinglabs.com/)

  • Computer Measurement Group (http://www.cmg.org)



Microsoft Windows Server 2003 Insider Solutions
Microsoft Windows Server 2003 Insider Solutions
ISBN: 0672326094
EAN: 2147483647
Year: 2003
Pages: 325

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net