Get best of the week

A história do pássaro Dodo do gênero Phoenix. A Grande Queda de Dodo É

Todos os anos, em 21 de abril, lembramos a história da Grande Queda do Dodo IS em 2018. O passado é um professor cruel, mas justo. Vale lembrar, repetindo as lições, transmitindo o conhecimento acumulado às novas gerações e tratando com gratidão quem nos tornamos. Sob o corte, queremos contar uma história sobre como foi e compartilhar conclusões. Você não pode sequer desejar tal situação ao inimigo.




Grande História do Outono


Dia 1. O acidente que nos custou milhões de rublos


No sábado, 21 de abril de 2018, o sistema Dodo IS caiu. Caiu muito mal. Por várias horas, nossos clientes não puderam fazer um pedido pelo site ou pelo aplicativo móvel. A linha de chamadas para o call center cresceu a tal ponto que a voz automática da secretária eletrônica diz: "Ligaremos em 4 horas".



Naquele dia, experimentamos uma das mais graves quedas do Dodo IS. O pior foi que, no dia anterior, lançamos a primeira campanha publicitária de TV federal com um orçamento de 100 milhões de rublos. Foi um grande evento para Dodo Pizza. A equipe de TI também estava bem preparada para a campanha. Automatizamos e simplificamos a implantação - agora, com a ajuda de um único botão no TeamCity, podemos implantar um monólito em 12 países. Não fizemos todo o possível e, portanto, estragamos tudo.

A campanha publicitária foi incrível. Recebemos de 100 a 150 pedidos por minuto. Essa foi uma boa notícia. A má notícia: o Dodo IS não suportou tal carga e morreu. Atingimos o limite de escala vertical e não conseguimos mais processar pedidos. O sistema ficou instável por cerca de três horas, recuperando-se periodicamente, mas caiu imediatamente novamente. Cada minuto de inatividade nos custa dezenas de milhares de rublos, sem contar a perda de respeito de clientes irritados. A equipe de desenvolvimento decepcionou todo mundo: clientes, parceiros, funcionários de pizzarias e um call center.



Não tivemos escolha senão arregaçar as mangas e sentar para corrigir a situação. Desde domingo (22 de abril), trabalhamos no modo difícil, não temos o direito de cometer um erro.

A seguir, é apresentado nosso resumo da experiência sobre como nos encontrar em uma situação dessas e como sair dela mais tarde. Amigos, não cometer nossos erros.

Duas falhas que lançaram o efeito dominó


Vale a pena começar com como tudo começou e onde estragamos tudo.



No sábado, 21/04/2018, por volta das 17:00, notamos que o número de bloqueios no banco de dados começou a crescer - um indicador de problemas. Tínhamos um runbook pronto para resolver, pois entendíamos de onde vinham esses bloqueios.

Tudo deu errado depois que o runbook falhou duas vezes. Por alguns minutos, a base voltou ao normal e novamente começou a engasgar. Infelizmente, o banco de dados mestre rollback_on_timeout teve 600 segundos, motivo pelo qual todos os bloqueios estavam se acumulando. Este é o primeiro arquivo importante nesta história. Uma configuração simples pode salvar tudo.

Depois, houve tentativas de trazer o sistema de volta à vida de várias maneiras, nenhuma das quais teve sucesso. Até que percebemos que há uma diferença no esquema de recebimento de pedidos no aplicativo móvel e no novo site. Ao reduzi-los, conseguimos entender onde estão os buracos no antigo esquema de tomada de pedidos.

O sistema de aceitação de pedidos foi escrito há muito tempo. Naquele momento, ele já estava sendo processado e foi lançado no novo site dodopizza.ru. Não foi usado no aplicativo móvel. Inicialmente, os motivos para a criação de um novo esquema de pedidos estavam relacionados a regras puramente comerciais; os problemas de desempenho nem estavam na agenda. Este é o segundo arquivo importante - não conhecíamos os limites do nosso sistema.

Dia 2. Eliminação de Acidentes


A resposta da equipe foi muito reveladora. Nossa estação de serviço escreveu um post no Slack e todos vieram no dia seguinte - em 22 de abril, o trabalho começou às 8h30 da manhã. Ninguém precisava ser persuadido ou convidado a sair no dia de folga. Todos entenderam tudo: o que precisa ser suportado, ajudado, com as mãos, com a cabeça, nos testes, otimização de consultas, infraestrutura. Alguns chegaram até com toda a família! Os caras das equipes vizinhas, não relacionados à TI, chegaram ao escritório com comida, e o call center trouxe forças adicionais por precaução. Todas as equipes unidas em um único objetivo - subir!



