October 13, 2010 at 8:32 am
I was tasked with coming up with a few guidelines for application owners for their databases once they are created in dev. Examples are: 1) Need to give DBA one weeks notice before moving to QA and two weeks notice before moving to production and 2) Be advised that the DBA will ask you to perform some application testing before moving environments, so he/she can watch how the application performs.
Do any of you have guidelines like this in place? If so, what are your guidelines? Other than performance tests and proper notice, do I need to include anything else in my list of guidelines?
Thanks in advance!
October 13, 2010 at 9:18 am
First Rule:- All the live changes should be tested successfully on the testing or Preprod server before we deploy in live including backout steps.
Type of changes & the timlines required.
Standard :-- 7 days time
Emergency :- when the service, or environment, requires an urgent physical change to either maintain service availability, to prevent a critical problem from occurring
Failed lead time :- when the service, or environment, requires an urgent physical change to either maintain service availability, to prevent a critical problem from occurring
Critical details that are required in Change Record:-
Change Objective Details:-
The information detailed in the objective of a change record should give a clear description of the change using, as far as is practicable, non-technical terminology or technical acronyms. Where it is unavoidable to use such devices the underlying concepts of these should be clearly described.
Implementation Details:-
The procedures required to implement the change should be detailed in a step-by-step or sequence bulleted task list, including a description of each individual task and any associated script file names, script locations/delivery method, target server and database details and schema/logon information.
Change window time:-
The change window is the start and end time of the change. Consideration to the time to prove the change should be included in the time allowed for the change window. The implementation time of the change must be agreed with the business to proceed at a time, so that where possible, the change will not impact the service.
Supporting teams:-
Other departments assisting in the implementation of the change should be included in the supporting department's tab.
Backout Details:-
The details of the backout plan should give a step-by-step or sequence bulleted task list, including a description the individual tasks and any associated script file names, script locations/delivery method, target server and database details and schema/logon information. If necessary, such as a when the backout of change is particularly complex, accompanying procedures or documentation may be referred to in the backout details.
Testing Details :-
Where necessary, or appropriate, a full testing regime of the change should be engaged and should provide the basis of the installation process and the procedure documentation required to implement the change. This information should be clearly described in the Testing section of the change.
Impact and Risk Rating
A detailed description of what the impact would be in the event of the change failing to implement successfully. If this is not relevant this should be indicated as clearly as possible in the impact on failure section of the change record The impact rating is based around the number of service lines that an individual change could affect.The general implementation risk associated with the change activity.
October 13, 2010 at 10:09 am
I would always add performance testing / tuning as #1 priority beyond "does it work as required?".
That MUST include not breaking anything else that was working before. A good way to test this is to have a copy of prod in a seperate yet equally performing machine server. Run a trace on prod. Replay the trace on QA before and after the changes and see how much NET improvement you get and decide based on guidelines if it's acceptable.
It's better if you can have a realistic 24/7/365 trace which includes end of month/quarter/year reporting and processing. I'm not saying to have a 365 days trace but all the main events that will play during that year.
October 13, 2010 at 3:19 pm
DBAgal (10/13/2010)
... do I need to include anything else in my list of guidelines?
Do you have a ticketing system to track changes?
Is there an established weekly Change Management call scheduled?
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.October 14, 2010 at 7:11 am
PaulB-TheOneAndOnly (10/13/2010)
DBAgal (10/13/2010)
... do I need to include anything else in my list of guidelines?Do you have a ticketing system to track changes?
Is there an established weekly Change Management call scheduled?
We do have a ticketing system, but every application doesn't have a workflow associated with it yet. The ticketing system is a work in progress. A lot of my requests come in through email, so that is why I am trying create a document with SQL change management guidelines.
And no, we don't have a weekly change management call scheduled for SQL Server. Our SQL Server environment is somewhat small; we're predominantly an Oracle shop.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply