Quer estejamos transmitindo um filme em nosso telefone, analisando imagens de satélite com modelos de aprendizado de máquina ou apenas marcando um jantar, simplesmente esperamos que as tecnologias nas quais nos apoiamos funcionem perfeitamente – sempre. A tecnologia da informação (TI) está cada vez mais no centro de nossas vidas sociais, trabalho, escolas, sistemas de saúde e muito mais. E como todos nós já experimentamos, quando ocorrem interrupções, os impactos podem ser dolorosos.
Para as empresas que criam os produtos e serviços digitais que usamos, atender às nossas crescentes expectativas significa garantir que esses serviços estejam sempre disponíveis, sem tempo de inatividade, nunca — mesmo no caso de picos de demanda, desastres naturais, ataques cibernéticos ou erro humano. Essa consistência é conhecida como 99,999% de tempo de atividade, ou “cinco noves” no jargão da engenharia, e as ferramentas da Amazon Web Services (AWS) permitem que mais e mais clientes alcancem cinco noves de disponibilidade.
Assim como acontece com a segurança dos aplicativos executados na nuvem, a responsabilidade pela disponibilidade e resiliência desses aplicativos é compartilhada. A parte da negociação da AWS é construir uma infraestrutura de nuvem que possa resistir a interrupções de quase qualquer tipo ou escala. A AWS faz isso em grande parte primeiro criando várias zonas de disponibilidade (AZ) nas regiões da AWS em todo o mundo. Cada zona de disponibilidade consiste em um ou mais data centers com energia, refrigeração e segurança física próprias. As AZs em uma região da AWS são conectadas por meio de redes redundantes de latência ultrabaixa. Na contagem mais recente, a AWS tem 96 zonas de disponibilidade em 30 regiões geográficas em todo o mundo.
As zonas de disponibilidade são projetadas para estarem geograficamente distantes o suficiente para diminuir o risco de que qualquer evento possa impactar outro datacenter na região da AWS. Mas eles não estão tão distantes que a continuidade dos negócios seja um problema para os clientes se eles tiverem cargas de trabalho em mais de uma zona de disponibilidade (muitos o fazem) ou tiverem que mudar para outro AZ por qualquer motivo, seja devido a um grande aumento na demanda ou um terremoto. A infraestrutura da AWS tem backups para os backups e mais alguns.
O lado da equação de responsabilidade do cliente da AWS é garantir que os serviços que estão executando na infraestrutura da AWS sejam projetados com a mesma disponibilidade e resiliência contínuas em mente. Justin Waite, vice-presidente de engenharia da Cisco, diz que, embora esse tipo de resiliência completa nem sempre seja possível, o truque é otimizar os processos que entram em ação quando há interrupções.
“É muito difícil atingir a perfeição em um espaço de tecnologia”, disse Waite. “Os fluxos e refluxos e os tiques e taques estão acontecendo tão rapidamente que você pode trabalhar para aperfeiçoar algo e então alguém pode aparecer com uma ferramenta que a torna completamente obsoleta. Tudo vai falhar em algum momento. A questão é: “Como falhamos graciosamente e como garantir a experiência correta do cliente quando ocorre uma falha?”
Dê aos engenheiros espaço para experimentar com segurança
Waite disse que a nuvem mudou a equação para transformar uma ideia em um produto que pode ser oferecido aos clientes de forma rápida e confiável.
“Agora, as decisões podem ser tomadas e as lâmpadas acesas em questão de minutos. Não leva um ano planejando e imaginando como vamos colocar tudo isso em uma determinada região, data center ou colocation, com determinado hardware, rede e assim por diante.”
De acordo com Waite, um elemento crucial na construção de produtos que funcionam “como mágica”, praticamente sem tempo de inatividade, é dar às equipes de engenharia seu próprio espaço de criação – um lugar onde elas têm a liberdade de mexer com segurança nas ferramentas de nuvem. Essas ferramentas funcionam como telas abertas, permitindo que os desenvolvedores avancem os produtos e comecem a jogar em cenários “e se”, sem ter que se preocupar em quebrar algo real e causar problemas no negócio principal.
“Isso é muito diferente do gerenciamento que distribui um diagrama de roteiro de produto com especificações de hardware. Você começa a ver os desenvolvedores resolvendo problemas – não necessariamente de maneiras mais inteligentes, mas com mais experimentação”, disse Waite. “Claro, haverá algumas falhas, mas trata-se de encorajar uma mentalidade de ‘experimentar e comprar’. Quer ver o que acontece quando alguém puxa aquele plugue ou um usuário pressiona este botão? Ótimo, aí está. Experimente um dispositivo ou serviço de Internet das Coisas (IoT)? Legal, aí está é. Por causa da nuvem, os desenvolvedores têm uma caixa de ferramentas muito maior.”
Para Roustem Karimov, fundador do gerenciador de senhas 1Password , a “maior caixa de ferramentas” oferecida pela Nuvem AWS foi o que permitiu que ele e seus cofundadores criassem sua empresa e oferecessem atendimento constante a seus clientes.
Quando Karimov criou o primeiro protótipo do 1Password ao lado do cofundador Dave Teare, há mais de uma década, como um projeto paralelo para seu outro trabalho, o espectro de ferramentas de nuvem que ele e sua equipe agora têm à disposição não estava disponível. Como consequência, o 1Password simplesmente não era possível ainda, disse ele. Mas em 2016, com a tecnologia AWS ao seu alcance, ele disse que o modelo de negócios – gerenciamento de senhas com segurança, em escala e em tempo real – finalmente fazia sentido.
Hoje, mais de 100.000 empresas em todo o mundo confiam no 1Password para gerenciar suas senhas e esperam disponibilidade o tempo todo (o 1Password também oferece serviços para indivíduos e famílias). Para Karimov e sua equipe, isso significa manter os sistemas funcionando mesmo quando o tráfego é anormalmente alto, um componente do código falha ou hackers tentam atacar o sistema. Caso contrário, funcionários, gerentes e executivos – clientes do 1Password – podem ser repentinamente bloqueados de seus aplicativos críticos.
Então, como eles projetaram contra cenários apocalípticos?
“Em primeiro lugar, a AWS nos permitiu garantir que não houvesse um único ponto de falha. Cada componente da infraestrutura tem uma opção de failover. Além disso, podemos criar um serviço 1Password inteiro — todo o ambiente — incluindo todos os componentes, bancos de dados, caches e servidores de aplicativos executando apenas um único script”, disse Karimov.
A automação da infraestrutura permite que o 1Password atraia novos clientes e atenda os existentes de forma rápida, previsível e confiável.
“Temos vários ambientes de desenvolvimento, ambientes de teste, ambientes de preparação e ambientes de produção”, disse Karimov. “Isso nos permite ter um processo que leva o sistema do desenvolvimento ao teste, preparação e produção em tempo real e nunca perde um momento de serviço.”
O 1Password executa todos os seus serviços por meio da nuvem, contando com a infraestrutura e as ferramentas de nuvem da AWS que possibilitam esse tipo de disponibilidade constante.
“Se estivéssemos tentando fazer isso manualmente, sem a nuvem, nosso tempo de atividade não seria possível”, disse Karimov.
Prepare-se para quando as coisas piorarem: três dicas para evitar interrupções
O engenheiro distinto e vice-presidente sênior da Amazon, James Hamilton, oferece três maneiras de dar a cada empresa a melhor chance no mais alto nível de disponibilidade.
Automatize o máximo possível. De acordo com o Uptime Institute, a maioria das interrupções é causada por erro humano, comumente introduzido em tarefas como testes, backups e revisões de código. Automatize o máximo que puder, para que erros humanos não aconteçam.
Teste os conhecidos e desconhecidos e quebre as coisas antes que elas realmente quebrem. O teste pode assumir a forma de quebrar coisas propositalmente e ver o que acontece. O objetivo é submeter seu sistema a cenários do mundo real que você pode antecipar, bem como aqueles que podem parecer fora do reino das possibilidades. Ao testar os limites do seu sistema sob circunstâncias controladas, você pode estar pronto para corrigir problemas e evitar o tempo de inatividade quando ocorrerem problemas. Se você praticar as ações e os passos que tomaria durante um desastre, antes que um evento real ocorra – e acontecerá – você estará pronto. Colete e analise continuamente dados de seus aplicativos e, tão importante quanto, unifique-os. Ter uma única fonte de verdade tornará mais fácil para sua equipe de desenvolvimento identificar problemas e corrigi-los. Você pode reduzir bastante o tempo gasto na solução de problemas e na correção de bugs se todos estiverem lendo o mesmo conjunto de dados e usando as mesmas ferramentas de análise.
Fonte: About Amazon