Soru

Zorluk: Çok zorConfiguration and Change Management

A senior network engineer is leading a major infrastructure upgrade to implement multi-chassis link aggregation and new VLAN topologies across an enterprise datacenter. To satisfy compliance and ensure minimal service disruption, the organization enforces a strict ITIL-aligned change control policy. Place the following phases of the change management lifecycle in the correct sequential order from first to last.

  1. 1Draft a comprehensive Request for Change (RFC) defining technical scope, business justification, risk assessment, and a detailed rollback plan.
  2. 2Perform non-production sandbox testing and configuration syntax validation to gather empirical feasibility and impact data.
  3. 3Present the RFC along with sandbox validation results to the Change Advisory Board (CAB) for risk review and formal authorization.
  4. 4Schedule the authorized maintenance window and publish change advisories to all affected enterprise stakeholders.
  5. 5Execute the approved configuration changes within the designated maintenance window and conduct immediate post-change functional testing.
  6. 6Conduct a Post-Implementation Review (PIR), update configuration baselines and topology diagrams, and close the RFC.

Cevap

The proper sequence for the enterprise change management lifecycle is: (1) Draft the Request for Change (RFC) with rollback plans, (2) Perform sandbox lab testing and validation, (3) Present the RFC and test findings to the Change Advisory Board (CAB) for authorization, (4) Schedule the maintenance window and notify stakeholders, (5) Execute the change within the maintenance window and run post-change validation, and (6) Conduct a Post-Implementation Review (PIR), update network baselines, and close the RFC.
The correct sequence strictly adheres to structured change management governance: drafting the initial RFC and rollback plan, proving concept stability via sandbox testing, acquiring formal CAB authorization, scheduling windows and alerting stakeholders, deploying changes with immediate verification during the window, and concluding with a Post-Implementation Review to update baselines and close the ticket.

Adım Adım Çözüm

1
Identify the initial proposal phase.
Drafting the Request for Change (RFC) establishes the technical scope, impact evaluation, and contingency rollback plan.
A formal change process cannot proceed without documented objectives, risk assessments, and recovery steps.
2
Determine pre-authorization testing requirements.
Executing non-production lab testing validates the configuration commands and verifies rollback procedures.
Empirical testing evidence is required to prove safety and refine risk metrics before seeking administrative authorization.
3
Identify the authorization checkpoint.
Presenting the RFC and lab validation evidence to the Change Advisory Board (CAB) secures formal organizational approval.
The CAB must assess high-level operational risks and business impacts before authorizing deployment into production.
4
Identify post-approval scheduling requirements.
Scheduling the maintenance window and broadcasting stakeholder advisories.
Stakeholder advisories and resource locking must only occur after the change has been officially approved by the CAB.
5
Determine execution and immediate verification phase.
Executing the configuration modifications during the maintenance window followed by immediate post-change testing.
Modifications must be confined to approved windows, and post-change testing ensures immediate detection of failures while the window is active.
6
Identify post-implementation closure requirements.
Conducting a Post-Implementation Review (PIR), updating configuration baselines and network documentation, and closing the RFC.
Closing the lifecycle requires capturing final network state baselines, updating CMDB records, and auditing the overall success of the change.

Anahtar Kavram

Standard Change Management Workflow
Bu soruyu puanla