Harapan bukanlah strategi: 7 prinsip rekayasa keandalan situs (SRE)

Rekayasa keandalan situs, atau SRE, adalah pendekatan yang memperlakukan masalah operasi seolah-olah itu adalah masalah perangkat lunak. Awalnya dinamai dan dijelaskan pada tahun 2003 oleh Ben Treynor Sloss, seorang insinyur di Google. Sebagai disiplin, SRE bertujuan untuk menjaga ketersediaan, kinerja, dan efisiensi sistem tertentu.

SRE bisa sulit untuk dipatahkan. Ini adalah sebuah pendekatan atau disiplin, bukan serangkaian tugas yang bersifat preskriptif, dan mengambil bentuk yang berbeda berdasarkan kebutuhan organisasi tertentu. Untungnya, ada tujuh prinsip rekayasa keandalan situs yang dapat membantu memandu tim SRE menuju kesuksesan.

Sebagian besar pengembangan perangkat lunak berhak difokuskan pada pembuatan, termasuk DevOps, bidang terkait tetapi berbeda, yang lebih berkaitan dengan seluruh siklus hidup produk. Tetapi pekerjaan itu hampir tidak selesai ketika sistem diluncurkan. Dalam kata pengantar  panduan Google untuk SRE, penulis mencatat bahwa "40 hingga 90% dari total biaya suatu sistem dikeluarkan setelah lahir." SRE peduli dengan apa yang terjadi setelah peluncuran, bertujuan untuk membantu memastikan bahwa suatu produk tetap dapat digunakan.

Elemen terpenting dari SRE adalah keandalan sistem dan waktu aktif. Layanan terbesar di dunia tidak dapat memberikan banyak kebaikan bagi siapa pun jika tidak beroperasi. Oleh karena itu, SRE difokuskan pada meminimalkan waktu henti dan menciptakan sistem yang andal.

Tim SRE juga memastikan bahwa semua elemen produk selalu diperbarui, melalui pengelolaan pembaruan perangkat lunak dan keamanan yang cermat. Standar dan peraturan dapat berubah, dan tim teknik memastikan kepatuhan berkelanjutan.

Praktik SRE juga dapat memberikan penghematan finansial. Banyak prinsip inti SRE berkaitan dengan efisiensi yang dapat menyebabkan penghematan biaya dan upaya yang signifikan, termasuk melalui otomatisasi dan manajemen sumber daya.

Tujuh prinsip SRE meliputi:    

• Merangkul risiko
• Tujuan tingkat layanan
• Menghilangkan kerja keras
• Pemantauan
• Otomatisasi
• Rekayasa rilis
• Kesederhanaan

Sementara SRE sangat peduli dengan mengelola dan membatasi waktu henti, kecenderungan ini tidak berarti bahwa tujuannya adalah agar layanan mempertahankan keandalan layanan yang sempurna dan 100% tersedia. Faktanya, salah satu pilar utama SRE adalah bahwa 100% keandalan tidak hanya tidak realistis, bahkan tidak selalu merupakan hasil yang diinginkan.

% Dalam SRE, risiko dipahami dalam sebuah kontinum, di mana pengurangan risiko menjadi lebih sulit dan mahal secara eksponensial ketika risiko tersebut mendekati keandalan 100%. Mencoba pindah dari 99,99% dapat diandalkan ke 99,999% dapat diandalkan jauh lebih sulit daripada pindah dari 80% ke 99%. Sumber daya yang dibutuhkan untuk semakin mendekati 100% mengurangi kemampuan tim pengembangan untuk melakukan tugas-tugas lain, seperti berinovasi fitur dan pembaruan baru. Sebaliknya, tim memiliki anggaran kesalahan untuk mewakili jumlah kegagalan yang sesuai.

Hal lain yang menentang keandalan total, betapapun berlawanan dengan intuisi, adalah bahwa pelanggan biasanya tidak akan melihat peningkatan keandalan di luar ambang batas tertentu. Ini tidak hanya mahal; ada juga sedikit imbalan. Idealnya, tujuan ditetapkan dan dipenuhi, tetapi tidak terlampaui secara berlebihan.

Sebaliknya, SRE menggunakan metrik untuk mengukur penerimaan risiko waktu henti. Dalam satu metrik, tahun keandalan 99,99% akan mencakup 52,6 menit waktu henti. Metrik yang lebih kompleks mempertimbangkan potensi waktu henti di satu lokasi atau satu elemen layanan sementara yang lain tetap aktif.