Uma nova recepção da ordem foi o principal objetivo no domingo, 22 de abril. Entendemos que o pico de pedidos seria comparável ao sábado. Tivemos o prazo mais severo - às 17 horas, uma nova enxurrada de pedidos cairá.

Neste dia, agimos de acordo com o plano "para garantir que não caia", que elaboramos na véspera do dia 21 no final da noite, quando já havíamos levantado o sistema e entendido o que havia acontecido. O plano foi dividido condicionalmente em 2 partes:

  1. Implementação do esquema com um novo pedido no aplicativo móvel.
  2. Otimização do processo de criação de pedidos.

Ao implementar essas coisas, podemos ter certeza de que o Dodo IS não cairá.

Nós determinamos a frente do trabalho e trabalho


A implementação do esquema com um novo pedido em um aplicativo móvel foi a maior prioridade. Não tínhamos números exatos para todo o esquema, mas em algumas partes, o número e a qualidade das consultas ao banco de dados, entendemos habilmente que isso daria um aumento na produtividade. Uma equipe de 15 pessoas trabalhou na tarefa dia após dia.

Embora, de fato, a introdução de um novo esquema de pedidos, começamos antes do outono de 21/04/04, mas não concluímos o negócio. Ainda havia bugs ativos e a tarefa pendia em um estado semi-ativo.

A equipe dividiu a regressão em partes: regressão de duas plataformas móveis, além do gerenciamento de pizzarias. Passamos muito tempo manualmente para preparar pizzarias de teste, mas uma separação clara ajudou a paralelizar a regressão manual.

Assim que algumas mudanças foram introduzidas, elas foram implantadas imediatamente no ambiente de pré-produção e testadas instantaneamente. A equipe estava sempre em contato, eles realmente sentavam em uma sala grande com hangouts. Os caras de Nizhny Novgorod e Syktyvkar também estavam sempre em contato. Se houvesse um plugue, ele imediatamente decidiu.

Normalmente, lançamos novas funcionalidades gradualmente: 1 pizzaria, 5 pizzarias, 10 pizzarias, 20 pizzarias e assim por diante a toda a rede gradualmente. Naquela época, precisávamos agir de forma mais decisiva. Não tivemos tempo - às 17h, um novo pico começou. Nós simplesmente não conseguimos deixar de pegá-lo.

Por volta das 15:00, a atualização foi lançada para metade da rede (são cerca de 200 pizzarias). Às 15:30, garantimos que tudo estava funcionando bem e ativamos toda a rede. Os recursos de alternância, implantações rápidas, regressão dividida em partes e API fixa ajudaram a fazer tudo isso.

O restante da equipe lidou com diferentes opções de otimização ao criar um pedido. O novo esquema não era inteiramente novo, ainda usava a parte legada. Salvar endereços, aplicar códigos promocionais, gerar números de pedidos - essas peças foram e permaneceram comuns. Sua otimização foi reduzida para reescrever as consultas SQL, ou para se livrar delas no código, ou para otimizar suas chamadas. Algo ocorreu no modo assíncrono, algo, como se viu, foi chamado várias vezes em vez de uma.

A equipe de infraestrutura estava comprometida em alocar parte dos componentes para separar instâncias simplesmente para não atravessar a carga. Nosso principal componente de problema foi a fachada do Legacy, que foi para a base do Legacy. Todo o trabalho foi dedicado a ele, incluindo a divisão de instâncias.

Organize o processo


De manhã, tivemos a única sincronização do dia, dividimos as equipes e saímos para trabalhar.

No início, mantivemos todo o log de alterações e tarefas diretamente no Slack, porque no início não havia muitas tarefas. Mas o número deles estava crescendo, então mudamos rapidamente para o Trello. A integração configurada entre Slack e Trello notificou qualquer alteração de status no quebra-cabeça.

Além disso, era importante para nós ver todo o registro de alterações na produção. A versão eletrônica estava no Trello, a versão de backup estava na placa de infraestrutura na forma de cartões. Caso algo desse errado, precisávamos descobrir rapidamente quais mudanças reverteriam. A regressão completa foi apenas para o esquema com uma nova ordem; o restante das alterações foi testado com mais lealdade.

As tarefas voavam para a produção na velocidade de bala. No total, atualizamos o sistema 15 vezes naquele dia. Os caras foram implantados em bancas de teste, uma por equipe. Desenvolvimento, verificação rápida, implantação na produção.

