2. Establishing Policy and Metric Baselines
As mentioned earlier, it is recommended that
you first begin defining policies and procedures regarding service
levels and objectives. Because each environment varies in design, you
can’t create cookie-cutter policies—you need to tailor them to your
particular business practices and to the environment. In addition, you
should strive to set policies that set user expectations and, more
important, help winnow out empirical data.
Essentially, policies and procedures define
how the system is supposed to be used—establishing guidelines to help
users understand that they cannot use the system in just 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 but where network performance becomes sluggish, it
would be safe to assume that groups of people weren’t playing a
multiuser network game, that several individuals weren’t sending
enormous email attachments to everyone in the global address list, or
that a rogue web or FTP server was not placed on the network.
The network environment is shaped by the
business more so than the IT department. Therefore, it is equally
important to gain an understanding of users’ expectations and
requirements through interviews, questionnaires, surveys, and more.
Some examples of policies and procedures that you can implement in your
environment pertaining to end users could be the following:
• Email message size, including attachments, cannot exceed 10MB.
• SQL Server databases settings are enforced with Policy Based Management.
• Beta software, freeware, and
shareware can be installed only on test equipment (that is, not on
client machines or servers in the production environment).
• Specify what software is allowed to run on a user’s PC through centrally managed but flexible group policies.
• All computing resources are for business use only (in other words, no gaming or personal use of computers is allowed).
• Only business-related and approved applications are supported and allowed on the network.
• All home directories are limited in size (for example, 5GB) per user.
• Users can receive IT support by filling out the technical support web form or through the advertised help desk phone number.
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 an internal
set of rules to abide by. The following list provides some examples of
policies and procedures that might be applied to the IT department:
• System backups must include system
state data and should be completed by 5 a.m. each workday, and restores
should be tested monthly for accuracy and disaster preparedness.
• Routine system maintenance should be
performed only outside of normal business hours (for example, weekdays
between 8 p.m. and 5 a.m. or on weekends).
• Basic technical support requests should be attended to within 2 business days.
• Priority technical support requests should be attended to within 4 hours of the request.
• Any planned downtime for
servers should follow a change-control process and must be approved by
the IT director at least one week in advance with a 5-day lead time
provided to those impacted by the change.
3. 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. The Microsoft
Baseline Security Analyzer (MBSA) is one tool that performs a security
compliance scan against a predefined baseline.
Baselines give you a starting point with
which you can compare results. For the most part, determining baseline
performance levels involves working with hard numbers that represent
the health of a system. A few variables coincide with the statistical
representations, however, such as workload characterization, vendor
requirements or recommendations, industry-recognized benchmarks, and
the data that you collect.
Workload Characterization
Workloads are defined by how processes or
tasks are grouped, the resources they require, and the type of work
being performed. Examples of how workloads can be characterized include
departmental functions, time of day, the type of processing required
(such as batch or real time), companywide functions (such as payroll),
volume of work, and much more.
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.
So, why is workload characterization so
important? Identifying system workloads allows 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
Benchmarks are a means to measure the
performance of a variety of products, including operating systems,
nearly 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 is appropriate for
their network environment.
As you would suspect, sales and marketing
departments all too often exploit the benchmark results to sway IT
professionals over their way. For this reason, it is important to
investigate the benchmark results and the companies or organizations
that produced the results. Vendors, for the most part, are honest with
the results, but it is always a good idea to check with other sources,
especially if the results are suspicious. For example, if a vendor has
supplied benchmarks for a particular product, check to ensure 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, 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 should not serve as 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. It is also recommended that you pay
close attention to their interpretation.
Table 1
lists companies or organizations that provide benchmark statistics and
benchmark-related information, and some also offer tools for evaluating
product performance.
Table 1. Organizations That Provide Benchmarks
