1. 2. 3. 4. 5. · Private cloud Strictly centralized service. 12 Centralization: Support Component...
Transcript of 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
1. Strategy Business Case
2. Design RequirementsDesign
3. Transition BuildTestDeploy
4. Operation DeliverSupport
5. Continual Improvement
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
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
19
Software: Multi Tier Architecture
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)
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
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
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 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
1. Strategy Business Case
2. Design RequirementsDesign
3. Transition BuildTestDeploy
4. Operation DeliverSupport
5. Continual Improvement
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
Server Upgrade Process (cont’d)
Step 3: Develop Verification Tests Is the service working properly Useful before and after OS upgrade! Reusable (DevOps)
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
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
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
41
Server Upgrade Process (cont’d)
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