Apa Itu SLO? Panduan Anggaran Kesalahan dan Sheets

Jadi, apa itu SLO? Service level objective adalah target keandalan yang Anda tetapkan untuk layanan, ditulis sebagai angka dalam jendela waktu. "99,9% permintaan berhasil selama 30 hari" adalah SLO. Ini memberi tahu tim Anda berapa banyak kegagalan yang dapat diterima sebelum Anda berhenti mengirim dan mulai memperbaiki. Matematika di baliknya adalah pembagian sederhana, yang merupakan alasan mengapa spreadsheet menanganinya dengan baik.

Biscuit sudah mengambil rumusnya. Anda membawa angkanya.

Tiga singkatan yang terus Anda lihat, dipisahkan

SLI, SLO, SLA. Orang sering mencampuradukkan di rapat, jadi di sini versi singkatnya.

• SLI (service level indicator): hal yang Anda ukur. Bagian permintaan yang kembali tanpa kesalahan, bagian halaman yang muat di bawah 300 ms, bagian pekerjaan yang selesai tepat waktu.

• SLO (service level objective): target untuk pengukuran tersebut. "SLI harus setidaknya 99,9% selama 30 hari."

• SLA (service level agreement): kontrak dengan konsekuensi, biasanya uang kembali, terlampir pada target.

Uji terbaik berasal dari buku SRE Google: tanyakan apa yang terjadi jika Anda melewatkan target. Jika tidak ada yang terjadi secara kontraktual, Anda melihat SLO, bukan SLA. SLO Anda harus lebih ketat daripada SLA apa pun yang telah Anda tandatangani, sehingga Anda mendapat peringatan sebelum pelanggan mendapat pengembalian dana.

Dalam istilah spreadsheet: SLI adalah kolom pengukuran, SLO adalah satu sel dengan target, dan SLA adalah PDF yang disimpan seseorang di legal.

Mengapa 99,9% dan 99,99% adalah janji yang sangat berbeda

Setiap angka 9 tambahan mengurangi downtime yang diizinkan dengan faktor sepuluh. Selama bulan 30 hari (43.200 menit), inilah yang tersisa untuk setiap target:

• 99%: anggaran 1%, 432 menit (7,2 jam) downtime yang diizinkan per 30 hari

• 99,5%: anggaran 0,5%, 216 menit (3,6 jam)

• 99,9%: anggaran 0,1%, 43,2 menit

• 99,95%: anggaran 0,05%, 21,6 menit

• 99,99%: anggaran 0,01%, 4,32 menit

Baris terakhir adalah jebakan. Empat menit per bulan berarti manusia bahkan tidak dapat menyelesaikan membaca peringatan sebelum anggaran hilang. Sebagian besar alat internal, dasbor, dan produk SaaS kecil tidak membutuhkannya, dan mengejarnya membutuhkan biaya nyata dalam redundansi dan jam on-call.

Lewati 99,99% kecuali pelanggan membayar Anda khusus untuk itu. Saran Google juga blak-blakan: mulai dengan target yang longgar yang dapat Anda ketatkan nanti, karena target yang ketat yang harus Anda relaksasi mengajarkan semua orang untuk mengabaikan angka tersebut.

Anggaran kesalahan: angka yang sebenarnya diperdebatkan tim Anda

Anggaran kesalahan adalah apa pun yang tersisa oleh SLO. Target 99,9%, jadi anggarannya adalah 0,1%. Selama 30 hari, itu adalah 43,2 menit waktu "buruk" yang diizinkan untuk digunakan.

Anggap saja sebagai indikator bahan bakar. Deploy yang berisiko membakar bahan bakar. Migrasi database yang buruk membakar bahan bakar. Outage pada jam 3 pagi membakar banyak bahan bakar. Ketika tangkinya penuh, kirim lebih cepat. Ketika kosong, berhentilah menambah fitur dan perbaiki keandalan.

Kebijakan sampel Google sendiri konkrit tentang hal itu: jika layanan menguras anggarannya selama jendela empat minggu, semua perubahan berhenti kecuali perbaikan P0 dan patch keamanan sampai layanan kembali dalam SLO-nya. Anggaran adalah alat negosiasi, bukan hukuman. Ini memungkinkan manajer produk dan insinyur berdebat dari sel yang sama alih-alih dari firasat.

Bernilai repot jika Anda memiliki lebih dari satu tim yang menyentuh layanan yang sama. Overkill jika Anda adalah pendiri solo dengan satu halaman landing dan formulir kontak.

Memilih SLI yang dikenali pengguna Anda

SLI terbaik menggambarkan momen yang akan diperhatikan seseorang. Tiga mencakup sebagian besar layanan:

• Availability (Ketersediaan): bagian dari permintaan yang berhasil. Mudah diukur, mudah dijelaskan.

• Latency (Latensi): bagian permintaan lebih cepat dari ambang batas. "95% pencarian kembali dalam 300 ms" lebih baik daripada rata-rata, karena rata-rata menyembunyikan ekor lambat yang mengganggu orang.

