WeOp 2014
Marcus Vechiato - @vechiato
Agenda
 Objetivo
 Como pensamos em um sistema de
monitoração ?
 Do simples ao complexo
 O que monitorar ?
 O que acom...
Objetivo
Objetivo desta apresentação é explorar
implementações de monitoração sem me ater à
ferramentas.
Melhores práticas...
Como pensamos em um sistema de monitoração
?
Como pensamos em um sistema de monitoração
?
 Não é apenas uma ferramenta
 A ferramenta de monitoração é um dos
componen...
Alguns números da Locaweb
 Equipamentos de Rede
 Brocade / Cisco / Force10 e outros
 ~21 mil servidores (físicos e virt...
Do simples ao complexo
 Tenha claro quais são suas maiores dores pra
definir seus objetivos
 Não idealize o sistema perf...
O que monitorar ?
 Infraestrutura e serviços Core – rede/no
breaks/temperatura/DNS
 Sistema Operacional (memória/cpu/red...
O que acompanhar ?
Converter a visão de indicadores de
infraestrutura para produtos/componentes/times
 Dashboards para pú...
Onde alguns se perdem
 É comum o diagnóstico: “a ferramenta xpto não
funciona, precisamos de uma nova”
 Intervalo entre ...
Automação de configurações
 A monitoração é o melhor lugar pra começar a
gerenciar a instalação de componentes e
configur...
ITIL e Ferramentas de ITSM
 Ferramentas de ITSM
 Recomendo fortemente
 Se pretende abrir incidentes automaticamente gas...
Abertura automática de incidentes
Alguns benefícios da abertura automática em ambientes
maiores:
 Equaciona a ineficiênci...
Abertura automática de incidentes
 Integração via:
 API preferencialmente (rest/soap)
 E-mail – com templates, a maiori...
Abertura automática de incidentes
 Re-abertura automática de incidente caso seja
resolvido e continue falhando na monitor...
Abertura automática de incidentes
 Fechamento automático de incidentes caso a
monitoração normalize antes de atuação do
t...
Ferramentas já utilizadas
 Monitoração:
 Nagios
 Check_mk – Locaweb
 Zabbix
 ITSM:
 Service Now (API) – Locaweb
 CA...
Desafios
 Regra de Ouro: “Todo alarme tem que ter uma
atuação corretiva” nem que seja ajustar os
thresholds em caso de fa...
Desafios
 Quem implementa a solução e quem
administra o dia a dia ?
 Implementação da solução: naturalmente o
time/pesso...
Desafios
Mais importante que as ferramentas são as pessoas
e aderência aos processos definidos, de ponta a
ponta.
Revisite...
Perguntas ?
Próximos SlideShares
Carregando em…5
×

Monitoração - muito além do sistema operacional - WeOp 2014

755 visualizações

Publicada em

O objetivo desta apresentação é explorar implementações de monitoração sem me ater somente a ferramentas. Melhores práticas aplicáveis a todos os tamanhos de infraestrutura, no que deu certo e no aprendizado dos erros cometidos nestes anos, incluindo automação de configurações, ferramentas, processos, pessoas e como atingir e manter a eficiência.

Publicada em: Tecnologia
0 comentários
6 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
755
No SlideShare
0
A partir de incorporações
0
Número de incorporações
25
Ações
Compartilhamentos
0
Downloads
12
Comentários
0
Gostaram
6
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Monitoração - muito além do sistema operacional - WeOp 2014

  1. 1. WeOp 2014 Marcus Vechiato - @vechiato
  2. 2. Agenda  Objetivo  Como pensamos em um sistema de monitoração ?  Do simples ao complexo  O que monitorar ?  O que acompanhar ?  Alguns números da Locaweb  Onde alguns se perdem  Automação de configurações  Itil e Ferramentas de ITSM  Abertura automática de Incidentes  Ferramentas já utilizadas  Desafios
  3. 3. Objetivo Objetivo desta apresentação é explorar implementações de monitoração sem me ater à ferramentas. Melhores práticas destacando o que deu certo e o aprendizado dos erros cometidos ao longo destes anos.
  4. 4. Como pensamos em um sistema de monitoração ?
  5. 5. Como pensamos em um sistema de monitoração ?  Não é apenas uma ferramenta  A ferramenta de monitoração é um dos componentes do processo  Processo - pode nos remeter à burocracia se não for efetivo
  6. 6. Alguns números da Locaweb  Equipamentos de Rede  Brocade / Cisco / Force10 e outros  ~21 mil servidores (físicos e virtuais)  Windows (2003/2008/2012)  Linux (CentOs/Redhat/Debian)  Oracle/MySql/Postgre/MSSQL/Mongo DB  VmWare/Xen  ~500 mil ítens/serviços monitorados a cada minuto  ~17 mil incidentes tratados por mês
  7. 7. Do simples ao complexo  Tenha claro quais são suas maiores dores pra definir seus objetivos  Não idealize o sistema perfeito que cobrirá todos os GAPs, ele não existe  Lembre-se: quais são seus recursos e quais as reais habilidades do time  Prefira uma implementação gradual com entregáveis bem definidos
  8. 8. O que monitorar ?  Infraestrutura e serviços Core – rede/no breaks/temperatura/DNS  Sistema Operacional (memória/cpu/rede local/disco) onde aplicável  Aplicações  Visão do usuário (requisição http/tcp)  Local (uso de memória/threads/processos/etc)  Indicadores de Negócio/erros  Ex.: Vendas por hora  Ex.: Falhas de autenticação por minuto
  9. 9. O que acompanhar ? Converter a visão de indicadores de infraestrutura para produtos/componentes/times  Dashboards para públicos diferentes  Operações ○ Visão de Indicadores por times/infraestrutura  Ex.: MTTR de incidentes do N1 por prioridade  Ex.: SLA e MTTR de storage abc  Produtos/Negócio ○ Visão de Indicadores comuns e específicos  Ex.: SLA do produto xpto 99,89%  Ex.: MTTR do produto xpto 0h45m
  10. 10. Onde alguns se perdem  É comum o diagnóstico: “a ferramenta xpto não funciona, precisamos de uma nova”  Intervalo entre probes de monitoração muito pequeno  Re-tentativas são importantes pra diminuir falsos positivos  Minha experiência:  Intervalo de probes padrão entre 1 e 5 minutos  Re-tentativas: ○ 5m durante a implantação/com instabilidades conhecidas ○ 3m em ambientes estavéis
  11. 11. Automação de configurações  A monitoração é o melhor lugar pra começar a gerenciar a instalação de componentes e configurações  começe com o agente de monitoração (se houver)  Servidor de monitoração ○ Via API onde for possível ○ Arquivos de configuração  Qual ferramenta usar pra automação ?  Depende do seu ambiente e conhecimento do time. Chef e Puppet são boas opções pra começar
  12. 12. ITIL e Ferramentas de ITSM  Ferramentas de ITSM  Recomendo fortemente  Se pretende abrir incidentes automaticamente gaste mais tempo avaliando qual será sua ferramenta  Processos são a espinha dorsal  Gestão de Incidentes  Gestão de Problemas  Gestão de Mudanças  CMDB – registro/controle é mandatório  Em instalações pequenas sua ferramenta de monitoração é seu CMDB  Em ambientes maiores você terá que sincronizá-lo com a ferramenta de ITSM
  13. 13. Abertura automática de incidentes Alguns benefícios da abertura automática em ambientes maiores:  Equaciona a ineficiência de registro manual de incidentes  Registra falhas no momento que ocorrem  Permite pré-definir importância de cada componente/serviço e em caso de falha priorizar sua resolução  Diminuir a resolução informal de incidentes sem registro  Subsídio para análise profunda do ambiente  Integrada à gestão de crises reduz o tempo de resolução e melhora a comunicação relacionada  Cálculo realista de OLA’s e SLA’s
  14. 14. Abertura automática de incidentes  Integração via:  API preferencialmente (rest/soap)  E-mail – com templates, a maioria das ferramentas permitem (só use em último caso)  Utilize a prioridade ao abrir o incidente para permitir a priorização pelo time resolvedor. Segundo Itil, de 1-5:  Prioridades (pense numa pirâmide): ○ 1 e 2: tem que ser menos de 10% dos incidentes ○ 3: 30% ○ 4: 40% ○ 5: 10%  Pra cada prioridade defina seus diferentes OLA’s de resolução. Lembre-se que isto vai afetar diretamente o tamanho dos times resolvedores
  15. 15. Abertura automática de incidentes  Re-abertura automática de incidente caso seja resolvido e continue falhando na monitoração ou falhe novamente em menos de 30m  Novo incidente no caso de novo alarme após 30m do último incidente resolvido  Não abrir incidentes durante manutenções programadas
  16. 16. Abertura automática de incidentes  Fechamento automático de incidentes caso a monitoração normalize antes de atuação do time com status de “sem intervenção” permite:  refinar a solução e sua eficiência  ajuste de thresholds muito justos  Informações para abertura de Problemas  Falhas de planejamento/execução em mudanças  Retomar rapidamente o tratamento de incidentes após eventos com centenas/milhares de incidentes abertos em curto período de tempo
  17. 17. Ferramentas já utilizadas  Monitoração:  Nagios  Check_mk – Locaweb  Zabbix  ITSM:  Service Now (API) – Locaweb  CA – Service Desk Manager (API) – Locaweb  HP – Service Center (API)  OTRS – (API)
  18. 18. Desafios  Regra de Ouro: “Todo alarme tem que ter uma atuação corretiva” nem que seja ajustar os thresholds em caso de falso positivo.  Não se engane – no ínicio você vai ter muitos falsos positivos. É preciso persistência.  Se você não fechar incidentes automaticamente durante instabilidades, normalmente de rede, você vai ficar soterrado em incidentes e vai deixar de ver alarmes importantes quando a instabilidade cessar.
  19. 19. Desafios  Quem implementa a solução e quem administra o dia a dia ?  Implementação da solução: naturalmente o time/pessoa mais Sênior  Quem deve incluir as monitorações no sistema ? Se pensou no estagiário ou nas pessoas mais Júniores do time pensou errado. Também é responsabilidade dos mais Sêniores.
  20. 20. Desafios Mais importante que as ferramentas são as pessoas e aderência aos processos definidos, de ponta a ponta. Revisite os processos periodicamente para ajustar e evoluir de acordo com as necessidades correntes Se algum processo não está funcionando, mude-o. Não permita que ele seja abandonado ou burlado.
  21. 21. Perguntas ?

×