Qeyd. tərcümə.: Bu məqalə İT sistemlərində nasazlıqların nəticələrini azaltmaq üçün eksperimentin əhəmiyyətini sadə və aydın şəkildə izah etməyə çalışan AWS texnologiya evangelist Adrian Hornsby-nin böyük məqalələr silsiləsi ilə davam edir.
"Əgər bir plan hazırlaya bilmirsənsə, deməli uğursuz olmağı planlaşdırırsan." - Benjamin Franklin
В Bu məqalələr silsiləsində mən xaos mühəndisliyi anlayışını təqdim etdim və onun sistemdəki çatışmazlıqları istehsal uğursuzluğuna gətirib çıxarmazdan əvvəl tapmaq və düzəltməyə necə kömək etdiyini izah etdim. O, həmçinin xaos mühəndisliyinin təşkilatlar daxilində müsbət mədəni dəyişikliyi necə təşviq etdiyini müzakirə etdi.
Birinci hissənin sonunda mən “sistemə nasazlıqların daxil edilməsi üçün alətlər və üsullar” haqqında danışmağa söz verdim. Təəssüf ki, başımın bununla bağlı öz planları var idi və bu yazıda xaos mühəndisliyinə girmək istəyən insanlar arasında yaranan ən populyar suala cavab verməyə çalışacağam: Əvvəlcə nəyi qırmaq lazımdır?
Əla sual! Ancaq bu panda onu xüsusilə narahat etmir ...
Xaos pandası ilə qarışmayın!
Qısa cavab: Tələb yolu boyunca kritik xidmətləri hədəfləyin.
Daha uzun, lakin daha aydın cavab: Xaosla eksperimentə haradan başlamaq lazım olduğunu başa düşmək üçün üç sahəyə diqqət yetirin:
- Baxın qəza tarixi və nümunələri müəyyən etmək;
- Qərar verin kritik asılılıqlar;
- Sözdə istifadə edin həddindən artıq güvən təsiri.
Gülməli, amma bu hissəni asanlıqla adlandırmaq olar "Özünü kəşf etməyə və maariflənməyə səyahət". Orada bəzi gözəl alətlərlə "oynaya" başlayacağıq.
1. Cavab keçmişdə yatır
Xatırlayırsınızsa, birinci hissədə Səhvlərin Korreksiyası (COE) anlayışını təqdim etdim - səhvlərimizi - texnologiyada, prosesdə və ya təşkilatda səhvləri - onların səbəblərini anlamaq və qarşısını almaq üçün təhlil etdiyimiz bir üsul. gələcəkdə təkrarlanma. Ümumiyyətlə, buradan başlamaq lazımdır.
"Bu günü anlamaq üçün keçmişi bilmək lazımdır." - Karl Saqan
Uğursuzluqların tarixinə baxın, onları COE və ya postmortemlərdə etiketləyin və təsnif edin. Tez-tez problemlərə gətirib çıxaran ümumi nümunələri müəyyənləşdirin və hər bir COE üçün özünüzə aşağıdakı sualı verin:
"Bunu proqnozlaşdırmaq və buna görə də səhv inyeksiya ilə qarşısını almaq olardımı?"
Karyeramın əvvəlində bir uğursuzluğu xatırlayıram. Əgər biz bir neçə sadə xaos sınağı keçirsəydik, bunun qarşısını asanlıqla almaq olardı:
Normal şəraitdə, backend nümunələri sağlamlıq yoxlamalarına cavab verir ). ELB sorğuları sağlam nümunələrə yönləndirmək üçün bu yoxlamalardan istifadə edir. Nümunənin “sağlam olmadığı” məlum olduqda, ELB ona sorğu göndərməyi dayandırır. Bir gün, uğurlu marketinq kampaniyasından sonra, trafikin həcmi artdı və arxa uçlar sağlamlıq yoxlamalarına həmişəkindən daha yavaş cavab verməyə başladı. Bu sağlamlıq idarələri edildiyini söyləmək lazımdır , yəni asılılıqların vəziyyəti yoxlanılıb.
Ancaq bir müddət hər şey qaydasında idi.
Sonra, kifayət qədər gərgin şəraitdə, instansiyalardan biri qeyri-kritik, müntəzəm ETL cron tapşırığını yerinə yetirməyə başladı. Yüksək trafik və cronjobun birləşməsi CPU istifadəsini demək olar ki, 100%-ə çatdırdı. CPU həddindən artıq yüklənməsi sağlamlıq yoxlamalarına cavabları daha da yavaşlatdı, o qədər ki, ELB nümunənin performans problemləri ilə üzləşdiyinə qərar verdi. Gözlənildiyi kimi, balanslaşdırıcı ona trafik paylamağı dayandırdı, bu da öz növbəsində qrupda qalan nümunələrdə yükün artmasına səbəb oldu.
Birdən bütün digər hallar da sağlamlıq yoxlamasından keçməyə başladı.
Yeni nümunənin işə salınması paketlərin endirilməsini və quraşdırılmasını tələb etdi və ELB-nin avtomatik miqyaslama qrupunda onları tək-tək söndürməsi üçün sərf etdiyi vaxtdan çox vaxt çəkdi. Aydındır ki, tezliklə bütün proses kritik nöqtəyə çatdı və tətbiq qəzaya uğradı.
Sonra biz həmişə aşağıdakı məqamları başa düşdük:
- Yeni bir nümunə yaratarkən proqram təminatının quraşdırılması uzun müddət tələb edir, dəyişməz yanaşmaya üstünlük vermək daha yaxşıdır və .
- Çətin vəziyyətlərdə sağlamlıq yoxlamalarına və ELB-lərə cavablar prioritet olmalıdır - istədiyiniz son şey qalan hallar üçün həyatı çətinləşdirməkdir.
- Sağlamlıq yoxlamalarının yerli keşləşdirilməsi çox kömək edir (hətta bir neçə saniyə).
- Çətin vəziyyətdə, cron tapşırıqlarını və digər kritik olmayan prosesləri yerinə yetirməyin - ən vacib vəzifələr üçün resurslara qənaət edin.
- Avtomatik ölçmə zamanı daha kiçik nümunələrdən istifadə edin. 10 kiçik nümunədən ibarət qrup 4 böyükdən ibarət qrupdan daha yaxşıdır; bir instansiya uğursuz olarsa, birinci halda trafikin 10%-i 9 bal üzərində, ikincidə isə üç nöqtə üzərində trafikin 25%-i paylanacaq.
Belə ki, bunu qabaqcadan görmək olardı və buna görə də problemi gündəmə gətirməklə qarşısını almaq olardı?
Bəli, və bir neçə yolla.
Birincisi, kimi alətlərdən istifadə edərək yüksək CPU istifadəsini simulyasiya etməklə və ya :
❯ stress-ng --matrix 1 -t 60s
stress-of
İkincisi, nümunəni həddindən artıq yükləməklə və digər oxşar kommunal xidmətlər:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Təcrübələr nisbətən sadədir, lakin əsl uğursuzluq stresindən keçmədən düşüncə üçün yaxşı qida təmin edə bilər.
Lakin orada dayanma. Test mühitində qəzanı təkrarlamağa çalışın və suala cavabınızı yoxlayın "Bunu qabaqcadan görmək olarmı və buna görə də xəta tətbiq etməklə qarşısını almaq olardımı?" Bu, fərziyyələri sınamaq üçün xaos sınağı daxilində mini xaos təcrübəsidir, lakin uğursuzluqla başlayır.
Bu yuxu idi, yoxsa həqiqətən baş verdi?
Beləliklə, uğursuzluqların tarixini öyrənin, təhlil edin EOC, onları "vuruş radiusu"na, daha dəqiq desək, təsirlənən müştərilərin sayına görə etiketləyin və təsnif edin və sonra nümunələri axtarın. Özünüzdən soruşun ki, problemi təqdim etməklə bunu proqnozlaşdırmaq və qarşısını almaq olarmı? Cavabınızı yoxlayın.
Sonra ən geniş diapazonlu ən ümumi nümunələrə keçin.
2. Asılılıq xəritəsini qurun
Müraciətiniz haqqında düşünmək üçün bir az vaxt ayırın. Onun asılılıqlarının aydın xəritəsi varmı? Uğursuzluq olarsa, onların necə təsir edəcəyini bilirsinizmi?
Tətbiqinizin kodu ilə o qədər də tanış deyilsinizsə və ya o, çox böyük olubsa, kodun nə etdiyini və ondan asılılıqların nə olduğunu başa düşmək çətin ola bilər. Bu asılılıqları və onların tətbiqə və istifadəçilərə mümkün təsirini başa düşmək xaos mühəndisliyi ilə haradan başlamaq lazım olduğunu bilmək üçün çox vacibdir: başlanğıc nöqtəsi ən böyük təsir radiusuna malik komponentdir.
Asılılıqların müəyyən edilməsi və sənədləşdirilməsi "adlanır.asılılıq xəritəsinin qurulması» (asılılıq xəritəsi). Bu adətən kod profili alətlərindən istifadə edərək böyük kod bazası olan proqramlar üçün edilir. (kod profili) və alətlər (alətlər). Siz həmçinin şəbəkə trafikinə nəzarət etməklə xəritə yarada bilərsiniz.
Bununla belə, bütün asılılıqlar eyni deyil (bu, prosesi daha da çətinləşdirir). Bəziləri tənqidi, digər - ikinci dərəcəli (ən azı nəzəri cəhətdən, çünki qəzalar tez-tez qeyri-kritik hesab edilən asılılıqlarla bağlı problemlər səbəbindən baş verir).
Kritik asılılıqlar olmadan xidmət işləyə bilməz. Qeyri-kritik asılılıqlar "etməməlidir» düşmə halında xidmətə təsir etmək. Asılılıqları başa düşmək üçün tətbiqiniz tərəfindən istifadə olunan API-lər haqqında aydın anlayışa sahib olmalısınız. Bu, göründüyündən daha çətin ola bilər - ən azı böyük tətbiqlər üçün.
Bütün API-lərdən keçməklə başlayın. Ən çox vurğulayın əhəmiyyətli və kritikdir. Alın bağımlılıkları kod deposundan yoxlayın əlaqə qeydləri, sonra baxın sənədlər (əlbəttə, əgər varsa - əks halda hələ də varоdaha böyük problemlər). üçün alətlərdən istifadə edin profilləşdirmə və izləmə, xarici zəngləri süzün.
kimi proqramlardan istifadə edə bilərsiniz netstat - sistemdəki bütün şəbəkə əlaqələrinin (aktiv rozetkaların) siyahısını göstərən komanda xətti yardım proqramı. Məsələn, bütün cari əlaqələri siyahıya almaq üçün yazın:
❯ netstat -a | more
AWS-də istifadə edə bilərsiniz (axın qeydləri) VPC sizə VPC-də şəbəkə interfeyslərinə gedən və ya ondan gələn IP trafiki haqqında məlumat toplamağa imkan verən üsuldur. Bu cür qeydlər digər tapşırıqlarda da kömək edə bilər - məsələn, müəyyən trafikin niyə instansiyaya çatmadığı sualına cavab tapmaq.
Siz də istifadə edə bilərsiniz . X-Ray ətraflı, "son" əldə etməyə imkan verir (başdan-uca) sorğular tətbiqdə hərəkət edərkən onlara ümumi baxış, həmçinin tətbiqin əsas komponentlərinin xəritəsini qurur. Asılılıqları müəyyən etmək lazımdırsa, çox rahatdır.
AWS X-Ray Konsolu
Şəbəkə asılılığı xəritəsi yalnız qismən həlldir. Bəli, hansı tətbiqin hansı ilə əlaqə saxladığını göstərir, lakin başqa asılılıqlar da var.
Bir çox proqramlar asılılıqlara qoşulmaq üçün DNS-dən istifadə edir, digərləri isə konfiqurasiya fayllarında xidmət kəşfindən və ya hətta sərt kodlu IP ünvanlarından istifadə edə bilər (məsələn. /etc/hosts).
Məsələn, yarada bilərsiniz köməyi ilə iptables və görün nə pozulur. Bunu etmək üçün aşağıdakı əmri daxil edin:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS qara dəliyi
Əgər /etc/hosts və ya digər konfiqurasiya faylları ilə bağlı heç nə bilmədiyiniz IP ünvanlarını tapacaqsınız (bəli, təəssüf ki, bu da olur), yenidən xilasetmə işinə gələ bilərsiniz. iptables. Tutaq ki, siz kəşf etdiniz 8.8.8.8 və bunun Google-un ictimai DNS server ünvanı olduğunu bilmirəm. İstifadə etməklə iptables Aşağıdakı əmrlərdən istifadə edərək bu ünvana gələn və gedən trafiki bloklaya bilərsiniz:
❯ 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"
Giriş bağlanır
Birinci qayda bütün paketləri Google-un ictimai DNS-dən çıxarır: ping işləyir, lakin paketlər geri qaytarılmır. İkinci qayda, cavab olaraq sisteminizdən gələn bütün paketləri Google-un ictimai DNS-inə endirir ping əldə edirik Əməliyyata icazə verilmir.
Qeyd: bu xüsusi halda istifadə etmək daha yaxşı olardı whois 8.8.8.8, lakin bu sadəcə bir nümunədir.
Dovşan dəliyindən daha da dərinə gedə bilərik, çünki TCP və UDP istifadə edən hər şey əslində IP-dən də asılıdır. Əksər hallarda IP ARP ilə bağlıdır. Firewallları unutma...
Qırmızı həbi qəbul etsəniz, Möcüzələr ölkəsində qalarsınız və mən sizə dovşan dəliyinin nə qədər dərin olduğunu göstərəcəyəm”.
Daha radikal yanaşmadır söndürmək maşınları bir-bir gör və nə xarab olub... “xaos meymunu”na çevril. Əlbəttə ki, bir çox istehsal sistemləri belə bir kobud güc hücumu üçün nəzərdə tutulmayıb, lakin ən azı test mühitində sınaqdan keçirilə bilər.
Asılılıq xəritəsinin yaradılması çox vaxt çox uzun bir işdir. Bu yaxınlarda yüzlərlə mikroservis və əmrlər üçün yarı avtomatik olaraq asılılıq xəritələrini yaradan bir alət hazırlamağa təxminən 2 il sərf edən bir müştəri ilə danışdım.
Nəticə isə olduqca maraqlı və faydalıdır. Sisteminiz, onun asılılıqları və əməliyyatları haqqında çox şey öyrənəcəksiniz. Yenə də səbirli olun: ən vacib olan səyahətin özüdür.
3. Həddindən artıq özünə inamdan çəkinin
"Kim nəyi xəyal edirsə, ona inanır." - Demosfen
Heç eşitmisiniz həddindən artıq güvən təsiri?
Vikipediyaya görə, həddən artıq güvən effekti “insanın öz hərəkətlərinə və qərarlarına inamının, xüsusən də etimad səviyyəsi nisbətən yüksək olduqda, bu mühakimələrin obyektiv dəqiqliyindən əhəmiyyətli dərəcədə yüksək olduğu bilişsel qərəzdir”.
İnstinkt və təcrübə əsasında...
Təcrübəmə görə, bu təhrif xaos mühəndisliyi ilə haradan başlamaq lazım olduğuna dair əla bir işarədir.
Həddindən artıq özünə inamlı operatordan çəkinin:
Charlie: "Bu şey beş ildir düşmür, hər şey yaxşıdır!"
Qəza: "Gözləyin... Tezliklə orada olacağam!"
Həddindən artıq inamın nəticəsi olaraq qərəzlilik ona təsir edən müxtəlif amillər səbəbindən məkrli və hətta təhlükəli bir şeydir. Bu, xüsusilə komanda üzvləri bir texnologiyaya ürəklərini tökdükləri və ya onu "düzəltməyə" çox vaxt sərf etdikləri zaman doğrudur.
Xülasə
Xaos mühəndisliyi üçün başlanğıc nöqtəsi axtarışı həmişə gözləniləndən daha çox nəticə verir və hər şeyi çox tez qırmağa başlayan komandalar (xaos-)mühəndislik - yaradıcı istifadə elmi metodlar и empirik sübut (proqram təminatı) sistemlərinin dizaynı, inkişafı, istismarı, texniki xidməti və təkmilləşdirilməsi üçün.
Bununla ikinci hissə yekunlaşır. Zəhmət olmasa rəylər yazın, fikirləri paylaşın və ya sadəcə əllərinizi çırpın . Növbəti hissədə İ həqiqətən Sistemlərə nasazlıqların daxil edilməsi üçün alətlər və üsulları nəzərdən keçirəcəyəm. qədər!
Tərcüməçidən PS
Bloqumuzda da oxuyun:
- «";
- «";
- «";
- «.
Mənbə: www.habr.com