October 2, 2012 at 2:24 pm
Presently we have no defined process or policy for changes to SQL Server instances and databases in our environment. I'm working on creating some written policy and procedure. This is desperately needed, and a high priority.
I'm curious what the rest of the community does in your own environments. Specifically, these are the major changes I'm initially looking at process for:
- SQL Server installations and removals.
- SQL Server instance and database configuration changes.
- Backup and restore requests.
- Permissions changes.
- Use of server-level roles.
- Regular security audits and review.
If anyone would be willing to share how you manage these (or other major database-related changes) where you are (and possibly indicate the industry you are in and size of the organization) I'd be grateful. Thanks!
October 3, 2012 at 7:51 am
I'm curious what the rest of the community does in your own environments. Specifically, these are the major changes I'm initially looking at process for:
- SQL Server installations and removals.
- SQL Server instance and database configuration changes.
- Backup and restore requests.
- Permissions changes.
- Use of server-level roles.
- Regular security audits and review.
Im in medium-large organisation and production changes are handled by ITIL practises. The change initiator or sys admin raises an RFC which is risk assessed and approved by all stakeholders. The change is recorded in a change calender on sharepoint.
Depending on the configuration change, this is normally approved by the DBA team leader.
Permissions and role changes are approved by the system owner or area manager in writing.
Audits / backups /restores are handled by a DBA.
SQL Installs are approved by the infrastructure manager to comply with licencing and DR resourcing.
October 3, 2012 at 11:02 am
foxxo (10/3/2012)
Im in medium-large organisation and production changes are handled by ITIL practises. The change initiator or sys admin raises an RFC which is risk assessed and approved by all stakeholders. The change is recorded in a change calender on sharepoint.Depending on the configuration change, this is normally approved by the DBA team leader.
Permissions and role changes are approved by the system owner or area manager in writing.
Audits / backups /restores are handled by a DBA.
SQL Installs are approved by the infrastructure manager to comply with licencing and DR resourcing.
Perfect. Thank you! Anyone else?
October 3, 2012 at 11:46 am
I have yet to see a change request policy that I liked. 😛
I will just say that if I was you I would try to write the policies so that they accomplish your goals without adding too much red tape. I worked at one company where the change requests got completely out of hand. The worst I had to deal with was 5 hours of phone calls, a couple face-to-face meetings, and several emails back and forth to get 3 rows added to a lookup table. Took up pretty much a full 8 hour work day for myself and 4 other people when the change was considered low-risk and only impacted a small % of customers.
This wasn't normal but it did happen. The backlog of change requests got so long that a minimum turn around time of 2-3 weeks was expected. This led to everything being an emergency ecm...:w00t:
This was the extreme case, but it's seems that these types of policies can get out of hand. Just my 2 cents.
October 3, 2012 at 11:56 am
Actually, Brendan, what you're described is what I've seen over and over.
While well intentioned, such processes usually end up being roadblocks rather than welcome centers (to stay with the road traveling metaphor).
It's very difficult to find the proper balance between proper review and overall speed.
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
October 3, 2012 at 12:37 pm
brendan woulfe (10/3/2012)
I will just say that if I was you I would try to write the policies so that they accomplish your goals without adding too much red tape.
Glad to hear this perspective. The goal is to avoid either extreme: having no policy (which is where we are now), or being handcuffed by excessive policy. It's real easy to swing from one side of the pendulum to the other. I expect to begin with a handful of simple policies and only develop more as issues arise.
Thanks for the input so far! Any more would be very welcome.
October 3, 2012 at 4:11 pm
Backup and restore requests.
I've done away with a lot of the "requests" -- just provide 'em a stored proc that can be run to do the backup. The stored proc enforces a naming scheme for the backup (i.e. they tell you the db name they want backed up, but not the backup file name).
Generally the same for restores in dev/qa, if it is a reasonable size.
Tell em if they abuse it, you'll cut them off.
One less cycle of requests you have to deal with :-).
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
October 9, 2012 at 2:26 pm
I'm a one-man-band here myself, but I would suggest that you start off small, maybe with a policy that requires at least the documentation of all things done in that regard. That will give you an inside look at what is happening, who is requesting it, and whether anything goes wrong when it is done.
You can then look into actual approvals, etc. later if it is deemed necessary.
October 10, 2012 at 9:19 am
Thanks for all the input! I will be publishing our policy in the next couple of weeks, and I believe it is better for the information in this thread.
Thanks again.
October 10, 2012 at 11:24 am
Foxxo is right on track. By following ITIL practices changes are classified to levels (1-3) as follows:
Level 1's are presented to your Change Advisory Board (CAB) by the Change Manager (CM) with the support of the necessary stakeholders of the request. Requests that require this level of review usually are larger scope and have one or more significant impacts to the organization (costs, time / effort of various resources, etc).
Level 2's are not presented to the CAB. The CM can approve these on their own. However these are significant enough to justify a project based on visibility.
Level 3's are standard changes. These are requests that can be done immediately. These are recognized changes in the organization that are typically repeatable and have procedures and work instructions identified for how to complete the task.
This is just a nutshell explanation but this is basically how you avoid the red tape and manage changes in IT effectively and responsibly.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply