Your SlideShare is downloading. ×
0
ITIL IN PRACTICE

Lê Thành Trung
01/2014
GIỚI THIỆU

Strictly Confidential – Do Not Distribute

2
VỀ CÁ NHÂN
• Lê Thành Trung
– Senior Operation Manager

• Kinh nghiệm:
– 13 năm làm việc trong lĩnh vực IT
– 8 năm làm việ...
VỀ VNG
• VNG là công ty hàng đầu Việt Nam trong lĩnh
vực Internet (www.vng.com.vn)

“Phát triển Internet để thay đổi cuộc ...
MỤC ĐÍCH
• Chia sẻ bài học và kinh nghiệm triển khai
quy trình vận hành (theo ITIL) tại VNG
– Service Desk
– Incident Mana...
QUÁ TRÌNH TRIỂN KHAI
•
•
•
•
•
•

2008 – Thành lập Operation Office
2009 – Triển khai hệ thống ITSM
2009 – Triển khai đào ...
1. THÀNH LẬP OPERATION OFFICE

Strictly Confidential – Do Not Distribute

7
VNG 2008
•
•
•
•

~ 200 Engineer
~15 products cho Game + Web Business
~ 5 Share Systems
Tự vận hành Data center
– Hàng tră...
TỔ CHỨC
Web Business

Game Business

Service
Desk

Game Technical
Operation

NOC

Share
Systems

Network

Facility

Web Te...
TỔ CHỨC

Game Business

?
Service
Desk

Web Business
?

Game Technical
Operation

?

Share
Systems

?

?

Web Technical
Op...
TỔ CHỨC
• Technical Operation Team
Dept. Head
Technical Operation Team
Leader

SE Level 1

Product(s)

SE Level 2
SE = Sys...
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à
escalatio...
OPERATION OFFICE
• 2008 – VNG có COO
• 2009 – Thành lập Operation Office
– Thiết lập các quy trình vận hành
– Triển khai c...
NGUYÊN TẮC

Quy
trình

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

Công
cụ
Con
người

Strictly Confidential – Do Not Distribute

14
THỰC HIỆN
• Thành lập Technical Operation Management
(TOM) Dept.
• Các nhóm vận hành sản phẩm báo cáo cho
COO
COO

Ảnh hưở...
THỰC HIỆN

• Quyết định sử dụng ITIL làm cơ sở để phát
triển các quy trình vận hành
– ITIL là gì?
ITIL là tập các “best pr...
ITIL V2

Strictly Confidential – Do Not Distribute

17
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

Strictly Con...
ITIL V2 - SERVICE DELIVERY
Đảm bảo khả năng
quản lý các dịch vụ IT
để luôn cung cấp cho
khách hàng dịch vụ
như cam kết

St...
ITIL V2
• Ví dụ
Bộ phận IT quản lý hệ thống ERP và cung
cấp dịch vụ cấp quyền truy cập vào hệ
thống.
Cam kết SLA – Service...
ITIL V2
• Service Support
– Quy trình hỗ trợ khách hàng khi không thể đăng
nhập/sử dụng hệ thống (Incident Mng.)
– Quy trì...
ITIL V2
• Service Delivery
– Quy trình kiểm tra định kỳ đảm bảo hệ thống
Uptime 99% (Availability Mng.)
– Quy trình kiểm t...
2. LỰA CHỌN HỆ THỐNG ITSM

Strictly Confidential – Do Not Distribute

23
LỰA CHỌN HỆ THỐNG ITSM
• Hiện trạng
– Một số nhóm đã triển khai Incident Mng. Process
– Một số nhóm đã đi học ITIL
– Một s...
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
...
LỰA CHỌN HỆ THỐNG ITSM

• Các hệ thống được chọn
– Axios
– HP ITSM
– IBM Maximo

-> Lựa chọn: HP ITSM
Strictly Confidentia...
TRIỂN KHAI
• Thống nhất quy trình chung
• Làm việc với đối tác triển khai
• Thực hiện UAT
• Hiệu chỉnh quy trình và thương...
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 Serv...
3. SERVICE DESK

Strictly Confidential – Do Not Distribute

29
Những khách hàng khó tính nhất
của bạn chính là những người giúp
bạn học được nhiều bài học nhất
Strictly Confidential – D...
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ả...
THAY ĐỔI TỔ CHỨC
Web Business

Game Business

Service Desk

Game Technical
Operation

TOM

NOC

Share
Systems

Network

We...
NHÂN LỰC
• Service Desk
– Trực ca 24/7
– Tool Dev. Team
– System Operation
– Process Quality Assurance (PQA)

Strictly Con...
SERVICE DESK KPI
• % số Incident Service Desk tự xử lý được
• Số Incident không thể phát hiện bởi hệ
thống Monitor
• Số In...
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ư...
4. INCIDENT MANAGEMENT

Strictly Confidential – Do Not Distribute

36
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.
Strictly Confidential – Do Not Distribute

37
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...
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 ...
QUY TRÌNH TƯƠNG TÁC

Strictly Confidential – Do Not Distribute

40
CÂU HỎI

• Giá trị của Incident Management với
Business?
• Giá trị của Incident Management đối với
Operation?

Strictly Co...
INCIDENT MANAGEMENT & BUSINESS
• Incident -> Downtime -> Impact Business
• Business Impact Metrics
– Số lượng User (CCU)
–...
INCIDENT MANAGEMENT & OPERATION

• Thống kê số liệu
– Nhóm incident và số lượng
– Nhóm Incident gây impact nhiều cho
busin...
INCIDENT MANAGEMENT & OPERATION
• Phân nhóm Incident theo
category & sub category

