SRE (Сайтын найдвартай байдлын инженерчлэл) нь вэб төслүүдийг хүртээмжтэй болгох арга юм. Энэ нь DevOps-ийн хүрээ гэж тооцогддог бөгөөд DevOps практикийг хэрхэн амжилттай хэрэгжүүлэх талаар өгүүлдэг. Энэ нийтлэлийг орчуулав номууд Google-ээс. Би энэ орчуулгыг өөрөө бэлтгэсэн бөгөөд хяналтын үйл явцыг ойлгох өөрийн туршлагад тулгуурласан. Телеграм суваг дээр и Би мөн үйлчилгээний түвшний зорилгын тухай мөн номын 6-р бүлгийн орчуулгыг хэвлүүлсэн.
Муурны орчуулга. Уншихыг сайхан өнгөрүүлээрэй!
Үнэн хэрэгтээ ямар үзүүлэлтүүд чухал болохыг, тэдгээрийг хэрхэн хэмжих, үнэлэх талаар ойлголтгүй бол үйлчилгээг удирдах боломжгүй юм. Үүний тулд бид хэрэглэгчдэдээ манай дотоод API эсвэл нийтийн бүтээгдэхүүнийг ашигладаг эсэхээс үл хамааран тодорхой түвшний үйлчилгээг тодорхойлж, үзүүлдэг.
Бид өөрсдийн зөн совин, туршлага, Үйлчилгээний түвшний шалгуур үзүүлэлт (SLIs), Үйлчилгээний түвшний зорилтууд (SLOs), Үйлчилгээний түвшний гэрээг (SLAs) ойлгох гэсэн хэрэглэгчдийн хүсэл эрмэлзэлийн талаарх ойлголтыг ашигладаг. Эдгээр хэмжигдэхүүнүүд нь бидний хянахыг хүсч буй гол хэмжүүрүүдийг тодорхойлдог бөгөөд хэрэв бид хүлээгдэж буй үйлчилгээний чанарыг хангаж чадахгүй бол хариу үйлдэл үзүүлэх болно. Эцсийн эцэст, зөв хэмжүүрийг сонгох нь ямар нэг зүйл буруу болвол зөв үйлдлүүдийг удирдан чиглүүлэхэд тусалдаг ба SRE-ийн багт үйлчилгээний эрүүл мэндэд итгэх итгэлийг өгдөг.
Энэ бүлэг нь хэмжүүрийн загварчлал, хэмжүүр сонголт, хэмжүүр шинжилгээний асуудлуудтай тэмцэхэд бидний ашигладаг арга барилыг тайлбарладаг. Тайлбарын ихэнх нь жишээгүй байх тул бид үндсэн санааг харуулахын тулд түүний хэрэгжилтийн жишээнд (Шекспирийн бүтээлүүдийг хайх) тайлбарласан Шекспирийн үйлчилгээг ашиглах болно.
Үйлчилгээний түвшний нэр томъёо
Олон уншигчид SLA гэсэн ойлголтыг мэддэг байх магадлалтай боловч SLI болон SLO гэсэн нэр томьёо нь ерөнхийдөө SLA гэдэг нэр томьёо нь хэт ачаалалтай бөгөөд контекстээс хамааран хэд хэдэн утгатай байдаг тул нарийн тодорхойлолтыг өгөх ёстой. Тодорхой болгохын тулд бид эдгээр утгыг салгахыг хүсч байна.
Шалгуур үзүүлэлтүүд
SLI нь үйлчилгээний түвшний үзүүлэлт бөгөөд үзүүлж буй үйлчилгээний түвшний аль нэг талыг нарийн тодорхойлсон тоон хэмжүүр юм.
Ихэнх үйлчилгээний хувьд гол SLI нь хүсэлтийн хоцрогдол гэж тооцогддог - хүсэлтийн хариуг буцаахад хэр хугацаа шаардагдах вэ. Бусад нийтлэг SLI-д ихэвчлэн хүлээн авсан бүх хүсэлтийн нэг хэсэг болгон илэрхийлэгддэг алдааны түвшин, секундэд ирдэг хүсэлтээр хэмжигддэг системийн нэвтрүүлэх чадвар багтдаг. Хэмжилтийг ихэвчлэн нэгтгэдэг: түүхий өгөгдлийг эхлээд цуглуулж, дараа нь өөрчлөлтийн хурд, дундаж эсвэл хувь болгон хувиргадаг.
Хамгийн тохиромжтой нь SLI нь сонирхсон үйлчилгээний түвшинг шууд хэмждэг боловч эх хувийг олж авах эсвэл тайлбарлахад хэцүү байдаг тул заримдаа зөвхөн холбогдох хэмжүүрийг хэмжих боломжтой байдаг. Жишээлбэл, үйлчлүүлэгчийн хоцролт нь ихэвчлэн илүү тохиромжтой хэмжигдэхүүн байдаг ч хоцролтыг зөвхөн сервер дээр хэмжих тохиолдол байдаг.
SRE-д чухал ач холбогдолтой SLI-ийн өөр нэг төрөл бол хүртээмж буюу үйлчилгээг ашиглах боломжтой хугацаа юм. Ихэнхдээ амжилттай хүсэлтийн хувь гэж тодорхойлогддог бөгөөд заримдаа гарц гэж нэрлэдэг. (Насан туршдаа—өгөгдөл удаан хугацаанд хадгалагдах магадлал—өгөгдөл хадгалах системд мөн чухал байдаг.) Хэдийгээр 100% хүртээмжтэй байх боломжгүй ч 100% орчим хүртээмжтэй байх нь ихэвчлэн боломжтой байдаг; бэлэн байдлын утгыг дараах байдлаар илэрхийлдэг. "есөн"-ийн тоо » бэлэн байдлын хувь. Жишээлбэл, 99% ба 99,999% хүртээмжийг "2 ес", "5 ес" гэж тэмдэглэж болно. Google Compute Engine-ийн одоогийн тодорхойлсон бэлэн байдлын зорилго нь "гурван ес хагас" буюу 99,95% байна.
Зорилтууд
SLO нь үйлчилгээний түвшний зорилго юм: SLI-аар хэмжигддэг үйлчилгээний түвшний зорилтот утга эсвэл утгын хүрээ. SLO-ийн хэвийн утга нь “SLI ≤ Зорилтот” эсвэл “Доод хязгаар ≤ SLI ≤ Дээд хязгаар” юм. Жишээлбэл, бид SLO-г хайлтын асуулгын дундаж хоцролтыг 100 миллисекундээс бага хэмжээнд тохируулснаар Шекспирийн хайлтын үр дүнг "хурдан" буцаах шийдвэр гаргаж магадгүй.
Зөв SLO сонгох нь нарийн төвөгтэй үйл явц юм. Нэгдүгээрт, та үргэлж тодорхой утгыг сонгож чадахгүй. Таны үйлчилгээнд ирж буй гадны HTTP хүсэлтийн хувьд секундэд асуулга (QPS) хэмжигдэхүүн нь үндсэндээ таны хэрэглэгчдийн танай үйлчилгээнд зочлох хүсэлтэй байгаагаас шалтгаалж тодорхойлогддог бөгөөд та үүнд SLO тохируулах боломжгүй.
Нөгөөтэйгүүр, та хүсэлт бүрийн дундаж хоцролтыг 100 миллисекундээс бага байлгахыг хүсч байна гэж хэлж болно. Ийм зорилго тавих нь таныг бага хоцрогдолтойгоор нүүр хуудас бичих эсвэл ийм хоцрогдолтой тоног төхөөрөмж худалдан авахад хүргэж болзошгүй юм. (100 миллисекунд бол дур зоргоороо тоо гэдэг нь ойлгомжтой, гэхдээ үүнээс ч бага хоцрогдолтой байх нь дээр. Хурдан хурд нь удаан хурдаас илүү сайн гэдгийг нотлох баримтууд байдаг бөгөөд хэрэглэгчийн хүсэлтийг тодорхой утгаас дээш боловсруулахад хоцрогдол нь хүмүүсийг хол байлгахад хүргэдэг. таны үйлчилгээнээс.)
Дахин хэлэхэд, энэ нь эхлээд харахад илүү ойлгомжгүй юм: та QPS-ийг тооцооллоос бүрэн хасч болохгүй. Баримт нь QPS болон хоцролт нь хоорондоо нягт холбоотой байдаг: өндөр QPS нь ихэвчлэн илүү их хоцрогдолд хүргэдэг бөгөөд үйлчилгээ нь ачааллын тодорхой босгонд хүрэхэд гүйцэтгэл нь огцом буурдаг.
SLO-г сонгох, нийтлэх нь үйлчилгээ хэрхэн ажиллах талаар хэрэглэгчийн хүлээлтийг бий болгодог. Энэхүү стратеги нь үйлчилгээний эзэнтэй холбоотой үндэслэлгүй гомдол, тухайлбал гүйцэтгэл удаашралыг бууруулж чадна. Тодорхой SLO байхгүй бол хэрэглэгчид хүссэн гүйцэтгэлийн талаар өөрсдийн хүлээлтийг бий болгодог бөгөөд энэ нь үйлчилгээг зохион бүтээж, удирдаж буй хүмүүсийн санал бодолтой ямар ч холбоогүй байж болно. Энэ нөхцөл байдал нь хэрэглэгчид уг үйлчилгээ нь бодит байдлаас илүү хүртээмжтэй байх болно гэж андуурч, систем нь бодит байдлаасаа бага найдвартай гэж итгэх үед үл итгэх итгэлийг бий болгож, үйлчилгээнээс хэт их хүлээлт үүсгэж болно.
Гэрээ
Үйлчилгээний түвшний гэрээ нь таны хэрэглэгчдэд агуулагдах SLO-г хангасны (эсвэл хангаагүй) үр дагаврыг агуулсан тодорхой буюу далд гэрээ юм. Үр дагавар нь санхүүгийн хувьд хөнгөлөлт эсвэл торгууль байх үед хамгийн амархан хүлээн зөвшөөрөгддөг боловч бусад хэлбэрээр байж болно. SLO болон SLA-ийн ялгааны талаар ярих хялбар арга бол "Хэрвээ SLO-г хангаагүй бол яах вэ?" Гэж асуух явдал юм. Хэрэв тодорхой үр дагавар байхгүй бол та SLO-г харж байгаа нь гарцаагүй.
SLA нь бизнесийн болон бүтээгдэхүүний шийдвэртэй нягт холбоотой байдаг тул SLA нь SLA үүсгэхэд оролцдоггүй. Гэсэн хэдий ч SRE нь бүтэлгүйтсэн ТХГ-ын үр дагаврыг бууруулахад тусалдаг. Тэд мөн SLI-ийг тодорхойлоход тусалж чадна: Мэдээжийн хэрэг, гэрээнд SLO-г хэмжих бодит арга зам байх ёстой, эс тэгвээс санал зөрөлдөөн гарах болно.
Google Хайлт нь нийтийн SLA-гүй чухал үйлчилгээний жишээ юм: бид хүн бүр Хайлтыг аль болох үр ашигтай ашиглахыг хүсч байгаа ч бид дэлхийтэй гэрээ байгуулаагүй байна. Гэсэн хэдий ч хайлт боломжгүй бол үр дагавар байсаар байна - боломжгүй байгаа нь бидний нэр хүндийг унагаж, зар сурталчилгааны орлого буурахад хүргэдэг. Google for Work зэрэг Google-ийн бусад олон үйлчилгээ нь хэрэглэгчидтэй үйлчилгээний түвшний гэрээтэй байдаг. Тодорхой үйлчилгээ нь SLA-тай эсэхээс үл хамааран SLI болон SLO-г тодорхойлж, үйлчилгээг удирдахад ашиглах нь чухал юм.
Маш их онол - одоо туршлага.
Практикт байгаа үзүүлэлтүүд
Үйлчилгээний түвшинг хэмжихэд тохирох хэмжигдэхүүнийг сонгох нь чухал гэж бид дүгнэсэн тул ямар хэмжүүр үйлчилгээ эсвэл системд чухал болохыг та одоо яаж мэдэх вэ?
Та болон танай хэрэглэгчид юуг анхаардаг вэ?
Та хэмжигдэхүүн бүрийг хяналтын системд хянах боломжтой SLI болгон ашиглах шаардлагагүй; Хэрэглэгчид системээс юу хүсч байгааг ойлгох нь хэд хэдэн хэмжигдэхүүнийг сонгоход тусална. Хэт олон үзүүлэлт сонгох нь чухал үзүүлэлтүүд дээр төвлөрөхөд хүндрэл учруулдаг бол цөөн тоог сонгох нь таны системийн томоохон хэсгүүдийг хараа хяналтгүй орхиж болзошгүй юм. Бид системийн эрүүл мэндийг үнэлэх, ойлгохын тулд хэд хэдэн гол үзүүлэлтүүдийг ихэвчлэн ашигладаг.
Үйлчилгээг ерөнхийд нь SLI-д хамаарах хэд хэдэн хэсэгт хувааж болно:
- Манай жишээн дээрх Шекспирийн үйлчилгээний хайлтын интерфэйс зэрэг захиалгат урд талын системүүд. Тэдгээр нь бэлэн байх ёстой, сааталгүй, хангалттай зурвасын өргөнтэй байх ёстой. Үүний дагуу асуултуудыг асууж болно: бид хүсэлтэд хариу өгөх боломжтой юу? Хүсэлтийн хариуг өгөхөд хэр хугацаа зарцуулсан бэ? Хэдэн хүсэлтийг боловсруулах боломжтой вэ?
- Хадгалах систем. Тэд хариу үйлдэл үзүүлэх хугацаа бага, хүртээмж, бат бөх чанарыг үнэлдэг. Холбогдох асуултууд: Өгөгдлийг унших, бичихэд хэр хугацаа шаардагдах вэ? Хүсэлтийн дагуу бид өгөгдөлд хандах боломжтой юу? Мэдээлэл бидэнд хэрэгтэй үед боломжтой юу? Эдгээр асуудлын талаар дэлгэрэнгүй ярилцахын тулд 26-р бүлгийг үзнэ үү Өгөгдлийн нэгдмэл байдал: Таны уншсан зүйл бол таны бичсэн зүйл юм.
- Өгөгдөл боловсруулах дамжуулах хоолой зэрэг том өгөгдлийн системүүд нь дамжуулах чадвар болон асуулга боловсруулах хоцролтоос хамаардаг. Холбогдох асуултууд: Хэр их өгөгдөл боловсруулагддаг вэ? Хүсэлтийг хүлээн авахаас эхлээд хариу өгөх хүртэл өгөгдөл хэр удаан үргэлжлэх вэ? (Системийн зарим хэсэг нь тодорхой үе шатанд сааталтай байж болно.)
Шалгуур үзүүлэлтүүдийн цуглуулга
Үйлчилгээний түвшний олон үзүүлэлтүүдийг Borgmon гэх мэт хяналтын системийг ашиглан сервер талаас нь цуглуулдаг (доороос үзнэ үү). ) эсвэл Prometheus, эсвэл зүгээр л логуудад дүн шинжилгээ хийж, 500 статустай HTTP хариултуудыг тодорхойлох. Гэсэн хэдий ч зарим систем нь үйлчлүүлэгчийн хэмжүүрийн цуглуулгаар тоноглогдсон байх ёстой, учир нь үйлчлүүлэгчийн хяналт байхгүй нь олон тооны асуудлуудыг орхигдуулахад хүргэдэг. хэрэглэгчид, гэхдээ сервер талын хэмжүүрт нөлөөлөхгүй. Жишээлбэл, манай Шекспирийн хайлтын тестийн програмын арын хэсгийн хариултын хоцролтод анхаарлаа хандуулах нь JavaScript-ийн асуудлаас болж хэрэглэгчийн тал дээр саатал үүсэхэд хүргэж болзошгүй: энэ тохиолдолд хөтчөөс хуудсыг боловсруулахад хэр их хугацаа шаардагдахыг хэмжих нь илүү сайн үзүүлэлт юм.
Нэгтгэх
Хэрэглэхэд хялбар, хялбар байхын тулд бид ихэвчлэн түүхий хэмжилтийг нэгтгэдэг. Үүнийг болгоомжтой хийх хэрэгтэй.
Зарим хэмжигдэхүүнүүд нь секундэд хийх хүсэлт гэх мэт энгийн мэт боловч энэ нь ойлгомжтой хэмжилт ч гэсэн цаг хугацааны явцад өгөгдлийг далд байдлаар нэгтгэдэг. Хэмжилтийг секундэд нэг удаа тусгайлан хүлээн авдаг уу эсвэл хэмжилтийг минутанд хийсэн хүсэлтийн тоогоор дундажласан уу? Сүүлчийн сонголт нь хэдхэн секунд үргэлжилдэг илүү олон тооны хүсэлтийг нуух боломжтой. Секундэд 200 хүсэлтийг тэгш тоогоор, үлдсэн хугацаанд 0-д өгдөг системийг авч үзье. Дунджаар секундэд 100 хүсэлт, агшин зуурын ачаалал хоёр дахин их байх хэлбэрийн тогтмол нь ижил зүйл биш юм. Үүний нэгэн адил асуулгын хоцролтыг дундажлах нь сонирхол татахуйц мэт санагдаж болох ч энэ нь нэг чухал зүйлийг нуудаг: ихэнх асуулга хурдан байх боломжтой, гэхдээ удаан асуулга олон байх болно.
Ихэнх үзүүлэлтүүдийг дунджаас илүү хуваарилалт гэж үзэх нь дээр. Жишээлбэл, SLI хоцрогдлын хувьд зарим хүсэлт хурдан боловсруулагдах бол зарим нь үргэлж удаан, заримдаа илүү их хугацаа шаардагдана. Энгийн дундаж нь эдгээр урт саатлыг нууж чадна. Зурагт жишээг үзүүлэв: Хэдийгээр ердийн хүсэлтийг гүйцэтгэхэд ойролцоогоор 50 мс шаардагддаг ч хүсэлтийн 5% нь 20 дахин удаан байна! Зөвхөн дундаж хоцрогдол дээр тулгуурлан хяналт, сэрэмжлүүлэг өгөх нь өдрийн турш зан үйлийн өөрчлөлтийг харуулахгүй бөгөөд зарим хүсэлтийг боловсруулах хугацаанд мэдэгдэхүйц өөрчлөлт гардаг (хамгийн дээд шугам).
50, 85, 95, 99 хувийн системийн хоцролт. Y тэнхлэг нь логарифм хэлбэртэй байна.
Шалгуур үзүүлэлтийн хувьд хувь хэмжээг ашиглах нь тархалтын хэлбэр, түүний шинж чанарыг харах боломжийг олгодог: 99 эсвэл 99,9 гэх мэт өндөр хувь нь хамгийн муу утгыг, харин 50 хувь (мөн медиан гэгддэг) нь хамгийн олон давтамжтай төлөвийг харуулдаг. хэмжигдэхүүн. Хариулах хугацаа их байх тусам удаан үргэлжилсэн хүсэлтүүд хэрэглэгчийн туршлагад төдий чинээ нөлөөлдөг. Үр нөлөө нь өндөр ачаалал, дараалал байгаа үед нэмэгддэг. Хэрэглэгчийн туршлагын судалгаагаар хүмүүс ерөнхийдөө хариу өгөх хугацаа ихтэй, удаан системийг илүүд үздэг тул зарим SRE багууд 99,9 хувийн үзүүлэлттэй хэмжигдэхүүн сайн байвал ихэнх хэрэглэгчид асуудал гарахгүй гэсэн үндсэн дээр зөвхөн өндөр хувийн оноонд анхаарлаа хандуулдаг. .
Статистикийн алдааны тухай тэмдэглэл
Бид ерөнхийдөө олон тооны утгын дундаж (арифметик дундаж) гэхээсээ илүү хувьтай ажиллахыг илүүд үздэг. Энэ нь ихэвчлэн дунджаас мэдэгдэхүйц ялгаатай (мөн илүү сонирхолтой) шинж чанартай байдаг илүү тархсан утгыг авч үзэх боломжийг бидэнд олгодог. Тооцооллын системийн зохиомол шинж чанараас шалтгаалан хэмжүүрийн утгууд ихэвчлэн хазайдаг, жишээлбэл, ямар ч хүсэлт 0 мс-ээс бага хугацаанд хариу хүлээн авах боломжгүй бөгөөд 1000 ms-ийн хугацаа хэтэрсэн нь илүү их утгатай амжилттай хариулт өгөх боломжгүй гэсэн үг юм. хугацаа дууссанаас илүү. Үүний үр дүнд бид дундаж ба медиан нь ижил эсвэл бие биентэйгээ ойрхон байж болохыг бид хүлээн зөвшөөрөх боломжгүй юм!
Урьдчилсан туршилт хийлгүйгээр, мөн тодорхой стандарт таамаглал, ойролцооллыг баримтлаагүй тохиолдолд бид өгөгдөл хэвийн тархсан гэж дүгнэхээс болгоомжилж байна. Хэрэв түгээлт нь хүлээгдэж буй шиг биш бол асуудлыг засдаг автоматжуулалтын процесс (жишээлбэл, хэт давчуу утгыг олж харах үед серверийг хүсэлтийг боловсруулах хоцрогдол ихтэй дахин эхлүүлдэг) үүнийг хэт олон удаа хийдэг эсвэл хангалтгүй (хоёулаа тийм биш) байж болно. маш сайн).
Шалгуур үзүүлэлтүүдийг стандартчилах
Бид SLI-ийн ерөнхий шинж чанаруудыг стандартчилахыг зөвлөж байна, ингэснээр та тэдгээрийн талаар байнга таамаглах шаардлагагүй болно. Стандарт хэв маягт нийцсэн аливаа шинж чанарыг SLI-ийн тодорхойлолтоос хасч болно, жишээлбэл:
- Нэгтгэх интервал: "дундаж 1 минутаас дээш"
- Нэгтгэх талбар: "Кластер дахь бүх ажил"
- Хэмжилтийг хэр олон удаа хийдэг вэ: "10 секунд тутамд"
- Ямар хүсэлтүүд багтсан бэ: "Хар хайрцагны хяналтын ажлуудаас HTTP GET"
- Мэдээллийг хэрхэн олж авах вэ: "Сервер дээр хэмжсэн бидний мониторингийн ачаар"
- Өгөгдлийн хандалтын хоцролт: "Сүүлийн байт хүртэлх хугацаа"
Хүчин чармайлтаа хэмнэхийн тулд нийтлэг хэмжигдэхүүн бүрт дахин ашиглах боломжтой SLI загваруудыг үүсгэнэ үү; Тэд мөн тодорхой SLI гэж юу болохыг ойлгоход хялбар болгодог.
Практик дахь зорилго
Та юу хэмжиж чадахаа биш, харин таны хэрэглэгчид юуг анхаардаг талаар бодож (эсвэл олж мэдэх!) эхэл. Ихэнхдээ таны хэрэглэгчдийн санаа зовдог зүйлийг хэмжихэд хэцүү эсвэл боломжгүй байдаг тул та тэдний хэрэгцээнд ойртдог. Гэсэн хэдий ч, хэрэв та хэмжихэд хялбар зүйлээс л эхэлбэл танд ашиг тус багатай SLO-ууд гарах болно. Үүний үр дүнд бид заримдаа хүссэн зорилгоо тодорхойлж, дараа нь тодорхой үзүүлэлтүүдтэй ажиллах нь шалгуур үзүүлэлтийг сонгоод дараа нь зорилгодоо хүрэхээс илүү үр дүнтэй болохыг олж мэдсэн.
Зорилгоо тодорхойлох
Хамгийн их ойлгомжтой болгохын тулд SLO-г хэрхэн хэмждэг, тэдгээр нь хүчинтэй байх нөхцөлийг тодорхойлсон байх ёстой. Жишээлбэл, бид дараах зүйлийг хэлж болно (хоёр дахь мөр нь эхнийхтэй ижил боловч SLI-ийн өгөгдмөлүүдийг ашигладаг):
- Get RPC дуудлагын 99% (дунджаар 1 минутаас дээш) нь 100 мс-ээс бага хугацаанд дуусна (бүх арын серверт хэмжсэн).
- Get RPC дуудлагын 99% нь 100мс хүрэхгүй хугацаанд дуусна.
Гүйцэтгэлийн муруй хэлбэр нь чухал бол та хэд хэдэн SLO-г зааж өгч болно:
- Get RPC дуудлагын 90% нь 1 мс-ээс бага хугацаанд дуусдаг.
- Get RPC дуудлагын 99% нь 10 мс-ээс бага хугацаанд дуусдаг.
- Get RPC дуудлагын 99.9% нь 100 мс-ээс бага хугацаанд дуусдаг.
Хэрэв таны хэрэглэгчид янз бүрийн ажлын ачааллыг үүсгэдэг бол: бөөнөөр боловсруулах (үүнд нэвтрүүлэх чадвар чухал) болон интерактив боловсруулалт (үүнд хоцрогдол чухал байдаг) ачааллын ангилал тус бүрийн хувьд тусдаа зорилгыг тодорхойлох нь зүйтэй.
- Хэрэглэгчийн хүсэлтийн 95% нь дамжуулах чадварыг шаарддаг. Гүйцэтгэсэн RPC дуудлагын тоог <1 секундээр тохируулна уу.
- Үйлчлүүлэгчдийн 99% нь хоцрогдолд санаа тавьдаг. <1 КБ ачаалалтай, <10 мс ажиллаж байгаа RPC дуудлагын тоог тохируулна уу.
SLO-г 100% хангана гэж шаардах нь бодитой бус бөгөөд хүсээгүй зүйл юм: энэ нь шинэ функцийг нэвтрүүлэх, байршуулах хурдыг бууруулж, үнэтэй шийдлүүдийг шаарддаг. Үүний оронд алдааны төсөв - системийн сул зогсолтын хувь хэмжээг зөвшөөрч, энэ утгыг өдөр бүр эсвэл долоо хоног бүр хянах нь дээр. Ахлах удирдлага сар эсвэл улирал бүр үнэлгээ хийхийг хүсч болно. (Алдааны төсөв нь зүгээр л өөр SLO-той харьцуулах SLO юм.)
SLO зөрчлийн хувийг алдааны төсөвтэй харьцуулж болно (3-р бүлэг ба хэсгийг үзнэ үү ), шинэ хувилбаруудыг хэзээ байршуулахыг шийддэг процессын орц болгон ашигладаг зөрүүний утгыг агуулсан.
Зорилтот утгыг сонгох
Төлөвлөлтийн үнэ цэнийг (SLOs) сонгох нь сонгогдсон SLI, SLO (болон магадгүй SLA) -д тусгах ёстой бүтээгдэхүүн, бизнесийн ашиг сонирхлын улмаас цэвэр техникийн үйл ажиллагаа биш юм. Үүний нэгэн адил боловсон хүчин, зах зээлд гарах хугацаа, тоног төхөөрөмжийн хүртээмж, санхүүжилттэй холбоотой асуудлаар мэдээлэл солилцох шаардлагатай байж магадгүй юм. SRE нь энэхүү ярианы нэг хэсэг байх ёстой бөгөөд янз бүрийн хувилбаруудын эрсдэл, амьдрах чадварыг ойлгоход туслах ёстой. Хэлэлцүүлгийг илүү үр дүнтэй болгоход туслах хэд хэдэн асуултыг бид дэвшүүлсэн:
Одоогийн гүйцэтгэл дээр үндэслэн зорилгоо сонгох хэрэггүй.
Системийн давуу тал, хязгаарыг ойлгох нь чухал боловч хэмжүүрүүдийг үндэслэлгүйгээр тохируулах нь системийг хадгалахад саад учруулж болзошгүй: энэ нь томоохон дахин төлөвлөлтгүйгээр хүрч чадахгүй зорилгод хүрэхийн тулд баатарлаг хүчин чармайлт шаарддаг.
Энгийн байлгаарай
Нарийн төвөгтэй SLI тооцоолол нь системийн гүйцэтгэлийн өөрчлөлтийг нууж, асуудлын шалтгааныг олоход хэцүү болгодог.
Үнэмлэхүй байдлаас зайлсхий
Хэдийгээр хоцролтыг нэмэгдүүлэхгүйгээр хязгааргүй өсөн нэмэгдэж буй ачааллыг даван туулах чадвартай системтэй болох нь сонирхолтой боловч энэ шаардлага нь бодитой бус юм. Ийм үзэл баримтлалд ойртож буй систем нь загвар зохион бүтээх, бүтээхэд маш их цаг хугацаа шаардагдах бөгөөд ажиллуулахад үнэтэй байх бөгөөд үүнээс бага зүйлийг хийх хэрэглэгчдийн хүлээлтийг хангахад хэтэрхий сайн байх болно.
Аль болох цөөн SLO ашигла
Системийн шинж чанаруудыг сайн хамрахын тулд хангалттай тооны SLO-г сонго. Сонгосон SLO-уудаа хамгаалаарай: Хэрэв та тодорхой SLO-г зааж өгснөөр тэргүүлэх чиглэлийн маргаанд хэзээ ч ялж чадахгүй бол энэ SLO-г авч үзэх нь үнэ цэнэтэй зүйл биш байх магадлалтай. Гэсэн хэдий ч системийн бүх шинж чанарууд нь SLO-д тохирохгүй: SLO-г ашиглан хэрэглэгчийн таашаал ханамжийн түвшинг тооцоолоход хэцүү байдаг.
Төгс төгөлдөр байдлын хойноос хөөцөлдөх хэрэггүй
Та ачааллын үед системийн үйл ажиллагааны талаар илүү ихийг мэдэхийн хэрээр SLO-ийн тодорхойлолт, зорилгыг цаг хугацааны явцад сайжруулах боломжтой. Хэтэрхий хатуу зорилгыг сонгохоос илүүтэйгээр цаг хугацаа өнгөрөх тусам улам боловсронгуй болгох хөвөгч зорилгоос эхлүүлсэн нь дээр.
SLO нь SRE болон бүтээгдэхүүн хөгжүүлэгчдэд зориулсан ажлыг эрэмбэлэх гол хөшүүрэг байж болох бөгөөд байх ёстой, учир нь тэдгээр нь хэрэглэгчдийн санаа зовоосон асуудал юм. Сайн SLO нь хөгжүүлэлтийн багт хэрэгтэй хэрэгжүүлэх хэрэгсэл юм. Гэхдээ муу зохион бүтээсэн SLO нь баг хэт түрэмгий SLO-д хүрэхийн тулд баатарлаг хүчин чармайлт гаргавал үрэлгэн ажилд, эсвэл SLO хэт бага бол муу бүтээгдэхүүн гаргахад хүргэдэг. SLO бол хүчирхэг хөшүүрэг бөгөөд үүнийг ухаалгаар ашигла.
Хэмжилтээ хянах
SLI ба SLO нь системийг удирдахад ашигладаг гол элементүүд юм:
- SLI системийг хянах, хэмжих.
- SLI-г SLO-той харьцуулж, арга хэмжээ авах шаардлагатай эсэхийг шийдээрэй.
- Хэрэв арга хэмжээ авах шаардлагатай бол зорилгодоо хүрэхийн тулд юу хийх хэрэгтэйг олж мэдээрэй.
- Энэ үйлдлийг гүйцээнэ үү.
Жишээлбэл, 2-р алхам нь хүсэлтийн хугацаа дуусч, юу ч хийгээгүй тохиолдолд SLO-г хэдхэн цагийн дотор эвдэхийг харуулж байвал 3-р алхам нь серверүүд нь CPU-тэй холбоотой гэсэн таамаглалыг шалгах бөгөөд илүү олон сервер нэмэх нь ачааллыг хуваарилах болно. SLO байхгүй бол та (эсвэл хэзээ) арга хэмжээ авахаа мэдэхгүй байх байсан.
SLO тохируулах - дараа нь хэрэглэгчийн хүлээлт тохируулагдах болно
SLO-г нийтлэх нь хэрэглэгчийн системийн үйл ажиллагааны хүлээлтийг тогтоодог. Хэрэглэгчид (болон боломжит хэрэглэгчид) ашиглахад тохиромжтой эсэхийг ойлгохын тулд үйлчилгээнээс юу хүлээж байгааг мэдэхийг хүсдэг. Жишээлбэл, зураг хуваалцах вэб сайтыг ашиглах хүсэлтэй хүмүүс архивын бүртгэлийн удирдлагын системд ижил үйлчилгээ тохиромжтой байж болох ч урт наслалт, хямд өртөгтэй үйлчилгээг ашиглахаас зайлсхийхийг хүсч болно.
Хэрэглэгчиддээ бодитой хүлээлт үүсгэхийн тулд дараах тактикуудын аль нэгийг эсвэл хоёуланг нь ашиглаарай.
- Аюулгүй байдлын хязгаарыг хадгалах. Хэрэглэгчдэд сурталчилж байгаагаас илүү хатуу дотоод SLO ашигла. Энэ нь асуудлыг гаднаас нь харагдахаас нь өмнө хариу үйлдэл үзүүлэх боломжийг танд олгоно. Мөн SLO буфер нь системийн гүйцэтгэлд нөлөөлдөг хувилбаруудыг суулгахдаа аюулгүй байдлын хязгаартай байх боломжийг олгож, хэрэглэгчдийг сул зогсолтод оруулахгүйгээр системийг засварлахад хялбар байх боломжийг олгодог.
- Хэрэглэгчийн хүлээлтээс хэтэрч болохгүй. Хэрэглэгчид таны хэлж буй зүйлд бус харин таны санал болгож буй зүйлд тулгуурладаг. Хэрэв таны үйлчилгээний бодит гүйцэтгэл нь заасан SLO-ээс хамаагүй дээр байвал хэрэглэгчид одоогийн гүйцэтгэлд найдах болно. Та системийг зориудаар хаах эсвэл хөнгөн ачааллын үед гүйцэтгэлийг хязгаарлах замаар хэт хараат байдлаас зайлсхийх боломжтой.
Систем нь хүлээлтэд хэр нийцэж байгааг ойлгох нь системийг хурдасгах, илүү хүртээмжтэй, уян хатан болгоход хөрөнгө оруулах эсэхээ шийдэхэд тусалдаг. Эсвэл хэрэв үйлчилгээ хэт сайн ажиллаж байгаа бол ажилчдын зарим цагийг техникийн өрийг барагдуулах, шинэ боломжуудыг нэмэх, шинэ бүтээгдэхүүн нэвтрүүлэх зэрэг бусад тэргүүлэх чиглэлд зарцуулах хэрэгтэй.
Практикт байгаа хэлэлцээрүүд
SLA-г бий болгохын тулд бизнесийн болон хуулийн багууд үүнийг зөрчсөний үр дагавар, шийтгэлийг тодорхойлох шаардлагатай. SRE-ийн үүрэг бол SLA-д тусгагдсан ТХГ-ыг хангахад гарч болзошгүй бэрхшээлүүдийг ойлгоход нь туслах явдал юм. SLO-г бий болгох зөвлөмжүүдийн ихэнх нь SLA-д мөн хамаарна. Хэрэглэгчдэд амласан зүйлдээ консерватив байх нь ухаалаг хэрэг юм, учир нь танд хэдий чинээ их байх тусам үндэслэлгүй эсвэл биелүүлэхэд хэцүү мэт санагдах SLA-г өөрчлөх, устгахад хэцүү байдаг.
Орчуулгыг дуустал нь уншсан танд баярлалаа. Хяналтын талаар миний телеграм сувагт бүртгүүлнэ үү и .
Эх сурвалж: www.habr.com