Conteúdo:
Este documento visa esclarecer como foi o trabalho desenvolvido na GVI (agosto/1999 a abril/2000), em relação ao projeto de servidores virtuais (a especificação do projeto encontra-se abaixo, assim como o significado de cada termo usado neste documento).
Além disso, serão destacados pontos relativos ao trabalho, como ambiente, estrutura, pessoal, perspectivas, opiniões, dentre outros. Meu objetivo com isso é passar minha experiência para que os alunos de outros anos possam aproveitá-la.
Manterei a seguinte linha: somente relatarei em cada item como as coisas eram, e deixarei para o item Opiniões Pessoais as impressões e as opiniões propriamente ditas.
Conceitos básicos não serão discutidos, como domínio, site, e-mail, etc.
A Global View Internet Services é um pequeno provedor de acesso à internet que começou suas atividades no meio do ano de 1999. Com uma cartela de clientes restrita, seu foco foi obter crescimento através de um nicho de mercado expressivo: a de hospedagem de sites.
O crescimento da empresa estaria muito limitado se fosse depender de pessoas para fazerem a manutenção dos domínios; além disso, os usuários gostariam que as configurações fossem feitas na hora pedida, o que também era um problema. Com esses fatores em mente, foi idealizado o projeto de servidores virtuais, que seria um sistema que automatiza toda a manutenção de hospedagem de domínios (sites).
A empresa é de pequeno porte e teve algumas mudanças no decorrer do tempo. No momento em que cheguei (agosto/1999), a empresa acabara de se formar, e estava se assentando. Apesar da idéia de servidores virtuais já ter surgido e estar se aperfeiçoando, o produto era na ocasião a criação de sites, sua hospedagem (manual), além do serviço de acesso discado próprio. Constava no quadro de funcionários designers, pessoal administrativo, vendedores, além do quadro técnico. Conforme o tempo passava, o desenvolvimento do projeto se concretizava, e o acesso discado como produto final não estava vingando (este produto teve seu fim decretado em janeiro de 2000, quando entraram as empresas de acesso gratuito no Brasil); este quadro da empresa também foi mudando: pouco tempo antes do sistema entrar no ar, deixaram a empresa os vendedores, os designers, restringiu-se o setor administrativo; também, foram contratados novos vendedores (vindos da área de hospedagem), além de suporte técnico especializado. Com o produto pronto, o quadro de funcionários era de aproximadamente 10 pessoas.
Com este quadro, não havia muita hierarquia. Havia o dono e seu sócio, e abaixo todos os outros funcionários. Como dito anteriormente, não havia um superior na área técnica, e éramos ao total 2 pessoas. Nós mesmos que discutíamos o problema, e íamos atrás das soluções.
Neste tópico tratarei como era a estrutura do trabalho, isto é, como era o trabalho diário, como eram as responsabilidades e obrigações. Tratarei também como era o trabalho em equipe (ou como não era), e como era a reportagem aos superiores.
O quadro de funcionários da empresa era muito reduzido, contando somente com duas pessoas na área de desenvolvimento. Fora nós dois, não havia nenhum superior na área, assim como nenhuma pessoa com experiência em desenvolvimento de sistemas que pudesse estar ajudando e/ou coordenando o desenvolvimento. Dessa maneira, deveríamos nos reportar diretamente com o diretor/proprietário da empresa.
A estrutura de trabalho lá passou por mudanças também. No início, quando entrei, havia eu e o Gustavo. Ele estava acabando de arrumar o provedor (ele entrara pouco tempo antes de mim), e como havia bastante trabalho, dividíamos este trabalho, mas atuávamos sozinhos. Poucas vezes neste início trabalhamos juntos, mas conforme o tempo passava, a necessidade de mais interação surgia. Após este período, quando foi dado início ao projeto, trabalhávamos juntos, ora discutindo idéias e diferentes pontos de vista, ou diferentes implementações, ou também pesquisando sobre o sistema. Mesmo neste período apareciam coisas do provedor relacionadas ao Gustavo a se fazer, e eu então ia tocando sozinho durante estes períodos. Boa parte do núcleo do sistema foi feito assim, desenvolvido por mim devido à necessidade.
Durante a fase de desenvolvimento da interação com o usuário, o trabalho foi totalmente dividido e feito a quatro mãos: sentávamos, discutíamos as idéias, dividíamos a tarefa e íamos em frente. Após esta fase, quando faltavam alguns detalhes para se tornar o sistema usável, o Gustavo precisou ser alocado para assuntos do provedor novamente, caindo sobre mim a responsabilidade de se finalizar o sistema.
A finalização do sistema coincidiu com a saída do Gustavo da empresa (fevereiro de 2000). Neste mesmo período, o Jeferson Mariano passou a fazer parte da equipe. Como ele não tinha experiência em desenvolvimento de sistemas para internet, primeiramente eu delegava algumas tarefas básicas que precisavam ser feitas a ele, e outras de cunho didático. Nisto, o sistema já estava funcionando e eu era o único responsável por ele e também o único responsável a corrigir seus erros e acrescentar novos serviços e utilidades.
Até minha saída, o Jeferson não pode se inteirar suficientemente no sistema para cooperar com seu desenvolvimento propriamente dito. Eu trabalhava sozinho no sistema, mas havia a responsabilidade de gerenciar todo o projeto, o que incluía o trabalho do Jeferson, a configuração e instalação das máquinas, a manutenção de nossa rede e o link de acesso, e até algumas vezes a conversar com clientes para tirar certas dúvidas.
Tratarei neste tópico dos objetivos do sistema, isto é, onde se queria chegar com seu desenvolvimento, e que tipo de funcionalidade ele deveria possuir.
O objetivo era desenvolver um sistema de hospedagem de sites totalmente automatizado, isto é, via interface web o usuário poderia executar todas as tarefas necessárias à manutenção de domínios, assim como de seus respectivos usuários. Estas tarefas incluem, por exemplo, a criação de domínios, de e-mails em cada domínio, de criação de contas ftp, etc. Em suma: o usuário do sistema não teria que ser nenhum conhecedor da área, e deveria conseguir mesmo assim hospedar seus sites, utilizando-se do sistema de servidores virtuais.
Na prática, nos foi passada uma idéia bem mais básica do que a descrição acima. Nenhuma especificação mais detalhada nos foi fornecida; simplesmente foi passado que deveria ser um sistema semelhante aos existentes nos EUA, que desse poder ao usuário de administrar tudo o que precisasse via interface web.
Não nos foi passado nenhum objetivo técnico. Coisas básicas, como utilizar linux como plataforma, e produtos open source nós definimos. Integração de plataformas, como o sistema se portaria tecnicamente, coisas deste tipo foram deixadas para a fase de desenvolvimento decidir.
Além disso, criamos o conceito de servidores virtuais. Uma noção de serviços virtuais pode ser encontrada neste howto. Definimos que cada máquina deveria se comportar como várias, e que cada usuário teria a impressão de que possui um servidor só para ele. Essa é a idéia do que é um servidor virtual: um sistema que se porta como um servidor, mas que na verdade é um subsistema dentro do servidor. Dentro de cada sistema desse seria possível trabalhar como se fosse um servidor de verdade isto é, configurar domínios, servidores de correio, etc. Também, O usuário teria acesso somente ao seu servidor virtual, não interferindo em nada nos outros instalados na mesma máquina. Seria possível fazer configurações específicas em cada servidor virtual (desde que o mecanismo de automatização estivesse desenvolvido), como tamanho máximo em disco, limite de banda, etc. Além disso, cada servidor virtual teria recursos de um servidor de internet, como servidor de páginas, de correio, de ftp, etc.
Tratarei aqui da capacitação tecnológica de empresa, e os recursos que oferecia para o desenvolvimento do projeto em questão.
Apesar de pequena, a empresa estava provida de boa capacidade técnica. Possuía link de acesso a internet (E1 canalizada, com 256kbps) próprio, roteador Cisco 2600, switch Intel 24 portas, no-break, 2 racks, com aproximadamente 10 máquinas, todas com HD scsi, e algumas com RAID 1. Sendo um provedor de internet, seus Access Servers não eram próprios, e estavam com a concessionária do link (Netstream). O que realmente faltava era redundância de link: como o produto era hospedagem, não poderíamos estar fora do ar em nenhum momento. Entretanto, isto não era a realidade: o link com a Netstream caía freqüentemente, e logo todos os domínios hospedados estavam fora do ar.
Tratarei aqui das tecnologias, ferramentas, sistemas e linguagens utilizados no sistema de hospedagem na época de seu lançamento até minha saída. Não sei o que permanece ou mudou, já que não acompanho mais o projeto.
O sistema operacional para todo o sistema era Linux, escolhido tanto por sua arquitetura, como pelos recursos oferecidos, além de ser GPL (GNU Public License). A base de dados, utilizada para se guardar informações sobre o sistema, assim como seu estado corrente, e dados de configuração, era MySQL, uma implementação open source de SQL, com vantagens e desvantagens.
O sistema em si não consistia em um programão só, mas vários programas ou scripts isolados, que juntos davam a funcionalidade desejada. Estes programas utilizavam Perl, BASH, Expect, e C. Basicamente, foi seguido o seguinte princípio em relação a linguagens:
Tarefas que necessitassem processar textos, ou fazer consultas a base de dados e posterior executar procedimentos, eram feitas em Perl.
Tarefas que necessitassem basicamente mexer com arquivos, fazer instalações ou inicializações, eram feitas em bash.
Tarefas que necessitassem interagir com outros programas eram feitas em Expect.
Tarefas que necessitassem rodar muitas vezes, e cuja performance fosse uma prioridade, eram desenvolvidas em C.
Como cada máquina possuía vários servidores virtuais, existia um mecanismo que direcionava cada requisição a um pseudo filesystem correspondente. Este pseudo filesystem era uma estrutura que simulava o sistema operacional e filesystem original, não permitindo que o usuário visse outros arquivos senão aqueles de seu servidor virtual (dando a impressão de ter um servidor de verdade pra si), mas ao mesmo tempo permitindo que use os dispositivos necessários do sistema operacional.
Exemplos desses desenvolvimentos, são o servidor POP (escrito em C), que foi bastante alterado para usar nossa base de dados, e o script de criação de um servidor virtual, que era um grande script (em bash) que fazia todas as configurações, criações de bancos de dados, definições de interfaces de rede, e criação do pseudo filesystem, entre muitas outras coisas.
Além disso, a rede que compunha os servidores virtuais possuía uma distribuição especial: saindo do switch, tínhamos um firewall que encaminhava os pacotes à rede correta. Além disso, este firewall era responsável pelo limite de banda para os servidores virtuais, isto é, limitar o fluxo de dados utilizados pela hospedagem de sites, a fim de que este serviço não prejudicasse os outros produtos do provedor. As máquina 'hospedeiras' possuíam RAID 1 (Rapid Access Independent Disc, nível 1) por hardware, que consiste em dois HDs, mas utilizando-se capacidade somente de um: caso este HD apresente problemas, o segundo assume, e tudo fica transparente para o SO (uma placa controla tudo isso). Além disso, elas possuem os sistemas instalados, e, via NFS (Network File System) elas enxergam as interfaces de administração, que estão fisicamente no firewall. Este método foi escolhido para que qualquer alteração na interfaces seja automaticamente aplicado a todos os servidores, aumentando assim a escalabilidade e facilidade de manutenções.
O sistema está pronto e em funcionamento desde fevereiro/2000. Descreverei neste item seu desenvolvimento, cobrindo todas as etapas da engenharia do software, mostrando como foram feitas, ou deixadas de se fazer. Também aproveito para explicar melhor o significado deste sistema.
Definidos quais seriam os objetivos do sistema, partimos então para o desenvolvimento. O departamento técnico se reuniu, e, com base nos objetivos (técnicos e funcionais), analisamos os requisitos. Esta fase de análise também foi uma fase de muito estudo: sabíamos o que queríamos obter, mas não sabíamos como chegar lá, e portanto não sabíamos o que seria necessário.
Primeiramente, devíamos saber que serviços estaríamos disponibilizando aos usuários, a fim de podermos analisar seus requisitos. Definimos que iríamos restringir ao máximo o usuário, visando a segurança de nossos servidores, mas sem deixar de lhe fornecer ferramentas para fazer toda a manutenção. Definimos então usar um banco de dados para armazenar dados, e que o usuário não poderia ter acesso shell na máquina. Todos nossos serviços deveriam usar o banco de dados para obter seus dados (configurações e autenticações), e esses serviços teriam que dar a impressão a usuário de que ele está em um servidor só dele, ou restringir sua visão a resto da máquina. Assim definimos quais serviços iriam rodar.
Em seguida, precisávamos descobrir uma maneira de se obter vários servidores de uma mesma máquina. Este howto nos deu uma ótima orientação, mas possuíamos situações particulares, que tivemos que analisar também. Além disso, para conseguir rodar esses serviços em pseudo filesystems (regiões 'enjauladas') do sistema operacional, precisávamos saber o que seria necessário, isto é, quais são as partes necessárias do sistema operacional para se fazer isso. Após definido o que seria preciso para construir estas regiões fechadas, e alguns testes muito superficiais (nenhuma implementação), conseguimos definir como os serviços iriam rodar em cada servidor virtual.
Definidos os serviços e os filesystems, precisávamos também saber o que seria necessário para a máquina poder receber conexões para diferentes domínios. Estudamos o assunto e verificamos que para cada servidor virtual deveríamos ter um IP diferente, mas dentro deste servidor, os domínios poderiam compartilhar este mesmo IP. Ademais, definimos que seria necessário um mecanismo de controle de banda (quantidade de informações trafegando) para cada servidor virtual, a fim de não prejudicarmos o conjunto.
Nesta fase também foram avaliadas as necessidades de linguagens de programação. Pensamos no que seria necessário programar e constatamos que tínhamos toda a habilidade e conhecimento para isso.
Além disso, precisávamos saber sobre a interação com o usuário, o que seria necessário. Definimos que seriam usadas páginas dinâmicas com PHP, fazendo consulta em nossa base de dados; mais detalhes resolvemos deixar para a fase devida.
Devido ao fato de ser um projeto novo, sem nada parecido já feito onde pudéssemos consultar, à nossa falta de experiência em desenvolvimento de projetos para poder especificar prazos, e ao ambiente da empresa, que estava sempre preocupada em resolver problemas imediatos, nunca pensando à frente, nunca foi estipulado um prazo para o projeto, nem para suas fases.
Mesmo sem cronograma estipulado, não tínhamos dedicação total ao projeto: éramos sempre interrompidos ou para atender as necessidades de um cliente do provedor, ou para termos reuniões sobre outros sistemas e projetos, sem se preocupar em estipular um cronograma e fases de desenvolvimento do projeto atual. Além disso, éramos sempre cobrados em relação à data de lançamento, o que prejudicava o projeto como um todo, pois isto priorizava a rapidez, e não qualidade.
No final, o projeto começara em outubro/1999 e a primeira versão do sistema entrou no ar em fevereiro/2000, um período pequeno, relativamente a um desenvolvimento de software deste gênero.
Devido à falta de maiores objetivos pré-definidos por parte dos superiores, utilizamos nossas idéias e nossa análise para definirmos a especificação do projeto. Com base nessas informações projetamos o sistema: definimos como cada módulo iria se comunicar com o outro, quais seriam as linguagens usadas em cada parte, como realizaríamos nossas tarefas (do ponto de vista técnico), e como tudo isso seria interagido com o usuário, tendo sempre em mente a segurança do sistema e a facilidade do usuário.
Foi nesta fase que nos deparamos com um problema: um serviço muito desejado pelos usuários de hospedagem de sites é poder fazer páginas dinâmicas, isto é, executar CGI (Common Gateway Interface) ou SSI (Server Side Include). Basicamente, isto significa rodar um processo no servidor que devolverá a página para o browser. Este processo pode fazer qualquer coisa, desde escrever em arquivos até consultar bases de dados; é um processo normal para sistema operacional. E aí está o problema: este processo poderia ser um perigo para a máquina, assim como para os outros servidores virtuais que estão na mesma máquina; ele poderia travar a máquina, ler dados de outros usuários etc. Pesquisamos muito na época, e percebemos que é um problema comum sem uma boa solução: ou confiaríamos nos usuários (não é suficiente, pois eles poderiam deixar descuidadamente um 'buraco', por onde terceiros poderiam entrar), ou não liberaríamos acesso (se quiséssemos ter controle sobre a segurança). Uma decisão difícil, pois optando em permitir a execução de CGIs, perdíamos em segurança, e em proibindo, perdíamos em clientes! Antes de tomar a decisão final, entramos em contato com a linuxcare e com o grupo que desenvolve o Apache (web server), e o PHP, pedindo sugestões e informações sobre futuros features de seus produtos; pouco adiantou. Finalmente, decidimos em fornecer aos usuários uma biblioteca básica de CGIs, contendo funções e programas muito procurados, e proibindo a execução de processos desconhecidos.
O primeiro item desenvolvido foi um script em bash que criava um pseudo filesystem, onde rodariam os serviços enjaulados (chrooted). Como a distribuição linux utilizada era RedHat, utilizou-se o sistema de pacotes RPMs como facilitador. Com os RPMs em mão definimos quais os necessários (bibliotecas, configurações, etc), e construí o script. Esse script também criava hard links com devices do sistema operacional, para que esses pudessem ser usados. Esse script foi sendo modificado ao decorrer do desenvolvimento, como descrito abaixo.
Em seguida, tínhamos que conseguir rodar esses processos enjaulados e conseguir acessá-los depois. Foi desenvolvido então um programa que, a cada nova conexão com a interface de rede, verificava para onde era destinado, pesquisava em uma base de dados qual o filesystem devido, e direcionava a conexão para o lugar certo. Como isso deveria ser muito rápido, foi desenvolvido em C, e depois otimizado.
O próximo passo era fazer com que uma mesma interface de rede (mesmo endereço MAC) pudesse responder por endereços lógicos diferentes (IPs). Isso era necessário, pois teríamos diversos servidores virtuais em uma mesma máquina, cada um com um endereço IP diferente, e somente uma placa de rede. Também, precisávamos do mecanismo de controle de banda. A solução foi recompilar o kernel com novas diretivas, utilizando então 'IP Aliasing' e 'Traffic Shaper', e fazendo algumas configurações.
Tudo isso pronto, era hora de se mudar o script de geração de filesystem, para que ele agora instalasse um servidor virtual, já alocando um endereço IP a partir da base de dados, levantando as interfaces de rede, os serviços, e estabelecendo a comunicação necessária com o mundo exterior. Agora, o script também fazia criação e inserções na base de dados, fornecendo assim as informações particulares sobre este servidor. Precisávamos também de um script que fizesse todas as inicializações necessárias nos sistemas instalados a cada vez que a máquina rebootasse, isto é, um script de inicialização de servidores virtuais. Este também foi desenvolvido em bash. Alguns outros scripts de inicialização foram alterados, para poder iniciar também os serviços virtuais.
Por fim, serviços que não rodariam enjaulados deveriam dar transparência total. Este era o caso do Apache (web server). Rodando um apache para cada servidor virtual iria consumir recursos demais, prejudicando bastante a performance e escalabilidade. Por isso, teríamos somente um apache, que iria responder por todos os domínios de todos os servidores virtuais da máquina. Para isso, foram usados módulos especiais, que permitiriam uma configuração mais rápida e eficiente, diminuindo o número de vezes necessários de se parar tal serviço, aumentando-se assim a performance e escalabilidade. Mais uma vez, o script de instalação foi alterado para fazer tal configuração.
O próximo passo, e muito importante, era desenvolver um sistema de quota de disco para os servidores virtuais; cada servidor teria um limite, que não poderia ser ultrapassado. A solução foi montar um 'quebra-cabeça` com usuários no sistema operacional e suas permissões, para que fosse usufruído o sistema de quotas que o kernel implementa.
Agora, o sistema estava praticamente pronto, só que não existia nenhuma interface com os usuários, por onde eles pudessem fazer suas configurações. Após algum planejamento de interface, criei o layout das telas que os usuários utilizariam, dando uma funcionalidade muito boa para a interface. Um ponto forte era que, além das telas não serem pesadas para se fazer o download, eram necessários pouca navegação para se fazer qualquer configuração. Neste ramo, isto é muito bom, pois geralmente os usuários estão com pressa e querem ir direto ao ponto. Dado o layout, fizemos a geração destas páginas com PHP. Fazer alterações que mexessem somente na base de dados era simples; já fazer alterações que necessitassem de outro tipo de alteração (configuração arquivo texto, criação de usuários no sistema, etc) necessitavam de scripts, chamados pelo PHP, que realizassem tais ações. Como muitas destas tarefas precisavam ser executadas como root, visando a segurança, desenvolveu-se scripts em expect que realizavam estas tarefas.
Posterior ao desenvolvimento desta GUI, o sistema foi considerado suficiente, e foi liberado para os usuários. Logo em seguida, mesmo sabendo das limitações sobre a execução de CGIs, os usuários começaram a reclamar, fazendo então com que o desenvolvimento tendesse para a elaboração da biblioteca de CGIs. Certo de que iria encontrar pronto, procurei na Internet e encontrei vários scripts básicos prontos, bastando uma configuração. Esta foi então a primeira tarefa designada ao Jeferson: customizar e adaptar os scripts, para disponibilizar recursos para os usuários trabalharem. Enquanto isso, problemas apareceram e era alocado para sua resolução, e então o desenvolvimento propriamente ficou estagnado.
Estando a situação controlada, sem muitos problemas acontecendo, me voltei ao desenvolvimento. Entretanto, era necessário o desenvolvimento de um sistema automatizado de cobrança, pois a maneira corrente era muito precária (o pessoal financeiro recebia por e-mail cada operação que um usuário executasse que implicasse em cobrança). Ao mesmo tempo, eu não poderia perder muito tempo com isso, já que eram necessários novos serviços e funcionalidades ao sistema de hospedagem. Bolei então um sistema, baseado em banco de dados (MySQL), onde sempre que uma ação implicasse cobrança fosse executada, um registro no banco de dados seria feito. Esse registro seria relacional com outras informações da base, como usuário, tipos de ações cobradas, plano de serviços, e valores por ação. Foi desenvolvida também uma GUI, por onde o pessoal financeiro colocaria a data de pesquisa, e receberia a cobrança deste período, em um formato compatível para a posterior geração de boletos bancários. Mais tarde, com algumas adaptações, este sistema se tornou também um controle básico de quanto dinheiro esta entrando na empresa, decorrente da hospedagem de sites.
Após este sistema, voltei a corrigir problemas no sistema de hospedagem e a fornecer novos serviços aos usuários.
Os testes seguiram um esquema bottom-up: a cada módulo, script, ou sub-sistema criado, aplicávamos uma série de testes para ver se obtivemos realmente os resultados esperados.
Seguindo o desenvolvimento, primeiramente testamos se o script de criação de pseudo filesystems funcionava em qualquer situação. Possíveis erros de programação foram sendo corrigidos durante os testes, aplicando-se novamente os testes, num esquema circular.
Em seguida, testou-se o programa responsável pelo direcionamento de conexões para os filesystems corretos. Primeiro testou-se somente com uma conexão, e depois fizemos um stress test, onde testou-se sua eficiência num ambiente concorrente e com a carga da máquina alta.
Seguimos a mesma idéia para as interfaces de rede virtuais: primeiro uma sozinha, de depois um stress test.
Para a criação de servidores virtuais, o teste foi mais longo, pois houve maior ocorrência de falhas de programação, além de parametrização de comandos para as diversas situações possíveis. Durante esta fase de testes percebemos também a necessidade de um script que desinstalasse um servidor virtual. Programei então tal script em bash, que desalocava o endereço IP do servidor, e liberando também qualquer recurso alocado.
Para o controle de espaço em disco, um stress test foi adequado, verificando se em condições adversas a quota era respeitada.
Devido à pressa para o lançamento, os testes com as interfaces foram bem superficiais, visando somente verificar se elas respondiam bem aos comandos dos usuários. Os scripts que eram chamados a partir desta GUI também foram testados neste modelo, sem muita preocupação em Ter certeza de que nunca falhariam.
Os scripts de nossa biblioteca de CGIs foram modificados e testados pelo Jeferson, e todos puderam passar por esta fase antes de sua liberação ao uso.
Como nota-se no texto acima, não foram feitos testes necessários no sistema como um todo, incluindo a GUI. Stress tests, verificações de caminhos de execuções levando em conta a interface com o usuário, assim como um estudo para tomar consciência dos limites do sistema seriam fundamentais para detectar e prevenir possíveis problemas.
Devido à grande cobrança e pressa da empresa, pouca documentação foi elaborada, sendo a maioria comentários em programa explicando como e o porquê do código.
Mesmo quando o Gustavo deixou a empresa, os responsáveis não tiveram interesse de se colocar no papel o projeto. Ao contrário, queriam que o sistema crescesse o mais rápido possível. Um exemplo disso é o fato de que só eu sabia as senhas de root das máquinas, do roteador e do switch até pouco antes de minha saída.
Quando eu deixei a empresa, o máximo aconteceu foi uma conversa com o Jeferson para ele se inteirar do projeto (até então ele só mexia nos scritps da biblioteca de CGI). Mesmo explicando tudo não foi possível ele absorver todas as idéias; nunca um projeto inteiro deste gênero seria compreendido em apenas uma conversa.
Mesmo com a falta de tempo para me dedicar a desenvolver melhorias e novos serviços ao sistema, eu tinha noção de algumas coisas que eram necessárias, e muitas vezes de como fazê-las. Citarei aqui alguns tópicos de serviços que faltavam ser incorporados/desenvolvidos/implantados, assim como de problemas que não estavam solucionados (alguns destes tópicos podem já terem sido desenvolvidos).
- Webmail
Como liberar CGI para usuários de maneira segura?
Sistema automático para controle de pagamentos (geração online de boletos, de verificação de pagamentos anteriores)
Melhorar controle de cota de disco.
Esse era um problema sério: após a instalação de um servidor virtual, possivelmente o usuário iria precisar de mais espaço em disco. Como poder sempre fornecer espaço a esse usuário? A máquina onde seu servidor poderia estar cheia; além disso, deveria ser previsto que o próprio sistema operacional necessitaria de espaço, para armazenamento de logs, arquivos temporários, etc.Melhorar controle de usuários no sistema
Melhorar sistema de automatização de serviços de web server
Sistema de auto-resposta de e-mails
Muitos usuários desejavam poder definir uma mensagem padrão que fosse enviada a quem lhes escrevesseAutomatização total dos serviços.
Muitos serviços ainda necessitavam de alterações em configurações (arquivos textos), reinicializações (deveriam ser executadas como root), ou seja, de ações que precisavam ser feitas para seu funcionamento que não eram simples ou imediatas. O ideal seria qualquer alteração fosse muito simples e erros desta alteração pudessem ser sempre detectados e rolled back, isto é, desfeitos.
Opiniões Pessoais
Irei tratar neste tópico sobre minha impressão da experiência, os pontos positivos e negativos, os desafios apresentados e frustrações encontradas, além das lições aprendidas.
Acima de tudo, esta experiência foi repleta de aprendizados, tanto técnicos como profissionais. Foi uma oportunidade única para se desenvolver um sistema grande e complexo do zero, vê-lo em uso, e posteriormente gerenciar e manter toda a estrutura criada para ele. Também, foi uma oportunidade para sentir de perto o mercado de trabalho na área de internet, e observar seu crescimento: o período em que trabalhei nesta empresa também foi o período de boom da internet no Brasil. Ao mesmo tempo, pude perceber que no mundo real, fora da faculdade, as pessoas com quem você trabalha não são iguais a seus colegas de curso; estes, por menor experiência profissional que tenham, entendem muito bem como deve ser feito o desenvolvimento de software. Além disso, o fator financeiro não tem a importância no meio acadêmico que tem no mercado: as pessoas fazem coisas visando somente o lucro, e este tipo de atitude muitas vezes dá errado.
Quando entrei na empresa eu já trabalhava com Internet há um ano, mas o meu forte mesmo era a parte de programação. Como a empresa era pequena e éramos duas pessoas no departamento técnico, tinha que fazer tudo: desde a programação de páginas até a configuração do roteador. Isso foi muito bom para meu aprendizado, pois o tipo de coisas que aprendi lá eu só teria aprendido em uma oportunidade dessas, e esses conhecimentos adquiridos são importantes e valorizados pelo mercado. Além disso, pude colocar em prática muitas coisas, e desenvolver muitas outras do zero, exercitando assim o raciocínio e praticando um desenvolvimento de software fora do meio acadêmico. Mesmo tirando muitos benefícios desta experiência (aprendizados, experiências, etc), eu contribuí muito também, já que desenvolvi o sistema para a empresa, o que trouxe muitos clientes, e que foi uma alternativa à falta de mercado para o acesso discado depois dos acessos gratuitos.
Apesar da experiência ter sido muito construtiva, tem um lado negativo muito grande também, e que me levou a deixar a empresa. Todos os problemas basicamente se originavam da falta de experiência da empresa ou seus dirigentes em Internet e desenvolvimento de software. Não houve planejamento algum da empresa: não montaram nenhum cronograma, lista de requisitos do sistema, nem uma descrição específica do que queriam; o máximo foi passar uma URL de um sistema destes nos EUA e dizer que queriam um sistema semelhante. Sem cronograma em mãos, éramos interrompidos toda hora para discutir outros projetos (mesmo estando longe de finalizarmos esse e de sermos apenas duas pessoas que não se dedicavam período integral!), para fazermos manutenção no provedor, e para sermos cobrados sobre o sistema. A sala em que trabalhávamos também não era adequada: havia muito movimento, impedindo a concentração para a criação; após algum tempo mudamos para uma outra sala, onde não havia muito movimento, mas onde o telefone não parava de tocar. A cobrança era enorme: o diretor dizia que a estrutura toda era cara, que precisávamos do sistema, etc. Na verdade, o problema era que ele é/era uma pessoa que não é do ramo e não entende como as coisas funcionam, que para funcionar corretamente devemos fazer realmente um controle de qualidade no software; ele só havia entrado nesse mercado visando o lucro, sem conhecimento algum. O estresse gerado por isso era enorme.
Essa enorme cobrança acabou gerando problemas, como era de se esperar: o sistema entrou no ar sem finalizarmos os testes, o que resultou em muitos problemas com os clientes. Nesse começo de uso do sistema, não havia suporte capacitado, por isso muitas coisas paravam em mim. Aconteceram coisas piores ainda, como ter que colocar um servidor incompleto no ar e depois ter que passar a noite toda consertando um problema.
Mesmo no lado negativo acredito que houve aprendizado: aprendi como deve ser um ambiente agradável para o desenvolvimento de sistemas, e como gerência qualificada na empresa faz diferença. Como disse, esse ambiente desagradável acabou me desmotivando, e me levando a deixar a empresa.
A Universidade e o Mercado
Apesar de um título muito abrangente, vou tratar neste tópico qual foi a relação observada entre esta minha experiência profissional e o que aprendemos e vivemos na faculdade (IME).
Este projeto que desenvolvi foi muito rico em aprendizado, assim como em aplicações de conhecimentos. Nele, eu pude colocar em prática muitas coisas aprendidas na faculdade, e agregar muitos outros conhecimentos. Como é um sistema diferente do que existe, e como não tive outro igual para me basear, muitas vezes me deparei com um obstáculo técnico em seu desenvolvimento. Nessas horas acredito que o curso fez a diferença: as idéias surgiam facilmente, e conseguia ter um raciocínio muito rápido e elevado, podendo atender as exigências da empresa (que podem ser consideradas as exigências do mercado), e desenvolver um produto de qualidade. Além disso, tive que aprender sozinho muitas coisas, tarefa que não foi difícil graças à experiência acadêmica.
Este projeto envolveu substancialmente sistemas operacionais, redes de computadores, linguagens de programação, bancos de dados, engenharia de software, entre outras áreas. Preocupações com a concorrência das aplicações também era fundamental, assim como com a corretude e eficiência de códigos.
Em suma, o alto grau de raciocínio e auto-aprendizado adquiridos na faculdade foram importantíssimos para o trabalho. Diria que foram até mais importantes que os próprios conhecimentos, pois eles são o alicerce de todos os outros conhecimentos que possuíamos e que ainda vamos adquirir.
Conclusão
É necessário sempre se tirar alguma coisa de uma experiência: algo que não se deve fazer, ou algo a se repetir. É necessário refletir sobre experiências (principalmente profissionais), admitir erros próprios e se preocupar em melhorar, procurando sempre um bom ambiente de trabalho, onde você possa crescer.
Em minha opinião, o estágio deve ser uma fase acima de tudo de aprendizado. Uma fase sem grandes responsabilidades profissionais, onde estudantes possam contribuir ao mercado com conhecimentos acadêmicos e dedicação; em retribuição, as empresas devem fornecer um ambiente agradável, onde ele possa aprender e crescer, para futuramente poder contribuir mais. Dado este fato, acredito que o estágio não deve ser em hipótese alguma mão-de-obra barata: empresas não deveriam procurar estudantes para isso e estudantes não deveriam aceitar tais condições. É claro que a necessidade fala mais alto, mas o estudante deve preocupar-se ao máximo em aproveitar a época de faculdade sabendo que existe o momento de curtir e estudar, e que depois existirá também o momento de trabalhar.
Muitas vezes, um ingresso precoce ao mercado atrapalha a formação do estudante. No meu caso, não aconteceu somente devido à minha força de vontade: eu comecei a trabalhar no 2º ano (época muito exigente do curso), e fui o único que conseguiu levar tal rotina ininterruptamente até o final. Ganhei em experiência profissional e em conhecimentos, mas percebi que deixei de aproveitar muitas coisas; o estresse era muito grande, e não era necessário eu passar por isso na época. Ao mesmo tempo, consegui um boa posição profissional mesmo antes de formado. Acredito que não é uma decisão fácil, e cada um deve tomar a sua. Mas uma coisa tenho certeza: nunca se deve deixar os estudos de lado devido ao trabalho que apareceu. Os trabalhos e tendências vêm e vão, e se você não possuir uma boa formação acadêmica você ficará logo desatualizado e perdido.
Meu conselho aos alunos dos outros anos é não acumular repetências, estudar bastante, para que quando a época chegar, seja possível se dedicar ao trabalho e poder exigir posições mais justas dentro do mercado.