Acquire best practices with this system administration handbook

Often, books published about IT are obsolete the moment they hit the shelves: modern technology moves too fast for physical publishing. However, this particular volume aims for longevity.

IT operations professionals assume many responsibilities to perform their role satisfactorily. New technologies require more training and new processes come with a learning curve -- but what about the IT ops staples, such as the help desk, server management and the dreaded on-call shift?

The third edition of The Practice of System and Network Administration: Volume 1: DevOps and other Best Practices for Enterprise IT, casually referred to as "The Sys Admin Handbook," is a comprehensive resource for IT ops teams. It provides general information and best practices -- rather than weighty discussions on temporal technologies or platforms -- relating to how sys admins can flourish in their job.

The third edition of this system administration handbook, published in 2016 and written by Tom Limoncelli, Christina Hogan and Strata Chalup, expanded the sections on workstation setup and server management. It also introduced a number of DevOps concepts -- all of which would still resonate with organizations undergoing DevOps transformation today.

"[We] want to make sure that these books are really about the fundamental underpinning," Limoncelli said. "You can take this information with you, no matter how your career grows and changes and how technology grows and changes."

Tom LimoncelliTom Limoncelli

The Practice of System and Network Administration covers basic IT operations building blocks and offers both new and veteran sys admins a guide to success -- and happiness, which holds its own dedicated chapter within the book. The book often frames information as a short case study or vignette to illustrate key points. For example, chapter 2 features a section on how to eliminate "Hell Month," the belabored and exhausting time of semi-annual deployments:

A company had a team of software developers who produced a new release every six months. When a release shipped, the operations team stopped everything and deployed the release into production. The process took three or four weeks and was very stressful for all involved. Scheduling the maintenance window required complex negotiation. Testing each release was complex and required all hands on deck. The actual software installation never worked on the first try. Once it was deployed, a number of high-priority bugs would be discovered, and each would be fixed by various 'hot patches' that would follow.

[We] want to make sure that these books are really about the fundamental underpinning.
Tom Limoncelliauthor

Even though the deployment process was labor intensive, there was no attempt to automate it. The team had many rationalizations that justified this omission. The production infrastructure changed significantly between releases, making each release a moving target. It was believed that any automation would be useless by the next release because each release's installation instructions were shockingly different. With each next release being so far away, there was always a more important 'burning issue' that had to be worked on first. Thus, those who did want to automate the process were told to wait until tomorrow, and tomorrow never came. Lastly, everyone secretly hoped that maybe, just maybe, the next release cycle wouldn't be so bad. Such optimism is a triumph of hope over experience.

Each release was a stressful, painful month for all involved. Soon it was known as Hell Month. To make matters worse, each release was usually late. This made it impossible for the operations team to plan ahead. In particular, it was difficult to schedule any vacation time, which just made everyone more stressed and unhappy. Feeling compassion for the team's woes, someone proposed that releases should be done less often, perhaps every 9 or 12 months. If something is painful, it is natural to want to do it less frequently.

To everyone's surprise the operations team suggested going in the other direction: monthly releases. This was a big-batch situation. To improve, the company didn't need bigger batches, it needed smaller ones.

While scenarios like the one above track a subject from problem to progress to resolution, this system administration handbook also follows up with more straightforward and objective lessons. For example, this particular scenario concludes with two lists of tangible benefits -- one for IT operations and the latter for the business overall -- of the shift to smaller, more frequent deployments. For example, IT's benefits include increased deployment speed and introduction of new features, the elimination of Hell Month and the newfound freedom to focus on important and strategic projects.

The Practice of System and Network Administration The Practice of System
and Network Administration

While there isn't a fourth edition in the works, there are a couple of significant changes or additions to the book that Limoncelli would like. For example, security should become a much bigger and more dedicated section, as IT security practices and protocols have evolved in the age of DevOps. Also, because this system administration handbook is over 1,000 pages long, one potential path forward is to break it into two volumes instead, said Limoncelli: one on help desk management and the other on server management.

Editor's note: This excerpt is from the third edition of The Practice of System and Network Administration: Volume 1: DevOps and other Best Practices for Enterprise IT authored by Tom Limoncelli, Christina Hogan and Strata Chalup, published with Pearson's Addison-Wesley imprint, November 14, 2016, ISBN: 9780321919168.

Dig Deeper on DevOps

Software Quality
App Architecture
Cloud Computing
SearchAWS
TheServerSide.com
Data Center
Close