SRE (Téknik Reliabilitas Situs) mangrupikeun pendekatan pikeun mastikeun kasadiaan proyék wéb. Éta dianggap kerangka pikeun DevOps sareng ngobrolkeun kumaha carana ngahontal kasuksésan dina nerapkeun prakték DevOps. Tarjamahan dina artikel ieu buku ti Google. Kuring nyiapkeun tarjamahan ieu sorangan sareng ngandelkeun pangalaman kuring sorangan dina ngartos prosés ngawaskeun. Dina saluran telegram и я публиковал также перевод 6 главы этой же книги о целях уровня обслуживания.
Tarjamahan ku ucing. Senang maca!
Teu mungkin pikeun ngatur jasa upami teu aya pamahaman naon indikator saleresna penting sareng kumaha ngukur sareng meunteun aranjeunna. Pikeun tujuan ieu, urang nangtukeun tur nyadiakeun tingkat nu tangtu jasa ka pamaké urang, paduli naha maranéhna ngagunakeun salah sahiji API internal urang atawa produk umum.
Urang ngagunakeun intuisi, pangalaman, jeung pamahaman kahayang pamaké pikeun ngarti Service Level Indikator (SLIs), Service Level Tujuan (SLOs), sarta Service Level Agreements (SLAs). Diménsi ieu ngajelaskeun métrik utama anu urang hoyong monitor sareng anu bakal diréaksikeun upami urang henteu tiasa nyayogikeun kualitas jasa anu dipiharep. Pamustunganana, milih métrik anu leres ngabantosan pituduh tindakan anu leres upami aya anu salah, sareng ogé masihan kapercayaan tim SRE dina kasehatan jasa.
Bab ieu ngajelaskeun pendekatan anu kami anggo pikeun merangan masalah modél métrik, pamilihan métrik, sareng analisis métrik. Kalolobaan katerangan bakal tanpa conto, jadi urang bakal ngagunakeun layanan Shakespeare dijelaskeun dina conto palaksanaan na (neangan karya Shakespeare urang) pikeun ngagambarkeun titik utama.
Terminologi tingkat layanan
Seueur pamiarsa sigana wawuh sareng konsép SLA, tapi istilah SLI sareng SLO pantes definisi ati-ati sabab sacara umum istilah SLA overloaded sareng gaduh sababaraha harti gumantung kana kontéksna. Pikeun kajelasan, urang hoyong misahkeun nilai ieu.
indikator
SLI mangrupikeun indikator tingkat jasa-ukuran kuantitatif anu didefinisikeun sacara saksama tina hiji aspék tingkat jasa anu disayogikeun.
Kanggo sabagéan ageung jasa, konci SLI dianggap latency pamundut - sabaraha lila waktu nu diperlukeun pikeun balik respon kana pamundut a. SLIs umum lianna kaasup laju kasalahan, mindeng dikedalkeun salaku fraksi sadaya requests narima, sarta throughput sistem, biasana diukur dina requests per detik. Pangukuran sering dijumlahkeun: data atah dikumpulkeun heula teras dirobih janten tingkat parobihan, rata-rata, atanapi persentil.
В идеале, SLI непосредственно измеряет уровень обслуживания, представляющий интерес, но иногда для измерения доступна только связанная метрика, потому что первоначальную трудно получить или интерпретировать. Например, задержки на стороне клиента часто является более подходящей метрикой, но бывает, что измерение задержки возможно только на сервере.
Другим видом SLI, важным для SRE, является доступность или часть времени, в течение которого сервисом можно пользоваться. Часто определяется как доля успешных запросов, иногда называемых выработкой. (Продолжительность срока службы — вероятность того, что данные будут храниться в течение длительного периода времени, ещё важна и для систем хранения данных.) Хотя доступность на 100% невозможна, доступность близкая к 100% часто достижима, значения доступности выражаются в виде количества «девяток» процента доступности. Например, доступность 99% и 99,999% может быть обозначена как «2 девятки» и «5 девяток». Текущая заявленная цель доступности Google Compute Engine — «три с половиной девятки» или 99,95%.
gol
SLO mangrupikeun tujuan tingkat jasa: nilai target atanapi rentang nilai pikeun tingkat jasa anu diukur ku SLI. Nilai normal pikeun SLO nyaéta "SLI ≤ Target" atanapi "Wates Handap ≤ SLI ≤ Wates Upper". Contona, urang bisa mutuskeun yén urang bakal balik hasil teangan Shakespeare "gancang" ku netepkeun SLO ka latency query pilarian rata-rata kirang ti 100 milliseconds.
Milih SLO anu leres mangrupikeun prosés anu rumit. Kahiji, anjeun teu bisa salawasna milih nilai husus. Pikeun pamundut HTTP asup éksternal kana layanan anjeun, métrik Query Per Second (QPS) utamana ditangtukeun ku kahayang pamaké anjeun nganjang ka layanan anjeun, sarta anjeun teu bisa nyetél SLO pikeun éta.
Di sisi anu sanés, anjeun tiasa nyarios yén anjeun hoyong rata-rata latency pikeun tiap pamundut kirang ti 100 milidetik. Netepkeun tujuan sapertos kitu tiasa maksa anjeun nyerat frontend anjeun kalayan latency rendah atanapi mésér alat anu nyayogikeun latensi sapertos kitu. (100 milliseconds écés mangrupa angka sawenang, tapi leuwih hade mun boga angka latency malah handap. Aya bukti nunjukkeun yén speeds gancang leuwih hade tinimbang speeds slow, sarta latency dina ngolah requests pamaké luhureun nilai tangtu sabenerna maksa jalma pikeun ngajauhan. tina jasa anjeun.)
Sakali deui, ieu langkung ambigu ti anu sigana sigana dina pandangan kahiji: anjeun henteu kedah ngaleungitkeun QPS tina itungan. Kanyataan yén QPS sareng latency aya hubunganana pisan: QPS anu langkung luhur sering nyababkeun latensi anu langkung luhur, sareng jasa biasana ngalaman panurunan anu seukeut dina pagelaran nalika aranjeunna ngahontal ambang beban anu tangtu.
Milih sareng nyebarkeun SLO netepkeun ekspektasi pangguna ngeunaan kumaha jasa éta bakal jalan. Strategi ieu bisa ngurangan keluhan unfounded ngalawan nu boga jasa, kayaning kinerja slow. Tanpa SLO anu eksplisit, pangguna sering nyiptakeun ekspektasi sorangan ngeunaan kinerja anu dipikahoyong, anu henteu aya hubunganana sareng pendapat jalma anu ngarancang sareng ngatur jasa. kaayaan ieu bisa ngakibatkeun ekspektasi inflated tina jasa, nalika pamaké salah yakin yén layanan bakal leuwih diaksés ti sabenerna, sarta ngabalukarkeun mistrust lamun pamaké yakin yén sistem kirang dipercaya ti eta sabenerna.
Pasatujuan
Kasapukan tingkat layanan nyaéta kontrak eksplisit atawa implisit jeung pamaké anjeun nu ngawengku konsékuansi tina minuhan (atawa teu minuhan) SLOs aranjeunna ngandung. Konsékuansi anu paling gampang dipikawanoh nalika aranjeunna finansial-diskon atawa denda-tapi aranjeunna tiasa nyandak bentuk sejen. Cara anu gampang pikeun ngobrol ngeunaan bédana antara SLO sareng SLA nyaéta naroskeun "naon anu bakal kajadian upami SLO henteu kapendak?" Upami teu aya akibat anu jelas, anjeun ampir pasti ningali SLO.
SRE ilaharna henteu kalibet dina nyieun SLA sabab SLAs raket dihijikeun jeung kaputusan bisnis jeung produk. SRE, kumaha oge, aub dina mantuan pikeun mitigate konsékuansi tina gagal SLOs. Éta ogé bisa mantuan nangtukeun SLI: Jelas, kudu aya hiji cara obyektif pikeun ngukur SLO dina perjangjian atawa bakal aya kaayaan teu satuju.
Pilarian Google mangrupikeun conto jasa penting anu henteu ngagaduhan SLA umum: kami hoyong sadayana nganggo Search sabisa-gancang, tapi kami henteu acan nandatanganan kontrak sareng dunya. Sanajan kitu, masih aya konsékuansi lamun pilarian teu sadia - unavailability ngakibatkeun turunna reputasi urang ogé ngurangan sharing iklan. Seueur jasa Google anu sanés, sapertos Google for Work, gaduh perjanjian tingkat jasa anu eksplisit sareng pangguna. Paduli naha layanan tinangtu boga SLA, hal anu penting pikeun nangtukeun SLI na SLO sarta ngagunakeun éta pikeun ngatur jasa.
Так много теории — теперь к опыту.
Indikator dina prakna
Nunjukkeun yen kami geus menyimpulkan yén hal anu penting pikeun milih metrics luyu pikeun ngukur tingkat layanan, kumaha anjeun ayeuna nyaho metrics nu penting pikeun layanan atawa sistem?
Naon anu anjeun sareng pamaké anjeun paduli?
Anjeun teu kedah nganggo unggal métrik salaku SLI anu tiasa dilacak dina sistem ngawaskeun; Ngartos naon anu dipikahoyong ku pangguna tina sistem bakal ngabantosan anjeun milih sababaraha métrik. Milih loba teuing indikator ngajadikeun hésé difokuskeun indikator penting, bari milih sajumlah leutik bisa ninggalkeun sakumpulan badag tina sistem Anjeun unattended. Kami biasana ngagunakeun sababaraha indikator konci pikeun meunteun sareng ngartos kasehatan sistem.
Jasa umumna tiasa dirobih janten sababaraha bagian dina hal SLI anu relevan pikeun aranjeunna:
- Sistim hareup-tungtung custom, kayaning interfaces pilarian pikeun layanan Shakespeare tina conto urang. Éta kedah sayogi, teu aya telat sareng gaduh bandwidth anu cekap. Sasuai, patarosan tiasa ditaroskeun: naha urang tiasa ngabales pamenta? Sabaraha lami kanggo ngabales pamundut? Sabaraha requests bisa diolah?
- Sistem gudang. Aranjeunna ngahargaan latency respon low, kasadiaan, sarta durability. Patarosan anu aya hubunganana: Sabaraha lami waktos maca atanapi nyerat data? Naha urang tiasa ngaksés data upami dipénta? Naha datana sayogi nalika urang peryogi? Tingali Bab 26 Integritas Data: Naon Anu Anjeun Baca Nyaeta Anu Anjeun Tulis pikeun sawala lengkep ngeunaan masalah ieu.
- Sistem data ageung sapertos pipa ngolah data ngandelkeun throughput sareng latency ngolah pamundut. Patarosan patali: Sabaraha data anu diolah? Sabaraha lami waktos kanggo ngarambat data tina nampi pamundut dugi ka ngaluarkeun réspon? (Sababaraha bagéan sistem ogé tiasa ngalambatkeun dina tahapan anu tangtu.)
Kumpulan indikator
Seueur indikator tingkat jasa anu paling alami dikumpulkeun di sisi server, nganggo sistem ngawaskeun sapertos Borgmon (tingali di handap). ) atawa Prometheus, atawa ngan saukur périodik analisa log, ngaidentipikasi réspon HTTP kalawan status 500. Sanajan kitu, sababaraha sistem kudu dilengkepan kumpulan metrics sisi klien, saprak kurangna ngawaskeun klien-sisi bisa ngakibatkeun leungit sababaraha masalah anu mangaruhan. pamaké, tapi teu mangaruhan metrics server-sisi. Contona, fokus dina latency respon backend tina aplikasi tés pilarian Shakespeare urang bisa ngakibatkeun latency di sisi pamaké alatan masalah JavaScript: dina hal ieu, ngukur sabaraha lila browser pikeun ngolah kaca mangrupakeun métrik hadé.
Agregasi
Pikeun kesederhanaan sareng gampang dianggo, urang sering ngahijikeun pangukuran atah. Ieu kudu dilakukeun taliti.
Некоторые показатели кажутся простыми, например, количество запросов в секунду, но даже это, очевидное, прямое измерение неявно агрегирует данные по времени. Является ли измерение полученным конкретно один раз в секунду или это измерение усреднено по количеству запросов в течение минуты? Последний вариант может скрыть гораздо более высокое мгновенное количество запросов, которые сохраняются всего на несколько секунд. Рассмотрим систему, которая обслуживает 200 запросов в секунду с четными номерами и 0 в остальное время. Константа в виде среднего значения в 100 запросов в секунду и вдвое большая мгновенная нагрузка — совсем не одно и то же. Точно так же усреднение задержек запросов может показаться привлекательным, но скрывает важную деталь: вполне возможно, что большинство запросов будут быстрыми, но среди них окажется много запросов, которые будут медленными.
Kaseueuran indikator langkung saé dianggap salaku distribusi tinimbang rata-rata. Contona, pikeun latency SLI, sababaraha requests bakal diprosés gancang, bari sababaraha bakal salawasna nyandak deui, kadang leuwih lila. A rata basajan bisa nyumputkeun ieu Nepi panjang. Angka ieu nunjukkeun conto: sanaos pamenta anu biasa nyandak kirang langkung 50 ms pikeun ngalayanan, 5% tina pamundut 20 kali langkung laun! Ngawaskeun sareng ngageterkeun ngan ukur dina latency rata-rata henteu nunjukkeun parobihan paripolah sapopoe, nalika kanyataanna aya parobahan anu nyata dina waktos ngolah sababaraha pamundut (garis paling luhur).
50, 85, 95, jeung 99 persentil Sistim latency. Sumbu Y aya dina format logaritmik.
Ngagunakeun persentil pikeun indikator ngidinan Anjeun pikeun ningali bentuk sebaran sarta ciri na: tingkat persentil luhur, kayaning 99 atawa 99,9, nembongkeun nilai awon, sedengkeun 50 persentil (ogé katelah median) nembongkeun kaayaan paling sering. métrik. Langkung ageung panyebaran waktos réspon, paménta anu langkung panjang mangaruhan pangalaman pangguna. Pangaruhna ningkat dina beban anu luhur sareng ku ayana antrian. Panaliti pangalaman pangguna nunjukkeun yén jalma umumna resep sistem anu langkung laun sareng varians waktos réspon anu luhur, ku kituna sababaraha tim SRE ngan ukur fokus kana skor persentil anu luhur, dina dasar yén upami paripolah métrik dina persentil 99,9 saé, kalolobaan pangguna moal ngalaman masalah. .
Catetan dina kasalahan statistik
Обычно мы предпочитаем работать с процентилями, а не со средним (средним арифметическим) набором значений. Это позволяет рассматривать более дисперсные значения, которые часто имеют существенно отличающиеся (и более интересные) характеристики, чем среднее. Из-за искусственного характера вычислительных систем значения метрик часто искажаются, например, ни один запрос не может получить ответ менее чем за 0 мс, а тайм-аут в 1000 мс означает, что успешных ответов со значениями, превышающими таймаут, не может быть. В результате мы не можем принять, что среднее и медианы могут быть одинаковы или близки друг к другу!
Tanpa tés sateuacana, sareng upami asumsi sareng perkiraan standar anu tangtu tahan, urang ati-ati supados henteu nyimpulkeun yén data urang sebaran normal. Upami distribusina henteu sapertos anu diharapkeun, prosés otomasi anu ngalereskeun masalahna (contona, nalika ningali outlier, éta bakal ngamimitian deui server kalayan latency pamrosésan paménta anu luhur) tiasa sering teuing atanapi henteu sering cukup (duanana henteu. saé pisan).
Standarisasi indikator
Kami ngarékoméndasikeun standarisasi ciri umum pikeun SLI ku kituna anjeun teu kudu speculate ngeunaan eta unggal waktu. Fitur naon waé anu nyugemakeun pola standar tiasa dikaluarkeun tina spésifikasi SLI individu, contona:
- Interval agregasi: "rata-rata leuwih ti 1 menit"
- Wewengkon agregasi: "Sadaya tugas dina kluster"
- Sakumaha sering pangukuran dilaksanakeun: "Unggal 10 detik"
- Paménta naon anu diaktipkeun: "HTTP GET tina padamelan ngawaskeun kotak hideung"
- Как данные получены: «Благодаря нашему мониторингу, измеренному на сервере»,
- Задержка доступа к данным: «Время до последнего байта»
Pikeun nyimpen usaha , nyieun hiji set reusable SLI template pikeun tiap métrik umum; aranjeunna ogé ngagampangkeun pikeun sadayana ngartos naon hartosna SLI tangtu.
Tujuan dina prakna
Начните с размышлений (или узнайте!), о чем заботятся ваши пользователи, а не о том, что вы можете измерить. Часто то, что беспокоит ваших пользователей, трудно или невозможно измерить, так что в итоге вы приблизитесь к их потребностям. Однако, если вы просто начнете с того, что легко измерить, вы получите менее полезные SLO. В результате мы иногда обнаруживали, что первоначальное определение желаемых целей и дальнейшая работа с конкретными индикаторами работает лучше, чем выбор индикаторов, а затем достижение целей.
Nangtukeun tujuan
Для максимальной ясности, должно быть определено как измеряются SLO и условия, при которых они действительны. Например, мы можем сказать следующее (вторая строка такая же, как первая, но использует SLI-значения по умолчанию):
- 99% (rata-rata langkung ti 1 menit) Telepon Kéngingkeun RPC bakal réngsé dina kirang ti 100ms (diukur dina sadaya server backend).
- 99% Telepon Kéngingkeun RPC bakal réngsé dina kirang ti 100ms.
Upami bentuk kurva kinerja penting, anjeun tiasa netepkeun sababaraha SLO:
- 90% Telepon Kéngingkeun RPC réngsé kirang ti 1 ms.
- 99% Telepon Kéngingkeun RPC réngsé kirang ti 10 ms.
- 99.9% Telepon Kéngingkeun RPC réngsé kirang ti 100 ms.
Lamun pamaké anjeun ngahasilkeun beban gawé hétérogén: processing bulk (nu throughput penting) jeung processing interaktif (nu latency penting), meureun aya worthwhile nangtukeun tujuan misah pikeun tiap kelas beban:
- 95% tina requests customer merlukeun throughput. Setel jumlah telepon RPC anu dilaksanakeun <1 s.
- 99% klien paduli latency. Setel itungan telepon RPC kalayan lalu lintas <1 KB sareng jalan <10 mdet.
Нереалистично и нежелательно настаивать на том, что SLO будут выполняться в 100% случаев: это может снизить темпы ввода нового функционала и деплоймента, потребовать дорогостоящих решений. Вместо этого лучше разрешить бюджет ошибок — долю разрешённого простоя системы и отслеживать это значение ежедневно или еженедельно. Возможно, высшее руководство будет хотеть ежемесячную или ежеквартальную оценку. (Бюджет ошибок — это просто SLO для сравнения с другим SLO).
Persentase pelanggaran SLO tiasa dibandingkeun sareng anggaran kasalahan (tingali Bab 3 sareng bagian ), kalayan nilai bédana dipaké salaku input kana prosés nu mutuskeun iraha bade nyebarkeun release anyar.
Выбор плановых значений
Milih nilai perencanaan (SLOs) sanes kagiatan teknis murni kusabab produk jeung kapentingan bisnis nu kudu reflected dina SLIs dipilih, SLOs (jeung kamungkinan SLAs). Kitu ogé, inpormasi panginten kedah ditukeurkeun ngeunaan masalah anu aya hubunganana sareng staf, waktos ka pasar, kasadiaan alat, sareng pembiayaan. SRE kedah janten bagian tina paguneman ieu sareng ngabantosan ngartos résiko sareng viability tina pilihan anu béda. Kami parantos nyayogikeun sababaraha patarosan anu tiasa ngabantosan diskusi anu langkung produktif:
Ulah milih tujuan dumasar kana kinerja ayeuna.
Nalika ngartos kakuatan sareng wates sistem penting, adaptasi métrik tanpa alesan tiasa ngahalangan anjeun pikeun ngajaga sistem: éta bakal meryogikeun usaha heroik pikeun ngahontal tujuan anu teu tiasa dihontal tanpa desain ulang anu signifikan.
Будьте проще
Сложные расчёты SLI могут скрыть изменения в производительности системы и усложнят поиск причины проблемы.
Nyingkahan mutlak
Sanaos pikabitaeun gaduh sistem anu tiasa ngadamel beban anu teu aya watesna tanpa ningkatkeun latency, syarat ieu henteu realistis. Sistem anu ngadeukeutan cita-cita sapertos kitu sigana bakal meryogikeun seueur waktos pikeun ngarancang sareng ngawangun, bakal mahal pikeun dioperasikeun, sareng bakal saé teuing pikeun ekspektasi pangguna anu bakal ngalakukeun naon waé anu kirang.
Paké saloba mungkin SLOs
Pilih jumlah cukup SLOs pikeun mastikeun sinyalna alus tina atribut sistem. Nangtayungan SLO anjeun milih: Lamun anjeun pernah bisa meunang hiji argumen ngeunaan prioritas ku nangtukeun hiji SLO husus, éta meureun teu patut mertimbangkeun SLO nu. Sanajan kitu, teu sakabeh atribut sistem anu amenable mun SLOs: hese ngitung tingkat delight pamaké ngagunakeun SLOs.
Ulah ngudag kasampurnaan
Anjeun salawasna tiasa nyaring definisi sareng tujuan SLO dina waktosna nalika anjeun diajar langkung seueur ngeunaan paripolah sistem dina beban. Langkung sae pikeun ngamimitian ku tujuan ngambang anu anjeun bakal nyaring kana waktosna tibatan milih tujuan anu ketat pisan anu kedah santai nalika anjeun mendakan éta henteu tiasa dicapai.
SLO tiasa sareng kedah janten panggerak konci dina prioritas padamelan pikeun SRE sareng pamekar produk sabab ngagambarkeun perhatian pikeun pangguna. SLO anu saé mangrupikeun alat penegak anu mangpaat pikeun tim pamekaran. Tapi hiji SLO dirancang kirang bisa ngakibatkeun karya boros lamun tim nyieun usaha heroik pikeun ngahontal hiji SLO overly agrésif, atawa produk goréng lamun SLO teuing low. SLO mangrupakeun uas kuat, make eta bijaksana.
Kontrol pangukuran anjeun
SLI sareng SLO mangrupikeun elemen konci anu dianggo pikeun ngatur sistem:
- Monitor jeung ngukur sistem SLI.
- Bandingkeun SLI mun SLO jeung mutuskeun lamun aksi diperlukeun.
- Upami tindakan diperyogikeun, terangkeun naon anu kedah kajantenan pikeun ngahontal tujuan.
- Lengkepan tindakan ieu.
Salaku conto, upami léngkah 2 nunjukkeun yén pamundutna parantos waktosna sareng bakal ngarobih SLO dina sababaraha jam upami teu aya anu dilakukeun, léngkah 3 tiasa ngalibetkeun uji hipotésis yén server kabeungkeut CPU sareng nambihan langkung seueur server bakal ngadistribusikaeun beban. Tanpa SLO, anjeun moal terang upami (atanapi iraha) nyandak tindakan.
Atur SLO - lajeng ekspektasi pamaké bakal disetel
Nerbitkeun hiji SLO susunan ekspektasi pamaké pikeun kabiasaan sistem. Pamaké (sareng pangguna poténsial) sering hoyong terang naon anu diarepkeun tina jasa pikeun ngartos naha éta cocog pikeun dianggo. Salaku conto, jalma-jalma anu hoyong nganggo situs wéb babagi poto panginten hoyong nyingkahan ngagunakeun jasa anu ngajangjikeun umur panjang sareng béaya rendah kanggo tukeran kasadiaan anu rada kirang, sanaos jasa anu sami tiasa cocog pikeun sistem manajemén rékaman arsip.
Pikeun nyetel ekspektasi realistis pikeun pamaké anjeun, make salah sahiji atawa duanana taktik ieu:
- Ngajaga margin kaamanan. Anggo SLO internal anu langkung ketat tibatan anu diémbarkeun ka pangguna. Ieu bakal masihan anjeun kasempetan pikeun ngaréaksikeun masalah sateuacan aranjeunna katingali sacara éksternal. Panyangga SLO ogé ngamungkinkeun anjeun gaduh margin kaamanan nalika masang sékrési anu mangaruhan kinerja sistem sareng mastikeun yén sistem éta gampang dijaga tanpa kedah ngagagalkeun pangguna kalayan downtime.
- Ulah ngaleuwihan ekspektasi pamaké. Pamaké dumasar kana naon anu anjeun tawarkeun, sanés naon anu anjeun carioskeun. Lamun kinerja sabenerna layanan anjeun leuwih hadé ti SLO dinyatakeun, pamaké bakal ngandelkeun kinerja ayeuna. Anjeun tiasa ngahindarkeun katergantungan kaleuleuwihan ku ngahaja mareuman sistem atanapi ngabatesan kinerja dina beban anu hampang.
Ngartos kumaha sistem nyumponan ekspektasi ngabantosan mutuskeun pikeun investasi dina ngagancangkeun sistem sareng ngajantenkeun langkung diaksés sareng tahan banting. Alternatipna, lamun jasa a ngajalankeun teuing alus, sababaraha waktu staf kudu spent dina prioritas séjén, kayaning Mayar off hutang teknis, nambahkeun fitur anyar, atawa ngenalkeun produk anyar.
Соглашения на практике
Nyiptakeun SLA butuh tim bisnis sareng hukum pikeun ngartikeun akibat sareng hukuman pikeun ngalanggar éta. Peran SRE nyaéta ngabantosan aranjeunna ngartos tantangan anu dipikaresep dina nyumponan SLO anu aya dina SLA. Kalolobaan saran pikeun nyieun SLO ogé lumaku pikeun SLAs. Éta wijaksana pikeun konservatif dina naon anu anjeun janjikeun ka pangguna sabab langkung seueur anjeun gaduh, langkung hese ngarobih atanapi ngahapus SLA anu sigana teu masuk akal atanapi sesah dipendakan.
Hatur nuhun pikeun maca tarjamahan nepi ka ahir. Ngalanggan saluran telegram kuring ngeunaan monitoring и .
sumber: www.habr.com