Nota. transl.: Este artigo continúa cunha gran serie de artigos do evanxelista tecnolóxico de AWS Adrian Hornsby, quen se propón explicar dun xeito sinxelo e claro a importancia da experimentación para mitigar as consecuencias dos fallos nos sistemas informáticos.
"Se non preparas un plan, entón planeas fallar". - Benjamín Franklin
В Nesta serie de artigos, presentei o concepto de enxeñaría do caos e expliquei como axuda a atopar e corrixir fallos no sistema antes de que provocasen fallos de produción. Tamén discutiu como a enxeñería do caos promove un cambio cultural positivo dentro das organizacións.
Ao final da primeira parte, prometín falar de "ferramentas e métodos para introducir fallos nos sistemas". Por desgraza, a miña cabeza tiña os seus propios plans a este respecto, e neste artigo intentarei responder á pregunta máis popular que xorde entre as persoas que queren entrar na enxeñería do caos: Que romper primeiro?
Gran pregunta! Non obstante, non parece estar especialmente molestado por este panda...
Non te metas co panda do caos!
Resposta curta: Diríxese aos servizos críticos ao longo da ruta de solicitude.
Resposta máis longa pero clara: Para entender por onde comezar a experimentar co caos, preste atención a tres áreas:
- Mirar para historial de accidentes e identificar patróns;
- Decídete dependencias críticas;
- Use o chamado efecto de exceso de confianza.
É divertido, pero esta parte podería chamarse facilmente "Unha viaxe ao autodescubrimento e á iluminación". Nela comezaremos a “tocar” cuns instrumentos chulos.
1. A resposta está no pasado
Se lembrades, na primeira parte introducín o concepto de corrección de erros (COE) - un método polo que analizamos os nosos erros - erros na tecnoloxía, proceso ou organización- para comprender a súa(s) causa(s) e previr recorrencia no futuro. En xeral, aquí é onde debes comezar.
"Para comprender o presente, cómpre coñecer o pasado". —Carl Sagan
Observa o historial de fallos, etiquétaos en COE ou en autopsias e clasifícaos. Identifica patróns comúns que adoitan levar a problemas e, para cada COE, fai a seguinte pregunta:
"¿Podería ser previsto e, polo tanto, evitado mediante a inxección de fallos?"
Recordo un fracaso ao comezo da miña carreira. Pódese evitar facilmente se levamos a cabo un par de simples experimentos de caos:
En condicións normais, as instancias de backend responden ás comprobacións de saúde de ). ELB usa estas comprobacións para redirixir as solicitudes a instancias saudables. Cando resulta que unha instancia non é "saludable", ELB deixa de enviarlle solicitudes. Un día, despois dunha exitosa campaña de marketing, o volume de tráfico aumentou e os backends comezaron a responder aos controis de saúde máis lentamente do habitual. Hai que dicir que estes controis de saúde foron , é dicir, comprobouse o estado das dependencias.
Non obstante, todo estivo ben durante un tempo.
Entón, xa en condicións bastante estresantes, unha das instancias comezou a executar unha tarefa cron ETL normal e non crítica. A combinación de alto tráfico e cronjob levou a utilización da CPU a case o 100%. A sobrecarga da CPU retardou aínda máis as respostas ás comprobacións de saúde, tanto que o ELB decidiu que a instancia estaba experimentando problemas de rendemento. Como era de esperar, o equilibrador deixou de repartirlle o tráfico, o que provocou, á súa vez, un aumento da carga no resto de instancias do grupo.
De súpeto, todos os demais casos tamén comezaron a fallar o control de saúde.
Iniciar unha nova instancia requiriu descargar e instalar paquetes e levou moito máis tempo do que levou a ELB desactivalos, un por un, no grupo de escalado automático. Está claro que pronto todo o proceso chegou a un punto crítico e a aplicación fallou.
Entón sempre entendemos os seguintes puntos:
- A instalación de software ao crear unha nova instancia leva moito tempo; é mellor dar preferencia ao enfoque inmutable e .
- En situacións complexas, as respostas aos controis de saúde e aos ELB deberían ter prioridade; o último que queres é complicar a vida para os casos restantes.
- O almacenamento en caché local das comprobacións de saúde axuda moito (aínda que sexa durante uns segundos).
- Nunha situación difícil, non executes tarefas cron e outros procesos non críticos: aforra recursos para as tarefas máis importantes.
- Ao escalar automaticamente, use instancias máis pequenas. É mellor un grupo de 10 exemplares pequenos que un grupo de 4 grandes; se falla unha instancia, no primeiro caso o 10% do tráfico distribuirase en 9 puntos, no segundo - o 25% do tráfico en tres puntos.
Así, poderíase prever isto e, polo tanto, evitarse introducindo o problema?
Si, e de varias maneiras.
En primeiro lugar, simulando un alto uso da CPU usando ferramentas como ou :
❯ stress-ng --matrix 1 -t 60s
estrés-ng
En segundo lugar, sobrecargando a instancia con e outras utilidades similares:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Os experimentos son relativamente sinxelos, pero poden proporcionar un bo alimento para pensar sen ter que pasar polo estrés dun verdadeiro fracaso.
Pero non pares aí. Tenta reproducir o fallo nun ambiente de proba e comproba a túa resposta á pregunta "Pódese previr e, polo tanto, evitarse introducindo un fallo?" Este é un mini experimento de caos dentro dun experimento de caos para probar as suposicións, pero comezando cun fracaso.
Foi un soño ou sucedeu realmente?
Así que estuda a historia dos fallos, analice EOC, etiquétaos e clasifícaos por "raio de acerto" -ou, máis exactamente, o número de clientes afectados- e despois busca patróns. Pregúntate se isto podería ser previsto e evitado introducindo o problema. Comproba a túa resposta.
A continuación, cambia aos patróns máis comúns co maior rango.
2. Construír un mapa de dependencias
Dedica un momento a pensar na túa solicitude. Existe un mapa claro das súas dependencias? Sabes que impacto terán se hai un fracaso?
Se non estás moi familiarizado co código da túa aplicación ou se fixo moi grande, pode ser difícil entender o que fai o código e cales son as súas dependencias. Comprender estas dependencias e o seu posible impacto na aplicación e nos usuarios é fundamental para saber por onde comezar coa enxeñaría do caos: o punto de partida é o compoñente con maior radio de impacto.
A identificación e documentación das dependencias chámase "construír un mapa de dependencias» (mapeo de dependencias). Normalmente, isto faise para aplicacións cunha base de código grande mediante ferramentas de creación de perfís de código. (perfil de código) e instrumentación (instrumentación). Tamén podes construír un mapa supervisando o tráfico da rede.
Non obstante, non todas as dependencias son iguais (o que complica aínda máis o proceso). Algunhas crítico, outra - secundario (polo menos en teoría, xa que os accidentes adoitan ocorrer debido a problemas con dependencias que se consideraban non críticas).
Sen dependencias críticas, o servizo non pode funcionar. Dependencias non críticas "non debería» para influír no servizo en caso de caída. Para comprender as dependencias, debes ter unha comprensión clara das API utilizadas pola túa aplicación. Isto pode ser moito máis difícil do que parece, polo menos para grandes aplicacións.
Comeza percorrendo todas as API. Destaca o máis significativo e crítico. Toma dependencias desde o repositorio de código, comprobeo rexistros de conexión, despois ver documentación (por suposto, se existe; se non, aínda tesоproblemas maiores). Use as ferramentas para perfilado e rastrexo, filtra as chamadas externas.
Podes usar programas como netstat - unha utilidade de liña de comandos que mostra unha lista de todas as conexións de rede (sockets activos) do sistema. Por exemplo, para listar todas as conexións actuais, escriba:
❯ netstat -a | more
En AWS podes usar (rexistros de fluxo) VPC é un método que che permite recompilar información sobre o tráfico IP que vai cara ou desde interfaces de rede nun VPC. Estes rexistros tamén poden axudar con outras tarefas, por exemplo, atopar unha resposta á pregunta de por que certo tráfico non chega á instancia.
Tamén podes usar . X-Ray permítelle obter información detallada e "definitiva" (de punta a punta) visión xeral das solicitudes a medida que se moven pola aplicación e tamén constrúe un mapa dos compoñentes subxacentes da aplicación. Moi cómodo se necesitas identificar dependencias.
Consola AWS X-Ray
Un mapa de dependencia de rede é só unha solución parcial. Si, mostra que aplicación se comunica con cal, pero hai outras dependencias.
Moitas aplicacións usan DNS para conectarse ás dependencias, mentres que outras poden usar o descubrimento de servizos ou mesmo enderezos IP codificados en ficheiros de configuración (p. ex. /etc/hosts).
Por exemplo, podes crear coa axuda iptables e a ver que rompe. Para facelo, introduza o seguinte comando:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
Burato negro DNS
O /etc/hosts ou outros ficheiros de configuración, atoparás enderezos IP dos que non sabes nada (si, por desgraza, isto tamén ocorre), podes vir ao rescate de novo iptables. Digamos que descubriu 8.8.8.8 e non sei que este é o enderezo do servidor DNS público de Google. Mediante o uso iptables Podes bloquear o tráfico entrante e saínte a este enderezo usando os seguintes comandos:
❯ 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"
Pechando acceso
A primeira regra elimina todos os paquetes do DNS público de Google: ping funciona, pero os paquetes non se devolven. A segunda regra elimina todos os paquetes orixinados do teu sistema cara ao DNS público de Google, en resposta a ping obtemos Operación non permitida.
Nota: neste caso particular sería mellor usar whois 8.8.8.8, pero isto é só un exemplo.
Podemos afondar aínda máis na madriguera do coello, porque todo o que usa TCP e UDP tamén depende da IP. Na maioría dos casos, a IP está ligada a ARP. Non te esquezas dos cortalumes...
Se tomas a pílula vermella, quédase no País das Marabillas e mostrarei ata que punto está a madriguera do coello".
Un enfoque máis radical é desconectar coches un por un e mira o que está roto... convértete nun "mono do caos". Por suposto, moitos sistemas de produción non están deseñados para tal ataque de forza bruta, pero polo menos pódese probar nun ambiente de proba.
Construír un mapa de dependencia adoita ser unha tarefa moi longa. Hai pouco falei cun cliente que pasou case 2 anos desenvolvendo unha ferramenta que xera mapas de dependencias de xeito semiautomático para centos de microservizos e comandos.
O resultado, con todo, é moi interesante e útil. Aprenderá moito sobre o seu sistema, as súas dependencias e operacións. De novo, teña paciencia: é a propia viaxe o que máis importa.
3. Coidado co exceso de confianza
"Quen soña con que, cre nel". - Demóstenes
Xa escoitou falar efecto de exceso de confianza?
Segundo Wikipedia, o efecto de sobreconfianza é "un sesgo cognitivo no que a confianza dunha persoa nas súas accións e decisións é significativamente maior que a precisión obxectiva deses xuízos, especialmente cando o nivel de confianza é relativamente alto".
Baseado no instinto e na experiencia...
Na miña experiencia, esta distorsión é unha boa pista de por onde comezar coa enxeñería do caos.
Coidado co operador demasiado confiado:
Charlie: "Esta cousa non caeu en cinco anos, todo está ben!"
Crash: "Espera... estarei alí pronto!"
O sesgo como consecuencia do exceso de confianza é algo insidioso e mesmo perigoso debido aos diversos factores que inflúen nel. Isto é especialmente certo cando os membros do equipo dedicaron o seu corazón a unha tecnoloxía ou pasaron moito tempo "reparando".
Resumindo
A procura dun punto de partida para a enxeñería do caos sempre trae máis resultados dos esperados, e os equipos que comezan a romper cousas demasiado rápido perden de vista a esencia máis global e interesante do (caos-)enxeñaría - uso creativo métodos científicos и evidencia empírica para o deseño, desenvolvemento, operación, mantemento e mellora de sistemas (software).
Así conclúe a segunda parte. Escribe comentarios, comparte opinións ou simplemente aplaude . Na seguinte parte I realmente Considerarei ferramentas e métodos para introducir fallos nos sistemas. Ata!
PS do tradutor
Lea tamén no noso blog:
- «»;
- «»;
- «»;
- «».
Fonte: www.habr.com