Posts Tagged Manutenção
Ferramentas Gratuitas para Manutenção de Servidores – Parte 1 (Munin)
Posted by Jairton Júnior in Linux on 03/03/2010
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.


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
Como nós aplicamos Scrum em Projetos de Manutenção
Posted by Fernando Cézar in Desenvolvimento, Scrum on 01/03/2010
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.


