Large Systems: Administration: Services. Image (c) Facebook

Transcription

1 Large Systems: Administration: Services Image (c) Facebook

2 2 Managing IT Services Stages Activities 1. Strategy Business Case 2. Design Requirements Design 3. Transition Build Test Deploy 4. Operation Deliver Support 5. Continual Improvement Improve Source: ITIL

3 Service Strategy What services to offer as IT department? Service portfolio Adding a service is a strategic decision What is the business case for the service? Why should we offer the service (cf. Outsourcing)? Service portfolio must be reviewed periodically Retain/Replace/Rationalize/Refactor/Renew/Retire Together with customer ITIL processes: Portfolio management Business relationship management

4 Service Strategy Need insight into costs of a service To determine the business case What to charge to customers (internal or external) To determine costs you need insight into demand Frequency Volume Location Duration of use ITIL processes: Financial management Demand management

5 5 (De)Centralization (Ch. 35) Services are being centralized or decentralized Common cause of changes Rationale for Centralization Less duplication Lower prices due to larger volume Larger scale allows specialization Rationale for Decentralization Central provides low quality Needs not met, no custom solutions, no innovation Costs too high

6 11 Next Stage: Design Stages Activities 1. Strategy Business Case 2. Design Requirements Design 3. Transition Build Test Deploy 4. Operation Deliver Support 5. Continual Improvement Improve Source: ITIL

7 12 Service Design For a service to be valuable: 1.Must do something (Utility) 2.Must be working (Warranty) Utility is expressed as functional requirements Warranty is expressed in terms of required Availability Capacity Continuity (disaster recovery) Security

8 13 Service Design: HOWTO (Ch.16) Start with a Kick-off meeting Ensure people involved know each other IRL Gather written requirements All can read (transparency) All can verify (fewer gaps) Fewer misunderstandings Get Buy-in and approval Fixes scope (no feature creep) Accountability Add MoSCoW classification

9 14 Service Design: HOWTO Issues: Speaking the same language Asking the right questions Difficult requests

10 15 Service Design: HOWTO Utility and Warranty requirements are turned into Service Level Requirements IT department then Evaluates feasibility and costs Creates functional design Creates technical design / architecture

11 17 Service Design: HOWTO Service Level Requirements are deemed feasible? May require testing (Service Transition stage) If yes, written down in a Service Level Agreement (SLA): Agreement between customer and provider (you)

12 18 Example SLA This is the SLA for the production planning system. This is an agreement between the production business and the IT department Service Description Provides the ability to plan the manufacturing schedule, identify raw material needs and place purchase orders Source: ITIL for Dummies, P. Farenden, 2012, p. 100

13 19 Example SLA (cont d) Service Level Targets Service Hours 24/7 Planned maintenance can take place between 2 and 5 am on weekdays, up to a total of 5 hours per week Availability and Reliability Service available over all service hours (except maintenance) Unplanned outages: restored within 2 hours No more than 3 outages in any 7 day period

14 20 Example SLA (cont d) Service Level Targets Response to Incidents P1: Interruption to critical service; restored in 2 h P2: Degradation to critical service; restored in 8 h P3: Low-criticality incident; restored in 48 h P4: Planned work Capacity and Performance Max concurrent users = 100 System response time < 2 s with all users IT service continuity When disaster; restored service < 2 h at recovery site

15 21 Example SLA (cont d) Support Service desk is point of contact Hours 8 am to 6 pm Out of hours contact via same number Reporting and Review Reports of service levels vs. targets first Monday of each month. Reviews held on 2 nd Monday of each month.

16 22 Meeting an SLA Your service depends on others E.g. Networking, Database teams External suppliers To meet the SLA you therefore need Operation Level Agreements (OLAs) With own IT Underpinning Contracts (UCs) With external suppliers

17 23 Meeting an SLA Need to show you meet the SLA E.g. SLA Monitoring chart (SLAM) Target Week 1 Week 2 Week 3 Week 4 Availability G G G G System Response Time G A G G Service Desk Response Time G G R G Incident Response Time G G G G G=Target Met, A = Target Threatened, R = Target Breached Source: ITIL for Dummies

18 24 Service Design: Output All information required to decide whether to go ahead with the transition of the service Functional Requirements Service Level Requirements or Agreements Design of the preferred solution Organizational readiness assessment Plan for introducing the service Service acceptance criteria ITIL: Service Design Package (SDP) Source: ITIL for Dummies

19 25 Next Stage: Transition Stages Activities 1. Strategy Business Case 2. Design Requirements Design 3. Transition Build Test Deploy 4. Operation Deliver Support 5. Continual Improvement Improve Source: ITIL

20 26 Deploying a Service Once built and tested, next step is deployment Deployment = Change Management (Ch. 32) Traditional Method: Change Review Board (CRB) Review and approve Change Requests Made up of stakeholders Communicate to affected parties Just bureaucracy? No Have to think about all aspects of a change

21 27 Change Process SA writes change proposal Which changes Systems and services affected Reason Risks Test results Success Criteria Backout plan Change duration Backout duration Decision point

22 28 Change Process (cont d) CRB meets weekly (or Emergency CRB) Proposals sent to CRB before meeting Change is classified into e.g. Routine Update Major Update Sensitive Update Emergency Update Risk of change is quantified

23 29 Change Process (cont d) Scheduling What time in week Any change freezes? cf. Maintenance Windows (Ch. 34) Communication DevOps challenge: Eliminate CRB

24 30 Choices and Best Practices (Ch. 21) Minimize intrusiveness for customer Layers vs pillars Vendor support Communicate to customer Training Gradual Rollouts vs Flash cuts

25 31 Choices and Best Practices (Ch. 19) Launch Readiness Criteria Monitoring in place? Backups and restores tested? Access control tested? SLA defined? Service requests enabled? Documentation complete? Load test complete? Scaling option?

26 Example: Server OS Upgrade (Ch. 33) 32 Step 1: Develop Service Checklist Which services provided by host? By which software packages? For which users? Ideally from Config Mgmt DB (CMDB) Verify with stakeholders

27 33 Server Upgrade Process (cont d) Step 2: Verify Software Compatibility Will software packages run on new OS? Check with vendor If not compatible: Upgrade package to version that is Upgrade package after update Postpone / change

28 34 Server Upgrade Process (cont d) Step 3: Develop Verification Tests Is the service working properly Useful before and after OS upgrade! Reusable (DevOps)

29 35 Server Upgrade Process (cont d) Step 4: Choose Upgrade Strategy In-place vs. new machine In-place faster New machine enables pilots In-place riskier In-place less disruptive In-place less effort No IP address changes

30 36 Server Upgrade Process (cont d) Step 5: Write Detailed Implementation Plan Detailed, step-by-step Steps for OS and packages / services Add/Remove services? Plan dress rehearsal

31 37 Server Upgrade Process (cont d) Step 6: Write Backout Plan Step 7: Select a Maintenance Window When? How Long? Step 8: Announce the Upgrade Step 9: Execute Tests on Old OS Step 10: Lock Out Customers Step 11: Do the Upgrade Together Step 12: Execute Tests on New OS Step 13: Backout on fail

32 38 Server Upgrade Process (cont d) Step 14: Restore Access Step 15: Communicate Success/Failure

33 39 DevOps Design and Transition smaller changes (Ch. 20) ITIL: Early Life Support Don t just throw over the wall to Operations Gartner: Bimodal IT Mode 1: Predictability (Legacy) Mode 2: Exploration (New stuff)

34 40 Done Feedback?