4.2 - Change Management Flashcards
1
Q
Change management
A
- How to make a change
– Upgrade software, patch an application, change firewall
configuration, modify switch ports - One of the most common risks in the enterprise
– Occurs very frequently - Often overlooked or ignored
– Did you feel that bite? - Have clear policies
– Frequency, duration, installation process, rollback
procedures - Sometimes extremely difficult to implement
– It’s hard to change corporate culture
2
Q
Rollback plan
A
- The change will work perfectly and nothing will ever go bad
– Of course it will - You should always have a way to revert your changes
– Prepare for the worst, hope for the best - This isn’t as easy as it sounds
– Some changes are difficult to revert - Always have backups
3
Q
Sandbox testing
A
- Isolated testing environment
– No connection to the real world or production system
– A technological safe space - Use before making a change to production
– Try the upgrade, apply the patch
– Test and confirm before deployment - Confirm the rollback plan
– Move everything back to the original
– A sandbox can’t consider every possibility
4
Q
Responsible staff members
A
- A team effort - Many different parts of the organization
- IT team - Implements the change
- Business customer - The user of the technology or software
- Organization sponsor
– Someone’s budget is responsible for the process
– Or responsible for the profit
5
Q
Change management process
A
- A formal process for managing change
– Avoid downtime, confusion, and mistakes - Nothing changes without the process
– Complete the request forms
– Determine the purpose of the change
– Identify the scope of the change
– Schedule a date and time of the change
– Determine affected systems and the impact
– Analyze the risk associated with the change
– Get approval from the change control board
– Get end-user acceptance after the change is
complete
6
Q
Change request forms
A
- A formal process always seems to include a bit of
paperwork
– This is usually an online system - Nothing gets missed
– Easy to manage
– Create detailed reports and statistics - Usually a transparent process
– Many different groups and people are usually
7
Q
Purpose of the change
A
- Why are we doing this?
– There needs to be a compelling reason - Application upgrades
– New features
– Bug fixes
– Performance enhancements - Security fixes
– Monthly patches and vulnerability fixes - There needs to be a good reason
– Changes are costly
8
Q
Scope of the change
A
- Determine the effect of the change
– May be limited to a single server
– Or an entire site - A single change can be far reaching
– Multiple applications, Internet connectivity,
remote site access, external customer access - How long will this take?
– Specific date and time for the change
– May have no impact, could have hours of downtime
9
Q
Risk analysis
A
- Determine a risk value - i.e., high, medium, low
- The risks can be minor or far-reaching
– The “fix” doesn’t actually fix anything
– The fix breaks something else
– Operating system failures
– Data corruption - What’s the risk with NOT making the change?
– Security or application vulnerability
– Unexpected downtime to other services
10
Q
Change board and approvals
A
- Go or no go
– Lots of discussion - All important parts of the organization are represented
– Potential changes can affect the entire company - Some changes have priority
– The change board makes the schedule
– Some changes happen quickly, some take time - This is the last step
– The actual work comes next
11
Q
End-user acceptance
A
- Nothing happens without a sign-off
– The end users of the application / network - One of your jobs is to make them successful
– They ultimately decide if a change is worth it to them - Ideally, this is a formality
– Of course, they have been involved
throughout this entire process
– There’s constant communication before and after
