Preparing for Infrastructure Management (Part 1)

Unit 5: Preparing for Infrastructure Management
Identifying System Components: [Chap 3 : high-availability-design]
To improve system availability, first identify all the system components that work together to enable a user's
application to run. A chain is only as strong as its weakest link. If your system has one component that is
prone to failure, your entire system is prone to failure
Most systems can be divided into the following elements:
• Host or server—. This is the portion of the system where most data is stored or processed. The
server fulfills transaction requests sent to it and sends the results to the requestor of the transaction.
For example, in a bank Automated Teller Machine (ATM) system, the host is usually the bank
mainframe system, or large server, that manages client bank accounts and transactions.
• Client—. This is the component that makes a request from the server. In our ATM example, the
client is the ATM machine.
• Network—. This is the component that allows the client to communicate with the server, and vice
versa. In our ATM example, the network is typically a combination of a private network, the public
telephone network and all associated communication equipment.
For each of these areas, examine all components: hardware, software, environment, processes and
procedures, and personnel.
Hardware is the physical equipment making up the system. It includes, but is not limited to, the following:
• Central processing unit—. The device that controls the operation of the computer system or other
intelligent equipment
• Storage devices—. Data repositories, whether permanent or volatile media, such as memory and
hard disks
• Input devices—. Components for receiving commands or data from users or other equipment, for
example, keyboards, mice, and serial ports
• Output devices—. Components for presenting data to the user, such as monitors, speakers, and
printers
• Cables—. Often neglected but crucial to the reliability of any computer system
Software consists of the programs running in the system that enable it to perform its functions, including:
• Firmware—. Software embedded in hardware, acting as the interface between hardware resources
and the operating system. In PCs, this software is also called the Basic Input/Output System (BIOS).
• Operating system—. Core programs that allow applications to run on a computer without directly
interfacing with the computer's hardware components. Common operating systems include Windows
95/98, Windows 2000, UNIX, Linux, OS/400 and OS/390.
• Utilities—. Software that performs housekeeping and system control functions. Normally, system
administrators or maintenance staffers use these programs.
• Programming software—. Software that supports the creation of applications, including languages
such as C++, Java and COBOL, and development tools such as Microsoft Visual Studio.
• Applications—. Programs designed to perform user-specified tasks or operations. These programs
may be written by the company (in-house applications) or purchased from a software vendor (off-
the-shelf or shrink-wrapped software).
• Middleware—. Programs supporting communication or data exchange between multiple programs
or computer systems.
Environment is the external equipment the system needs in order to run:
• Power—. Including automatic voltage regulators, uninterruptible power supplies, generators, surge
suppressors, and lightning arrestors
• Cooling—. Including air conditioning units and dehumidifiers
• Floor space—. Including raised flooring and secured access areas

Processes and procedures are the operational activities needed to run the system. These include, but are not
limited to:
• Activation—. Including power up, system initialization, application startup, and verification of
system activation
• Operation—. Including resource management, input/output control, job control, and network
management
• Systems management—. Including system monitoring and change administration
• Housekeeping—. Including backup and restore, as well as archiving of data
• User management—. Including user and security administration
• Deactivation—. Including application shutdown, system shutdown, and power down
People refers to those who interact with the system:
• Users—. Including both internal and external users
• System support staff—. Including operators, system administrators, programmers, technical
support professionals, and others
• Vendors and suppliers—. Including electricity vendors, equipment suppliers,
telecommunications providers, and others
Addressing Critical Components
After you identify all relevant system components, the next step is to find the critical system components, those that
represent single points of failure for the system. When these components encounter a problem, the entire system is
affected.
Several approaches are available for reducing the risks associated with these critical components:
• Reduce outage frequency—. Look for ways to prevent outages from happening to that critical component,
thereby increasing its reliability.
• Minimize outage duration—. If outages cannot be entirely avoided, find ways to recover immediately from
them, thereby improving recoverability. If recovery is impossible, ensure that the component can be
immediately repaired. In other words, improve serviceability.
• Minimize outage scope—. Minimize the parts of a system that are impacted by an outage.
• Prevent future outages—. Reduce the potential for users and other external factors to affect system
availability, and make it easier to maintain the system's health by addressing its manageability.
The Four Elements of Availability
From the preceding section, we can define four elements of availability:
• Reliability—. The ability to perform under stated conditions for a stated period of time
• Recoverability—. The ability to easily bypass and recover from a component failure
• Serviceability—. The ability to perform effective problem determination, diagnosis, and repair
• Manageability—. The ability to create and maintain an environment that limits the negative impact people
may have on the system
Summary
To devise an effective plan to address system availability, you must first understand the entiresystem, and how
each component affects overall system availability. By then identifying the most criticalsystem components, you
can intelligently set priorities. Remember that no matter how insignificant a system component may seem, it can have
a profound effect on overall system availability. Once you identify the most critical components, seek ways to
improve their reliability, recoverability, serviceability, and manageability.

