The following is an excerpt from Chapter 9 of the book Mining New Gold - Managing Your Business Data by Penny, Jeffrey and Gillian Garbus which can be purchased here.
How often do you set up a maintenance schedule for your data environment? What about management processes? The truth is that the first time you do it, it’s very possible to feel overwhelmed. Or if you’ve never done it, you may be trying to figure out where to start.
In hopes of making things easier for you, we’re sharing how to begin the process of evaluating the importance of your environment workload, your data, environment, and servers.
Creating Safe Data Environments
1. Create a list of what you consider to be environments that contain core data.
Which data is crucial to keeping your business up and running daily? Which databases run reports that are critical to cash flow? Which data needs to be backed up, secured, and follow government regulations and auditing processes? These are a high priority data environment.
Once you flesh this out, set up a maintenance and management plan for these environments. Typically, these are databases that are stored on production servers. Be precise about this as your business grows.
If some production environments have replicated, failover, mirrored servers or warm standbys, you may want to set up the maintenance plans in advance so that they can be quickly turned on when or if they get called into action.
2. Create maintenance plans for your test, development, and support environments.
After you have production, cash producing, and an audited environment set up and maintained, you can then focus on creating maintenance plans for your test, development and support environments.
Our mantra is: If you’re storing code, methodologies, or need to be able to restore any system to the moment before a crash, you should create a backup and maintenance schedule for that environment.
3. Regularly review your procedures and adjust as your needs change.
Doing a yearly spring cleaning will allow you to determine whether your production data environment ran out of space last year, or whether the IT and business teams are using a drive on the development server for backups or for general storage.
4. Back up and maintain all environments.
Our advice is to backup and maintain all environments. If your developers are using scrum methodologies for application releases and updates, you want to watch those development servers because if you are using scrum, your users are expecting rollups to fix issues quickly. Otherwise, a lost development server can cost time and money. Therefore, at least back up the development servers daily and do integrity checks to make sure nothing has become corrupted.
If there are inactive development servers, back them up at least so your code is saved.
You often will find backing up development servers is as important as backing up your production servers; losing a development server can mean losing months of work, times dozens of developers.
Let Case Studies Serve as Warning Stories About Data Loss
You can’t talk to anybody in the IT industry without hearing stories about data becoming corrupt because of issues with poor care.
As examples, we’re sharing a couple of recent cases:
Many of our customers have come from partner referrals. One recently came to us because a database became corrupted. Once they identified the corruption, they looked for backups, only to find out that the backups also had been corrupted too.
The damage was so expansive, this company furloughed 1,200 of their 1,400 employees. In fact, they were getting ready to shut down operations before we came in and were able to mine data from the corrupted database.
In another case, we on-boarded 120 servers for a customer. As part of the process of validating databases, we found three corrupted databases: They were returning bad data unknown to application users. We cleaned these up, but it should never have gotten to this stage.
At a recent health check, as a small part of the performance work, we were asked to take a few minutes to look at a system that was being used by 3,000 customer service representatives.
These reps were downloading 30 days of scheduling data each evening. It was taking more than 30 minutes and getting longer, and the handheld Internet connectivity was timing out in many cases, requiring a restart.
With minor index changes, we were able to take down the performance to under 2 minutes, saving 1,500 man-hours each night. The only “downside” were the 3,000 calls they got that evening asking if something was wrong or whether it was fixed. They told us it was the best 3,000-call night of all time.
As we move about in our daily work activities, we sometimes forget to slow down and look at data.
Key Takeaways
Any data that affects your bottom line should always be a priority. From there review, discuss, and create processes and procedures for other data environments. The reality of how each environment supports your business and job will dictate the amount you spend managing and maintaining that data.
