Availability management · ITIL 5 Learn

Purpose in one sentenceTujuan dalam satu kalimatMake sure services deliver agreed levels of availability to meet the needs of customers and users.Memastikan layanan memberikan tingkat ketersediaan yang disepakati untuk memenuhi kebutuhan pelanggan dan pengguna.

Availability means the service is there when people need it. That sounds simple, but it is not the same as "the server is up". A login page that loads but won’t let anyone in is not available. Availability management designs, measures and improves availability from the user’s point of view, at a cost that matches the service’s value.

Ketersediaan berarti layanan ada saat orang membutuhkannya. Kedengarannya sederhana, tetapi tidak sama dengan "servernya hidup". Halaman login yang terbuka tetapi tidak bisa dipakai masuk bukanlah layanan yang tersedia. Availability management merancang, mengukur, dan meningkatkan ketersediaan dari sudut pandang pengguna, dengan biaya yang sepadan dengan value layanan tersebut.

Key ideasKonsep kunci

Availability, reliability, recovery. How often it fails (MTBF) and how fast it comes back (MTTR) together decide availability.
Measure from the user’s side. Count the agreed hours that matter, and count partial outages too.
Find the single points of failure. Add redundancy where the business impact justifies the cost.
Every extra "nine" costs more. In a 30-day month, 99% allows about 7 hours of downtime, 99.9% about 43 minutes, 99.99% about 4 minutes.
Design for failure. Assume components will fail, and make the service degrade gracefully instead of stopping.

Ketersediaan, keandalan, pemulihan. Seberapa sering gagal (MTBF) dan seberapa cepat pulih (MTTR) bersama-sama menentukan ketersediaan.
Ukur dari sisi pengguna. Hitung jam yang disepakati dan yang penting, termasuk gangguan sebagian.
Temukan single point of failure. Tambahkan redundansi di tempat yang dampak bisnisnya sepadan dengan biayanya.
Setiap tambahan "sembilan" makin mahal. Dalam sebulan 30 hari, 99% memberi ruang sekitar 7 jam gangguan, 99,9% sekitar 43 menit, 99,99% sekitar 4 menit.
Rancang dengan asumsi akan gagal. Anggap komponen pasti suatu saat gagal, dan buat layanan menurun secara bertahap alih-alih berhenti total.

Key activitiesAktivitas kunci

A typical flow. Real work loops back and skips steps when it makes sense.

Alur yang umum. Dalam praktik, pekerjaan bisa kembali ke langkah sebelumnya atau melewati langkah tertentu bila masuk akal.

Agree needsWhich hours matter, and how much downtime is acceptable?
DesignRemove single points of failure that matter.
MeasureTrack availability as users experience it.
Analyze outagesWhy did it fail, and why did recovery take so long?
ImproveInvest where the impact is biggest.
TestPractice failover before you need it.

Menyepakati kebutuhanJam berapa yang penting, dan berapa lama gangguan yang dapat diterima?
MerancangHilangkan single point of failure yang penting.
MengukurPantau ketersediaan sebagaimana dialami pengguna.
Menganalisis gangguanMengapa gagal, dan mengapa pemulihannya lama?
MemperbaikiBerinvestasi di tempat yang dampaknya terbesar.
MengujiLatih failover sebelum benar-benar dibutuhkan.

How to measure itCara mengukurnya

MetricMetrik	What it tells youApa yang ditunjukkan	Watch out forPerhatikan
Availability % (user view)% ketersediaan (sudut pandang pengguna)	Whether the service is there when neededApakah layanan ada saat dibutuhkan	Measuring server uptime insteadMengukur uptime server sebagai gantinya
MTBFMTBF	How reliable the service isSeberapa andal layanan	Few failures hiding one very long outageSedikit kegagalan yang menyembunyikan satu gangguan yang sangat lama
MTTRMTTR	How fast you recoverSeberapa cepat Anda pulih	Averages hiding the worst casesRata-rata yang menyembunyikan kasus terburuk
Outages per critical serviceJumlah gangguan per layanan kritis	Where to focusDi mana perlu fokus	Short outages not recorded at allGangguan singkat yang tidak dicatat sama sekali
Critical services without single points of failureLayanan kritis tanpa single point of failure	Resilience of the designKetahanan rancangan	Redundancy that has never been testedRedundansi yang belum pernah diuji

What each level looks likeGambaran setiap level

Use these descriptions as a quick self-check before running the full assessment. Level 3 is a strong, realistic target for most teams.

Gunakan deskripsi ini sebagai pengecekan cepat sebelum menjalankan asesmen lengkap. Level 3 adalah target yang kuat dan realistis bagi sebagian besar tim.

