Argumentar que o site sempre deve estar acessível é de má educação e banalidade, mas a acessibilidade de 100%, embora seja um pré-requisito, é na maioria das vezes ainda um ideal inacessível. Agora, existem muitas soluções no mercado que prometem o máximo tempo de atividade ou oferecem soluções para aumentá-lo, mas sua aplicação nem sempre é útil, em alguns casos, pode até levar a riscos aumentados e acessibilidade reduzida ao projeto. Neste artigo, abordaremos os erros clássicos que encontramos constantemente. A maioria dos problemas é elementar, mas as pessoas os permitem repetidamente.
Prefácio necessário: antes de tentar garantir o tempo de atividade máximo do projeto, você deve correlacionar os custos e o custo do tempo de inatividade. Geralmente, isso é muito importante para empresas cujo trabalho depende do trabalho de outras empresas - soluções B2B, serviços de API, serviços de entrega. A inacessibilidade por alguns minutos levará, pelo menos à carga no call center de clientes insatisfeitos. Para empresas de outro tipo, por exemplo, uma pequena loja on-line ou uma empresa cujos clientes trabalham de 9 a 18 anos, a inacessibilidade mesmo por várias horas pode ser mais barata que um site de backup completo.
1. Localização de todo o projeto em um data center / uma zona de hospedagem na nuvem
O marketing de hospedagem na nuvem fixou firmemente o conceito errado na cabeça das pessoas: a hospedagem na nuvem não está ligada ao hardware e isso significa que a infraestrutura da nuvem não cairá. Três falhas de 24 horas no Amazon Web Services, a recente falha no cloud4y e a perda de dados do cloudmouse mostraram que a localização dos dados e do projeto em um data center é uma maneira garantida de obter muitas horas de inatividade, sem a capacidade de elevar o projeto facilmente para outro site. A lei sobre dados pessoais, nesse sentido, cria problemas adicionais. Acreditamos que qualquer hospedagem na nuvem deve passar por vários acidentes graves para aprender como evitá-los (relâmpagos que atingem a Amazon, problemas de configuração de rede relacionados ao fator humano etc.) e se a hospedagem na nuvem ocidental passar por essa série de desastres, muitos sites russos ainda precisam fazer isso, e isso deve ser levado em consideração.
A situação é aproximadamente a mesma com os data centers "de ferro". Frequentemente, vemos a configuração do cliente, onde vários servidores estão reservados em um site, caso um deles falhe; no entanto, em nossa experiência, há problemas de rede quando vários racks em um datacenter ou em todo o datacenter inteiro se tornam inacessíveis acontecem com muito mais frequência do que falhas em um único servidor, e isso também precisa ser levado em consideração.
O fluxo de trabalho recomendado do projeto da AWS envolve o uso de várias zonas de disponibilidade padrão para obter o tempo máximo de atividade do projeto.
2. Falta de duplicação adequada no local da reserva
Assim, chegamos à conclusão banal sobre a necessidade de ter um site de backup para obter o tempo de atividade máximo do projeto; no entanto, para mudar para ele, os dados devem ser adequados ao site de produção. O importante aqui não é a criação inicial da reserva - este é um procedimento bastante simples e compreensível; a sincronização e o monitoramento da sincronização de outras alterações são muito mais importantes. Primeiro de tudo, estamos falando sobre:
- Configuração de cluster / sincronização de dados no cluster quando falamos sobre um site complexo
- Sincronização da estrutura de arquivos e monitoramento do atraso na sincronização
- Rastrear alterações na configuração do servidor
- Depuração de processos de monitoramento e adição à sincronização de novos projetos / serviços no site.
- Acompanhamento da adição de novos serviços secundários (novas filas, mecanismos de processamento e interações etc.).
- Monitoramento contínuo adequado de todos esses processos.
3. Falta de um plano de comutação e alternância regular para um site de backup
Qualquer um, mesmo o melhor monitoramento, não pode garantir que o site de backup esteja pronto para alternar quando for realmente necessário. De acordo com nossa experiência, um acidente ocorrerá na primeira troca para a reserva, e isso acontecerá várias vezes. Em seus relatórios, o Stack Overflow diz que eles levaram cerca de cinco trocas para a reserva, antes de se convencerem de que agora estava completamente pronto para aceitar o tráfego após o acidente. Portanto, no plano de trabalho para aumentar o tempo de atividade do projeto, é necessário incluir chaves de teste na reserva e levar em conta que essas chaves levarão a um acidente. Depois de elaborar e corrigir o mecanismo de comutação na documentação, você precisa continuar alternando regularmente para a reserva para garantir que tudo ainda esteja funcionando.
4. Localização do site de reserva no mesmo canal / na mesma região da nuvem
Se os sites de produção e reserva estiverem na mesma empresa de hospedagem, é bem possível que, em caso de acidente, os dois sites parem de funcionar imediatamente. Vários acidentes graves na AWS afetaram imediatamente todas as zonas de disponibilidade de uma região; o Selectel caiu ao mesmo tempo em que os data centers em São Petersburgo e Moscou, as empresas podem falar sobre isolamento completo, mas o acidente na nuvem, que levou à inacessibilidade total do Bitrix24, sugere que mesmo nesses casos existem grandes riscos. O ideal, do nosso ponto de vista, é uma configuração em que uma configuração de backup está localizada na mesma empresa de hospedagem (para usar meios regulares de mudança para uma reserva, como VRRP ) e uma plataforma de backup secundária em outra empresa de hospedagem.
5. Colocação de versões idênticas nos sites principal e de reserva.
Mesmo o uso de um site de reserva verificado e o uso de um site secundário em outro data center não garantem a disponibilidade da reserva para assumir rapidamente a carga de produção. Isso se deve à essência da redundância: uma nova versão do código que criou uma carga fatal no ambiente de produção criará exatamente a mesma carga no site de backup e o projeto ficará completamente inacessível. Como uma solução simples, deve haver um mecanismo para reverter para a versão anterior; no entanto, na corrida de negócios para lançamentos, isso nem sempre é possível, e então começamos a pensar em outro site de backup com a versão anterior. Também devemos falar sobre backups : a exclusão acidental de dados no site principal também afetará o site de backup; portanto, você deve pensar em uma replicação atrasada (por 15 minutos, por hora) para poder alternar para um banco de dados que ainda não ocorreu. operação fatal.
6. Dependência de serviços externos que o projeto está acessando.
Mas isso não é suficiente. Um grande número de projetos agora usa serviços externos para fornecer seus próprios serviços. A maioria das pessoas usa o SMS para autenticação dupla, as lojas online calculam os prazos de entrega usando serviços de entrega, o pagamento é aceito por meio de gateways de pagamento de terceiros e, se esses serviços falharem, não importa se há uma reserva ou não, o projeto ainda estará indisponível. Raramente vemos reservas de serviços externos, mas, enquanto isso, esses são exatamente os mesmos projetos que podem ter problemas com o site de reserva ou pode não haver reserva. E se o serviço externo estiver indisponível, a manutenção de seus clientes também será impossível. Recomendamos que você duplique todos os sistemas externos críticos, monitore sua disponibilidade e planeje trocá-los em caso de acidente.
Isso está longe de tudo, mas pelo menos as coisas básicas. Discutimos isso com mais detalhes nas reuniões da comunidade uptime.com , a próxima será em outubro, mas por enquanto você pode conversar no grupo de telegrama .