Como o comércio eletrônico sobrevive às promoções em larga escala. Preparando-se para picos de carga na web [Parte 2]

Olá Habr!
Há uma semana, houve um artigo no qual iniciei uma conversa sobre como preparar um projeto de comércio eletrônico para o crescimento explosivo do tráfego e outras delícias de promoções em larga escala.
Descobrimos os principais detalhes técnicos, agora prestaremos atenção às questões administrativas e otimizaremos os processos de suporte durante picos de carga:

• o que torna o site instável e por que a nuvem não é uma panacéia;
  
• quais parâmetros de negócios precisam ser monitorados para detectar um problema antes que ele traga perdas significativas;
  
• como rotear incidentes de evento para solução sem caos e localizar a falha.
  

E muito mais - peço a todos que cortem!

Na minha experiência, a maior dor de cabeça na preparação para ações em larga escala é uma forte pressão administrativa. O negócio, que até então era muito calmo, de repente tem um desejo de que todos estejam no riacho, remova poeira do local e assim por diante: "Deus proíba o que acontece, seremos multados". Vamos tentar satisfazer esse desejo geralmente sólido. Falaremos sobre isso no exemplo da Black Friday, pois esse é o exemplo mais impressionante de um aumento acentuado na carga no site.
E começaremos com a pergunta fundamental: qual é exatamente a causa da operação instável do nosso site?

O que torna um site instável

Chegou a hora de fazer o que você está adiando há muito tempo. Para entender quais fatores tornam um site menos estável, aumente e analise o histórico de problemas. Só não diga que você não tem.

Sua parte superior terá mais ou menos os seguintes motivos:

1. Liberar falhas relacionadas.
   
2. Os administradores erraram - consertou um, mas outro quebrou. Infelizmente, essas sobreposições geralmente são ocultas e não fazem história.
   
3. Estragou o negócio - lançou a ação tortamente, excluiu algo, etc.
   
4. Serviços afiliados quebrados.
   
5. Software "triste". Na maioria das vezes isso acontece devido a parágrafos. 1 e 2.
   
6. Dano físico.
   
7. Outros problemas
   

Obviamente, todas as situações são diferentes, e sua "classificação" pode ser um pouco diferente. Mas os problemas associados às mudanças no site e ao fator humano, bem como os frutos de seu amor conjunto - lançamentos ou tentativas de otimizar algo - ainda vão levar.

Erradicar esses problemas para que, na primeira tentativa de fazer as alterações necessárias e não quebrar o que funciona bem, seja uma tarefa sobre a qual muitas cópias foram quebradas. E temos muito pouco tempo, apenas quatro meses. Felizmente, isso pode ser tratado localmente. Para fazer isso, siga algumas regras simples:

1. Funciona - não toque.

Conclua todo o trabalho planejado o mais cedo possível - em algumas semanas, em um mês. A data de início das melhorias contará o histórico de incidentes. Mostra quanto tempo dura a cauda principal dos problemas. Depois disso, não toque no site e na infraestrutura do produto até que a carga tenha passado.

2. Se você ainda precisou entrar no produtivo para reparos urgentes - teste.

Regularmente, incansavelmente, até as mudanças menores e menores. Primeiro, em um ambiente de teste, inclusive sob carga, e somente depois transfira-o para o prod. E, novamente, teste e verifique novamente os principais parâmetros do site. É melhor executar o trabalho à noite, quando a carga é mínima, porque você deve ter tempo para salvar a situação, se algo der errado. Um bom teste é uma ciência, mas mesmo apenas um teste inteligente é melhor do que não tê-lo. O principal é não confiar no "talvez".

Congelar alterações durante uma carga alta é a única ferramenta confiável.

O que fazer com os serviços afiliados, já discutimos em um artigo anterior. Em resumo - desconecte sem piedade de qualquer problema. Na maioria das vezes, muitos usuários do serviço têm problemas imediatamente e entrar em contato com o suporte técnico é uma medida pouco eficaz. Suas cartas não os ajudarão a consertar mais rapidamente, em tais horas o departamento de TI do serviço estará quente sem elas.

