Catetan. narjamahkeun.: Artikel ieu nuluykeun runtuyan hébat artikel ti AWS téhnologi evangelist Adrian Hornsby, anu susunan kaluar pikeun ngajelaskeun dina cara basajan tur jelas pentingna experimentation mun mitigate konsékuansi tina gagal dina sistem IT.
"Upami anjeun gagal nyiapkeun rencana, maka anjeun ngarencanakeun gagal." - Benjamin Franklin
В Dina séri tulisan ieu, kuring ngenalkeun konsép rékayasa huru-hara sareng ngajelaskeun kumaha éta ngabantosan mendakan sareng ngabenerkeun cacad dina sistem sateuacan aranjeunna nuju gagal produksi. Éta ogé ngabahas kumaha rékayasa huru-hara ngamajukeun parobahan budaya anu positif dina organisasi.
Dina ahir bagian kahiji, kuring jangji bakal ngobrol ngeunaan "parabot sareng metode pikeun ngenalkeun gagal kana sistem." Aduh, sirah kuring ngagaduhan rencana sorangan dina hal ieu, sareng dina tulisan ieu kuring bakal nyobian ngajawab patarosan anu paling populer anu timbul diantara jalma anu hoyong asup kana rékayasa huru-hara: Pegat heula naon?
Patarosan hébat! Nanging, anjeunna sigana henteu kaganggu ku panda ieu ...
Tong kacau jeung panda rusuh!
Jawab pondok: Target jasa kritis sapanjang jalur pamundut.
Jawaban anu langkung panjang tapi langkung jelas: Pikeun ngartos dimana ngamimitian ékspérimén sareng huru-hara, perhatikeun tilu daérah:
- kasampak di sajarah kacilakaan jeung ngaidentipikasi pola;
- mutuskeun dina kagumantungan kritis;
- Paké disebut pangaruh overconfidence.
Ieu lucu, tapi bagian ieu bisa sagampang disebut "Perjalanan pikeun Penemuan Diri sareng Pencerahan". Di dinya urang bakal ngamimitian "maén" sareng sababaraha alat anu saé.
1. jawaban perenahna di kaliwat
Upami anjeun émut, dina bagian kahiji kuring ngenalkeun konsép Correction-of-Errors (COE) - metode anu urang nganalisa kasalahan urang - kasalahan dina téknologi, prosés atanapi organisasi - pikeun ngartos panyababna sareng nyegah. kambuh deui dina mangsa nu bakal datang. Sacara umum, ieu dimana anjeun kedah ngamimitian.
"Pikeun ngartos jaman ayeuna, anjeun kedah terang jaman baheula." - Carl Sagan
Tingali kana sajarah gagalna, tag aranjeunna dina COE atanapi postmortems sareng klasifikasikeunana. Identipikasi pola umum anu sering nyababkeun masalah, sareng pikeun unggal COE, naroskeun ka diri anjeun patarosan ieu:
"Naha ieu tiasa diprediksi sareng ku kituna dicegah ku suntikan lepat?"
Abdi émut hiji kagagalan dina awal karir abdi. Éta tiasa gampang dicegah upami urang ngalaksanakeun sababaraha percobaan huru-hara sederhana:
Dina kaayaan normal, instansi backend ngabales cék kaséhatan ti ). ELB ngagunakeun cék ieu pikeun alihan pamundut ka instansi séhat. Nalika tétéla yén hiji conto "teu damang", ELB ngeureunkeun ngirim pamundut ka éta. Hiji poé, sanggeus kampanye pamasaran suksés, volume lalulintas ngaronjat sarta backends mimiti ngabales cék kaséhatan leuwih laun ti biasa. Ieu kudu ngomong yén ieu cék kaséhatan éta , nyaeta, kaayaan dependensi dipariksa.
Sanajan kitu, sagalana éta rupa pikeun sawatara waktu.
Lajeng, geus dina kaayaan rada stres, salah sahiji instansi mimiti executing non-kritis, tugas cron ETL biasa. Kombinasi lalulintas tinggi na cronjob kadorong utilization CPU ampir 100%. Overload CPU salajengna ngalambatkeun réspon kana pamariksaan kaséhatan, ku kituna ELB mutuskeun yén conto éta ngalaman masalah kinerja. Saperti nu diharapkeun, balancer nu dieureunkeun ngadistribusikaeun lalulintas ka dinya, anu, kahareupna ngabalukarkeun kanaékan beban dina instansi sésana dina grup.
Ujug-ujug, sadaya instansi sanésna ogé gagal dina pamariksaan kaséhatan.
Ngamimitian conto anyar peryogi ngaunduh sareng masang bungkusan sareng nyandak langkung lami tibatan éta nyandak ELB pikeun nganonaktipkeun aranjeunna - hiji-hiji - dina grup autoscaling. Éta écés yén pas sadayana prosés ngahontal titik kritis sareng aplikasi nabrak.
Teras urang salamina ngartos poin-poin ieu:
- Masang parangkat lunak nalika nyiptakeun conto énggal butuh waktos anu lami; éta langkung saé pikeun masihan pilihan kana pendekatan anu teu tiasa dirobih sareng .
- Dina kaayaan anu sesah, réspon kana pamariksaan kaséhatan sareng ELB kedah janten prioritas - hal anu terakhir anu anjeun pikahoyong nyaéta ngahesekeun kahirupan pikeun instansi anu sésana.
- Caching lokal tina cék kaséhatan mantuan pisan (sanajan pikeun sababaraha detik).
- Dina kaayaan anu sesah, ulah ngajalankeun tugas cron sareng prosés non-kritis sanés - simpen sumber daya pikeun tugas anu paling penting.
- Nalika autoscaling, make instansi leutik. Hiji grup 10 spésimén leutik leuwih hade tinimbang grup 4 leuwih badag; lamun hiji conto gagal, dina kasus nu pertama 10% tina lalulintas bakal disebarkeun leuwih 9 titik, dina kadua - 25% tina lalulintas leuwih tilu titik.
Ku kituna, bisa ieu geus foreseen, sarta ku kituna dicegah ku ngawanohkeun masalah?
yen, sareng ku sababaraha cara.
Kahiji, ku simulating pamakéan CPU tinggi ngagunakeun parabot kayaning atawa :
❯ stress-ng --matrix 1 -t 60s
setrés-ng
Bréh, ku overloading conto jeung sareng utilitas anu sami:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Percobaan anu kawilang basajan, tapi bisa nyadiakeun sabagian kadaharan alus pikeun pamikiran tanpa kudu ngaliwatan stress a gagal nyata.
kumaha oge ulah eureun didinya. Coba baranahan kacilakaan dina lingkungan tés sareng pariksa jawaban anjeun kana patarosan "Bisa ieu geus foreseen sahingga dicegah ku ngawanohkeun kasalahan?" Ieu percobaan rusuh mini dina percobaan rusuh pikeun nguji asumsi, tapi dimimitian ku gagal.
Naha éta impian, atanapi éta leres-leres kajantenan?
Jadi diajar sajarah gagal, analisa EOC, tag sarta mengklasifikasikan aranjeunna ku "radius pencét" -atawa leuwih akurat, jumlah konsumén kapangaruhan-lajeng néangan pola. Nanya ka diri lamun ieu bisa geus diprediksi jeung dicegah ku ngawanohkeun masalah. Pariksa jawaban anjeun.
Teras gentos kana pola anu paling umum kalayan rentang anu paling ageung.
2. Ngawangun peta kagumantungan
Sakedap kanggo mikir ngeunaan aplikasi anjeun. Naha aya peta anu jelas ngeunaan kagumantunganana? Naha anjeun terang naon dampak anu bakal aya upami aya kagagalan?
Upami anjeun teu wawuh pisan sareng kode aplikasi anjeun atanapi janten ageung pisan, tiasa sesah ngartos naon kodeu sareng naon tanggungan na. Ngartos katergantungan ieu sareng kamungkinan dampakna dina aplikasi sareng pangguna penting pisan pikeun terang dimana ngamimitian rékayasa huru-hara: titik awal nyaéta komponén anu gaduh radius dampak panggedéna.
Ngidentipikasi sareng ngadokumentasikeun katergantungan disebut "ngawangun peta kagumantungan» (pemetaan gumantungna). Ieu biasana dilakukeun pikeun aplikasi anu nganggo kode dasar anu ageung nganggo alat profiling kode. (kode profiling) jeung instrumentasi (instrumén). Anjeun ogé tiasa ngawangun peta ku ngawaskeun lalu lintas jaringan.
Nanging, henteu sadayana katergantungan sami (anu langkung rumit prosésna). Sababaraha kritis, lain- sekundér (sahenteuna dina téori, sabab kacilakaan sering kajantenan kusabab masalah sareng katergantungan anu dianggap non-kritis).
Tanpa kagumantungan kritis, jasa éta moal tiasa jalan. Ketergantungan non-kritis "kuduna henteu»pikeun pangaruh jasa dina acara ragrag. Pikeun ngartos dependensi, anjeun kedah gaduh pamahaman anu jelas ngeunaan API anu dianggo ku aplikasi anjeun. Ieu tiasa langkung hese tibatan sigana - sahenteuna pikeun aplikasi anu ageung.
Mimitian ku ngaliwat sadaya API. Nyorot paling signifikan jeung kritis. Nyandak gumantung ti gudang kode, pariksa kaluar log sambungan, teras tingali dokuméntasi (tangtosna, upami aya - upami henteu anjeun masih gaduhоmasalah anu langkung ageung). Paké parabot pikeun profiling jeung tracing, nyaring kaluar telepon éksternal.
Anjeun tiasa nganggo program sapertos netstat - utilitas garis paréntah anu nampilkeun daptar sadaya sambungan jaringan (sockets aktip) dina sistem. Contona, pikeun daptar sadaya sambungan ayeuna, ketik:
❯ netstat -a | more
Dina AWS anjeun tiasa nganggo (log aliran) VPC mangrupakeun metoda nu ngidinan Anjeun pikeun ngumpulkeun informasi ngeunaan lalulintas IP bade atanapi ti interfaces jaringan dina VPC a. Log sapertos kitu ogé tiasa ngabantosan tugas-tugas sanés - contona, milarian jawaban kana patarosan naha lalulintas tangtu henteu ngahontal conto.
Anjeun oge bisa make . X-Ray ngamungkinkeun anjeun pikeun detil, "pamungkas" (tungtung-tungtung) Tinjauan pamundut nalika aranjeunna ngaliwat aplikasi, sareng ogé ngawangun peta komponén dasar aplikasi. Kacida merenah upami anjeun kedah ngaidentipikasi katergantungan.
Konsol X-Ray AWS
Peta kagumantungan jaringan ngan ukur solusi parsial. Leres, éta nunjukkeun aplikasi mana anu komunikasi, tapi aya katergantungan anu sanés.
Seueur aplikasi nganggo DNS pikeun nyambungkeun ka dependensi, sedengkeun anu sanésna tiasa nganggo penemuan jasa atanapi bahkan alamat IP anu disandi keras dina file konfigurasi (misalna. /etc/hosts).
Contona, Anjeun bisa nyieun kalayan bantuan iptables tur tingal naon ngarecah. Jang ngalampahkeun ieu, lebetkeun paréntah di handap ieu:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS liang hideung
Upami di /etc/hosts atanapi file konfigurasi anu sanés, anjeun bakal mendakan alamat IP anu anjeun teu terang nanaon (enya, hanjakalna, ieu ogé kajantenan), anjeun tiasa nyalametkeun deui iptables. Hayu urang nyebutkeun kapanggih 8.8.8.8 sareng henteu terang yén ieu mangrupikeun alamat server DNS umum Google. Ku ngagunakeun iptables Anjeun tiasa meungpeuk lalu lintas asup sareng kaluar ka alamat ieu nganggo paréntah di handap ieu:
❯ 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"
Nutup aksés
Aturan kahiji ngahapus sadaya pakét tina DNS publik Google: ping jalan, tapi pakét teu balik. Aturan kadua ngagentos sadaya pakét anu asalna tina sistem anjeun ka DNS publik Google - pikeun ngaréspon ping urang meunang Operasi teu diwenangkeun.
Catetan: dina hal husus ieu bakal leuwih hadé ngagunakeun whois 8.8.8.8, tapi ieu sakadar conto.
Urang tiasa langkung jero kana liang kelenci, sabab sadayana anu nganggo TCP sareng UDP saleresna gumantung kana IP ogé. Dina kalolobaan kasus, IP dihijikeun ka ARP. Ulah poho ngeunaan firewalls ...
Upami anjeun nyandak pil beureum, anjeun cicing di Wonderland, sareng kuring bakal nunjukkeun anjeun sabaraha jero liang kelenci."
Pendekatan anu langkung radikal nyaéta megatkeun sambungan mobil hiji-hiji jeung ningali naon nu pegat ... jadi "monyét rusuh." Tangtosna, seueur sistem produksi henteu dirancang pikeun serangan gaya kasar sapertos kitu, tapi sahenteuna tiasa dicoba dina lingkungan uji.
Ngawangun peta kagumantungan sering mangrupikeun padamelan anu panjang pisan. Kuring nembe nyarios sareng klien anu nyéépkeun ampir 2 taun ngembangkeun alat anu semi-otomatis ngahasilkeun peta kagumantungan pikeun ratusan microservices sareng paréntah.
Hasilna, kumaha oge, pisan metot jeung mangpaat. Anjeun bakal diajar seueur ngeunaan sistem anjeun, katergantungan sareng operasina. Sakali deui, sabar: éta perjalanan sorangan anu paling penting.
3. Waspada tina overconfidence
"Saha waé anu ngimpi naon, percaya kana éta." - Demosthenes
Dupi anjeun kantos ngadéngé pangaruh overconfidence?
Numutkeun Wikipedia, pangaruh overconfidence nyaeta "bias kognitif dimana kapercayaan hiji jalma dina lampah jeung kaputusan maranéhanana sacara signifikan leuwih gede dibandingkeun akurasi obyektif tina judgments maranéhanana, utamana lamun tingkat kapercayaan relatif luhur".
Dumasar kana naluri sareng pangalaman ...
Dina pangalaman kuring, distorsi ieu mangrupikeun petunjuk anu hadé pikeun ngamimitian sareng rékayasa huru-hara.
Waspada operator overconfident:
Charlie: "Hal ieu henteu murag dina lima taun, sadayana henteu kunanaon!"
Kacilakaan: “Tungguan... geura ka ditu!”
Bias salaku konsekuensi overconfidence mangrupakeun hal insidious malah bahaya alatan rupa-rupa faktor anu mangaruhan eta. Ieu hususna leres lamun anggota tim geus dituang haté maranéhna kana téhnologi atawa spent loba waktu "ngalereskeun" eta.
Nyimpulkeun
Milarian titik awal pikeun rékayasa huru-hara salawasna ngahasilkeun hasil anu langkung ageung tibatan anu disangka, sareng tim anu ngamimitian ngarecah hal-hal gancang teuing leungiteun hakekat anu langkung global sareng pikaresepeun (kaos-)rékayasa - pamakéan kreatif métode ilmiah и bukti empiris pikeun rarancang, pamekaran, operasi, pangropéa sareng perbaikan sistem (software).
Ieu menyimpulkan bagian kadua. Punten nyerat ulasan, bagikeun pendapat atanapi ngan ukur keprok . Dina bagian salajengna I bener Kuring bakal mertimbangkeun alat sareng metode pikeun ngenalkeun kagagalan kana sistem. Dugi ka!
PS ti penerjemah
Baca ogé dina blog urang:
- «";
- «";
- «";
- «".
sumber: www.habr.com