~ Early Life

Transcription

1 Measurements and reporting systems are established Suessful validation of the deployment triggers the launh of Early Life Support (ELS). 6.0 Deploy & Verify - Q)... E Q) t1 Ol Change.r::: t1 0 t1 (jj Ol 6.0 t1 Deploy & t1 Verify 6.4 Develop and a Coordinate 0::: Exeution of l Ation Plan Doument & (jj Report Issues & Ol to,l IL t1 Communiate Remediation t1 Ations Early Life Verify Deployment Verify Deployment Support Q) Complete Complete E >- 0 Ci Q) a Figure 10. RDM Deploy and Verify Sub-Proess Table 13 desribes the Deploy and Verify sub-proess steps as depited in Figure 10. Table 13. RDM Deploy and Verify Sub-Proess Desriptions 6.0 Deploy & Verify Number Proess Ativity Desription 6.1 Exeute Deployment When adding a servie, deommissioning, retiring a servie or servie asset, the Deployment Manager will deploy the servie release pakage in aordane with the established PWis. 6.2 Verify Deployment Validations will be exeuted by the deployment team in aordane with Complete established PWis. 6.3 Deployment ELS entrane riteria met? Suessful? If yes go to step 6.5, Doument and Report Issues and Remediation Ations. If no, go to step 6.4, Develop and Coordinate Exeution of Ation Plan. 6.4 Develop and The deployment is not suessful. The Deployment Manager may reommend up Coordinate Exeution to and inluding the implementation of the bak-out plan. The Deployment of Ation Plan Manager will oordinate the exeution of the ation plan with the deployment team. The Deployment Manager notifies ChM of the exeution of the ation plan. 6.5 Doument and The deployment team will doument the results from eah deployment step and Report Issues and develop remediation ativities, as required. If no remediation is required, then the Remediation Ations deployment is promoted to Early Life Support. 35

2 4.7 Early Life Support Approved RFC External Pro ess_j Change Plan & Prepare...,. Enterprise Engineering Verifiation Environment Proess Servie Design Release ---+ Build Release r-+ Validation & Testing + Internal Proess umer t-roesses 5.0 Plan & Prepare... Change Configuration for Deployment 6.0 Deploy & Verify utner Proesses 7.0 Early Life Change Inident Support 8.0 Review and Close End Event ELS is the additional expert servie support provided immediately after the deployment to ensure servie ontinuity and stakeholder satisfation. Resoures from IT Operations introdue the new servie apability and resoures to operations in a ontrolled manner. Resoure support sope is determined by the release ontent delivered. In Servie Design, the stakeholders have agreed to the entry and exit riteri a for ELS, but it may be neessary to renegotiate the performane targets and exit riteria early in the ELS stage as performane results are generated in the prodution environment. The ROM Manager negotiates with the stakeholders for release approval. Re lease approval may inlude known errors with interim work-arounds or bak-out plans are invoked if a satisfatory release is not possible. 36

3 05 Apri/ Early Life Support U) I <ll I e I : l Inident Event Change I 7.3 Exit riteria Me Yes Review & Close <ll E > Gather and Evaluate Performane Data T Early Ufe Additional Support I----' Suppo rt for Deployment 7.4 Develop Corretive Ation '------' Plans for ISSU QS & Risks Figure 11. ROM Early Life Support Sub-Proess Table 14 desribes the Early Life Support sub-proess steps as depited in Figure 11. Table 14. ROM Early Life Support Sub-Proess Desriptions 7.0 Early Life Support Number Proess Ativity Desription 7.1 Additional Support As the transition is initiated, the deployment team alerts users where issues may for Deployment surfae and provide diretion for roles and responsibilities, funding requirements, raising inidents and hange requests, esalation proedures, omplaint proedures using tools and aids, and software liensing rules. The exit riteria and performane targets are finalized with the stakeholders. The transition of the new or hanged servie to Servie Operations is initiated in a ontrolled manner. 7.2 Gather and Performane data (number of inidents and problems by type) is olleted as soon Evaluate as possible after the transition begins. Results are analyzed. Improvements are Performane Data implemented. If appropriate, performane data between different deployment groups is ompared. 7.3 Exit Criteria Met? Exit riteria is defined in the PWis. When ELS exit riteria is met, the release is promoted to Review and Close. If the exit riteria is not met, then move to 7.4 Develop Corretive Ations. 7.4 Develop Corretive If exit riterion is not met, orretive ation plans are developed and implemented Ation Plans for and forwarded to Change for review and disposition. Issues and Risks One a release has been suessfully deployed into the environment, the deployment outome is sent to both Event and Change. 37

