SRE (Site Reliability Engineering) minangka pendekatan kanggo njamin kasedhiyan proyek web. Iki dianggep minangka kerangka kanggo DevOps lan ngobrol babagan carane entuk sukses ing ngetrapake praktik DevOps. Terjemahan ing artikel iki buku saka Google. Aku nyiapake terjemahan iki dhewe lan ngandelake pengalamanku dhewe kanggo mangerteni proses ngawasi. Ing saluran telegram и Aku uga nerbitake terjemahan Bab 6 saka buku sing padha babagan tujuan tingkat layanan.
Terjemahan dening kucing. Seneng maca!
Ora mungkin kanggo ngatur layanan yen ora ana pangerten babagan indikator apa sing penting lan cara ngukur lan ngevaluasi. Kanggo tujuan iki, kita nemtokake lan nyedhiyakake tingkat layanan tartamtu kanggo pangguna, ora preduli yen nggunakake salah sawijining API internal utawa produk umum.
Kita nggunakake intuisi, pengalaman, lan pangerten babagan kepinginan pangguna kanggo mangerteni Service Level Indicators (SLIs), Service Level Objectives (SLOs), lan Service Level Agreements (SLAs). Dimensi kasebut njlèntrèhaké metrik utama sing arep dipantau lan bakal ditanggepi yen ora bisa nyedhiyani kualitas layanan sing dikarepake. Pungkasane, milih metrik sing bener mbantu nuntun tumindak sing bener yen ana sing salah, lan uga menehi kapercayan tim SRE babagan kesehatan layanan kasebut.
Bab iki nerangake pendekatan sing digunakake kanggo nglawan masalah modeling metrik, pilihan metrik, lan analisis metrik. Umume panjelasan bakal tanpa conto, mula kita bakal nggunakake layanan Shakespeare sing diterangake ing conto implementasine (nelusuri karya Shakespeare) kanggo nggambarake poin utama.
Terminologi tingkat layanan
Akeh pembaca sing ngerti konsep SLA, nanging istilah SLI lan SLO pantes didefinisikan kanthi ati-ati amarga umume istilah SLA overloaded lan duwe sawetara makna gumantung konteks. Kanggo gamblang, kita pengin misahake nilai kasebut.
Indikator
SLI minangka indikator tingkat layanan-ukuran kuantitatif sing ditemtokake kanthi teliti saka siji aspek saka tingkat layanan sing diwenehake.
Kanggo umume layanan, kunci SLI dianggep minangka latensi panyuwunan - suwene wektu kanggo ngasilake respon kanggo panjaluk. SLI umum liyane kalebu tingkat kesalahan, asring ditulis minangka bagian sekedhik saka kabeh panjalukan sing ditampa, lan throughput sistem, biasane diukur ing panjalukan saben detik. Pangukuran asring dikumpulake: data mentah dikumpulake dhisik banjur diowahi dadi tingkat owah-owahan, rata-rata, utawa persentil.
Saenipun, SLI langsung ngukur tingkat kapentingan layanan, nanging kadhangkala mung metrik sing gegandhengan sing kasedhiya kanggo pangukuran amarga sing asli angel dipikolehi utawa diinterpretasikake. Contone, latensi sisih klien asring dadi metrik sing luwih cocog, nanging ana wektu nalika latensi mung bisa diukur ing server.
Jinis SLI liyane sing penting kanggo SRE yaiku kasedhiyan, utawa bagean wektu sajrone layanan bisa digunakake. Asring ditetepake minangka tingkat panjalukan sing sukses, kadhangkala disebut ngasilake. (Urip-kemungkinan data bakal disimpen kanggo wektu sing suwe-uga penting kanggo sistem panyimpenan data.) Senajan kasedhiyan 100% ora bisa, kasedhiyan cedhak 100% asring bisa digayuh; nilai kasedhiyan ditulis minangka jumlah "sangang" » persentasi kasedhiyan. Contone, kasedhiyan 99% lan 99,999% bisa uga diwenehi label minangka "2 sangang" lan "5 sangang". Sasaran kasedhiyan Google Compute Engine saiki yaiku "telung lan setengah sangang" utawa 99,95%.
Tujuane
SLO minangka tujuan tingkat layanan: nilai target utawa sawetara nilai kanggo tingkat layanan sing diukur dening SLI. Nilai normal kanggo SLO yaiku "SLI ≤ Target" utawa "Limit Ngisor ≤ SLI ≤ Limit Ndhuwur". Contone, kita bisa mutusake yen bakal ngasilake asil panelusuran Shakespeare "cepet" kanthi nyetel SLO menyang latensi pitakon panelusuran rata-rata kurang saka 100 milidetik.
Milih SLO sing bener yaiku proses sing rumit. Kaping pisanan, sampeyan ora bisa milih nilai tartamtu. Kanggo panjalukan HTTP mlebu eksternal menyang layanan sampeyan, metrik Query Per Second (QPS) utamane ditemtokake dening kepinginan pangguna kanggo ngunjungi layanan sampeyan, lan sampeyan ora bisa nyetel SLO kanggo iku.
Ing sisih liya, sampeyan bisa ujar manawa sampeyan pengin latensi rata-rata kanggo saben panyuwunan kurang saka 100 milidetik. Nyetel tujuan kasebut bisa meksa sampeyan nulis frontend kanthi latensi sing sithik utawa tuku peralatan sing nyedhiyakake latensi kasebut. (100 milliseconds temenan nomer kasepakatan, nanging luwih apik kanggo duwe nomer latensi malah luwih murah. Ana bukti kanggo suggest sing kacepetan cepet luwih saka kacepetan alon, lan latency ing pangolahan pangguna panjalukan ndhuwur nilai tartamtu bener meksa wong kanggo tetep adoh. saka layanan sampeyan.)
Maneh, iki luwih ambigu tinimbang sing katon sepisanan: sampeyan ora kudu ngilangi QPS saka pitungan. Kasunyatane yaiku yen QPS lan latensi ana hubungane banget: QPS sing luwih dhuwur asring nyebabake latensi sing luwih dhuwur, lan layanan biasane ngalami penurunan kinerja sing cetha nalika tekan ambang beban tartamtu.
Milih lan nerbitake SLO nyetel pangarepan pangguna babagan cara layanan kasebut bakal ditindakake. Strategi iki bisa nyuda keluhan sing ora ana dhasar marang pemilik layanan, kayata kinerja alon. Tanpa SLO sing jelas, pangguna kerep nggawe pangarepan dhewe babagan kinerja sing dikarepake, sing bisa uga ora ana hubungane karo panemu wong sing ngrancang lan ngatur layanan kasebut. Kahanan iki bisa nyebabake pangarep-arep saka layanan kasebut, nalika pangguna salah percaya yen layanan kasebut bakal luwih gampang diakses tinimbang sing sejatine, lan nyebabake rasa ora percaya nalika pangguna percaya yen sistem kasebut kurang dipercaya tinimbang sing sejatine.
Persetujuan
Persetujuan tingkat layanan minangka kontrak eksplisit utawa implisit karo pangguna sampeyan sing kalebu akibat saka patemon (utawa ora ketemu) SLO sing ana. Konsekuensi paling gampang diakoni nalika ana finansial - diskon utawa denda - nanging bisa uga ana ing wangun liya. Cara sing gampang kanggo ngomong babagan bedane SLO lan SLA yaiku takon "apa sing kedadeyan yen SLO ora ketemu?" Yen ora ana akibat sing jelas, sampeyan meh mesthi ndeleng SLO.
SRE biasane ora melu nggawe SLA amarga SLA raket karo keputusan bisnis lan produk. Nanging, SRE melu mbantu nyuda akibat saka SLO sing gagal. Dheweke uga bisa mbantu nemtokake SLI: Temenan, kudu ana cara sing objektif kanggo ngukur SLO ing persetujuan utawa bakal ana ora setuju.
Panelusuran Google minangka conto layanan penting sing ora duwe SLA umum: kita pengin kabeh wong nggunakake Panelusuran kanthi efisien, nanging kita durung mlebu kontrak karo jagad iki. Nanging, isih ana akibat yen telusuran ora kasedhiya - ora kasedhiya nyebabake penurunan reputasi kita uga nyuda revenue iklan. Akeh layanan Google liyane, kayata Google for Work, duwe perjanjian tingkat layanan sing jelas karo pangguna. Preduli saka layanan tartamtu wis SLA, iku penting kanggo nemtokake SLI lan SLO lan digunakake kanggo ngatur layanan.
Dadi akeh teori - saiki kanggo pengalaman.
Indikator ing laku
Amarga kita wis nyimpulake manawa penting kanggo milih metrik sing cocog kanggo ngukur tingkat layanan, kepiye saiki sampeyan ngerti metrik sing penting kanggo layanan utawa sistem?
Apa sing sampeyan lan pangguna peduli?
Sampeyan ora perlu nggunakake saben metrik minangka SLI sing bisa dilacak ing sistem ngawasi; Ngerteni apa sing dikarepake pangguna saka sistem bakal mbantu sampeyan milih sawetara metrik. Milih indikator sing akeh banget ndadekake angel fokus ing indikator penting, nalika milih nomer cilik bisa ninggalake potongan gedhe saka sistem sampeyan tanpa dijaga. Biasane kita nggunakake sawetara indikator utama kanggo ngevaluasi lan ngerti kesehatan sistem.
Layanan umume bisa dipérang dadi sawetara bagéan saka syarat-syarat SLI sing cocog karo:
- Sistem front-end khusus, kayata antarmuka telusuran kanggo layanan Shakespeare saka conto kita. Dheweke kudu kasedhiya, ora ana wektu tundha lan duwe bandwidth sing cukup. Patut, pitakonan bisa ditakoni: apa kita bisa nanggapi panjaluk kasebut? Suwene wektu kanggo nanggapi panjaluk kasebut? Carane akeh panjalukan bisa diproses?
- Sistem panyimpenan. Dheweke nganggep latency respon sing kurang, kasedhiyan, lan daya tahan. Pitakonan sing gegandhengan: Suwene wektu maca utawa nulis data? Apa kita bisa ngakses data yen dijaluk? Apa data kasedhiya nalika kita butuh? Deleng Bab 26 Integritas Data: Apa sing Diwaca Apa Sing Sampeyan Tulis kanggo diskusi rinci babagan masalah kasebut.
- Sistem data gedhe kayata pipa pangolahan data gumantung marang throughput lan latensi pangolahan pitakon. Pitakonan sing gegandhengan: Pira data sing diproses? Suwene suwene data kanggo lelungan saka nampa panjalukan kanggo nerbitake respon? (Sawetara bagéan saka sistem bisa uga ana wektu tundha ing tahapan tartamtu.)
Koleksi indikator
Akeh pratondho tingkat layanan sing paling alami diklumpukake ing sisih server, nggunakake sistem ngawasi kayata Borgmon (ndeleng ngisor). ) utawa Prometheus, utawa mung nganalisa log kanthi periodik, ngenali respon HTTP kanthi status 500. Nanging, sawetara sistem kudu dilengkapi koleksi metrik sisih klien, amarga kekurangan pemantauan sisih klien bisa nyebabake ilang sawetara masalah sing mengaruhi pangguna, nanging ora mengaruhi metrik sisih server. Contone, fokus ing latensi respon backend aplikasi tes telusuran Shakespeare kita bisa nyebabake latensi ing sisih pangguna amarga masalah JavaScript: ing kasus iki, ngukur suwene browser kanggo ngolah kaca minangka metrik sing luwih apik.
Agregasi
Kanggo kesederhanaan lan gampang digunakake, kita asring nglumpukake pangukuran mentah. Iki kudu ditindakake kanthi ati-ati.
Sawetara metrik katon prasaja, kaya panyuwunan saben detik, nanging malah pangukuran sing katon langsung iki sacara implisit nglumpukake data saka wektu. Apa pangukuran ditampa sacara khusus sapisan saben detik utawa pangukuran rata-rata saka jumlah panjalukan saben menit? Opsi sing terakhir bisa ndhelikake panjaluk cepet sing luwih dhuwur sing mung sawetara detik. Coba sistem sing serves 200 panjalukan per detik karo nomer malah lan 0 liyane wektu. Konstanta ing wangun nilai rata-rata 100 panjalukan per detik lan kaping pindho beban cepet ora padha. Kajaba iku, rata-rata latensi pitakon bisa uga katon apik, nanging ndhelikake rincian penting: bisa uga akeh pitakon cepet, nanging ana akeh pitakon sing alon.
Umume indikator luwih dideleng minangka distribusi tinimbang rata-rata. Contone, kanggo latensi SLI, sawetara panjalukan bakal diproses kanthi cepet, dene sawetara bakal luwih suwe, kadhangkala luwih suwe. Rata-rata prasaja bisa ndhelikake wektu tundha sing dawa iki. Tokoh kasebut nuduhake conto: sanajan panjaluk khas mbutuhake udakara 50 ms kanggo dilayani, 5% panjaluk 20 kaping luwih alon! Ngawasi lan menehi tandha mung adhedhasar latensi rata-rata ora nuduhake owah-owahan ing prilaku sedina muput, nalika nyatane ana owah-owahan sing katon ing wektu pangolahan sawetara panjalukan (baris paling dhuwur).
Latensi sistem persentil 50, 85, 95, lan 99. Sumbu Y ana ing format logaritma.
Nggunakake persentil kanggo indikator ngidini sampeyan ndeleng wangun distribusi lan ciri-cirine: tingkat persentil sing dhuwur, kayata 99 utawa 99,9, nuduhake nilai paling awon, dene persentil 50 (uga dikenal minangka median) nuduhake negara sing paling kerep. metrik kasebut. Sing luwih akeh panyebaran wektu nanggepi, panjaluk sing luwih dawa bakal mengaruhi pengalaman pangguna. Efek kasebut tambah ing beban dhuwur lan ana antrian. Panaliten pengalaman pangguna nuduhake manawa umume wong seneng sistem sing luwih alon kanthi variasi wektu respon sing dhuwur, mula sawetara tim SRE mung fokus ing skor persentil sing dhuwur, kanthi basis yen prilaku metrik ing persentil 99,9 apik, umume pangguna ora bakal ngalami masalah. .
Cathetan babagan kesalahan statistik
Umume kita luwih seneng nggarap persentil tinimbang rata-rata (rata-rata aritmetika) saka sakumpulan nilai. Iki ngidini kita nimbang nilai sing luwih nyebar, sing asring duwe ciri sing beda (lan luwih menarik) tinimbang rata-rata. Amarga sifat buatan sistem komputasi, nilai metrik asring miring, mula ora ana panjaluk sing bisa nampa respon kurang saka 0 ms, lan wektu entek 1000 ms tegese ora ana respon sing sukses kanthi nilai sing luwih gedhe tinimbang wektu entek. Akibaté, kita ora bisa nampa manawa rata-rata lan median bisa padha utawa cedhak!
Tanpa tes sadurunge, lan kajaba ana asumsi lan perkiraan standar tartamtu, kita ngati-ati supaya ora nyimpulake yen data kita disebarake kanthi normal. Yen distribusi ora kaya sing dikarepake, proses otomatisasi sing ndandani masalah kasebut (umpamane, nalika ndeleng outlier, bakal miwiti maneh server kanthi latensi pangolahan panjaluk sing dhuwur) bisa uga kerep banget utawa ora cukup (loro-lorone ora apik tenan).
Standarisasi indikator
Disaranake standarisasi karakteristik umum kanggo SLI supaya sampeyan ora kudu spekulasi saben wektu. Fitur apa wae sing nyukupi pola standar bisa uga ora kalebu saka spesifikasi SLI individu, contone:
- Interval agregasi: "rata-rata luwih saka 1 menit"
- Wilayah agregasi: "Kabeh tugas ing kluster"
- Sepira kerepe pangukuran ditindakake: "Saben 10 detik"
- Panjaluk apa sing kalebu: "HTTP GET saka proyek pemantauan kothak ireng"
- Kepiye data dipikolehi: "Thanks kanggo pemantauan sing diukur ing server"
- Latensi akses data: "Wektu nganti pungkasan byte"
Kanggo nyimpen gaweyan, nggawe pesawat saka Cithakan SLI bisa digunakake maneh kanggo saben metrik umum; padha uga wis luwih gampang kanggo everyone mangertos apa tegese SLI tartamtu.
Gol ing laku
Miwiti kanthi mikir babagan (utawa nemokake!) Apa sing dikarepake pangguna, dudu apa sing bisa diukur. Asring, apa sing dikarepake pangguna sampeyan angel utawa ora bisa diukur, mula sampeyan bakal nyedhaki kabutuhan. Nanging, yen sampeyan mung miwiti karo apa gampang kanggo ngukur, sampeyan bakal mungkasi karo SLOs kurang migunani. Akibaté, kadhangkala kita nemokake yen pisanan ngenali gol sing dikarepake banjur nggarap indikator tartamtu bisa luwih apik tinimbang milih indikator banjur entuk gol.
Nemtokake gol sampeyan
Kanggo kajelasan maksimal, kudu ditetepake carane SLO diukur lan kahanan sing bener. Contone, kita bisa ngomong ing ngisor iki (baris kapindho padha karo sing pisanan, nanging nggunakake standar SLI):
- 99% (rata-rata luwih saka 1 menit) saka Entuk telpon RPC bakal rampung kurang saka 100ms (diukur ing kabeh server backend).
- 99% Entuk panggilan RPC bakal rampung kurang saka 100ms.
Yen wangun kurva kinerja penting, sampeyan bisa nemtokake sawetara SLO:
- 90% Entuk telpon RPC rampung kurang saka 1 ms.
- 99% Entuk telpon RPC rampung kurang saka 10 ms.
- 99.9% Entuk telpon RPC rampung kurang saka 100 ms.
Yen pangguna sampeyan ngasilake beban kerja sing heterogen: pangolahan akeh (sing pentinge throughput) lan pangolahan interaktif (sing pentinge latensi), bisa uga migunani kanggo nemtokake tujuan sing kapisah kanggo saben kelas muatan:
- 95% panjalukan pelanggan mbutuhake throughput. Setel jumlah panggilan RPC sing ditindakake <1 s.
- 99% klien peduli babagan latensi. Setel jumlah panggilan RPC kanthi lalu lintas <1 KB lan mlaku <10 ms.
Iku ora realistis lan undesirable kanggo nandheske sing SLOs bakal ketemu 100% wektu: iki bisa nyuda jangkah ngenalke fungsi anyar lan penyebaran prajurit, lan mbutuhake solusi larang. Nanging, luwih becik ngidini anggaran kesalahan - persentase downtime sistem sing diidini - lan ngawasi nilai iki saben dina utawa saben minggu. Manajemen senior bisa uga pengin evaluasi saben wulan utawa saben wulan. (Anggaran kesalahan mung minangka SLO kanggo dibandhingake karo SLO liyane.)
Persentase pelanggaran SLO bisa dibandhingake karo anggaran kesalahan (pirsani Bab 3 lan bagean ), kanthi nilai prabédan sing digunakake minangka input kanggo proses sing mutusake kapan ngirim rilis anyar.
Milih nilai target
Milih nilai perencanaan (SLO) dudu kegiatan teknis murni amarga produk lan kapentingan bisnis sing kudu dibayangke ing SLI, SLO (lan bisa uga SLA) sing dipilih. Kajaba iku, informasi bisa uga kudu diijolke babagan masalah sing ana gandhengane karo staf, wektu kanggo pasar, kasedhiyan peralatan, lan pendanaan. SRE kudu dadi bagian saka obrolan iki lan mbantu ngerti risiko lan kelangsungan pilihan sing beda. Kita wis nggawe sawetara pitakonan sing bisa mbantu njamin diskusi sing luwih produktif:
Aja milih gol adhedhasar kinerja saiki.
Nalika ngerti kekuwatan lan watesan sistem penting, adaptasi metrik tanpa alesan bisa ngalangi sampeyan njaga sistem kasebut: mbutuhake upaya heroik kanggo nggayuh tujuan sing ora bisa digayuh tanpa desain ulang sing signifikan.
Dadi prasaja
Petungan SLI Komplek bisa ndhelikake owah-owahan ing kinerja sistem lan nggawe harder kanggo nemokake sabab saka masalah.
Nyingkiri mutlak
Nalika nggodho duwe sistem sing bisa nangani beban sing terus berkembang tanpa nambah latensi, syarat iki ora realistis. Sistem sing nyedhaki cita-cita kasebut bakal mbutuhake akeh wektu kanggo ngrancang lan mbangun, bakal larang kanggo operate, lan bakal apik banget kanggo pangarepan pangguna sing bakal nindakake apa wae sing kurang.
Gunakake minangka sawetara SLOs sabisa
Pilih jumlah SLO sing cukup kanggo njamin jangkoan apik saka atribut sistem. Nglindhungi SLO sampeyan milih: Yen sampeyan ora bisa menang pitakonan bab prioritas dening nemtokake SLO tartamtu, iku mbokmenawa ora worth considering SLO sing. Nanging, ora kabeh atribut sistem cocog karo SLO: angel ngetung tingkat kesenengan pangguna nggunakake SLO.
Aja nguber kasampurnan
Sampeyan bisa tansah nyaring definisi lan gol saka SLOs liwat wektu nalika sampeyan sinau liyane babagan prilaku sistem ing mbukak. Iku luwih apik kanggo miwiti karo goal ngambang sing bakal nyaring liwat wektu saka milih goal kebacut ketat sing kudu anteng nalika sampeyan nemokake iku unattainable.
SLO bisa lan kudu dadi pembalap utama ing prioritizing karya kanggo SREs lan pangembang produk amarga padha nggambarake badhan kanggo pangguna. SLO sing apik minangka alat penegakan sing migunani kanggo tim pangembangan. Nanging SLO sing dirancang kanthi apik bisa nyebabake karya boros yen tim kasebut nggawe upaya heroik kanggo entuk SLO sing agresif banget, utawa produk sing ora apik yen SLO kurang. SLO minangka pengungkit sing kuat, gunakake kanthi wicaksana.
Ngontrol pangukuran sampeyan
SLI lan SLO minangka unsur kunci sing digunakake kanggo ngatur sistem:
- Monitor lan ngukur sistem SLI.
- Bandingake SLI kanggo SLO lan mutusake yen tumindak dibutuhake.
- Yen tumindak dibutuhake, pikirake apa sing kudu ditindakake kanggo nggayuh tujuan kasebut.
- Rampungake tumindak iki.
Contone, yen langkah 2 nuduhake yen panjalukan wis entek lan bakal ngilangi SLO ing sawetara jam yen ora ana sing ditindakake, langkah 3 bisa uga nliti hipotesis manawa server kasebut kaiket CPU lan nambah server liyane bakal nyebarake beban kasebut. Tanpa SLO, sampeyan ora bakal ngerti yen (utawa kapan) tumindak.
Setel SLO - banjur pangarepan pangguna bakal disetel
Nerbitake SLO nyetel pangarepan pangguna kanggo prilaku sistem. Pangguna (lan pangguna potensial) kerep pengin ngerti apa sing bakal dikarepake saka layanan kanggo mangerteni apa iku cocok kanggo digunakake. Contone, wong sing pengin nggunakake situs web enggo bareng foto bisa uga pengin ngindhari nggunakake layanan sing njanjeni umur dawa lan biaya sing murah kanggo ngganti kasedhiyan sing rada kurang, sanajan layanan sing padha bisa uga cocog kanggo sistem manajemen arsip.
Kanggo nyetel pangarepan sing nyata kanggo pangguna, gunakake siji utawa loro taktik ing ngisor iki:
- Njaga wates safety. Gunakake SLO internal sing luwih ketat tinimbang sing diiklanake kanggo pangguna. Iki bakal menehi sampeyan kesempatan kanggo nanggepi masalah sadurunge katon externally. Buffer SLO uga ngidini sampeyan duwe wates safety nalika nginstal rilis sing mengaruhi kinerja sistem lan mesthekake yen sistem gampang kanggo njaga tanpa kudu gawe frustasi pangguna karo downtime.
- Aja ngluwihi pangarepan pangguna. Pangguna adhedhasar apa sing sampeyan tawakake, dudu apa sing sampeyan ucapake. Yen kinerja layanan sampeyan luwih apik tinimbang SLO sing wis kasebut, pangguna bakal ngandelake kinerja saiki. Sampeyan bisa ngindhari katergantungan kanthi sengaja mateni sistem utawa mbatesi kinerja ing beban sing entheng.
Ngerteni carane sistem nyukupi pangarepan mbantu mutusake apa arep nandur modal kanggo nyepetake sistem lan nggawe luwih gampang diakses lan tahan banting. Utawa, yen layanan apik banget, sawetara wektu staf kudu digunakake kanggo prioritas liyane, kayata mbayar utang teknis, nambah fitur anyar, utawa ngenalake produk anyar.
Persetujuan ing laku
Nggawe SLA mbutuhake tim bisnis lan hukum kanggo nemtokake akibat lan paukuman kanggo nglanggar. Peran SRE yaiku mbantu wong-wong mau ngerti tantangan-tantangan sing bisa ditindakake nalika ketemu SLO sing ana ing SLA. Umume rekomendasi kanggo nggawe SLO uga ditrapake kanggo SLA. Iku wicaksana kanggo konservatif ing apa sing dijanjekake pangguna amarga luwih akeh sampeyan duwe, luwih angel ngganti utawa mbusak SLA sing katon ora wajar utawa angel ditemoni.
Matur nuwun kanggo maca terjemahan nganti pungkasan. Langganan saluran telegram babagan pemantauan и .
Source: www.habr.com