MAC499 Trabalho de formatura Supervisionado
Sobre a empresa
No período de ABRIL /2000 até hoje fiz estágio em dois lugares cujas propostas eram totalmente diferentes.
Aqui vou dar enfoque ao estágio que fiz no CCE .
![]()
Aluno : Daniel Martins Sakai
Período : ABRIL / 2000 ate FEVEREIRO / 2001
Supervisor : Leila Lage Humes
Professora supervisora : Nami Kobayashi
O
CCE é o órgão responsável pela área
de informática e comunicação de dados da Universidade
de São Paulo - USP, e também presta serviços de informática
para a Comunidade Universitária.
Ele auxilia a Comissão Central
de Informática (CCI) à formular as diretrizes gerais de informática
e é responsável por executá-las. Assessora o Reitor
em assuntos relativos à informática, e em programas centralizados
de apoio de informática.
De forma breve, pode-se discriminar as grandes áreas de atuação
do CCE, neste momento, como segue:
1 - Gerência da USPnet, a rede computacional da USP, englobando a
manutenção de sua espinha dorsal, e projetos de redes locais
de Unidades.
2 - Gerência do Programa Pró-aluno, da redealuno e dos projetos
a eles associados.
3 - Prestação de serviços de informática a
docentes, pesquisadores e alunos englobando correio eletrônico, acesso
à USPnet por linha discada e apoio ao uso de ferramentas e ambientes.
4 - Apoio a pesquisadores que necessitam de recursos de computação
de alto desempenho para desenvolvimento de seus trabalhos.
5 - Suporte a computadores de uso geral da administração
da Universidade.
6 - Prestação de serviços de manutenção
de microinformática.
Maiores informações sobre
a empresa podem ser encontradas em www.usp.br/cce
O projeto de MONITORAÇÃO remota das máquinas.
Comecei junto com mais dois estagiários o projeto de monitoração dos computadores da rede . O pessoal do suporte tinha muita dificuldade de saber quais máquinas estavam OK e quais estavam com problemas ( eram mais de 20 computadores) . Esse projeto foi muito interessante , basicamente cada máquina monitorada rodava um script que fornecia informações úteis sobre o sistema eu escrevi um programa que pegava a saída deste script e o enviava a um computador servidor e, após algum processamento criava uma página em HTML informando a situação da respectiva máquina. No comeco do projeto éramos só três estagiários depois entraram mais alguns para ajudar na manutenção e correção de falhas do sistema . O projeto inicialmente iria monitorar um pequeno número de máquinas mas após perceberem a sua eficácia ele passou a monitorar muitas outras.
1 - O problema .
No CCE localizam-se grande parte dos computadores da USP , lá existe uma sala refrigerada 24 hs por dia que é o local onde ficam os grandes computadores , o CCE possui gerador próprio de modo que o fornecimento de energia elétrica é ininterrupto . Nesta sala ficam as máquinas que rodam o sistema Jupiter , a folha de pagamento dos funcionários da USP e diversas máquinas destinadas a processamento científico . Como existem muitas máquinas é difícil saber quais estavam funcionando bem e quais não estavam . Procuramos por um programa pronto na rede mas todos que achamos eram muitos genéricos e não nos fornecia a informação específica de que necessitávamos . Por isso nós criamos um programa novo destinado a este fim .
2 - Distribuição das tarefas
As tarefas não foram distribuídas formalmente o projeto simplesmente nos foi passado , eu assumi a parte do envio e recebimento dos pacotes e ajudei na parte da programação em Perl responsável pelo parser no pacote. A única parte que eu não tive uma participação mais ativa foi na contruçao das páginas em html.
3 - Prazo
Não houve um prazo específico simplesmente deveríamos terminar o quanto antes . Mas nossa chefe supervisionava nosso progresso nos dando orientação e tirando eventuais dúvidas .
4 - O script
Uma das mais importantes partes do projeto é o script que roda em
cada máquina cliente. Esta foi uma das últimas partes
a serem implementadas mas para fins didáticos será a primeira
a ser explicada .
Esse script executa comandos na máquina cliente a fim de saber qual
o seu status. Alguns comandos usados foram ...
A saída deste script é colocada num aquivo texto mais tarde
explicarei como ele é enviado para o servidor. Dependendo da arquitetura
da máquina e da sua função esses comandos são
diferentes , estes são os básicos e mais usados.
5 - O processo de envio.
No início do projeto uma das grandes dúvidas era , como enviar
pacotes de máquina para máquina sem a necessidade de se utilizar
login e password. A solução encontrada foi utilizar sockets
. Isto é , escrever um programa que monitorasse uma das portas de
uma máquina a espera de mensagens vindas de outras máquinas.
Foi utilizado sockets pois era uma maneira rápida de se enviar mensagen
e no início eu não conhecia outras maneiras. Escrevi um programa
em C que cuidava do envio e recebimento dos arquivos. Um detalhe importante
é que o programa deveria ser escrito de maneira muito geral pois
ele rodaria em plataformas muito diferentes desde um PC até a uma
máquina CRAY . Por isso escrevi o programa em C e não em
java por exemplo.
6 - Cliente
A
função deste programa é enviar um arquivo texto para
o servidor , pensei em compactar o arquivo para que o envio fosse mais
rápido e talvez até criptografá-lo para aumentar a
segurança mas meus chefes disseram que não era preciso o
que eu achei frustrante pois o programa ficaria muito mais interessante
desta maneira.
A chamada do programa é simples basta digitar cliente servidor
arquivo a porta de envio ficou hardcoded apesar de eu preferir uma
solução mais genérica . O
código pode ser visto aqui
7 - Servidor
A peça principal do sistema, é ele quem recepciona os arquivos
enviados e decide o que fazer . Como na parte do cliente
não houve preocupação com a segurança
decidi que ao menos no servidor haveria uma verificação do
IP , isto é , assim que o pacote chega é verificado
o IP do cliente se o IP fosse conhecido criava-se um arquivo texto correspondente
ao pacote enviado . Desta maneira só são aceitos pacotes
vindos de clientes conhecidos. Acredito que essas medidas não irão
gerar problemas já que o programa cliente não estava disponível
para qualquer usuário e que as portas dos sockets também
eram desconhecidas, desta maneira seria difícil alguém
enviar um pacote estranho e mesmo que o fizesse o problema só duraria
cinco minutos como irei explicar a seguir. O
código so servidor pode ser visto aqui.
Na realidade o projeto inteiro contém DOIS
servidores isto porque uma das redes do CCE tem um comportamento um tanto
quanto estranho. Lá existem máquinas que fazem parte de duas
redes completamente diferentes e o nome das máquinas muda de rede
para rede , logo uma máquina possui dois nomes . Até aqui
sem problemas mas a grande dificuladade é que elas possuem o mesmo
endereço IP . Desta forma o servidor não sabia de onde vinha
tal pacote se da rede A ou B . Mas até ai tudo bem pois mesmo que
estivesse em duas redes ainda se tratava da mesma máquina... Porém
uma das funções do projeto era verificar se uma máquina
ainda estava na rede então poderia ocorrer o caso em que uma
das redes caísse e a outra não e para o programa a máquina
estaria OK, por isso foram criados dois programas servidores em portas
diferentes e dois programas clientes de modo que uma máquina que
estivesse em duas redes deveria enviar dois pacotes para a máquina
servidora.
Outro dado interessante é que na realidade
são enviados pacotes para dois servidores de modo que se um sair
do ar o outro estará lá para cumprir a mesma função
. A única coisa que muda é o endereço do servidor
( óbvio).
Um dos problemas encontrados no servidor era que
este programa tinha a "mania" de ficar saindo do ar , isto é , durante
a fase de testes na minha máquina o programa se comportou muito
bem não saiu do ar nem uma vez sequer , porém ao começar
a receber muitos pacotes ele saia do ar de repente. Para resolver isso
encontramos um programa feito para linux que garantia que um daemon não
saia do ar em hipótese nenhuma , quer dizer ele até sai do
ar mas assim que isto acontece uma nova chamada ao programa é feita
e temos a impressão que nada aconteceu.
Um detalhe importante é que o servidor era
um PC com o linux Debian instalado.
No início do projeto foi especificado que
o programa iria monitorar um certo número de máquinas por
isso o servidor usava o IP da máquina dentro do próprio código
fonte , isso ficou ruim pois cada vez que eram colocadas novas máquinas
no projeto era preciso recompilar o servidor , deveríamos ter usado
um arquivo texto para isto , assim não seria necessária
toda esta recompilação.
8 - A junção do cliente com o script.
Agora vou explicar como é feito o envio do
do arquivo de estado da máquina cliente . Criamos um outro script
que tem a função de juntar esse arquivo texto com o programa
de envio. Ele simplesmente roda o script com os comandos de estado , coloca
a saída num arquivo texto e roda o programa de envio para mandar
o arquivo texto para o cliente . Esse novo script foi colocado no crontab
de todas as máquinas clientes de modo que rodasse de cinco
em cinco minutos. O crontab é um programa que se encarrega de agendar
tarefas no UNIX. Como o intervalo de envio dos pacotes é de cinco
minutos , mesmo que alguém mau intencionado envie um pacote da máquina
cliente para o servidor esse arquivo só é válido por
cinco minutos .
9 - A máquina servidora
É nesta máquina que fica o programa servidor
ela recepciona todos os pacotes enviados pelos clientes , tenho um diretório
que contém todos os arquivos de log mais atualizados .
Aqui nesta máquina temos um apache instalado com
suporte a cgi .
10 - Scripts em Perl / cgi-bin
Estes scripts são os responsáveis em ler os arquivos de log enviados pelos clientes e mostrar em uma página HTML a situação da respectiva máquina . Existem duas maneiras deste script ser executado uma seria a chamada via web brownser , que é a mais óbvia a segunda maneira entretanto é mais complicada o script deve ser executado de tempos em tempos na máquina servidora pois na primeira página HTML do projeto , nós mostramos quais as máquinas que estão com problemas e para saber isso é preciso verficar todas as máquinas de minutos em minutos. Fizemos isso para facilitar a vida do usuário de modo que ele não necessitasse ficar procurando por máquinas com problemas com esta solução a máquina com problemas é quem procura o usuário.
11 - Diferenças entre as máquinas
Como o projeto visa atender diferentes arquiteturas
a quantidade de scripts deveria ser no máximo igual ao número
de arquiteturas. Porém aqui foi feita a maior besteira do projeto
essa é a parte que me envergonha profundamente. Durante a fase de
testes cada um dos estagiários fez o script em Perl para uma das
arquiteturas, como estávamos testando , fizemos o seguinte, para
diferentes máquinas de uma mesma arquitetura copiávamos o
arquivo com um nome diferente , até ai tudo bem pois na versão
final iríamos usar apenas um arquivo mandando o nome da máquina
como parâmetro , só que houve um problema... Quando mostramos
para nossa chefe ela gostou tabnto do projeto e no mesmo instante mandou
o pessoal do CPd ( quem cuida mesmo das máquinas) começar
a usar o programa. Quando falamos que ele iria ser alterado ela disse que
como estava funcionando bem não era preciso fazer isso e falou para
deixarmos do jeito que estava . Por isto temos diversos arquivos iguais
que fazem a mesma coisa...
Tudo errado eu até pensei em alterar mas aí eu teria
que começar a mexer na parte dos outros e ninguém gostou
da minha sugestão . Depois todos concordaram comigo pois para dar
manutenção em todos estes arquivos dava um enorme trabalho
.
Desafios e frustrações encontrados
Para mim o grande desafio foi escrever o programa que enviaria e receberia
os pacotes vindos das diversas máquinas , eu não fiz a matéria
de redes por isso o meu conhecimento de rede era bem pequeno dei uma boa
procurada na Internet por informações para conseguir fazer
o programa , acredito que essa parte tenha ficado boa . A minha maior frustração
vocês irão ler na descrição do projeto , foi
a cópia inútil de código , escrever diversos programas
iguais que faziam praticamente a mesma coisa com exceção
do nome da máquina para mim isso foi uma enorme frustração
. Após a conclusão do projeto foi solicitado que houvesse
um histórico do estado das máquinas , nesta parte fiz o programa
da maneira correta recebendo como parâmetro o nome da máquina
desta forma existe um programa em Perl para cada arquitetura somente .
Durante o estágio em geral
achei frustante a cobrança feita aos estagiários, às
vezes ficavamos semanas sem nada para fazer e o ócio é algo
terrivelmente tedioso , chegavámos a procurar coisas para fazer
mesmo sem alguém ter nos pedido . Eu me sentia meio inútil
, e muitas vezes explicavam-me coisas óbvias o que me irritava
demais , alguns dos analistas não sabiam tanto quanto eu sobre computação
e mesmo sobre a rede do CCE e eu me sentia menosprezado pois muitas vezes
os ensinava e não era reconhecido . No fim do meu estágio
entrei em um projeto com um dos analistas e fui eu quem acabou assumindo
toda a responsabilidade , não que eu tenha achado ruim mas isso
me fez pensar que ali não era meu lugar pois eu fazia um melhor
trabalho e não era recompensado por isto . Isto me mostrou que há
uma carência de bons funcionários lá no CCE. As únicas
pessoas que me passaram algo foram minhas chefes que sabiam muito sobre
o assunto e os dois analistas que foram do bcc porque do resto eu não
aprendi nada .
Por se tratar de uma intituição pública
para ser promovido você precisa ter a sorte de abrir uma vaga e de
ter certos anos de casa, essa metodologia é horrível pois
eu vi analistas que sabiam menos que eu tornarem-se chefes dos meus antigos
colegas do BCC . Achei uma injustiça pois o pessoal que foi do BCC desempenhava
um trabalho melhor porém por não ter muito tempo de casa
acabavam ficando para trás . Por isto muitos desistem de trabalhar
lá indo atrás de salários melhores.
Sobre continuar na área
Se eu fosse continuar a trabalhar no CCE faria alguma
das matérias sobre redes e com certeza faria a matéria sobre
Administração de Sistemas UNIX se eu as tivesse feito elas
teriam ajudado demais no estágio . Uma matéria que me ajudou
muito foi Laboratório de Programação II por causa
dos scripts em Perl e cgi . Outra essencial foi MAC-122 pois é a
base de tudo mas com certeza ED também colaborou muito com a clareza
do código .
Não continuei lá pois não seria
muito valorizado minhas chefes sabiam do meu valor porém como eu
demoraria para me formar só poderia ser efetivado depois de muito
tempo e mesmo assim ainda haveriam analistas que faziam menos que eu e
sabiam menos que eu me dando ordens erradas e eu odeio isso , gosto de
aprender e não de ter de me conformar e ser político . Por
isso fui para uma nova empresa em que sou reconhecido e que meu chefe sabe
mais que eu, e quem me manda fazer os programas também sabe
muito , assim qualquer coisa que eu faço eu estou aprendendo
e se acho que está errado também posso discutir e mostrar
meu ponto de vista.
Sobre o grupo de trabalho
Acredito que a grande diferença
entre o trabalho em grupo nas disciplinas do IME e num estágio ou
emprego seja a motivação , no CCE não havia uma forte
cobrança sobre os prazos etc. Logo que entrei procurei sempre achar
algo para fazer pois não gosto de ficar parado e isso fez muita
diferença pois meus chefes perceberam isso e sempre que me enviavam
tarefas não se preocupavam em ficar me cobrando os resultados .
No IME você sempre tem que fazer o que lhe é pedido como num
EP e normalmente você é quem escolhe seu grupo, em um
emprego não você não escolhe com quem trabalhar por
isso você sempre tem de estar ajudando e ouvindo seus parceiros apesar
de muitas vezes eles estarem errados. No IME quando você termina
seu EP e recebeu sua nota você nunca mais vai mexer nele , em compensação
num trabalho você é o responsável pelo que você
fez e se você fizer algo mal feito e depois de um tempo aparecer
algum problema é você quem vai resolver por isso é
muito melhor fazer programas limpos e simples pois caso algo de errado
um ano mais tarde você consegue resolvero problema facilmente . E
diferentemente de um EP a especificação pode ser mudada
se você acha que conhece uma solução melhor você
não precisa fazer da maneira que seu chefe falou mas pode convencê-lo
que existe uma maneira mais rápida e mais simples e isto foi algo
que realmente eu gostei lá as minhas idéias foram sempre
ouvidas e discutidas e na maior parte da vezes atendidas.