Exist Processes, Data, Application, Tools and their Integration: [Chap 4 : high-availability-design]
Systems Management is the combination of processes, data, tools, and organization needed to manage a
system efficiently and effectively. Processes deal with how to perform the task. Data refers to the
information required to perform the process. Tools are the equipment needed to perform the processes.
Organization refers to the people that support the process and how they are set up to do so.
Systems management is not merely a set of procedures for running a system, rather, it integrates all four
elements mentioned above. We have seen too many IT organizations come up with exhaustively detailed
procedures, yet fail because they have not tackled all four key elements. To illustrate, let us review examples
of implementations that lacked one or more of these elements:
• Process element ignored—. Many help desks have no escalation procedures. Obviously, this leads
to many complaints by users (and their management), when severe problems do not receive
appropriate attention and support. To add insult to injury, in many cases, IT management only
becomes aware of these problems when users complain.
• Data element ignored—. Often, help desks fail to adequately identify the data they need to gather
from users. One help desk had more-than-adequate staffing, and clear procedures for handling calls.
However, nobody quite knew what information to request, and there was no standard form for
recording details. Whenever the caller's problem was passed to technical support, the support person
usually had to call the user again for more information. Problem resolution was delayed,
productivity suffered, and users were dissatisfied. Eventually, users decided that calling the
centralized help desk was a waste of time, and began calling support specialists directly.
• Tool element ignored—. This is the most comman systems management mistake IT organizations
make— they erroneously believe you can simply throw bodies at the problem. One organization's
help desk was in total disarray because the help desk staff was demoralized. We discovered they had
no computerized means of recording and tracking calls — they were simply using a paper-based
logbook. When management asked for weekly reports, the help desk staff needed a whole day
simply to sort and filter their call records. Adding staff simply led to more paper shuffling, and even
more lost call information.
• Organization element ignored—. Many IT organizations seem to think that you can have an
effective help desk simply by seating people in front of a phone to answer user calls. They fail to
recognize that it is also important to organize the people making up the help desk. Organizing a
help desk includes identifying the appropriate staffing and skills requirements, creating clear
reporting lines within the help desk organization, and distributing responsibilities efficiently
amongst the help desk staff. Without the right people and the proper organizational structure, there
is little chance that calls will be handled properly. Moreover, there may be little cooperation among
the help desk staff. Calls will most likely pass from one person to another without ever getting
resolved adequately.
Systems Management in the PC World (or the Lack of It)
Systems management covers all aspects of an IT operation, from design and procurement of IT equipment to its
implementation, problem resolution, security, and much more. No matter how small your computing resource, you
need some form of systems management discipline in order to preserve system availability and maximize IT's value to
your business. Systems management may have evolved in the mainframe environment, but even a single PC can
benefit from well-implemented systems management techniques.
Consider your typical standalone PC. How many times did you have to reinstall your operating system because you
installed new software that changed system configuration files — and degraded the entire system? If you had
implemented even just the basic change management practice of creating a backup copy of system configuration files
before making changes, you could have easily undone the changes and restored your system to health. Newer
operating systems (notably Windows 2000) incorporate features that help protect configuration files from unauthorized
change. Upgrading to these operating systems may be worth serious consideration.
IT Organizations: Away from Centralization, Then Back Again
In the continuing wave of migration from mainframe-centric systems to distributed client-server systems, users have
initiated most of the migration. These users became fed up with the slow pace at which mainframe shops delivered
new applications. In the client-server world, they found many off-the-shelf software packages, tools for faster, easier
applications development; and lower upfront hardware and software costs. Unsurprisingly, they began making their

