Initial DRAFT Standard Operating Environment SOE

1
Initial DRAFTStandard Operating Environment (SOE)

• NTA Meeting Oct 14-15 2002
• A joint work of SBC and the CSU

2
History

• RFP for ITRP Provided us all with a clear
  message all campuses will have the same network
  infrastructure, equipment and NMS why?
• Better pricing
• We can use each other for help
• As a large organization we can put pressure on
  vendors for change

3
History Contd

• We have developed and adapted some guidelines and
  formal documents on various subjects
• Network Baseline document (..\..\Offical
  Docs\NtwrkBsln.vFinal1.doc)
• FCAPS as the NMS baseline (..\..\Network
  Management\Network Management Oct-12-01.doc)
• Change Process (..\..\change process
  Oct-12-01.doc)

4
History Contd

• During tough economic times we will
• have less
• be asked to maximize efficiency e.g
• Buy less support
• Implement 7X24 with no new
• Measure Of Success reports need to be consistent
  common merics and data gathering techniques.
• SOE is one way to achieve these goals, as well as
  providing other benefits

5
Take a deep breath

• The next step in the TII build-out process is to
  define a set of Operating Standards and Practices
  and related metrics aka Standard Operating
  Environment
• What is the frame work and process to create the
  SOE?

6
Take a deep breath ContdA few more seconds

• During the NMS meeting at SSU 8/29 SBC presented
  the principals of SOE for NMS. (This presentation
  has been available on the NTA intranet since
  9/24/02)
• With the creation of the PIGs and SOWs we have
  started the process of SOE. We might feel like
  we are losing control if we do not put the right
  process and content in place.

7
SOE Proposed Framework

• What is included in the SOE AKA best operating
  practices?
• Version Control
• Change Management
• Architectural Steering

8
Version Control

• All software versions identified w/ patch level,
  scripts, adapters and edited files
• Exact revisions adhered to across the board
• All systems installed identically disk, file
  systems, and environment variables including
  hardening of OS
• Any modification to any software/firmware
  component are identified and documented
• Must be able to revert to regressed
  architecture configuration when working on new
  enhancements or technology introductions

9
Version Control Contd

• Impact of introducing new product must be tested
  in exact environment.
• Should be able to identify file system changes
  such as difference, history, properties,
  permissions and status.

10
Change Management

• Describe why change is needed/requested
• Identify pros/cons of change
• Identify the proposed change from a service
  impacting perspective
• Is change vendor certified?
• Is change platform certified?
• Identify Change Approver(s) and Change Schedule
  of Authorizations
• Identify potential impacts via the
  upstream/downstream pairs of change

11
Change Management Contd

• Identify potential impacts via the
  upstream/downstream pairs of change
• Produce CSU Change Management Template and supply
  to all campuses
• Produce documentation from vendor or in-house
  proving change will succeed
• Establish NMS/ITRP test bed to mitigate risks
• Build fall back plans prior to change(s) if
  activity does not perform as expected

12
Critical Steps for Creating a Change Management
Process

• Planning for Change
• Risk Assessment
• Test and Validation
• Change Planning
• Change Controller
• Change Management Team

13
Critical Steps for Creating a Change Management
Process Contd

• Communication
• Implementation Team
• Test Evaluation of Change
• Network Management Update
• Documentation

14
Change Management process
15
High-Level Process Flow for Emergency Change
Management Contd

• Issue Determination
• Limited Risk Assessment
• Communications
• Documentation
• Implementation
• Test and Evaluation
• Performance Indicators for Change Management

16
High-Level Process Flow for Emergency Change
Management Contd

• Change Management Metrics by Functional Group
• Targeting Change Success
• Change History Archive
• Change Planning Archive
• Configuration Change Audit

17
High-Level Process Flow for Emergency Change
Management
18
Architectural Steering

• Is the hardware platform robust enough to handle
  applications/traffic?
• Software performs as advertised
• Reports are useful and accurate
• Products share information well

19
Architectural Steering Contd

• Platform helps administrators and users do their
  jobs
• What additions would benefit the platform?
• Have vendors introduced any enhancements to
  existing installation?
• Has any testing been done to help make the
  decision?
• A forum for functional and organized technology
  enhancement, release management, and overall SOE
  governance

20
Next steps

• How do proceed from here?
• Bring your ideas to the NTA meeting
• This is only a DRAFT