Reliability Engineering: Membangun Sistem Cloud yang Tetap Stabil Kendati Terjadi Gangguan

Banyak organisasi masih mengukur reliability hanya dari uptime. Jika dashboard menunjukkan sistem masih berjalan, maka layanan dianggap baik-baik saja. Padahal, cara mengukur reliability dari perspektif pengguna dapat menghasilkan gambaran yang sangat berbeda.

Mengingat saat ini arsitektur aplikasi makin terdistribusi, menjaga sistem tetap reliable menjadi tantangan yang makin kompleks. Satu layanan dapat bergantung pada database, API, load balancer, jaringan, identity service, hingga layanan pihak ketiga. Akibatnya, ketika salah satu komponen mengalami gangguan maka dapat berdampak pada layanan lainnya.

Inilah alasan reliability engineering tidak hanya berbicara tentang menjaga server tetap hidup. Fokusnya adalah memastikan layanan tetap memenuhi ekspektasi pengguna dan mencegah failure, bahkan ketika latency meningkat, dependency gagal, atau sebagian komponen mengalami gangguan. Karena sistem cloud dan distributed systems tidak mungkin sepenuhnya bebas dari failure.

Apa itu Reliability Engineering?

Reliability engineering adalah pendekatan engineering untuk memastikan sistem dapat memenuhi tingkat reliability yang dibutuhkan oleh pengguna dan bisnis. Dalam konteks cloud dan distributed system, reliability dan mencakup aspek availability, latency, error rate, throughout, durability, hingga kemampuan sistem untuk pulih dari gangguan.

Reliability engineering membantu tim mengubah konsep yang mengharuskan sistem untuk selalu stabil, menjadi target yang lebih terukur. Dengan begitu, ketimbang memastikan aplikasi harus tersedia, Tim dapat menentukan target yang lebih spesifik. Misalnya, 99,9 persen request pengguna harus berhasil dalam periode tertentu atau 95 persen request harus mendapatkan response dalam waktu kurang dari 300 milidetik.

Dengan memiliki target yang jelas, reliability tidak hanya menjadi persepsi. Tim dapat mengukur, mengevaluasi, dan mengambil tindakan nyata berdasarkan data.

Bagaimana Hubungannya dengan Resilience?

Reliability dan resilience saling berkaitan, tetapi memiliki fokus yang berbeda. Jika reliability berfokus pada kemampuan sistem untuk secara konsisten memberikan layanan sesuai target yang telah ditentukan. Maka resilience berfokus pada kemampuan sistem untuk menghadapi, menoleransi, dan pulih dari gangguan.

Sebuah sistem mungkin memiliki availability tinggi dalam kondisi normal, tetapi belum tentu resilient ketika salah satu dependency gagal. Sebaliknya, sistem yang resilient dirancang agar gangguan pada satu komponen tidak langsung menyebabkan seluruh layanan berhenti. Karena itu, reliability engineering dan resilience perlu berjalan bersama.

Reliability membantu menjawab pertanyaan tentang kemampuan layanan dalam memenuhi target yang dijanjikan kepada pengguna. Sedangkan resilience membantu menjawab pertanyaan tentang kemungkinan yang terjadi jika sistem mengalami kegagalan.

Sistem yang Reliable Bukan Berarti Tidak Pernah Gagal

Salah satu kesalahpahaman terbesar dalam reliability adalah menganggap sistem yang reliable tidak boleh mengalami kegagalan. Padahal faktanya, kegagalan pada sistem cloud tidak selalu dapat dihilangkan.

Server dapat mengalami masalah. Jaringan dapat mengalami latency. Database dapat mencapai batas kapasitas. API dependency dapat gagal. Bahkan kesalahan konfigurasi atau deployment dapat memicu incident.

Karena itu, reliability engineering tidak berusaha menciptakan sistem yang mustahil gagal. Fokusnya adalah membangun sistem yang memiliki kemampuan:

Mengurangi kemungkinan failure

Membatasi dampak failure

Mendeteksi gangguan lebih cepat

Memulihkan layanan dengan lebih efektif

Mencegah kegagalan kecil berkembang menjadi outage yang lebih besar

