S&T IT Change Management Policy and Procedure

Transcription

1 S&T IT Change Management Plicy and Prcedure 5/1/2016

2 Page 2 f 10 Executive Summary S&T IT Change Management All IT & Ed Tech staff are respnsible t fllw the Change Management Prcess when intrducing changes int the IT envirnment f Missuri University f Science & Technlgy. The CIO is respnsible fr enfrcing the change management plicy as well as updating the plicy and prcess. Change management is a prcess meant t ensure that any changes t existing, r intrductin f new, sftware r hardware within the Missuri University f Science and Technlgy s (S&T) Infrmatin Technlgy (IT) prductin envirnment is dne is an rderly and cntrlled manner. Ensuring effective change management within the S&T IT prductin envirnment is extremely imprtant in ensuring the efficient delivery f IT services while reducing risk. Objective This dcument prvides plicy and prcedures fr S&T IT change management. The details in this dcument are intended t meet the fundatin requirements fr industry best practices as detailed within the Infrmatin Technlgy Infrastructure Library (ITIL) directly relating t IT change management. It is imprtant t nte that nt all f the ITIL best practices fr IT change management are included in this dcument. These peratins als are intended t satisfy the Cntrl Objectives fr Infrmatin and Related Technlgies ( change management. In additin t meeting all f the ITIL and COBIT requirements, these guidelines prvide fr the efficient and effective handling f S&T IT changes cmpleted by the IT rganizatin. IT Change Management (in general) All IT & Ed Tech staff are respnsible t fllw the Change Management Prcess when intrducing changes int the IT envirnment f Missuri University f Science & Technlgy. The CIO is respnsible fr enfrcing the change management plicy as well as updating the plicy and prcess. S&T IT Change Management (CM) is the prcess f requesting, analyzing, apprving, develping, implementing, and reviewing a planned r unplanned change within the IT infrastructure. The Change Management Prcess begins with the creatin f a Change Request within the S&T IT s technlgy platfrm and ends with the mst apprpriate implementatin f the change and the cmmunicatin f the result f that change t all interested parties. The change management (CM) prcess is used t cntrl, dcument, determine risk and impact f changes and cmmunicate infrmatin abut changes made t prductin services. S&T IT utilizes an nline web applicatin t dcument and track changes as they prceed thrugh the S&T IT CM prcess. All changes t prductin systems and applicatins are required t be entered int the applicatin. The applicatin can be accessed at All change requests are reviewed during the weekly CM meetings. The nrmal prcess fr a change request is t be reviewed at least 1 week prir t being implemented in prductin. Any CM request with less than 1 week f lead time t review is cnsidered an emergency change and requires management apprval and a pst review audit. All areas f IT and select ther campus grups are encuraged t attend the CM meeting each week as this is the frum t debate what changes are being prpsed and apprved. Any change wner with requests scheduled fr review is required t attend r send a prxy, therwise the request is denied.

3 Page 3 f 10 CM steps (All f the fllwing are described in detail: within the sectins that fllw) 1. Initiating a change request 2. Analysis, Initial Apprval and Planned 3. Cmpleting the CM entry. The fllwing fields are required t enter a CM entry request: Status Owner Participants Summary Impacted Services Change length Outage Length Risk level Impact level Review date Change date Change Time Purpse Prcedure Risk Analysis Cmmunicatin Type User Impact 4. Risk Levels and Analysis assessments 5. User Impact Levels and Analysis assessments 6. Change Date and Lead time determinatins 7. Develping the Backut Plan 8. Testing 9. Peer, Cde and Security Reviews and Apprvals 10. Change Scheduling - Reviewing the request during the weekly change management meeting. Pst reviews (Audits) f any emergency request r ther requests are reviewed. New requests scheduled fr review are presented by the wner and reviewed fr apprval r denial If apprved update the status f the request t scheduled. If declined update the status f the request t declined. Previusly reviewed requests scheduled fr implementatin at the next windw are listed Other CM items nt yet entered int the system are discussed 11. Implementatin and Prmtin - Change is implemented during scheduled CM windw. 12. Testing, Validatin and Acceptance - Update the status f the request t cmpleted. 13. Pst review is dne if necessary. In Scpe The intended scpe f S&T IT s Change Management is t cver all f the S&T s cmputing systems and platfrms. The primary IT functinal and peratinal cmpnents include: Hardware Installatin, mdificatin, remval r relcatin f cmputing equipment. Sftware Installatin, patching, upgrade r remval f sftware prducts including perating systems, access methds, cmmercial ff-the-shelf (COTS) packages, internally develped packages and utilities. Database Changes t databases r files such as additins, rerganizatins and majr maintenance. SDLC/Applicatin Sftware develpment life cycle and applicatin changes t be prmted t prductin as well as the integratin f new applicatin systems and the remval and decmmissin f bslete elements.

4 Page 4 f 10 Mves, Adds, Changes and Deletes Changes t system cnfiguratin. Schedule Changes - Requests fr creatin, deletin, r revisin t jb schedules, back-up schedules r ther regularly scheduled jbs managed by the S&T s IT rganizatin. VOIP Installatin, mdificatin, de-installatin, r relcatin f PBX equipment and services. Desktp Any mdificatin r relcatin f desktp equipment and services. Generic and Miscellaneus Changes Any changes that are required t cmplete tasks assciated with nrmal jb requirements. Out f Scpe There are many IT services and tasks perfrmed at S&T, either by the IT department r by the end users that d nt fall under the plicies and prcedures f Change Management. Services and tasks that require an peratinal prcess, but are utside the initial scpe f the S&T s Change Management prcess include: Cntingency/Cntinuity/Disaster Recvery Changes t nn-prductin elements r resurces Changes made within the daily administrative prcess. Examples f daily administrative tasks are: Passwrd resets User adds/deletes User mdificatins Adding, deleting r revising security grups Rebting machines when there is n change t the cnfiguratin f the system File permissin changes The S&T IT Directrs/Management may mdify the scpe peridically t include items in the scpe f S&T IT s verall Change Management prcess. Change Management (in detail) This sectin describes the basic tasks assciated with Change Management fr S&T IT in mre detail. Initiating a Change Request It is critical that the Change Management Prcess is cnsistent in quality and cmpleteness and discards irrelevant requests. Change requests can be submitted by anyne within an S&T business unit via the self-service Help Desk Ticket System (help.mst.edu) r by cntacting the IT Help Desk ( upn review f the created ticket at IT s tier 1 supprt level fr cmpleteness, the ticket will typically be assigned t a tier 2/3 level IT resurce grup (Netwrk, Systems, PIMS/Applicatins, Desktp, Ed Tech, IT RSS). Requesters can make changes t the request r check the status via the self-service Help Desk Ticket System (help.mst.edu), by cntacting the IT Help Desk ( r directly cntacting the assigned IT resurce. Requestrs will likewise be cntacted if additinal infrmatin is required. Analysis, Initial Apprval and Planned The assigned tier 2/3 level IT resurce grup cllects additinal infrmatin t define the change parameters, identify cding and/r technical requirements as well as establishes the initial pririty and apprval frm management. At this pint a new Change Management entry is made within the S&T IT Change Management (CM) system ( with a status f planned if the request is t be rutine and/r scheduled maintenance. Rutine and scheduled maintenance priritized changes ccur within the S&T IT s

5 Page 5 f 10 scheduled maintenance windws ( based n the IT resurce grup it is assigned. Emergency priritized requests ccur as needed (with emphasis n implementing/prmting the change within a scheduled maintenance windw if pssible ) t prevent any catastrphic events that are likely t ccur and/r t recver services frm such an event and may result in interruptins f campus cmputing services lasting several hurs r lnger. These are changes that, if nt implemented immediately, will leave the rganizatin pen t significant risk (fr example, applying a security patch) r a change that is imprtant fr the S&T and must be implemented sn t prevent a significant negative impact t S&T s ability t cnduct business. IT cmmunicatins will be as needed based n the emergency. Emergency change requests require 2 Directr s t apprval, all CM requirements t be cmpleted after implemented, is identified in the CM system as an Audit and a review f why it was an emergency is reviewed after implementatin fr avidance f reccurring. As an example, the PIMS emergency prmtin prcess is detailed belw Develper ntifies directr f PIMS that an issue has been discvered in an applicatin and that an urgent fix needs t be put int place. The develper will give an apprximate amunt f effrt needed t fix the issue t the PIMS directr. Develper makes necessary changes in develpment and tests the changes themselves t see if they slve the issue. The develper requests a PIMS prmtin manager t prmte the accunt t test (all apprpriate servers) and let them knw that an emergency prmtin will mst likely be ccurring n this accunt sn. Develper cntacts custmer t have them verify the change fixes the issue. Develper ensures that nly the changes that need t be cmmitted t fix the issue are cmmitted t the repsitry and a cde review is submitted with thse changes. While the develper is cmpleting steps 2 4, the PIMS directr needs t get written ( is acceptable) apprval frm at least ne ther IT directr t apprve the emergency prmtin f the applicatin. Once the PIMS directr has gtten apprval frm a secnd IT directr, that apprval needs t be frwarded t PIMS prmtin managers s they have recrd f the apprval and knw it is OK t prceed with it. Once the cde review and any assciated audits n the accunt is clsed, the develper ntifies the PIMS prmtin managers that the CR is clsed and that the emergency prmtin can be cmpleted. PIMS prmtin manager prmtes accunt t all apprpriate servers in prductin and then ntifies the develper and PIMS directr that the emergency prmtin is cmplete. An entry needs t be placed in Change Management as an Audit t be reviewed at the next meeting. NOTE: Emergency changes are t be kept t an abslute minimum due t the increased risk invlved in implementing them. Cmpleting the CM entry Fr all changes, the assigned tier 2/3 level IT resurce must cmplete the S&T IT CM entry. The fllwing are the fields fr cmpleting a CM entry (mandatry fields with * must be filled in befre the CM entry can be updated frm Planned status): Status*: Planned/ Audit/ Review/ Scheduled/ Declined/ Delete Owner*: List single userid respnsible fr the change (typically this is the persn assigned t the change and creating the CM entry)

6 Page 6 f 10 Participants*: List all userids invlved in change (ie security, database, server, applicatins) Ticket: Related ITSM ticket number Applicatin User: IT app userid Summary*: high level descriptin f the change Impacted Services*: See the fllwing sectin Risk Levels and Analysis Change Length*: See the fllwing sectin User Impact Levels and Analysis Outage Length*: See the fllwing sectin User Impact Levels and Analysis Risk Level*: (Lw/Medium/High) and see the fllwing sectin Risk Levels and Analysis Impact Level*: (Lw/Medium/High) and see the fllwing sectin User Impact Levels and Analysis Review Date*: See the fllwing sectin Change Date and Lead Time Change Date*: See the fllwing sectin Change Date and Lead Time Change Time*: select the apprpriate scheduled maintenance windw ( Purpse*: Define the requirements and descriptin f the change. Estimate the IT, business and ther resurces required t implement the Change, cvering the likely csts, the number and availability f peple required, the elapsed time, and any new infrastructure elements r additinal nging resurces required based n the change. Prcedure*: Instructins and back ut fr the implementatin and prmtin (See the fllwing sectin Develping the Backut Plan Risk Analysis: See the fllwing sectin Risk Levels and Analysis Cmmunicatin Type: select frm Change Owner Handling Cmmunicatins r IT Cmms Assistance Required User Impact*: See the fllwing sectin User Impact Levels and Analysis Risk Levels and Analysis This sectin describes the criteria t cnsider when evaluating the risk and impact f a change. This prcess is intended t evaluate and validate the technical feasibility, risk and effect a change will have n the prductin envirnment and end user prductivity. Cnsider the fllwing risk criteria while reviewing any change: Evaluate the change t gauge the risk, impact and effect f the change during and immediately fllwing the change implementatin. Review the cmpleteness f the change, including anticipated assets changed, impact n start-up r shut dwn f systems, impact n disaster recvery plans, back-up requirements, strage requirements, and perating system requirements. Evaluate the technical feasibility f the change and the whle impact f the change in terms f: Perfrmance Capacity Security Operability Validate technical aspects, feasibility, and plan. After the abve risk assessment is cmplete, the reviewer must assign a Risk level t the change in the CM entry based n the belw. Lw Fr rutine categries, the risk default is lw. If the evaluatin f the risk crrespnds with the criteria belw, the risk will be designated as lw. The risk criteria include: Invlves IT resurces frm ne wrkgrup within same IT divisin Lw cmplexity n technical crdinatin required Lw risk t system availability (system/service utage affecting clients during

7 Page 7 f 10 Nn-Prime Time) Easy implementatin and back-ut N impacts t service level agreements The change is well understd and has been tested Backut is defined and tested Medium The cmpnents f a medium risk include: Invlves IT resurces frm mre than ne wrkgrup within same IT divisin Significant cmplexity technical crdinatin required frm ne r mre functinal grups Mderate risk t system availability (system/service utage expsure during Prime/Peak Times, utage primarily expected during Nn-Prime Time) Sme cmplexity t implementatin and back-ut plans, back-ut nt expected t extend the windw timeframe Affects applicatin, data r server security Impacts service level agreements (e.g. Business Nn-Prime Time) and internal supprt required The change is less understd Has been partially tested including backut r cannt be tested but backut is well defined High A risk is cnsidered t be classified as high if the fllwing criteria apply t the change: Invlves IT resurces frm mre than tw wrkgrups, crsses IT divisins High cmplexity cmplex technical crdinatin required with ne r mre functinal grups High risk t system availability (system/service utage expected during Prime/Peak Times) Cmplex implementatin and back-ut plans, back-ut likely t extend the windw timeframe Affects security f data n infrastructure Impacts service level agreements (e.g. Business Prime/Peak Time) Outside vendr supprt is typically required The change is nt understd Backut is difficult r des nt exist User Impact Levels and Analysis This sectin details the ptential user impacts assciated with a change, and the criteria necessary t assign a user impact level t a change. This user impact analysis is cmpleted when a new change recrd is created. The user impact prcess evaluates the impact f the change as it relates t the ability f S&T t cnduct business. The key bjective is t cnfirm that the change is cnsistent with S&T s business bjectives. The fllwing pints shuld be cnsidered while perfrming this user impact assessment: Evaluate business risk/impact f bth ding and nt ding the change Analyze timing f the change t reslve any cnflicts and minimize impact Ensure all affected parties are aware f the change and understand its impact Determine if the implementatin f the change cnflicts with the business cycle Ensure current business requirements and bjectives are met. User impact levels are established based n the answers t the fllwing questins: Custmer and/r Client Impact

8 Page 8 f 10 High (4) Impacts several internal and/r external custmers, majr disruptin t critical systems r impact t missin critical services. Medium (3) Impacts several internal custmers, significant disruptin t critical systems r missin critical services. Lw (2) Impacts a minimal number f internal custmers, minimal impact t a prtin f a business unit r nn- critical service. N Risk (1) N impact t internal custmers, as well as n impact t critical systems r services. IT Resurce Impact High (4) Invlves IT resurces frm mre than tw wrkgrups and crsses IT divisins r invlves expertise nt currently staffed. Medium (3) Invlves IT resurces frm mre than tw wrkgrups within the same IT divisin r invlves expertise that has limited staffing. Lw (2) Invlves IT resurces frm ne wrkgrup within same IT divisin. N Risk (1) Invlves a single IT resurce frm a wrkgrup. Implementatin Cmplexity High (4) High cmplexity requiring technical and business crdinatin. Medium (3) Significant cmplexity requiring technical crdinatin nly. Lw (2) Lw cmplexity requiring n technical crdinatin. N Risk (1) Maintenance type f change Duratin f Change High (4) Change utage greater than 1 hur and affecting clients during Prime/Peak times. Lengthy install and back-ut. Medium (3) Change utage less than 1 hur during Prime/Peak times r greater then 1 hur during Nn-Prime times. Lw (2) Change utage less than 1 hur during Nn-Prime times and affecting clients during Nn-Prime times. N Risk (1) N utage expected. Security High (4) Affects critical data r server security and the back-ut wuld likely extend the windw timeframe. Medium (3) Affects nn-critical data r server security and has a mderate back-ut plan which wuld nt extend windw timeframe. Lw (2) N security issues and easy back-ut plan. N Risk (1) N back-ut plan needed. Service Level Agreement Impact High (4) Impacts SLA during business Prime/Peak times. Mderate (3) Impacts SLA during business Nn-Prime times. Lw (2) Little measurable affect n SLA times. N Risk (1) N affect n SLA times. RANGE User Impact Level High Medium 12 1 Lw Change Date and Lead times It is essential that requests fr change are submitted and apprved in a timely manner. This will allw cmpletin f accurate dcumentatin, change prcessing and btaining the apprvals in sufficient time prir t the requested implementatin date, and als prvide fr cnflict reslutin fr scheduling f changes. Lead times are the number f days an actin (Initiatin r Apprval) must be cmpleted prir t the requested change date. The number f days may vary depending n the pririty and the

9 Page 9 f 10 risk level. The Risk Wrksheet which is required t be cmpleted fr each change will assist Change Initiatrs t determine risk ptential. Preferably, high risk and/r large change requests shuld have several weeks (r even mnths) ntice prir t the requested implementatin date. Lead Times fr each change will vary depending n the type f change. Change Initiatrs shuld plan lead times t allw sufficient time fr planning, review, and apprval. In sme cases, lead times wuld als need t be planned t allw fr standard implementatin times that have been set fr certain prcesses like the SDLC Apprval prcess. Develping the Backut Plan Develpment f the back-ut plan is essential t ensuring effective recvery in the event f a failed change. The back-ut plan is primarily based n the risk and user impact levels and analysis and the implementatin and prmtin prcedures and plan. Testing All changes will underg sme level f testing depending n the cmplexity f the change. Once the change is built, cnfigured and integrated in the develpment envirnment, the change is mved t the Test/QA envirnment. This phase fcuses n cnducting testing and quality assurance t ensure reliability and perfrmance f all cmpnents f the rganizatin s technlgy infrastructure. The assigned tier 2/3 level IT resurce will versee testing and whether r nt t advance the change t the next step. Peer, cde and Security Reviews and Apprvals Peer, cde and security reviews are the last step f the Change Develpment Phase. Peer, cde and security reviews are required fr all cdes changes and ptinal but recmmended fr all ther S&T IT changes. All peer, cde and security reviews and apprvals are cnducted, dcumented and cmpleted using S&T IT s cllabrative peer cde review system (Crucible) frm Atlassian ( The purpse f peer, cde and security reviews f cde are t imprve develper skills, crss knwledge f cde and cnsequently the quality and security f the cde. In general the review ges as fllws: Develper checks cde int subversin Develper submits a cde review (frm Reviewers are autmatically assigned t the review by netgrup which sends an ntificatin Peer review allws cmments abut cde and mapping f defects t standards IT Security checks reviews fr cmpleteness (tw reviewers cmplete and develper has respnded as relevant t cmments) There are tw types f clsures f the review: 1 gd t g: this is used when n further develpment wrk is indicated 2 needs audit: this is used when further develpment wrk is indicated There are in general fur types f addressable cmments that can be prduced by a cde review: 1 Defects are when the cde des nt meet the requirements f an apprved cding standard 2 Security issues that d nt have a matching cding standard 3 Other issues that are nt cding standard r security related (fr example, grup cnventins, cde des nt wrk as expected, typgraphical errrs) 4 Requests fr clarificatin as t purpse r intent f cde Identified defects must be addressed in accrdance with the apprved cding standard. Security issues are t be addressed based n the risk and impact f the issue, but generally fall int fix befre prmtin r fix befre next prmtin.

10 Page 10 f 10 Other issues are addressed as apprpriate. Fr example, the apps team may have requirements levied n their applicatins that the system team des nt use. Requests fr clarificatin are addressed by prviding the clarificatin, which may lead t further cmments. In general, the IT Security versight f the prcess is ensuring that tw reviewers have cmpleted and that raised issues are addressed. Audit Reviews The purpse f an audit review is t facilitate the prcessing f changes made pursuant t a previus peer review. By limiting the scpe t nly previusly identified and apprved changes, the full peer review is nt required. General Flw (Audit) Develper makes changes indicated frm peer review Develper submits a cde review, nting previus review and specifying audit f CR-#### IT Security checks current and previus review t validate that all and nly the indicated changes have been made On successful cmpletin the review is clsed with gd t g If IT Security is the develper then any audit requires at least ne ther reviewer t certify that that changes match. Change Scheduling After all previus step are cmpleted, the status within the S&T IT CM system can be changed t reviewed and brught befre the weekly CM meeting (every Wednesday 2-2:30) t be apprved fr the status t be changed t scheduled. Implementatin and Prmtin Once a change is scheduled in the S&T IT CM system, it mves int the Implementatin and Prmtin Phase. During this step a designated S&T IT Prmtin Managers reviews all cmments, recmmendatins, apprvals and the prcedure fr the implementatin and prmtin f the change t ensure all required tasks have been cmpleted and may cntact the assigned IT resurce fr the change if needed. The Prmtin Manager implements the change in accrdance with the CM prcedures during the scheduled time. Failure f the implementatin at this level will nrmally require the Change Implementer t fllw the backut plan t ensure nrmal system peratins. Testing, Validatin, and Acceptance Once a change has been implemented, the S&T assigned IT resurce fr the change and the requestr will test and accept/reject the change. Fllwing a successful change implementatin, a change review must be cnducted t determine if the change resulted in the desired utcme. In mst cases, this review prcess might be very brief. Fr a rutine change, where the effect has been small and the results relatively predictable, the review prcess will be limited t checking that the change has prvided the user with the desired functinality. After this is cnducted the S&T IT CM entry status is changed t cmpleted and any cmments gathered are captured as Pst Cmments within the system. Reprting and Dcumentatin f Changes Reprting and dcumentatin f changes are within S&T IT are all in the Change Management (CM) system (