De Will Tipton, engenheiro de confiabilidade de sites, e Alex Bramley, engenheiro de confiabilidade do cliente
Nas últimas postagens, discutimos a importância da criação de um documento de política explícito que descreva como encaminhar violações de objetos de nível de serviço (SLO) e mostramos um exemplo real de um documento da equipe de engenharia de confiabilidade de sites (SRE) do Google. Nesta última postagem, temos um exercício sobre hipóteses para mostrar alguns cenários que aplicam a política e ilustrar casos extremos. Todos os cenários abaixo supõem um SLO de disponibilidade de "três noves" para um serviço em que metade do seu orçamento de erros é consumido por erros de segundo plano. Em outras palavras, nosso orçamento, ou limite, de erros é 0,1% e 0,05% de erros é considerado "normal".
Primeiro, vamos rever os limites da política:
Limite 1: alertas automatizados notificam a SRE de um SLO em risco
Limite 2: os SREs concluem que precisam de ajuda para manter o SLO e encaminham o problema aos desenvolvedores
Limite 3: o orçamento de erros de 30 dias foi esgotado e a causa raiz não foi encontrada. A SRE bloqueia versões e pede mais suporte da equipe de desenvolvimento
Limite 4: o orçamento de erros de 90 dias foi esgotado e a causa raiz não foi encontrada. A SRE encaminha o problema à liderança executiva para alocar mais tempo da engenharia aos trabalhos de confiabilidade
Depois de relembrar esses pontos, vamos examinar as violações do SLO.
Cenário 1: a causa raiz de uma interrupção curta, mas severa, é rapidamente determinada como um problema de dependência
Cenário : uma implementação incorreta de uma dependência crítica gera uma interrupção de 50% por uma hora enquanto a equipe responsável pela dependência reverte a versão que apresentou o problema. Quando a reversão é concluída, a taxa de erro retorna aos níveis anteriores. A equipe identifica e reverte o commit que é a causa raiz. A equipe responsável pela dependência escreve um relatório de análise retrospectiva. Os SREs do serviço contribuem com algumas IAs para impedir a recorrência.
Orçamento de erros : considerando a disponibilidade de três noves, 70% do orçamento de erros de 30 dias foi usado apenas durante essa interrupção. O orçamento de 7 dias foi excedido e, considerando os erros de segundo plano, o orçamento de 30 dias também.
Encaminhamento : a SRE foi alertada para administrar o impacto na produção (limite 1). Se a SRE entender que a classe do problema (má configuração ou push binário) é suficientemente rara ou foi adequadamente reduzida, o serviço é "retornado ao SLO" e a política não determina outro encaminhamento. Isso é intencional. A política prioriza a velocidade de desenvolvimento, e bloquear versões exclusivamente pelo esgotamento do orçamento de erros de 30 dias contraria essa política.
Se o problema for recorrente (ou seja, ocorrer duas vezes na semana, consumindo mais de um quarto do orçamento de erros) ou se a recorrência for considerada provável, é hora de encaminhar para o limite 2 ou 3.
Cenário 2: uma interrupção curta, mas severa, que não tem causa raiz óbvia
Cenário : o serviço tem uma interrupção de 50% por uma hora, sem causa conhecida.
Orçamento de erros : como no cenário anterior, ou seja, o serviço excedeu seus orçamentos de erro de 7 dias e 30 dias.
Encaminhamento : a SRE é alertada para administrar o impacto na produção (limite 1). A SRE encaminha rapidamente o problema à equipe de desenvolvimento. A equipe pode solicitar novas métricas para obter maior visibilidade do problema, instalar alertas de fallback, e o SRE e a equipe envolvidos priorizam a investigação do problema para a próxima semana (limite 2).
Se, mesmo assim, a causa raiz não for determinada, o SRE suspenderá o lançamento de recursos após a primeira semana até que a interrupção saia da janela de medição de 30 dias do SLO. Mais membros das equipes de SRE e desenvolvimento são retirados das tarefas atuais para depurar ou tentar reproduzir a interrupção. Essa passa a ser a prioridade número um até que o serviço retorne ao SLO ou a causa raiz seja determinada. À medida que a investigação progride, as equipes de SRE e desenvolvimento partem para mitigação, soluções temporárias e desenvolvimento de defesas detalhadas. O ideal é que, quando a interrupção sair do horizonte do SLO, a SRE esteja confiante de que será mais fácil detectar a causa raiz em uma eventual recorrência e que ela não terá o mesmo impacto. Nessa situação, a equipe poderá justificar a retomada do lançamento de versões, mesmo sem ter identificado uma causa raiz concreta.
Cenário 3: um consumo lento do orçamento de erros com uma causa raiz mal determinada
Cenário : uma regressão afeta a produção no dia T, e o serviço começa a apresentar 0,15% de erros. A causa raiz da regressão escapa aos SREs e desenvolvedores por semanas. Eles tentam diversas correções, mas não reduzem o impacto.
Orçamento de erros : se não resolvido, o problema consumirá mensalmente 150% do orçamento mensal de erros.
Encaminhamento : o SRE envolvido é notificado via tíquete por volta de T+5 dias, quando o orçamento de 7 dias é esgotado. O SRE aciona o limite 2 e encaminha o problema à equipe de desenvolvimento por volta de T+7 dias. Por conta de algumas correlações com a maior utilização de CPU, as equipes de SRE e desenvolvimento envolvidas criam a hipótese de que a causa raiz dos erros é uma regressão no desempenho. Os desenvolvedores envolvidos encontram algumas otimizações simples e as aplicam. Elas entram em produção em T+16 dias como parte do processo normal de lançamento. As correções não resolvem o problema, mas agora é impraticável reverter duas semanas de lançamentos de código diários para o serviço afetado.
Em T+20 dias, o serviço excede o orçamento de erros de 30 dias, acionando o limite 3. A SRE interrompe o lançamento de versões e encaminha o problema para aumentar o envolvimento do desenvolvimento. A equipe de desenvolvimento concorda em montar um grupo de trabalho de dois desenvolvedores e um SRE, cuja prioridade é determinar a causa raiz e remediar o problema. Sem uma boa relação entre as mudanças no código e a regressão, o grupo começa a criar perfis de desempenho detalhados e remover mais gargalos. Todas as correções são agregadas em um patch semanal maior aplicado na versão de produção atual. A eficiência do serviço aumenta consideravelmente, mas a taxa de erros continua elevada.
Em T+60 dias, o serviço consome o orçamento de erros de 90 dias, acionando o limite 4. A SRE encaminha o problema à liderança executiva, que solicita uma quantidade considerável de esforço de desenvolvimento resolver a falta constante de confiabilidade. A equipe de desenvolvimento faz uma análise detalhada e encontra problemas de arquitetura. Após algum tempo, implementa novamente alguns recursos para eliminar um caso extremo de interação entre o servidor e o cliente. As taxas de erro voltam ao nível anterior. Os recursos bloqueados são lançados em lotes assim que o lançamento de versões é reiniciado.
Cenário 4: excursões transientes e recorrentes da SLI
Cenário : versões binárias causam picos transientes de erro que ocorrem com a versão diária ou semanal.
Orçamento de erros : se os erros não ameaçam o SLO de longo prazo, a SRE é a única responsável por garantir o ajuste correto do alerta. Por isso, considerando este cenário, suponha que os picos de erro não ameaçam o SLO em nenhum período superior a algumas horas.
Encaminhamento : inicialmente, o alerta baseado no SLO notifica os SREs. O processo de encaminhamento prossegue como no caso de consumo lento. Especificamente, o problema não deve ser considerado "resolvido" simplesmente porque a SLI retorna ao normal entre as versões, já que isso é insuficiente para recolocar um serviço no SLO. A SRE pode ajustar o alerta para que um consumo maior ou mais rápido do orçamento de erros acione uma página e pode decidir investigar o problema como parte do trabalho contínuo de confiabilidade do serviço.
Resumo
É importante simular situações de uso da política de encaminhamento em condições severas com cenários hipotéticos para garantir a eliminação de casos extremos inesperados e verificar se a política é clara. Divulgue amplamente esboços da política e use anexos para abordar os problemas detectados, mas não sobrecarregue a política com justificativas dos pontos de mudança escolhidos. Espere discussões prolongadas se seus colegas entenderem que suas propostas são controversas. Lembre-se de que o que mostramos aqui é apenas um exemplo. Uma equipe de SRE real que pretenda atingir a meta de alta disponibilidade provavelmente estruturaria a política de encaminhamento de forma diferente.
4 comentários :
Do you want to find the best persuasive essay topics list? I have one!
Ingin mendapatkan kemewahan hidup yang nyata beberapa game poker ini pokerrepublik88 sangat direkomendasikan yang sekarang sedang trending di 2019, situs terpercaya di kartupoker2019 ini sudah dimainkan oleh berjuta juta pengguna internet ditambah lagi dengan deposit yang sangat murah membuat remipoker2019 dan lima situs yang saya rekomendasikan ini lebih diminati untuk semua kalangan masyarakat jangan lewatkan kesempatan tersebut, segera anda mendaftar secara gratis dan mudah di rajaqq2019 , dapatkan keuntungan nyata yang fantastis dari sini indoqq2019
Ingin mendapatkan kemewahan hidup yang nyata beberapa game poker ini pokerrepublik 88 sangat direkomendasikan yang sekarang sedang trending di 2019, situs terpercaya di Kartupoker 2019 ini sudah dimainkan oleh berjuta juta pengguna internet ditambah lagi dengan deposit yang sangat murah membuat remipoker 2019 dan lima situs yang saya rekomendasikan ini lebih diminati untuk semua kalangan masyarakat jangan lewatkan kesempatan tersebut, segera anda mendaftar secara gratis dan mudah di rajaqq 2019, dapatkan keuntungan nyata yang fantastis dari sini indoqq 2019
peluang bisnis yang sangat menguntungkan di zaman ini pokerqiu adalah pemanfaatan teknologi karena setiap tahun perkembanngan teknologi link alternatif pokeroriental 2019 di dunia ini akan berkembang secara terus menerus dengan memanfaatkan teknologi internetjinpoker kita bisa melakukan usaha dalam bentuk online dan tanpa harus keluar rumah dan kebetulan kami juga menyediakan game judi online masterpoker88 yang bisa anda mainkan di rumah atau di ponsel anda tentunya game iniaduqq bisa menghasilkan uang jadi selain bisa menghilangkan capek anda juga bisa mendapatkan uang situs ini sudah terpercaya di seluruh indonesia dan kami sajikan untuk anda segera mainkan game ini sekarang juga!!
Thank you for sharing with us such a great blog. I would like to share my experience with you as well.
I'm an author on the travel blog and I travel around the world a lot
delta airlines telephone number customer service
south west phone number in spanish
air canada customer service phone number
alaska airlines visa customer service phone number
Postar um comentário