1. 2. 3. 4. 5. · Private cloud Strictly centralized service. 12 Centralization: Support Component...

1

Recap: Helpdesk Scope of Support

1.2.3.4.5.

2

Limoncelli Process (cont’d)

Phase D: Verification ("Verify It") Step 8: Step 9:

3

Recap: Debugging

Occam's Razor 3 Debugging Approaches

LIA

Large Installation Administration

Services

5

Managing IT Services

Stages Activities

1. Strategy Business Case

2. Design RequirementsDesign

3. Transition BuildTestDeploy

4. Operation DeliverSupport

5. Continual Improvement

Improve

Source: ITIL

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

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

(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

(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

Centralization Recommendations

Architecture Strictly centralized

Security: Component Recommendation

Authentication Strictly centralized service

Authorization Centralized platform

Internet Access Strictly centralized service

Remote Access Strictly centralized service

Extranet connections Centralized platform

New acquisitions Strictly centralized service

Malware detection Strictly centralized service

Data leakage prevention Strictly centralized service, orCentralized w/ decentralized delegation

11

Centralization: InfrastructureComponent Recommendation

Datacenters Centralized w/ decentralized delegation

Networking Centralized w/ decentralized delegation

IP address mgmt Centralized w/ decentralized delegation

Inventory mgmt Strictly centralized service

Software depot Strictly centralized service

Config mgmt Strictly centralized service

Namespace mgmt Strictly centralized service

Communications Centralized platform

Data mgmt Centralized platform

Monitoring + Logging Centralized platform

Automated systems Strictly centralized service

Private cloud Strictly centralized service

12

Centralization: Support

Component Recommendation

Helpdesk Strictly centralized service

End-user support Centralized w/ decentralized delegation

Server support Centralized w/ decentralized delegation

Infra support Strictly centralized service

Security operations Strictly centralized service

Malware detection Strictly centralized service

14

Next Stage: Design

Stages Activities






Improve

Source: ITIL

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

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

17

Service Design: HOWTO

Issues: Speaking the same language Asking the right questions Difficult requests

18


Utility and Warranty requirements are turned into Service Level Requirements

IT department then Evaluates feasibility and costs Creates functional design Creates technical design / architecture

19

Software: Multi Tier Architecture

20


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)

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

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

23


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

24


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 2nd Monday of each month.

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)

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

Source: ITIL for Dummies

G=Target Met, A = Target Threatened, R = Target Breached

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

28

Next Stage: Transition

Stages Activities






Improve

Source: ITIL

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

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

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

32

Change Process (cont’d)

Scheduling Time in week Change freezes cf. Maintenance Windows (Ch. 34)

Communication DevOps challenge: Eliminate CRB

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

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?

35Example: Server OS Upgrade (Ch. 33)

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

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

37


Step 3: Develop Verification Tests Is the service working properly Useful before and after OS upgrade! Reusable (DevOps)

38


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

39


Step 5: Write Detailed Implementation Plan Detailed, step-by-step Steps for OS and packages / services Add/Remove services? Plan dress rehearsal

40


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

41


Step 14: Restore Access Step 15: Communicate Success/Failure

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)

43

Naming Naming

44

Major Planned Maintenance

Flight director technique Coordinates group of SAs in 3 stages:

Stage Activity

Preparation a)Schedule a windowb)Pick a flight directorc)Prepare change proposalsd)Build a master plan

Execution a)Disable accessb)Determine shutdown sequencec)Execute pland)Perform testing

Resolution a)Announce completionb)Enable accessc)Have a visible presenced)Be prepared for problems

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

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

47

Resolution

Inform customers Reenabling Remote Access Be Visible the Next Morning Postmortem

1. 2. 3. 4. 5. · Private cloud Strictly centralized service. 12 Centralization: Support Component...

Documents

Transcript of 1. 2. 3. 4. 5. · Private cloud Strictly centralized service. 12 Centralization: Support Component...