A long time ago I started working in a team of people as a general systems administrator. I worked in a team of six people managing a large, 1000+ node network with a number of servers. In my first exposure to SQL Server, we had a very unstable application that forced us to provide 24x7 support. With a couple of contractors, we had to ensure someone was on-site all the time, often working with Microsoft and our corporate developers to stabilize the applications. We were constantly trying new techniques to fix our application, and with staff stretched thin, we struggled to understand what might have happened in the previous 12 hours when we reported for work. At the time, I suggested leaving a text document on each server's desktop, updated with a note for each change.

That worked well and I brought that technique with me to future positions. In another job, we constantly remotely connected to systems, and having a standard file on the desktop was helpful. As we became more security conscious, and stopped using shared logins, we moved our logging to Exchange public folders. Every action taken by an admin needed to be cut and pasted into a new post. That wasn't a perfect system, but we built habits over time and we had an audit trail that helped us in understanding the changes we've made and assisted in troubleshooting.

Today I'm curious. I want to ask the question about the data corrections, those quick changes, those fixes that get production working. Do you log everything? Is there some system in place to ensure you know what's happening?

I've been wondering about this and thinking hard as the date for GDPR enforcement approaches. One of the items that I'd glean from the law's text is that any change to correct data, any quick fix made, needs to have an audit trail. We need to prove that we know who, when, and why this change occurred. This is especially important if a data subject requested some correction. You'll need to prove you actually performed the action.

I've never worked anywhere that some admin (including myself) completely avoided connecting to a production machine and making some change. Sometimes we've had great auditing, often not, but ad hoc fixes and changes, especially in the heat of an issue, are a fact of life. I've learned to deal with it and try to build lightweight habits to help me capture those changes.

Let me know today. How bulletproof is your auditing?

Join the debate, and respond to today's editorial on the forums

The Azure DTU Calculator asks you to capture these metrics for upload:

?Ref: Azure SQL Database DTU Calculator - click here

» Discuss this question and answer on the forums