Category
Can’t Identify
Human
Security
...
INCIDENT ANALYSIS SAMPLE

Incident root cause trend (by area)
140
120
100
80
60
40

20
0

1

2

3

Software

4

1

2

3

N...
INCIDENT MANAGEMENT & TEAMS
Functional
Teams

Product Tech.
Operation
Teams

Service
Desk

Customer
Support

Management
Te...
INCIDENT MANAGEMENT & TEAMS
Hỗ trợ bộ phận sản phẩm khắc
phục incident hoặc xử lý incident

Product Tech.
Operation
Teams
...
INCIDENT MANAGEMENT POLICY
• Escalation Path & Time scales
– Service Desk: 15-60 phút đánh giá inc.
– Engineer Level 1: 60...
INCIDENT MANAGEMENT POLICY
• Critical Incident Analysts – CIA Team
– Nhóm nhân sự có chuyên môn cao lĩnh vực kỹ
thuật
– Bắ...
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...
CÁC HỆ THỐNG PHÁT SINH
• Service Desk
– Monitoring & Alert
– Incident Ticket Open Tool
– Contact Management
– Call center ...
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ư...
INCIDENT MANAGEMENT & CSF
• 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í...
5. CONFIGURATION MANAGEMENT

Strictly Confidential – Do Not Distribute

54
Joseph M. Juran

Data are of high quality "if they are
fit for their intended uses in
operations, decision making, and
pla...
YÊU CẦU
• Xây dựng hệ thống quản lý dữ liệu phục
vụ cho các hoạt động vận hành
– Xác định mức độ ảnh hưởng của CI khi có
I...
HP Universal CMDB

Strictly Confidential – Do Not Distribute

57

CMDB = Configuration Management Database
CMDB
Configuration Item (CI)

Server
Configuration

IP/MAC

OS

Service/
Software

System
Linkages

Product Layer
Physical...
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...
QUẢN LÝ CMDB
• Việc thu thập dữ liệu cập nhật 1 lần vào
CMDB là không đủ tốt
• Đưa các activity cập nhật CMDB vào quy
trìn...
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...
QUẢN LÝ CMDB

Strictly Confidential – Do Not Distribute

62
MÔ HÌNH fCMDB & MDR
fCMDB

MDR 1

MDR 2

MDR 3

MDR 4

MDR 1
Information
Mng. Process

MDR 2
Information
Mng. Process

MDR...
MÔ HÌNH fCMDB & MDR
• Tạo ra sự tự do cho các tool quản lý thông
tin ở từng nhóm vận hành & phân trách
nhiệm
• Đồng bộ dữ ...
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
...
6. CHANGE MANAGEMENT

Strictly Confidential – Do Not Distribute

