ITIL in practice

VẤN ĐỀ • Các nhóm hoạt động độc lập • Trao đổi thông tin không tốt giữa • Không rõ ràng về cam kết chất lượng và escalation contact point • Không có số đo về chất lượng vận hành • Không

ITIL IN PRACTICE

Lê Thành Trung

01/2014

GIỚI THIỆU

VỀ CÁ NHÂN

• Lê Thành Trung

• Kinh nghiệm:

– 13 năm làm việc trong lĩnh vực IT

– 8 năm làm việc tại VNG

VỀ VNG

“Phát triển Internet để thay đổi cuộc sống

người Việt Nam”

QUÁ TRÌNH TRIỂN KHAI

1 THÀNH LẬP OPERATION OFFICE

TỔ CHỨC

Web Technical Operation

Game Business

Game Technical Operation

Web Business

Share Systems

Data Center

Storage Service

Desk

TỔ CHỨC

Web Technical Operation

Game Business

Game Technical Operation

Web Business

Share Systems

VẤN ĐỀ

• Các nhóm hoạt động độc lập

• Trao đổi thông tin không tốt giữa

• Không rõ ràng về cam kết chất lượng và escalation contact point

• Không có số đo về chất lượng vận hành

• Không tổng hợp được các vấn đề

• Không đánh giá được hiệu quả giải pháp

• Không có chiến lược chung về vận hành

OPERATION OFFICE

• 2008 – VNG có COO

• 2009 – Thành lập Operation Office

cụ/quy trình nhằm tăng chất lượng vận hành

NGUYÊN TẮC

Con người

Công

cụ

Quy trình

Chất Lượng Vận Hành

Data Center Service Desk TOM

Ảnh hưởng thông qua

Operation Processes &

Policy

– IT Service là gì?

Là các dịch vụ liên quan đến IT cung cấp bởi

ITIL V2

ITIL V2 - SERVICE SUPPORT

Duy trì khả năng liên

tục , sẵn sàng và chất

lượng của các dịch vụ

IT đến End User

ITIL V2 - SERVICE DELIVERY

Cam kết SLA – Service Level Agreement

– Sau 8h sẽ tạo xong account và cấp quyền cho User tính từ khi nhận được yêu cầu

– Khó khăn trong việc truy cập vào hệ thống

sẽ được giải quyết trong vòng 4h

ITIL V2

• Service Support

nhập/sử dụng hệ thống (Incident Mng.)

nhiều lần để xử lý triệt để (Problem Mng.)

có thay đổi (Change Mng.)

thống được Test kỹ trước khi thực hiện (Release Mng.)

ITIL V2

• Service Delivery

Uptime 99% (Availability Mng.)

license cung cấp cho End User (Capacity Mng.)

lại hệ thống khi có sự cố (Continuity Mng.)

