Information Technology Reference
In-Depth Information
Chapter 2. Designing for Operations
Your job is to design systems that operate.
—Theo Schlossnagle
This chapter catalogs the most common operations tasks and discusses how to design for
them. It also discusses how to rework an existing architecture that was not designed with
operations in mind.
Designing for operations means making sure all the normal operational functions can be
done well. Normal operational functions include tasks such as periodic maintenance, up-
dates, and monitoring. These issues must be kept in mind in early stages of planning.
When you consider the full life cycle of a given service, only a small portion of that life
cycle is spent building the features of the service. The vast majority of the life cycle is spent
operating the service. Yet traditionally the operational functions of software are considered
lower priority than features, if they are considered at all.
Thebeststrategyforprovidingahighlyavailableserviceistobuildfeaturesintothesoft-
warethatenhanceone'sabilitytoperformandautomateoperationaltasks.Thisisincontrast
to strategies where operations is an after-thought and operations engineers are forced into a
position of “running what other people build.” That's the outdated way.
2.1 Operational Requirements
Softwareisusuallydesignedbasedonrequirementsrelatedtowhattheultimateuserwillsee
and do. The functionality required for smooth operations is rarely considered. As a conse-
quence, systems administrators find themselves lacking control points for key interactions.
When we design for operations, we take into account the normal functions of an infrastruc-
ture life cycle. They include, but are not necessarily limited to, the following:
• Configuration
• Startup and shutdown
• Queue draining
• Software upgrades
• Backups and restores
• Redundancy
• Replicated databases
Search WWH ::




Custom Search