Pikirkan kembali metodologi Anda mengukur ketersediaan kemudian bekerja dengan pelanggan Anda untuk menetapkan target yang berarti .
Jika Anda menjalankan situs web besar, uptime tidak berguna sama sekali. Jika Anda mengajukan pertanyaan selama 10 menit ketika pelanggan Anda sangat membutuhkannya (lalu lintas puncak), itu bisa lebih merusak bisnis daripada pemadaman selama satu jam pada pukul 3 pagi pada hari Minggu.
Terkadang perusahaan web besar mengukur ketersediaan, atau keandalan, menggunakan metrik berikut:
- persentase kueri yang berhasil dijawab, tanpa kesalahan sisi server (HTTP 500s).
- persentase kueri yang dijawab di bawah target latensi tertentu .
- kueri yang hilang harus dihitung terhadap statistik Anda (lihat di bawah).
Ketersediaan tidak boleh diukur menggunakan probe sampel, yang dapat dilaporkan oleh entitas eksternal seperti pingdom dan pingability. Jangan hanya mengandalkan itu. Jika Anda ingin melakukannya dengan benar, setiap permintaan tunggal harus dihitung . Ukur ketersediaan Anda dengan melihat keberhasilan Anda yang sebenarnya dan dirasakan.
Cara paling efisien adalah mengumpulkan log atau statistik dari load-balancer Anda dan menghitung ketersediaan berdasarkan metrik di atas.
Persentase kueri yang dijatuhkan juga harus dihitung terhadap statistik Anda. Itu bisa dipertanggungjawabkan dalam ember yang sama dengan kesalahan sisi server. Jika ada masalah dengan jaringan atau dengan infrastruktur lain seperti DNS atau load balancers, Anda bisa menggunakan matematika sederhana untuk memperkirakan berapa banyak kueri yang hilang . Jika Anda mengharapkan pertanyaan X untuk hari itu dalam seminggu tetapi Anda mendapat X-1000, Anda mungkin menjatuhkan 1000 pertanyaan. Plot lalu lintas Anda ke grafik kueri per menit (atau detik). Jika kesenjangan muncul, Anda menjatuhkan kueri. Gunakan geometri dasar untuk mengukur area celah itu, yang memberi Anda jumlah total kueri yang dijatuhkan.
Diskusikan metodologi ini dengan pelanggan Anda dan jelaskan manfaatnya. Tetapkan garis dasar dengan mengukur ketersediaan mereka saat ini. Akan menjadi jelas bagi mereka bahwa 100% adalah target yang mustahil.
Kemudian Anda dapat menandatangani kontrak berdasarkan perbaikan pada baseline. Katakanlah, jika mereka saat ini mengalami 95% ketersediaan, Anda bisa berjanji untuk memperbaiki situasi sepuluh kali lipat dengan mencapai 98,5%.
Catatan: ada kelemahan cara mengukur ketersediaan ini. Pertama, mengumpulkan log, memproses dan membuat laporan sendiri mungkin tidak sepele, kecuali jika Anda menggunakan alat yang ada untuk melakukannya. Kedua, bug aplikasi dapat mengganggu ketersediaan Anda. Jika aplikasi berkualitas rendah, itu akan melayani lebih banyak kesalahan. Solusi untuk ini adalah dengan hanya mempertimbangkan 500-an yang dibuat oleh load-balancer daripada yang berasal dari aplikasi.
Hal-hal mungkin menjadi sedikit rumit dengan cara ini, tetapi ini satu langkah lebih dari sekadar mengukur waktu server Anda .