共用方式為

Release Management 101

  • 發行項

Commonly I come across a scenario with customers where they focus on implementing MOM/OpsMgr, yet do not think about process in relation to the tools.  A prime example with Operations Manager or MOM is with Management Packs and Release Management - Plan, Build, Test, Review and Deploy (simply speaking).  You can't just simply download a Management Pack, import it into your management group, and then expect it to go off and begin monitor your environment (Lets face it, there will be some level of inaccurate alerting that will occur even though the developers have tuned it to minimize "noise"). And why?  Because everyone implements technology differently out of the box - customizations, tightening security, etc.  Therefore, some level of tuning needs to occur before you "release" it into production.

 From a Release Management perspective, you need to:

  1. Plan the release - identify who needs to be involved in the release (teams and roles), the schedule, the project plan (if necessary), what's affected, documentation, etc.  Review the deployment guide that accompanies the Management Pack, and prepare to test it in a lab environment.
  2. Build the release - Develop the process, tools, and technology required to release into production.  Here you are going to determine how you are going to deploy the Management Pack into production, which typically is importing it on a Management Server in the management group or use an automated method from the command-line or SDK.  This could be the default MP and/or custom MP (depending on the situation).
  3. Test - Once you have the build package developed and accepted, you then need to test the Management Pack and tune it based upon your requirements.  The changes you make to the defalut MP should be saved in a Custom Management Pack to avoid those changes being overwritten when you import a new version of the MP (for MOM 2005.  For OpsMgr 2007, you need to save your changes in a custom MP because the MP's that are released by the vendor are sealed and cannot be modified).  Document the customizations you make and implement a version control system as well.  Make sure the changes return the expected results - alerts are raised for valid issues, thresholds are set to variances outside of expected performance characteristics, etc.  Basically no ambiguous alerts and that you are seeing the results based upon how you have the service or application configured in your environment.
  4. Review & Deploy - review with the necessary parties the results of the different phases of the process and if accepted, the MP can be deployed into production based upon the RFC submitted to the CAB (Change Advisory Board).  If there are concerns or issues, it may not be approved and back to testing to rectify the concerns or issues.  In addition, store the MP and documentation in a DSL (Distributed Software Library) - such as a share repository for all MP's or even something like Visual SourceSafe where it is logically structured per type of MP and version.  Important for tracking and control of changes so that you maintain in a centralized manner.  Don't forget to update your CMDB if you have one to follow the process for Configuration Management.

This may appear to be alot of unnecesary red-tape, but the point I am trying to make is do your due diligence in reviewing the MP and what it does, the requirements and caveats, and test it before you go ahead and implement in production.  This is an enterprise monitoring product that should be controlled to ensure accurate notification of true health or reliability issues with services and applcations monitored in your datacenter.  More importantly, the business will feel confident in IT meeting SLA's and the report data being reliable and that you are actually able to provide it.