4 4.8 Review and Close Approved RFC '--"",., External Pro ess_j 1.0 Change Plan & Prepare "' Enterprise Engineering Verifiation Environment Proess Servie Design Release f---. Build Release Validation & Testing! Internal Proess Uther!-'roesses 5.0 Plan & Prepare +-+ Change Configuration for Deployment 6.0 Deploy & Verify Other Proesses 7.0 Eay Life Change Inident Support 8.0 Review and Close End Event The RDM Manager onduts a review to ensure appropriate and thorough knowledge transfer, training, and doumentation is delivered to the stakeholders and end users. All fi xes and hanges are omplete and have been presented to the ustomer for ri sk aeptane. All problems and known errors are identified and doumented w ith known workarounds. The entrane and exit riteria for eah stage of the proess has been assessed and met. The RDM Manager reviews the tasks ompleted during deployments and determines that all obj etives of the deployment plan were met. A management plan is established for outstanding risks, tssues, inidents, and known errors before the deployment is losed. The RDM Manager notifies the Projet Offier who then issues a lose notifiation as the last step in the review. A ll re lease partiipants and end users are notified of the final review results for the release. 38

5 8.0 Review and Close Q) g> <0.eo () Change ' ' u Verify Handoff to... - Q) Servie Cl Operations ltl ltl Verify Deliverable Notify Change ( End Pro ess in Use & Complete 0 0:: Qj u!i: 0 t5 Q) e a Rev;ew& Close Figure 12. ROM Review and Close Sub-Proess Close Release Table 15 desribes the Review and Close sub-proess steps as depited in Figure 12. Number Proess Ativity Table 15. ROM Review and Close Sub-Proess Desriptions 8.0 Review and Close Desription 8.1 Verify Deliverable A deployment review is onduted, assessing the deliverable in aordane with in Use and established PWis. Complete 8.2 Verify Hand-off to Coordinate the transition of deployment group support to Servie Operations with Servie Operations ChM. 8.3 Close Release The Projet Offier loses the release, and ChM is notified that the release has been transitioned to Servie Operations. 39

6 Appendix A - ACRONYMS The offiial list of E-ITSM aronyms an be found on the Enterprise Information Tehnology Servie site ( The I ink to the doument is referened below: millsites/irm/itsm/douments/formsiaiiitems.aspx?rootfolder=%2fsites%2firm%2fitsm%2fdouments%2 FE%2DITSM%20Aronym %20List&FolderCT I D=OxO B7035A54 78C E3ACBCD& View=f9CD820B3-EF85-402C-BDOC-A255AEE9E400} 40

7 05 April 2013 Appendix B - GLOSSARY Asset Bak-out Plan Change Shedule Configuration Item Cl Type Term I Definition Configuration Database Configuration System Asset is the proess responsible for traking and reporting the finanial value and ownership of assets throughout their lifeyle. A Bak-out Plan is developed in the Release planning phase. This plan provides a reovery plan to return to the original onfiguration or proess if the release fails to ahieve the planned outome. A Change Shedule is a doument that lists all approved hanges and their planned implementation dates. A Configuration Item (CI) is any omponent that needs to be managed in order to deliver an IT Servie. Information about eah Cl is reorded in a Configuration Reord within the Configuration System (CMS) and is maintained throughout its lifeyle by Configuration. Cis are under the ontrol of Change. Cis typially inlude IT servies, hardware, software, buildings, people and formal doumentation suh as proess doumentation and SLAs. Cl Type is a ategory used to Classify Cis. The Cl Type identifies the required attributes and relationships for a onfiguration reord. Common Cl Types inlude: server, doument, user, et. A Configuration Database (CMDB) is a database used to store onfiguration reords throughout their lifeyle. The Configuration System (CMS) maintains one or more CMDBs and eah CMDB stores attributes of Cis and relationships with other Cis. A Configuration System (CMS) is a set of tools and databases used to manage an IT servie provider's onfiguration data. The CMS also inludes information about inidents, problems, known errors, hanges, and releases and may ontain data about employees, suppliers, loations, units, ustomers and users. The CMS inludes tools for olleting, storing, managing, updating and presenting data about all Cis and their relationships. The CMS is maintained by Configuration and is used by all IT Servie proesses. Deployment Deployment is the ativity responsible for movement of new or hanged hardware, software, doumentation, proess, et. to the live environment. Deployment is part of the Release and Deployment Proess. Deployment Readiness Test A Deployment Readiness Test is onduted to ensure that the deployment proesses, proedures, and systems an deploy, install, ommission, and deommission the release pakage and resultant new or hanged servie in the prodution/deployment environment. Deployment Verifiation Test A Deployment Verifiation Test is onduted to ensure the servie apability has been orretly deployed for eah target deployment group or environment. Early Life Support EM System Environment Early Life Support (ELS) involves Tehnial or IT Operations providing support for a new or hanged IT servie for a period of time after it is released. During ELS, the IT servie provider may review the KPis, servie levels, and monitoring thresholds and provide additional resoures for inident management and problem management (when implemented). The EM System (EMS) is omprised of tools whih monitor Cis and provide event notifiations. It is a ombination of software and hardware whih provides a means of delivering a message to a set of reipients. The EMS often requires real-time interation, esalation, and sheduling. Environment is a subset of the IT infrastruture used for a partiular purpose (e.g., live environment, test environment or build environment). It is possible for multiple environments to share a Cl (e.g., test and live environments may use different partitions on a single mainframe omputer). In the term physial environment, environment an be defined as the aommodation, air onditioning, power system, et. Environment an be used as a generi term defined as the external onditions that influene or affet something. 41