own purchasing decisions, disregarding centralized IT organizations.
As these new distributed systems have matured and grown, businesses have become extremely dependent on them.
Gradually, small problems — which users could easily deal with — grew in number and complexity. Users without
experience running mission-critical systems were faced with managing database backups, optimizing performance,
supporting large numbers of users, and many other difficult challenges. What was easy to deploy and manage
became extremely difficult to maintain and control. Increasingly, users are willingly relinquishing control of
their client-server-based systems to centralized IT organizations that "know more about managing these
systems than we do."
The lesson is simple — having the right hardware or software does not guarantee that you will always have the
system you need. You must consciously plan your system, and diligently manage it. Hence, the need for systems
management disciplines.
Understanding the Systems To Manage
To deploy the optimal systems management infrastructure, you must first thoroughly understand the system you
intend to manage. Knowing the technical aspects of your system is not enough. To design a cost-effective,
practical systems management infrastructure, consider the following points:
• How critical the system is to the business—. Greater criticality requires better systems management.
Consider how much of the business will be affected if the system is not available, in terms of lost
productivity, increased expenses, lost business opportunities, and erosion of customer satisfaction.
• Size of the system to manage—. Expect your systems management infrastructure to be increasingly complex
as system size increases. Size can be gauged in terms of the amount of resources (hardware, software,
people, etc.) being utilized, the amount of data being processed, or the number of users being served.
• Complexity of the system—. The more complex a system, the more difficult it is to manage. Complexity is
a measure of the number of different resources interacting and working with each other. A system can
be complex for many reasons. For example, it may be complex because multiple operating systems are in
use, or because many types of users are sharing the same set of applications (e.g., customers, suppliers,
managers, and staff). When multiple components are shared, there is greater risk of dysfunction or
reduced performance due to competition for scarce resources.
• Distribution of system components across different locations—. Increasingly, components are distributed
across servers and workstations in different buildings, cities, or even countries. Components that are widely
dispersed are more difficult to manage effectively. System management processes associated with
dispersed components are likely to be slower and more prone to failures.
• Ownership of resources—. It becomes more difficult to coordinate systems if many different owners have
the final say as to what is done, simply because you must get permission from many different people and
coordinate all their decisions and actions. In a highly distributed computing environment, it is common
to have different owners for the workstations, servers, communication facilities (often owned by a
telecommunications company or service provider), and many others.
• Security requirements—. Systems and information assets that must be protected introduce new
complexities, such as access control and authentication, making them more difficult to manage.
• Skill sets—. When devising a systems management infrastructure, consider not only the skills of the IT
organization, but also those of users. As systems become increasingly distributed, management
responsibilities may also be distributed, and everyone involved is likely to need new skills and training.
• New technologies—. Consider forthcoming technologies and your organization's long term IT goals, so
the systems management infrastructure you design will not be made obsolete by rapid change.
• Environmental dependencies—. It may be difficult or impossible to control the external environment in
which your systems operate, but you can limit the impact of changes in the external environment on the
operations of your systems. For example, if the power supplied to your equipment is prone to outages, you
can deploy backup power generation facilities and establish procedures for switching to them.
• Standards—. You cannot deploy the right tools without considering corporate hardware and software

