SRE (Сайтын найдвартай байдлын инженерчлэл) нь вэб төслүүдийг хүртээмжтэй болгох арга юм. Энэ нь DevOps-ийн хүрээ гэж тооцогддог бөгөөд DevOps практикийг хэрхэн амжилттай хэрэгжүүлэх талаар өгүүлдэг. Энэ нийтлэлийг орчуулав номууд Google-ээс. Би энэ орчуулгыг өөрөө бэлтгэсэн бөгөөд хяналтын үйл явцыг ойлгох өөрийн туршлагад тулгуурласан. Телеграм суваг дээр и Би мөн ижил номын 4-р бүлгийн Үйлчилгээний түвшний зорилтуудын орчуулгын холбоосыг нийтэлсэн.
Муурны орчуулга. Уншихыг сайхан өнгөрүүлээрэй!
Google SRE багууд амжилттай хяналт, мэдэгдлийн системийг бий болгох үндсэн зарчим, шилдэг туршлагуудтай. Энэ бүлэгт вэб хуудасны зочдод ямар асуудал тулгарч болох, вэб хуудсыг харуулахад хүндрэл учруулж буй асуудлыг хэрхэн шийдвэрлэх талаар зөвлөмж өгдөг.
Тодорхойлолт
Мониторингтой холбоотой сэдвүүдийг хэлэлцэхэд ашигладаг ганц үгийн сан байдаггүй. Google дээр ч гэсэн доорх нэр томьёо түгээмэл хэрэглэгддэггүй ч бид хамгийн түгээмэл тайлбаруудыг жагсаах болно.
Хяналт шинжилгээ
Системийн талаарх бодит цагийн тоон мэдээллийг цуглуулах, боловсруулах, нэгтгэх, харуулах: хүсэлтийн тоо, хүсэлтийн төрөл, алдааны тоо, алдааны төрөл, хүсэлтийг боловсруулах хугацаа, серверийн ажиллах хугацаа.
Цагаан хайрцагны хяналт
Дотоод статистикийг үүсгэдэг лог, JVM эсвэл HTTP зохицуулагчийн профайлыг тодорхойлох хэмжигдэхүүн зэрэг системийн дотоод хэсгүүдийн харуулсан хэмжигдэхүүнд суурилсан хяналт.
Хар хайрцагны хяналт
Хэрэглэгчийн байр сууринаас програмын зан төлөвийг шалгах.
Хяналтын самбар (хяналтын самбар)
Үйлчилгээний эрүүл мэндийн гол үзүүлэлтүүдийн тоймыг өгдөг интерфейс (ихэвчлэн вэб интерфэйс). Хяналтын самбар нь шүүлтүүртэй, ямар хэмжигдэхүүнийг харуулахыг сонгох боломжтой гэх мэт байж болно.Интерфэйс нь хэрэглэгчдийн хамгийн чухал хэмжигдэхүүнийг тодорхойлоход зориулагдсан. Хяналтын самбар нь техникийн дэмжлэг үзүүлэх ажилтнуудад зориулсан мэдээллийг харуулах боломжтой: хүсэлтийн дараалал, өндөр ач холбогдолтой алдааны жагсаалт, тухайн хариуцлагын чиглэлээр томилогдсон инженер.
Анхааруулга (мэдэгдэл)
Алдаа эсвэл хүсэлтийн дараалал нэмэгдсэний үр дүнд өдөөгдөж болзошгүй, цахим шуудангаар эсвэл өөр хэлбэрээр хүлээн авах зорилготой мэдэгдэл. Мэдэгдэлийг тасалбар, имэйл дохио, мессенжер мессеж гэж ангилдаг.
Үндсэн шалтгаан (үндсэн шалтгаан)
Програм хангамжийн согог эсвэл хүний алдаа засч залруулсны дараа дахин гарах ёсгүй. Асуудал нь хэд хэдэн үндсэн шалтгаантай байж болно: процессын автоматжуулалт хангалтгүй, програм хангамжийн согог, хэрэглээний логикийн хангалтгүй судалгаа. Эдгээр хүчин зүйлүүд тус бүр нь үндсэн шалтгаан байж болох бөгөөд тэдгээр нь тус бүрийг арилгах ёстой.
Зангилаа ба машин (зангилаа ба машин)
Физик сервер, виртуал машин эсвэл контейнер дээр ажиллаж байгаа програмын нэг тохиолдлыг илэрхийлэх сольж болох нэр томъёо. Нэг машин дээр хэд хэдэн үйлчилгээ байж болно. Үйлчилгээнүүд нь:
- өөр хоорондоо холбоотой: жишээлбэл, кэш сервер ба вэб сервер;
- ижил техник хангамж дээрх хамааралгүй үйлчилгээ: жишээлбэл, кодын хадгалах газар, тохиргооны системийн шидтэн гэх мэт. буюу .
түлхэх
Програм хангамжийн тохиргоонд гарсан аливаа өөрчлөлт.
Яагаад хяналт тавих шаардлагатай байна
Програмыг хянах хэд хэдэн шалтгаан бий:
Урт хугацааны чиг хандлагын дүн шинжилгээ
Мэдээллийн сан хэр том, хэр хурдацтай хөгжиж байна вэ? Өдөр тутмын хэрэглэгчдийн тоо хэрхэн өөрчлөгддөг вэ?
Гүйцэтгэлийн харьцуулалт
Acme Bucket of Bytes 2.72 дээрх асуулга Ajax DB 3.14-ээс хурдан байна уу? Нэмэлт зангилаа гарч ирсний дараа хүсэлтүүд хэр сайн хадгалагддаг вэ? Сайт өнгөрсөн долоо хоногтой харьцуулахад удааширсан уу?
Анхааруулга (мэдэгдэл)
Ямар нэг зүйл эвдэрч, хэн нэгэн үүнийг засах хэрэгтэй. Эсвэл удахгүй ямар нэг зүйл эвдэрч, хэн нэгэн үүнийг удахгүй шалгах хэрэгтэй болно.
Хяналтын самбар үүсгэх
Хяналтын самбар нь үндсэн асуултуудад хариулж, ямар нэг зүйлийг багтаасан байх ёстой - саатал (хоцролт), замын хөдөлгөөн (хөдөлгөөн), алдаа (алдаа) ба ачааллын утга (ханасан байдал).
Ретроспектив шинжилгээ хийх (дибаг хийх)
Хүсэлтийг боловсруулах хоцрогдол нэмэгдсэн, яг тэр үед өөр юу болсон бэ?
Хяналтын системүүд нь бизнесийн тагнуулын системийн мэдээллийн эх сурвалж болж, аюулгүй байдлын ослын дүн шинжилгээ хийхэд тустай. Энэхүү ном нь ЭХЭМҮТ-ийн мэргэшсэн инженерийн салбарт гол анхаарлаа хандуулдаг тул бид энд хяналтын арга техникийг хэлэлцэхгүй.
Хяналт, дохиолол нь систем нь эвдэрсэн эсвэл эвдрэх гэж байгаа үед мэдэгдэх боломжийг олгодог. Хэрэв систем автоматаар өөрийгөө засаж чадахгүй бол бид хүнээс сэрэмжлүүлэгт дүн шинжилгээ хийж, асуудал хэвээр байгаа эсэхийг тодорхойлж, түүнийг засч, үндсэн шалтгааныг тогтоохыг хүсдэг. Хэрэв та системийн бүрэлдэхүүн хэсгүүдэд аудит хийхгүй бол "ямар нэгэн зүйл хачирхалтай санагдаж байна" гэсэн анхааруулга хэзээ ч авахгүй.
Хүний дохиог ачаалах нь ажилтны цагийг нэлээд үнэтэй ашиглах явдал юм. Хэрэв ажилтан ажиллаж байгаа бол сэрэмжлүүлэг нь ажлын урсгалыг тасалдаг. Хэрэв ажилтан гэртээ байгаа бол дохиолол нь хувийн цагийг тасалдуулж, унтаж магадгүй юм. Сэрэмжлүүлэг хэтэрхий олон удаа гарч ирэх үед ажилтнууд ирж буй дохиог хайхрахгүй, хойшлуулах эсвэл үл тоомсорлодог. Үе үе тэд чимээ шуугианаар далдлагдсан жинхэнэ сэрэмжлүүлгийг үл тоомсорлодог. Дуу шуугиан нь асуудлыг хурдан оношлох, шийдвэрлэхээс сэргийлдэг тул үйлчилгээний тасалдал удаан үргэлжилж болно. Үр дүнтэй нийтийн хаягийн систем нь дохио ба дуу чимээний харьцаатай байдаг.
Хяналтын системээс боломжийн хүлээлтийг тодорхойлох
Нарийн төвөгтэй хэрэглээнд хяналт тавих нь өөрөө нарийн төвөгтэй инженерийн ажил юм. Цуглуулга, дэлгэц, анхааруулах хэрэгслүүдийн томоохон дэд бүтэцтэй байсан ч 10-12 гишүүнтэй Google SRE багт гол зорилго нь хяналтын системийг бий болгох, засвар үйлчилгээ хийх нэг эсвэл хоёр хүн багтдаг. Бид мониторингийн дэд бүтцийг нэгтгэж, төвлөрүүлснээр энэ тоо цаг хугацааны явцад буурсан боловч SRE-ийн баг бүр дор хаяж нэг зөвхөн мониторинг хийдэг ажилтантай байдаг. Хяналтын системийн хяналтын самбарыг үзэх нь нэлээд сонирхолтой боловч SRE-ийн багууд асуудлыг хянахын тулд хэн нэгнийг дэлгэц рүү харах шаардлагатай нөхцөл байдлаас болгоомжтой зайлсхийдэг гэдгийг хэлэх ёстой.
Ерөнхийдөө Google нь бодит дүн шинжилгээ хийх оновчтой хэрэгсэл бүхий энгийн бөгөөд хурдан хяналтын системд шилжсэн. Бид босгыг урьдчилан таамаглах эсвэл үндсэн шалтгааныг автоматаар илрүүлэхийг оролддог "шидэт" системээс зайлсхийдэг. Эцсийн хэрэглэгчийн хүсэлтээс хүсээгүй агуулгыг илрүүлдэг мэдрэгч нь цорын ганц сөрөг жишээ юм; Эдгээр мэдрэгч нь энгийн хэвээр байвал ноцтой гажиг үүсэх шалтгааныг хурдан илрүүлж чадна. Хүчин чадлыг төлөвлөх, замын хөдөлгөөний урьдчилан таамаглах зэрэг хяналтын өгөгдлийг ашиглах бусад хэлбэрүүд нь илүү төвөгтэй байдаг. Маш удаан хугацаанд (сар эсвэл жил) түүвэрлэлтийн бага хурдаар (цаг эсвэл өдөр) ажиглалт хийх нь урт хугацааны чиг хандлагыг харуулах болно.
Google SRE баг нь хараат байдлын шаталсан шатлалтай янз бүрийн түвшинд амжилттай ажилласан. Бид "хэрэв би мэдээллийн сан удаашралтай болсныг мэдвэл мэдээллийн сангийн удаашралын дохио авдаг, үгүй бол сайтын удаашралтай сануулга авдаг" гэх мэт дүрмийг бараг ашигладаггүй. Хараат байдалд суурилсан дүрмүүд нь манай системийн өөрчлөгдөөгүй хэсгүүд, тухайлбал дата төв рүү чиглэсэн хэрэглэгчийн урсгалыг шүүх систем гэх мэт. Жишээлбэл, "Хэрэв дата төвийн замын хөдөлгөөний шүүлтүүрийг тохируулсан бол хэрэглэгчийн хүсэлтийг боловсруулахад саатсан талаар надад бүү анхааруулаарай" нь өгөгдлийн төвийн дохиоллын нийтлэг дүрэм юм. Манай дэд бүтцэд байнгын рефакторинг тогтмол хийдэг тул Google-ийн цөөхөн баг нарийн төвөгтэй хамаарлын шатлалыг дэмждэг.
Энэ бүлэгт дурдсан санаануудын зарим нь үнэн хэвээр байна: ялангуяа байнга өөрчлөгдөж байдаг системд шинж тэмдгүүдээс үндсэн шалтгаан руу хурдан шилжих арга үргэлж байдаг. Иймд энэ бүлэгт хяналтын системийн зарим зорилгууд болон тэдгээр зорилгод хэрхэн хүрэх талаар тодорхойлсон хэдий ч хяналтын систем нь багийн гишүүдэд энгийн бөгөөд ойлгомжтой байх нь чухал юм.
Үүний нэгэн адил дуу чимээ бага, дохионы түвшинг өндөр байлгахын тулд дохио өгч буй объектыг хянах арга нь маш энгийн бөгөөд найдвартай байх ёстой. Хүмүүст сэрэмжлүүлэг өгдөг дүрмүүд нь ойлгоход хялбар бөгөөд тодорхой асуудалтай байх ёстой.
Шалтгаан ба шинж тэмдэг
Таны хяналтын систем "юу эвдэрсэн бэ", "яагаад эвдэрсэн бэ" гэсэн хоёр асуултанд хариулах ёстой.
“Юу эвдэрсэн” гэдэг нь шинж тэмдгийг, “яагаад эвдэрсэн” гэдэг нь шалтгааныг илэрхийлдэг. Доорх хүснэгтэд ийм холбоосуудын жишээг харуулав.
Шинж тэмдэг
Шалтгаан
HTTP алдаа 500 эсвэл 404 хүлээн авч байна
Өгөгдлийн сангийн серверүүд холболт хийхээс татгалзаж байна
Серверийн хариу удаан
CPU-ийн өндөр ашиглалт эсвэл гэмтсэн Ethernet кабель
Антарктидын хэрэглэгчид муурны GIF-г авахгүй байна
Таны CDN эрдэмтэд болон муурыг үзэн яддаг тул зарим IP хар жагсаалтад орсон байна
Хувийн контентыг хаа сайгүй үзэх боломжтой
Програм хангамжийн шинэ хувилбарыг гаргаснаар галт ханыг бүх ACL-г мартаж, хүн бүрийг дотогш оруулах боломжийг олгосон
"Юу", "Яагаад" нь хамгийн их дохио, хамгийн бага дуу чимээ бүхий сайн хяналтын системийг бий болгох хамгийн чухал барилгын блокуудын нэг юм.
Хар хайрцаг, цагаан хайрцаг
Бид цагаан хайрцгийн өргөн хүрээний хяналтыг чухал хэмжүүрүүдийн хувьд даруухан хар хайрцагны хяналттай хослуулдаг. Black-box-г White-box-той харьцуулах хамгийн хялбар арга бол Black-box нь шинж тэмдгүүдэд төвлөрсөн бөгөөд идэвхтэй хяналт гэхээсээ илүү идэвхтэй байдаг: "систем яг одоо зөв ажиллахгүй байна." Цагаан хайрцаг нь системийн дотоод шалгах чадвараас хамаарна: үйл явдлын бүртгэл эсвэл вэб сервер. Тиймээс White-box нь удахгүй болох асуудал, хүсэлтийг дахин дамжуулах гэх мэт эвдрэлийг илрүүлэх боломжийг олгодог.
Олон давхаргат системд нэг инженерийн хариуцлагын бүс дэх шинж тэмдэг нь өөр инженерийн хариуцлагын шинж тэмдэг болдог гэдгийг анхаарна уу. Жишээлбэл, мэдээллийн сангийн гүйцэтгэл буурсан. Өгөгдлийн сангийн удаашралтай уншилт нь тэдгээрийг илрүүлдэг өгөгдлийн сангийн SRE-ийн шинж тэмдэг юм. Гэсэн хэдий ч, удаан вэбсайт үзэж байгаа SRE-ийн хувьд мэдээллийн баазыг удаан уншдаг шалтгаан нь мэдээллийн сан удаан байдагтай холбоотой. Тиймээс цагаан хайрцагны хяналт нь хэр өргөн цар хүрээтэй байгаагаас хамааран заримдаа шинж тэмдэг, заримдаа шалтгаан дээр төвлөрдөг.
Дибаг хийх зорилгоор телеметрийг цуглуулахдаа Цагаан хайрцагны хяналт шаардлагатай. Хэрэв вэб серверүүд өгөгдлийн сангийн асуулгад удаан хариу үйлдэл үзүүлдэг бол вэб сервер өгөгдлийн сантай хэр хурдан харилцаж, хэр хурдан хариу үйлдэл үзүүлж байгааг мэдэх хэрэгтэй. Үгүй бол та өгөгдлийн сангийн удаашралтай сервер болон вэб сервер болон өгөгдлийн сангийн хоорондох сүлжээний асуудлыг ялгаж чадахгүй.
Хар хайрцагны хяналт нь сэрэмжлүүлэг илгээх гол давуу талтай: асуудал аль хэдийн бодит шинж тэмдгийг үүсгэсэн үед та хүлээн авагчид мэдэгдэл илгээдэг. Нөгөөтэйгүүр, хараахан гарч амжаагүй байгаа, гэхдээ ирээдүйн асуудал болох "Хар хайрцаг"-ын хувьд хяналт тавих нь ашиггүй юм.
Дөрвөн алтан дохио
Хяналтын дөрвөн алтан дохио нь саатал, замын хөдөлгөөн, алдаа, ханасан байдал юм. Хэрэв та зөвхөн дөрвөн хэрэглэгчийн системийн хэмжигдэхүүнийг хэмжих боломжтой бол тэдгээр дөрөв дээр анхаарлаа хандуулаарай.
Хойшлуулах
Хүсэлтийг боловсруулахад шаардагдах хугацаа. Амжилттай болон амжилтгүй хүсэлтийн хоцролтыг ялгах нь чухал юм. Жишээлбэл, мэдээллийн сан эсвэл өөр арын хэсэгт холболт тасарсанаас үүссэн HTTP 500 алдааг маш хурдан оношлох боломжтой боловч HTTP 500 алдаа нь амжилтгүй хүсэлтийг илэрхийлж болно. Нийт хоцролтод 500 алдааны нөлөөллийг олох нь алдаатай дүгнэлт гаргахад хүргэдэг. Нөгөөтэйгүүр, удаан алдаа нь бүр хурдан алдаа юм! Тиймээс алдааг шүүхээс илүүтэйгээр алдааны хоцролтыг хянах нь чухал юм.
замын хөдөлгөөний
Өндөр түвшний системийн хэмжүүрээр хэмжигддэг таны системд ирсэн хүсэлтийн тоо. Вэб үйлчилгээний хувьд энэ хэмжилт нь ихэвчлэн секундэд хийгдэж буй HTTP хүсэлтийн тоог хүсэлтийн шинж чанарт (жишээ нь, статик эсвэл динамик контент) хуваадаг. Аудио урсгалын системийн хувьд энэ хэмжилтийг сүлжээний оролт/гаралтын хурд эсвэл зэрэгцсэн сешнүүдийн тоонд төвлөрүүлж болно. Түлхүүр-утга хадгалах системийн хувьд энэ хэмжилт нь секундэд гүйлгээ эсвэл хайлт байж болно.
Алдаа
Энэ нь бүтэлгүйтсэн хүсэлтийн хувь, тодорхой (жишээ нь, HTTP 500), далд хэлбэрээр (жишээ нь, HTTP 200, гэхдээ муу агуулгатай хослуулсан) эсвэл бодлогын дагуу (жишээ нь, "Хэрэв та нэг секундын дотор хариулт авбал ямар ч нэг секунд бол алдаа"). Хэрэв бүтэлгүйтлийн бүх нөхцөлийг илэрхийлэх хангалттай HTTP хариу код байхгүй бол хэсэгчилсэн эвдрэлийг илрүүлэхийн тулд хоёрдогч (дотоод) протокол шаардлагатай болно. Ийм бүх алдаатай хүсэлтийг хянах нь мэдээлэлгүй байж болох ч төгсгөл хоорондын системийн туршилт нь таныг буруу контент боловсруулж байгааг илрүүлэхэд тусална.
Ханалт
Энэ хэмжигдэхүүн нь таны үйлчилгээг хэр их ашиглаж байгааг харуулдаг. Энэ нь хамгийн хязгаарлагдмал нөөцийг тодорхойлдог системийн хяналтын хэмжүүр юм (жишээлбэл, хязгаарлагдмал санах ойтой системд санах ойг харуулдаг, хязгаарлагдмал I / O системд I / O-ийн тоог харуулдаг). Олон систем 100% ашиглалтад хүрэхээсээ өмнө доройтдог тул ашиглалтын зорилтот байх нь чухал гэдгийг анхаарна уу.
Нарийн төвөгтэй системд ханасан байдлыг дээд түвшний ачааллын хэмжилтээр нөхөж болно: танай үйлчилгээ давхар урсгалыг зөв зохицуулж чадах уу, зөвхөн 10%-иар илүү траффик хүлээн авч чадах уу, эсвэл одоогийнхоос ч бага урсгалыг зохицуулж чадах уу? Хүсэлтийн нарийн төвөгтэй байдлыг өөрчилдөг параметргүй (жишээ нь: "Надад юу ч өгөхгүй" эсвэл "Надад цорын ганц монотон бүхэл тоо хэрэгтэй" гэх мэт) тохиргоог ховор өөрчилдөг энгийн үйлчилгээний хувьд статик ачааллын туршилтын утга хангалттай байж болно. Өмнөх догол мөрөнд дурдсанчлан ихэнх үйлчилгээнүүд нь дээд хязгаар нь мэдэгдэж байгаа CPU ашиглалт эсвэл сүлжээний зурвасын өргөн гэх мэт шууд бус дохиог ашиглах ёстой. Өсөн нэмэгдэж буй хоцролт нь ихэвчлэн ханасан байдлын гол үзүүлэлт юм. Жижиг цонхонд (жишээ нь нэг минут) 99 дэх хувийн хариу өгөх хугацааг хэмжих нь маш эрт ханалтын дохиог өгч чадна.
Эцэст нь ханалт нь удахгүй болох ханалтын талаарх таамаглалтай холбоотой, тухайлбал: "Таны мэдээллийн сан 4 цагийн дотор таны хатуу дискийг дүүргэх бололтой."
Хэрэв та бүх дөрвөн алтан дохиог хэмжиж, хэмжүүрүүдийн аль нэгэнд нь асуудал (эсвэл ханасан тохиолдолд бараг л асуудал) байвал тухайн хүнд мэдэгдвэл таны үйлчилгээ хяналтанд их бага хэмжээгээр хамрагдах болно.
Сүүлний талаар санаа зовох (эсвэл багаж хэрэгсэл, гүйцэтгэл)
Хяналтын системийг эхнээс нь барьж байгуулахдаа дундаж хоцролт, зангилааны төв процессорын дундаж ашиглалт эсвэл мэдээллийн сангийн дундаж ачаалал зэрэгт суурилсан системийг хөгжүүлэх сонирхолтой байдаг. Сүүлийн хоёр жишээний аюул нь тодорхой байна: процессорууд болон мэдээллийн сангууд урьдчилан таамаглах аргагүй байдлаар устгагдсан. Энэ нь хойшлуулахад хамаарна. Хэрэв та секундэд 100 хүсэлт гаргахад дунджаар 1000 мс хоцролттой вэб үйлчилгээг ажиллуулж байгаа бол хүсэлтийн 1% нь 5 секунд зарцуулдаг. Хэрэв хэрэглэгчид ийм олон вэб үйлчилгээнээс хамааралтай бол нэг арын хэсгийн 99 дэх хувь нь интерфэйсийн медиан хариу өгөх хугацаа болж чадна.
Удаан дундаж болон маш удаан хүсэлтийг хооронд нь ялгах хамгийн энгийн арга бол бодит саатал гэхээсээ илүү статистикт илэрхийлсэн хүсэлтүүдийн хэмжилтийг цуглуулах явдал юм (гистограмм нь харуулахад тохиромжтой хэрэгсэл юм). 0 мс-ээс 10 мс-ийн хооронд, 10 мс-ээс 30 мс-ийн хооронд, 30 мс-ээс 100 мс-ийн хооронд, 100 мс-ээс 300 мс-ийн хооронд гэх мэт. Гистограмын хязгаарыг ойролцоогоор экспоненциалаар (3 орчим дахин) өргөтгөх нь хүсэлтийн хуваарилалтыг төсөөлөхөд хялбар арга юм.
Хэмжилтийн зөв ширхэглэлийг сонгох
Системийн янз бүрийн элементүүдийг янз бүрийн түвшний нарийвчлалтайгаар хэмжих ёстой. Жишээлбэл:
- Тодорхой хугацааны туршид CPU-ийн ашиглалтыг ажиглавал өндөр хоцрогдолд хүргэдэг урт өсөлтийг харуулахгүй.
- Нөгөөтэйгүүр, жилд 9 цагаас илүүгүй зогсолт (жилийн 99,9%) вэб үйлчилгээний хувьд минут тутамд нэгээс хоёроос илүү удаа HTTP 200-ийн хариуг шалгах нь шаардлагагүй юм.
- Үүний нэгэн адил хатуу дискний сул зайг 99,9% байгаа эсэхийг 1-2 минут тутамд нэгээс олон удаа шалгах нь шаардлагагүй байж магадгүй юм.
Хэмжээг хэрхэн яаж зохион байгуулахдаа анхаар. Секундэд 1 CPU-ийн ашиглалтын хурд нь сонирхолтой өгөгдөл өгөх боломжтой боловч ийм давтамжтай хэмжилт нь цуглуулах, хадгалах, дүн шинжилгээ хийхэд маш их зардал шаарддаг. Хэрэв таны хяналтын зорилго өндөр нарийвчлал шаарддаг бөгөөд өндөр хариу үйлдэл шаарддаггүй бол та сервер дээр хэмжүүр цуглуулах тохиргоог хийж, дараа нь эдгээр хэмжигдэхүүнүүдийг цуглуулах, нэгтгэх гадаад системийг тохируулах замаар эдгээр зардлыг бууруулж болно. Та чадах уу:
- CPU-ийн хэрэглээг секунд тутамд хэмжинэ.
- Нарийвчилсан мэдээллийг 5% хүртэл бууруул.
- Минут тутамд хэмжигдэхүүнүүдийг нэгтгэнэ.
Энэхүү стратеги нь танд дүн шинжилгээ хийх, хадгалахад өндөр зардал гаргахгүйгээр маш нарийн ширхэгтэй өгөгдлийг цуглуулах боломжийг олгоно.
Аль болох энгийн, гэхдээ хялбар биш
Өөр өөр шаардлагыг давхарлан тавих нь маш нарийн төвөгтэй хяналтын системийг бий болгодог. Жишээлбэл, таны системд дараахь төвөгтэй элементүүд байж болно.
- Хүсэлтийн хоцрогдлын янз бүрийн босгоны дагуу, янз бүрийн хувиар, янз бүрийн хэмжигдэхүүнээр дохио өгдөг.
- Боломжит шалтгааныг илрүүлэх, тодорхойлох нэмэлт код бичих.
- Асуудлын боломжит шалтгаан бүрийн хувьд холбогдох хяналтын самбарыг үүсгэ.
Боломжит хүндрэлийн эх үүсвэрүүд хэзээ ч дуусдаггүй. Бүх програм хангамжийн системүүдийн нэгэн адил хяналт нь маш нарийн төвөгтэй болж, эмзэг, өөрчлөх, засварлахад хэцүү болдог.
Тиймээс хяналтын системээ аль болох хялбарчлах үүднээс зохион бүтээгээрэй. Юуг хянахаа сонгохдоо дараахь зүйлийг санаарай.
- Бодит тохиолдлуудад ихэвчлэн тохиолддог дүрмүүд нь аль болох энгийн, урьдчилан таамаглах боломжтой, найдвартай байх ёстой.
- Өгөгдөл цуглуулах, нэгтгэх, сэрэмжлүүлэхэд зориулсан тохиргоог хааяа хийдэг (жишээ нь, зарим SRE багуудын хувьд улирлаас бага) хасах хэрэгтэй.
- Цуглуулсан боловч урьдчилан харах самбарт харуулаагүй эсвэл ямар нэгэн сэрэмжлүүлэгт ашиглаагүй хэмжигдэхүүнүүдийг устгахад нэр дэвшигчид.
Google-д хэмжүүрүүдийн үндсэн цуглуулга, нэгтгэх нь дохиолол, хяналтын самбартай хослуулан харьцангуй бие даасан систем шиг сайн ажилладаг (Google-ийн хяналтын систем нь үнэндээ хэд хэдэн дэд системд хуваагддаг, гэхдээ ихэвчлэн хүмүүс эдгээр дэд системийн бүх талыг мэддэг). Хяналтыг нарийн төвөгтэй системийг турших бусад аргуудтай хослуулах нь сонирхолтой байж болох юм: системийн нарийвчилсан профайл, үйл явцын дибаг хийх, үл хамаарах зүйл, алдаа дутагдлыг хянах, ачааллын туршилт, бүртгэл цуглуулах, дүн шинжилгээ хийх, замын хөдөлгөөний шалгалт. Эдгээр зүйлсийн ихэнх нь үндсэн хяналттай нийтлэг шинж чанартай байдаг ч тэдгээрийг холих нь хэт олон үр дүнд хүргэж, нарийн төвөгтэй, хэврэг тогтолцоог бий болгоно. Програм хангамжийн хөгжүүлэлтийн бусад олон асуудлын нэгэн адил тодорхой, энгийн, сул холбогдсон интеграцийн цэгүүд бүхий өөр өөр системийг дэмжих нь хамгийн сайн стратеги юм (жишээлбэл, вэб API ашиглан хураангуй мэдээллийг урт хугацаанд тогтмол байлгах форматаар авах боломжтой. ).
Зарчмуудыг хооронд нь холбох
Энэ бүлэгт авч үзсэн зарчмуудыг Google SRE-ийн багууд баталж, дагаж мөрддөг хяналт, сэрэмжлүүлэг философи болгон нэгтгэж болно. Энэхүү хяналтын философийг баримтлах нь зүйтэй бөгөөд энэ нь сэрэмжлүүлэх арга зүйг бий болгох эсвэл өөрчлөхөд сайн эхлэл бөгөөд танай байгууллагын хэмжээ, үйлчилгээ, системийн нарийн төвөгтэй байдлаас үл хамааран үйл ажиллагаандаа зөв асуулт тавихад тусална.
Хяналт, сэрэмжлүүлгийн дүрмийг бий болгохдоо дараах асуултуудыг асуувал худал мэдээлэл болон шаардлагагүй сэрэмжлүүлгээс зайлсхийхэд тусална.
- Энэ дүрэм нь яаралтай, арга хэмжээ авахыг уриалж, хэрэглэгчдэд зайлшгүй нөлөөлсөн системийн төлөвийг илрүүлдэг үү?
- Энэ нь хоргүй гэдгийг мэдсээр байж энэ анхааруулгыг үл тоомсорлож болох уу? Би хэзээ, яагаад энэ анхааруулгыг үл тоомсорлож, энэ хувилбараас хэрхэн зайлсхийх вэ?
- Энэ анхааруулга нь хэрэглэгчдэд сөрөг нөлөө үзүүлж байна гэсэн үг үү? Хэрэглэгчдэд сөргөөр нөлөөлдөггүй нөхцөл байдал, тухайлбал, замын хөдөлгөөний шүүлтүүр эсвэл туршилтын системийг ашиглах үед анхааруулга шүүж байх ёстой юу?
- Би энэ сэрэмжлүүлгийн хариуд арга хэмжээ авч болох уу? Эдгээр арга хэмжээг яаралтай авах уу эсвэл өглөө болтол хүлээж чадах уу? Үйлдлийг автоматжуулах нь аюулгүй юу? Энэ арга хэмжээ нь урт хугацааны шийдэл байх уу, эсвэл богино хугацааны шийдэл байх уу?
- Зарим хүмүүс энэ асуудлын талаар хэд хэдэн анхааруулга авдаг, тэгвэл тоог багасгах боломжтой юу?
Эдгээр асуултууд нь дохиолол, дохиоллын системийн үндсэн философийг тусгасан болно.
- Сэрэмжлүүлэг ирэх болгонд би яаралтай хариу арга хэмжээ авах шаардлагатай болдог. Би ядрахаасаа өмнө өдөрт хэд хэдэн удаа яарч чадна.
- Сэрэмжлүүлэг бүр шинэчлэгдсэн байх ёстой.
- Сэрэмжлүүлгийн хариу болгонд хүний оролцоо шаардлагатай. Хэрэв мэдэгдлийг автоматаар боловсруулах боломжтой бол энэ нь ирэх ёсгүй.
- Анхааруулга нь шинэ асуудал эсвэл урьд өмнө тохиолдож байгаагүй үйл явдлын тухай байх ёстой.
Энэ арга нь тодорхой ялгааг бүдгэрүүлдэг: хэрэв дохио нь өмнөх дөрвөн нөхцөлийг хангасан бол дохиог White-box хяналтын систем эсвэл Black-Box-аас илгээсэн эсэх нь хамаагүй. Энэ арга нь тодорхой ялгааг бататгаж өгдөг: шалтгаанаас илүү шинж тэмдгийг тодорхойлоход илүү их хүчин чармайлт гаргах нь дээр; Шалтгаануудын тухайд та зөвхөн зайлшгүй шалтгаануудын талаар санаа зовох хэрэгтэй.
Урт хугацааны хяналт
Орчин үеийн үйлдвэрлэлийн орчинд хяналтын системүүд нь програм хангамжийн бүтэц, ачааллын шинж чанар, гүйцэтгэлийн зорилтуудыг өөрчлөх замаар байнга хөгжиж буй үйлдвэрлэлийн системийг хянадаг. Одоогоор автоматжуулахад хэцүү байгаа сэрэмжлүүлэг нь нийтлэг болж магадгүй, магадгүй анхаарал хандуулах ёстой. Энэ үед хэн нэгэн асуудлын үндсэн шалтгааныг олж, засах ёстой; хэрэв ийм шийдвэр гаргах боломжгүй бол дохиоллын хариу үйлдэл нь бүрэн автоматжуулалтыг шаарддаг.
Хяналтын шийдвэрийг урт хугацааны зорилгыг бодолцон гаргах нь чухал. Өнөөдөр гарч буй дохио бүр нь хүнийг маргааш системийг сайжруулахаас холдуулдаг тул урт хугацаанд хяналтын системийг сайжруулахад шаардагдах хугацаанд бүтээмжтэй системийн хүртээмж, гүйцэтгэл буурч байдаг. Энэ үзэгдлийг харуулсан хоёр жишээг авч үзье.
Bigtable SRE: Хэт сэрэмжтэй байдлын тухай түүх
Google-ийн дотоод дэд бүтцийг ихэвчлэн Үйлчилгээний Түвшин (SLO)-аар хэмждэг. Хэдэн жилийн өмнө Bigtable үйлчилгээний SLO нь ажиллаж байгаа үйлчлүүлэгчийг дуурайлган хийсэн нийлэг гүйлгээний дундаж гүйцэтгэлд суурилсан байв. Bigtable болон хадгалах стекийн доод түвшний асуудлуудын улмаас дундаж гүйцэтгэл нь "том" сүүлээс шалтгаалсан: асуулгын хамгийн муу 5% нь бусад асуулгаас хамаагүй удаан байсан.
SLO-ийн босго хүрэхэд и-мэйл мэдэгдлийг илгээсэн бөгөөд SLO хэтэрсэн үед мессенжерийн анхааруулга илгээсэн. Энэ хоёр төрлийн сэрэмжлүүлэг нь нилээд олон удаа илгээгдэж, инженерчлэлийн хувьд хүлээн зөвшөөрөгдөөгүй их цаг зарцуулсан: баг нь үнэхээр хамааралтай хэд хэдэн дохиог олохын тулд сэрэмжлүүлгийг задлан шинжлэхэд ихээхэн цаг зарцуулсан. Зөвхөн цөөн хэдэн сэрэмжлүүлэг нь тухайн асуудалд зориулагдсан байсан тул бид хэрэглэгчдэд үнэхээр нөлөөлсөн асуудлыг орхигдуулдаг. Сэрэмжлүүлэгүүдийн ихэнх нь ойлгомжтой дэд бүтцийн асуудлаас болж яаралтай биш байсан бөгөөд стандарт байдлаар зохицуулагдсан эсвэл огт зохицуулагдаагүй.
Нөхцөл байдлыг засахын тулд баг гурван үндсэн арга барилыг ашигласан: Bigtable-ийн гүйцэтгэлийг сайжруулахын тулд бид шаргуу ажиллахын зэрэгцээ асуулгад хариу өгөх саатлын 75 дахь хувийг түр хугацаанд SLO зорилт болгон тавьсан. Маш олон байсан тул оношлоход цаг алдах боломжгүй байсан тул бид мөн имэйлийн сэрэмжлүүлгийг унтраасан.
Энэхүү стратеги нь тактикийн асуудлыг байнга засахын оронд Bigtable болон хадгалах стекийн доод давхаргын урт хугацааны асуудлуудыг шийдэж эхлэх боломжийг бидэнд олгосон. Инженерүүд дохиогоор байнга бөмбөгддөггүй байсан ч ажлаа хийж чаддаг байсан. Эцсийн эцэст, сэрэмжлүүлгийг боловсруулахад түр саатсан нь үйлчилгээний чанарыг сайжруулах боломжийг бидэнд олгосон.
Gmail: Урьдчилан таамаглах боломжтой, алгоритмын хүний хариу үйлдэл
Хамгийн эхэнд Gmail нь хайлтын индексийн хэсгүүдийг багцлах зорилгоор бүтээгдсэн өөрчилсөн Workqueue процессын хяналтын систем дээр бүтээгдсэн. Ажлын дарааллыг урт хугацааны процесст тохируулж, дараа нь Gmail-д ашигласан боловч тунгалаг хуваарийн кодын зарим алдааг засахад маш хэцүү байсан.
Тухайн үед Gmail-ийн хяналт нь Workqueue-г ашиглан бие даасан ажлуудыг цуцалсан үед дохио өгдөг байхаар бүтэцтэй байсан. Энэ арга нь тийм ч тохиромжтой биш байсан, учир нь тэр үед Gmail олон мянган даалгавруудыг гүйцэтгэсэн бөгөөд тус бүрийг манай хэрэглэгчдийн хэдэн хувьд нь өгдөг байв. Бид Gmail-ийн хэрэглэгчдэд сайн хэрэглэгчийн туршлага бий болгохын тулд маш их анхаарал хандуулсан боловч олон анхааруулгатай ажиллах боломжгүй байсан.
Энэ асуудлыг шийдэхийн тулд Gmail SRE нь хэрэглэгчдэд үзүүлэх нөлөөллийг багасгахын тулд хуваарьт дибаг хийхэд туслах хэрэгслийг бүтээсэн. Асуудлыг олохоос эхлээд урт хугацааны шийдэл олох хүртэл бүхэл бүтэн мөчлөгийг автоматжуулах эсэх талаар багийнхан хэд хэдэн удаа ярилцсан боловч зарим нь ийм шийдэл нь асуудлыг бодитоор шийдвэрлэхийг хойшлуулна гэж санаа зовж байсан.
Багийн доторх ийм хурцадмал байдал нийтлэг байсан бөгөөд ихэвчлэн сахилга батдаа үл итгэх байдлыг илэрхийлдэг: багийн зарим гишүүд зөв засах цаг гаргахыг хүсдэг бол зарим нь эцсийн засвар мартагдаж, түр зуурын засвар үүрд үргэлжлэх болно гэж санаа зовдог. Асуудлыг байнгын засварын оронд түр зуур засах нь дэндүү амархан тул энэ асуудал анхаарал хандуулах ёстой. Удаан хугацааны засварыг хэрэгжүүлэхэд менежерүүд болон техникийн ажилтнууд гол үүрэг гүйцэтгэдэг бөгөөд эхний өвдөлт намдаж байсан ч урт хугацааны урт хугацааны засваруудыг дэмжиж, эрэмбэлэн эрэмбэлдэг.
Тогтмол давтагдах сэрэмжлүүлэг, алгоритмын хариу үйлдэл нь улаан туг байх ёстой. Танай баг эдгээр сэрэмжлүүлгийг автоматжуулахаас татгалзаж байгаа нь баг алгоритмуудад итгэж чадна гэдэгт итгэлгүй байна гэсэн үг. Энэ бол шийдвэрлэх шаардлагатай ноцтой асуудал юм.
Урт хугацааны
Нийтлэг сэдэв нь Bigtable болон Gmail-ийн жишээнүүдийг холбодог: богино болон урт хугацааны бэлэн байдлын хоорондох өрсөлдөөн. Ихэнхдээ хүчтэй хүчин чармайлт нь эмзэг системийг өндөр хүртээмжтэй болгоход тусалдаг боловч энэ зам нь ихэвчлэн богино хугацаанд үргэлжилдэг бөгөөд багийн ядралт, энэ баатарлаг багийн цөөн тооны гишүүдээс хамааралтай байдаг.
Хяналттай, богино хугацааны хүртээмж буурах нь ихэвчлэн өвдөлттэй байдаг ч системийн урт хугацааны тогтвортой байдалд стратегийн ач холбогдолтой байдаг. Сэрэмжлүүлэг бүрийг тусад нь авч үзэх нь чухал биш, харин дохиоллын нийт хувь хэмжээ нь амьдрах чадвартай баг, таатай таамаглал бүхий эрүүл, зөв хүртээмжтэй системд хүргэж байгаа эсэхийг авч үзэх нь чухал юм. Бид сэрэмжлүүлгийн түвшний статистикийг (ихэвчлэн нэг ээлжинд тохиолдсон тохиолдлоор илэрхийлдэг, осол нь хэд хэдэн холбоотой тохиолдлоос бүрдэх боломжтой) улирал тутмын тайланд удирдлагатай хамтран дүн шинжилгээ хийж, шийдвэр гаргагчдад дохиоллын системийн ачаалал болон багийн ерөнхий эрүүл мэндийг тасралтгүй танилцуулах боломжийг олгодог.
дүгнэлт
Эрүүл хяналт, сэрэмжлүүлэгт хүрэх зам нь энгийн бөгөөд ойлгомжтой. Энэ нь анхааруулга үүсгэж буй асуудлын шинж тэмдгүүдэд анхаарлаа төвлөрүүлж, шалтгааныг хянах нь асуудлыг засахад туслах болно. Өгөгдлийн сангийн ачаалал болон гүйцэтгэлийн хяналтыг шууд өгөгдлийн сан дээр хийх ёстой хэдий ч та хянаж буй стекийн өндөр түвшинд байх тусам шинж тэмдгийг хянах нь илүү хялбар байдаг. Имэйл мэдэгдлүүд нь маш хязгаарлагдмал хэрэглээтэй бөгөөд дуу чимээ ихсэх хандлагатай байдаг; Үүний оронд та цахим шуудангаар анхааруулж байгаа бүх асуудлыг хянадаг хяналтын самбар ашиглах хэрэгтэй. Хяналтын самбарыг үйл явдлын бүртгэлтэй хослуулж, түүхэн хамаарлыг шинжлэх боломжтой.
Урт хугацаанд шинж тэмдгийн дохио болон удахгүй болох бодит асуудлуудыг амжилттай сольж, хяналт нь хурдан оношлоход дэмжлэг үзүүлэхийн тулд зорилтуудыг тохируулах шаардлагатай.
Орчуулгыг дуустал нь уншсан танд баярлалаа. Хяналтын талаар миний телеграм сувагт бүртгүүлнэ үү и .
Эх сурвалж: www.habr.com