Baca Juga: Bisnis Ikut Lumpuh Akibat Gangguan API? Kenali Risikonya Sekarang

Mengenal SLI, SLO, dan Error Budget

SLI, SLO, dan error budget merupakan tiga konsep utama yang membantu organisasi mengelola reliability secara lebih objektif.

Secara sederhana, ketiganya dapat dianalogikan sebagai berikut:

SLI mengukur kondisi aktual service.

SLO menentukan target reliability.

Error budget menentukan batas kegagalan yang masih dapat ditoleransi.

Ketiganya membantu tim menjawab tiga pertanyaan penting terkait sejauh mana layanan dapat berjalan, seberapa reliable suatu layanan, dan berapa banyak kegagalan yang masih dapat diterima oleh suatu sistem.

SLI

Service Level Indicator atau SLI adalah indikator yang digunakan untuk mengukur performa atau kondisi aktual sebuah layanan. SLI dapat berupa persentase request yang berhasil, response time, error rate, availability, latency, dan throughput.

Hal terpenting adalah memilih SLI yang mencerminkan pengalaman pengguna. Karena tidak semua metrik teknis harus menjadi SLI.

CPU utilization, misalnya, dapat berguna untuk monitoring infrastruktur. Namun, tingginya CPU tidak selalu berarti pengguna mengalami gangguan. Sebaliknya, peningkatan error rate atau latency dapat secara langsung memengaruhi pengalaman pengguna.

Contohnya:

99,95 persen requests berhasil dalam periode 30 hari.

Atau:

95 persen requests mendapatkan respons dalam waktu kurang dari 500 milidetik.

SLO

Service Level Objective atau SLO adalah target reliability yang ingin dicapai berdasarkan SLI. Jika SLI mengukur kondisi aktual, SLO menentukan target yang ingin dipenuhi.

Contohnya:

99,9% request harus berhasil setiap bulan.

SLO membantu organisasi menghindari target yang terlalu abstrak seperti:

“Sistem harus selalu cepat.” atau:

“Aplikasi tidak boleh down.”

Dengan SLO, ekspektasi reliability menjadi lebih spesifik dan dapat diukur. Namun, target 100 persen tidak selalu menjadi pilihan terbaik.

Target reliability yang terlalu tinggi membutuhkan investasi yang sangat besar dan memperlambat kemampuan tim untuk melakukan perubahan. Karena itu, target reliability perlu disesuaikan dengan kebutuhan bisnis dan dampaknya terhadap pengguna.

Error Budget

Error budget adalah batas kegagalan yang masih dapat ditoleransi berdasarkan target SLO.

Secara sederhana:

Error Budget = 100 persen – SLO

Maka jika sebuah service memiliki SLO 99,9 persen, maka tersedia error budget sebesar 0,1 persen.

Error budget bukan berarti perusahaan membiarkan sistem gagal. Sebaliknya, error budget membantu organisasi menentukan batas risiko yang dapat ditolerir.

Selama layanan masih berada dalam batas error budget, tim dapat terus melakukan deployment, eksperimen, atau perubahan sistem. Namun, ketika error budget telah habis, reliability perlu menjadi prioritas.

Baca Juga: Mengapa API Integration Menjadi Tulang Punggung Transformasi Digital Perusahaan Modern

Bagaimana SLO Membantu Menentukan Prioritas Reliability?

Tanpa target yang jelas, setiap gangguan dapat memicu perdebatan, di antaranya:

Apakah masalah ini cukup serius?

Apakah deployment perlu dihentikan?

Apakah tim harus memperbaiki reliability atau melanjutkan pengembangan fitur?

SLO membantu mengurangi subjektivitas tersebut. Jika performa layanan masih berada dalam target, tim mungkin masih memiliki ruang untuk melakukan perubahan.

Namun, jika layanan secara konsisten gagal memenuhi SLO, reliability perlu menjadi prioritas. Dengan demikian, SLO membantu organisasi menentukan kapan harus fokus pada stabilitas, memperbaiki technical debt, mengurangi risiko deployment, meningkatkan observability, hingga meredesain dependency.

Selain itu, SLO juga membantu tim agar masih memiliki ruang untuk merilis fitur baru, melakukan eksperimen, meningkatkan kecepatan deployment, hingga mengembangkan inovasi.