Tim SRE harus menilai setiap layanan dan menentukan tingkat ketidakandalan yang dapat diterima. Berapa lama waktu henti yang diizinkan? Apakah berbagai jenis kegagalan, yang timbul dari akar masalah yang berbeda, memiliki dampak yang berbeda pada pengalaman pengguna? Berapa banyak (dalam hal tenaga kerja dan keuangan) biaya yang dibutuhkan untuk melampaui itu? Di mana keseimbangannya?

Memilih tujuan, dan mengukur seberapa efektif tujuan tersebut tercapai dan mengapa, sangat penting bagi tim SRE. Tujuan tingkat layanan, atau SLO, adalah target spesifik dan terukur yang mewakili tingkat kualitas yang telah ditetapkan oleh tim SRE sebagai tujuan. SLO ini dapat berbentuk berbagai metrik, tetapi ketersediaan, tingkat kueri, tingkat kesalahan, dan waktu respons adalah yang paling umum.

Tujuan ini diukur dengan menggunakan indikator tingkat layanan, atau SLI, yang merupakan pengukuran kinerja mentah seperti latensi. Jadi dalam hal ini, SLI akan menjadi metrik latensi, dan SLO adalah agar metrik tersebut tetap berada di bawah ambang batas tertentu. SLOs pada gilirannya dapat menjadi bagian dari perjanjian tingkat layanan, atau SLA, yang merupakan kontrak antara penyedia dan pengguna yang menjabarkan SLOs serta konsekuensi jika tidak memenuhinya.

Memilih SLOs bisa jadi rumit. Idealnya, SLOs harus disusun di sekitar apa yang paling penting bagi pengguna. Untuk layanan game cloud, misalnya, SLO mungkin berkisar pada latensi rendah, tetapi latensi tidak terlalu penting untuk layanan akuntansi.

Idealnya, seorang insinyur keandalan lokasi akan menggunakan SLO yang relatif sedikit untuk fokus pada pencapaian tujuan-tujuan tersebut; yang terpenting adalah melakukan tugas utama dengan benar. Menetapkan tujuan yang realistis juga penting; seperti yang telah kita bahas sebelumnya, kesempurnaan bukanlah tujuan yang realistis atau yang diinginkan.

Para pencipta SRE menekankan pentingnya mendefinisikan “kerja keras” sebagai kategori pekerjaan yang tumpang tindih, namun tidak sama dengan, pekerjaan. Kerja keras adalah tugas-tugas pekerjaan manual yang berskala linear, yang umumnya manual dan berulang-ulang, dan yang sering kali dapat diselesaikan melalui otomatisasi.

Pekerjaan yang harus dilakukan berulang-ulang diklasifikasikan sebagai kerja keras; sebaiknya, tugas individu hanya memerlukan satu atau dua panduan. Pekerjaan yang tidak membuat produk ditingkatkan juga merupakan kerja keras. "Jika layanan Anda tetap dalam keadaan yang sama setelah Anda menyelesaikan tugas, tugas itu mungkin melelahkan," tulis Vivek Rau dari Google. Perbaikan bug, peningkatan fitur dan pengoptimalan bukanlah hal yang sulit, tetapi mengunduh metrik secara manual adalah hal yang berat. Respons insiden, yang dapat mencakup koordinasi yang signifikan antara insinyur dan tim operasi, bukanlah kerja keras, dan taktik manajemen insiden harus direncanakan sebelum rilis.

Ada juga kerja keras kognitif. Pernahkah Anda memiliki resep dasar yang sering Anda gunakan, tetapi harus mencari bahan dan ukurannya setiap kali? Itu adalah kerja keras kognitif: buang-buang waktu dan tenaga untuk harus mempelajari kembali sesuatu berulang kali. Sebaliknya, SRE mengajarkan pembuatan lebih banyak panduan dan standar, yang menghilangkan kebutuhan untuk terus mengingat atau mempelajari kembali metodologi dan tugas.

Salah satu bagian terpenting dari rekayasa keandalan situs adalah pemantauan: menggunakan alat untuk terus mengukur, menganalisis, dan meningkatkan fitur inti dan kinerja sistem. Fitur-fitur inti tersebut sering mencakup apa yang disebut sebagai "empat sinyal emas" pemantauan:

