New Year's Resolutions for Library Web Types
So, I've had a week to think about personal and professional resolutions-can't rush in to these things, you know. Personally, it's to get my house in order. Literally. I spent most of Saturday with my very patient 6-year-old daughter scouring Target and hardware stores in the southern burbs of Denver for two gigantic tubs that would hold the parts of our artificial Christmas tree. At every store, sales were not only on discounted holiday items, but on plastic bins of every fathomable size, shape, and color. How very nice of major retail to support my quest for organization!
Professionally, I'm committed to breaking bad habits in my web "house" at work. Lots of us library web types are self-taught, at least initially. (And there seem to be a number of us who were English majors, I've noticed over the years.) It took me years before I had a true understanding of all of the non-sexy web work like project management, maintenance, backups, upgrades, etc. And as I've graduated to more and more complex web environments-from static HTML sites to CMSs-I've learned how this gets more and more complex along the way.
So, in the spirit of a week-late resolution, I invite you to consider the following with me. For some of you, this is old hat, second nature, no prob. Maybe you have IT support in your library, or as part of your parent organization, that takes care of all of this for you. For those of you like me, however, who came into this area of our profession sideways, spare yourself from anguish by following the resolutions below.
When's the last time you, or your IT support, ran a complete backup of your web presence? And ALL of it-public-facing site(s), intranet, client sites, etc. Where do you keep your backups? If they're stored off-site, how fast could you get your data back if you needed it immediately? Are you really backing up what you think you are; are your backups capturing everything you need them to?
Resolution: Create and adhere to a backup schedule. Every so often, in a test space, test your backup and restoration procedure. If you already have a backup plan/schedule in place, review it, and make sure it still meets your needs and adequately covers all of your web content. Automate backups as much as you can, and put those that you can't in your calendar as a reminder.
How up-to-date is your site, and its web server environment? Is the OS current and patched? If you use a content management system, are you keeping up the software stack that supports it (i.e., PHP, MySQL) as well as everything on the application layer and above?
Resolution: If you don't already have one in place, create a maintenance calendar that covers your site from the server environment up-even if the server environment is maintained by someone else. Make sure they are doing their part to patch, and upgrade, if necessary. Sites that are never upgrade eventually break in unrecoverable ways. Be sure to test major upgrades in a test environment.
What would happen, right now, if your web server went poof, irrevocably? If you have solid backups, do you have a procedure for disaster recovery, that includes the web platform itself? Keep in mind the effect on your blood pressure and state of mind that a sudden and unscheduled outage can cause; it will be a lot harder to "just figure it out" when everyone's waiting on the site to come back. What if your server environment is offline for days or weeks due to a physical problem where it's housed? And what if it's finals week, or the beginning of your summer reading program?
Resolution: Write a full disaster recovery plan, and more importantly, test, test, test it. Write procedures so that you're not the only person who can fix a crucial issue, and let them practice in a development environment. Don't have a development environment? Add that to your list of resolutions!
My web sites over the years have been mercifully disaster-free, but looking back, I know now that I was lucky. I did all of these things, but I didn't do them as methodically and rigorously as I could-no, should-have. At my last job, campus IT took database backups every night. But how was I supposed to get my hands on them after hours, when the IT help desk was closed? I didn't have access to their storage. Resolve to stop going half-in on backups, maintenance, and disaster recovery!