Prinsip dan praktik utama SRE: siklus yang baik
Jika benar bahwa dalam arti tertentu "Anda adalah apa yang Anda lakukan", maka kami telah datang ke jantung modul ini. Di unit ini, kita akan melihat dua praktik yang sering dianggap inti untuk praktik SRE. Keduanya berasal dari prinsip bahwa penting untuk menciptakan "siklus berbudi." Siklus yang berbudi dalam konteks ini adalah praktik yang membangun perulangan umpan balik di organisasi yang membantu organisasi tersebut terus menjadi lebih baik. Kami memiliki seluruh modul tindak lanjut pada tepat dua praktik ini sehingga kami hanya akan melompati permukaan dengan gambaran umum masing-masing di sini.
Siklus yang baik #1: SLI dan SLO
Sebelumnya dalam modul ini, kami menekankan titik kami tentang bekerja menuju "tingkat keandalan yang sesuai". Bagian ini tepatnya adalah tempat di mana konsep itu dibawa untuk menanggung.
Katakanlah Anda memiliki layanan baru yang Anda rencanakan untuk dibawa ke produksi (baik yang telah dibangun atau yang masih dalam proses perencanaan). Sebagai bagian dari proses itu, penting untuk membuat beberapa keputusan tentang keandalan yang diinginkan. Jika Anda tidak menulis semua kode sendiri, keputusan ini dibuat (dan titik ini sangat penting) dalam kolaborasi dengan pengembang yang membuat hal tersebut.
Keputusan pertama yang harus dibuat adalah, apa yang harus kita gunakan sebagai indikator kesehatan layanan (Indikator Tingkat Layanan atau SLI)? Cara lain untuk mengajukan pertanyaan ini adalah "Bagaimana Anda tahu kapan terserah dan bekerja dengan baik?". Ada banyak cara untuk melacak SLI dan kami menjelajahi beberapa secara rinci nanti. Namun, indikator ini biasanya:
- Langkah-langkah keberhasilan vs. kegagalan. Apakah layanan berhasil menyelesaikan operasi beberapa persentase waktu?
- Ukuran waktu. Apakah kita mengembalikan jawaban dalam ambang waktu tertentu?
- Ukuran throughput. Apakah kita memproses sejumlah data?
Atau, beberapa kombinasi dari semua langkah ini.
Sebagai contoh sederhana, kita dapat mengatakan bahwa SLI untuk layanan kita adalah seberapa sering berhasil, ditunjukkan melalui kode HTTP 200 (vs. 500 atau beberapa kode lainnya).
Sekarang kita memiliki indikator yang jelas yang memberi tahu kita bagaimana layanan dilakukan. Kami ingin memutuskan tingkat keandalan apa yang kami harapkan atau inginkan darinya. Misalnya, apakah kita mengharapkan selama jangka waktu sehari untuk melihat tingkat kegagalan 20% dari layanan? Kami menggunakan angka bulat dan besar di sini karena mudah untuk alasan di awal. Dalam modul selanjutnya, kami meningkatkan kompleksitas dan presisi pernyataan seperti ini ("pengguna mana yang melihat tingkat kesalahan tersebut? beberapa dari mereka? kebanyakan dari mereka?" dan sebagainya). Harapan itu, dibuat bekerja sama dengan pengembang layanan, adalah Tujuan Tingkat Layanan (SLO).
SLO harus menjadi sesuatu yang dapat diukur dan diwakili secara akurat dalam sistem pemantauan Anda. Ini dimaksudkan sebagai tujuan yang objektif, dipahami dengan baik untuk keandalan layanan berapa jumlah yang cukup baik? Tidak ada "baik, saya pikir layanan telah baik-baik saja selama seminggu terakhir atau lebih, tetapi agak sulit untuk mengatakan" terjadi di sini. Baik layanan memenuhi SLO-nya atau tidak, data harus jelas. Jika tidak memenuhi SLO-nya (terutama berulang kali selama rentang waktu), maka ada sesuatu yang salah dan perlu ditangani.
Anggaran kesalahan
Kami dapat memahami bahwa organisasi mungkin beraksi jika layanan tidak memenuhi SLO-nya. Tapi, SRE mengambil seluruh konsep ini langkah maju lain untuk kasus di mana SLO terpenuhi atau terlampaui. Beberapa organisasi menggunakan SLO untuk membangun apa yang mereka sebut "anggaran kesalahan".
Untuk menunjukkan ide ini, mari kita gunakan layanan sampel yang telah kita bahas dan SLO-nya 80% berhasil (anggap saja sebagai "harus naik 80% dari waktu"). Dengan SLO waktu aktif 80% kami telah menyatakan bahwa layanan kami harus naik 80% dari waktu. Tapi bagaimana dengan 20% lainnya? Jika layanan kami turun 20% lainnya, kami tidak benar-benar "peduli" karena kami telah memutuskan untuk naik 20% tambahan tidak penting bagi kami sebagai tujuan layanan.
Jadi jika kami tidak peduli tentang apa yang terjadi selama waktu itu, apa yang bisa kami lakukan dengan layanan? Satu hal yang dapat kami lakukan adalah mengganggu layanan yang sedang berjalan dengan meningkatkannya, mungkin dengan rilis baru yang menambahkan beberapa fitur. Jika rilis baru tetap aktif dan tidak menambahkan waktu henti, bagus. Jika rilis baru tersebut menyebabkan layanan kurang stabil dan mengembalikan kesalahan 10% waktu lain saat di-debug, masih baik-baik saja. Kami berada dalam anggaran kami yang diizinkan tidak dapat diandalkan.
Anggaran kesalahan adalah perbedaan antara potensi keandalan sempurna layanan dan keandalan yang diinginkan (100% - 80% = 20%). Dalam hal ini, anggaran kesalahan memberi kita dana 20% tidak keandalan 20% waktu di mana kita "tidak peduli apakah itu naik atau tidak karena masih dalam spesifikasi". Kita dapat menarik dan menghabiskan 20% waktu yang kita inginkan (mungkin dengan lebih banyak rilis) sampai habis seperti anggaran lainnya.
Anggaran kesalahan juga digunakan di beberapa organisasi untuk kasus yang kurang menyenangkan, di mana Anda tidak membuat SLO Anda. Dalam hal ini, Anda mungkin memilih untuk melakukan sesuatu yang sedikit lebih ketat daripada hanya "mengambil tindakan". Katakanlah layanan kami telah mengalami beberapa masalah dan telah naik hanya 60% dari waktu seperti yang ditunjukkan oleh SLI yang kami pilih sebelumnya. Kami tidak membuat tujuan kami (SLO). Layanan kami telah menggunakan anggaran kesalahannya. Organisasi dapat memilih untuk menahan rilis yang direncanakan karena tahu bahwa mengganggu sistem lebih jauh pada titik ini kemungkinan hanya akan memperburuk situasi keandalan. Biasanya, anggaran kesalahan dihitung untuk jangka waktu yang ditetapkan; sebulan, seperempat, dan sebagainya. Secara bergulir sehingga pada akhirnya jika keandalan layanan membaik, anggaran tersebut akan kembali.
Selama waktu rilis terjaga, organisasi mungkin memilih untuk mempivot beberapa sumber daya rekayasa dari pengembangan fitur menuju pekerjaan keandalan. Dengan tujuan untuk membantu mengungkap dan meningkatkan sumber masalah yang menyebabkan layanan meledakkan SLO-nya.
Alasan mengapa kami mengatakan "beberapa organisasi" ketika datang ke kesalahan anggaran adalah implementasinya, terutama dalam kasus di mana digunakan untuk gerbang rilis, memerlukan dukungan institusional tertentu. Ketika dihadapkan dengan keputusan rilis, organisasi harus bersedia untuk menahan rilis jika keandalan layanan hingga saat ini belum dihentikan. Keputusan itu bukan keputusan yang bersedia dibuat oleh semua organisasi. Keputusan ini juga bukan satu-satunya kemungkinan respons terhadap anggaran kesalahan yang habis, tetapi itu adalah salah satu yang paling banyak dibicarakan.
Dalam modul terpisah, kita berbicara secara jauh lebih rinci tentang SLI, SLO, dan anggaran kesalahan. Tapi, ada baiknya di sini untuk menyoroti aspek siklus yang saleh dari praktik-praktik ini. Secara teori, ini menyediakan cara bagi organisasi untuk menggambarkan, berkomunikasi, dan bertindak berdasarkan keandalan layanan. Meskipun melakukannya dengan cara yang membuat semua orang bekerja menuju keandalan yang lebih baik. Perulangan umpan balik ini bisa sangat penting.
Siklus yang baik #2: postmortem tanpa cela
Gagasan postmortem—analisis retrospektif dari peristiwa yang signifikan dan biasanya tidak diinginkan—bahkan tidak spesifik untuk rekayasa keandalan situs dari jarak jauh. Bahkan tidak jarang di dunia operasi. Satu hal yang lebih dekat untuk menjadi khas adalah desakan SRE bahwa postmortems harus "tanpa cela." Mereka perlu fokus pada kegagalan proses atau teknologi selama insiden, bukan tindakan orang tertentu. “Ada apa dengan proses yang kami miliki yang memungkinkan X melakukan hal yang menyebabkan kegagalan? Informasi apa yang orang itu tidak sediakan, atau bahkan menonjol saat ini yang menyebabkan mereka sampai pada kesimpulan yang salah? Pagar pembatas apa yang seharusnya ada sehingga tidak mungkin mengalami kegagalan bencana seperti itu?" Pertanyaan-pertanyaan ini adalah jenis yang diajukan dalam postmortem tanpa disalahkan.
Tenor dan arah pertanyaan-pertanyaan ini sangat penting. Kami mencari cara untuk meningkatkan sistem atau proses, bukan cara untuk menghukum individu yang penggunaan sistem atau proses tersebut dengan itikad baik berkontribusi pada pemadaman. Sangat penting untuk diingat "Anda tidak dapat memecat jalan Anda untuk dapat diandalkan". Dalam pengalaman kami, organisasi yang memecat seseorang setiap kali ada insiden produksi (dengan beberapa pengecualian), tidak belajar dari insiden tersebut. Sebaliknya, mereka dibiarkan dengan satu individu, gemetar di sudut, takut untuk membuat perubahan pada apa pun sama sekali.
Tetapi proses pasca-mortem yang berfungsi dengan baik dalam organisasi menciptakan siklus yang baik. Ini memungkinkan organisasi belajar dari pemadamannya dan terus meningkatkan sistemnya (memberikan analisis dan tindak lanjut yang tepat dilakukan).
Hubungan dengan kegagalan dan kesalahan yang dianut oleh organisasi sebagai peluang untuk pembelajaran dan peningkatan adalah prinsip inti dari rekayasa keandalan situs. Konstruksi siklus yang baik untuk memanfaatkan peluang ini dan untuk membimbing organisasi menuju keandalan yang lebih besar adalah hal lain.
Mari kita jelajahi beberapa prinsip dan praktik lain, yang berpusat pada sisi manusia SRE, di unit berikutnya.