Mais cedo ou mais tarde, em qualquer projeto, é hora de trabalhar na estabilidade / disponibilidade do seu serviço. Para alguns serviços, no estágio inicial, a velocidade do desenvolvimento de recursos é mais importante, neste momento a equipe não está totalmente formada e as tecnologias não são selecionadas com muito cuidado. Para outros serviços (geralmente tecnológicos b2b), para ganhar a confiança do cliente, surge a necessidade de um alto tempo de atividade com o primeiro lançamento público. Mas suponha que o momento X tenha chegado e você começou a se preocupar com quanto tempo seu serviço "fica" no período do relatório. De acordo com o corte, sugiro analisar o que é o tempo de inatividade e a melhor forma de trabalhar para reduzi-lo.
Indicadores
Obviamente, antes de melhorar algo, você precisa entender o estado atual. Portanto, se começamos a reduzir o tempo de inatividade, é primeiro e necessário começar a medi-lo.
Não falaremos aqui em detalhes sobre como fazer isso especificamente, os prós e os contras de diferentes abordagens, mas o processo da tese é mais ou menos assim:
- contamos com métricas de quase negócios (erros no serviço, tempo de resposta do serviço, US $ / segundo, inscrições / segundo, etc.)
- determinar o que é bom e o que é ruim
- transição boa-> ruim é o começo de um incidente
- transição ruim-> boa - fim do incidente
- tempo do começo ao fim - a duração do incidente (limite conosco)
- a soma da duração dos incidentes para o período (mês / trimestre / ano) - tempo de inatividade
- (100 - <tempo de inatividade> / <duração do período> * 100) = porcentagem de disponibilidade para o período
Ao falar sobre tempo de atividade / tempo de inatividade, eles costumam mencionar outro indicador:
MTTR (tempo médio de reparo) - o tempo médio desde o início do incidente até o final.
Os problemas com ele começam desde a primeira palavra da abreviação. Como todos os incidentes são diferentes, a média da duração não pode nos dizer nada sobre o sistema.
Desta vez, não calcularemos a média de nada, mas apenas veremos o que acontece durante o incidente.
Anatomia de um incidente
Vamos ver quais etapas significativas podem ser distinguidas durante o incidente:
- detecção - o intervalo entre o primeiro erro que demos ao usuário antes de o atendente receber SMS
- reação - de receber uma notificação sobre um problema até o momento em que uma pessoa começou a resolver esse problema (geralmente naquele momento o evento de monitoramento é transferido para o estado de Confirmação)
- investigação - desde o início do trabalho em um problema até o momento em que a causa do incidente é compreendida e sabemos o que precisa ser feito para restaurar o trabalho.
- eliminação - o tempo de recuperação, por exemplo, liberação de reversão, promoveu uma nova
mestre servidor de banco de dados primário
Talvez nosso modelo esteja incompleto e existam outras etapas, mas proponho apresentá-las somente depois de percebermos como isso nos ajudará na prática. Enquanto isso, considere mais detalhadamente cada etapa.
Detecção
Por que gastamos tempo procurando uma emergência? Por que não enviar uma notificação sobre o primeiro erro que um usuário recebe? De fato, conheço muitas empresas que tentaram fazer isso, mas abandonaram essa ideia apenas algumas horas depois, pelas quais receberam várias dezenas de SMS. Eu acho que não existe um único serviço mais ou menos grande que não tenha um fluxo constante de "segundo plano" de erros. Nem todos eles são um sinal de que algo está quebrado, há também erros no software, dados inválidos obtidos do formulário e validação insuficiente etc.
Como resultado, o nível de erros (ou outras métricas) que excede as flutuações diárias é usado como critério para abrir um incidente. É exatamente isso que leva ao fato de que a notificação dos funcionários responsáveis ocorre depois do início real do problema.
Mas voltando à nossa tarefa original - reduzir a duração dos incidentes. Como podemos reduzir o tempo de detecção? Mais rápido para notificar? Chegando com uma super lógica para detectar anomalias?
Sugiro não fazer nada ainda, mas olhar para as próximas etapas, pois na realidade elas estão interconectadas.
Reacção
Aqui temos um fator puramente humano. Assumimos que o monitoramento conseguiu detectar o problema e ativamos com sucesso o engenheiro de serviço (toda a escalação também funcionou no estágio anterior).
Considere o "pior" caso, não temos um serviço de serviço dedicado e o alerta capturou o administrador que dorme pacificamente. Suas ações:
- responder ao SMS: aqui uma esposa com ouvido sensível ajuda muito, vários aplicativos para o telefone, melhorando o efeito de receber SMS (1-5 minutos)
- tome uma decisão de que, no entanto, sairá da cama: se os alertas não forem definidos corretamente, uma pessoa poderá esperar 2 minutos "e se a resolução vier?" e adormecer (1-15 minutos)
- acesse o laptop, abra os olhos, acorde, acesse o monitoramento, pressione Ack: (1-15 minutos)
Como resultado, no pior dos casos, temos 35 minutos de reação. De acordo com minhas observações, esse tempo de reação parece verdadeiro.
Como, neste estágio, estamos lidando com pessoas, devemos agir com extrema cautela e consideração. Em nenhum caso você precisa escrever um regulamento segundo o qual uma pessoa que acabou de acordar deve se mudar! Vamos apenas criar as condições.
Vamos nos livrar das dúvidas do engenheiro de que o problema terminará por conta própria. Isso é feito de maneira muito simples: torne o critério de alerta insensível a problemas menores e notifique se o incidente dura algum tempo significativo . Sim, acabamos de aumentar a duração do estágio "detecção", mas vamos ver um exemplo:
- aumentar o tempo de detecção em 5 minutos
- o número de incidentes é reduzido: todas as breves rajadas de erros geralmente caem dentro de 1 minuto. Esses incidentes curtos devem ser registrados, mas sem notificar as pessoas. Geralmente, eles oferecem um tempo de inatividade muito grande no total, mas você pode lidar com eles durante o horário comercial. Para esta tarefa, você precisará de alta granularidade no monitoramento, uma vez que o problema já terminou, e as ferramentas de diagnóstico em sua maior parte não mantêm o histórico.
- se uma pessoa é forçada a responder a alertas uma vez por mês ou menos frequentemente, e não a cada dois dias, ela responderá a ela de forma mais adequada e não tratará isso como uma rotina
- notificação atrasada permite que uma pessoa não pense: se um SMS chegar, tudo será sério e não será corrigido
Potencialmente, essa abordagem reduzirá o tempo total de reação em mais de 15 minutos. Se esse tempo de reação não lhe agradar, pense no serviço de serviço.
Investigação
Talvez este seja o estágio mais difícil de um acidente, quando você precisa entender o que está acontecendo e o que fazer. Na realidade, esse estágio muitas vezes é combinado ao estágio de tomada de medidas, pois geralmente o processo é assim:
- olhamos para monitoramento, logs (se o monitoramento não for suficiente), lançamos algumas outras ferramentas de diagnóstico
- apresentar hipóteses
- testamos hipóteses, por métricas ou executando alguma ação (reinicie tudo :)
- avaliar os resultados das mudanças
- comunicar com colegas se o seu conhecimento de um subsistema específico não for suficiente
e assim por diante até a iluminação ou o fim do incidente.
Esse estágio é geralmente o mais significativo na duração total do incidente. Como reduzi-lo?
Tudo não está muito claro aqui, existem vários vetores:
- Simplifique sua infraestrutura : imagine com que rapidez as pessoas que têm um banco de dados e um serviço travam
- disseminação do conhecimento em uma equipe : ideal se a comunicação das pessoas não ocorrer durante o incidente, mas durante o trabalho diário (a comunicação das pessoas geralmente é um processo muito longo)
- monitoramento : muitas pessoas pensam que o monitoramento funciona apenas no estágio "detecção", mas, na verdade, pode atuar como uma otimização do processo de teste de hipóteses ("o banco de dados funciona corretamente?", "meu serviço funciona com recursos?") e também como um transporte disseminação do conhecimento em equipe. "Serge, verifique se há erros no log do X sobre conflitos?" pode ser transformado em um gatilho, cuja descrição será um link para o wiki com instruções .
Eliminação
Como eu disse acima, esse estágio geralmente se funde com o anterior. Mas acontece que o motivo é imediatamente claro, mas a recuperação será muito longa. Por exemplo, você tem um servidor morto com mestre primário (não vou me acostumar por muito tempo :) com um banco de dados e você nunca promoveu uma réplica, ou seja, lerá a documentação, lançará uma nova configuração de aplicativo etc.
Naturalmente, após cada incidente significativo, você precisa descobrir como impedir que isso aconteça novamente ou acelerar muito a recuperação. Mas vamos ver quais direções podemos tentar elaborar proativamente:
- ferramentas de gerenciamento de infraestrutura : se para corrigir tudo o que você precisa para implementar uma nova configuração, mas isso é feito em pelo menos 20 minutos - essa é sua limitação. Tente criar cenários do que pode acontecer e uma maneira de acelerar urgentemente alguns processos. Por exemplo, em ansible você configurou serial (execução paralela de tarefas) = 3, mas se ainda mentir, poderá rolar com serial = 30, precisará ensinar todos a redefinir isso (da mesma forma que a estratégia de atualização sem interrupção no kubernetes).
- exercícios : se você souber que os cenários prováveis de falha e recuperação não são automatizados, você deve ter instruções que devem ser testadas . Planeje o tempo de inatividade (se necessário), realize exercícios. Muitas vezes, nesse estágio, esses casos são automatizados, pois a maioria das armadilhas, mesmo dos procedimentos mais complicados à primeira vista, são esclarecidas durante os exercícios.
- interação com prestadores de serviços: você deve saber com antecedência o que fará se o seu provedor de hospedagem ficar doente. Freqüentemente, a conscientização da probabilidade de um problema e do custo do fechamento de riscos leva à conclusão - "apenas esperamos pela recuperação". Mas, por outro lado, engenheiros e empresas estarão prontos para esse cenário. Por exemplo, você pode resolver o problema de mudar seu tráfego para um esboço pré-preparado, notificar os usuários com uma carta pré-preparada etc. Ou vice-versa, você faz uma instrução segundo a qual damos ao hoster 30 minutos para recuperar e depois começamos a mudar para outro controlador de domínio, onde já existe uma réplica do banco de dados, mas você precisa expandir todo o resto. E aqui, novamente, os ensinamentos, notamos o tempo para mudar, etc.
MTBF (tempo médio entre falhas)
Outra métrica comum mencionada na discussão do tempo de atividade. Novamente, proponho não fazer a média de nada, mas simplesmente falar sobre o número de incidentes que ocorrem durante um intervalo de tempo.
Aqui está a vanguarda da questão de quanto você cuidou da tolerância a falhas do seu serviço:
- existe um ponto único de falha (SPOF) na infraestrutura, qual é a probabilidade de falha?
- Você está confiante de que não existem SPOFs que você não conhece? (este é exatamente o problema que o macaco do caos resolve)
- Os balanceadores de carga estão funcionando bem? ( meu relatório sobre balanceamento )
- Quão resiliente é a rede?
- Quão confiável é o data center?
Às vezes, para calcular / prever tudo isso, eles fazem um "mapa de risco", onde cada cenário (que pode ser assumido, é claro que sempre existem aqueles que ainda não sabemos) tem uma probabilidade + impacto (tempo de inatividade curto / longo, perda de dados, perda de reputação) etc.). Em seguida, eles trabalham sistematicamente nesse cartão, fechando antes de tudo os cenários altamente prováveis e sérios em termos de impacto.
Outra técnica que pode ser usada é a classificação de incidentes passados. Fala-se muito agora que é muito útil escrever incidentes "post mortem", que analisam as causas do problema, as ações das pessoas, elaboram possíveis ações futuras. Mas, para analisar rapidamente as causas de todos os acidentes no período anterior, é conveniente resumir sua duração com um agrupamento de acordo com as "classes de problemas" e onde o maior tempo de inatividade é tomar medidas:
- erros humanos : reduza o número de ações manuais na produção, várias proteções contra erros do operador
- lançamentos malsucedidos : vale a pena melhorar os testes (incluindo testes de carga)
- erros de aplicação : repare vazamentos, falhas e outros congelamentos
- rede : compre equipamentos, configure, contrate networkers, mude o contratante
- Bancos de dados : contrate um DBA, cuide da tolerância a falhas, compre um hardware melhor
- DC : pense em backup ou realocação
- influências externas (ddos, bloqueio, revisão de certificados, domínios): compre antiddos, armazene proxies, monitore o período de validade de domínios / certificados, tenha vários certificados de diferentes CAs.
Ou seja, se você nem tentar prever possíveis cenários de problemas, definitivamente vale a pena trabalhar com incidentes que já ocorreram.
Total
Todos os incidentes são diferentes:
O algoritmo para trabalhar para aumentar o tempo de atividade é muito semelhante a qualquer outra otimização:
-> -> ->
Pela minha própria experiência, posso dizer que, para uma melhoria significativa no tempo de atividade, basta começar a segui-lo e analisar as causas dos incidentes. Geralmente acontece que as mudanças mais simples trazem o efeito mais significativo.
Nosso serviço de monitoramento ajuda não apenas no estágio "detecção", mas também reduz bastante a "investigação" (os clientes confirmarão)