Além do processo principal de CTO, Sasha Andronov constantemente se deparava com equipes com a pergunta "Como ajudar?". Isso ajudou a redistribuir esforços e a não perder tempo com o fato de alguém não ter pensado em pedir ajuda. Gerenciamento de desenvolvimento semi-manual, um mínimo de distrações e trabalho até o limite.

Depois daquele dia, foi necessário sair com a sensação de que fizemos tudo o que podíamos. E ainda mais. E nós conseguimos! Às 15:30, um novo esquema para receber um pedido foi implementado para um aplicativo móvel em toda a rede. Modo Hackathon, menos de 20 implantações por produção por dia!

A noite de 22 de abril foi calma e clara. Nem cai, nem uma única dica é que o sistema possa estar com defeito.

Por volta das 22h, nos reunimos novamente e delineamos um plano de ação semanal. Limitação, testes de desempenho, ordem assíncrona e muito mais. Foi um longo dia, e havia longas semanas pela frente.

Renascimento


A semana de 23 de abril foi infernal. Depois disso, dissemos a nós mesmos que tínhamos feito o nosso melhor 200% e feito tudo o que podíamos.

Tivemos que salvar o Dodo IS e decidimos aplicar alguma analogia médica. Em geral, este é o primeiro caso real de usar uma metáfora (como no XP original), o que realmente ajudou a entender o que estava acontecendo:

  • Reanimação - quando você precisa salvar um paciente que está morrendo.
  • Tratamento - quando há sintomas, mas o paciente ainda está vivo.




Reanimação


O primeiro estágio da ressuscitação é o runbook padrão para restaurar o sistema em caso de falha, de acordo com alguns parâmetros. Uma coisa caiu - nós estamos fazendo isso, que uma caiu - nós estamos fazendo isso e assim por diante. No caso de uma falha, encontramos rapidamente o runbook desejado, todos eles estão no GitHub e são estruturados por problemas.

O segundo estágio da ressuscitação é a limitação das ordens. Adotamos essa prática em nossas próprias pizzarias. Quando muitos pedidos são descartados na pizzaria e eles entendem que não podem cozinhá-los rapidamente, eles ficam parados por 5 minutos. Apenas para limpar a linha do pedido. Criamos um esquema semelhante para o Dodo IS. Decidimos que, se ficar muito ruim, ativaremos o limite geral e informaremos aos clientes, por exemplo, pessoal, 5 minutos e faremos seu pedido. Desenvolvemos essa medida apenas por precaução, mas, como resultado, nunca a usamos. Nao é útil. E agradável.

Tratamento


Para iniciar o tratamento, é necessário fazer um diagnóstico, por isso nos concentramos em testes de desempenho. Parte da equipe foi coletar um perfil de carga real da produção usando o GoReplay, parte da equipe focada em testes sintéticos no palco.

Os testes sintéticos não refletiram o perfil de carga real, mas deram margem para melhorias, mostraram algumas fraquezas no sistema. Por exemplo, pouco antes disso, estávamos movendo o conector do MySQL da Oracle para um novo . Na versão do conector, houve um erro nas sessões de pool, o que levou ao fato de que os servidores simplesmente subiram ao limite da CPU e pararam de atender às solicitações. Reproduzimos isso com testes de estágio, concebidos e silenciosamente entramos em produção. Havia uma dúzia desses casos.

Ao diagnosticar e identificar as causas dos problemas, eles são corrigidos no sentido horário. Compreendemos ainda que nosso caminho ideal é a recepção assíncrona de um pedido. Começamos a trabalhar na introdução em um aplicativo móvel.

Inferno semanas: organização do processo


Uma equipe de 40 pessoas trabalhou em um único grande objetivo - a estabilização do sistema. Todas as equipes trabalharam juntas. Não sabe o que fazer? Ajude outras equipes. O foco em objetivos específicos ajudou a não ser borrifado e a não se envolver em bobagens desnecessárias para nós.



Três vezes por dia havia sincronização, uma posição comum, como em um scrum clássico. Para 40 pessoas. Somente duas vezes em três semanas (por quase 90 sincronizações) não encontramos 30 minutos. A sincronização mais longa durou 57 minutos. Embora geralmente levassem 20 a 30 minutos.

O objetivo das sincronizações: entender onde a ajuda é necessária e quando levaremos essas ou essas tarefas à produção. Os caras unidos nas equipes de projeto, se precisavam da ajuda de infraestrutura, uma pessoa veio ali, todos os problemas foram resolvidos rapidamente, menos discussão era mais um problema.

À noite, para apoiar os caras, nosso laboratório de P&D preparava comida para os desenvolvedores à noite. Receitas de pizza loucas, asas de frango, batatas! Isso foi irreal, legal! Esse apoio motivou os caras o máximo possível.



