{"id":2572,"date":"2021-07-04T18:48:27","date_gmt":"2021-07-04T21:48:27","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=2572"},"modified":"2024-01-11T18:02:05","modified_gmt":"2024-01-11T21:02:05","slug":"fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/","title":{"rendered":"Fundamentos para arquiteturas de sistemas resilientes \/ Cap\u00edtulo 13 v 1.0"},"content":{"rendered":"

Com a transforma\u00e7\u00e3o digital, sistemas est\u00e3o cada vez mais conectados. Clientes, parceiros e fornecedores t\u00eam cada vez mais acesso a sistemas que at\u00e9 bem pouco tempo eram acessados apenas “dentro de casa”. As “janelas para\u00a0downtime<\/em>” est\u00e3o ficando cada vez menores. Nunca disponibilidade e confiabilidade foram t\u00e3o importantes.<\/strong><\/p>\nSob o ponto de arquitetura de software, \u00e9 cada vez mais relevante identificar que funcionalidades dos sistemas “n\u00e3o devem parar”, assim como quais podem ficar eventualmente indispon\u00edveis e em que “janelas”. A partir dessas informa\u00e7\u00f5es, \u00e9 poss\u00edvel criar de propostas de design<\/em> de componentes que colaborem com a solu\u00e7\u00e3o, sem custos desnecess\u00e1rios.\n

\nH\u00e1 tempos, a ind\u00fastria de software tem mantido sistemas dispon\u00edveis adotando estrat\u00e9gias como replica\u00e7\u00f5es e clusters<\/em>. A ideia \u00e9 que a escala horizontal previne a satura\u00e7\u00e3o de recursos e cria um “backup” operante se algo vai mal. Entretanto, em sistemas cada vez mais distribu\u00eddos, com componentes cada vez menores, esta estrat\u00e9gia parece n\u00e3o ter mais efetividade. Parece fazer mais sentido implementar t\u00e1ticas para resili\u00eancia do que replica\u00e7\u00e3o.\n
\r\n

Resili\u00eancia<\/p>\r\n<\/p>\n

Resili\u00eancia, como propriedade da f\u00edsica, implica \u00e9 a propriedade que alguns corpos apresentam de retornar \u00e0 forma original ap\u00f3s terem sido submetidos a uma deforma\u00e7\u00e3o el\u00e1stica. Informalmente, \u00e9 a\u00a0capacidade de se recobrar facilmente ou se adaptar \u00e0 m\u00e1 sorte ou \u00e0s mudan\u00e7as<\/strong>.<\/p>\n

<\/div>\n

Defini\u00e7\u00f5es para disponibilidade e confiabilidade<\/h2>\n

Disponibilidade<\/strong> \u00e9 um atributo de qualidade, mensur\u00e1vel, que indica a rela\u00e7\u00e3o entre o tempo em que um sistema ou componente est\u00e1 dispon\u00edvel e o tempo em que ele “poderia” (ou “deveria”) estar. Entendendo-se, nesse contexto, que um sistema est\u00e1 dispon\u00edvel quando funciona com a performance projetada.<\/p>\n

Confiabilidade<\/strong>, tamb\u00e9m um atributo de qualidade mensur\u00e1vel, implica que, al\u00e9m de dispon\u00edvel, um sistema ou componente opere sem erros nem defeitos.<\/p>\n

Para ser confi\u00e1vel, um sistema ou componente precisa se manter dispon\u00edvel. Entretanto, nem todo sistema dispon\u00edvel \u00e9 confi\u00e1vel.<\/strong><\/p>\n

Estrat\u00e9gia para disponibilidade<\/h4>\n

Historicamente, disponibilidade \u00e9 obtida atrav\u00e9s de clusteriza\u00e7\u00e3o e replica\u00e7\u00e3o. A ideia \u00e9 tentar reduzir o impacto de satura\u00e7\u00e3o de alguma inst\u00e2ncia de componente, distribuindo cargas.<\/p>\n

Estrat\u00e9gia para confiabilidade<\/h4>\n

Devido aos custos de escala e a fragmenta\u00e7\u00e3o crescente de componentes (como em arquiteturas baseadas em microsservi\u00e7os), ultimamente tem-se adotado, outra estrat\u00e9gia: a resili\u00eancia<\/strong>.<\/p>\n

Para ser resiliente, um componente precisa adaptar seu comportamento, reconhecendo eventuais erros ou defeitos nos demais, tolerando problemas com lat\u00eancia, eventualmente implantando mecanismos de retentativas, circuit-breaking<\/em>, reinicializa\u00e7\u00e3o autom\u00e1tica, etc. Sistemas resilientes n\u00e3o s\u00e3o, necessariamente, mais dispon\u00edveis, mas, sem d\u00favidas, s\u00e3o mais confi\u00e1veis.<\/strong><\/p>\n

Sobre falhas, erros e defeitos<\/h2>\nO que voc\u00ea pensa quando v\u00ea uma rachadura pequena na tela de um celular? Eu sempre penso sobre em quanto tempo\u00a0 la ir\u00e1 se propagar e se h\u00e1 algo que possa ser feito para conten\u00e7\u00e3o. Algo semelhante acontece com sistemas de software.\n
\n

Em sistemas de software, toda falha \u00e9 uma esp\u00e9cie de rachadura pequena que, se n\u00e3o forem contidas, eventualmente, “espalhadas”, convertem-se em defeito.<\/p>\n

Pequenas falhas (faults<\/em>)<\/strong> – como bugs\u00a0<\/em>ou valida\u00e7\u00f5es insuficientes em “entradas” fornecidas por usu\u00e1rios – deixam o sistema em estado inconsistente, o que, ocasionalmente, d\u00e1 origem a erros (errors<\/em>)<\/strong>, ou seja, comportamentos indesejados do software que, eventualmente, culminam em defeitos\u00a0(failures<\/em>)<\/strong>, geralmente indisponibilidades.<\/p>\n

Falhas provocam erros que provocam defeitos.\u00a0<\/strong>Por exemplo, consultas SQL mal escritas s\u00e3o falhas que, eventualmente, geram lentid\u00e3o no banco para responder outras consultas que, por sua vez, causam o aumento nas filas de requisi\u00e7\u00f5es que, se prolongadas, “topam” mem\u00f3ria que, finalmente, tornam um sistema indispon\u00edvel.<\/p>\n

Reconhecendo que falhas s\u00e3o inevit\u00e1veis e cada vez mais comuns<\/h2>\n

Sistemas est\u00e3o ficando maiores, logo, mais complexos nos \u00faltimos anos.<\/strong> Esse “crescimento” associado com tecnologias como a nuvem, conduziram ao desenvolvimento de solu\u00e7\u00f5es com cada vez mais componentes, cada vez menores, mais f\u00e1ceis de manter e distribuir. Entretanto, “n\u00e3o h\u00e1 almo\u00e7o gr\u00e1tis”, maior a fragmenta\u00e7\u00e3o, maiores os riscos a confiabilidade.<\/p>\n

\"\"<\/p>\n

Estatisticamente, \u00e9 f\u00e1cil demonstrar que quanto mais componentes formam um sistema, maiores s\u00e3o as chances da ocorr\u00eancia de incidentes com potencial para gerar instabilidade. Em termos simples, falhas, al\u00e9m de inevit\u00e1veis, devem ocorrer com frequ\u00eancia cada vez maior.\u00a0<\/strong>Por isso, implementa\u00e7\u00f5es ing\u00eanuas resultam em sistemas cada vez menos confi\u00e1veis.<\/p>\n

\n

Resili\u00eancia implica em conten\u00e7\u00e3o de falhas<\/h2>\n<\/div>\n

A estrat\u00e9gia mais efetiva para evitar defeitos \u00e9 impedir que falhas se convertam em erros. <\/strong>Para isso, \u00e9 importante, al\u00e9m de tentar minimiz\u00e1-las, impedir que seus efeitos “se espalhem”.<\/p>\n

Em sistemas complexos, sem o devido cuidado, falhas em um componente “se espalham” rapidamente gerando erros em componentes com acoplamento eferente mais alto.<\/strong> Por isso, sob ponto de vista arquitetural, \u00e9 importante cuidar dos integration points\u00a0<\/em>adotando estrat\u00e9gias que mitiguem impactos de falhas, erros ou defeitos de um componente nos demais.<\/p>\n

As falhas em componentes remotos podem assumir diversas formas, incluindo falhas de comunica\u00e7\u00e3o ou comportamento. Componentes remotos podem se tornar inesperadamente indispon\u00edveis ou, o que \u00e9 muito pior, incrivelmente lentos. Por isso, \u00e9 essencial que pr\u00e1ticas defensivas sejam adotadas.<\/p>\n

M\u00e9tricas importantes para confiabilidade<\/h2>\nA defini\u00e7\u00e3o de m\u00e9tricas \u00e9 de extrema import\u00e2ncia para o projeto arquitetural.<\/strong> Afinal, as decis\u00f5es que ser\u00e3o tomadas ir\u00e3o na dire\u00e7\u00e3o de obter melhores resultados para estas m\u00e9tricas. Assim, a escolha da m\u00e9trica errada pode comprometer a qualidade das decis\u00f5es.\n
\n

H\u00e1 dois pares de m\u00e9tricas fundamentais para o\u00a0design <\/em>arquitetural de software com disponibilidade e confiabilidade.<\/p>\n

    \n
  1. Sob a perspectiva funcional, MTTR e MTBF;<\/li>\n
  2. Sob a perspectiva de dados, RPO e RTO.<\/li>\n<\/ol>\n
    \n

    MTTR e MTBF<\/h4>\n

    MTTR (Mean time to recover – <\/em>tempo m\u00e9dio para recupera\u00e7\u00e3o) tem rela\u00e7\u00e3o com o tempo em que uma falha <\/i>destr\u00f3i valor em produ\u00e7\u00e3o. MTBF (Mean time between failures<\/em> \u2013 tempo m\u00e9dio entre falhas) tem rela\u00e7\u00e3o com o intervalo de tempo at\u00e9 falhas serem que destroem valor serem observadas em produ\u00e7\u00e3o.<\/p>\n

    \n

    Historicamente, \u00e9 mais comum dar \u00eanfase a medidas como MTBF<\/strong>, principalmente, quando se adota pr\u00e1ticas mais focadas em disponibilidade do que em confiabilidade. Entretanto, para ser efetiva, demanda sistemas menos complexos e menos fragmentados. Quando a \u00eanfase \u00e9 confiabilidade, a m\u00e9trica mais apropriada \u00e9 MTTR.<\/strong><\/p>\n<\/div>\nM\u00e9tricas criam \u201ctens\u00f5es\u201d na opera\u00e7\u00e3o que direcionam decis\u00f5es e padr\u00f5es operacionais. A \u201ctens\u00e3o\u201d gerada pelo MTBF, que \u00e9 uma m\u00e9trica bem intencionada, \u00e9 espa\u00e7ar problemas em produ\u00e7\u00e3o o m\u00e1ximo poss\u00edvel, evitando preju\u00edzos percebidos. O problema \u00e9 que, implicitamente, essa m\u00e9trica acaba encorajando, tamb\u00e9m, o prolongamento dos intervalos entre deploys<\/i>, afinal, em um sistema que est\u00e1 funcionando bem, toda mudan\u00e7a \u00e9 fonte potencial de problemas. Indiretamente, em fun\u00e7\u00e3o de menos entregas em produ\u00e7\u00e3o, h\u00e1 aumento do\u00a0lead time\u00a0<\/i>e tamb\u00e9m do tamanho de cada entrega, gerando, curiosamente, aumento nas chances de falhas no ambiente produtivo, mais dif\u00edceis de identificar, prejudicando o MTTR.\n

    Os riscos do MTBF podem ser bastante mitigados se o\u00a0deploy\u00a0<\/i>acontecer em \u201can\u00e9is\u201d e a m\u00e9trica ficar restrita apenas ao anel mais amplo.<\/div>\n
    \n

    RPO e RTO<\/h4>\n

    Pensar sobre disponbilidade para dados \u00e9 mais desafiador do que para outros artefatos. Afinal, quando n\u00e3o h\u00e1 perda de dados, solu\u00e7\u00f5es mais cr\u00edticas tem rela\u00e7\u00e3o, apenas, com replica\u00e7\u00e3o ou reinicializa\u00e7\u00e3o.<\/p>\n

    As m\u00e9tricas associadas com dados s\u00e3o, respectivamente RPO (recovery point objective<\/em>) e RTO (recovery time objective<\/em>)<\/strong>.<\/p>\n

    RPO tem rela\u00e7\u00e3o com o volume de dados que podem ser perdidos no caso de ocorr\u00eancia de uma falha. RTO define quanto tempo \u00e9 tolerado para recuperar dados para devolver o sistema ao RPO, impactando diretamente o MTTR.<\/p>\n

    Geralmente o RPO \u00e9 indicado pela “janela de tempo” m\u00e1xima onde perdas s\u00e3o toleradas. Quando menor for esta janela, geralmente maior \u00e9 o RTO.<\/p>\nUma estrat\u00e9gia para reduzir impactos no RPO e RTO \u00e9 estabelecer pr\u00e1ticas de gest\u00e3o de dados conforme temperatura, mantendo apenas os dados mais “quentes” pr\u00f3ximos do ambiente produtivo onde os defeitos acontecem. Nessa linha, dados mais “frios” podem ser movidos para estruturas de armazenamento menos flex\u00edveis.\n

    \n<\/div>\n

    T\u00e1ticas para identificar a ocorr\u00eancia de falhas<\/h2>\n

    Health Checks\u00a0<\/em>(verifica\u00e7\u00e3o de integridade)<\/h4>\n

    A melhor forma de saber que um componente est\u00e1 funcionando bem \u00e9 “perguntando” para ele<\/strong>. Sob o ponto de vista arquitetural, isto implica em adicionar uma fun\u00e7\u00e3o de verifica\u00e7\u00e3o para a “sa\u00fade” em cada componente, geralmente acess\u00edvel atrav\u00e9s de um endpoint\u00a0<\/em>espec\u00edfico.<\/p>\n

    \"\"<\/p>\nA ideia \u00e9 fazer com que cada componente execute alguma rotina de auto-verifica\u00e7\u00e3o, geralmente alguma atividade sint\u00e9tica, retornando um valor que indique seu “n\u00edvel de sa\u00fade”. Obviamente, caso o componente n\u00e3o consiga processar a requisi\u00e7\u00e3o, isso indica problema.\n

    \n

    As\u00a0health checks\u00a0<\/em>devem ser utilizadas tanto por\u00a0load balancers,<\/i>\u00a0orquestrados de cont\u00eaineres e por ferramentas de monitoramento.<\/p>\n

    Eventualmente, as verifica\u00e7\u00f5es podem incluir as principais depend\u00eancias dos componentes, como bancos de dados, servi\u00e7os remotos, etc.<\/p>\n

    Watchdogs<\/em><\/h4>\n

    Enquanto health checks<\/em> operam passivamente, fornecendo informa\u00e7\u00f5es sobre a “sa\u00fade” dos componentes,\u00a0watchdogs\u00a0<\/em>atuam ativamente, muitas vezes acionando\u00a0health checks,\u00a0<\/em>para, sob determinadas circunst\u00e2ncias, disparar algum tipo de a\u00e7\u00e3o.<\/p>\n

    Um watchdog<\/em> \u00e9 um programa, frequentemente associado a ferramentas de APM e m\u00e9tricas de infraestrutura. Seu objetivo \u00e9 detectar automaticamente poss\u00edveis problemas de aplicativo e infraestrutura, observando continuamente tend\u00eancias e padr\u00f5es nas m\u00e9tricas e procurando comportamento at\u00edpico.<\/p>\nWatchdogs\u00a0<\/em>devem ser planejados na arquitetura, mas raramente devem ser implementados “dentro de casa”. Todos os fornecedores do nuvem oferecem alternativas altamente configur\u00e1veis e flex\u00edveis.\n

    T\u00e1ticas para impedir a propaga\u00e7\u00e3o de falhas<\/h2>\n

    Comunica\u00e7\u00e3o ass\u00edncrona<\/h4>\n

    Substituir chamadas diretas por trocas de mensagens \u00e9, provavelmente, a medida mais eficiente para aumentar a resili\u00eancia de sistemas de software.\u00a0<\/strong>A ideia \u00e9 substituir chamadas a componentes potencialmente inst\u00e1veis por mecanismos de mensageria comprovadamente s\u00f3lidos e est\u00e1veis.<\/p>\n

    A abordagem mais simples \u00e9 utilizar filas\u00a0p<\/em>oint-to-point. <\/i>Uma\u00a0alternativa mais sofisticada (e menos acoplada) \u00e9 a ado\u00e7\u00e3o de \u00a0pub\/sub<\/em>.<\/p>\n

    \"\"<\/p>\n

    Bulkheads<\/em><\/h4>\n

    J\u00e1 tratamos de bulkheads<\/em> quando falamos sobre estrat\u00e9gias para suportar escalabilidade. Entretanto, o padr\u00e3o tamb\u00e9m \u00e9 \u00fatil para cria\u00e7\u00e3o de sistemas resilientes.<\/p>\n

    \"\"<\/p>\n

    A ideia \u00e9 criar inst\u00e2ncias dedicadas de determinados componentes para alguns cen\u00e1rios de uso. Dessa forma, impedindo que falhas ou eventos em um contexto de consumo propaguem para os demais.<\/p>\n

    T\u00e1ticas para previnir falhas<\/h2>\n

    Back pressure<\/em><\/h4>\n

    Sempre o traffic intensity\u00a0<\/em>for desfavor\u00e1vel para um componente, o ideal \u00e9 que este passe a recusar novas demandas (usando load shedding <\/em>ou\u00a0rate limiting<\/em>),<\/em> devolvendo a “press\u00e3o” para o cliente que dever\u00e1 implementar alguma estrat\u00e9gia de retentivas ou, at\u00e9 mesmo, reduzir o volume de demandas com alguma estrat\u00e9gia de\u00a0gracefully degradation.<\/em><\/p>\n

    Do ponto de vista do componente que est\u00e1 adotando\u00a0back pressure,\u00a0<\/em>a implementa\u00e7\u00e3o \u00e9 restrita a algum mecanismo de sinaliza\u00e7\u00e3o (talvez retornando 429 – Too many requests<\/em>) para o cliente indicando a condi\u00e7\u00e3o. Caber\u00e1 ao cliente adotar estrat\u00e9gia apropriada, conforme sinaliza\u00e7\u00e3o.<\/p>\n

    Load shedding (Governor pattern)<\/em><\/h4>\n

    Assim como um rate limiter,\u00a0<\/em>um componente de\u00a0load shedding\u00a0<\/em>opera como um middleware\u00a0<\/em>que monitora os recursos computacionais necess\u00e1rios para um componente, bem como das depend\u00eancias, e recusa ativamente novas requisi\u00e7\u00f5es at\u00e9 que n\u00edveis saud\u00e1veis sejam restaurados.<\/p>\n

    Timeout<\/em><\/h4>\n

    Pior do que componentes que param de responder s\u00e3o aqueles que passam a operar com lentid\u00e3o incomum.<\/strong>\u00a0Estabelecer timeouts<\/em>\u00a0\u00e9 importante para impedir que componentes clientes esperem “tempo demais”, seja para solicita\u00e7\u00f5es s\u00edncronas quanto ass\u00edncronas.<\/p>\n

    \n

    Embora n\u00e3o haja uma “receita de bolo” para escolher um timeout<\/em> correto, eles devem ser relativamente curtos. A recomenda\u00e7\u00e3o segura \u00e9 150% do tempo m\u00e9dio de resposta do servi\u00e7o.<\/p>\n

    Circuit breaker<\/em><\/h4>\n

    Circuit breaker<\/em> \u00e9 uma inst\u00e2ncia de m\u00e1quina de estados implementada entre dois componentes, um “cliente” e o outro “servidor”. O objetivo de um\u00a0Circuit breaker\u00a0<\/i>\u00e9 proteger o “servidor” de requisi\u00e7\u00f5es enquanto este estiver enfrentando dificuldades (potencial satura\u00e7\u00e3o).<\/p>\n

    \"\"<\/p>\n

    O funcionamento da m\u00e1quina de estados \u00e9 a seguinte:<\/p>\n

      \n
    1. Circuito fechado\n
        \n
      • Toda requisi\u00e7\u00e3o do “cliente” deve ser encaminhada ao “servidor”<\/li>\n
      • Se houverem mais falhas do que o “aceit\u00e1vel” dentro de um intervalo de tempo, ent\u00e3o o circuito deve “abrir”.<\/li>\n<\/ul>\n<\/li>\n
      • Circuito aberto\n
          \n
        • Nenhuma requisi\u00e7\u00e3o do “cliente” deve ser encaminhada ao “servidor”, falhando imediatamente<\/li>\n
        • Transcorrido um determinado tempo, o circuito deve ficar “meio aberto”<\/li>\n<\/ul>\n<\/li>\n
        • Circuito meio aberto\n
            \n
          1. Algumas requisi\u00e7\u00f5es devem ser encaminhadas para o “servidor”, \u00a0outras negadas<\/li>\n
          2. Se as falhas persistirem, o circuito dever\u00e1 “abrir” novamente<\/li>\n
          3. Se as falhas n\u00e3o ocorrerem mais, o circuito dever\u00e1 “fechar”.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n

            Sumarizando<\/h2>\n

            Estrat\u00e9gias tradicionais para disponibilidade, baseadas em replica\u00e7\u00e3o e clusters<\/em>, n\u00e3o s\u00e3o mais suficientes para manter sistemas confi\u00e1veis.<\/strong><\/p>\n

            T\u00e3o importante quanto garantir que h\u00e1 recursos suficientes para atender as demandas de performance, sem satura\u00e7\u00e3o, \u00e9 tamb\u00e9m importante adotar pr\u00e1ticas e cuidados arquiteturais que identifiquem, previnam e interrompam a propaga\u00e7\u00e3o\u00a0de falhas, para que elas n\u00e3o se tornem erros e, finalmente, defeitos.<\/p>\n

            \/\/ TODO<\/h2>\n

            Antes de avan\u00e7ar para o pr\u00f3ximo cap\u00edtulo, recomendo as seguintes reflex\u00f5es:<\/p>\n

              \n
            1. Que padr\u00f5es para resili\u00eancia j\u00e1 adotou?<\/li>\n
            2. Qual a rela\u00e7\u00e3o entre a complexidade crescente dos sistemas e a demanda por resili\u00eancia?<\/li>\n<\/ol>\n","protected":false},"featured_media":2650,"parent":0,"comment_status":"open","ping_status":"closed","template":"","url":[],"sessoes":[58],"apendices":[],"capitulos":[41],"class_list":["post-2572","volume-1","type-volume-1","status-publish","has-post-thumbnail","hentry","sessoes-secao-2","capitulos-capitulo-2-4"],"acf":[],"yoast_head":"\nFundamentos para arquiteturas de sistemas resilientes \/ Cap\u00edtulo 13 v 1.0 - Manual do Arquiteto de Software<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/\" \/>\n<meta property=\"og:locale\" content=\"pt_BR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Fundamentos para arquiteturas de sistemas resilientes \/ Cap\u00edtulo 13 v 1.0 - Manual do Arquiteto de Software\" \/>\n<meta property=\"og:description\" content=\"Com a transforma\u00e7\u00e3o digital, sistemas est\u00e3o cada vez mais conectados. Clientes, parceiros e fornecedores t\u00eam cada vez mais acesso a sistemas que at\u00e9 bem pouco tempo eram acessados apenas “dentro de casa”. As “janelas para\u00a0downtime” est\u00e3o ficando cada vez menores. Nunca disponibilidade e confiabilidade foram t\u00e3o importantes. Defini\u00e7\u00f5es para disponibilidade e confiabilidade Disponibilidade \u00e9 um […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/\" \/>\n<meta property=\"og:site_name\" content=\"Manual do Arquiteto de Software\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/facebook.com\/eximiaco\" \/>\n<meta property=\"article:modified_time\" content=\"2024-01-11T21:02:05+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/07\/faults.jpeg\" \/>\n\t<meta property=\"og:image:width\" content=\"1024\" \/>\n\t<meta property=\"og:image:height\" content=\"683\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:site\" content=\"@eximiaco\" \/>\n<meta name=\"twitter:label1\" content=\"Est. tempo de leitura\" \/>\n\t<meta name=\"twitter:data1\" content=\"12 minutos\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/\",\"name\":\"Fundamentos para arquiteturas de sistemas resilientes \/ Cap\u00edtulo 13 v 1.0 - Manual do Arquiteto de Software\",\"isPartOf\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/07\/faults.jpeg\",\"datePublished\":\"2021-07-04T21:48:27+00:00\",\"dateModified\":\"2024-01-11T21:02:05+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/#breadcrumb\"},\"inLanguage\":\"pt-BR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/#primaryimage\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/07\/faults.jpeg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/07\/faults.jpeg\",\"width\":1024,\"height\":683},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Volume 1\",\"item\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Fundamentos para arquiteturas de sistemas resilientes \/ Cap\u00edtulo 13 v 1.0\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\",\"name\":\"Manual do Arquiteto de Software\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"pt-BR\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization\",\"name\":\"EximiaCo\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg\",\"width\":150,\"height\":150,\"caption\":\"EximiaCo\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/facebook.com\/eximiaco\",\"https:\/\/x.com\/eximiaco\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Fundamentos para arquiteturas de sistemas resilientes \/ Cap\u00edtulo 13 v 1.0 - Manual do Arquiteto de Software","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/","og_locale":"pt_BR","og_type":"article","og_title":"Fundamentos para arquiteturas de sistemas resilientes \/ Cap\u00edtulo 13 v 1.0 - Manual do Arquiteto de Software","og_description":"Com a transforma\u00e7\u00e3o digital, sistemas est\u00e3o cada vez mais conectados. Clientes, parceiros e fornecedores t\u00eam cada vez mais acesso a sistemas que at\u00e9 bem pouco tempo eram acessados apenas “dentro de casa”. As “janelas para\u00a0downtime” est\u00e3o ficando cada vez menores. Nunca disponibilidade e confiabilidade foram t\u00e3o importantes. Defini\u00e7\u00f5es para disponibilidade e confiabilidade Disponibilidade \u00e9 um […]","og_url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/","og_site_name":"Manual do Arquiteto de Software","article_publisher":"https:\/\/facebook.com\/eximiaco","article_modified_time":"2024-01-11T21:02:05+00:00","og_image":[{"width":1024,"height":683,"url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/07\/faults.jpeg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_site":"@eximiaco","twitter_misc":{"Est. tempo de leitura":"12 minutos"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/","name":"Fundamentos para arquiteturas de sistemas resilientes \/ Cap\u00edtulo 13 v 1.0 - Manual do Arquiteto de Software","isPartOf":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website"},"primaryImageOfPage":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/#primaryimage"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/#primaryimage"},"thumbnailUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/07\/faults.jpeg","datePublished":"2021-07-04T21:48:27+00:00","dateModified":"2024-01-11T21:02:05+00:00","breadcrumb":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/#breadcrumb"},"inLanguage":"pt-BR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/"]}]},{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/#primaryimage","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/07\/faults.jpeg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/07\/faults.jpeg","width":1024,"height":683},{"@type":"BreadcrumbList","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-1-0\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/"},{"@type":"ListItem","position":2,"name":"Volume 1","item":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/"},{"@type":"ListItem","position":3,"name":"Fundamentos para arquiteturas de sistemas resilientes \/ Cap\u00edtulo 13 v 1.0"}]},{"@type":"WebSite","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/","name":"Manual do Arquiteto de Software","description":"","publisher":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"pt-BR"},{"@type":"Organization","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization","name":"EximiaCo","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/","logo":{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg","width":150,"height":150,"caption":"EximiaCo"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/facebook.com\/eximiaco","https:\/\/x.com\/eximiaco"]}]}},"_links":{"self":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/volume-1\/2572","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/volume-1"}],"about":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/types\/volume-1"}],"replies":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/comments?post=2572"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media\/2650"}],"wp:attachment":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media?parent=2572"}],"wp:term":[{"taxonomy":"url","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/url?post=2572"},{"taxonomy":"sessoes","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/sessoes?post=2572"},{"taxonomy":"apendices","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/apendices?post=2572"},{"taxonomy":"capitulos","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/capitulos?post=2572"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}