vụ, cách hạch toán và phân bổ chi phí (Financial

2 LỰA CHỌN HỆ THỐNG ITSM

– Quản lý tập trung việc vận hành

• Mục tiêu

– Lựa chọn hệ thống triển khai quy trình ITIL V2

LỰA CHỌN HỆ THỐNG ITSM

• Tiêu chí quan trọng

– Xây dựng theo chuẩn quy trình ITIL

– Có khả năng customize theo nhiều yêu cầu (giao diện, quy trình, dữ liệu, biểu mẫu, dữ liệu …)

– Hỗ trợ nhiều module/process để có thể

mở rộng theo nhu cầu tương lai

– Nằm trong ngân sách cho phép

Strictly Confidential – Do Not Distribute

• Hiệu chỉnh quy trình và thương lượng

• Đào tạo chuyển giao hệ thống

-> Kết quả 1 tháng triển khai

TRIỂN KHAI

• Thuê chuyên gia đào tạo ITIL V2 cho 40

Senior Engineer

• Tuyển dụng bổ sung 1 Senior PQA

• Tập trung vào Service Support

3 SERVICE DESK

Những khách hàng khó tính nhất của bạn chính là những người giúp

THAY ĐỔI TỔ CHỨC

• Tách Service Desk thành Dept độc lập

• Nhiệm vụ hỗ trợ sản phẩm

– Theo dõi tình trạng kỹ thuật của sản phẩm

– Cung cấp thông tin tình hình xử lý incident

– Dịch vụ First Level Support xử lý Incident

– Đảm bảo thông tin về Incident được quản

lý chính xác và đầy đủ

THAY ĐỔI TỔ CHỨC

Web Technical Operation

Game Business

Game Technical Operation

Web Business

Share Systems

Storage

TOM

Service Desk

SERVICE DESK KPI

• % số Incident Service Desk tự xử lý được

• Số Incident không thể phát hiện bởi hệ

GHI CHÚ

• Service Desk đóng vai trò “Cực Kỳ Quan

Trọng” trong việc triển khai ITIL & Process

• Service Desk Leader phải hướng đến khách hàng và chất lượng dịch vụ

• Service Desk tạo ra sức ép và động lực cho các dịch vụ IT

• Service Desk Leader luôn đặt ra yêu cầu

4 INCIDENT MANAGEMENT

Chúng ta chỉ tin tưởng vào Chúa, còn lại đều phải chứng minh

bằng số liệu

INCIDENT

• Incident là sự gián đoạn không có kế

hoạch của một dịch vụ IT hoặc là ngưng hoạt động của một thành phần dịch vụ mà không làm ảnh hưởng đến dịch vụ

YÊU CẦU

• Một quy trình quản lý Incident chung

• Kênh thông tin thống nhất về Incident

• Có thể quản lý toàn bộ thông tin về Incident

• Đưa ra các quy định để hạn chế ảnh hưởng của Inc tới Business

• Làm cơ sở để phân tích

– Nguyên nhân, xu hướng Incident

– Giải pháp hạn chế Incident & ảnh hưởng

– Đánh giá hiệu quả vận hành

QUY TRÌNH TƯƠNG TÁC

INCIDENT MANAGEMENT & BUSINESS

• Incident -> Downtime -> Impact Business

• Business Impact Metrics

– …

• Thiết lập 5 level cho incident

INCIDENT MANAGEMENT & OPERATION

INCIDENT MANAGEMENT & OPERATION

• Phân nhóm Incident theo

category & sub category

• Phân nhóm Incident theo loại Controllable

Category

Can’t Identify Human

Security Software CDN Virtualization Server

Network Facility

INCIDENT ANALYSIS SAMPLE

Incident root cause trend (by area)

INCIDENT MANAGEMENT & TEAMS

Service Desk

Functional Teams

Customer Support

Product Tech

Operation Teams

INCIDENT MANAGEMENT & TEAMS

Service Desk

Functional Teams

Customer Support

Management Teams

Product Tech

Operation Teams

Chịu trách nhiệm thu thập và nhập thông tin chính xác về quá

trình xử lý incident

Hỗ trợ bộ phận sản phẩm khắc

phục incident hoặc xử lý incident

Chịu trách nhiệm cập nhật thông

tin cách xử lý và nguyên nhân

của incident Làm báo cáo về incident

Các team đều chịu chung KPI

là Incident Downtime -> tăng mức độ hợp tác

INCIDENT MANAGEMENT POLICY

• Escalation Path & Time scales

• Incident Close

định root cause, solution/workaround

INCIDENT MANAGEMENT POLICY

• Critical Incident Analysts – CIA Team

thuật

đến Inc Level 1,2 phải làm báo cáo, gửi cho CIA

• TOM theo dõi quá trình tổ chức và thực hiện theo action

LIÊN KẾT INCIDENT

• 1 Incident có thể tạo ra nhiều incident liên quan ảnh hưởng đến nhiều sản phẩm

• 1 incident có thể gây ra do 1 Change

• 1 incident có thể link tới Problem và Known Error

-> Operation Team Leader tạo link đến Inc

Note:

CÁC HỆ THỐNG PHÁT SINH

• Service Desk

• Product Team & Tech Operation Team

INCIDENT MANAGEMENT & KPI

• Số lượng incident gây ra ảnh hưởng đến toàn bộ sản phẩm

• Số lượng incident level 1,2

• Số lượng incident liên quan đến

security

• Thời gian downtime & ảnh hưởng tới business (CCU, …)

INCIDENT MANAGEMENT & CSF

53

• Service Desk Team

– Phải hiểu rõ nhiệm vụ & trách nhiệm

– Chịu khó trong việc nhập dữ liệu chính xác

– Tuân thủ chính xác quy định về xử lý Incident

– Leader hiểu biết về Soft Dev & Data Analysis

• Product Operation Team

– Hiểu trách nhiệm

– Set KPI để phối hợp chặt chẽ với Service Desk

– Trung thực và có khả năng phân tích root cause &

action plan

• CIA

– Có khả năng review và phản biện với Operation Team

5 CONFIGURATION MANAGEMENT

Data are of high quality "if they are fit for their intended uses in

operations, decision making, and planning"

Joseph M Juran

Dữ are được coi là có chất lượng

“khi nó đáp ứng nhu cầu sử dụng trong vận hành, ra quyết định và lập kế hoạch"

Strictly Confidential – Do Not Distribute

HP Universal CMDB

57

Network Configuration Layer

CMDB

Facility

Equipment &

Network

Server & Storage Layer

Physical Server Storage Virtual Server VLAN ACL

Configuration Item (CI)

VAI TRÒ CỦA CMDB

• CMDB là nguồn thông tin quan trọng cho vận hành

• Không có CMDB thì như mù khi vận hành

• Có CMDB nhưng dữ liệu không được cập nhật thì vận hành mà luôn có rủi ro

-> Sử dụng PQA để thực hiện audit dữ liệu

QUẢN LÝ CMDB

Kết luận

• CMDB khó đảm bảo chính xác 100%

• Cần có cách thức quản lý và Audit để

đánh giá mức độ chính xác của dữ liệu

• Cần gắn trách nhiệm của mỗi bộ phận với một loại dữ liệu cụ thể

QUẢN LÝ CMDB

MDR 2 Information Mng Process

MDR 3 Information Mng Process

MDR 4 Information Mng Process

CMDB & CSF

• Các bộ phận hiểu rõ tầm quan trọng của dữ liệu CMDB trong vận hành

• Hướng tới việc cập nhật dữ liệu tự động

• Có chiến lược quản lý dữ liệu CMDB bằng cách đưa activity trong process và phân

trách nhiệm theo nhóm

• PQA có hiểu biết về các dữ liệu và phương pháp quản lý để Audit dữ liệu chính xác

6 CHANGE MANAGEMENT

Không phải loài mạnh nhất cũng như thông minh nhất là có thể tồn tại mà chính là loài có khả năng

thích nghi nhất với sự thay đổi

• Tạo ra các quy định và cách giám sát

(control) để đảm bảo Change

QUY TRÌNH

CHANGE MANAGEMENT & BUSINESS

• Giúp Engineer hiểu được ảnh hưởng

của các Change đối với Business

• Engineer có trách nhiệm và chủ động

đánh giá, lập kế hoạch cho các Change

-> giảm thiểu ảnh hưởng đối với Business

• Thiết lập các quy định nhằm hạn chế tối

đa các ảnh hưởng của Change đối với Business

Strictly Confidential – Do Not Distribute

CHANGE MANAGEMENT & OPERATION

73

• Giúp Engineer hiểu được trách nhiệm

và quyền hạn khi thực hiện hoặc phê duyệt Change

• Quản lý và thông tin về Change và

cập nhật cho các bên liên quan

• Quản lý và đánh giá rủi ro cho các

Change

• Quản lý cập nhật thông tin vào CMDB đối với các Change

CHANGE MANAGEMENT & OPERATION

• Phân loại Change theo Level

• Change level được xác định dựa trên level Incident mà Change có thể gây

Strictly Confidential – Do Not Distribute

CHANGE MANAGEMENT & OPERATION

CHANGE MANAGEMENT & COMMUNICATION

• Technical Operation Team mở Change

• Team Leader -> Close Change

• Change quá thời gian quy định

-> Service Desk mở Incident và link đến

CHANGE MANAGEMENT & CAB

• CAB phê duyệt Change, phản biện các giải pháp kỹ thuật

– Đảm bảo các Change được chuẩn bị trước

– Đảm bảo đánh giá chính xác rủi ro

– Các kế hoạch phải được lên chi tiết

– Có phương pháp kiểm tra lại kết quả khi

Change

– Có kế hoạch backup nếu Change thất bại

CHANGE MANAGEMENT & CAB

• Technical Operation Team phải

chuẩn bị tài liệu kỹ thuật

– Sơ đồ hệ thống

– Cấu hình thiết bị

– Báo cáo kết quả test

– Kế hoạch Change

CHANGE MANAGEMENT & KPI

• Số lượng Change gây ra Incident và Impact đến Business

• Số lượng Change không tuân thủ

theo quy trình

• Kết quả Audit của PQA cho việc tuân thủ đúng quy trình Change

Management

CHANGE MANAGEMENT & CSF

• Product Operation Team

– Hiểu rõ trách nhiệm và ảnh hưởng đến Business nếu không thực hiện theo Change Process

7 PROBLEM MANAGEMENT

PROBLEM

• Problem là nguyên nhân (cause) gây

ra nhiều Incident hoặc Incident có

ảnh hưởng đến nhiều User

MỤC TIÊU

• Thiết lập quy trình thực hiện

– Phân tích các Incident để xác định

Problem

– Theo dõi, xử lý Problem để

User lặp lại

QUY TRÌNH

• Problem Manager đưa ra action plan để

xử lý hoặc ngăn ngừa Known Error xảy ra

XÁC ĐỊNH PROBLEM

• Sử dụng phân tích Pareto xác định nhóm nguyên nhân Incident

• Đặt câu hỏi “WHY” trên các nguyên nhân

để tìm hiểu sâu

• Sử dụng phân tích sơ đồ xương cá

XÁC ĐỊNH PROBLEM

PROBLEM MANAGEMENT & BUSINESS

• Giải quyết triệt để Inc -> Ổn định hoạt

động Business

• Khó thấy được giá trị của Problem

Management đối với Business

- > Operation Team không có nhiều động lực

để thực hiện

PROBLEM MANAGEMENT & OPERATION

các Incident lặp lại -> hiệu quả về nhân lực

Incident rơi vào 2 trường hợp

- Incident ảnh hưởng đến nhiều User -> đã

được xử lý theo Incident Mng Process

- Incident lặp lại -> phụ thuộc vào Vendor

Kết luận

8 CAPACITY MANAGEMENT

Mong chờ kết quả tốt nhất Chuẩn bị cho khả năng xấu nhất

Capacity Report

Capacity Plan

CAPACITY MANAGEMENT & BUSINESS

• Engineer luôn plan over capacity cho

trường hợp “the worst”

• Business luôn nghĩ tới trường hợp “the

best”

-> Khó đánh giá hiệu quả của Capacity

Management cho Business

CAPACITY MANAGEMENT & OPERATION

• Capacity cho biết tình hình sử dụng tài

9 RISK MANAGEMENT

The more we think about risk, the more risk seem to be

Ben Carson

Càng nghĩ nhiều về rủi ro thì càng có nhiều rủi ro (có thể xảy ra)

TRIỂN KHAI

• Nghiên cứu các Risk Managemet

Framework và lựa chọn

TRIỂN KHAI

• Nghiên cứu các phương pháp đánh giá

FMEA áp dụng cho đánh giá Risk của Process FAIR áp dụng cho đánh giá Risk theo các yếu

tố trong vận hành (Factors)

TRIỂN KHAI

• Đánh giá Risk theo FMEA -> Khó + Không phù hợp

• Đánh giá Risk theo Factor

-> Cần có template và Factor chuẩn

COBIT Risk IT Practitioner Guide

RISK & CONTROL

• Xác định các Asset

• Xác định các Risk liên quan đến Asset

• Xác định các Control để giảm nhẹ/ngăn ngừa Risk

COBIT Risk IT Practitioner Guide

COBIT Risk IT Practitioner Guide

• Xây dựng metrics của Risk Rating

RISK ASSESSMENT TEMPLATE

RISK ASSESSMENT TEMPLATE

RISK CONTROL TEMPLATE

RISK CONTROL TEMPLATE

RISK MANAGEMENT & BUSINESS

RISK MANAGEMENT & OPERATION

• Xác định rủi ro và chủ động thực hiện

giải pháp ngăn ngừa Inc

• Có kế hoạch phòng ngừa hoặc khắc

phục nếu rủi ro xảy ra

• Yêu cầu Review Risk/Control Data khi có Inic và Change giúp liên tục cập nhật

Risk Status

-> Tăng tính chủ động trong vận hành

RISK MANAGEMENT & PROCESS KHÁC

Thực hiện Control

Risk Assessment

(Hàng Quý)

Incident Management

Change Management Risk & Control

Data

RISK MANAGEMENT & KPI

• Tỉ lệ % số Risk được control

• Số incident xảy ra do control không

hiệu quả

RISK MANAGEMENT & CSF

• Các team vận hành phải hiểu rõ ý nghĩa

của việc đánh giá rủi ro

• Người thực hiện đánh giá rủi ro phải có

hiểu biết tốt về asset cần đánh giá

• Người review cần có kiến thức tốt để phản biện về risk data và ảnh hưởng

• Các control được chuẩn hóa theo các

process vận hành (Change Mng., Capacity

10 BÀI HỌC KINH NGHIỆM

CAM KẾT

• Lãnh đạo cấp cao phải có cam kết thực hiện

– Triển khai KPI

– Xem báo cáo phân tích

– Tham gia họp định kỳ

– Yêu cầu các team phối hợp thực hiện

CÁC BƯỚC TRIỂN KHAI

TEAMS

• Cần có team dành toàn bộ cho việc

– Phát triển và duy trì process/policy

– Đào tạo Process

– Đưa Process vào hệ thống ITSM

– Làm báo cáo định kỳ về tình hình tuân thủ process trong vận hành

KPI

• Toàn bộ các team vận hành cần chia sẻ

KPI liên quan đến

• Dữ liệu phải được thu thập chính xác,

khách quan để đánh giá KPI

TIẾP CẬN TRIỂN KHAI

• PQA phải bắt đầu bằng mindset là support các team vận hành áp dụng quy trình

• PQA cũng cần độc lập và chính xác trong việc phân tích dữ liệu

• PQA phải có kiến thức và hiểu rõ việc vận hành sản phẩm để có đánh giá chính xác

và khách quan

• Luôn hướng tới việc tạo nhận thức cho

các team về giá trị của các Process

THEO DÕI TRIỂN KHAI

• TOM định kỳ theo dõi các action plan (Incident/ Change/ Risk Management)

để đảm bảo các team thực hiện

• Có số liệu thống kê tình hình Incident

và các chỉ số KPI cần thiết để các

team nắm rõ thông tin và hiểu rõ

trách nhiệm

11 Q&A

Q&A

12 ITIL V3

13 HUẤN LUYỆN

• Triển khai quy trình vào thực tế

• PQA: Phân tích dữ liệu và Báo cáo

• Lựa chọn và đào tạo nhân sự

XIN CÁM ƠN!

CHÚC MỪNG NĂM MỚI 2014