Saturs
- Gatavošanās neveiksmei
- Nākamie soļi
- Bez kļūdām, bez stresa - jūsu soli pa solim, kā izveidot programmatūru, kas maina dzīvi, neiznīcinot savu dzīvi
- Mācīšanās un uzlabošana, izmantojot treniņus
Avots: spiediensUA / iStockphoto
Izņemšana:
Mūsdienu sistēmām jāspēj rīkoties ar haosu, lai izvairītos no dīkstāves. Tāpēc ir svarīgāk nekā jebkad agrāk rūpīgi pārbaudīt sistēmas un nodrošināt to noturību.
Neskatoties uz lielākajiem centieniem no tiem izvairīties, IT incidenti ir neizbēgama darba sastāvdaļa - un mēģinājumi palikt priekšā dīkstāvi, kas ietekmē uzņēmējdarbību, kļūst tikai grūtāk. Mūsdienās sistēmas ir cieši savienotas un kļūst arvien sarežģītākas, un ar vairāk kustīgām detaļām rodas vairāk iespēju, lai viss notiktu nepareizi.
Tas ir viens no iemesliem, kāpēc arvien vairāk organizāciju vēršas pie mikropakalpojumiem, lai palielinātu pakalpojumu pieejamību un uzlabotu izturību pret kļūmēm. Bet, lai arī šīs ir lieliskas telpas monolītu lietojumu pārtraukšanai, tās arī var potenciāli sabojāt kļūmes risku - ja vien tās nav īpaši izstrādātas, ņemot vērā elastīgumu.
Gatavošanās neveiksmei
Ņemot vērā izkliedēto sistēmu raksturīgo haotisko raksturu, pakalpojumi ir jāattīsta ne tikai, lai paredzētu kļūmes, bet arī automātiski atjaunotos neveiksmes gadījumā. Tas nozīmē, ka regulāri jāuzsāk kļūmes, lai nodrošinātu, ka jūsu sistēmas var rīkoties haosā, netraucējot gala lietotājiem sniegt pakalpojumus. Un, lai to sasniegtu, jums jāprot simulēt ražošanai līdzīgu trafiku testa vidē.
Protams, ir laba ideja pārbaudīt noturību, pirms izmaiņas to ietekmē ražošanā. Ja jūs to nedarīsit, jūs nevarēsit pārliecināties, vai jūsu pakalpojumi var atbalstīt gan vidējo, gan maksimālo slodzi. Patiesībā visdrošākā likme ir nodrošināt, lai jūsu produkts spētu rīkoties līdz pat divreiz lielākam par maksimālo daudzumu, nepieprasot to palielināt.
Runājot par noturības pārbaudi, pareizajiem rīkiem nevajadzētu pārāk uztraukties par to, kā tiek apstrādāti pieprasījumi, tikai tāpēc, ka tiem visbeidzot ir pareiza ietekme. Atcerieties, ka noteiktos apstākļos ievades pakalpojums var neizdot pieprasījumu citai sistēmai, bet neziņot par kļūmi. Neuzņemieties risku, lidojot zem uzraudzības radara, pārliecinoties, ka patiesībā notiek pilnīga validācija. (Plašāku informāciju skatiet Tehniskās kļūmes: vai mēs varam dzīvot ar viņiem?)
Nākamie soļi
Pēc izpratnes par to, kā dienesti rīkojas bez slodzes, ir pienācis laiks sākt iepazīstināt ar kļūmes gadījumiem. Tāpat kā visās programmatūras testēšanas reizēs, vislabāk ir automatizēti rīki, kas ļauj viegli un ātri reproducēt scenārijus, lai jūs varētu koordinēt sarežģītus notikumus, kas ietekmē dažādas infrastruktūras tehnoloģijas. Papildus spējai pārbaudīt pakalpojumu labojumus un izmaiņas, tas ļauj palaist nejaušu kļūmju scenārijus jebkurā vidē un pēc grafika.
Nozīmīgi neveiksmes notikumi lielā mērā ir atkarīgi no jūsu pakalpojumu izkārtojuma, un jūs varat tos formulēt, uzdodot konkrētus jums svarīgus jautājumus. Piemēram, kāda ir ietekme uz cilvēkiem, kas izmanto front-end, kad datu bāze noteiktā laika posmā kļūst nepieejama? Vai šie lietotāji joprojām var pārvietoties tīmekļa lietotāja saskarnē? Vai viņi joprojām var izdot atjauninājumus savai informācijai, un vai šie atjauninājumi tiks apstrādāti pareizi, kad datu bāze atkal būs pieejama?
Ja palaižat vairākus mikropakalpojumus, varat jautāt, vai notiks globāls pārtraukums, ja kāds atsevišķs pakalpojums avarēs. Vai arī, ja jums ir rindas veidošanas mehānisms, lai buferizētu saziņu starp pakalpojumiem, kas notiek, kad patērētāju pakalpojums (vai pakalpojumi) pārstāj darboties? Vai lietotāji joprojām varēs strādāt ar jūsu lietojumprogrammu? Un, ņemot vērā vidējo slodzi, cik ilgs laiks jums ir, pirms rindas tiek pārpildītas, un jūs sākat zaudēt s?
Bez kļūdām, bez stresa - jūsu soli pa solim, kā izveidot programmatūru, kas maina dzīvi, neiznīcinot savu dzīvi
Jūs nevarat uzlabot savas programmēšanas prasmes, kad nevienam nerūp programmatūras kvalitāte.
Kad esat definējis dažus galvenos jautājumus par savu infrastruktūru, varat sākt uzskaitīt dažādus veidus, kā simulēt šīs kļūmes. Varētu būt pietiekami, lai apturētu noteiktu pakalpojumu vai datu bāzes serveri. Jūs varētu bloķēt pakalpojuma galveno pavedienu, lai simulētu strupceļu, kamēr tā konteiners joprojām reaģē un darbojas. Jūs varētu nolemt ieviest noteikumus tīklā, lai bloķētu satiksmi starp noteiktiem pakalpojumiem. Linux vidē varat izmantot tādus rīkus kā “tc”, lai atdarinātu tīkla situācijas, piemēram, ar lielu latentumu, pazaudētām, bojātām vai dublētām paketēm. (Var būt svarīgi iesaistīt testēšanā lietotājus. Lasiet vairāk par 4 iemesliem, kāpēc galalietotājiem jāpiedalās testēšanā pirms UAT.)
Mācīšanās un uzlabošana, izmantojot treniņus
Viens no vērtīgākajiem neveiksmes scenāriju veidošanas aspektiem ir tas, ka tie var atklāt visus iespējamos veidus, kā sistēma var izgāzties, tādējādi paverot ceļu uz pašdziedināšanās loģiku. Jūsu komanda veiks visas darbības pakalpojumu manuālai atkopšanai - starp citu, lielisks treniņš, lai apstiprinātu, ka viņš to spēj SLA ietvaros. Var tikt strādāta pie šī atkopšanas procesa automatizācijas, taču pa to laiku jūs varat ērti atpūsties, zinot, ka jūsu komanda ir izgājusi cauri pakalpojumu atjaunošanas procesam. Padarot kļūmes scenārijus pēc nejaušības principa un regulāri un neatklājot pilnīgu informāciju par darbību, urbumam varat iekļaut arī atklājumus un diagnozes - kas galu galā ir kritiska SLA daļa.
Haosa inženierijas pamatā ir sistēmas sarežģītība kā noteikta, to testē, imitējot jaunus un prātā jušamus apstākļus, un novēro, kā sistēma reaģē. Datu inženieru komandām ir jāpārveido un jāpārkonfigurē sistēma, lai panāktu lielāku elastīgumu. Ir tik daudz iespēju apgūt jaunas un noderīgas lietas. Piemēram, jūs varat atrast gadījumus, kad pakalpojumi nesaņem atjauninājumus, kad ir mainījušies pakārtotie pakalpojumi, vai arī apgabali, kur pilnībā trūkst uzraudzības. Netrūkst aizraujošu veidu, kā padarīt jūsu produktu elastīgāku un izturīgāku!