No entanto, se você não reportar o problema e não receber o número do incidente com o tempo em que foi iniciado, provavelmente não poderá cobrar ao serviço uma penalidade por violar o SLA.

Um pouco sobre confiabilidade

Como parte da preparação, você precisa alterar todos os serviços de cluster e hardware com falha. Mais sobre isso em um dos meus artigos anteriores.

Gostaria de chamar sua atenção para o seguinte equívoco popular: parece que a transferência de um site de seus servidores para a nuvem fornece imediatamente +100 confiabilidade. Infelizmente, apenas +20.

Para aumentar a tolerância a falhas de um servidor virtual, a nuvem comercial simplesmente automatiza e acelera a "substituição" de hardware em queda em segundos, aumentando automaticamente a máquina virtual em um dos servidores ativos. Palavras-chave - “acelera” e “ferro caído”. A máquina virtual ainda será reiniciada. A tolerância a falhas do VMware e os análogos que permitem escapar de uma reinicialização geralmente não são usados ​​na virtualização comercial devido ao consumo de recursos e ao desempenho reduzido das máquinas virtuais protegidas. Daí a conclusão: uma nuvem comercial não é uma panacéia para tolerância a falhas, suas principais vantagens são flexibilidade e escalabilidade.

Veja o histórico de quantas interrupções você teve para substituir ou reparar equipamentos físicos. Depois de mudarem para a nuvem, o número deles diminuirá e - sim, a vida se tornará um pouco mais fácil para você. Você não precisa correr para um armazém ou loja para um novo servidor. Mas agora as piadas de virtualização serão adicionadas às falhas de ferro.

Pode acontecer que a máquina fique indisponível, mas o host físico ainda está respondendo. A nuvem não verá esse problema. Ou exatamente o oposto: o host não está respondendo, mas está tudo bem com as máquinas virtuais. Nesse caso, a virtualização os elevará para outro lugar. Levará algum tempo para começar e, novamente, você ficará ocioso do nada. E sob carga, pode ser fatal. Portanto, mesmo na nuvem, você precisa se lembrar sobre redundância. A propósito, alertar o provedor de virtualização sobre quais máquinas fazem backup um do outro é uma ótima idéia. Caso contrário, pode acontecer que todos os seus carros acabem no mesmo servidor físico e morram ao mesmo tempo.

• Ao realizar testes de carga, faz sentido planejar testes de tolerância a falhas sob carga.
  

É quando, exatamente durante o teste de carga, você solta o nó no cluster e vê o que acontece. Com clusters configurados corretamente e recursos alocados corretamente, isso não deve afetar adversamente os resultados do teste e causar vários erros.

Parece que terminamos todos os "tambores" típicos. Antes de ler mais, recomendo que você atualize os detalhes técnicos descritos no artigo anterior . Afinal, se o site for tecnicamente incapaz de suportar a carga, a velocidade da reação não o salvará.

Agora vamos pensar em como se preparar para o incomum ou repentino. Não podemos evitá-los por definição, por isso resta arregaçar as mangas e aprender a repará-las o mais rápido possível.

Etapas para resolver um incidente

Considere o que constitui o tempo para eliminar o acidente:

1. Velocidade de detecção de falhas - atraso no monitoramento, recebimento de uma mensagem do usuário etc.
   
2. Tempo de resposta ao incidente detectado - alguém deve observar o relatório e lidar com ele.
   
3. Hora de confirmar a presença do incidente - havia um menino?
   
4. Hora de analisar o incidente e encontrar soluções.
   
5. Hora de resolver o incidente e os problemas. Nem sempre é possível corrigir tudo da primeira vez, e esse estágio pode ter várias iterações.
   

Geralmente, um serviço de suporte é responsável pela solução de problemas. Se a equipe for grande, cada uma dessas etapas poderá ser executada por pessoas diferentes. E tempo, como você sabe, é dinheiro. No nosso caso, literalmente. A Black Friday tem duração fixa e os concorrentes estão em alerta - os clientes podem gastar tudo com eles. Portanto, é fundamental que cada funcionário conheça sua área de responsabilidade e que os incidentes sejam resolvidos pelo transportador.

