Posts Tagged Manutenção

Ferramentas Gratuitas para Manutenção de Servidores – Parte 1 (Munin)

Estreando aqui no Geeks Anônimos e a pedido do meu caro amigo Fernando, reposto aqui o início de um guia que estou escrevendo para o meu blog sobre algumas aplicações free que podem ajudar muito na manutenção e gerenciamento de servidores.

Estou há alguns poucos meses trabalhando nessa área, mas aprendi muito. Perdi o medo que tinha do Linux e agora configuro e monitoro servidores utilizando ferramentas que, uma vez configuradas corretamente, tornam a vida muito mais simples.

Não irei me focar em ensinar a configurar cada uma visto que as configurações variam de OS para OS e  existem tutoriais no site oficial da respectiva ferramenta e no Google. Simplesmente darei um overview apresentando as principais características, prós, contras e outras observações pertinentes.

Dividirei os posts, apresentando uma aplicação de cada vez. E começarei com o Munin.

1. Munin (http://munin.projects.linpro.no/)

É uma aplicação bastante simples de monitoramento de recursos de servidores. Permite a visualização via navegador de diversos gráficos referentes à uso de memória, espaço em disco, uso de CPU, tráfego de saída e entrada de dados, e outros. Sendo que cada fonte de dados, por padrão, é compilada em quatro gráficos (diário, semanal, mensal e anual). A coleta de dados é realizada através de um agendamento no cron do sistema, criado na instalação do Munin.

munin1

munin2

a. Instalação e configuração

No próprio site existe um guia abrangendo a instalação do Munin em diversas distribuições do Linux e até mesmo para o MacOS (no donuts for you, Windows users). Após esse processo, basta configurar o grupo e nome do servidor (como mostrado aqui) e configurar o Apache para permitir acesso ao “home” da aplicação (por padrão /var/www/munin/ ) através de algum URL.

O Munin é baseado em plugins, sendo que cada conjunto de gráficos é um plugin que pode ser instalado ou desinstalado fácil e independentemente. Basta criar ou excluir um link simbólico (atalho) na pasta /etc/munin/plugins do plugin desejado localizado em /usr/share/munin/plugins.

Além disso, é possível facilmente configurar o Munin para emitir alertas em certas condições como, por exemplo, quando o uso de CPU for maior que 80%. Isso pode ser feito integrando com o Nagios ou enviando e-mail através de do serviço sendmail ou um script externo.

b. Prós

  • Simples, direto e rápido;
  • Fácil configuração e permite a edição de plugins ou criação de novos;
  • Possui opção de alertas em determinadas condições.

c. Contras

  • A configuração do envio de alertas é muito básica, não permitindo controlar a quantidade ou a periodicidade dos envios. Se utilizado o Nagios, é possível configurá-lo para isso;
  • Depende da disponibilidade do sistema para realizar o monitoramento. Se o servidor travar do nada, o Munin ficará travado também;
  • Documentação online bagunçada e muitas vezes insuficiente para orientar novos usuários.

d. Observações adicionais

Por padrão, o Munin não apresenta um sistema de segurança para o acesso às suas informações. Uma forma bastante simples de fazer essa segurança é configurando o Apache para utilizar um arquivo de autenticação:

        Order deny,allow
        Deny from all
        Allow from 127.0.0.1

        AuthType Basic
        AuthName "My Server Munin"
        AuthUserFile /var/www/html/.htpasswd
        require valid-user

        Satisfy Any

Então é isso. ^^

Espero em breve voltar com outro post sobre outra aplicação para o gerenciamento de servidores ou dando continuidade à série “Java para Web” =P

TwitterFacebookPlurkDeliciousRead It LaterInstapaperLinkedInShare

, , , , , ,

2 Comentários

Como nós aplicamos Scrum em Projetos de Manutenção

Prosseguindo com os posts do blog, vamos entrar em um tema mais técnico.

Acredito que várias pessoas tem o mesmo que problemas que nós estamos tendo para a implantação do Scrum na empresa em que trabalho: – E os Projetos de Manutenção?

Antes que eu comece a descer a ladeira, preciso que vocês entendam a nossa situação. Somo uma empresa de desenvolvimento de softwares sob medida para nossos clientes, logo, não temos praticamente nenhum “Produto de Prateleira”, e geralmente depois da entrega do software, fechamos um banco de horas de manutenção e implementação de novas funcionalidades. E exatamente nesses projetos que estamos utilizando o Scrum da maneira que vou descrever.

Procurando algumas referencias, encontrei pouco material, e o que encontrei geralmente se aplicava a apenas um projeto. Desenvolvemos o nosso método baseado nesse 2 links: Kanban for support and operations e Applying Agile/Scrum practices in Maintenance projects

No PDF, Kanban for support and operations, eles recomendam que se utilize um Kanban que possa ser facilmente alterado a ordem dos projetos, visto que os projetos devem ser ordenados por Prioridade da esquerda para a direta horizontalmente (sendo o mais prioritário na esquerda), o fluxo das atividades e tarefas deve ser feito de baixo para cima, iniciando com o Backlog e no topo deve estar o Pronto.

Os Sprints desses projetos são semanais. Inicialmente estamos presos a desenvolvedores que conhecem o projeto para poder mexer nele, mas a idéia é que com o tempo, toda a equipe de manutenção seja capaz de resolver qualquer pendência de qualquer um dos projetos de manutenção, logo, quem estiver disponível atende.

Tomamos por Pronto tudo que é publicado em ambiente de produção. E se, por acaso, a tarefa voltar devido a algum bug, é cadastrada uma nova tarefa.

Abaixo tem algumas imagens do nosso Kanban de Manutenção.


Essa foto foi tirada no dia que desenhamos o Kanban


Essa foto, foi tirada antes da reunião de retrospectiva, após uma semana de trabalho. Após a reunião retiramos todos post-it’s que estava Prontos e Preparamos para a nova semana.

Notem que houve uma alteração no kanban, precisamos criar uma nova fase que em nenhuma das referencias é citada. Como nos projetos, por vezes, dependem do aprovação do Project Owner (PO), estava poluindo muito o kanban manter os post-it’s na fase de iniciado, enquanto o cliente não aprovava. Então criamos uma fase desenvolvido, para os Scrums Masters poderem saber o que deve ser cobrado do PO.

Bom, acho que isso já deve dar um rumo para quem está tendo o mesmo problema que nós tivemos.
Se você tem alguma experiência, compartilhe conosco nos comentários.

TwitterFacebookPlurkDeliciousRead It LaterInstapaperLinkedInShare

, , , , ,

9 Comentários