Selama 7+ tahun berkarir di pengembangan perangkat lunak, mempelajari berbagai hal dari pola; prinsip, dan peraktik terbaik baik dari teori maupun implementasi, salah satu pola favorit gue dalam mengembangkan perangkat lunak adalah resiliensi.
Di bahasa pemrograman Erlang, ada sebuah filosofi yang sederhananya bernama “Let it crash”. Merujuk ke slide yang dibawakan oleh Joe Amstrong (pembuat Erlang, RIP) yang berjudul “The do’s and don’ts of error handling”, bagian favorit gue adalah di slide pembuka yang menjelaskan *“A system is fault tolerant if it continues working even if something is wrong” *dan dilanjutkan dengan pembahasan tentang komputasi terdistribusi dan konkurensi.
Dalam praktik pengembangan peranti lunak, kebanyakan dari kita akan selalu fokus ke keberhasilan. Dari menyajikan fitur tanpa bug, membuat validasi, menangani sesuatu ketika terjadi kesalahan, dsb.
Yang padahal kita semua tahu bahwa kesalahan adalah sesuatu yang tidak bisa dihindari.
Dalam perspektif pengembangan, usaha yang kita lakukan adalah menangani setiap kemungkinan kesalahan, dan melacak kesalahan yang belum tertangani. Ketika gue mencoba melihat lebih luas lagi khususnya dari perspektif operasional, bagian yang tidak kalah penting selain menangani kesalahan adalah tentang kemampuan dalam mengatasi suatu kesalahan untuk kembali ke status sebelum krisis.
Atau yang sederhananya disebut dengan resiliensi.
Contoh sederhananya adalah seperti ini. Misal aplikasi lo harus mengirim 100 email pada jam 13.37 WIB, 17 email sukses dikirim namun terjadi kegagalan ketika ingin mengirim email yang ke-18. Aplikasi terjadi crash karena di satu waktu sedang melakukan pekerjaan yang memakan banyak memori dan CPU.
Resiliensi yang gue ketahui adalah tentang:
- Apa yang terjadi ketika aplikasi tersebut crash?
- Apa yang terjadi setelah aplikasi tersebut crash?
Jawaban sederhananya adalah dengan memulai kembali aplikasi tersebut, mengingat kita sudah mengetahui sumber masalahnya. Dan jawaban kedua—yang sekaligus menjadi pertanyaan—adalah apakah aplikasi akan melanjutkan pengiriman email yang ke-18 tadi *atau *justru melupakan bahwa dia harus mengirim 100 email?
Jawabannya selalu tergantung, tapi setidaknya sudah mendapatkan gambaran tentang konteks yang gue maksud.
Diluar dunia aplikasi, ini juga berlaku di kehidupan sehari-hari.
Kesalahan ataupun kegagalan adalah sesuatu yang inevitable. Tidak bisa dihindari. Yang menjadi poin utama gue rasa adalah bukan tentang melakukan kesalahan/kegagalan nya, melainkan tentang bagaimana menghadapi ketika situasi tersebut terjadi.
Contoh sederhana adalah ketika mempelajari hal baru. Misal, belajar mengendarai sepeda. Anggap kita belajar bersepeda lalu merasakan bagaimana sakitnya jatuh dari sepeda. Bisa saja kita akan kapok belajar bersepeda karena merasakan sakitnya jatuh dari sepeda, tergantung bagaimana kita menyikapinya. Kalau gue dulu karena gengsi: apapun yang terjadi gue harus bisa naik sepeda biar kayak teman-teman gue. And yes, it works. Dan pada akhirnya gue lupa gimana sakitnya jatuh dari sepeda (plus bekas luka gesekan di tangan gue waktu belajar sepeda pada akhirnya pun menghilang).
Kata orang bijak, kita harus banyak merasakan kegagalan. Of course maknanya lebih luas dari itu, namun di banyak contoh, konteksnya ada di tentang mencoba sesuatu, seperti, gak apa-apa gagal setidaknya lo sudah mencoba.
Kegagalan adalah sebuah paradoks. Di satu sisi adalah sebuah aib, namun di satu sisi adalah sebuah hal yang wajar. Sejak kecil kebanyakan dari kita ditanamkan untuk jangan melakukan kegagalan; dari harus terus naik kelas, harus menghindari mendapatkan ranking terakhir sampai harus meyakini bahwa hidup harus sesuai dengan yang kita inginkan.
Tentu saja itu tidak salah.
Tapi gue rasa masih relatif jarang yang menanamkan, seperti, untuk bisa mengatasi bagaimana bila kegagalan tersebut terjadi.
Toh siapa juga yang ingin melakukan kesalahan?
Di banyak kasus, yang menanamkan untuk bisa mengatasi bagaimana bila kegagalan tersebut terjadi gue rasa adalah waktu. Lo gagal dalam interview kerja, merasa down, dan klo lo gak tau apa yang bisa membuat lo bangkit kembali, besar kemungkinan tinggal menunggu waktunya saja.
Gue hampir tidak pernah kapok dalam melakukan sesuatu, kecuali gue tahu kapan harus berhenti. Dalam memulai kembali, lo tidak memulai sesuatu dari nol, melainkan memulai dengan pengalaman. Lo tahu rasanya ketika lamaran lo di reject oleh sebuah perusahaan, lo tahu rasanya ketika putus dalam menjalin hubungan, lo tahu rasanya ketika berada di sebuah kondisi lo butuh pertolongan, namun tidak ada tangan yang bisa lo genggam.
Rasanya masih sama, yang akan berbeda adalah sikap lo dalam mengatasinya.
Dalam KPI untuk resiliency, setidaknya ada 4 metriks yang bisa dijadikan acuan: MTBF (mean time between failure), MTTR (mean time to repair), MTTA (mean time to acknowledge), dan MTTF (mean time to failure).
Tapi di kehidupan sehari-hari, kita tidak perlu 4 metriks tersebut, karena, well, kita bukan sebuah sistem apalagi produk, technically.
Gue hanya ingin mengingatkan kembali jika pada dasarnya kesalahan adalah sesuatu yang inevitable. Tentu saja bila kesalahan yang sama terus dilakukan jatuhnya adalah menjadi sebuah keputusan, but anyway regardless the problem the main metric you should care about is that fucking MTTR.
Lo mungkin sedang menyesali sesuatu, atau sedang mengecewakan sesuatu, but the point is, mau sampai kapan?
Semakin kecil MTTR lo berbanding lurus dengan sikap yang harus lo lakukan ketika kesalahan tersebut terjadi.
Lo setidaknya jadi tahu jika X, maka Y, berarti harus Z.
Perihal X dan Y, itu urusan lain.
Resiliensi adalah tentang si Z ketika X dan Y ter-definisi. Perihal kejadian X terulang lagi, itu urusan lain.
Setidaknya lo gak perlu menghabiskan banyak energi untuk mencari ataupun menentukan si Z lagi, khususnya dalam pola yang sama.
And perhaps I should stop reading too much SRE books, I guess?