Em agosto de 2013, a Amazon teve seu site – principal canal de vendas – fora do ar por aproximadamente 40 minutos. Segundo o portal VentureBeat [1], o prejuízo estimado pelo período fora do ar foi de $4.72 milhões de dólares. No ano anterior, a companhia também registrou instabilidades no mês de Junho [2] e Outubro [3] nos serviços de cloud impactando diversas empresas como Netflix, Instagram, Pinterest, Reddit, Airbnb e Coursera.
Nomeamos sistemas com grande usabilidade e larga operação de sistemas de missão crítica e, em ocasiões como essas, vemos os efeitos e prejuízos de quando estes sistemas apresentam inoperabilidade, mesmo que por um período de curta duração.
O que é missão crítica
Missão crítica tem como propósito fornecer uma solução confiável e resiliente a um mercado ou segmento, evitando paralisação e perda de dados. Mas, como definimos a taxa de disponibilidade de cada solução? Por quanto tempo uma indisponibilidade seria viável?
A resposta mais apropriada para esses questionamentos é: depende. O nível de criticidade e a necessidade técnica variam de indústria para indústria e de acordo com a dimensão de cada operação, mas – em termos gerais – aplicações de massa crítica não deveriam experimentar nenhuma instabilidade quando os usuários estão utilizando-a.
Para explicar o “depende”, vou utilizar um exemplo: um sistema de controlador aéreo exige que o sistema esteja 100% operante e disponível para qualquer ação, uma vez que temos sempre aeronaves voando de um lado ao outro do globo terrestre. Em contrapartida, por mais que um sistema bancário realize transações diariamente, existem algumas “janelas” operacionais de menor uso pelos clientes e de funcionamento das instituições que possibilitam uma paralisação momentânea nesses intervalos apresentados.
Esses indicadores são úteis para a tomada de decisão de quais tecnologias, recursos, investimento e manutenção são necessários para manter os serviços dessa solução sempre disponíveis. Para isso, é importante considerarmos o uptime e downtime.
Disponibilidade e tolerância de falha
Uptime é o tempo em que uma solução está em uso, e o Downtime é o tempo em que ela não está. Provido dessas informações, temos uma base para definir o nível de disponibilidade esperado e qual SLA (service level agreement) deve ser respeitado nesse ambiente.
Ainda utilizando o exemplo anterior, poderíamos dizer que o valor de uptime esperado de um sistema bancário é de 99,9%. O ano possui 365 dias – 8.760 horas, com isso, o sistema precisa estar disponível por aproximadamente 8.751 horas e ter no máximo 9h de paralisação em um ano; isso visando garantir que o sistema respeite a necessidade o SLA de 99.9% operando.
No caso do operador aéreo, 9h de indisponibilidade representa um grande prejuízo à operação. Logo, o tempo de indisponibilidade precisa ser muito menor, o que eleva a taxa de uptime e gera um rígido SLA de 99.9999% e uma taxa de downtime de cerca de 31 segundos por ano! Para outras simulações em escala de tempo o Portal uptime pode ser bem adequado.
Vale salientar que o tempo de tolerância de falha não contempla paralisações programadas para atualização de serviços, sistemas ou manutenção preventiva, e de que todo sistema é passível de falha, ou seja, é irrealizável a definição de sistemas com SLA de 100%. O anseio para que seja atingido “high availability” em absoluto depende de uma série de variáveis e sempre haverá uma margem para erros.
Uma forma prática para ilustrar como sistemas e equipamentos não conseguem alcançar o 100% absoluto é o serviço de GPS (Global Positioning System). Seu funcionamento é baseado no cálculo da triangulação (diferença do tempo das ondas eletromagnéticas de diferentes pontos da terra) de três ou mais satélites em relação ao emissor do sinal. Porém, o campo eletromagnético da terra sofre variações em consequência da radiação solar e das variações de sua rotação. Isso dificulta o cálculo da triangulação e é aí que entra o relógio atômico. Ele é responsável por realizar a contagem das transições de energia dos elétrons de alguns elementos químicos (podendo ser césio ou hidrogênio, por exemplo) para medir a passagem do tempo de forma precisa e calibrar a operação. Sobre isso, o professor Ricardo José de Carvalho, chefe de divisão do serviço da ordem do Observatório Nacional (ON/MCT), relata em sua reportagem ao portal Inovação Tecnológica [5] que “relógios baseados na frequência atômica do Hidrogênio levariam 10 milhões de anos para atrasar ou adiantar um segundo”. Ou seja, até mesmo a variável das mudanças da natureza demonstra como instrumentos e sistemas de suma precisão podem ser sensíveis e apresentar falhas.
Criando aplicações de missão crítica
Uma vez que definimos o avaliability que o mercado ou o segmento exige e qual SLA deve ser respeitado, vários arquitetos e engenheiros de solução podem apresentar o cloud computing como principal premissa e único garantidor. Atualmente, muito se tem falado em cloud first strategy e sobre como carregam inúmeros benefícios em diversas dimensões de uma solução. Todavia, vale mencionar que cloud first não tem como sinônimo direto cloud only e essa liberdade e tomada de decisão depende muito dos interesses de cada organização. Por mais que haja muitas vantagens, algumas organizações continuam com sua infraestrutura on-premise. O fato é que os critérios primários que dominarão essa decisão serão os recursos computacionais requeridos, budget, custo de manutenção e da estratégia organizacional.
Apenas com esses tópicos iniciais, é possível evitar situações como a do dia 26 de julho de 2021 [6] onde a plataforma Lattes, sistema dos pesquisadores do CNPq – Conselho Nacional de Desenvolvimento Científico e Tecnológico, tiveram uma parada operacional e uma provável perda de dados devido a “queima” do servidor em que a aplicação estava hospedada e a carência de backup dos dados. Esse fato, mais uma vez, reafirma que as instituições independentemente do modelo utilizado (on-premise ou cloud computing) devem se atentar à alguns itens fundamentais para qualquer estruturação de uma solução crítica.
De acordo com o fato acima, podemos afirmar que é prioritário possuir uma governança e time estruturados para garantir a operabilidade e manutenção preventiva e precativa dos recursos. Ecossistemas que não possuem uma central de observability e apm (Application Performance Management) sempre estarão cegos sobre como o real funcionamento e status de suas aplicações em ambientes produtivos. Isso, muito provavelmente, só será perceptível aos stakeholders (parte interessada e responsável pela parte do negócio) e administradores da solução quando o usuário final já estiver experimentando erros na aplicação. O simples uso de logging e a implementação de health-check dos services e dos third-parties services que alimentam um dashboard de monitoramento em tempo real entregam muito valor no acompanhamento atual de resposta ou falha e identificação imediata do nó inoperante.
Além disso, a resiliência dos recursos e serviços é primordial. Considerando que todas as aplicações de missão crítica armazenam algum tipo de informação (seja dado transacional, logging ou auditoria do sistema). Manter esses dados seguros e protegidos é vital para muitas operações. Vai muito além de realizar um backup para os dados, é gerir e disponibilizar – mesmo com uma alta volumetria – o acesso a essas informações por meio dos services com uma baixa latência. Estratégias como segmentação dos dados por access tiers (archive, cold and hot), redundancy e replication, asseguram múltiplas cópias dos dados localmente ou em múltiplas regiões para os proteger de qualquer evento (planejado ou não), incluindo falhas de hardwares, rede, quedas de energia e desastres naturais.
Outro item a se considerar é concurrency, capacidade de escalar as aplicações horizontalmente ou verticalmente. Por alguns anos, o comércio e varejo enfrentaram muita dificuldade de manter suas aplicações disponíveis sem gargalos de atendimento ou latência de resposta das requisições devido as campanhas sazonais que acentuam muito os acessos às plataformas e as demandas na operação. Concurrency ataca frontalmente esse problema permitindo que as soluções possam crescer e diminuir elasticamente, independentemente do tamanho da operação ou demanda apresentada. Negligenciar o movimento flexível dos serviços certamente demonstra desconfiança do vendor no mercado e traz prejuízos às instituições. A CNN juntamente com a Sofist, empresas que monitoram a performance de grandes varejistas, estimam que, devido a lentidão e instabilidade técnicas nos e-commerces nas primeiras 12 horas da Black Friday de 2021, podem ter resultado em um prejuízo de R$ 8.1 milhões [7].
Tudo isso não importando qual modelo utilizado (on-premise ou cloud), poderá ser impraticável se não considerado medidas de safety (proteção contra ameaças cibernéticas). Aqui, podemos destacar dois eventos extremamente críticos: o primeiro, aconteceu em 2011 [8] quando a ex-presidente Dilma Rousseff foi vítima de invasão cibernética onde o invasor teve acesso a 300 mensagens, a exames e a dados sigilosos da ex-presidente no Superior Tribunal Militar. O segundo, 11 anos depois em agosto de 2022, [9] o grupo ‘Everest’ declarou terem roubado mais de 3 TB de dados do governo federal. Esses fatos de extrema gravidade ilustram os trágicos resultados que a negligência da segurança pode originar.
Podemos examinar esse item em 3 níveis: nível de aplicação, nível de arquitetural e nível de governança. Sem dúvidas, todos os níveis fazem interligações com as áreas de DevSecOps e Cyber Security, mas iremos limitar nossa discussão no âmbito da construção de soluções.
Os níveis de aplicação e arquitetura se responsabilizam pela definição e implementação de ferramentas que formarão as proteções e defesas da solução. Ferramentas como cofre de senhas – utilizado inclusive em sistemas de armazenamento em nuvem (OneDrive, Google Drive) – deveriam ser sempre pré-requisitos. A manipulação por vias humanas das credenciais tanto na aplicação quanto no deploy dos ambientes, eleva drasticamente a possibilidade de vazamento e erros de segurança. De acordo com o relatório da Verison’s Data Breaches de 2022 [10], 82% das violações envolvem o elemento humano, logo, isso é um dos principais gargalhos de segurança e de risco à uma solução de missão crítica. Outros elementos como criptografias, tokens de autorização e expiração destes parecem ser triviais, porém devem ser mencionados uma vez que nem todas as aplicações parecem utilizá-las.
Outros recursos de proteção de rede e recursos como sandbox environments, api gateways, api proxy, firewall e outros itens de infraestrutura poderiam formar uma segunda camada de segurança de invasão. Mesmo com todos esses elementos implementados e operantes, só serão efetivos se o monitoramento de vulnerabilidades e monitoramento destas ameaças indicar onde é necessário fortalecer as barreiras e, através dessas análises, aprender o comportamento e como funcionam esses ataques. Uma constante atualização das janelas de vulnerabilidade e entendimento da evolução e/ou transformação dos ataques cibernéticos permitirá atuações mais precisas e assertivas. Boas práticas de execução periódica de ferramentas como o uso do Pentesting (Penetration test ou ethical hacking) – ataque simulado de um conjunto de ferramentas e sistemas para medição e avaliação da segurança – devem ser consideradas.
Disaster and Recovery
Mesmo considerando todas as instruções descritas em cada tópico, é primordial a definição de um plano de Disaster and Recovery. Este plano é responsável por definir políticas e ações de resposta a qualquer evento inesperado como ataques cibernéticos, desastres naturais, quedas de energia ou inoperabilidade de recursos. Normalmente, essas políticas podem ser definidas por tipos de catástrofe, índice de criticidade ou até por localização, a ponto de determinar um script de orientações simples e assertivas que devem ser atendidas em caso de falha.
Da mesma forma que temos uptime e o downtime para de determinar o tempo de disponibilidade/indisponibilidade que uma aplicação de missão crítica deve obedecer, para o plano de disaster and recovery temos o RTO (Recovery Time Objective) e o RPO (Recovery Point Objective).
RTO refere-se ao tempo máximo tolerável que um recurso pode ficar indisponível depois de um desastre inesperado até sua total restauração. Similar ao downtime, o RTO também depende da criticidade de cada regra de negócio, aplicações de missão crítica poderão exigir que a recuperação seja praticamente instantânea, porém com a diferença que não se refere à quantidade máxima de tempo de falha, mas sim de recuperação.
RPO por sua vez, se refere a quantidade máxima de perda de dados permitida após um incidente de perda de dados medido pela quantidade de tempo. Basicamente, é indicar um “ponto” no tempo antes de qualquer evento de desastre para que possa ser restaurado com maior confiabilidade de backup. Por exemplo: houve uma queda de energia e o ponto de recuperação (RPO) é de 15 horas e o último backup foi de 10 horas atrás. Desta maneira, estaríamos dentro do RPO exigido pela regra de negócio. O fator tempo, lembra muito o papel que o RTO desempenha e, sim, eles podem ser relacionados, mas não confundidos ao afirmar que são a mesma coisa. Eles apenas se complementam, lembre-se: o RPO é responsável em indicar – através do tempo – o ponto máximo de recuperação de dados sem exceder esse limite.
Abaixo, podemos ver de uma maneira didática um fluxo para a construção e manutenção do plano de Disaster and Recovery desde a análise até a definição dos steps e acompanhamento periódico.
Figura 1 – Fluxo de construção de um plano de Disaster and Recovery
O fluxo acima demonstra a importância de análise da regra de negócio e da infraestrutura no objetivo de serem aderentes e assertivos em qualquer cenário de falha. Eles serão os balizadores de quais estratégias devem ser adotadas e como reagir nos eventos inesperados. Felizmente, com o uso da tecnologia e infraestrutura correta, já é possível realizar recuperações de curtíssimo tempo ou até mesmo instantâneas. Tudo dependerá da necessidade, investimento e melhoria contínua.
Vemos que os desafios envolvidos em todas os tópicos descritos nos levam a sempre considerar o conceito de zero trust. Mesmo que este conceito seja mais utilizado na área de segurança, podemos nos apropriar da definição de que qualquer fator, interno ou externo, deve ser considerado como hostil, podendo se modificar de maneira orgânica no ecossistema e apresentar falha.
Evidentemente, aplicações de missão crítica exigem que os stackeholders estejam cientes de que para atender tal necessidade do mercado é necessário investimento, levantamento sólido dos requisitos e uma cultura de colaboração mútua para que este objetivo seja alcançado. O desequilibro de qualquer um desses itens implicará em prejuízo seja na esfera sistêmica, de dados ou do próprio negócio. Sendo assim, como qualquer projeto, o excesso de burocracia ou resistência juntamente com a negligência técnica comprometerá a construção de um parque tecnológico saudável e sustentável.
Referências:
[1] https://venturebeat.com/business/amazon-website-down/
[2] https://venturebeat.com/cloud/amazon-outage-netflix-instagram-pinterest/
[3] https://venturebeat.com/cloud/amazon-cloud-outage-takes-down-reddit-airbnb-flipboard-more/
[8] https://exame.com/tecnologia/hacker-invadiu-o-e-mail-pessoal-da-presidente-dilma-diz-jornal/
[10] https://www.verizon.com/business/resources/reports/dbir/
https://www.infowester.com/missaocritica.php
https://www.techtarget.com/searchitoperations/definition/mission-critical-computing
https://mundoeducacao.uol.com.br/fisica/relogio-atomico.htm
https://www.sofisica.com.br/conteudos/curiosidades/gps.php
https://brasilescola.uol.com.br/fisica/o-campo-magnetico-terra.htm