Latensi: Pada dasarnya, berapa lama waktu yang dibutuhkan untuk memenuhi permintaan? Perhatikan bahwa hal ini dapat bervariasi tergantung pada apakah permintaan berhasil atau tidak; terkadang pesan kesalahan dapat memakan waktu yang jauh lebih lama untuk ditayangkan.

Lalu lintas: Berapa banyak beban atau permintaan yang ditempatkan pada layanan? Unit spesifik akan bervariasi; mungkin itu tampilan halaman, mungkin transaksi, mungkin permintaan HTTP.

Kesalahan: Biasanya diukur berdasarkan kecepatan, kesalahan dapat mencakup pengambilan data yang salah, pengambilan data lebih lambat daripada yang ditetapkan dalam SLA, atau gagal mengambil data sama sekali.

Saturasi: Pada dasarnya, saturasi adalah ukuran seberapa dekat dengan kapasitas suatu layanan. Memahami saturasi itu penting karena beberapa layanan akan mulai gagal, atau melambat atau menghasilkan lebih banyak kesalahan, saat mereka mendekati 100% kejenuhan.

Ada banyak alat pemantauan yang dapat mengumpulkan data, menetapkan tolok ukur, men-debug dan menganalisis masalah, menyediakan dasbor observabilitas yang berguna, dan memperingatkan SRE tentang potensi pemadaman atau masalah lainnya. Penting juga untuk memberikan laporan postmortem yang kuat setelah insiden diselesaikan, yang menjelaskan konteks apa pun di sekitar insiden, akar masalah dan pemicu, dampak, metodologi penyelesaian, dan pelajaran untuk masa depan. Postmortem yang terperinci dan objektif bisa sangat berharga dalam menghindari kesalahan yang sama dua kali.

Seperti banyak elemen teknologi modern lainnya, tujuan menggabungkan otomatisasi ke dalam alur kerja adalah untuk membebaskan insinyur dari keharusan bergulat dengan tugas-tugas berulang yang tidak menambah nilai. Dengan waktu luang yang baru diperluas, para insinyur kemudian dapat mengerjakan tugas-tugas yang tidak dapat diselesaikan oleh otomatisasi: kreasi, ide, panduan berskala besar, dan banyak lagi.

Otomatisasi dapat sangat berharga untuk tujuan berikut:

Konsistensi: Sisi buruk dari tugas manual yang berulang-ulang bukan hanya membosankan dan dapat menyita waktu untuk melakukan tindakan yang lebih berharga. Jika tugas-tugas tersebut, seperti pembuatan akun pengguna, diselesaikan dengan alat otomatisasi, kesalahan dan ketidakkonsistenan hampir dapat dihilangkan. Seorang karyawan baru mungkin melakukan sesuatu secara berbeda dibanding karyawan lama; seorang pengguna mungkin secara tidak sengaja memasukkan nilai di kolom yang salah. Proses otomatis (umumnya) akan konsisten.

Skalabilitas: Skalabilitas adalah manfaat jangka panjang utama otomatisasi. Mari kita ambil contoh pembuatan akun pengguna kami sebelumnya. Jika pembuatan akun meningkat secara eksponensial, beban kerja untuk orang yang bertanggung jawab atas penyiapan akun juga meningkat secara eksponensial, sehingga menarik karyawan ini dari aspek lain yang mungkin lebih berharga dalam pekerjaannya. Sistem otomatis tidak akan memiliki masalah ini.

Kecepatan: Tugas-tugas tertentu, seperti menemukan dan memperbaiki bug dalam kode, dapat memakan waktu yang sangat lama bagi manusia. Sistem perangkat lunak otomatis memiliki kemampuan untuk memantau sejumlah besar data, dan sering kali dapat mendeteksi kesalahan lebih cepat daripada manusia melalui pengenalan pola yang canggih dan alat bantu lainnya. Perbaikan dapat diterapkan dengan cepat, seringkali tanpa keterlibatan manusia.

Ada juga, tentu saja, bahaya yang mengintai di samping proses otomatisasi apa pun. Yaitu antara lain:

Biaya di muka: Otomatisasi harus dibuat sebelum dapat diterapkan. Ini dapat memakan banyak waktu, tenaga, dan bahkan biaya perangkat keras. Nilai otomatisasi harus dianggap sebagai keseimbangan antara upaya untuk membuatnya dan sumber daya aktual yang akan dihemat setelah diluncurkan.