Trabalhar nesse modo ininterrupto foi muito difícil. Na quarta-feira, 25 de abril, por volta das 17 horas, Oleg Blokhin, um de nossos desenvolvedores, abordou o CTO, que esteve no sábado sem parar. Havia fadiga desumana em seus olhos: "Fui para casa, não aguento mais". Ele dormiu bem e no dia seguinte foi caloroso. Então você pode descrever a condição geral de muitos caras.

No sábado seguinte, 28 de abril (era um sábado útil para todos na Rússia), estava mais calmo. Não podíamos mudar nada, vimos o sistema, os caras descansaram um pouco do ritmo. Tudo correu silenciosamente. A carga não era tão grande, mas era. Eles sobreviveram sem problemas, e isso deu confiança de que estávamos seguindo o caminho certo.

A segunda e terceira semanas após a queda já estavam em um modo mais calmo, o ritmo infernal até o final da noite se foi, mas o processo geral da lei marcial permaneceu.

Dia seguinte X: Teste de força


No dia seguinte, X foi no dia 9 de maio! Alguém estava sentado em casa e monitorando o status do sistema. Aqueles de nós que foram passear levaram laptops para estarem totalmente armados se algo desse errado. Sasha Andronov, nossa estação de serviço, aproximou-se do pico da noite de uma das pizzarias para ver tudo pessoalmente em caso de problemas.

Naquele dia, recebemos 91500 pedidos na Rússia (na época, o segundo resultado na história do Dodo). Não havia sequer a menor sugestão de problema. 9 de maio confirmou que estamos no caminho certo! Concentre-se em estabilidade, desempenho, qualidade. A reestruturação do processo nos aguardava ainda mais, mas essa é uma história completamente diferente.

Grande outono retrô e 6 práticas


Em situações críticas, são desenvolvidas boas práticas que podem e devem ser transferidas para um momento silencioso. Foco, ajuda entre equipes, rápida implantação na produção sem esperar por uma regressão completa. Começamos com retro e, em seguida, desenvolvemos a estrutura do processo.



Os dois primeiros dias se passaram em uma discussão de práticas. Não estabelecemos o objetivo de "colocar uma retrospectiva às duas horas". Após essa situação, estávamos prontos para dedicar algum tempo para elaborar nossas idéias e nosso novo processo em detalhes. Todos participaram. Todos os envolvidos na restauração trabalham de uma maneira ou de outra.



Como resultado, havia seis práticas importantes sobre as quais gostaria de falar com mais detalhes.

  1. Top N . , . Product Owners , , , . . , . , , , . , . N – Lead Time .
  2. . . -, , . , , , . .
  3. . , « » . , . , , . , - . Dodo IS. .
  4. Pull Request. , Pull Request, - . . , , , , - . , . , . 15 .
  5. Performance- — . performance- . , . Performance- . baseline , PR . , .
  6. Performance . — . , , -, , , . . , .



1.

21.04.2018 – Dodo IS. ?


(Site Reliability Engineering): . , .

(Site Reliability Engineering, Product Owner Dodo IS): . , , .

auth’, . . , .

, () :



. , .

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

. redis, . . - , . .

Dodo IS . . , . , , , , . , — .

. « ». « , » .

- ?


:

– . . . , . . .

:

. , . ( ), - . .

. :

  1. .
  2. .
  3. , .

?



:

, , , .

:

, , . , .

? ?



: , – .

:

  1. — . - - .

    , . 2018 , PerformanceLab, .
  2. , . Less-.
  3. . 2018 -, . , . - 2018 .
  4. async . , 21.04.2018 . , . async.
  5. . , SaveOrder async-await. , . : , LF, 20 . , . , . !

    , , , .

    , , . — -. .
  6. . , (, ). , . «» . nginx , - , .

    : innodb_lock_wait_timeout = 5; innodb_rollback_on_timeout = ON. . , , , , .

, ?


:

  1. , , , . , .
  2. , .
  3. , , , . – .

:

  1. .
  2. . , , -. .
  3. . , - , .

, ?


:

«» , «». , , . .

:

, . , , . .

2. , (Dodo IS Architect)
— , . , — .

, , . , (, , ) .

IT-. Dodo IS, . …

X , . . Dodo IS , , , . , , , . . 146%, . , Dodo IS ?

, . , , . , . , !

, . « »: 11- , , 2 . «» . 3-4 , . , . .

, , . . Dodo IS , « ». ! ( ).

, Dodo IS , . Dodo IS . « », , . ( ), loadtest, , .

More articles:


All Articles