8 Error Esalation Event Event Correlation Exit and Entry Criteria (Pass/Fail) Governane Term I Definition Key Performane Indiator Known Error Monitoring Notifiation Proess Quality Assurane Role Severity Servie Design Pakage Servie Validation and Testing Snapshot Test An Error is a design flaw or malfuntion that auses a failure of one or more Cl or IT servies. A mistake made by a person or a faulty proess that affets a Cl or IT servie is also an error. Esalation is an ativity that obtains additional resoures when needed to meet servie-level targets or ustomer expetations. An Event is a piee of data that provides information about one or more system resoures. Most events are benign. Some events show a hange of state whih has signifiane for the management of a Cl or IT servie. The term 'event' is also used to define an alert or notifiation reated by any IT servie, Cl, or monitoring tool. Events typially require IT operations personnel to take ations and often lead to inidents being logged. Event orrelation involves assoiating multiple related events. Often, multiple events are generated as a result of the same infrastruture fault. Events need orrelation to prevent dupliation of effort in resolving the original fault. These are riteria (defined well in advane and aepted by the stakeholders) defined at authorized points in the Release and Deployment Proess to set expetations of aeptable/unaeptable results. Governane is the proess of ensuring poliies and strategy are atually implemented and that required proesses are orretly followed. Governane inludes defining roles and responsibilities, measuring, and reporting and taking ations to resolve any issues identified. A Key Performane Indiator (KPI) is a metri used to help manage a proess, IT servie, or ativity. Many metris may be measured, but only the most important of these are defined as KPis and used to atively manage and report on the proess, IT servie, or ativity. KPis are seleted to ensure that effiieny, effetiveness, and ost effetiveness are all managed. A Known Error is a problem that has a doumented root ause and a work-around. Known errors are reated and managed throughout their lifeyle by Problem. Known errors may also be identified by SIE or suppliers. Monitoring is the proess of repeated observation of a Cl, IT servie, or proess to detet events and to ensure that the urrent status is known. Notifiation is a ommuniation that provides information. A Proess is a strutured set of ativities designed to aomplish a speifi objetive. A proess takes one or more defined inputs and turns them into defined outputs. A proess may inlude any of the roles, responsibilities, tools, and management ontrols required to reliably deliver the outputs. A proess may define poliies, standards, guidelines, ativities, and work instrutions, if needed. Quality Assurane (QA) is the proess responsible for ensuring the quality of a produt and also ensuring it will provide its intended value. A Role refers to a set of onneted behaviors or ations that are performed by a person, team, or group in a speifi ontext. Severity refers to the level or degree of intensity. A Servie Design Pakage (SOP) is omposed of doument(s) defining all aspets of an IT servie and its requirements through eah stage of its lifeyle. An SOP is produed for eah new IT servie, major hange, or IT servie retirement. Servie Validation and Testing is the proess responsible for validation and testing of a new or hanged IT servie. Servie Validation and Testing ensures an IT servie mathes the design speifiation and will meet the needs of the business. Servie Validation and Testing during release onduts testing in the pre-prodution Systems Integration Environment (SIE) and during deployment in the pilot prodution environment. A Snapshot is the baseline as aptured by a disovery tool. A snapshot an also be alled a benhmark. A Test is an ativity that verifies that a Cl, IT servie, or proess meets its speifiation or agreed requirements. 42

9 Term I Definition Test Environment User Aeptane Testing Work-around Work Instrution A Test Environment is a ontrolled environment used to test Cis, builds, IT servies, and proesses. User Aeptane Testing is a testing ativity onduted by the user intended to verify a Cl, IT servie, or proess meets a speifiation. It is also used to validate whether agreed requirements have been met. Work-arounds for problems are doumented in known error reords and are intended to redue or eliminate the impat of an inident or problem for whih a full resolution is not yet available. Work-arounds for inidents that do not have assoiated problem reords are doumented in the inident reord. The Work Instrution is a doument ontaining detailed instrutions that speify exatly what steps are followed to arry out an ativity. A work instrution ontains muh more detail than a proedure and is only reated if very detailed instrutions are needed. 43