Esta é a parte final da série que descreve como estamos aumentando nossa disponibilidade de serviços no Citymobil (você pode ler a parte anterior
aqui ). Agora vou falar sobre mais um tipo de interrupções e as conclusões que tiramos sobre elas, como modificamos o processo de desenvolvimento, que automação introduzimos.
1. Versão ruim: bug
Esse é o tipo mais desagradável de interrupções e incidentes. O único tipo que não apresenta sintomas visíveis além das reclamações de usuários finais ou comerciais. É por isso que esse incidente, especialmente um pequeno, pode permanecer despercebido na produção por um tempo.
Todos os outros tipos de interrupções são mais ou menos semelhantes a "Versão ruim: 500 erros internos do servidor". A única coisa é que eles não são acionados por uma liberação, mas por uma carga de trabalho, operação manual ou um problema de serviço externo.
Para descrever o método de lidar com esse tipo de interrupção, devemos lembrar uma piada antiga:
Um matemático e um físico recebem a mesma tarefa: ferver água. Eles recebem algumas ferramentas auxiliares: um fogão, uma chaleira, uma torneira com água, fósforos. Ambos se revezam no enchimento da chaleira com água, ligando o gás e começando a aquecer a chaleira. Depois, a tarefa é simplificada: eles recebem uma chaleira, cheia de água e um fogão que já está ligado. A tarefa é a mesma - ferver água. O físico coloca a chaleira no fogão. O matemático esvazia a chaleira, apaga o gás e diz: "O problema é reduzido para um que já foi resolvido". © anekdotov.net
Esse tipo de interrupção deve ser reduzido para "Versão ruim: 500 erros internos do servidor" a todo custo. Idealmente, os erros devem ser registrados da mesma maneira que 500 erros. No entanto, é claro, você não pode registrar o evento de um bug porque, se pudesse, não o faria em primeiro lugar.
Uma das idéias para rastrear um bug é procurar rastros no banco de dados. Esses rastreamentos nos permitem ver que há um erro e enviar alertas. Como podemos ajudar nisso? Começamos a investigar todos os grandes erros e a encontrar soluções: que tipo de monitoramento / alerta por SMS pode ser criado para fazer com que esse erro se revele imediatamente como um erro 500? Aqui estão alguns exemplos.
1.1 Exemplo de uma interrupção causada por um bug
De repente, estávamos recebendo uma enorme quantidade de reclamações de nossos usuários: os pedidos pagos via Apple Pay não podiam ser fechados. Iniciamos nossa investigação; o problema foi reproduzido no ambiente de teste. A causa raiz foi encontrada: atualizamos o formato da data de validade dos cartões de crédito porque ela foi alterada por um serviço de processamento de pagamentos, mas não foi feita corretamente para pagamentos via Apple Pay; portanto, todos os pagamentos do Apple Pay foram recusados. Nós o corrigimos assim que soubemos do problema, o implantamos e o problema desapareceu. No entanto, esse problema permaneceu ativo por 45 minutos.
Após esse problema, monitoramos vários pagamentos mal-sucedidos do Apple Pay e criamos alertas SMS e IVR com um limite diferente de zero (já que alguns pagamentos malsucedidos são considerados normais pelo serviço; por exemplo, se um cliente não tem dinheiro em sua conta ou o cartão de crédito dela está bloqueado). Desde aquele momento, descobriríamos imediatamente a passagem do limiar. Se uma nova versão causar algum problema no processamento do Apple Pay, descobriremos isso imediatamente devido ao monitoramento e reverterá a versão em 3 minutos (o processo de reversão manual é descrito em um dos artigos anteriores). Portanto, costumava ser 45 minutos de inatividade parcial e agora são 3 minutos. Lucro!
1.2 Outros exemplos
Um erro na lista de pedidos. Implementamos uma lista de otimização de pedidos no aplicativo de driver. O código teve um erro. Como resultado, às vezes os motoristas viam a lista de pedidos vazia. Descobrimos esse bug por acaso: um dos engenheiros estava brincando com o aplicativo do driver e nos deparamos com esse problema. Identificamos rapidamente a versão ruim e ela foi revertida imediatamente. Consequentemente, criamos um gráfico de um número médio de pedidos na lista com base nas informações do banco de dados. Em seguida, analisamos este gráfico retrospectivamente mês a mês. Percebemos uma ravina recente causada por esse bug e criamos um alerta de SMS por meio de uma consulta SQL. Ele cria esse gráfico quando um número médio de pedidos na lista ultrapassa o limite inferior que foi definido com base no mínimo para o mês atual.
Um bug no cachback. Estávamos alterando a lógica de distribuição de cashback do usuário. Entre outras coisas, enviamos para o grupo errado de clientes. O problema foi resolvido, o gráfico de reembolso foi criado; vimos um aumento drástico e também notamos que isso nunca havia acontecido antes e criamos um alerta por SMS com um limite apropriado.
Mais uma vez um erro nos pagamentos. O novo lançamento causou o erro - levaria uma eternidade para fazer um pedido, o pagamento com cartão não funcionou, os motoristas solicitaram que os clientes pagassem em dinheiro. Descobrimos o problema por meio de reclamações de call center. Implementamos uma correção e criamos um alerta para o horário de fechamento de pedidos com limites, descobertos por meio da análise de gráficos históricos.
Como você pode ver, estamos usando a mesma abordagem para lidar com todos os incidentes desse tipo:
- Descobrimos um problema.
- Nós solucionamos o problema e encontramos um erro no código.
- Nós consertamos isso.
- Nós descobrimos os rastreamentos no banco de dados (também podem ser encontrados nos logs do servidor da Web ou no Kibana) que podem apontar para os sinais do problema.
- Construímos um gráfico desses traços.
- Voltamos no tempo e observamos os altos e baixos do gráfico.
- Selecionamos um bom limite para um alerta.
- Quando o problema surge novamente, nós o descobrimos imediatamente através de um alerta por SMS.
O que há de bom nesse método: um gráfico e um alerta resolvem todo o grande grupo de problemas (exemplos de grupos de problemas: pedidos não podem ser fechados, bônus extras, pagamentos do Apple Pay não são processados etc.)
Eventualmente, implementamos alertas e monitoramento para todos os grandes erros como parte de nossa cultura de engenharia. Para não perder essa cultura, formalizamos um pouco. Começamos a nos forçar a criar um relatório para cada interrupção. O relatório é um formulário preenchido com respostas para as seguintes perguntas: causa raiz, como a corrigimos, impacto nos negócios, sugestões. Todos os campos são de preenchimento obrigatório. Então, tivemos que concluir se gostamos ou não. Essa mudança de processo foi obviamente escrita em fazer e não fazer.
2. Kotan
Nosso nível de automação de processos estava aumentando e decidimos que era hora de criar uma interface da web que mostrasse o estado atual do processo de desenvolvimento. Chamamos essa interface da web de "Kotan" (da palavra russa "roll", "roll out" :-)
"Kotan" tem a seguinte funcionalidade:
Lista de incidentes . Ele contém a lista de todos os alertas anteriores - o que exigiu uma reação humana imediata. Para cada incidente, registramos a hora em que começou, a hora em que acabou (se já acabou), o link para um relatório (se o incidente acabou e há um relatório) e o link do guia de alerta para ver que tipo de alerta esse incidente pertence a.
O diretório de alertas . Esta é praticamente uma lista de todos os alertas. Para deixar mais claro, a diferença entre um alerta e um incidente é a seguinte: o alerta é como uma classe, enquanto o incidente - é um objeto. Por exemplo, "número de 500 erros é maior que 1" é o alerta. E "número de 500 erros é maior que 1 e eles aconteceram nesta data, neste momento, duraram tanto tempo" - é um incidente. Todo alerta é adicionado ao sistema manualmente através do processo descrito acima, após a resolução de um problema específico que nunca foi detectado pelo sistema de alerta. Essa abordagem iterativa garante um baixo risco de alertas falsos positivos (que não requerem ação). O diretório contém um histórico completo do relatório para todos os tipos de alerta; que ajuda a diagnosticar um problema mais rapidamente: você recebe um alerta, acessa "Kotan", clica no diretório, verifica todo o histórico e tem uma idéia de onde mergulhar. A chave para a solução de problemas bem-sucedida é ter todas as informações em mãos. O link para alertar o código-fonte (para saber com certeza sobre qual situação esse alerta indica). Uma descrição escrita dos melhores métodos atuais para combater esse alerta.
Relatórios Estes são todos os relatórios da história. Todo relatório possui links para todos os incidentes aos quais está associado (às vezes os incidentes ocorrem em grupos; a causa raiz é a mesma e criamos um relatório para todo o grupo), a data em que este relatório foi gravado, o sinalizador de confirmação da solução do problema e a maioria importante: a causa raiz, como foi corrigida, o impacto nos negócios, as conclusões.
Lista de tópicos . Todo take-away tem uma nota informando se foi implementado, a implementação ainda está chegando ou não é necessária (com uma explicação do por que não).
3. O que mudou no processo de desenvolvimento de software?
Um componente crítico da melhoria da disponibilidade é um processo de desenvolvimento de software. O processo está mudando constantemente. O objetivo de tais mudanças é diminuir a chance de incidentes. As decisões para alterar o processo não devem ser tomadas abstratamente, mas devem ser baseadas em experiências, fatos e números. O processo não deve ser construído direcionalmente para baixo, mas de baixo para cima, com a participação ativa de todos os membros da equipe, uma vez que muitos chefes de toda a equipe são melhores que um chefe de gerente. O processo deve ser seguido e monitorado; caso contrário, não faz sentido tê-lo. Os membros da equipe devem se corrigir em caso de divergência: quem mais faria isso por eles? Deve haver automação máxima cuidando das principais funções, pois um humano comete erros constantemente, principalmente no trabalho criativo.
Para garantir que cada incidente tenha esclarecimentos, fizemos o seguinte:
- Todo alerta bloqueia automaticamente os lançamentos.
- Quando recebemos um alerta de fechamento (uma mensagem de texto informando que o incidente terminou), não desbloqueamos as liberações imediatamente, mas, em vez disso, somos oferecidos a criar um relatório sobre acidente.
- Um relatório deve conter as seguintes informações: a causa raiz de um acidente, como foi corrigido, o impacto nos negócios, as conclusões.
- O relatório é escrito pela equipe que solucionou o acidente. Aqueles armados com as informações completas sobre o acidente.
- As liberações são bloqueadas automaticamente até que esse relatório seja criado e aprovado. Isso motiva a equipe a se concentrar rapidamente e criar um relatório logo após a correção de um acidente.
- O relatório deve ser aprovado por alguém que não faz parte da equipe, para garantir que o relatório contenha todas as informações necessárias para entendê-lo.
Ao fazer isso, conseguimos, por um lado, autodisciplina ao salvar cada incidente na história e, por outro, fornecemos um controle automatizado. Agora é impossível não tirar conclusões ou não escrever um relatório.
4. Em vez de um epílogo
No lugar de um epílogo, deixe-me resumir rapidamente o que mudamos no processo de desenvolvimento de software para diminuir várias viagens perdidas.
Obrigado pela leitura até o fim. Boa sorte para o seu negócio! Desejo-lhe menos pedidos perdidos, transações, compras, viagens e tudo o que é crucial para você!