Vamos analisar cada estágio separadamente, identificar pontos problemáticos e considerar maneiras de otimizá-los rapidamente.

Todas as dicas, sugestões e recomendações abaixo não são uma receita para uma "vida bonita", mas coisas específicas que você poderá implementar nos próximos 3-4 meses restantes até a Black Friday.

Detectar acidente

No cenário mais malsucedido, o cliente informa sobre os problemas. Ou seja, o problema é tão sério que ele passou o tempo reportando . Nesse caso, apenas um cliente muito dedicado gravará ou telefonará e um usuário simples sairá com um encolher de ombros.

Além disso, muitas vezes o cliente não tem acesso direto ao departamento de TI. Portanto, ele escreve para info@business.ru ou liga para garotas de um call center. Quando as informações chegam à TI, passa muito tempo.

Suponha que temos muitos clientes fiéis e que cada um deles considera seu dever escrever sobre problemas no TP. Enquanto o incidente é classificado como massivo, enquanto aumenta e decide, as horas passam. Ao mesmo tempo, chamadas individuais podem ser perdidas e o e-mail info@business.ru às vezes não é rastreado por semanas.

Portanto, será muito útil iniciar um monitoramento independente dos principais parâmetros de negócios. Pelo menos - o número de usuários no site, o número de compras feitas e sua proporção. Esses dados permitirão que você responda rapidamente se algo der errado e reduza significativamente o tempo para identificar (e resolver) um problema específico no site.

Nenhum usuário? Precisamos ver para onde eles poderiam ir. Existem usuários no site, mas não há vendas? Este é um sinal do problema, e bastante tarde. O teste automatizado de cenários o ajudará a descobrir que algo aconteceu em algum lugar . Normalmente, os testes automáticos são executados em versões ou compilações, mas são ótimos para o monitoramento. Com a ajuda deles, você pode ver a avaria ou a desaceleração de alguns processos comerciais importantes através dos olhos do usuário.

Obviamente, se você não tiver testes de cenário, pelos poucos meses restantes até a Black Friday, não cobrirá todos os testes produtivos. Sim, e eles podem dar uma carga séria. Mas com os testes de uma dúzia de processos básicos, é bem possível chegar a tempo.

Também é muito útil rastrear o tempo médio de resposta do servidor. Se crescer, você pode esperar problemas de vendas. Esses dados devem ser monitorados automaticamente pelo sistema de monitoramento.

Como você pode ver, com o monitoramento competente, você pode reduzir o tempo necessário para detectar um problema de horas e dias para alguns minutos e , às vezes, ver o problema antes que ele atinja sua altura máxima.

Tempo de resposta a incidentes

Fizemos um ótimo trabalho e, graças ao monitoramento, detectamos uma falha instantaneamente. Agora você precisa iniciar o incidente, atribuir prioridade, encaminhar e designar a pessoa responsável pelo processamento adicional.

Duas coisas são importantes aqui:

• Receba a notificação de um problema o mais rápido possível;
  
• Esteja preparado para processar a notificação imediatamente.
  

Muitos especialistas em TI não estão acostumados a responder rapidamente às cartas, mesmo que tenham um cliente em seu smartphone. Notificações importantes não devem ser enviadas por email.

Use o SMS para alertas de acidentes. Melhor ainda, implemente um discador de bot para os casos mais críticos. Pessoalmente, não vi implementações práticas desses robôs, mas se os recursos permitirem, por que não? Como último recurso, use o WhatsApp / Viber / Jabber. Infelizmente, o telegrama no território da Federação Russa, por muitas razões compreensíveis, não pode ser um canal confiável para notificações de emergência.

Também pode ser útil escalar automaticamente um incidente se não houver confirmação. Ou seja, o monitoramento notificará o próximo da fila se o destinatário principal da notificação não responder. Este sistema garantirá se quando algo (ou alguém) der errado.