• Freshness (Kesegaran): untuk pipeline data dan laporan, bagian dari run yang selesai sebelum tenggat waktu. Yang ini sesuai dengan orang spreadsheet: "spreadsheet penjualan pagi diperbarui pada jam 8 pagi pada 99% hari kerja."

Tulis SLI sebagai pecahan: peristiwa baik dibagi dengan peristiwa yang valid. Satu kebiasaan itu membuat setiap SLO dapat dihitung dalam satu sel, dan itu memaksa Anda memutuskan apa yang dihitung sebagai "baik" sebelum insiden, bukan selama.

Untuk jendela, rolling 30 hari adalah pilihan yang biasa. Bulan kalender lebih sederhana untuk dilaporkan tetapi mengatur ulang anggaran pada hari ke-1, yang menggoda tim untuk mengirim rilis berisiko akhir bulan. Di spreadsheet, jendela rolling hanya berarti memfilter tab Incidents ke 30 hari terakhir dengan SUMIFS(Incidents!C:C,Incidents!A:A,">="&TODAY()-30).

Buat pelacak SLO di Google Sheets atau Excel dalam 10 menit

Anda tidak perlu platform monitoring untuk memulai. Anda memerlukan dua tab: Incidents dan SLO.

Di tab Incidents, catat setiap outage dengan waktu mulai di kolom A, waktu berakhir di kolom B, dan durasi di kolom C:

=(B2-A2)*24*60

• B2 dan A2: tanggal dan waktu akhir dan mulai insiden.

• *24*60: mengubah perbedaan berbasis hari menjadi menit.

Bekerja di Excel dan Sheets, semua versi.

Sekarang tab SLO. Masukkan label ini di kolom A dan rumus di kolom B:

B1: 0.999                         (target SLO Anda)
B2: 30                            (jendela dalam hari)
B3: =B2*24*60                     (total menit dalam jendela)
B4: =B3*(1-B1)                    (anggaran kesalahan dalam menit)
B5: =SUM(Incidents!C2:C)          (downtime sejauh ini)
B6: =1-B5/B3                      (ketersediaan aktual)
B7: =B4-B5                        (anggaran tersisa, dalam menit)
B8: =B5/B4                        (bagian anggaran terbakar)

Dengan target 99,9%, B3 mengembalikan 43200 dan B4 mengembalikan 43,2. Catat outage 12 menit dan B8 menunjukkan 27,8%. Voilà seperti apa hasilnya di sel nyata.

Catatan tentang C2:C di B5: jangkauan terbuka-akhir adalah sintaks Sheets. Di Excel, gunakan jangkauan tetap seperti Incidents!C2:C500 atau referensi tabel.

Tambahkan sel status sehingga tidak ada yang harus membaca angkanya:

=IF(B8>=1,"Freeze releases",IF(B8>=0.5,"Careful","Ship it"))

• B8>=1: anggaran sepenuhnya dihabiskan atau terlampaui.

• B8>=0.5: setengah hilang, jadi tinjau perubahan berisiko.

• Yang lain: lampu hijau.

Pilih ambang batas Anda sendiri. Lima puluh persen adalah tebakan awal, bukan hukum fisika.

Terjebak pada sintaks untuk versi Anda sendiri dari spreadsheet ini? Jelaskan dalam bahasa Inggris biasa dan biarkan alat menulisnya.

Menghitung permintaan bukan menit

Pelacakan berbasis waktu mudah dijelaskan tetapi kasar. Jika layanan Anda "down" selama 5 menit pada jam 4 pagi ketika tidak ada orang online, itu sakit lebih sedikit daripada 5 menit saat siang hari. Sebagian besar tim serius mendefinisikan SLI berdasarkan permintaan sebagai gantinya.

Tempel ekspor log permintaan Anda ke tab, dengan kode status HTTP di kolom B. Kemudian:

=1-COUNTIF(B2:B,">=500")/COUNTA(B2:B)

• COUNTIF(B2:B,">=500"): menghitung permintaan yang mengembalikan kesalahan server.

• COUNTA(B2:B): menghitung semua permintaan. Satu dikurangi bagian kesalahan memberi Anda bagian kesuksesan.

Hasilnya adalah SLI ketersediaan Anda sebagai pecahan. Bandingkan dengan sel target dan Anda memiliki seluruh SLO dalam satu baris. Excel 2016 dan 365 keduanya menerima COUNTIF; hanya tukar B2:B untuk jangkauan terbatas.

Dua peringatan jujur. Spreadsheet tersedak pada jutaan baris, jadi ekspor total harian sebagai gantinya dari log mentah. Dan respons 4xx biasanya kesalahan pengguna, bukan outage Anda, jadi putuskan aturan itu sekali dan tulislah.

Burn rate: rumus yang memperingatkan Anda sebelum terlambat

