No verão, tanto a atividade de compra quanto a intensidade das mudanças na infraestrutura dos projetos da web diminuem tradicionalmente, diz o Capitão Evidence. Só porque mesmo as pessoas de TI saem de férias. E CTO também. É ainda mais difícil para os que permanecem no posto, mas não sobre isso agora: talvez seja por isso que o verão seja o melhor momento para se apressar no esquema de reservas existente e planejar um aprimoramento. E nisso você se beneficiará da experiência de Yegor Andreev da AdminDivision , sobre a qual ele falou na conferência do dia da atividade .Durante a construção dos locais de reserva, durante a reserva, existem várias armadilhas nas quais você pode cair. E cair neles é absolutamente impossível. E nos arruinando em tudo isso, assim como em muitas outras coisas, perfeccionismo e ... preguiça. Estamos tentando fazer tudo, tudo, tudo é perfeito, mas você não precisa fazer isso perfeitamente! Só é necessário fazer certas coisas, mas fazê-las corretamente, trazê-las ao fim, para que funcionem normalmente.
O failover não é um tipo de coisa divertida de se divertir; é algo que deve fazer exatamente uma coisa - reduzir o tempo de inatividade para que o serviço, empresa, perca menos dinheiro. E em todos os métodos de reserva, sugiro pensar no seguinte contexto: onde está o dinheiro?
A primeira armadilha : quando construímos grandes sistemas confiáveis e fazemos backups, reduzimos o número de acidentes. Esta é uma falácia terrível. Quando fazemos backups, provavelmente aumentamos o número de acidentes. E se fizermos tudo certo, juntos reduziremos o tempo de inatividade. Haverá mais acidentes, mas eles ocorrerão a um custo menor. Afinal, o que é redundância? É uma complicação do sistema. Qualquer complicação é ruim: temos mais engrenagens, mais engrenagens, em uma palavra, mais elementos - e, portanto, uma maior chance de avaria. E eles realmente quebram. E eles vão quebrar com mais frequência. Um exemplo simples: digamos que temos um site com PHP, MySQL. E ele precisa urgentemente de ser reservado.
Shtosh (c) Pegamos o segundo site, construímos um sistema idêntico ... A complexidade se torna duas vezes maior - temos duas entidades. E também rolamos certa lógica de transferência de dados de uma plataforma para outra de cima - ou seja, replicação de dados, estática de cópia e assim por diante. Portanto, a lógica da replicação geralmente é muito complexa e, portanto, a complexidade total do sistema pode não ser 2, mas 3, 5, 10 vezes mais.
A segunda armadilha : quando construímos sistemas complexos realmente grandes, fantasiamos o que queremos obter no final. Voila: queremos obter um sistema super confiável que funcione sem nenhum tempo de inatividade, alterne em meio segundo (ou melhor em geral instantaneamente) e comece a transformar sonhos em realidade. Mas há também uma nuance: quanto menor o tempo de comutação desejado, mais complexa é a lógica do sistema. Quanto mais difícil for fazer essa lógica, mais frequentemente o sistema irá quebrar. E você pode entrar em uma situação muito desagradável: estamos fazendo o possível para reduzir o tempo de inatividade, mas na verdade complicamos as coisas e, quando algo der errado, o tempo de inatividade será mais longo. Aqui, muitas vezes, você se vê pensando: aqui ... seria melhor se eles não tivessem sido reservados. Seria melhor se funcionasse sozinho com um tempo de inatividade compreensível.
Como lidar com isso? Devemos parar de mentir para nós mesmos, parar de nos gabar de que vamos construir uma nave espacial aqui, mas para entender adequadamente o quanto o projeto pode se desenvolver. E, por esse tempo máximo, escolheremos com quais métodos, de fato, aumentaremos a confiabilidade do nosso sistema.
É hora de "histórias de w" ... da vida, é claro.
Exemplo número um
Imagine o cartão do local da usina de laminação de tubos nº 1 da cidade N. Está escrito em grandes letras - PIPELINE PLANT No. 1. Um pouco mais baixo - o slogan: "Nossos tubos são os mais redondos em N". E abaixo do número de telefone do CEO e seu nome. Entendemos que você precisa reservar - isso é uma coisa muito importante! Começamos a entender em que consiste. Html-static - ou seja, algumas fotos em que o general, de fato, à mesa no banho com seu parceiro está discutindo um próximo acordo. Começamos a pensar em tempo de inatividade. Lembra-se: você precisa ficar lá por cinco minutos, não mais. E então a pergunta é: quantas vendas deste site foram em geral? Quanto custa? O que significa zero? E isso significa: porque o general fez todas as quatro transações no ano passado na mesma mesa, com as mesmas pessoas com quem eles vão ao balneário sentam à mesa. E entendemos que, mesmo que o site fique parado por um dia, não haverá nada de terrível.
Com base na introdução, há um dia para levantar essa história. Começamos a pensar no esquema de backup. E nós selecionamos o esquema de backup mais ideal para este exemplo: não usamos redundância. Todo esse problema surge por qualquer administrador por meia hora com intervalos para fumar. Colocar um servidor web, colocar arquivos é tudo. Isso vai funcionar. Você não precisa seguir nada, não precisa prestar atenção especial a nada. Ou seja, a conclusão do exemplo número um é bastante óbvia: serviços que você não precisa reservar não são necessários.
Exemplo número dois
Blog da empresa: os especialmente treinados escrevem notícias por lá, por isso participamos de uma exposição dessas, mas aqui lançamos outro novo produto e assim por diante. Digamos que esse seja o PHP padrão do WordPress, um pequeno banco de dados e um pouco de estática. É claro que me ocorre novamente que você nunca deve mentir - "não mais do que cinco minutos!", Isso é tudo. Mas vamos pensar mais. O que este blog está fazendo? Eles vêm do Yandex, do Google, em alguns pedidos, de orgânicos. Uau. E as vendas estão de alguma forma relacionadas a ele? Introspecção: não realmente. O tráfego de publicidade vai para o site principal, que está em outra máquina. Começamos a pensar no esquema de reserva de folhetos. De uma maneira boa, ele precisa ser levantado em algumas horas e seria bom se preparar para isso. Seria razoável pegar uma máquina em outro data center, direcionar o ambiente para ela, ou seja, um servidor web, PHP, WordPress, MySQL, e deixá-la deitada. No momento em que entendemos que tudo está quebrado, duas coisas precisam ser feitas - role o despejo mysql para 50 metros, ele voará para lá em um minuto e tire algumas fotos do backup lá. Isso também não é uma boa notícia por lá. Assim, em meia hora, tudo isso aumenta. Sem réplicas, ou Deus me perdoe, failover automático. Conclusão: o que podemos implementar rapidamente do backup não é necessário reservar.
Exemplo número três, mais complicado
Loja online. PhP com coração aberto é um pouco arquivado, mysql com uma base sólida. Muita estática (afinal, a loja on-line tem belas imagens em HD e todo esse jazz), Redis para a sessão e Elasticsearch para a pesquisa. Começamos a pensar em tempo de inatividade. E aqui, é claro, é óbvio que uma loja on-line não pode passar o dia sem dor. Afinal, quanto mais tempo estiver, mais dinheiro perdemos. Vale a pena acelerar. Quanto? Acredito que, se nos deitarmos por uma hora, ninguém ficará louco. Sim, vamos perder alguma coisa, mas se começarmos a zelar, isso só piorará. Determinamos o tempo ocioso permitido por hora.
Como tudo isso pode ser reservado? De qualquer forma, é necessário um carro: uma hora é bastante. Mysql: replicação, replicação ao vivo já é necessária aqui, porque em uma hora 100 GB em um despejo, provavelmente, não serão derramados. Estática, imagens: novamente, em uma hora, 500 GB talvez não tenham tempo para mesclar. Portanto, é melhor copiar fotos imediatamente. Redis: mais interessante aqui. As sessões são em Redis - simplesmente não podemos pegá-lo e enterrá-lo. Porque não será muito bom: todos os usuários serão desconectados, cestas vazias e assim por diante. As pessoas serão forçadas a digitar novamente seu nome de usuário e senha, e muitas pessoas poderão se separar e não concluir a compra. Mais uma vez, a conversão cairá. Por outro lado, o Redis é diretamente um a um relevante, com os últimos usuários conectados, provavelmente, também não é necessário. E um bom compromisso é pegar o Redis e restaurá-lo do backup ontem, ou, se você fizer isso a cada hora, - uma hora atrás. O benefício de restaurá-lo do backup é copiar um arquivo. E a história mais interessante é a Elasticsearch. Quem já levantou a replicação do MySQL? Quem já criou a replicação do Elasticsearch? E quem ela trabalhou normalmente depois? O que estou fazendo: vemos uma certa entidade em nosso sistema. Parece ser útil - mas é complicado.
Complexo no sentido de que nossos colegas engenheiros não têm experiência em trabalhar com ele. Ou há uma experiência negativa. Ou entendemos que até agora essa é uma tecnologia relativamente nova, com nuances ou umidade. Nós pensamos ... Porra, elástico também é saudável, também leva muito tempo para restaurá-lo do backup, o que devo fazer? Entendemos que o elástico no nosso caso é usado para pesquisa. E como a nossa loja online vende? Vamos aos profissionais de marketing, perguntamos, de onde as pessoas vêm. Eles respondem: "90% do mercado Yandex vem diretamente para o cartão do produto". E compre ou não. Portanto, 10% dos usuários precisam de uma pesquisa. E para manter elástica a replicação, especialmente entre diferentes datacenters em zonas diferentes, existem muitas nuances. Qual é a saída? Tomamos elástico em um site reservado e não fazemos nada com ele. Se o caso persistir, um dia provavelmente o aumentaremos, mas isso não é certo. Na verdade, a conclusão mais ou menos é a mesma: nós, novamente, não reservamos serviços que não afetam o dinheiro. Para manter o circuito mais simples.
Exemplo número quatro, ainda mais difícil
Integrador: vender flores, chamar um táxi, vender mercadorias, em geral, qualquer coisa. Uma coisa séria que funciona 24/7 para um grande número de usuários. Com uma pilha interessante de pleno direito, onde existem bases, soluções interessantes, uma carga alta e, o mais importante, machuca-o ficar mais de 5 minutos. Não apenas e nem tanto, porque as pessoas não compram, mas porque as pessoas verão que essa coisa não está funcionando, elas ficarão chateadas e poderão não voltar pela segunda vez.
Ok Cinco minutos O que faremos com isso? Nesse caso, estamos de uma maneira adulta, com todo o dinheiro que estamos construindo em um site de backup real, com replicação de tudo e de tudo e talvez até automatizar a troca máxima para este site. Além disso, não se deve esquecer de fazer uma coisa importante: de fato, escreva a programação da troca. Os regulamentos, mesmo que você tenha tudo automatizado, podem ser muito simples. Na série “execute tal e tal script ansível”, “clique em tal e assim naw na rota 53” e assim por diante - mas essa deve ser uma lista exata de ações.
E tudo parece estar claro. A troca de replicação é uma tarefa trivial ou será alterada automaticamente. Reescreva um nome de domínio em DNS - da mesma série. O problema é que, quando um projeto semelhante falha, o pânico começa e até os administradores mais poderosos e barbudos podem ser propensos a ele. Sem uma instrução clara "abra um terminal, vá aqui, o endereço em nosso servidor ainda é assim", o prazo de 5 minutos alocado para reanimação é difícil de sustentar. Além disso, quando usamos esses regulamentos, é fácil corrigir algumas alterações na infraestrutura, por exemplo, e alterá-los de acordo.
Bem, se o sistema de backup é muito complexo e, em algum momento, cometemos um erro, também podemos colocar nosso site de reserva e, além disso, transformar os dados em uma abóbora nos dois sites - será muito triste.
Exemplo número cinco, hardcore completo
Um serviço internacional com centenas de milhões de usuários em todo o mundo. Todos os fusos horários, que existem apenas, carregam alta velocidade máxima, você não deve mentir. Um minuto - e será triste. O que fazer Reserve, novamente, na íntegra. Eles fizeram tudo o que foi mencionado no exemplo anterior e um pouco mais. Um mundo ideal e nossa infraestrutura - é de acordo com todos os conceitos da devopa IaaC. Ou seja, tudo em geral no git, e apenas clique no botão.
O que está faltando? Um são os ensinamentos. Você não pode prescindir deles. Parece que tudo está perfeito conosco, tudo está sob controle em geral. Pressionamos o botão, tudo acontece. Mesmo que seja assim - e entendemos que isso não acontece - nosso sistema interage com outros sistemas. Por exemplo, esses são DNS da rota 53, armazenamento s3, integração com algumas APIs. Não seremos capazes de prever tudo nesse experimento especulativo. E até realmente pressionarmos o interruptor, não saberemos se funcionará ou não.
Provavelmente é tudo. Não seja preguiçoso e não exagere. E que o tempo de atividade esteja com você!