Agora vamos falar sobre como fornecer uma resposta rápida às mensagens de falha. Primeiro, alguém deve estar preparado para ser responsável pelo tratamento de alertas. Alertas para toda a equipe são úteis, mas apenas para manter as pessoas atualizadas.

A responsabilidade coletiva é uma coisa não confiável quando a velocidade é necessária.

Se você não definir um relógio com um cronograma claro para a duração da ação, poderá encontrar que, durante uma força maior, alguém dormirá e alguém não terá acesso em casa. Alguém estará na estrada. E, de fato, não há ninguém para resolver o problema na próxima hora. Claro, você pode colocar um oficial de serviço operacional 24 horas por dia, mas há uma nuance aqui. Você não forçará bons especialistas a trabalhar constantemente em turnos, o que significa que, quando precisar deles, você ainda precisará procurá-los e acordá-los. E aqueles que ainda trabalham em turnos, saem do contexto geral da vida da equipe. Isso tem o efeito mais fatal em sua eficácia para as tarefas planejadas.

O que nos salvará é que, na maioria dos projetos, precisamos responder rapidamente às mensagens, entender o que aconteceu e precisar ser reparado com urgência cerca de 18 horas por dia. Normalmente, das 6 às 8 da manhã às 2 da manhã do dia seguinte, até 90% do tráfego e das vendas.

Para evitar sobreposições, basta mudar o horário de trabalho dos plantonistas para formatos como:

• 6: 00-15: 00 e 17: 00-02: 00 - dever "de casa";
  
• 15: 00-17: 00 - cubra os que estão no escritório;
  
• 02: 00-06: 00 - pouco tráfego. No entanto, nomeie uma pessoa que não esteja profundamente sonolenta.
  

Não se esqueça do fim de semana. Este problema pode ser resolvido da mesma maneira.

Se sua atividade diária do usuário for distribuída de maneira diferente, escolha uma programação semelhante na qual o site no horário nobre não será autônomo.

Estar em serviço significa ser responsável pelo processamento de eventos de monitoramento, chamadas de linhas anteriores (suporte ao cliente) e monitorar o sistema como um todo. Mas enquanto tudo está quieto, o oficial de serviço está envolvido em seu trabalho principal.

Certifique-se de começar a trabalhar alguns dias antes do início da carga. Em primeiro lugar, isso garantirá mais uma vez que todos tenham todos os acessos. Em segundo lugar, uma mudança no modo operacional é estresse, muitos precisarão "se acalmar". E seria melhor se o período de dependência não coincidisse com o calor principal.

Ótimo, alertas vêm, e é para aquelas pessoas que devem responder a eles. Mas o tempo de resposta das pessoas em serviço é grandemente influenciado pela presença de alertas desnecessários e não processados, além de notificações, que em princípio não envolvem nenhuma ação. É muito importante não deixar alertas não processados. Se muitos eventos semelhantes ocorrem regularmente, investigue a causa e repare-a. Não deve haver alarmes ativos no sistema de monitoramento.

Por experiência, se algo não puder ser reparado rapidamente ou se não precisar de reparo, mas ainda "piscar", é melhor suprimir a notificação e criar uma tarefa para o desenvolvimento. Um alarme constantemente piscando, mais cedo ou mais tarde, se torna familiar e deixa de atrair atenção. O problema é que, quando surge um problema real, as pessoas podem confundir a lâmpada e ignorar um evento realmente importante.

A configuração e priorização adequadas de eventos no sistema de monitoramento ainda são extremamente importantes. O sistema deve notificá-lo exatamente o que precisa ser corrigido. Sobre falhas específicas ou o risco de sua ocorrência. Você não reparará 100% de uso da CPU? Você eliminará altas latências no servidor WEB, porque o uso da CPU é uma informação para depuração, não um problema. Se, na Black Friday, o processador for carregado a 100% na carga desejada, na velocidade de resposta e levando em consideração os estoques - isso significa que você calculou tudo corretamente.

A utilização dos recursos do sistema deve ser controlada, mas essa é uma tarefa ligeiramente diferente, importante para o planejamento de recursos e a identificação de áreas de impacto do acidente.

