Auditing is often seen as mindlessly bureaucratic and something of a waste of time imposed on us by regulators and compliance wonks. However, used effectively, auditing can be a powerful tool.
The purpose of an audit trail is to answer questions. Obviously, it is most effective if (a) it is set up to answer questions that people are actually likely to ask, (b) you are aware of those questions and bear them in mind when you’re actually filling in the form, and (c) your audit trail gives you tools to help you data mine the answers to those questions easily.
Source control is one example. Some people like to set up their source control policies so that every changeset has to be referenced to an item in the issue tracker, so that they can answer the question, “Which changesets fixed this bug?” While this is useful information to have, it isn’t the kind of question that people ask all that often. The kinds of questions people are likely to ask from your source control system are (a) “Which changesets introduced this bug?” and (b) “Who wrote this line of code, and why?”
Change management is another example. Change management is sometimes scorned by some agilists as overly bureaucratic and pointless, but it only becomes that way if it’s implemented without any specific questions in mind. Here are some questions that an effective change management process can answer, for example:
- What services are running on this server?
- Who would know about the services that are running on this server?
- I’ve run into a problem while making a change to this service, has it happened before, and if so how was it fixed?
Most of these questions concern specific resources, such as servers, software, build images, subnets, routers etc. A good change management system will let you tie these specific resources to specific changes, and will let you quickly search through them and get answers to these questions.