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 ...

•     uptime     -    este comando serve para saber há quanto tempo uma máquina está no ar , ou seja , por ele descobrimos se a máquina acabou de sofrer um reboot, e para descobrir se a carga nos processadores está muito alta.
•     df                  -    este aqui é usado para saber o espaço em disco utilizado.
•     ls                    -    usado para saber se existe algum processo em loop ocupando muita memória ou CPU.
•     mail            -    algumas das máquinas são servidores de email este comnado verifica se a fila de mail está muito grande.

    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.