standardization policies. Also consider company operations rules, such as security guidelines and employee
management standards.
The Basics of Management: Five Phases
The traditional formula for effective systems management of any system, process, or activity comprises five
phases. These phases were identified based upon close examination of the key issues faced by managers:
• What activities must be performed everyday?
• How do we know these get done when they're supposed to?
• Who is responsible for performing each activity?
• How do we know if it's being done effectively and efficiently?
• Who tells management how it's going?
• Who gets blamed if things don't go right?
• How can you improve what you're doing?
The five phases of management activity related to systems management are described in the following sections.
Phase 1: Setting Objectives
The first and most important phase is setting objectives. Here, we determine the requirements of the business and
end users. Without properly determining what needs to be achieved, it is nearly impossible to execute the other phases
effectively. You must understand user objectives, so your plans and activities support them.
Alice in Wonderland provides a wonderful lesson. Lost in the forest, Alice came upon a fork in the road and asked the
Cheshire Cat which road to take. The Cheshire Cat's answer, in paraphrase:
“It does not matter which road you take if you don't know where you are going.”
In mature IT organizations, setting objectives often takes the form of defining Service Level Agreements —
enumerating the different services to be provided to the users, and corresponding attributes such as
performance, availability, and features.
Phase 2: Planning
In the planning phase, based on the objectives determined above, you define a plan to meet those objectives. This plan
usually covers the resources to be deployed, the activities to be done, the measurements to be tracked, the tools to
be used, and how the people are to be organized. Again, we cannot overemphasize the need to address the four
elements of systems management: process, data, tools, and organization.
Phase 3: Execution
In the execution phase, we actually perform the steps that were planned in Phase 2.
Phase 4: Measurement
In this phase, we record relevant data regarding the execution of the plan. Many different measures can be
tracked, falling into categories such as performance (speed of execution of a task), capacity (number of
concurrent tasks executed), failures (number of problems, frequency of problems, areas affected by problems,
number of repeat problems, number of detected problems, etc.), and recovery (problem resolution time).
Phase 5: Control
The control phase gives the manager a means to correct the first four phases on an ongoing basis. In this phase, you
can verify whether the measurements meet your objectives. Here, you can reexamine and refine your plans to
more effectively support achievement of your objectives, and eliminate execution problems. You can review how
you execute your plans, to ensure that the execution has not, itself, caused availability problems. Finally, you can
reevaluate your objectives to determine whether they should be upgraded or downgraded, to more effectively
balance user requirements against what can actually be achieved.
Phase 5 never ends. Rather, it circles back to Phase 1, giving the manager necessary information for revisiting
phases one through four, and creating a closed-loop process. If you skip any of these phases, your management
system is likely to become obsolete quickly.
The control phase is crucial to ensuring that the system is consistently managed well. Many IT shops develop excellent
plans and objectives, and perform extremely well when they first implement their plans. Since they fail to check on
what is happening, however, changing technology, environment, and user requirements leave their management
systems behind.

All five phases are interdependent. If you fail to get an accurate picture of user requirements in Phase 1, your
plans will be misdirected and insufficient. If you skip planning in favor of early execution, your activities will
lead to resource conflicts and poor performance measurements. If managers fail to monitor the process, they
cannot determine its ongoing effectiveness.
Identifying the Systems Management Disciplines
If we apply the fundamentals of management to information systems management, we can tabulate the systems
management disciplines necessary in any system, big or small. The only difference is how extensively the disciplines
are implemented.
The nitty-gritty (importance) of procedures, data, tools, and organization to support these disciplines can differ
dramatically for each organization.

Preparing for Infrastructure Management (Part 1)

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Preparing for Infrastructure Management (Part 1) (20)

More from Shipra Swati (20)

Recently uploaded (20)

Preparing for Infrastructure Management (Part 1)