66
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ự t...
CHANGE
• Là sự bổ sung, sửa đổi hoặc loại bỏ bất cứ
cái gì (kiến trúc, quy trình, công cụ,
metrics, tài liệu, hoặc các CI ...
YẾU CẦU
• Đưa ra một quy trình chung cho toàn bộ
các Change
• Tạo ra một kênh thông tin chung nhất cho
các Change
• Tạo ra...
QUY TRÌNH

Strictly Confidential – Do Not Distribute

70
CÂU HỎI

• Giá trị của Change Management với
Business?
• Giá trị của Change Management đối
với Operation?

Strictly Confid...
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ệ...
CHANGE MANAGEMENT & OPERATION

• 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...
CHANGE MANAGEMENT & OPERATION

• Phân loại Change theo Level
• Change level được xác định dựa trên
level Incident mà Chang...
CHANGE MANAGEMENT & OPERATION

• Thiết lập quy định cho việc phê duyệt
change & theo nhu cầu business.
– Emergency Change ...
CHANGE MANAGEMENT & COMMUNICATION

• Technical Operation Team mở Change
Request
• Service Desk thông báo Change với các
bê...
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...
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á...
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 qu...
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 ...
7. PROBLEM MANAGEMENT

Strictly Confidential – Do Not Distribute

81
Problems are not stop signs,
they are guidelines.

Robert H. Schuller

Strictly Confidential – Do Not Distribute

Các vấn ...
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

Strictly Confid...
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 để
• Hạn...
QUY TRÌNH

Strictly Confidential – Do Not Distribute

85
XÁC ĐỊNH PROBLEM
• Mỗi Technical Operation Team chỉ định 1
người giữ vai trò Prolem Manager
• Định kỳ Problem Manager phân...
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
để...
XÁC ĐỊNH PROBLEM

88
CÂU HỎI

• Giá trị của Problem Management với
Business?
• Giá trị của Problem Management đối
với Operation?

Strictly Conf...
PROBLEM MANAGEMENT & BUSINESS
• Giải quyết triệt để Inc. -> Ổn định hoạt
động Business

• Khó thấy được giá trị của Proble...
PROBLEM MANAGEMENT & OPERATION
• Problem Management giúp giải quyết triệt để
các Incident lặp lại -> hiệu quả về nhân lực
...
8. CAPACITY MANAGEMENT

Strictly Confidential – Do Not Distribute

92
Mong chờ kết quả tốt nhất
Chuẩn bị cho khả năng xấu nhất
Strictly Confidential – Do Not Distribute

93
MỤC TIÊU
• Thiết lập quy trình quản lý capacity để
đảm bảo các sản phẩm có đủ capacity
(server, network bandwidth, …) phục...
CAPACITY MANAGEMENT
• Định kỳ hàng quý, các Technical Operation
Team thực hiện review lại capacity của
product và báo cáo
...
CÂU HỎI

• Giá trị của Capacity Management với
Business?
• Giá trị của Capacity Management đối
với Operation?

Strictly Co...
CAPACITY MANAGEMENT & BUSINESS
• Engineer luôn plan over capacity cho
trường hợp “the worst”
• Business luôn nghĩ tới trườ...
CAPACITY MANAGEMENT & OPERATION
• Capacity cho biết tình hình sử dụng tài
nguyên cho sản phẩm
• Operation bị ảnh hưởng bởi...
9. RISK MANAGEMENT

Strictly Confidential – Do Not Distribute

99
The more we think about risk,
the more risk seem to be.
Ben Carson

Strictly Confidential – Do Not Distribute

Càng nghĩ n...
YÊU CẦU

• Triển khai phương pháp đánh giá và
quả lý rủi ro (Risk) cho việc vận hành
kỹ thuật.
• Quản lý rủi ro tốt sẽ giú...
TRIỂN KHAI
• Nghiên cứu các Risk Managemet
Framework và lựa chọn
– COBIT

Strictly Confidential – Do Not Distribute

102
TRIỂN KHAI
• Nghiên cứu các phương pháp đánh giá
- FMEA (Failure Mode and Effects Analysis)
- FAIR (Factor Analysis of Inf...
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...
RISK & CONTROL

Assets

Risks

Controls

• Xác định các Asset
• Xác định các Risk liên quan đến Asset
• Xác định các Contr...
COBIT Risk IT Practitioner Guide

Strictly Confidential – Do Not Distribute

106
COBIT Risk IT Practitioner Guide

Strictly Confidential – Do Not Distribute

107
ĐÁNH GIÁ RISK
• Xác định ảnh hưởng của Risk tới Business
– Downtime
– %Business Interruption
– CCU Lost
–…

• Xây dựng bản...
RISK ASSESSMENT TEMPLATE

Strictly Confidential – Do Not Distribute

109
RISK ASSESSMENT TEMPLATE

Strictly Confidential – Do Not Distribute

110
RISK CONTROL TEMPLATE

Strictly Confidential – Do Not Distribute

111
RISK CONTROL TEMPLATE

Strictly Confidential – Do Not Distribute

112
CÂU HỎI

• Giá trị của Risk Management với
Business?
• Giá trị của Risk Management đối với
Operation?

Strictly Confidenti...
RISK MANAGEMENT & BUSINESS

• Xác định các rủi ro để có kế hoạch
giảm thiểu ảnh hưởng tới Business
• Đánh giá các rủi ro v...
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ặ...
RISK MANAGEMENT & PROCESS KHÁC

Incident
Management

Risk Assessment
(Hàng Quý)

Risk & Control
Data

Thực hiện
Control

C...
RISK MANAGEMENT & KPI

• Tỉ lệ % số Risk được control
• Số incident xảy ra do control không
hiệu quả

Strictly Confidentia...
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 ...
10. BÀI HỌC KINH NGHIỆM

Strictly Confidential – Do Not Distribute

119
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ầ...
CÁC BƯỚC TRIỂN KHAI
•
•
•
•
•

Lựa chọn hệ thống ITSM
Service Desk
Incident Management
Change Management
Risk Management
–...
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ệ t...
KPI
• Toàn bộ các team vận hành cần chia sẻ
KPI liên quan đến
– Incident
– Downtime
– Kết quả Audit việc tuân thủ Process ...
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 ...
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 h...
11. Q&A

Strictly Confidential – Do Not Distribute

126
Q&A

Strictly Confidential – Do Not Distribute

127
12. ITIL V3

Strictly Confidential – Do Not Distribute

128
ITIL V3
• Chuyển mô hình Platform Infrastructure
theo mô hình hướng Service
– Quản lý SLA
– Quản lý Service Cost

Sẽ tiếp ...
13. HUẤN LUYỆN

Strictly Confidential – Do Not Distribute

130
NỘI DUNG
•
•
•
•
•
•
•
•

Cách thức xây dựng các quy trình
Lựa chọn ITSM Tool
Sử dụng các Template
Thiết lập các tham số (...
XIN CÁM ƠN!

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

Strictly Confidential – Do Not Distribute

132
Upcoming SlideShare
Loading in...5
×

Itil in practice (public version)

2,753

Published on

10 Comments
22 Likes
Statistics
Notes
  • @Ngô Hà Hi Hà, anh rất vui khi slide này giúp được gì đó cho em. Về tài liệu mẫu theo anh em có thể tham khảo các tài liệu trên mạng hoặc sách ITIL V3. Việc xem tài liệu quy trình của một công ty và áp dụng cho một công ty khác là không khả thi do nhiều yếu tố như tổ chức, cách làm việc. Anh có thể chia sẻ với em một số sách anh có qua email của em
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • e chào a Lê Trung...cảm ơn slide của a cho e cái nhìn thực tế về triển khai ITil...e đang làm đồ án về triển khai ITil cho công ty Pesico...bọn e phải viết tài liệu cho từ service...nhưng chưa được xem tài liệu mẫu nào cả..và chưa được xem dự án thật nên ko biết làm như thế nào...anh có thể gips bọn e đk ko ạ..cảm ơn a
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Thanks anh Trung
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Thank You So Much!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Học hỏi được nhiều. Thanks
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
2,753
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
274
Comments
10
Likes
22
Embeds 0
No embeds

No notes for slide

Transcript of "Itil in practice (public version)"

  1. 1. ITIL IN PRACTICE Lê Thành Trung 01/2014
  2. 2. GIỚI THIỆU Strictly Confidential – Do Not Distribute 2
  3. 3. VỀ CÁ NHÂN • Lê Thành Trung – Senior Operation Manager • 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 • 4 năm làm Software Development Manager • 4 năm làm Operation Manager Strictly Confidential – Do Not Distribute 3
  4. 4. VỀ VNG • VNG là công ty hàng đầu Việt Nam trong lĩnh vực Internet (www.vng.com.vn) “Phát triển Internet để thay đổi cuộc sống người Việt Nam” Strictly Confidential – Do Not Distribute 4
  5. 5. MỤC ĐÍCH • Chia sẻ bài học và kinh nghiệm triển khai quy trình vận hành (theo ITIL) tại VNG – Service Desk – Incident Management – Configuration Management – Change Management – Problem Management – Capacity Management – Risk Management Strictly Confidential – Do Not Distribute 5
  6. 6. QUÁ TRÌNH TRIỂN KHAI • • • • • • 2008 – Thành lập Operation Office 2009 – Triển khai hệ thống ITSM 2009 – Triển khai đào tạo ITIL V2 2009 – Áp dụng Incident Management 2009 – Ứng dụng Configuration Management 2010 – Áp dụng Change Management 2011 - Áp dụng Problem Management Capacity Management • 2013 – Áp dung Risk Management • 2014 – Bắt đầu tiến hành áp dụng ITIL V3 Strictly Confidential – Do Not Distribute 6
  7. 7. 1. THÀNH LẬP OPERATION OFFICE Strictly Confidential – Do Not Distribute 7
  8. 8. VNG 2008 • • • • ~ 200 Engineer ~15 products cho Game + Web Business ~ 5 Share Systems Tự vận hành Data center – Hàng trăm server – Sử dụng 1/2 bandwidth của toàn VN Strictly Confidential – Do Not Distribute 8
  9. 9. TỔ CHỨC Web Business Game Business Service Desk Game Technical Operation NOC Share Systems Network Facility Web Technical Operation Server & Storage Data Center Strictly Confidential – Do Not Distribute 9
  10. 10. TỔ CHỨC Game Business ? Service Desk Web Business ? Game Technical Operation ? Share Systems ? ? Web Technical Operation ? NOC Network Facility Server & Storage Data Center Strictly Confidential – Do Not Distribute 10
  11. 11. TỔ CHỨC • Technical Operation Team Dept. Head Technical Operation Team Leader SE Level 1 Product(s) SE Level 2 SE = System Engineer 11
  12. 12. 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 Strictly Confidential – Do Not Distribute 12
  13. 13. OPERATION OFFICE • 2008 – VNG có COO • 2009 – Thành lập Operation Office – Thiết lập các quy trình vận hành – Triển khai các công cụ hỗ trợ vận hành – Theo dõi chất lượng vận hành – Nghiên cứu và thực hiện các cải tiến công cụ/quy trình nhằm tăng chất lượng vận hành Strictly Confidential – Do Not Distribute 13
  14. 14. NGUYÊN TẮC Quy trình Chất Lượng Vận Hành Công cụ Con người Strictly Confidential – Do Not Distribute 14
  15. 15. THỰC HIỆN • Thành lập Technical Operation Management (TOM) Dept. • Các nhóm vận hành sản phẩm báo cáo cho COO COO Ảnh hưởng thông qua Operation Processes & Policy TOM Strictly Confidential – Do Not Distribute Technical Operation Teams Data Center Service Desk 15
  16. 16. THỰC HIỆN • Quyết định sử dụng ITIL làm cơ sở để phát triển các quy trình vận hành – ITIL là gì? ITIL là tập các “best practices” (quy định, quy trình, checklist,…) giúp bộ phận IT cung cấp các dịch vụ IT (IT Services) phục vụ yêu cầu của Business – IT Service là gì? Là các dịch vụ liên quan đến IT cung cấp bởi bộ phận IT. Strictly Confidential – Do Not Distribute 16
  17. 17. ITIL V2 Strictly Confidential – Do Not Distribute 17
  18. 18. 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 Strictly Confidential – Do Not Distribute 18
  19. 19. ITIL V2 - SERVICE DELIVERY Đảm bảo khả năng quản lý các dịch vụ IT để luôn cung cấp cho khách hàng dịch vụ như cam kết Strictly Confidential – Do Not Distribute 19
  20. 20. ITIL V2 • Ví dụ Bộ phận IT quản lý hệ thống ERP và cung cấp dịch vụ cấp quyền truy cập vào hệ thống. 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 – Hệ thống Uptime 99% Strictly Confidential – Do Not Distribute 20
  21. 21. ITIL V2 • Service Support – Quy trình hỗ trợ khách hàng khi không thể đăng nhập/sử dụng hệ thống (Incident Mng.) – Quy trình ghi nhận nếu có các Incident lặp lại nhiều lần để xử lý triệt để (Problem Mng.) – Quy trình thông báo cho End User khi hệ thống có thay đổi (Change Mng.) – Quy trình kiểm soát đảm bảo việc cập nhật hệ thống được Test kỹ trước khi thực hiện (Release Mng.) Strictly Confidential – Do Not Distribute 21
  22. 22. ITIL V2 • Service Delivery – Quy trình kiểm tra định kỳ đảm bảo hệ thống Uptime 99% (Availability Mng.) – Quy trình kiểm tra đảm bảo có đủ capacity về license cung cấp cho End User (Capacity Mng.) – Quy trình kiểm tra đảm bảo khả năng khôi phục lại hệ thống khi có sự cố (Continuity Mng.) – Quy trình kiểm tra đảm bảo ngân sách cho dịch vụ, cách hạch toán và phân bổ chi phí (Financial Mng.) Strictly Confidential – Do Not Distribute 22
  23. 23. 2. LỰA CHỌN HỆ THỐNG ITSM Strictly Confidential – Do Not Distribute 23
  24. 24. LỰA CHỌN HỆ THỐNG ITSM • Hiện trạng – Một số nhóm đã triển khai Incident Mng. Process – Một số nhóm đã đi học ITIL – Một số hệ thống quản lý thông tin vận hành đã có • Nhu cầu – Quản lý tập trung việc vận hành – Triển khai thực tế các quy trình trên Tool • Mục tiêu – Lựa chọn hệ thống triển khai quy trình ITIL V2 – Chuẩn hóa quy trình áp dụng cho toàn bộ VNG – Tránh thay đổi quá nhiều quy trình hiện tại Strictly Confidential – Do Not Distribute 24
  25. 25. 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 25
  26. 26. LỰA CHỌN HỆ THỐNG ITSM • Các hệ thống được chọn – Axios – HP ITSM – IBM Maximo -> Lựa chọn: HP ITSM Strictly Confidential – Do Not Distribute 26
  27. 27. TRIỂN KHAI • Thống nhất quy trình chung • Làm việc với đối tác triển khai • Thực hiện UAT • 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 - Incident Management Process - Change Management Process - Service Request Strictly Confidential – Do Not Distribute 27
  28. 28. 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     Service Desk Incident Management Change Management Configuration Management • TOM quản lý hệ thống ITSM (vận hành/ cấu hình/ triển khai quy trình Strictly Confidential – Do Not Distribute 28
  29. 29. 3. SERVICE DESK Strictly Confidential – Do Not Distribute 29
  30. 30. Những khách hàng khó tính nhất của bạn chính là những người giúp bạn học được nhiều bài học nhất Strictly Confidential – Do Not Distribute 30
  31. 31. 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 đủ Strictly Confidential – Do Not Distribute 31
  32. 32. THAY ĐỔI TỔ CHỨC Web Business Game Business Service Desk Game Technical Operation TOM NOC Share Systems Network Web Technical Operation Facility Server & Storage Data Center Strictly Confidential – Do Not Distribute 32
  33. 33. NHÂN LỰC • Service Desk – Trực ca 24/7 – Tool Dev. Team – System Operation – Process Quality Assurance (PQA) Strictly Confidential – Do Not Distribute 33
  34. 34. SERVICE DESK KPI • % số Incident Service Desk tự xử lý được • Số Incident không thể phát hiện bởi hệ thống Monitor • Số Incident không được xử lý theo đúng hướng dẫn của First Level Support • Đánh giá PQA về việc tuân thủ quy trình của Service Desk – Escalation Timescale – Độ chính xác của thông tin –… Strictly Confidential – Do Not Distribute 34
  35. 35. 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 – Phân tích dữ liệu – Xác định vấn đề – Đề xuất các thay đổi. Strictly Confidential – Do Not Distribute 35
  36. 36. 4. INCIDENT MANAGEMENT Strictly Confidential – Do Not Distribute 36
  37. 37. 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. Strictly Confidential – Do Not Distribute 37
  38. 38. 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ụ. Strictly Confidential – Do Not Distribute 38
  39. 39. 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 Strictly Confidential – Do Not Distribute 39
  40. 40. QUY TRÌNH TƯƠNG TÁC Strictly Confidential – Do Not Distribute 40
  41. 41. CÂU HỎI • Giá trị của Incident Management với Business? • Giá trị của Incident Management đối với Operation? Strictly Confidential – Do Not Distribute 41
  42. 42. INCIDENT MANAGEMENT & BUSINESS • Incident -> Downtime -> Impact Business • Business Impact Metrics – Số lượng User (CCU) – Thời gian ko truy cập đến được dịch vụ –… • Thiết lập 5 level cho incident – Level 1 = level cấp cao nhất – Level 5 = level cấp thấp nhất – Level 6 = có incident nhưng ko gây impact Strictly Confidential – Do Not Distribute 42
  43. 43. INCIDENT MANAGEMENT & OPERATION • Thống kê số liệu – Nhóm incident và số lượng – Nhóm Incident gây impact nhiều cho business -> Xác định giải pháp xử lý – Áp dụng giải pháp -> Đo hiệu quả Strictly Confidential – Do Not Distribute 43
  44. 44. INCIDENT MANAGEMENT & OPERATION • Phân nhóm Incident theo category & sub category Category Can’t Identify Human Security Software CDN Virtualization Server Network Facility • Phân nhóm Incident theo loại Controllable & Non-controllable Strictly Confidential – Do Not Distribute 44
  45. 45. INCIDENT ANALYSIS SAMPLE Incident root cause trend (by area) 140 120 100 80 60 40 20 0 1 2 3 Software 4 1 2 3 Network Strictly Confidential – Do Not Distribute 4 1 2 3 N/A 4 1 2 3 Management 4 1 4 Facility 1 2 3 Hardware 4 2 3 3 1 4 Security Vendor Capacity 45
  46. 46. INCIDENT MANAGEMENT & TEAMS Functional Teams Product Tech. Operation Teams Service Desk Customer Support Management Teams Strictly Confidential – Do Not Distribute 46
  47. 47. INCIDENT MANAGEMENT & TEAMS Hỗ trợ bộ phận sản phẩm khắc phục incident hoặc xử lý incident Product Tech. Operation Teams 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 Strictly Confidential – Do Not Distribute Functional Teams Service Desk Management 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 Customer Support Các team đều chịu chung KPI là Incident Downtime -> tăng mức độ hợp tác 47
  48. 48. INCIDENT MANAGEMENT POLICY • Escalation Path & Time scales – Service Desk: 15-60 phút đánh giá inc. – Engineer Level 1: 60-90 phút để xử lý level 1 – Engineer Level 2: 60-90 phút để xử lý level 2 – High Level Manager: 15-60 phút (inc. level 1,2) • Incident Close – Incident phải chuyển trạng thái Close sau 72h – Team Leader là người thực hiện Close và xác định root cause, solution/workaround Strictly Confidential – Do Not Distribute 48
  49. 49. INCIDENT MANAGEMENT POLICY • Critical Incident Analysts – CIA Team – Nhóm nhân sự có chuyên môn cao lĩnh vực kỹ thuật – Bắt buộc Technical Operation Team liên quan đến Inc. Level 1,2 phải làm báo cáo, gửi cho CIA – Tổ chức review phân tích và rút kinh nghiệm – Đưa ra các action để ngăn ngừa Inc. lặp lại • TOM theo dõi quá trình tổ chức và thực hiện theo action Strictly Confidential – Do Not Distribute 49
  50. 50. 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: – Liên kết Incident với CI (server, network switch, …) sẽ giúp có dữ liệu tốt hơn. Strictly Confidential – Do Not Distribute 50
  51. 51. CÁC HỆ THỐNG PHÁT SINH • Service Desk – Monitoring & Alert – Incident Ticket Open Tool – Contact Management – Call center Integration – Customer Support System Integration – Knowledge Base Management • Product Team & Tech. Operation Team – Incident Data Analysis (Excel) Strictly Confidential – Do Not Distribute 51
  52. 52. 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, …) Strictly Confidential – Do Not Distribute 52
  53. 53. INCIDENT MANAGEMENT & CSF • 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 53
  54. 54. 5. CONFIGURATION MANAGEMENT Strictly Confidential – Do Not Distribute 54
  55. 55. Joseph M. Juran Data are of high quality "if they are fit for their intended uses in operations, decision making, and planning" 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 55
  56. 56. YÊU CẦU • Xây dựng hệ thống quản lý dữ liệu phục vụ cho các hoạt động vận hành – Xác định mức độ ảnh hưởng của CI khi có Inc. – Dự đoán mức ảnh hưởng của CI khi thực hiện Change – Có thông tin đánh giá khi thực hiện Release – Đánh giá rủi ro của CI trong vận hành – Dữ liệu cơ sở để làm capacity planning & capacity optimization Strictly Confidential – Do Not Distribute 56
  57. 57. HP Universal CMDB Strictly Confidential – Do Not Distribute 57 CMDB = Configuration Management Database
  58. 58. CMDB Configuration Item (CI) Server Configuration IP/MAC OS Service/ Software System Linkages Product Layer Physical Server Storage Virtual Server Server & Storage Layer Facility Equipment & linkages Network Equipment & linkages VLAN ACL Bandwidth Network Configuration Layer Rack Cables … Infrastructure & Data center Layer Strictly Confidential – Do Not Distribute 58
  59. 59. 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 Strictly Confidential – Do Not Distribute 59
  60. 60. QUẢN LÝ CMDB • Việc thu thập dữ liệu cập nhật 1 lần vào CMDB là không đủ tốt • Đưa các activity cập nhật CMDB vào quy trình – Change Management – Service Request/ Request Fulfillment –… • Cập nhật thủ công sẽ có sai sót -> Sử dụng PQA để thực hiện audit dữ liệu • Triển khai tool tự động cập nhật CMDB -> Khó thực hiện + Đắt tiền Strictly Confidential – Do Not Distribute 60
  61. 61. 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ể Strictly Confidential – Do Not Distribute 61
  62. 62. QUẢN LÝ CMDB Strictly Confidential – Do Not Distribute 62
  63. 63. MÔ HÌNH fCMDB & MDR fCMDB MDR 1 MDR 2 MDR 3 MDR 4 MDR 1 Information Mng. Process MDR 2 Information Mng. Process MDR 3 Information Mng. Process MDR 4 Information Mng. Process fCMDB = Federal CMDB MDR = Master Data Repository Strictly Confidential – Do Not Distribute 63
  64. 64. MÔ HÌNH fCMDB & MDR • Tạo ra sự tự do cho các tool quản lý thông tin ở từng nhóm vận hành & phân trách nhiệm • Đồng bộ dữ liệu về CMDB tập trung • Thực hiện các phân tích chung tại CMDB không ảnh hưởng đến các MDR Strictly Confidential – Do Not Distribute 64
  65. 65. 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 Strictly Confidential – Do Not Distribute 65
  66. 66. 6. CHANGE MANAGEMENT Strictly Confidential – Do Not Distribute 66
  67. 67. 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. Strictly Confidential – Do Not Distribute 67
  68. 68. CHANGE • Là sự bổ sung, sửa đổi hoặc loại bỏ bất cứ cái gì (kiến trúc, quy trình, công cụ, metrics, tài liệu, hoặc các CI …) có làm ảnh hưởng đến dịch vụ IT Strictly Confidential – Do Not Distribute 68
  69. 69. YẾU CẦU • Đưa ra một quy trình chung cho toàn bộ các Change • Tạo ra một kênh thông tin chung nhất cho các Change • Tạo ra các quy định và cách giám sát (control) để đảm bảo Change – Được phê duyệt bởi các cấp có thẩm quyền – Được xem xét kỹ trước khi thực hiện Strictly Confidential – Do Not Distribute 69
  70. 70. QUY TRÌNH Strictly Confidential – Do Not Distribute 70
  71. 71. CÂU HỎI • Giá trị của Change Management với Business? • Giá trị của Change Management đối với Operation? Strictly Confidential – Do Not Distribute 71
  72. 72. 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 72
  73. 73. CHANGE MANAGEMENT & OPERATION • 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 Strictly Confidential – Do Not Distribute 73
  74. 74. 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 ra • Change level 1,2 cần được phê duyệt bởi CAB (Change Advisory Board) • Change level 3,4 được phê duyệt bởi Team Leader Strictly Confidential – Do Not Distribute 74
  75. 75. CHANGE MANAGEMENT & OPERATION • Thiết lập quy định cho việc phê duyệt change & theo nhu cầu business. – Emergency Change (CAB phê duyệt + thực hiện ngay) – Standard Change (12h-5 ngày) • VD: – Không thực hiện Change vào giờ cao điểm – Không thực hiện liên tiếp các Change Level 1,2 trong 1 tuần Strictly Confidential – Do Not Distribute 75
  76. 76. CHANGE MANAGEMENT & COMMUNICATION • Technical Operation Team mở Change Request • Service Desk thông báo Change với các bên liên quan • TOM sẽ tổ chức CAB review cho các change level 1,2 • Team Leader -> Close Change • Change quá thời gian quy định -> Service Desk mở Incident và link đến Change Strictly Confidential – Do Not Distribute 76
  77. 77. 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 Strictly Confidential – Do Not Distribute 77
  78. 78. 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 Strictly Confidential – Do Not Distribute 78
  79. 79. 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 Strictly Confidential – Do Not Distribute 79
  80. 80. 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 • CAB – Có đủ khả năng phản biện với Product Operation Team • TOM – Hỗ trợ các team hiểu quy định và thực hiện theo đúng quy trình Change – Giúp các team chuẩn bị đầy đủ tài liệu trước khi vào review với CAB Strictly Confidential – Do Not Distribute 80
  81. 81. 7. PROBLEM MANAGEMENT Strictly Confidential – Do Not Distribute 81
  82. 82. Problems are not stop signs, they are guidelines. Robert H. Schuller Strictly Confidential – Do Not Distribute Các vấn đề không phải là điểm kết thúc mà nó là những hướng dẫn (của bắt đầu). 82
  83. 83. 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 Strictly Confidential – Do Not Distribute 83
  84. 84. 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 để • Hạn chế việc lặp lại các Incident hoặc • Ngăn ngừa các Incident ảnh hưởng đến nhiều User lặp lại Incident Strictly Confidential – Do Not Distribute Problem Workaround Known Error 84
  85. 85. QUY TRÌNH Strictly Confidential – Do Not Distribute 85
  86. 86. XÁC ĐỊNH PROBLEM • Mỗi Technical Operation Team chỉ định 1 người giữ vai trò Prolem Manager • Định kỳ Problem Manager phân tích các Incident để xác định Problem, Root cause, Workaround và Known Error • Problem Manager đưa ra action plan để xử lý hoặc ngăn ngừa Known Error xảy ra Strictly Confidential – Do Not Distribute 86
  87. 87. 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á Strictly Confidential – Do Not Distribute 87
  88. 88. XÁC ĐỊNH PROBLEM 88
  89. 89. CÂU HỎI • Giá trị của Problem Management với Business? • Giá trị của Problem Management đối với Operation? Strictly Confidential – Do Not Distribute 89
  90. 90. 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 Strictly Confidential – Do Not Distribute 90
  91. 91. PROBLEM MANAGEMENT & OPERATION • Problem Management giúp giải quyết triệt để 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 • Problem Management khó phát huy hiệu quả Strictly Confidential – Do Not Distribute 91
  92. 92. 8. CAPACITY MANAGEMENT Strictly Confidential – Do Not Distribute 92
  93. 93. Mong chờ kết quả tốt nhất Chuẩn bị cho khả năng xấu nhất Strictly Confidential – Do Not Distribute 93
  94. 94. MỤC TIÊU • Thiết lập quy trình quản lý capacity để đảm bảo các sản phẩm có đủ capacity (server, network bandwidth, …) phục vụ business Strictly Confidential – Do Not Distribute 94
  95. 95. CAPACITY MANAGEMENT • Định kỳ hàng quý, các Technical Operation Team thực hiện review lại capacity của product và báo cáo Business Requirement Strictly Confidential – Do Not Distribute Capacity Profile Capacity Report Capacity Plan 95
  96. 96. CÂU HỎI • Giá trị của Capacity Management với Business? • Giá trị của Capacity Management đối với Operation? Strictly Confidential – Do Not Distribute 96
  97. 97. 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 Strictly Confidential – Do Not Distribute 97
  98. 98. CAPACITY MANAGEMENT & OPERATION • Capacity cho biết tình hình sử dụng tài nguyên cho sản phẩm • Operation bị ảnh hưởng bởi yêu cầu Business • Operation luôn chuẩn bị tài nguyên tốt nhất cho Business -> Engineer ko có động lực nhiều trong việc thực hiện Capacity Management Strictly Confidential – Do Not Distribute 98
  99. 99. 9. RISK MANAGEMENT Strictly Confidential – Do Not Distribute 99
  100. 100. The more we think about risk, the more risk seem to be. Ben Carson Strictly Confidential – Do Not Distribute Càng nghĩ nhiều về rủi ro thì càng có nhiều rủi ro (có thể xảy ra) 100
  101. 101. YÊU CẦU • Triển khai phương pháp đánh giá và quả lý rủi ro (Risk) cho việc vận hành kỹ thuật. • Quản lý rủi ro tốt sẽ giúp việc vận hành chủ động (proactive) hơn. • Phương pháp đánh giá – Không quá phức tạp – Phù hợp với hoạt động vận hành Strictly Confidential – Do Not Distribute 101
  102. 102. TRIỂN KHAI • Nghiên cứu các Risk Managemet Framework và lựa chọn – COBIT Strictly Confidential – Do Not Distribute 102
  103. 103. TRIỂN KHAI • Nghiên cứu các phương pháp đánh giá - FMEA (Failure Mode and Effects Analysis) - FAIR (Factor Analysis of Information Risk) 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) Strictly Confidential – Do Not Distribute 103
  104. 104. 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 Strictly Confidential – Do Not Distribute 104
  105. 105. RISK & CONTROL Assets Risks Controls • 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 Strictly Confidential – Do Not Distribute 105
  106. 106. COBIT Risk IT Practitioner Guide Strictly Confidential – Do Not Distribute 106
  107. 107. COBIT Risk IT Practitioner Guide Strictly Confidential – Do Not Distribute 107
  108. 108. ĐÁNH GIÁ RISK • Xác định ảnh hưởng của Risk tới Business – Downtime – %Business Interruption – CCU Lost –… • Xây dựng bảng đánh giá khả năng/tần xuất xảy ra của Risk – Tùy thuộc từng loại business • Xây dựng metrics của Risk Rating • Xây dựng metrics Risk Response Strictly Confidential – Do Not Distribute 108
  109. 109. RISK ASSESSMENT TEMPLATE Strictly Confidential – Do Not Distribute 109
  110. 110. RISK ASSESSMENT TEMPLATE Strictly Confidential – Do Not Distribute 110
  111. 111. RISK CONTROL TEMPLATE Strictly Confidential – Do Not Distribute 111
  112. 112. RISK CONTROL TEMPLATE Strictly Confidential – Do Not Distribute 112
  113. 113. CÂU HỎI • Giá trị của Risk Management với Business? • Giá trị của Risk Management đối với Operation? Strictly Confidential – Do Not Distribute 113
  114. 114. RISK MANAGEMENT & BUSINESS • Xác định các rủi ro để có kế hoạch giảm thiểu ảnh hưởng tới Business • Đánh giá các rủi ro và mức độ ảnh hưởng để xác định hiệu quả các chi phí đầu tư ngăn ngừa rủi ro. • Có phân tích cụ thể để xác định đầu tư giảm thiểu rủi ro cho Business Strictly Confidential – Do Not Distribute 114
  115. 115. 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 Strictly Confidential – Do Not Distribute 115
  116. 116. RISK MANAGEMENT & PROCESS KHÁC Incident Management Risk Assessment (Hàng Quý) Risk & Control Data Thực hiện Control Change Management Strictly Confidential – Do Not Distribute 116
  117. 117. RISK MANAGEMENT & KPI • Tỉ lệ % số Risk được control • Số incident xảy ra do control không hiệu quả Strictly Confidential – Do Not Distribute 117
  118. 118. 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 Mng., Incident Mng.) Strictly Confidential – Do Not Distribute 118
  119. 119. 10. BÀI HỌC KINH NGHIỆM Strictly Confidential – Do Not Distribute 119
  120. 120. 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 Strictly Confidential – Do Not Distribute 120
  121. 121. CÁC BƯỚC TRIỂN KHAI • • • • • Lựa chọn hệ thống ITSM Service Desk Incident Management Change Management Risk Management – Capacity Management – Problem Management –… Strictly Confidential – Do Not Distribute 121
  122. 122. 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 – PQA – Làm báo cáo định kỳ về tình hình tuân thủ process trong vận hành Strictly Confidential – Do Not Distribute 122
  123. 123. KPI • Toàn bộ các team vận hành cần chia sẻ KPI liên quan đến – Incident – Downtime – Kết quả Audit việc tuân thủ Process của PQA –… -> Tạo ra thống nhất trong việc áp dụng process • Dữ liệu phải được thu thập chính xác, khách quan để đánh giá KPI Strictly Confidential – Do Not Distribute 123
  124. 124. 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 Strictly Confidential – Do Not Distribute 124
  125. 125. 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 Strictly Confidential – Do Not Distribute 125
  126. 126. 11. Q&A Strictly Confidential – Do Not Distribute 126
  127. 127. Q&A Strictly Confidential – Do Not Distribute 127
  128. 128. 12. ITIL V3 Strictly Confidential – Do Not Distribute 128
  129. 129. ITIL V3 • Chuyển mô hình Platform Infrastructure theo mô hình hướng Service – Quản lý SLA – Quản lý Service Cost Sẽ tiếp tục chia sẻ Strictly Confidential – Do Not Distribute 129
  130. 130. 13. HUẤN LUYỆN Strictly Confidential – Do Not Distribute 130
  131. 131. NỘI DUNG • • • • • • • • Cách thức xây dựng các quy trình Lựa chọn ITSM Tool Sử dụng các Template Thiết lập các tham số (parameters) Thiết lập KPI 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ự Strictly Confidential – Do Not Distribute 131
  132. 132. XIN CÁM ƠN! CHÚC MỪNG NĂM MỚI 2014 Strictly Confidential – Do Not Distribute 132
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×