Recap: Helpdesk Scope of Support

Transcription

1 1 Recap: Helpdesk Scope of Support

2 2 Limoncelli Process (cont d) Phase D: Verification ("Verify It") Step 8: Step 9:

3 3 Recap: Debugging Occam's Razor 3 Debugging Approaches

4 LIA Large Installation Administration Services

5 5 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

6 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

7 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

8 8 (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

9 9 (De)Centralization Strategies Strictly centralized Centralized platform Opt-in Centralized with decentralized delegation Service run centrally Some support done locally (internal or outsourced) Centralized with well-defined exceptions Duplicate services on approval Centralized with leaky exceptions Duplicate services always allowed

10 10 Centralization Recommendations Architecture Strictly centralized Security: Component Recommendation Authentication Authorization Internet Access Remote Access Extranet connections New acquisitions Malware detection Data leakage prevention Strictly centralized service Centralized platform Strictly centralized service Strictly centralized service Centralized platform Strictly centralized service Strictly centralized service Strictly centralized service, or Centralized w/ decentralized delegation

11 11 Centralization: Infrastructure Component Datacenters Networking IP address mgmt Inventory mgmt Software depot Config mgmt Namespace mgmt Communications Data mgmt Monitoring + Logging Automated systems Private cloud Recommendation Centralized w/ decentralized delegation Centralized w/ decentralized delegation Centralized w/ decentralized delegation Strictly centralized service Strictly centralized service Strictly centralized service Strictly centralized service Centralized platform Centralized platform Centralized platform Strictly centralized service Strictly centralized service

12 12 Centralization: Support Component Helpdesk End-user support Server support Infra support Security operations Malware detection Recommendation Strictly centralized service Centralized w/ decentralized delegation Centralized w/ decentralized delegation Strictly centralized service Strictly centralized service Strictly centralized service

13 14 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

14 15 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

15 16 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

16 17 Service Design: HOWTO Issues: Speaking the same language Asking the right questions Difficult requests

17 18 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

18 Software: Multi Tier Architecture 19

19 20 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)

20 21 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

21 22 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

22 23 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

23 24 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.

24 25 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)

25 26 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

26 27 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

27 28 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

28 29 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

29 30 Change Process SA writes change proposal Which changes Systems and services affected Reason Risks Test procedure Success Criteria Backout plan Change duration Backout duration Decision point

30 31 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

31 32 Change Process (cont d) Scheduling Time in week Change freezes cf. Maintenance Windows (Ch. 34) Communication DevOps challenge: Eliminate CRB

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

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

34 Example: Server OS Upgrade (Ch. 33) 35 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

35 36 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

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

37 38 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

38 39 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

39 40 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

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

41 42 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)

42 Naming 43

43 44 Major Planned Maintenance Flight director technique Coordinates group of SAs in 3 stages: Stage Preparation Execution Resolution Activity a)schedule a window b)pick a flight director c) Prepare change proposals d)build a master plan a)disable access b)determine shutdown sequence c) Execute plan d)perform testing a)announce completion b)enable access c) Have a visible presence d)be prepared for problems

44 45 Preparation Get Management Buy-in Schedule the Window Select a Flight Director Managing Change Proposals Build a Master Plan Table per person: what & when Collated into master chart Shows dependencies System-wide tests

45 46 Preparation + Execution Ensuring Mechanics and Coordination Test vital tools Document shutdown/boot sequences Ensure communication during maintenance Disabling Access Track progress, update plan Test system

46 47 Resolution Inform customers Reenabling Remote Access Be Visible the Next Morning Postmortem