Nota. transl.: Aquest article continua una gran sèrie d'articles de l'evangelista de tecnologia d'AWS Adrian Hornsby, que es proposa explicar d'una manera senzilla i clara la importància de l'experimentació per mitigar les conseqüències dels errors en els sistemes informàtics.
"Si no prepares un pla, llavors penses fallar". - Benjamin Franklin
В En aquesta sèrie d'articles, vaig introduir el concepte d'enginyeria del caos i vaig explicar com ajuda a trobar i corregir defectes del sistema abans que provoquin errors de producció. També va parlar de com l'enginyeria del caos promou un canvi cultural positiu dins de les organitzacions.
Al final de la primera part, em vaig comprometre a parlar de "eines i mètodes per introduir errors als sistemes". Per desgràcia, el meu cap tenia els seus propis plans en aquest sentit, i en aquest article intentaré respondre la pregunta més popular que sorgeix entre les persones que volen entrar en l'enginyeria del caos: Què trencar primer?
Gran pregunta! No obstant això, no sembla que li molesti especialment aquest panda...
No et fiquis amb el panda del caos!
Resposta curta: Orienta els serveis crítics al llarg del camí de sol·licitud.
Resposta més llarga però clara: Per entendre per on començar a experimentar amb el caos, presteu atenció a tres àrees:
- Mirar historial d'accidents i identificar patrons;
- Decideix-te dependències crítiques;
- Utilitzeu l'anomenat efecte d'excés de confiança.
És divertit, però aquesta part es podria anomenar amb la mateixa facilitat "Un viatge cap a l'autodescobriment i la il·luminació". En ell començarem a “tocar” amb uns instruments genials.
1. La resposta es troba en el passat
Si recordeu, a la primera part vaig introduir el concepte de correcció d'errors (COE) - un mètode pel qual analitzem els nostres errors - errors en tecnologia, procés o organització - per tal d'entendre la seva(s) causa(s) i prevenir-ne. recurrència en el futur. En general, aquí és on hauríeu de començar.
"Per entendre el present, cal conèixer el passat". —Carl Sagan
Mireu l'historial de fallades, etiqueteu-los en COE o autopsia i classifica-los. Identifiqueu patrons comuns que sovint condueixen a problemes i, per a cada COE, feu-vos la pregunta següent:
"Això es podria haver predit i, per tant, prevenit per injecció d'errors?"
Recordo un fracàs al començament de la meva carrera. S'hauria pogut evitar fàcilment si haguéssim dut a terme un parell d'experiments de caos senzills:
En condicions normals, les instàncies de backend responen a les comprovacions de salut de ). ELB utilitza aquestes comprovacions per redirigir les sol·licituds a instàncies saludables. Quan resulta que una instància no és saludable, ELB deixa d'enviar-li sol·licituds. Un dia, després d'una campanya de màrqueting exitosa, el volum de trànsit va augmentar i els backends van començar a respondre als controls de salut més lentament de l'habitual. Cal dir que aquests controls de salut ho van ser , és a dir, es va comprovar l'estat de les dependències.
Tanmateix, tot va anar bé durant un temps.
Aleshores, ja en condicions força estressants, una de les instàncies va començar a executar una tasca cron ETL no crítica i regular. La combinació d'alt trànsit i cronjob va empènyer la utilització de la CPU a gairebé el 100%. La sobrecàrrega de la CPU va alentir encara més les respostes a les comprovacions de salut, tant que l'ELB va decidir que la instància estava experimentant problemes de rendiment. Com era d'esperar, l'equilibrador va deixar de distribuir-hi trànsit, cosa que, al seu torn, va provocar un augment de la càrrega de les instàncies restants del grup.
De sobte, totes les altres instàncies també van començar a fallar el control de salut.
L'inici d'una nova instància va requerir la descàrrega i la instal·lació de paquets i va trigar molt més del que va trigar l'ELB a desactivar-los, un per un, al grup d'escala automàtica. És evident que aviat tot el procés va arribar a un punt crític i l'aplicació es va estavellar.
Aleshores vam entendre per sempre els punts següents:
- La instal·lació de programari quan es crea una nova instància requereix molt de temps, és millor donar preferència a l'enfocament immutable .
- En situacions complexes, les respostes als controls de salut i ELB haurien de tenir prioritat; l'últim que voleu és complicar la vida per a les instàncies restants.
- L'emmagatzematge local a la memòria cau de les comprovacions de salut ajuda molt (fins i tot durant uns segons).
- En una situació difícil, no executeu tasques cron i altres processos no crítics; estalvieu recursos per a les tasques més importants.
- Quan feu l'escala automàtica, utilitzeu instàncies més petites. Un grup de 10 exemplars petits és millor que un grup de 4 grans; si una instància falla, en el primer cas el 10% del trànsit es distribuirà en 9 punts, en el segon - el 25% del trànsit en tres punts.
Per tant, això es podria haver previst i, per tant, prevenit introduint el problema?
Sí, i de diverses maneres.
En primer lloc, simulant un ús elevat de CPU mitjançant eines com ara o :
❯ stress-ng --matrix 1 -t 60s
estrès-ng
En segon lloc, sobrecarregant la instància amb i altres utilitats similars:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Els experiments són relativament senzills, però poden proporcionar una bona font de reflexió sense haver de passar per l'estrès d'un fracàs real.
Sinó no us atureu aquí. Intenteu reproduir l'error en un entorn de prova i comproveu la vostra resposta a la pregunta "Això s'hauria pogut preveure i, per tant, evitar-ho introduint una avaria?" Aquest és un mini experiment de caos dins d'un experiment de caos per provar hipòtesis, però començant amb un fracàs.
Va ser un somni o va passar realment?
Així que estudia la història dels fracassos, analitza COE, etiqueteu-los i classifiqueu-los segons el "radi d'accés" (o, més exactament, el nombre de clients afectats) i, a continuació, busqueu patrons. Pregunteu-vos si això s'hauria pogut predir i prevenir introduint el problema. Comprova la teva resposta.
A continuació, canvieu als patrons més comuns amb el rang més gran.
2. Construeix un mapa de dependències
Preneu-vos un moment per pensar en la vostra aplicació. Hi ha un mapa clar de les seves dependències? Saps quin impacte tindran si hi ha un fracàs?
Si no esteu molt familiaritzat amb el codi de la vostra aplicació o s'ha fet molt gran, pot ser difícil entendre què fa el codi i quines són les seves dependències. Entendre aquestes dependències i el seu possible impacte en l'aplicació i els usuaris és fonamental per saber per on començar amb l'enginyeria del caos: el punt de partida és el component amb el radi d'impacte més gran.
La identificació i documentació de dependències s'anomena "construir un mapa de dependències» (mapa de dependències). Això es fa normalment per a aplicacions amb una base de codi gran que utilitzen eines de perfil de codi. (perfilatge de codi) i instrumentació (instrumentació). També podeu crear un mapa supervisant el trànsit de la xarxa.
Tanmateix, no totes les dependències són iguals (la qual cosa complica encara més el procés). Alguns crític, altres - secundària (almenys en teoria, ja que els bloquejos sovint es produeixen a causa de problemes amb dependències que es consideraven no crítiques).
Sense dependències crítiques, el servei no pot funcionar. Dependències no crítiques"no hauria» per influir en el servei en cas de caiguda. Per entendre les dependències, cal tenir una comprensió clara de les API que utilitza la vostra aplicació. Això pot ser molt més difícil del que sembla, almenys per a aplicacions grans.
Comenceu passant per totes les API. Ressaltar el més important i crític. Pren dependències des del dipòsit de codi, comproveu-ho registres de connexió, després veure documentació (per descomptat, si existeix, en cas contrari encara ho tensоproblemes més grans). Utilitzeu les eines per perfilació i traçat, filtra les trucades externes.
Podeu utilitzar programes com netstat - una utilitat de línia d'ordres que mostra una llista de totes les connexions de xarxa (sockets actius) del sistema. Per exemple, per llistar totes les connexions actuals, escriviu:
❯ netstat -a | more
A AWS podeu utilitzar (Registres de flux) VPC és un mètode que us permet recopilar informació sobre el trànsit IP que va cap a o des de les interfícies de xarxa en un VPC. Aquests registres també poden ajudar amb altres tasques, per exemple, trobar una resposta a la pregunta de per què determinat trànsit no arriba a la instància.
També pots utilitzar . X-Ray us permet obtenir informació detallada i "última" (d'extrem a extrem) visió general de les sol·licituds a mesura que es mouen per l'aplicació i també crea un mapa dels components subjacents de l'aplicació. Molt convenient si necessiteu identificar dependències.
Consola AWS X-Ray
Un mapa de dependència de xarxa només és una solució parcial. Sí, mostra quina aplicació es comunica amb quina, però hi ha altres dependències.
Moltes aplicacions utilitzen DNS per connectar-se a dependències, mentre que altres poden utilitzar el descobriment de serveis o fins i tot adreces IP codificades en fitxers de configuració (p. /etc/hosts).
Per exemple, podeu crear via iptables i a veure què es trenca. Per fer-ho, introduïu l'ordre següent:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
Forat negre DNS
Si hi és /etc/hosts o altres fitxers de configuració, trobareu adreces IP de les quals no sabeu res (sí, per desgràcia, això també passa), podeu tornar al rescat iptables. Diguem que ho has descobert 8.8.8.8 i no sé que aquesta és l'adreça pública del servidor DNS de Google. Mitjançant l'ús de iptables Podeu bloquejar el trànsit entrant i sortint a aquesta adreça mitjançant les ordres següents:
❯ 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"
Tancament d'accés
La primera regla elimina tots els paquets del DNS públic de Google: ping funciona, però els paquets no es retornen. La segona regla deixa caure tots els paquets originats del vostre sistema cap al DNS públic de Google, com a resposta a ping obtenim Operació no permesa.
Nota: en aquest cas particular seria millor utilitzar-lo whois 8.8.8.8, però això és només un exemple.
Podem aprofundir encara més en el forat del conill, perquè tot el que utilitza TCP i UDP també depèn de la IP. En la majoria dels casos, la IP està vinculada a ARP. No us oblideu dels tallafocs...
Si prens la píndola vermella, et quedes al País de les Meravelles i et mostraré fins a quin punt és el forat del conill".
Un enfocament més radical és desconnectar cotxes un per un i veure què està trencat... convertiu-vos en un "mono del caos". Per descomptat, molts sistemes de producció no estan dissenyats per a un atac de força bruta, però almenys es pot provar en un entorn de prova.
Construir un mapa de dependències sovint és una tasca molt llarga. Recentment vaig parlar amb un client que va passar gairebé 2 anys desenvolupant una eina que genera de manera semiautomàtica mapes de dependència per a centenars de microserveis i ordres.
El resultat, però, és extremadament interessant i útil. Aprendràs molt sobre el teu sistema, les seves dependències i operacions. Un cop més, tingueu paciència: és el viatge en si el que més importa.
3. Compte amb l'excés de confiança
"Qui somia amb què, hi creu". —Demòstenes
N'heu sentit a parlar mai efecte d'excés de confiança?
Segons la Viquipèdia, l'efecte d'excés de confiança és "un biaix cognitiu en què la confiança d'una persona en les seves accions i decisions és significativament més gran que la precisió objectiva d'aquests judicis, especialment quan el nivell de confiança és relativament alt".
Basat en l'instint i l'experiència...
Des de la meva experiència, puc dir que aquesta distorsió és una bona pista d'on començar amb l'enginyeria del caos.
Compte amb l'operador excessivament confiat:
Charlie: "Això no ha caigut en cinc anys, tot està bé!"
Crash: "Espera... hi seré aviat!"
El biaix com a conseqüència de l'excés de confiança és una cosa insidiosa i fins i tot perillosa a causa dels diferents factors que hi influeixen. Això és especialment cert quan els membres de l'equip han posat el cor en una tecnologia o han passat molt de temps "arreglant-la".
Resumint
La recerca d'un punt de partida per a l'enginyeria del caos sempre aporta més resultats dels esperats, i els equips que comencen a trencar coses massa ràpidament perden de vista l'essència més global i interessant del (caos-)enginyeria - ús creatiu mètodes científics и evidència empírica per al disseny, desenvolupament, operació, manteniment i millora de sistemes (programari).
Així conclou la segona part. Si us plau, escriviu ressenyes, compartiu opinions o simplement aplaudiu . A la següent part I de veritat Consideraré eines i mètodes per introduir errors als sistemes. Fins a!
PS del traductor
Llegeix també al nostre blog:
- «»;
- «»;
- «»;
- «».
Font: www.habr.com