21

Service Level Management

Embed Size (px)

Citation preview

Page 1: Service Level Management
Page 2: Service Level Management

SLM Series | Page—1

Page 3: Service Level Management

SLM Series | Page—2

“Any change of state that has significance for the management of IT

service” (ITIL – Information Technology Infrastructure Library)

“setiap perubahan status yang berdampak/tidak berdampak

terhadap layanan IT”

Event ada tiga:

• Informational event yang tidak mengganggu layanan

• Warning mungkin bisa menjadi trigger yang dapat mengganggu

layanan

• Exceptional hampir dapat dipastikan merupakan sebuah trigger

yang mengganggu layanan

Page 4: Service Level Management

SLM Series | Page—3

“any event which is not part of the standard operation of a service

and which causes or may cause an interruption to, or a reduction

in, the quality of that service” (ITSM, 2007)

“setiap kejadian yang bukan bagian dari layanan operasional

standar yang menyebabkan atau berpotensi menyebabkan

interupsi/gangguan atau penurunan kualitas layanan”

“an unplanned disruption or degradation of service” (ITIL – Information Technology Infrastructure Library)

“gangguan yang tidak direncanakan atau penurunan (kualitas)

layanan”

Page 5: Service Level Management

SLM Series | Page—4

“the cause of one or more incidents” (ITIL – Information Technology Infrastructure Library)

“penyebab dari satu atau lebih insiden – suatu insidendapat pula disebabkan oleh masalah yang takterselesaikan”

The cause is not usually known at the time a Problem Record is created, and the Problem Management Process is responsible for further investigation.

Page 6: Service Level Management

SLM Series | Page—5

Akar penyebab suatu masalah (root cause of the problem) dapat diketahui atautidak.

Tindakan yang harus diambil terhadap suatu masalah:

Do nothing (tidak melakukan apa-apa)Tindakan ini dipilih jika masalah tidak berpengaruh terhadap bisnis ataubiaya untuk memperbaiki masalah melebihi manfaat yang didapat

Deploy work around (membuat solusi sementara)Ini dipilih jika penentuan akar penyebab masalah melebihi manfaat yang didapat

Determine root cause and fix the problem (menentukan akarpenyebab dan memperbaiki masalah)Ini dipilih jika manfaat yang didapat melebihi biaya untuk memperbaikimasalah atau masalah tersebut layak diperbaiki (worth it)

Page 7: Service Level Management

SLM Series | Page—6

• Kata kunci untuk ‘event’ perubahan status (Up to

Down, Active to Inactive)

• Kata kunci untuk ‘incident’

mengganggu, interupsi, tidak direncanakan

• Kata kunci untuk ‘problem’ kerusakan, akar

penyebab

Lantas GANGGUAN termasuk kategori yang mana?

Dari definisi yang ada, GANGGUAN lebih tepat atau

lebih dekat dengan „incident‟

Page 8: Service Level Management

SLM Series | Page—7

ProblemIncidentEvent

• Event yang bersifat informational bukanlah ‘incident’

• Setiap ‘problem’ belum tentu menjadi ‘incident’

• Setiap ‘incident’ pasti merupakan ‘problem’

Dalam operasional sehari-hari, istilah “incident/insiden” dan

“problem/masalah” sering kali dipertukarkan (interchangeably)

Page 9: Service Level Management

SLM Series | Page—8

Occurence Event Incident Problem

Server crash di jam kerja dan

mengganggu proses bisnis

Server crash di luar jam kerja

Pemeliharaan terencana

(schedule maintenance)

Schedule outage melebihi

waktu yang direncanakan

Page 10: Service Level Management

SLM Series | Page—9

• Availability (ketersediaan) adalah kemampuan untuk

menjalankan fungsi pada saat dibutuhkan atau untuk

menjalankan fungsi selama suatu periode waktu

tertentu

• Faktor penentu Availability:

• Reliability (keandalan)

• Maintainability (kemudahan pemeliharaan)

• Serviceability (kemudahan perbaikan)

Page 11: Service Level Management

SLM Series | Page—10

Availability

Reliability Maintainability

Serviceability

Page 12: Service Level Management

SLM Series | Page—11

MTBSI (Mean Time Between Service Incidents)

MTBF (Mean Time Between Failures)

MTRS (Mean Time to Restore Service)

(Agreed Service Time (AST) – Downtime)

Agreed Service Time (AST)X 100 %Availability (%) =

Service time in hours

Number of breaksReliability (MTBSI in hours) =

Service time in hours – Total downtime in hours

Number of breaksReliability (MTBF in hours) =

Total downtime in hours

Number of breaks

Maintainability (MTRS in hours) =

Page 13: Service Level Management

SLM Series | Page—12

Sebuah penyedia layanan jaringan 24/7 telah beroperasi

selama 1 bulan (720 jam). Catatan pada Problem Record

menunjukkan bahwa jaringan telah mengalami gangguan