Dengan kata lain, reliability bukan hanya menjadi tanggung jawab satu tim, tetapi menjadi bagian dari proses pengambilan keputusan bersama.

Bagaimana Error Budget Menyeimbangkan Reliability dan Kecepatan Inovasi?

Salah satu tantangan dalam engineering adalah adanya ketegangan antara dua kebutuhan. Di satu sisi, bisnis ingin bergerak lebih cepat dan merilis fitur baru. Di sisi lain, tim engineering perlu menjaga stabilitas sistem.

Jika setiap perubahan dianggap berisiko, inovasi dapat berjalan terlalu lambat. Namun, jika perubahan dilakukan tanpa kontrol, sistem dapat menjadi semakin tidak stabil. Error budget membantu menciptakan keseimbangan di antara dua tantangan tersebut.

Selama error budget masih tersedia, tim memiliki ruang untuk melakukan perubahan. Ketika error budget habis, organisasi dapat menerapkan kebijakan tertentu, misalnya:

Menunda feature release

Membatasi deployment non-kritis

Memprioritaskan reliability improvement

Melakukan root cause analysis

Memperbaiki monitoring dan testing

Pendekatan ini membuat reliability menjadi tanggung jawab bersama antara development, operations, dan product team. Keputusan tidak lagi hanya berdasarkan opini. Data reliability menjadi dasar untuk menentukan tingkat risiko yang dapat diterima.

Prinsip Membangun Sistem yang Lebih Resilient

Membangun sistem yang resilient membutuhkan lebih dari sekadar menambahkan backup. Arsitektur perlu dirancang dengan asumsi bahwa kegagalan dapat terjadi.

Beberapa prinsip penting meliputi:

Redundancy untuk Mengurangi Ketergantungan Pada Satu Komponen

Single point of failure dapat menyebabkan satu komponen menjadi titik kritis bagi seluruh sistem. Redundancy membantu menyediakan alternatif ketika salah satu komponen gagal.

Contohnya:

Multiple availability zones

Redundant instances

Replicated database

Multiple network paths

Namun, redundancy saja tidak cukup. Komponen cadangan juga perlu diuji untuk memastikan sistem benar-benar dapat melakukan failover ketika diperlukan.

Failure Isolation untuk Membatasi Dampak Gangguan

Gangguan pada satu layanan seharusnya tidak selalu menyebabkan seluruh sistem berhenti. Dengan melakukan isolasi terhadap failure domain, organisasi dapat membatasi dampak kegagalan.

Pendekatan ini dapat dilakukan melalui berbagai cara, mulai dari service isolation, queue, circuit breaker, bulkhead pattern, hingga dependency isolation. Tujuannya adalah mencegah cascading failure.

Graceful Degradation untuk Menjaga Layanan Tetap Berjalan

Ketika salah satu fitur gagal, seluruh aplikasi tidak selalu harus berhenti. Sistem dapat dirancang untuk tetap memberikan fungsi utama meskipun beberapa kapabilitas tidak tersedia.

Misalnya, aplikasi e-commerce mungkin tetap memungkinkan pengguna melihat katalog meskipun sistem rekomendasi sedang mengalami gangguan. Pendekatan ini membantu mengurangi dampak gangguan terhadap pengalaman pengguna.

Observability untuk Memahami Apa yang Terjadi

Tim tidak dapat memperbaiki masalah yang tidak dapat dilihat oleh mata. Untuk itu, observability membantu organisasi memahami kondisi sistem melalui data seperti metrics, logs, traces, dan events. Dengan visibilitas yang lebih baik, tim dapat mempercepat proses detection, diagnosis, dan recovery.

Peran Timeout, Retry, Exponential Backoff, dan Jitter

Dalam distributed systems, banyak kegagalan bersifat sementara atau transient failure. Misalnya, request gagal karena gangguan jaringan sesaat atau dependency sedang mengalami lonjakan beban.

Dalam kondisi seperti ini, retry dapat membantu request berhasil. Namun, retry yang dirancang secara tidak tepat justru dapat memperburuk gangguan.

Timeout

Timeout menentukan berapa lama sebuah service akan menunggu respons. Tanpa timeout yang tepat, request dapat terus menunggu dan menggunakan resource.

