Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Tdc 2020 gerenciamento de incidente neste novo mundo

42 views

Published on

No últimos anos vimos uma grande mudança no jeito de lidar com tecnologia da informação, grande parte causado pela bandeira da transformação digital, seja por meio da mudança da cultura pelo agile junto ao devops, práticas SRE novas arquiteturas sendo o principal microserviços. Porém como lidar com esse mundo novo dentro do gerenciamento de incidentes?, como manter os serviços funcionando ao meio de tanta transformação? Essa palestra será um bate papo de dicas e premissas no ambito de gerenciamento de incidentes dentro deste novo mundo.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Tdc 2020 gerenciamento de incidente neste novo mundo

  1. 1. Gerenciamento de incidentes no mundo de microserviços
  2. 2. Quem sou eu ? Felipe Signorini, SRE na Udemy, criador do Maestro server, uma plataforma de gerenciamento de servidores e aplicações para ambientes multi cloud. https://github.com/Signorini - @signorini https://medium.com/@felipeklerkk
  3. 3. - Introdução - O por que do microserviço - SRE - Gerenciamento de incidentes - Por onde começar - Oncall - Post mortem - Mudando a cultura Agenda
  4. 4. Microserviço, a solução de todos os problemas Problemas de performance? - Microserviço Problemas de escalabilidade? - Microserviço Seu time está desmotivado - Microserviço Falta de resiliência? - Microserviço Precisa de uma tecnologia moderna? - Microserviço = Kubernetes Introduction
  5. 5. Caso 2 - Microserviços + nodejs Carolina Pascale - Microservices using Node.js and RabbitMQ - BrazilJS Conf 2017 https://www.youtube.com/watch?v=M7le0OEF9NQ Introduction
  6. 6. Caso 2 - Borg até o Prometheus: SRE Felipe Signorini e Paulo Castro - Borg até o Prometheus: Site Reliability Engineering - TDC2017 https://www.slideshare.net/felipesignorini/tdc-2017-b org-at-o-prometheus-site-reliability-engineering Introduction
  7. 7. Caso 3 - The way our backend works It's because of the way our backend works - Kraken. https://www.youtube.com/watch?v=y8OnoxKotPQ Introduction
  8. 8. μServices Palavra para reunir tudo isso Microserviços. Pensando em todo esse novo cenário procuramos uma maneira de entender a operação como developers. Prometheus apareceu de uma maneira natural já que foi pensado em como monitorar aplicação publicadas no Kubernetes. Borg e SRE
  9. 9. Cargo Cult
  10. 10. O por que do Microserviços
  11. 11. Qual a real vantagem do microserviço? Microserviço Monolítico Performance
  12. 12. Qual a real vantagem do microserviço? Microserviço Monolítico Performance Possível via engenharia Com uma boa arquitetura de código
  13. 13. Qual a real vantagem do microserviço? Microserviço Monolítico Performance Possível via engenharia Com uma boa arquitetura de código Escalabilidade
  14. 14. Qual a real vantagem do microserviço? Microserviço Monolítico Performance Possível via engenharia Com uma boa arquitetura de código Escalabilidade Federação dos serviços por natureza Com uma boa arquitetura de serviços
  15. 15. Qual a real vantagem do microserviço? Microserviço Monolítico Performance Possível via engenharia Com uma boa arquitetura de código Escalabilidade Federação dos serviços por natureza Com uma boa arquitetura de serviços Manutenção
  16. 16. Qual a real vantagem do microserviço? Microserviço Monolítico Performance Possível via engenharia Com uma boa arquitetura de código Escalabilidade Federação dos serviços por natureza Com uma boa arquitetura de serviços Manutenção Facilita para o desenvolvedor, porém pesa para o arquitetura Com uma boa arquitetura de código
  17. 17. Qual a real vantagem do microserviço? Microserviço Monolítico
  18. 18. Qual a real vantagem do microserviço? Microserviço Monolítico Performance Possível via engenharia Com uma boa arquitetura de código Escalabilidade Federação dos serviços por natureza Com uma boa arquitetura de serviços Manutenção Facilita para o desenvolvedor, porém pesa para o arquitetura Com uma boa arquitetura de código Capacidade de evolução
  19. 19. Qual a real vantagem do microserviço? Microserviço Monolítico Performance Possível via engenharia Com uma boa arquitetura de código Escalabilidade Federação dos serviços por natureza Com uma boa arquitetura de serviços Manutenção Facilita para o desenvolvedor, porém pesa para o arquitetura Com uma boa arquitetura de código Capacidade de evolução Grande capacidade de escalar pessoas e código. Quanto maior o time, mais difícil de manter todos na mesma página.
  20. 20. Qual a real vantagem do microserviço? Capacidade de evolução = Escalabilidade de pessoas, times e funcionalidade
  21. 21. Qual a real vantagem do microserviço? Capacidade de evolução = Escalabilidade de pessoas e times
  22. 22. SRE
  23. 23. class SRE implements DevOps
  24. 24. Sre como um time que habilita outros times a operar
  25. 25. Sla como contratos a ser seguidos
  26. 26. - Não é o cargo do DevOps - Não vai contra o DevOps - Ownership entre os times de desenvolvimento - SLA como um contrato a ser seguido
  27. 27. Gerenciamento de incidentes
  28. 28. O gerenciamento de incidentes é um conjunto de processos para restauração da operação normal de um ou mais serviços o mais rápido possível durante um mal funcionamento. O que é?
  29. 29. - Foco na tecnologia - O herói solitário - Istio tá tudo vermelho Incidente não gerenciado
  30. 30. - Escolha os canais de comunicação oficial - Estabeleça alertas de acordo com os SLAs - Composição do time de oncall - Post mortem Onde começar
  31. 31. Escolha os canais de comunicação oficial Chats Video call Status page Email Social
  32. 32. Alertas de acordo com o SLA - Evite a fadiga de alertas - Utilize poucos SLAs e depois vai incrementando lentamente - Seja pragmático
  33. 33. Alertas de acordo com o SLA - Contrato para com os usuários - Up and down - Velocidade - Contrato para com outros serviços - Latência - Capacidade de processamento
  34. 34. O time de suporte é responsável por gerenciar o incidente não em resolve-lo. Ownership
  35. 35. O time de suporte (aka oncall) é a linha de frente de qualquer incidente, quando algo acontece ele é o primeiro a ser alertado tendo como responsabilidade estar alerta e disponível a tomar qualquer ação em qualquer momento. Oncall
  36. 36. Baseados em senioridade Oncall
  37. 37. Baseados em papéis Oncall
  38. 38. O especialista é o engenheiro que deve-se ficar alerta, estar disponível a qualquer problema que ocorra em períodos dentro do horário comercial bem como fora do mesmo. - Ter autonomia - Atender o chamado de forma rápida. - Possuir conhecimentos técnicos e bom senso. O especialista - AKA Oncaller
  39. 39. O gerente de oncall deve-se oferecer suporte ao engenheiro oncaller. - Ter um grande bom senso de julgamento - Durante um incidente, possui poderes acima de diretores O gerente de suporte - AKA Call leader
  40. 40. - Gerente de suporte - Suplente - Escriba - Representante interno - Representante externo - Especialistas Oncall - Pager Duty
  41. 41. Post mortem - O momento certo para discutir mudanças de arquitetura - Soluções para resolução completa
  42. 42. Comparação SRE e ITILv4 O modelo de gerenciamento de incidentes SRE, foca em suportar times ágil, com autonomia de operação de sistemas por equipe, totalmente baseado em interações e com a total descentralização das decisões, o ITIL foca mais na garantia de governança na padronização de processos através de comando controle. - error budged - oncall baseado em papéis - flexibilização de processos - registro de incidentes - oncall baseado em senioridade - comando controle
  43. 43. Mudança na tecnologia cultura
  44. 44. Não mude tudo radicalmente, faça mudanças incrementais juntamente com a maturidade dos processos.
  45. 45. - Evite ao máximo o burnout - Não cultive a cultura do herói solitário - Evite tentar fazer múltiplos papéis - Confecção do post mortem deve ser uma tarefa crítica Boas práticas
  46. 46. Foque nas pessoas e não nas ferramentas
  47. 47. Thanks github.com/Signorini medium.com/@felipeklerkk

×