sebanyak dua kali (masing-masing selama 1 jam dan 2

jam), maka:

• Availability = ((720–(1+2)) / 720) x 100% = 99.58%

• Reliability (MTBSI) = 720 / 2 = 360 jam

• Reliability (MTBF) = (720–(1+2)) / 2 = 358,5 jam

• Maintainability (MTRS) = (1+2) / 2 = 1,5 jam

MTBSI (Mean Time Between Service Incidents)

MTBF (Mean Time Between Failures)

MTRS (Mean Time to Restore Service)

Page 14: Service Level Management

SLM Series | Page—13

• Detection time NMS Red Icon

Waktu dimana penyedia layanan mengetahui/mendeteksi

adanya insiden

• Diagnosis time 1st Level Troubleshooting

Waktu dimana penyedia layanan melakukan diagnosis

untuk menentukan penyebab terjadinya insiden

• Repair time Data Link Layer UP

Waktu yang diperlukan untuk memperbaiki insiden

• Recovery time Network Routing UP

Waktu yang diperlukan untuk pemulihan insiden

• Restoration Point Application UP

Titik dimana layanan bisnis normal kembali

Resolution time

Page 15: Service Level Management

SLM Series | Page—14

Tangible Cost Intangible Cost

Biaya perbaikan gangguan

(transport, man-days)Penurunan reputasi perusahaan

Denda atau penalty dari customer karena

terganggunya layananKehilangan kepercayaan customer

Penurunan pendapatan karena customer

berhenti berlangganan

Kehilangan kepercayaan strategic

partner (integrator, vendor)

Biaya perbaikan perangkat yang rusak Kehilangan peluang bisnis

Biaya lembur jika gangguan terjadi saat

after office hour

Penurunan kepercayaan diri dari front

liner (operator, field technician)

Tangible cost : biaya yang dapat diukur dengan jelas secara finansial

Intangible cost : biaya yang tidak dapat/sulit diukur secara finansial

Source: Bob Hardian, Availability Management (2011), telah diolah kembali

Page 16: Service Level Management

SLM Series | Page—15

• Semaikin tinggi Availability yang diinginkan, semakin besar biayapreventive maintenance danresilience yang dibutuhkan (kurvalogaritmik)

• Semakin tinggiAvailability, semakin kecil biayacorrective maintenance yang dibutuhkan (kurva linier)

• Total cost optimum dicapai untukUptime/Availability 70%-85%

• Kebutuhan akan tingkat Availabilitymelebihi nilai optimum akanmembuat total cost naik secaradrastis atau signifikan

• Untuk mencapai Availability 99% dibutuhkan biaya sekitar 10 kali dari biaya optimum

Source: Bob Hardian, Availability Management (2011)

Page 17: Service Level Management

SLM Series | Page—16

Source: Kailash Jayaswal, Administering Data Centers: Servers, Storage, and Voice over IP (2006)

Page 18: Service Level Management

SLM Series | Page—17

Source: Kailash Jayaswal, Administering Data Centers: Servers, Storage, and Voice over IP (2006)

Server software,

30%

Environment, 5%

Planned downtime,

30%

People, 15%

Hardware, 10%

Network software,

5%

Client software,

5%

Page 19: Service Level Management

SLM Series | Page—18

• Untuk memastikan kinerja perangkat berjalan normal maka harus dipastikan perangkat tersebut bekerja dibawah ambang batas (threshold). Jika kapasitasperangkat telah mencapai atau melebihi ambangbatas, maka solusi yang bisa dilakukan:

• Scaling UpMelakukan penggantian dengan perangkat yang memilikikapasitas lebih besar.

• Scaling OutMelakukan penambahan unit perangkat dengan kapasitas yang sama (load-balancing, active-active redundancy, parallel run).

• Solusi Scaling Up atau Scaling Out yang dipilih bisaberdasarkan CBA (Cost-Benefit Analysis)

Page 20: Service Level Management

SLM Series | Page—19

• Agar dapat kompetitif, pilihan infrastruktur untuk masa depanharuslah memiliki sifat adaptif (Adaptive Infrastructure)

• Ciri infrastruktur adaptif

• EfisienTersedianya komponen yang dapat dimanfaatkan secara bersamaoleh berbagai sistem baik oleh sistem lama maupun sistem baru

• EfektifTersedianya komponen yang mudah dipadukan (interoperable) dandiintegrasikan (integrated)

• Fleksibel (agile)Tersedianya komponen yang mudah dirombak, di-upgrade atau diganti

• Adaptiveness dari infrastruktur diukur dari:

• Time to Market: kecepatan implementasi layanan baru

• Scalability: mampu mengakomodasi peningkatan penggunaan

• Extensibility: kemudahan penambahan komponen baru

Page 21: Service Level Management

SLM Series | Page—20

Contact us at: [email protected]

Follow our : @SujanaSaputra