Pemeliharaan: Tugas otomatis mungkin terlihat seolah-olah dapat berjalan selamanya, tetapi sering kali tidak demikian. Kode otomatisasi harus selalu diperbarui dan sinkron dengan kode lain dan pembaruan sistem. Jika fitur baru ditambahkan, kode otomatisasi mungkin juga perlu diperbarui melalui intervensi manusia untuk memasukkan tindakan baru atau untuk mencegah kesalahan.

Kecerdasan buatan menawarkan beberapa kemungkinan baru dan menarik untuk SRE, yang paling jelas di bidang otomatisasi. Baik biaya awal dan pemeliharaan secara teoritis dapat dimodulasi oleh model AI baru. Konon, AI juga membawa titik-titik masalah potensial baru: halusinasi, keamanan, dan privasi, terutama.

Rekayasa rilis adalah sub-disiplin rekayasa perangkat lunak yang secara khusus berfokus pada langkah-langkah yang diperlukan untuk merilis perangkat lunak. Langkah-langkah tersebut meliputi pembuatan versi, jadwal rilis, pembangunan berkelanjutan atau berkala, pemilihan dan pengumpulan metrik rilis, dan banyak lagi. Dalam SRE, rekayasa rilis dibangun di awal, bukan sebagai renungan; tujuannya adalah untuk menghindari penugasan tugas rekayasa rilis secara serampangan pada menit-menit terakhir.

Rekayasa rilis, sebagai disiplin, mencakup beberapa prinsip utama. Yaitu antara lain:

Otomatisasi dan layanan mandiri: Idealnya, banyak proses rilis dapat diotomatisasi, dan memerlukan interaksi minimal atau tidak sama sekali dari para insinyur. Ini memastikan rilis yang cepat dan stabil.

Kecepatan: Dalam rekayasa rilis, filosofi rilis yang cepat dan sering lebih disukai. Dengan meluncurkan rilis dengan cepat, bahkan mungkin sesering setiap jam di sekitar peluncuran, ada lebih sedikit perubahan antar versi. Kecepatan ini memungkinkan pengujian dan pemecahan masalah yang lebih mudah.

Build yang hermetis: Proses build harus sepenuhnya independen dari mesin build itu sendiri, menggunakan kompiler, pustaka, dan alat yang paling populer. "Jika dua orang mencoba membuat produk yang sama dengan nomor revisi yang sama di repositori kode sumber pada mesin yang berbeda, kami mengharapkan hasil yang sama," tulis Dinah McNutt dari Google.

Standar dan kebijakan: Untuk alasan keamanan, sangat penting bahwa ada pemeriksaan pada tugas-tugas tertentu, termasuk penerapan, perubahan kode sumber, rilis baru, dan perubahan untuk konfigurasi build.

Sebagian besar rekayasa keandalan situs bertujuan untuk kesederhanaan. Perangkat lunak, tulis Max Luebbe dari Google, "secara inheren dinamis dan tidak stabil." Dengan mengingat hal tersebut, kesederhanaan adalah kunci untuk meminimalkan potensi masalah dan mencoba mengendalikan ketidakstabilan yang melekat.

Untuk tujuan ini, rekayasa keandalan situs mempromosikan berbagai tugas yang dapat menyederhanakan dan memperjelas proyek.

1. Memilih fitur mana yang akan disertakan dengan cermat memang membantu, tetapi akan sama membantu jika Anda sekadar menghapus semua fitur yang tidak terlalu menambah kegunaan produk. Semakin banyak fitur berarti semakin rumit.
2. Rilis yang lebih kecil dan lebih sering memungkinkan debugging dan pemecahan masalah yang jauh lebih mudah. Rilis baru dengan lusinan fitur baru dapat memperkenalkan kesalahan yang mungkin sangat sulit untuk dilacak. Rilis dengan satu fitur baru? Masalah potensial hanya bisa datang dari satu tempat.
3. Demikian pula, Anda mungkin tergoda untuk menambahkan kompleksitas pada API melalui penggunaan beberapa titik akhir, layanan mikro, dan banyak lagi. Ini harus dihindari. API yang lebih sederhana lebih cepat diatur, membutuhkan lebih sedikit dokumentasi, dan mengurangi waktu dan biaya integrasi.