Vibrant MCSE BOOT Camp Notes :
Back : Contents : MCSE :

Using Sound Engineering Practices

After you are conversant on the technical issues, you must adopt an engineer's attitude. Each person working on the implementation must understand and religiously follow a few basic principles:

• Never throw anything away. No manual, disk, paper, or connector is insignificant enough to toss. Often the hastily written notes of someone else or the one-page errata sheet that came with the manual has exactly the information you're looking for. Don't throw out accessories until you no longer own the product.
• Always make a copy. No file is too inconsequential, no storage space too full that you cannot make a copy. Any file you edit, especially any configuration or system file of any kind, should always be copied first. For files you modify often, create a directory just below them in the tree that contains all the old versions. Often an error made in a system file won't show up until another change is made. If you only have the last version, the error is still there. Copy first, edit later.
• Have all the relevant materials with you before you begin. Nothing makes a job more frustrating than finally figuring out how to solve the problem and then realizing that it involves leaving what you're doing to get the part you need. Always imagine a very broad scope for any problem you're working on and get all materials you might need.
• Always prevent disaster. A physician takes an oath to do no harm; engineers should take an oath to always prevent disaster. Make sure that whatever you do to the system, you will not make it any worse. Also, ensure that regardless of what you do to the system, you're still capable of restoring it to its present level of operation. Not having a path back to where you were can easily get you lost in the labyrinth of the system.
• Troubleshoot by science, not voodoo. If you are unfamiliar with the scientific method, read up on it. Nothing is more embarrassing than naming the cause of the problem and eliminating it, only to have the problem recur. If you have a hypothesis, test it. If you believe you have found the cause and solution to the problem, cause and solve it again (assuming that you can do this without too much disruption). Never assume that because you were working on the problem and the problem went away that you actually solved it.
• Don't create voodoo for someone else. If a problem goes away and you are not sure that you solved it, don't insist that others follow your methods. If you have not tested a patch or method, do not insist that it really does what you say. People have a way of following procedures that make no sense, so try to avoid creating procedures that in reality do nothing.
• Test first; implement second. Any changes you are going to make to any system should be tested first if at all possible. Either set up a special system as a test platform or isolate the part of the system you will use and use it to test. No amount of hassle in setting up a testing area can be compared to the aggravation of trying to repair the damage from an untested product.
• Create an isolated test area. Remember that any test area you create must be isolated from causing damage to the system as a whole.
• Eliminate single points of failure. Identify functions outlined in your plan and list the system components involved in delivering those functions. Use that list to identify "single points of failure"-that is, any place where the failure of a single component will end that function. In other words, if a single disk crash will stop all of your Web service, that disk is a single point of failure. You would need a second disk to use in an emergency and backups of the failed disk.

back