Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Change management procedures

  • From: Jake Khuon
  • Date: Thu Mar 21 15:25:31 2002
  • Action:
  • Dcc:
  • Expires:

### On Thu, 21 Mar 2002 11:57:18 -0500 (EST), Greg Maxwell
### <gmaxwell@martin.fl.us> casually decided to expound upon
### <nanog@merit.edu> the following thoughts about "Change management
### procedures":

GM> More specifically, I'm interested in knowing how often blocking-type (i.e.
GM> group consent before change) change management is used vs logging type
GM> (i.e. recording the change during/after the fact so the change can be

At my previous employ, we had two different tracks for CM.  One handled
domestic, and the other handled international.  In both cases, blocking-type
and logging-type procedures were used concurrently.  CM meetings occured
every other day with meeting agendas mailed out at least a day prior and
covered events scheduled for at least a week out.


GM> reverted, and for root cause analysis). Also, for blocking type change
GM> management, I'd like to know how people deal with process latency,
GM> emergency changes, approval group selection, etc (if indeed anyone uses
GM> consent to manage top-tier staff, I haven't found anyone so far that does).

Emergency and near-term events were also discussed in detail.  As memory
recalls, the CM process for normally scheduled events specified at least a
week's notice for turnups and changes.  In addition to the actual CM team,
each group within engineering and operations (provisioning, network
engineering, peering, first and second line ops, etc) had a representative. 
Each event and maintenance had a case number issued upon insertion of a
change request into the system and a person (from the CM team) responsbile
for tracking purposes.  Process latencies were reported back through the
representative of the issuer of the change and then handled on a
case-by-case basis.  Some changes required approval at different levels
depending on whether or not any generic change-holds were in effect at the
time.


--
/*===================[ Jake Khuon <khuon@NEEBU.Net> ]======================+
 | Packet Plumber, Network Engineers     /| / [~ [~ |) | | --------------- |
 | for Effective Bandwidth Utilisation  / |/  [_ [_ |) |_| N E T W O R K S |
 +=========================================================================*/




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.