-
Notifications
You must be signed in to change notification settings - Fork 543
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #3140 from cncf/dev-pt
[PTBR] Merge dev-pt in the main branch
- Loading branch information
Showing
2 changed files
with
35 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,16 @@ | ||
--- | ||
title: Engenharia do Caos | ||
status: Completed | ||
category: conceito | ||
tags: ["metodologia"] | ||
--- | ||
|
||
A Engenharia do Caos, ou CE, é a disciplina de experimentar em um [sistema distribuído](/pt-br/distributed-systems/) em produção para construir confiança na capacidade do sistema de resistir a condições turbulentas e inesperadas. | ||
|
||
## Problema relacionado | ||
|
||
As práticas de [SRE](/pt-br/site-reliability-engineering/) e [DevOps](/pt-br/devops/)focam em técnicas para aumentar a resiliência e [confiabilidade](/pt-br/reliability/) do produto. A capacidade de um sistema de tolerar falhas enquanto garante qualidade de serviço adequada é tipicamente um requisito de desenvolvimento de software. Existem vários aspectos envolvidos que podem levar a falhas de um aplicativo, como infraestrutura, plataforma ou outras partes móveis de um aplicativo baseado em [microserviços](/pt-br/microservices/). A implantação frequente de novos recursos no ambiente de produção pode aumentar a probabilidade de tempo de inatividade e um incidente crítico — com consequências consideráveis para o negócio. | ||
|
||
## Como ajuda | ||
|
||
A engenharia do caos é uma técnica para atender aos requisitos de resiliência. É usada para alcançar resiliência contra falhas de infraestrutura, plataforma e aplicativo. Engenheiros de caos usam experimentos de caos para injetar proativamente falhas aleatórias e verificar se um aplicativo, infraestrutura ou plataforma pode se recuperar automaticamente e se a falha não pode afetar perceptivelmente os clientes. Os experimentos de caos visam descobrir pontos cegos (por exemplo, técnicas de monitoramento ou de escalonamento automático) e melhorar a comunicação entre equipes durante incidentes críticos. Essa abordagem ajuda a aumentar a resiliência e a confiança da equipe em sistemas complexos, especialmente em produção. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,19 @@ | ||
--- | ||
title: Edge Computing | ||
status: Completed | ||
category: Tecnologia | ||
--- | ||
|
||
A computação de borda é um modelo de [sistema distribuído](/pt-br/distributed-systems) que transfere parte da capacidade de armazenamento e processamento do [*data center*](/pt-br/data-center) principal para as fontes de dados. | ||
Os dados coletados são processados localmente (por exemplo, em uma fábrica, em uma loja ou em toda uma cidade) em vez de serem enviados para um *data center* centralizado para processamento e análise. | ||
Essas unidades ou dispositivos de processamento locais representam a borda do sistema, enquanto o *data center* é o seu centro. | ||
A saída processada na borda é então enviada de volta para o *data center* principal para processamento adicional. | ||
Exemplos de computação de borda incluem dispositivos vestíveis ou computadores que analisam o fluxo de tráfego. | ||
|
||
## Problema relacionado | ||
|
||
Na última década, vimos um aumento significativo nos dispositivos de borda (por exemplo, telefones celulares, relógios inteligentes ou sensores). Em alguns casos, o processamento de dados em tempo real não é apenas um recurso agradável de se ter, mas vital. Pense nos carros autônomos. Agora imagine se os dados dos sensores do carro tivessem que ser transferidos para um *data center* para processamento antes de serem enviados de volta para o veículo para que ele possa reagir adequadamente. A latência de rede inerente poderia ser fatal. Embora este seja um exemplo extremo, a maioria dos usuários não gostaria de usar um dispositivo inteligente que não pode fornecer feedback instantâneo. | ||
|
||
## Como ajuda | ||
|
||
Como descrito acima, para que os dispositivos de borda sejam úteis, eles devem fazer pelo menos parte do processamento e análise localmente para fornecer feedback quase em tempo real aos usuários. Isso é alcançado transferindo alguns recursos de armazenamento e processamento do *data center* para onde os dados são gerados: o dispositivo de borda. Os dados processados e não processados são posteriormente enviados para o *data center* para processamento e armazenamento adicionais. Em resumo, eficiência e velocidade são os principais impulsionadores da computação de borda. |