Ketika banyak request menunggu secara bersamaan, resource seperti memory, thread, atau connection dapat habis. Karena itu, timeout perlu disesuaikan dengan karakteristik layanan. Karena jika timeout terlalu lama membuat resource tertahan, sementara jika terlalu pendek dapat memicu terlalu banyak retry.

Retry

Retry memungkinkan aplikasi mencoba kembali request yang gagal. Mekanisme ini efektif untuk beberapa jenis transient failure. Namun, retry perlu dibatasi.

Jika sebuah dependency sedang overload, ribuan request yang melakukan retry secara bersamaan sehingga dapat menamnbah beban dan memperlambat proses recovery.

Exponential Backoff

Exponential backoff menambahkan waktu tunggu yang semakin panjang di antara setiap retry. Alih-alih mencoba kembali secara terus-menerus, aplikasi memberikan waktu bagi sistem untuk pulih. Pendekatan ini membantu mengurangi tekanan terhadap dependency yang sedang mengalami masalah.

Jitter

Masalah dapat muncul ketika banyak client melakukan retry pada waktu bersamaan. Jika semua request gagal dan mencoba kembali secara bersamaan, lonjakan traffic baru dapat kembali membebani sistem.

Jitter menambahkan variasi atau random delay pada waktu retry. Dengan demikian, retry tersebar dalam periode waktu yang berbeda dan risiko lonjakan serentak dapat dikurangi.

Intinya, timeout, retry, backoff, dan jitter harus dirancang sebagai satu strategi. Retry bukan selalu solusi. Dalam kondisi yang salah, retry justru dapat memperbesar failure.

Mengapa Testing terhadap Failure Scenario Penting?

Reliability tidak hanya dibangun ketika incident terjadi. Jika organisasi baru mengetahui kelemahan sistem setelah outage, maka pengguna telah menjadi bagian dari proses pengujian.

Karena itu, tim perlu menguji bagaimana sistem merespons berbagai failure scenario. Beberapa contoh skenario yang dapat diuji, antara lain:

Apa yang terjadi jika database tidak tersedia?

Bagaimana aplikasi merespons peningkatan latency?

Apa yang terjadi ketika API dependency gagal?

Apakah sistem dapat melakukan failover?

Apakah retry memperbesar beban?

Apakah alert memberikan informasi yang benar?

Seberapa cepat layanan dapat dipulihkan?

Testing terhadap failure scenario membantu tim menemukan kelemahan sebelum berdampak besar terhadap pengguna. Pendekatan ini dapat mencakup failure testing, load testing, chaos engineering, disaster recovery testing, dan game day exercise.

Tujuannya tak lain untuk membangun keyakinan bahwa ketika failure benar-benar terjadi, sistem dan tim sudah memiliki kesiapan untuk menghadapinya.

Baca Juga: Membangun Platform Thinking dalam Cloud Environment: Dari Cloud Infrastructure ke Platform Engineering

Pelajari Lebih Dalam Mengenai Reliability Engineering Bersama iCCom

Reliability engineering merupakan perjalanan yang terus berkembang di tengan sistem cloud yang semakin kompleks. Untuk itu, penting bagi engineer memahami bagaimana reliability, resilience, observability, dan operasional excellence saling berkaitan satu sama lain.

Saatnya memperluas pemahaman Anda tentang reliability engineering dan membangun sistem cloud yang dapat bertahan, bahkan ketika terjadi gangguan. Mulai perjalanan pemahaman Anda mengenai cloud dengan bergabung bersama komunitas iCCom (Indonesia Cloud Community), ruang untuk para cloud enthusiast belajar, berdiskusi, dan berbagi best practices seputar teknologi cloud, reliability engineering, resilience, serta perkembangan teknologi cloud lainnya.

Keanggotaan iCCOm GRATIS dan terbuka bagi siapa pun, baik pemula maupun profesional yang ingin memperluas wawasan seputar data, cloud, dan AI.

Bergabung bersama iCCOm untuk mengikuti berbagai kegiatan komunitas, mendapatkan teknologi terbaru, dan saling terhubung dengan sesama cloud enthusiast serta praktisi teknologi lainnya di Indonesia.