Mengetahui Anda membakar 27,8% anggaran bagus. Mengetahui Anda membakarnya lebih cepat daripada kalender berguna. Rasio itu adalah burn rate.

=B8/(B9/B2)

• B8: bagian anggaran terbakar sejauh ini.

• B9: hari berlalu dalam jendela (masukkan secara manual atau gunakan =TODAY()-B10, dengan tanggal awal jendela di B10).

• B2: total jendela dalam hari.

Burn rate 1 berarti Anda akan menyelesaikan jendela dengan tepat nol anggaran tersisa. Di atas 1, Anda menuju pembekuan. Di bawah 1, Anda punya ruang. Jika Anda 10 hari ke jendela 30 hari dan sudah membakar 60%, burn rate adalah 1,8. Itulah angka yang harus disimpan di layar.

Ini adalah ide yang sama yang digunakan alat monitoring besar untuk peringatan burn-rate. Spreadsheet tidak akan memanggil Anda pada jam 3 pagi, tetapi perlakukan sebagai lapisan pelaporan, bukan alarm.

Berikut contoh yang dikerjakan dengan angka nyata. SLO Anda adalah 99,9% lebih dari 30 hari, jadi anggarannya adalah 43,2 menit. Hari 1 hingga 8: deploy buruk mengambil halaman checkout selama 14 menit. Itu 32,4% dari anggaran yang hilang dalam seperempat jendela, burn rate sekitar 1,2. Tidak ada yang sedang terbakar, tetapi spreadsheet sekarang mengatakan "Careful", dan migrasi berisiko berikutnya mendapat pandangan kedua. Hari ke-15: outage penyedia menambahkan 30 menit. Total 44 menit, 101,9% terbakar. Sel status beralih ke "Freeze releases", dan percakapan tentang prioritas terjadi dengan angka di meja bukan perasaan.

Itulah nilai keseluruhan dari latihan itu. Bukan angka sembilan, tetapi sel bersama yang dapat ditunjuk semua orang.

Ketika spreadsheet berhenti cukup

Pelacak seperti ini berfungsi untuk satu atau dua layanan dan tinjauan mingguan. Ini rusak ketika Anda memiliki puluhan layanan, memerlukan pengumpulan data otomatis, atau menginginkan peringatan yang menyala dalam menit bukan pada rapat Senin berikutnya.

Waktunya melihat alat observabilitas yang tepat. Datadog dan Grafana keduanya memiliki fitur SLO asli yang menarik SLI langsung dari metrik Anda dan menggambar anggaran untuk Anda.

Pilih Grafana jika Anda menginginkan sumber terbuka dan sudah menjalankan Prometheus. Pilih Datadog jika Anda lebih suka membayar untuk tidak menjalankan apa pun sendiri. Either way, simpan spreadsheet di sekitar untuk deck tinjauan bulanan, karena semua orang di ruangan dapat membukanya dan tidak ada yang memerlukan login ke vendor.

Jika Anda ingin bantuan merancka set SLI pertama untuk layanan, asisten umum adalah mitra brainstorming yang layak. Verifikasi setiap angka yang diberikannya, karena akan dengan senang hati menemukan target yang terdengar masuk akal.

Kesalahan yang membuat SLO tidak berguna, dan apa yang harus dilakukan pada hari Senin

Beberapa pola yang telah dilihat Biscuit berakhir buruk:

• Menyalin performa saat ini sebagai target. Jika Anda berjalan pada 99,97% kuartal terakhir, SLO 99,97% mengunci kecepatan yang mungkin tidak dapat Anda pertahankan.

• Terlalu banyak SLO. Dua atau tiga per layanan. Melampaui itu, tidak ada yang ingat mana yang penting.

• Mengukur apa yang mudah, bukan apa yang dirasakan pengguna. Penggunaan CPU bukan SLI. Checkout yang gagal adalah.

• Tidak ada konsekuensi. SLO tanpa kebijakan anggaran kesalahan adalah harapan. Putuskan sebelumnya apa yang terjadi pada 50%, 100%, dan 150% terbakar.

• Tidak pernah mengunjungi kembali target. Tinjau setiap kuartal. Jika Anda tidak pernah mendekati menghabiskan anggaran, target terlalu longgar.

Sekarang bagian Senin. Pilih satu layanan. Tulis satu SLI dalam satu kalimat yang dapat diikuti non-insinyur. Tetapkan target yang longgar, 99,5% atau 99,9%. Bangun dua tab di atas, catat insiden bulan lalu, dan lihat apa yang dikatakan anggaran.

Jika jawabannya "kami membakar 300% darinya", Anda baru saja mengetahui mengapa semua orang merasa lelah. Jika jawabannya "kami membakar 4%", ketatkan target atau kirim lebih cepat. Either way, Anda sekarang memiliki angka untuk diperdebatkan bukan perasaan.

Good boy. Sekarang pergi dan catat insiden tersebut.