L1InitialNobody really knows how available services are. Outages are remembered, not measured.
L2RepeatableServer uptime is measured, but not availability as users experience it.
L3DefinedKey services have availability targets, measured from the user’s side, and single points of failure are known.
L4MeasuredOutages are analyzed, and trends drive investment decisions.
L5OptimizedServices are designed for failure, failover is tested regularly, and availability is balanced with cost.

L1InitialTidak ada yang benar-benar tahu seberapa tersedia layanan. Gangguan hanya diingat, tidak diukur.
L2RepeatableUptime server diukur, tetapi tidak dengan ketersediaan sebagaimana dialami pengguna.
L3DefinedLayanan utama memiliki target ketersediaan yang diukur dari sisi pengguna, dan single point of failure sudah diketahui.
L4MeasuredGangguan dianalisis, dan tren menjadi dasar keputusan investasi.
L5OptimizedLayanan dirancang dengan asumsi akan gagal, failover diuji secara rutin, dan ketersediaan diseimbangkan dengan biaya.

Assess availability management in the wizardNilai availability management di wizard →

Using AIMemanfaatkan AI

Failure prediction from early warning signs in logs and metrics.
Outage pattern analysis across months of incident data.
Impact simulation: what happens to services if this component fails?
Outage report drafts combining timelines, metrics and chat.

Prediksi kegagalan dari tanda-tanda awal di log dan metrik.
Analisis pola gangguan dari data incident berbulan-bulan.
Simulasi dampak: apa yang terjadi pada layanan jika komponen ini gagal?
Draf laporan gangguan yang menggabungkan kronologi, metrik, dan chat.

Keep a human in the loopTetap libatkan manusiaPredictions are probabilities, not facts. Check them before spending on replacements, and keep people deciding on risk trade-offs.Prediksi adalah kemungkinan, bukan fakta. Periksa sebelum mengeluarkan biaya penggantian, dan pastikan manusia yang memutuskan pertimbangan risiko.

Key ideaInti materiAvailability is what users experience at the times they need the service, bought at a cost that matches its value.Ketersediaan adalah apa yang dialami pengguna pada saat mereka membutuhkan layanan, diperoleh dengan biaya yang sepadan dengan value-nya.

Real-world example: a hospital laboratory systemContoh kasus: sistem laboratorium rumah sakit3 min3 menit

A hospital’s laboratory system reports 99.8% availability, which looks fine. But it runs on a single database server. When that server fails on a Saturday, lab results are unavailable for six hours and doctors have to phone the lab for every result.

Sistem laboratorium sebuah rumah sakit melaporkan ketersediaan 99,8%, yang terlihat baik. Namun sistem ini berjalan di satu server database. Saat server itu rusak pada hari Sabtu, hasil lab tidak tersedia selama enam jam dan dokter harus menelepon lab untuk setiap hasil.

The team adds a standby database with automatic failover and tests it every quarter. The next hardware failure causes a two-minute interruption instead of six hours.

Tim menambahkan database cadangan dengan failover otomatis dan mengujinya setiap kuartal. Kerusakan hardware berikutnya hanya menimbulkan gangguan dua menit, bukan enam jam.

Common pitfallsJebakan umum

Chasing 99.999% for every service, whatever its value.
Measuring servers instead of the service users see.
Forgetting that planned maintenance is downtime for users too.
Building redundancy and never testing the failover.

Mengejar 99,999% untuk semua layanan, apa pun value-nya.
Mengukur server, bukan layanan yang dilihat pengguna.
Lupa bahwa pemeliharaan terencana juga berarti gangguan bagi pengguna.
Membangun redundansi tetapi tidak pernah menguji failover-nya.

Related practicesPractice terkait

PracticePractice	How they connectBagaimana keterkaitannya
Service level management	Agrees the availability targets with customers.Menyepakati target ketersediaan dengan pelanggan.
Monitoring and event management	Provides the data to measure availability.Menyediakan data untuk mengukur ketersediaan.
Incident management	Fast restoration keeps downtime short.Pemulihan yang cepat menjaga gangguan tetap singkat.
Infrastructure and platform management	Builds and runs the redundant components.Membangun dan menjalankan komponen redundan.

Beginner tipsTips untuk pemula

Draw one critical service on a whiteboard and circle every single point of failure.
Turn your availability target into minutes per month. It makes the target real.
Test one failover this quarter, in a planned window.

Gambar satu layanan kritis di papan tulis dan lingkari setiap single point of failure.
Ubah target ketersediaan Anda menjadi menit per bulan. Ini membuat target terasa nyata.
Uji satu failover kuartal ini, di jadwal yang sudah direncanakan.

The practice name and purpose follow ITIL. KPIs, level descriptions, AI uses and pitfalls are practical guidance written in our own words, not official ITIL text.Nama dan tujuan practice mengikuti ITIL. KPI, deskripsi level, pemanfaatan AI, dan jebakan umum adalah panduan praktis yang ditulis dengan kata-kata sendiri, bukan teks resmi ITIL.