Edit: Still useful information.
Standards and checklists can take effort to maintain but, once in place, all of your builds look identical.
Originally posted January 2007 by IBM Systems Magazine
Note: This is the second of a two-part article series. The first part appeared in the December, 2006 EXTRA.
In my first part of this article series, I explained the importance of establishing good server build standards, along with a mechanism to enforce those standards. I also explained the importance of putting in place a checklist to ensure the standards are met in a consistent manner. This second article installment looks further into server build standards.
The Benefits of a Good Server Build
Standards and checklists can take a great deal of effort to maintain but, once in place, all of your builds look identical. The actual time it takes to deploy a server is minimized. Administrators are then free to work on other production issues instead of spending a great deal of time loading machines. When you’re only deploying a server once in a while, this might not be a big deal. But when you start to deploy hundreds of machines, your application support teams are going to appreciate your consistency. If two administrators are building machines – and each machine looks slightly different – your end users won’t know exactly what to expect when a machine gets turned over to them. They spend time asking for corrections and additions to the machine that should have been completed when the server was loaded. This makes your team’s work product look shoddy, as you’re not consistently delivering the same end product.
People who use the machines should come to expect the new server builds will have the same tools and settings as all the other machines in the environment. When the database team is ready to load their software, and find file systems or userids missing, it makes their job more difficult, as they’re not sure what to expect when they first get access to the machine.
Be Consistent
Besides the server builds, the actual carving up of LPARs should be consistent. Sure, some machines might be using “capacity on demand,” and some might want to run capped or uncapped, but when these decisions are made, document them so people know what to expect in the different profiles. If you explain why you chose the setting, people are less likely to change it. Likewise, if you tell them why you chose shared processors and why the minimum and maximum number of processors look the way they do, they’ll be less likely to mess with it.
So how do you get people to actually follow the standards and documentation you’ve been maintaining? Make sure it’s easy to follow. The new person who joins your team should be able to quickly get up to speed on what you’re doing and why. This will make them a more effective member of the team in less time. When people make mistakes, or blatantly ignore the standards, call them out on it; maybe privately at first, but if it continues, I think the whole team should be made aware that a problem exists. Maybe there’s a good reason the standards aren’t being followed. Maybe they’ve been to class and learned something new. If this is the case, there should be some discussion and consensus as to how the documentation and standards should change.
The documentation your team maintains should obviously focus on more than just server builds. The more quality procedures and documentation you can create, the easier your job is going to be over the long term. If you have a well written procedure, you can easily remind yourself of what you did six months ago, and which files you need to change and which commands you need to run to make changes to the system today.
Some members of the team have stronger documentation skills than others. Some members of the team may have very strong technical skills, but their writing skills may not be as effective. This shouldn’t automatically get people off the hook, but if they really don’t have a good grasp on the language, or just have problems getting documentation onto paper, maybe they need to work together with someone who has more skill in that area. Maybe there needs to be a dedicated resource that works on creating and maintaining the documentation. Obviously every team will be different. The key to making effective use of documentation is to make it easily available (especially when on call or working remotely) and making it easily searchable.
When you are able to quickly and easily search for documentation, and everyone knows exactly where it is, it is more apt to be used. Instead of reinventing the wheel, people should be able to quickly find the material they need to do their jobs. In some cases, a very brief listing of necessary commands may be very helpful in troubleshooting a problem. It’s also helpful to have a good overview of common problems, how things should behave normally, and where to go for further information if they’re still having problems.
Once the documentation and the golden image are in place, your team can start looking for other ways to automate and enhance the environment they work in. There are always better ways to do things. Just because something is the way things are done today doesn’t mean it’s the best way to get things done. With an open mind, and a fresh set of eyes, sometimes we can more easily see the things around us that could use improvement. Then it’s just a question of making the time to make things happen. Sometimes it requires small steps, but with a clear vision of how things should look, we can make the necessary adjustments to make things better.