Montamos os eventos, agora é importante priorizar corretamente o que corrigiremos em primeiro lugar. Para fazer isso, descobriremos quais são as diferenças entre os níveis de alertas críticos e de aviso. Deixe-me dar alguns exemplos exagerados, mas compreensíveis.

Crítico - é quando você vai para a avó no metrô, recebe um alerta e vai para a estação mais próxima. Você pega um laptop, senta em um pequeno banco e começa a trabalhar - houve uma interrupção nas vendas ou surgiram grandes perdas. Ou seja, Crítico é algo que tem um impacto direto, embora significativo, nos usuários.

Aviso - é quando você não sai do trabalho até repará-lo. Jogar tudo e correr para ajudar por uma questão de aviso não é necessário. Você pode terminar / terminar e tomar uma decisão. Por exemplo, havia um risco claro de problemas críticos, como queda de um servidor de um par de HA, erros caíam nos logs e similares. Se você não martelar e reparar conscientemente esses eventos (além de investigar as causas e realizar trabalhos para evitá-las), haverá muito poucas delas.

Outra coisa que é frequentemente esquecida. Não jogue em serviço apenas administradores. Certifique-se de atrair desenvolvedores, formando pares de trabalho para cada turno. Isso será útil para nós nas próximas etapas.

Se o projeto é funcionalmente complexo, faz sentido enviar consultores, analistas, testadores e todos os outros que possam ser úteis em serviço. Garanta sua disponibilidade pelo menos por chamada. O especialista precisará confirmar o problema (ou vice-versa) e ajudar na localização funcional - quando você precisar criar uma pessoa para reparo, isso economizará seu tempo. Discutirei esse assunto com mais detalhes na próxima seção.

E o último ponto importante. Cada oficial de serviço deve conhecer completamente os contatos e as áreas de responsabilidade de todos os seus colegas em situações de emergência. Se ele não conseguir resolver o problema sozinho e em pânico começar a procurar equipes de resgate disponíveis, o caos virá, por causa do qual você perderá muito tempo.

O cumprimento dessas regras simples ajudará a evitar problemas devido a notificações e garantias perdidas: quando a emergência chegar (leia “Black Friday” e “incidente de emergência”), as pessoas poderão resolver os problemas imediatamente.

Confirmar incidente

O próximo passo após receber uma notificação é entender o que exatamente deu errado e se há um problema em princípio: determinar imediatamente quem está certo, o usuário ou o sistema nem sempre é fácil. O fato é que o mesmo alerta pode ser interpretado de maneira diferente, dependendo do ângulo de visão.

, , ( ), . , . , . , , «» , .

, . , ! - , «».

- . «» . , , .

— , , . , . , , . — - « », « » « , ».

, , , , «». , , . — , , , . : , , .

, . , . . , , . — , : .

. -, , , – , , , , ( , ) .



. .

. , .

, . , , :

• ;
  
• ;
  
• ;
  
• ;
  
• (, ..).
  

, , , . -. , ELK .

, , .

- , , , .

, — . , , . , . , .

- , . , , , — .

: , , , . , 3 :

1. ;
   
2. ;
   
3. .
   

. ( ). , , -, , - .

. . , , , . , , — .

. , - - , , , - . . . , , , .

, , . , . , , « » .

– SLA. SLA – , , . SLA , . , - . , .

— , . , , . .

Até agora, é tudo o que gostaria de dizer sobre esse tópico. Ficarei feliz se meu conselho, sendo transferido para a realidade do seu negócio, me permitir sobreviver à carga pesada com calma e conforto.

Se você quiser conselhos sobre como agir em sua situação, convido você para o meu seminário Black Friday. Segredos de sobrevivência. No formato de perguntas e respostas, falaremos sobre a preparação do site para o crescimento do tráfego e discutiremos os detalhes técnicos e organizacionais desse processo.

O seminário será realizado em 16 de agosto em Moscou. Como o evento será bastante câmara (máximo de 25 pessoas), é necessário marcar uma consulta. E eu estou esperando o resto para discussão nos comentários. :)