Quando iniciamos o Glassix, novos recursos eram a principal prioridade, acima de quase tudo. Nossos primeiros clientes não perderam muito sono com o SLA de tempo de atividade; Eles queriam sua interface de usuário novíssima e a próxima integração de canais!

Quando assinamos nossos primeiros grandes clientes, suas prioridades eram diferentes. Embora ainda se preocupassem com a funcionalidade, também se preocupavam com a resiliência; um centro de suporte ao cliente com 40 agentes por turno não podia se dar ao luxo de ficar off-line porque tínhamos um servidor preguiçoso.

Então, há cerca de um ano e meio (convenientemente na mesma época em que minha filha nasceu), nossa plataforma começou a responder lentamente a vários pedidos. E por lentamente, quero dizer cerca de 20 segundos em média. Como agente, era quase impossível trabalhar desta forma. Esse problema (que mais tarde descobrimos estar relacionado a um backup oculto em nosso provedor de nuvem) acontecia por cerca de 20 longos minutos todas as semanas até que encontramos o problema.

Este foi um alerta para Glassix. A empresa, reconhecendo o equilíbrio crítico entre inovação e fiabilidade, começou a redireccionar recursos para o fortalecimento da sua infra-estrutura.

Apercebemo-nos de que tínhamos de agir rapidamente em alguns dos nossos projectos, pelo que também aproveitámos o poder das soluções de externalização e dos freelancers, que nos ajudaram a atingir os nossos objectivos em tempo útil.

Agora, além da lista de verificação usual, como cache, dimensionamento horizontal e CDN, também fizemos o seguinte:

Modo offline

Mesmo com um sinal de rede ruim, você ainda pode abrir e visualizar mensagens no seu aplicativo WhatsApp . Você pode até enviar mensagens e, quando estiver online, elas serão enviadas automaticamente. Magia!

A mesma coisa com Glassix. Experimente agora: fique off-line e navegue até seu espaço de trabalho Glassix. Você pode visualizar mensagens e imagens (que foram armazenadas em cache antes), enviar mensagens, visualizar respostas prontas, fechar tickets e atribuir conversas. Todas essas ações estão na fila e serão sincronizadas quando você estiver online novamente. É um dos nossos recursos de resiliência do qual mais me orgulho. Usamos o Workbox , que simplifica o processo de criação de aplicativos da web compatíveis com o modo off-line, facilitando a criação de experiências de usuário confiáveis, mesmo quando a rede não é confiável.

Nosso modo offline pode mitigar problemas de rede que nossos clientes possam enfrentar.

Pares de serviços paralelos 

Usamos tantos bancos de dados e serviços que perdi a conta: MongoDB, SQL server, Elastic search, Redis, Ably, aplicativos estáticos, funções sem servidor e muito mais.

Os serviços cobertos por um SLA com disponibilidade de quatro noves – ou 99,99% – podem ficar indisponíveis 52 minutos e 36 segundos por ano. A disponibilidade de três noves – 99,9% – permite 8 horas e 46 minutos de inatividade anualmente.

Digamos que cada um desses serviços principais fique inativo por 2 horas no total, uma vez por ano. Isso significa que ficaremos inativos por pelo menos 24 horas por ano, algo com o qual não podemos conviver! 

Então, é claro, todo serviço em nuvem vem com um backup, mas pela nossa amarga experiência, é necessário mais.

Nossa solução cara funciona bem: cada serviço principal possui um serviço de redundância.

a. O serviço de tabelas do Azure é executado com AWSdynamoDB.

b. SignalR com Ably.

c. Os aplicativos estáticos são replicados em cinco regiões armazenadas em cache no balanceador de carga.

d. CDN rápido com CDN do Azure.

e. Redis com Elasticache.

f. Vários domínios em caso de falha de DNS : *.glassix.com e *.glassix.io

E a lista continua.

Engenharia do caos

A Engenharia do Caos é uma abordagem disciplinada para identificar falhas antes que se tornem interrupções. Ao testar proativamente como um sistema responde sob estresse, você pode identificar e corrigir falhas antes que elas acabem nos noticiários. Basicamente, significa começar a quebrar coisas!

Desta forma, identificamos minuciosamente todos os pontos de gargalo da nossa plataforma e os resolvemos (com outros serviços/lógica diferente).

Você ama seu serviço Redis? Desligue-o (ou melhor ainda, bloqueie todos os IPs; dessa forma, você sempre atinge o timeout máximo configurado para cada solicitação). Descobrimos que você não pode fazer login em nosso aplicativo se o Redis estiver inativo devido ao nosso token CSRF.

Seu CDN? Bagunce seus registros DNS e veja o que acontece.

Descobrimos que sem o CDN nosso aplicativo trava. Portanto, implementamos uma lógica de nova tentativa em todos os lugares: primeiro, carregamos do CDN primário (Fastly); se falhar, vamos para o secundário (Azure CDN) e se falhar, vamos para o host atual.

Sacrifique poucos para salvar muitos

Este conceito em engenharia de software refere-se a fazer concessões ou decisões que podem envolver o sacrifício do desempenho ou dos recursos de alguns componentes ou processos para melhorar a confiabilidade e estabilidade geral de um sistema de software. Este conceito é frequentemente aplicado a situações com recursos limitados ou onde a otimização de cada componente não é viável ou prática.

No nosso caso, definimos tempos limite curtos para solicitações HTTP e SQL não críticas. Isso significa que eles serão os primeiros a falhar quando o SQL ou outro serviço não estiver funcionando bem, mas aliviamos a carga sobre esses serviços descartando essas solicitações não críticas rapidamente.

Disjuntor

Falhar rápido é fundamental. Considere um exemplo: muitos usuários acessam um serviço que está inativo, como em um aplicativo bancário onde o serviço de conta falha e sobrecarrega outros serviços, como a autenticação. Isso pode esgotar os recursos, causando falhas generalizadas no sistema. Os disjuntores em microsserviços evitam essas falhas em cascata, interrompendo rapidamente as operações para proteger o sistema. Também implementamos um disjuntor em algumas de nossas APIs HTTP não críticas. Quando um servidor detecta que está próximo da exaustão, ele rejeita automaticamente solicitações não críticas. 

Não coloque todos os ovos na mesma cesta

Os microsserviços podem melhorar a resiliência geral do aplicativo. Se um microsserviço falhar, isso não necessariamente derrubará todo o aplicativo. Esta contenção de falhas é uma vantagem significativa em relação às arquiteturas monolíticas, onde uma única falha pode impactar todo o sistema.

Qual é o próximo?

Essas grandes mudanças não aconteceram da noite para o dia. Tivemos que fazê-los lentamente, pois afetam o núcleo da nossa plataforma. Continuaremos a equilibrar a busca por recursos inovadores com a necessidade de uma plataforma robusta e confiável. Isso significa que persistiremos na introdução de recursos de ponta, garantindo ao mesmo tempo que a plataforma principal permaneça sólida e confiável.