Анхаарна уу. орчуулга.: Энэхүү нийтлэл нь МТ систем дэх алдааны үр дагаврыг бууруулах туршилтын ач холбогдлыг энгийн бөгөөд ойлгомжтой байдлаар тайлбарлахыг зорьсон AWS технологийн евангелист Адриан Хорнсбигийн гайхалтай цуврал нийтлэлүүдийг үргэлжлүүлж байна.
"Хэрэв та төлөвлөгөөгөө бэлдэж чадаагүй бол бүтэлгүйтэх төлөвлөгөөтэй байна." - Бенжамин Франклин
В Энэхүү цуврал нийтлэлд би эмх замбараагүй инженерчлэлийн тухай ойлголтыг танилцуулж, үйлдвэрлэлийн доголдолд хүргэхээс өмнө системийн алдаа дутагдлыг олж засварлахад хэрхэн тусалдаг талаар тайлбарласан. Түүнчлэн эмх замбараагүй инженерчлэл нь байгууллагуудын соёлын эерэг өөрчлөлтийг хэрхэн дэмждэг талаар ярилцав.
Эхний хэсгийн төгсгөлд би "системд алдаа гаргах арга хэрэгсэл, арга хэрэгслийн талаар" ярихаа амласан. Харамсалтай нь, миний толгой энэ талаар өөрийн гэсэн төлөвлөгөөтэй байсан бөгөөд энэ нийтлэлд би эмх замбараагүй инженерчлэлд орохыг хүсдэг хүмүүсийн дунд гарч ирдэг хамгийн түгээмэл асуултанд хариулахыг хичээх болно. Эхлээд юуг эвдэх вэ?
Гайхалтай асуулт! Гэсэн хэдий ч түүнд энэ панда тийм ч их санаа зовдоггүй бололтой...
Эмх замбараагүй пандатай битгий хутгалд!
Товчхондоо: Хүсэлтийн замын дагуух чухал үйлчилгээнүүдийг чиглүүлнэ.
Илүү урт боловч илүү тодорхой хариулт: Эмх замбараагүй байдлын туршилтыг хаанаас эхлэхээ ойлгохын тулд гурван зүйлд анхаарлаа хандуулаарай.
- Хар л даа ослын түүх мөн хэв маягийг тодорхойлох;
- Шийдвэрлэх чухал хамаарал;
- гэж нэрлэгддэг зүйлийг ашигла хэт итгэх нөлөө.
Энэ нь инээдтэй, гэхдээ энэ хэсгийг хялбархан дуудаж болно "Өөрийгөө нээж, гэгээрэлд хүрэх аялал". Үүн дээр бид хэд хэдэн гайхалтай хэрэгслүүдээр "тоглож" эхэлнэ.
1. Хариулт нь өнгөрсөнд байна
Хэрэв та санаж байгаа бол эхний хэсэгт би алдааг залруулах (COE) гэсэн ойлголтыг танилцуулсан - бид алдаагаа шинжлэх арга - технологи, үйл явц эсвэл зохион байгуулалт дахь алдааг тэдгээрийн шалтгааныг ойлгох, урьдчилан сэргийлэх зорилгоор. ирээдүйд давтагдах. Ерөнхийдөө эндээс л эхлэх хэрэгтэй.
"Одоог ойлгохын тулд өнгөрсөн үеийг мэдэх хэрэгтэй." - Карл Саган
Алдаа дутагдлын түүхийг харж, тэдгээрийг COE эсвэл үхлийн дараах шинжилгээнд тэмдэглэж, ангил. Ихэнхдээ асуудалд хүргэдэг нийтлэг хэв маягийг тодорхойлж, COE бүрийн хувьд дараах асуултыг өөрөөсөө асуу.
"Үүнийг урьдчилан таамаглаж, буруу тарилга хийснээр урьдчилан сэргийлэх боломжтой байсан уу?"
Би карьерынхаа эхэн үед нэг бүтэлгүйтлийг санаж байна. Хэрэв бид эмх замбараагүй байдлын хэд хэдэн туршилт хийсэн бол үүнээс амархан урьдчилан сэргийлэх боломжтой байсан.
Ердийн нөхцөлд арын инстанцууд нь эрүүл мэндийн үзлэгт хариу үйлдэл үзүүлдэг ). ELB нь хүсэлтийг эрүүл тохиолдол руу шилжүүлэхийн тулд эдгээр шалгалтыг ашигладаг. Тухайн тохиолдол "эрүүл бус" болох нь тогтоогдвол ELB түүнд хүсэлт илгээхээ больдог. Амжилттай маркетингийн кампанит ажил хийсний дараа нэг өдөр замын хөдөлгөөний хэмжээ нэмэгдэж, эрүүл мэндийн үзлэгт ердийнхөөс илүү удаан хариу үйлдэл үзүүлж эхлэв. Эдгээр эрүүл мэндийн үзлэгт хамрагдсан гэж хэлэх ёстой , өөрөөр хэлбэл, хамаарлын төлөвийг шалгасан.
Гэсэн хэдий ч хэсэг хугацаанд бүх зүйл сайхан байсан.
Дараа нь нэлээд стресстэй нөхцөлд аль хэдийн тохиолдлуудын нэг нь чухал биш, тогтмол ETL cron даалгаврыг гүйцэтгэж эхлэв. Өндөр ачаалал ба cronjob-ийн хослол нь CPU-ийн ашиглалтыг бараг 100% болгосон. Процессорын хэт ачаалал нь эрүүл мэндийн шалгалтын хариуг улам удаашруулж, улмаар ELB уг жишээг гүйцэтгэлийн асуудалтай тулгарсан гэж шийдсэн. Хүлээгдэж байсанчлан тэнцвэржүүлэгч түүнд траффик хуваарилахаа больсон нь эргээд бүлэгт үлдсэн тохиолдлуудын ачаалал нэмэгдэхэд хүргэсэн.
Гэнэт бусад бүх тохиолдлууд эрүүл мэндийн үзлэгт хамрагдаж чадахгүй болов.
Шинэ жишээ эхлүүлэхэд багцуудыг татаж суулгах шаардлагатай байсан бөгөөд автомат масштабын бүлэгт нэг нэгээр нь идэвхгүй болгохын тулд ELB-ээс хамаагүй удаан хугацаа зарцуулсан. Удалгүй бүх үйл явц эгзэгтэй цэгт хүрч, програм эвдэрсэн нь тодорхой байна.
Дараа нь бид дараахь зүйлийг үүрд ойлгосон.
- Шинэ жишээ үүсгэх үед програм хангамжийг суулгахад удаан хугацаа шаардагддаг тул хувиршгүй хандлагыг илүүд үзэх нь дээр. .
- Нарийн төвөгтэй нөхцөл байдалд эрүүл мэндийн үзлэг, ELB-ийн хариуг нэн тэргүүнд тавих ёстой - таны хүссэн хамгийн сүүлчийн зүйл бол үлдсэн тохиолдлуудын амьдралыг хүндрүүлэх явдал юм.
- Эрүүл мэндийн үзлэгийн орон нутгийн кэш нь маш их тусалдаг (хэдхэн секунд ч гэсэн).
- Хэцүү нөхцөл байдалд cron даалгавар болон бусад чухал бус процессуудыг бүү ажиллуул - хамгийн чухал ажлуудад нөөцийг хэмнээрэй.
- Автоматаар масштаблахдаа жижиг тохиолдлуудыг ашиглана уу. 10 жижиг сорьцын бүлэг нь 4 томоос илүү сайн; хэрэв нэг тохиолдол амжилтгүй болвол эхний тохиолдолд замын хөдөлгөөний 10% нь 9 цэг дээр, хоёр дахь нь гурван цэгээс дээш замын хөдөлгөөний 25% -ийг хуваарилна.
Тэгэхээр Энэ нь урьдчилан таамаглаж байсан тул асуудлыг оруулснаар урьдчилан сэргийлэх боломжтой байсан уу?
Тийм, мөн хэд хэдэн аргаар.
Нэгдүгээрт, зэрэг хэрэгслүүдийг ашиглан CPU-ийн өндөр хэрэглээг дуурайлган хийх замаар буюу :
❯ stress-ng --matrix 1 -t 60s
стресс-ng
Хоёрдугаарт, жишээг хэт ачаалах замаар болон бусад ижил төстэй хэрэгслүүд:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Туршилтууд нь харьцангуй энгийн боловч жинхэнэ бүтэлгүйтлийн стрессийг даван туулах шаардлагагүйгээр сэтгэн бодоход сайн тэжээл өгч чадна.
Гэсэн хэдий ч, үүгээр бүү зогс. Туршилтын орчинд ослыг хуулбарлахыг оролдож, асуултын хариултыг шалгана уу "Үүнийг урьдчилан харж, алдаа гаргах замаар урьдчилан сэргийлэх боломжтой байсан уу?" Энэ бол таамаглалыг шалгах эмх замбараагүй байдлын туршилтын доторх жижиг эмх замбараагүй туршилт боловч бүтэлгүйтлээс эхэлдэг.
Энэ зүүд байсан уу, эсвэл үнэхээр болсон уу?
Тиймээс бүтэлгүйтлийн түүхийг судалж, дүн шинжилгээ хий EOC, тэдгээрийг "хитийн радиус" буюу илүү нарийвчлалтайгаар өртсөн үйлчлүүлэгчдийн тоогоор тэмдэглэж, ангилаад дараа нь хэв маягийг хайж олоорой. Асуудлыг танилцуулснаар үүнийг урьдчилан таамаглаж, урьдчилан сэргийлэх боломжтой байсан эсэхийг өөрөөсөө асуу. Хариултаа шалгана уу.
Дараа нь хамгийн том хүрээтэй хамгийн нийтлэг хэв маяг руу шилжинэ.
2. Хамааралтай байдлын газрын зургийг бүтээх
Өргөдөлийнхөө талаар хэсэг хугацаанд бодож үзээрэй. Түүний хамаарлын тодорхой газрын зураг бий юу? Хэрэв бүтэлгүйтсэн тохиолдолд тэд ямар нөлөө үзүүлэхийг та мэдэх үү?
Хэрэв та програмынхаа кодыг сайн мэдэхгүй эсвэл маш том болсон бол код нь юу хийдэг, ямар хамааралтай болохыг ойлгоход хэцүү байж болно. Эдгээр хамаарал болон тэдгээрийн програм болон хэрэглэгчдэд үзүүлэх нөлөөллийг ойлгох нь эмх замбараагүй инженерчлэлийг хаанаас эхлэхээ мэдэхэд чухал ач холбогдолтой: эхлэлийн цэг нь хамгийн том нөлөөллийн радиустай бүрэлдэхүүн хэсэг юм.
Хамааралтай байдлыг тодорхойлж, баримтжуулахыг "гэж нэрлэдэг.хараат байдлын газрын зургийг бий болгох» (хамааралтай байдлын зураглал). Энэ нь ихэвчлэн кодын профайл хийх хэрэгслүүдийг ашиглан том кодын суурьтай програмуудад хийгддэг. (кодын профайл) болон багаж хэрэгсэл (багаж хэрэгсэл). Мөн та сүлжээний урсгалыг хянах замаар газрын зураг үүсгэж болно.
Гэсэн хэдий ч бүх хамаарал нь ижил биш (энэ нь үйл явцыг улам хүндрүүлдэг). Зарим шүүмжлэлтэй, бусад - хоёрдогч (наад зах нь онолын хувьд, нэн чухал биш гэж үздэг хамааралтай холбоотой асуудлаас болж осол ихэвчлэн гардаг тул).
Чухал хамааралгүйгээр үйлчилгээ ажиллах боломжгүй. Чухал бус хамаарал "байх ёсгүй» унасан тохиолдолд үйлчилгээнд нөлөөлөх. Хамааралтай байдлыг ойлгохын тулд та өөрийн програмын ашигладаг API-уудын талаар тодорхой ойлголттой байх хэрэгтэй. Энэ нь санагдахаас хамаагүй хэцүү байж болох юм - наад зах нь том програмуудын хувьд.
Бүх API-г дамжуулж эхэл. Хамгийн ихийг тодруул чухал бөгөөд чухал. Авах хамаарал кодын агуулахаас шалгана уу холболтын бүртгэлүүд, дараа нь харах баримт бичиг (мэдээжийн хэрэг, хэрэв байгаа бол - тэгэхгүй бол танд байгаа хэвээр байнаоилүү том асуудал). Хэрэгслийг ашиглана уу профайл хийх, мөрдөх, гадаад дуудлагыг шүүнэ.
гэх мэт програмуудыг ашиглаж болно netstat - систем дэх бүх сүлжээний холболтуудын (идэвхтэй залгуурууд) жагсаалтыг харуулдаг тушаалын мөрийн хэрэгсэл. Жишээлбэл, одоогийн бүх холболтыг жагсаахын тулд дараахыг бичнэ үү:
❯ netstat -a | more
AWS дээр та ашиглаж болно (урсгалын бүртгэл) VPC нь VPC-ийн сүлжээний интерфэйсүүд рүү орж байгаа IP траффикийн талаарх мэдээллийг цуглуулах боломжийг олгодог арга юм. Ийм бүртгэлүүд нь бусад ажлуудад тусалж чадна - жишээлбэл, тодорхой урсгал яагаад инстант руу хүрэхгүй байгаа вэ гэсэн асуултын хариултыг олоход тусалдаг.
Та бас ашиглаж болно . Рентген туяа нь танд "эцсийн" нарийвчилсан мэдээллийг авах боломжийг олгодог. (эцсийн төгсгөл) хүсэлтийг програмаар дамжуулж буй тойм, мөн програмын үндсэн бүрэлдэхүүн хэсгүүдийн газрын зургийг бүтээдэг. Хэрэв та хамаарлыг тодорхойлох шаардлагатай бол маш тохиромжтой.
AWS рентген консол
Сүлжээний хамаарлын зураг нь зөвхөн хэсэгчилсэн шийдэл юм. Тиймээ, энэ нь аль программтай харилцаж байгааг харуулдаг, гэхдээ бусад хамаарал байдаг.
Олон програмууд хамааралтай холбогдохын тулд DNS ашигладаг бол зарим нь тохиргооны файлууд дахь үйлчилгээний нээлт эсвэл бүр хатуу кодлогдсон IP хаягуудыг ашиглаж болно (жишээ нь. /etc/hosts).
Жишээлбэл, та үүсгэж болно тусламжтайгаар iptables юу эвдэрч байгааг хараарай. Үүнийг хийхийн тулд дараах тушаалыг оруулна уу.
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS хар нүх
Хэрэв байгаа бол /etc/hosts эсвэл бусад тохиргооны файлуудыг ашиглавал та юу ч мэдэхгүй IP хаягуудыг олох болно (тиймээ, харамсалтай нь ийм зүйл тохиолддог), та дахин аврах ажилд ирж болно. iptables. Та нээсэн гэж бодъё 8.8.8.8 Энэ нь Google-ийн нийтийн DNS серверийн хаяг гэдгийг мэдэхгүй байна. Ашиглах замаар iptables Та дараах тушаалуудыг ашиглан энэ хаяг руу орж ирж буй урсгалыг хааж болно.
❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"
Хандалтыг хааж байна
Эхний дүрэм нь Google-ийн нийтийн DNS-ээс бүх пакетуудыг устгадаг: ping ажилладаг боловч пакетуудыг буцааж өгөхгүй. Хоёрдахь дүрэм нь таны системээс ирсэн бүх пакетуудыг Google-ийн нийтийн DNS руу буулгадаг ping бид авдаг Үйл ажиллагаа явуулахыг зөвшөөрөхгүй.
Анхаарна уу: Энэ тохиолдолд ашиглах нь илүү дээр байх болно whois 8.8.8.8, гэхдээ энэ бол зүгээр л жишээ юм.
TCP болон UDP-г ашигладаг бүх зүйл IP-ээс хамаардаг тул бид туулайн нүх рүү улам гүнзгий орж чадна. Ихэнх тохиолдолд IP нь ARP-тэй холбоотой байдаг. Галт хананы талаар бүү мартаарай ...
Хэрэв чи улаан эм уувал гайхамшгийн оронд үлдэнэ, би чамд туулайн нүх ямар гүнд байдгийг харуулах болно."
Илүү радикал арга бол салгах машинуудыг нэг нэгээр нь хараад юу эвдэрсэнийг хараарай... "эмх замбараагүй сармагчин" болно. Мэдээжийн хэрэг, олон үйлдвэрлэлийн системүүд ийм харгис хэрцгий довтолгоонд зориулагдаагүй ч ядаж туршилтын орчинд туршиж үзэх боломжтой.
Хараат байдлын газрын зургийг бүтээх нь ихэвчлэн маш урт ажил юм. Би саяхан олон зуун бичил үйлчилгээ, командын хамаарлын газрын зургийг хагас автоматаар үүсгэдэг хэрэгсэл боловсруулахад бараг 2 жил зарцуулсан үйлчлүүлэгчтэй ярилцлаа.
Гэсэн хэдий ч үр дүн нь маш сонирхолтой бөгөөд ашигтай юм. Та өөрийн систем, түүний хамаарал, үйлдлийн талаар маш их зүйлийг сурах болно. Дахин хэлэхэд тэвчээртэй байгаарай: аялал өөрөө хамгийн чухал.
3. Өөртөө хэт итгэхээс болгоомжил
"Хэн юуг мөрөөддөг, түүнд итгэдэг." - Демосфен
Та сонсож байсан уу хэт итгэх нөлөө?
Википедиагийн хэлснээр, хэт итгэлтэй байдлын үр нөлөө нь "хүний үйлдэл, шийдвэрт итгэх итгэл нь эдгээр дүгнэлтийн бодит үнэн зөв байдлаас хамаагүй илүү байдаг танин мэдэхүйн гажуудал, ялангуяа итгэлийн түвшин харьцангуй өндөр байх үед" юм.
Зөн совин, туршлага дээр үндэслэн...
Миний туршлагаас харахад энэ гажуудал нь эмх замбараагүй инженерчлэлийг хаанаас эхлэх талаар маш сайн санаа юм.
Хэт итгэлтэй оператороос болгоомжил:
Чарли: "Энэ зүйл таван жилийн турш унасангүй, бүх зүйл сайхан байна!"
Сүйрэл: "Хүлээгээрэй... Би удахгүй очно!"
Хэт их өөртөө итгэх итгэлийн үр дагавар болох гажуудал нь түүнд нөлөөлж буй янз бүрийн хүчин зүйлээс шалтгаалж нууцлаг, бүр аюултай зүйл юм. Энэ нь ялангуяа багийн гишүүд ямар нэгэн технологид сэтгэл зүрхээ урсгасан эсвэл түүнийг "засах" гэж маш их цаг зарцуулсан үед үнэн юм.
Дүгнэх
Эмх замбараагүй байдлын инженерчлэлийн эхлэлийн цэгийг хайх нь үргэлж хүлээгдэж байснаас илүү үр дүнг авчирдаг бөгөөд аливаа зүйлийг хэтэрхий хурдан эвдэж эхэлдэг багууд (эмх замбараагүй байдлын) илүү глобал, сонирхолтой мөн чанарыг мартдаг.инженерчлэл - бүтээлч хэрэглээ шинжлэх ухааны аргууд и эмпирик нотолгоо (програм хангамж) системийг зохион бүтээх, хөгжүүлэх, ажиллуулах, засвар үйлчилгээ, сайжруулахад зориулагдсан.
Үүгээр хоёрдугаар хэсгийг дуусгаж байна. Сэтгэгдэл бичих, санал бодлоо хуваалцах эсвэл зүгээр л алгаа ташина уу . Дараагийн хэсэгт I Үнэхээр Би алдааг системд нэвтрүүлэх хэрэгсэл, аргуудыг авч үзэх болно. хүртэл!
Орчуулагчийн жич
Мөн манай блог дээрээс уншина уу:
- «";
- «";
- «";
- «".
Эх сурвалж: www.habr.com