Recebi um bocado de feedback de outros sysadmins sobre o post anterior via twitter ou IM. Se quiserem postar aqui as respostas mais gente vai poder ver.

Minha experiência pessoal é como sysadmin de redes (na época basicamente com equipamentos Cisco) e com Linux/Unix. Mas certeza que a idéia geral serve pra quem pensa em seguir carreirar como Sysadmin Microsoft, Oracle ou qualquer outra variação.

Já pegando o gancho aqui vale a pena citar o seguinte: Quanto mais especializado você for melhor você vai ganhar e menor vai ser o mercado de trabalho.

Explicando: Não tem muitos sysadmins especializados em deployment de super-computadores híbridos para análise meteorológica. Esses caras ganham uma boa grana. Mas em compensação quantos super-computadores tem por ai? Você precisa se decidir o quão especialista quer ser e definir seu plano de carreira.

Independente de que tipo de sysadmin que deseja ser existem algumas coisas que, no meu ponto de vista, são extremamente básicas e já vi muito nego que dá carteirada com certificação passando de otário por não saber o básico.

Redes

IMHO a primeira coisa a se saber é redes. TCP/IP. Não perca tempo com outras tecnologias se não pretende ser sysadmin de rede. (Vale ressaltar aqui que eu estou em dívida comigo mesmo por ainda não ter estudado IPv6 à fundo).

A impressão que eu tenho é que um sysadmin que não sabe rede é como um médico que não sabe dividir o corpo humano em cabeça, tronco e membros. Mas acredite, isso acontece direto. Quando eu trabalhava com redes era ocorrência diária o time de Windows ou Unix mandar chamados de “problema de rede” dizendo que o serviço X ou Y não estava acessível, mas “o servidor está OK”.

Não precisava mais do que 5 minutos de troubleshooting pra descobrir que o serviço não estava rodando, que estava dando connection refused, o processo dava reset na conexão ou outra coisa qualquer, totalmente não-relacionada a rede. Faça um favor para você mesmo e evite pagar de otário aprendendo a utilizar ping, netstat, route.

E sysadmins Microsoft em geral parecem ter um especial dificuldade em entender o conceito de “default gateway”. Então se você for trabalhar com MS e souber isso, já largou na frente.

Troubleshooting

E falando em troubleshooting eu deveria ter começado é com isso. Capacidade de efetuar troubleshooting é simplesmente a mais importante qualidade na vida de um sysadmin.  E eu penso que “troubleshooting skills” nada mais é do que apenas um nome chique pra “bom-senso”, então todo mundo deveria ter, mas 30 segundos na Internet me mostram que isso não é bem verdade.

Apesar de ser uma coisa que eu considero como um talento nato o mesmo com certeza pode e deve ser melhorado. Ao invés de fugir de problemas encare-os de frente e tente resolver todo tipo de pepino que aparecer na sua frente. Faça uma Wiki pessoal utilizando algo como o Google Notebook ou TiddlyWiki e mantenha registro de como solucionou problemas. Estude estratégias de resolução de problemas, como a minha favorita Divide and Conquer, e lembre-se sempre que você não é tão especial quanto você acha. Grandes chances de alguém já ter tido o mesmo problema que você está tendo. E nesse caso o Google é seu amigo. Aliás, seguindo o link que o Andreyev postou aqui, aprenda a usar o Google direito!

As bases

Então considerando que você já está OK com os dois pontos anteriores, vamos falar da sua área de atuação. E aqui vou usar meu exemplo pessoal como sysadmin Linux.

Antes de sair por ai assinando seu email como sysadmin e tomar uma bofetada como essa, conheça muito bem as bases e raízes do sistema. Saiba a diferença entre sistemas derivados de System V e BSD, leia e aprenda a maior quantidade de comandos que conseguir.

Conheça a estrutura de diretórios Unix e o Filesystem Hierarchy Standard .

Deixe de ser fan-boy de distribuição, já que um bom sysadmin Linux deve ser capaz de sentar na frente de um console, determinar que distribuição está rodando e sair trabalhando. E sim, Ubuntu é lindo, fácil de instalar e cheio de aplicações (eu mesmo uso), mas o fato de você ter ele instalado em dual-boot no seu micro de casa a 6 meses não te qualifica como sysadmin.

Hoje em dia sou preguiçoso, mas no passado já fui mais ativo e perdi as contas de quais distribuições usei. Cheguei a ter uma máquina de teste onde toda semana eu instalava algo diferente, como TurboLinux e Progeny. Sempre um exercício interessante.

Considere usar algo um pouco mais baixo-nível por um tempo, como Slackware ou Gentoo, mas do ponto de vista comercial preocupe-se mesmo com RedHat, SuSE e Ubuntu. Aliás, minha experiência corporativa até o momento diz que a RedHat reina absoluta. Estudar essa distribuição em particular é interessante. Use o CentOS caso, como eu, não tenha US $800 sobrando pra comprar uma licença.

Aprenda a compilar um kernel, compilar pacotes, utilizar gerenciadores de pacotes, e instalar módulos do Perl ou Ruby via CPAN ou Gem.

Por favor, aprenda permissões e saiba parâmetros do chown e chmod. Utilizar o sudoers e saber da existência do /etc/securetty também não machuca ninguém. Não rele no /etc/passwd via editor de texto, mas se realmente não tiver outra opção utilize o vipw!

Scripting

Fato: Mais cedo ou mais tarde você vai precisar criar um script pra alguma coisa. Por isso aprenda shell script muito bem. Eu diria que é um diferencial excelente na hora de procurar emprego. Mas nada de aprender mais ou menos e sair cantando de galo por ai. Saber fazer um “pipe grépe” não é escrever shell script.

E uma coisa que acompanha shell script tão bem quanto café acompanha leite é expressão regular. Poucos sysadmins conhecem regex e a vida é MUITO, MUITO mais fácil com ela.

E se quiser ir um pouco mais fundo (dica: sempre queira), aprender um outra linguagem mais complexa é sempre interessante. Pessoalmente escolhi Python, mas conheço também um pouco de Perl e gostaria muito de ter tempo pra estudar Ruby. Essas linguagens mais complexas e cheias de recursos podem acabar facilitando sua vida reduzindo a quantidade de código que precisaria para fazer a mesma coisa em Bash, por exemplo.

E aqui vale enfatizar: Não invente moda. Nada de criar um script gigante e cheio de frescura se puder resolver o problema só um find -exec.

Seja preguiçoso

Isso mesmo. Pense sempre o seguinte: Como eu consigo executar essa tarefa com o menor esforço possível? Ou então: Como eu posso automatizar essa atividade pra não precisar fazer isso todo dia? E ainda: O que eu posso fazer pra parar de ter esse problema e nego me enchendo o saco todo fim do mês?

Lembre-se que o at, a crontab ou outros schedulers são seus amigos. Criar um daemonzinho utilizando um shell script também pode ser uma saída para algumas coisas.

E caso precise fazer algo que realmente não possa ser 100% automatizado faça uma excelente documentação do processo e deixe em algum lugar disponível para consulta não só sua como de qualquer outro colega. Assim a próxima vez o processo pode passar para mãos mais inexperientes ou simplesmente pra quem estiver disponível. Não precisa ser necessariamente você.

E por falar em preguiça, por hoje chega.

Estávamos já 21hrs passada de pijama assistindo nossa AppleTV quando o telefone toca: O on-call me ligando. Isso não pode ser bom. Mas rapidamente me lembrei que não tinha recebido nenhum alerta do ipmonitor e não tinha visto nenhum email da empresa de after-hours até o momento. Eu teria visto, já que eles chegam no meu android, que estava na minha mão na frente da TV… Isso tudo passou pela minha cabeça num segundo apenas e atendi o telefone tranqüilo. Afinal já tinham me ligado outras vezes pra pedir dicas de restaurante, por exemplo.

- Alô, Eri… desculpa incomodar, mas a empresa que monitora nossos alarmes acabou de ligar. Parece que alguém tentou roubar o escritório.

Wow! Nunca esperava ouvir isso, por um um momento me lembrei da última vez que recebi uma chamada parecida, lá pelos idos de 1999/2000 quando ainda trabalhava com meu pai. Quando chegamos no escritório após uma ligação da polícia não tinha sobrado nada.

- Como assim? O que aconteceu?

- Pois é. Não sei direito. Eu esqueci minha senha e a pessoa no telefone falou que não podia dar detalhes se eu não confirmasse minha identidade com a senha. Mas liguei pro gerente de desenvolvimento, que está ligando pra eles agora e me pediu pra ligar pra você enquanto isso.

- Tá legal. Vou ver isso.

Ligo pro outro gerente:

- E ai? Que diabos tá acontecendo?

- O sensor de quebra de vidro disparou. A empresa mandou a polícia pra lá e vai me ligar de volta. Mas imagino que não seja nada. Já tivemos problemas com esses sensores no passado. Estou achando que vamos tomar multa****.

Quando ele falou isso eu fiquei sossegado e voltei a ver TV. Nisso meu Android bipa. Eu olho e tem um email da empresa de after hours. Que diaxo? Abro o email:

“Client Name: Halifax Regional Police”.

“Problem Description: Someone tried to brake in. Please, call”

“Call Dispatch: Delivered to On-call”

Um minuto depois meu telefone toca. O on-call meio assustado…

- “Eri… A polícia ligou. Tentaram roubar mesmo. O vidro tá estourado, eles falaram que precisa ir alguém lá”

DROGA. Eu já sabia que o outro gerente não estava em casa, que é um pouco mais perto do que a minha do escritório. No meio tempo ele já tinha tentado ligar pro nosso chefe, mas não tinha conseguido… Conversamos rapidamente e ele ficou de pesquisar algum serviço de reparação de vidro 24×7 e tentar falar com o chefe enquanto eu ia pro escritório.

Como não sou bobo achei que era melhor não ir sozinho e peguei o Hurd pra me acompanhar.

Agora uma rápida explicação de como é o escritório: É de esquina, dentro do que chamam de “business park”, que nada mais é do que um tipo de Mall recheado de escritórios.

O detalhe é que exceto pelas colunas de sustentação tudo é de vidro. De cabo-a-rabo. E lá dentro todas as áreas tem gente trabalhando perto das janelas, então passando da rua você vê facilmente todos os desktops, monitores e hardwares esquisitos que temos por lá. E na recepção tem 2 laptops e vários equipamentos interessantes para um eventual gatuno. A menos de 2 metros de distância do vidro.

Lógico que alguém bateu o olho naquilo e pensou: Há! É só tacar uma pedra no vidro, agarrar os laptops e sair correndo. Os gênios só não contavam que a segunda camada de vidro (usada pra isolamento térmico) não ia arrebentar. E o alarme ia disparar…

O resumo da história e a conclusão que eu chego é: Foi só um susto, ladrão canadense é amador pra cacete (porquê não jogaram uma segunda pedra quando estouraram o primeiro vidro e levaram o laptop pelo menos? Iam perder o que? Mais 30 segundos?), a empresa de segurança é competente e a polícia chegou rápido. E ainda ligaram pro suporte e abriram um chamado!

Só não sei se fecho como “Fixed” ou “No Issue”.

*** Se você chama algum serviço de emergência por aqui e é constatado alarme falso você toma uma “advertência” da primeira vez e multa em todas as próximas.

Mediante ao cumprimento de uma grande meta, o líder desejou comemorar o fato presenteando seus liderados com uma sobremesa especial. O chefe chamou o AGUIAR, seu funcionário, e lhe deu a seguinte tarefa:

- Aguiar, por favor, vá até a feira e compre laranja, melão e pêssego, pois quero fazer uma grande salada de frutas como sobremesa para comemorar nosso sucesso.

Aguiar correu para a rua e foi até a feira e trinta minutos depois voltou ao seu líder e disse:

- Chefe, a laranja havia acabado, o melão está fora de época e o pêssego não estava com uma boa aparência. Achei melhor não comprar.

O líder um tanto frustrado, agradeceu o Aguiar e chamou Carlos, outro funcionário da empresa.

- Carlos, por favor, vá até a feira e compre laranja, melão e pêssego, pois quero fazer uma grande salada de frutas como sobremesa para comemorar nosso sucesso.

Note que foi pedido a Carlos a mesma coisa que foi solicitada a Aguiar, mesmo sabendo que haveriam os mesmos problemas ditos anteriormente.

Carlos correu para a rua e foi até a feira e trinta minutos depois voltou ao seu líder e disse:

- Chefe, a laranja havia acabado, o melão está fora de época e o pêssego não estava com uma boa aparência. Achei melhor não comprar. Mas ví que o abacaxi estava bom, o morango com ótimo preço e a banana muito apetitosa. Peguei o celular do feirante e caso o senhor aprove ligo para ele e solicito que entreguem para nós.

Como profissional eu sempre tento ser pró-ativo, procuro me envolver em projetos complicados que ninguém tem interesse e procuro dar o máximo de mim em todas as situações. Até o momento tenho sido bem sucedido com essa abordagem, mas pela primeira vez achei um livro que reflete exatamente como me comporto. E aparentemente estou no caminho certo.

Não sei a experiência de vocês, mas algo que me incomoda muito é ver uma coisa sendo feita de um jeito defeituoso, complicado,  caro, complexo ou demorado demais só porque sempre foi feito daquela forma. E ninguém nunca toma a iniciativa de resolver aquele problema.

Ah, meu amigo… Na minha mão essas coisas não duram não.

Eu gosto muito de aprender pelo exemplo dos outros e caso alguém ai também goste vão aqui dois exemplos de coisas simples que eu fiz no  passado que fizeram uma imensa diferença profissional no futuro.

A primeira foi num banco onde trabalhei. No meu segundo dia lá o sujeito que eu estava substituindo apareceu para assinar uns papéis no RH e veio conversar comigo. Falou que o principal sistema do banco (Java-based) rodava em um servidor lá num canto do CPD e que ele caia pelo menos 2 vezes por dia. Minha principal responsabilidade na empresa seria ficar de ouvido e assim que alguém gritar que o sistema caiu sair correndo, entrar na sala dos servidores e rodar uma série de uns 10 comandos no shell para restaurar o sistema.

Dito e feito, naquele mesmo dia antes do final do expediente caiu o maldito e toca eu correr pra arrumar. Eu nem sabia o que estava fazendo, só sei que tinha uma série de comandos a serem executados. Mas ali mesmo já fiz uma melhoria. O cara digitava todos os comandos, demorando uns 2 ou 3 minutos para recuperar o sistema. Eu comecei só apertando flecha pra cima e usando o history. Já abaixei pra um minuto, mas ainda não tinha idéia do que rolava. Nem sabia que raios era aquilo.

Depois de um mês mais ou menos de casa (e muitas corridas minhas e dos meus colegas pra dentro do CPD) eu comecei a entender. A aplicação feita em Java rodava em um container proprietário. Um container que o banco pagou uma fortuna para ter. E era uma versão com uns 4 ou 5 anos de idade, cheio de bug.

Comecei a fazer amizade com o pessoal de desenvolvimento e descobri que como ambiente de desenvolvimento cada um rodava uma instância de Tomcat no seu próprio desktop e que nenhum deles tinha os problemas que apareciam em produção.

Lógico que cheguei pro meu chefe e sugeri migrar para Tomcat. E lógico que a resposta foi não.

Bom… ai entrei no modo black-ops e sorrateiramente instalei o Tomcat no servidor, mas numa porta alternativa e deixei rodando, sem ninguém acessando, por uns 2 ou 3 dias. Depois conversei com uns usuários que trabalhavam no meu andar e alterei o bookmark deles para acessar a minha instância do Tomcat por padrão ao invés do default. E eles rodaram felizes e sem quedas por mais de semana.

Nisso eu já me preparei, arrumei uns scripts num canto e numa segunda-feira assim que o sistema default caiu eu subi o Tomcat no lugar dele. Sem dó nem piedade.

Ao invés de cair 2 vezes por dia o sistema passou a cair só 2 vezes por semana. Rodando mais rápido e bem mais confiável. E eu quieto.

Com quase um mês com a coisa rodando eu chego pro meu chefe e falo: Reparou que o sistema parou de cair? Viu como está mais rápido? (Alguns usuários tinham até elogiado). Pois é. Instalei o Tomcat.

Fui elogiado e reconhecido apesar de ter desobedecido ordens pois resolvi um problema enorme da empresa sem nenhum custo e excelente resultado. Fiz o que precisava ser feito no melhor interesse da empresa e de mim mesmo, afinal não sou bombeiro para sair apagando incêndio.

Quase um ano depois acabei também descobrindo porque raios o sistema ainda caia uma ou duas vezes por semana: O servidor era um hardware RISC cuja última versão de Java disponível era 1.3 e os programadores estavam desenvolvendo o sistema em Java 1.4. Quando algumas rotinas eram chamadas elas simplesmente abendavam o container. (Não lembro ao certo os números das versões, mas era algo assim).

A segunda história foi quando eu trabalhava no meu primeiro emprego numa mega-empresa sendo recurso dedicado para um cliente que era outra mega-empresa.

Nosso time de brasileiros foi contratado para substituir um time de americanos. A gente custava menos de 1/4 do que eles custavam então rolou um outsource.

Parte de nossas atividades era uma vez por mês fazer um relatório de capacity planning para as localidades pelas quais éramos responsáveis e apresentar para os administradores dessas localidades.

Para fazer isso tínhamos uma planilha excel onde importávamos gráficos do Orion de cada localidade. Eram uns 4 ou 6 gráficos para cada localidade, umas 20 ou mais localidades para cada um dos 10 membros do time.  Eram umas 4 horas de trabalho gerar a planilha. Um total de 40 horas-homem cada mês só pra preparar o relatório.

Depois de uns 3 ou 4 meses fazendo esse treco eu cansei. Trabalho duro e chato demais. Não é possível que não tivesse um forma melhor de fazer aquilo.

Gastei então 2 dias inteiros (16 horas/homem) aprendendo como fazer macros em Excel e fiz um script que era capaz de gerar todos os gráficos sozinho, conectando no Orion e puxando o que fosse necessário. Arrumando fontes, cores, tudo do jeito que o povo estava acostumado.

Joguei na mão do meu time e todo mundo adorou. Criar o report então passou a ser uma atividade de 15 minutos (2.5 horas-homem/mês).

Isso, juntamente com outras inovações que o time trouxe em relação ao que os americanos faziam, nos renderam um prêmio e mais tarde eu consegui ser transferido para um outro departamento para onde eu sempre quis ir, exclusivamente dedicado a projetos.

Em nenhum dos dois casos ninguém me pediu para fazer nada. Não fazia parte das minhas atividades normais e, potencialmente poderiam até me prejudicar (quem sabe demitido no primeiro por desobedecer o chefe ou despedido no segundo por não ser mais necessário).

Eu já trabalhei com pessoas que pensam que não devem automatizar procedimentos pois não poderão mais justificar sua presença “se não tiverem o que fazer”. Outras não criam documentação nem procedimentos na esperança de se tornarem insubstituíveis.

Na minha humilde opinião qualquer trabalho que possa ser automatizado não vale a pena ser feito manualmente logo de cara. Se seu trabalho constitui-se apenas de coisas de um script poderia fazer melhor e mais rápido do que você faz seria uma boa idéia começar a procurar um novo emprego. Eu já fiz isso e não me arrependi. Automatizei todas as minha tarefas e pedi demissão. Todo mundo ficou feliz. Meu ex-chefe e eu.

E no segundo caso comento duas coisas:

• Ninguém é insubstituível.
• Quem é quase insubstituível é 100% impromovível.

Se você não tem uma atitude profissional do tipo “faça o que tem que ser feito” leia o livro e pense na sua carreira.

Você gastou 40, 80, 120 horas da sua vida juntando informações relevantes e tecnicamente acuradas e os imbecis escolhem o que? A mesma solução que eles queriam desde o começo, mas para manter as aparências de que estavam realmente analisando o mercado te mandam fazer papel de idiota pesquisando.

Ter solução errada enfiada goela abaixo é duro, mas muitas vezes temos que aceitar. Dentro dos limites, é lógico.

Quem acompanha o blog há mais ou menos um ano acompanhou meus posts metendo o pau no meu emprego antigo, mas vou contar o que realmente engatilhou minha saída. Eu estava trabalhando num projeto para implementar uma collaboration suite que iria substituir o atual sistema de email.

Junto com mais um colega passamos infinitas horas fazendo laborátorios, lendo, estudando, implementando testes, juntando fatos, preços, informações, participando de webinars e conference calls e recrutando pessoas para testar as opções (sendo que a última coisa foi realmente o mais difícil).

Depois de muito trabalho mandamos um relatório completo, com nossa recomendação, para nosso gerente – que encaminhou para o diretor. Ficamos sem ouvir nada a respeito até um dia que o meu gerente me chama para “falar 5 minutinhos” numa reunião.

Chegando lá estavam reunidos na sala o diretor e todos os gerentes de IT: Rede e Servidor, Desenvolvimento, Web, Desktop, Audio e vídeo e suporte. Todos eles haviam sido convidados para participar dos testes, mas nenhum se deu ao trabalho de fazê-lo, que fique claro.

Quando entro o diretor me faz algumas perguntas sobre o relatório, tira 2 dúvidas tão idiotas que percebi na hora que ele não tinha entendindo lhufas e então ele vira pra mim e diz: “Obrigado. Você pode ir. Agora nós podemos continuar a discutir qual ferramente escolher nós mesmos”.

“OPA! Como é que é, meu chapa? Eu ralei igual um FDP e conheço esses sistemas por dentro e por fora, sei todas as features, limitações e parâmetros de linha de comando de cada uma das opções e você, que não sabe nem fazer uma pergunta e essa cambada de gerente incompetente, que não perdeu 5 minutos para olhar os pilotos que configurei, estão me dispensando pois acham que são capazes de decidir por vocês mesmos? Tá de brincadeira?” – Pensei.

Basta dizer que 2 semanas depois eu tinha conseguido uma entrevista e em mais 2 semanas estava começando o novo emprego.

Ainda não posso cantar vitória no emprego novo, mas estou bem mais confiante de que meu tempo está sendo bem investido dessa vez.

A procura agora é diferente: Storage. Qual a melhor opção para o nosso caso? Para o cenário da nossa empresa?

Logo que cheguei meu chefe tinha uma idéia do que ele queria (Equallogic). Eu analisei, li um pouco e logo achei que não era a melhor opção. Já escaldado do emprego antigo quase não falei nada, mas achei melhor comentar que eu tinha outra idéia que deveríamos testar (NetApp).

A surpresa foi que, na semana seguinte, ele já tinha marcado com o representante da idéia que eu dei e conseguimos um FAS 2050 emprestado por um mês para analisar e fazer os testes que me dessem na telha.

Essa semana expira o mês e eu já fiz meu relatório e entreguei para o chefe. E na quarta-feira temos reunião com a NetApp. Provavelmente não vamos ficar com a solução.

Mas dessa vez não porquê vou ter que engolir uma solução que não escolhi. Dessa vez vai ser porquê eu pude comprovar através de muitos testes que a solução simplesmente não vale o investimento.

Não temos tamanho, necessidade ou grana para gastar numa caixa NetApp e, exceto se eles arriarem as calças e derem um desconto MUITO bom, vai rolar um “thanks, but no thanks.”

Como eu disse, ainda não posso fazer a dancinha da vitória, pois não sei se vamos realmente adquirir a solução que eu recomendei no final das contas. Mas que a sensação de poder descartar minha própria sugestão baseado em méritos do produto e não em politicagem é sensacional, isso é.

ps: Para quem ficou curioso, minha recomendação é baseada num Dell Power Edge R610, um Dell Power Vault MD1000 e Solaris 10 (ZFS, baby).

Fato: Eu sou preguiçoso pra cacete e odeio trabalho repetitivo. Logo, automatizar é preciso. As coisas que automatizei eu raramente precisaria fazer eu mesmo, já que tem o pessoal mais júnior pra fazer. Porém se eles estiverem fazendo esse trabalho chato e tedioso, outras coisas chatas e tediosas iam sobrar pra mim. E projeto, que é legal, vai ficando pra depois. Entenderam onde quero chegar?

O problema é que a empresa é pequena. Com 2 semanas de casa automatizando coisas já corria o boato que “o cara novo manja muito de script”. E ai, como diria o Dilbert, bate a maldição de ser competente.

90% dos negócios da empresa estão em cima do principal software, logo tem uma equipe de desenvolvedores que é praticamente metade dos funcionário da empresa. E eles estão atolados até a alma de coisa para fazer. Mas surgiu uma necessidade urgente (uns 3 meses atrás) de fazer parse em uns arquivos para analisar os dados e até então ninguém tinha nem olhado. E deram previsão de mais 6 meses antes de ter tempo de olhar.

O gerente de contas do cliente então chega pro cara novo (aka esse que vos fala) e pede: Será que você pode dar uma olhada? Hum… desenferrujei um pouco do Python e fiz o treco pro nego. A lógica é de pobre, mas é limpinha. Funciona e é o que interessa.

Mas e ai? Ai que ele ficou tão feliz que foi falar com o meu chefe se ele não me “emprestava” pra expandir o projeto, fazer sistema de relatorio, analise anti-fraude, transferência de arquivo…

Resumindo… caiu a casa pro meu lado. Vou passar um bom tempo agora em projeto de desenvolvimento. Mas eu vou armado, parceiro. E de farda preta:

Python

Meus caros leitores desenvolvedores, se preparem… porquê vou encher o saco de vocês com perguntas. Posso não ser programador, mas conheço um monte deles. E, pelo menos eu espero, vou conseguir tocar um projeto inteiro sozinho. Quem diria… Eu, programador.

A infra-estrutura proporcionalmente ao tamanho da empresa é bem grande. Como fazemos host de aplicações para clientes e o número de clientes é grande acaba que temos mais servidores do que funcionários na empresa.

Com exceção de dois servidores Windows 2003 (que até o momento não me arrisquei a perguntar quem é o “pai”, mas acho que sou eu mesmo) o resto é tudo nosso good old fellow, o Linux.

Pelo que eu entendi o cara que eu estou substituindo tinha muitos e muitos anos de empresa, mas pouca experiência com Linux. Aparentemente ele aprendeu meio que na marra, implementando o ambiente quando decidiram migrar para Linux – ah, sim… fuçando numas gavetas achei uns CDs de SCO Unix… – então a implementação não é lá um exemplo de primor.

Espero amanhã já ter acesso nos servidores para olhar uns scripts referenciados na documentação. Uma das melhores formas de ver o quanto um sysadmin conhece do barato é olhar os shell scripts dele. IMHO.

O ponto alto do dia foi descobrir que tenho uma sala. Depois de mais de 10 anos trabalhando em balcões e baias cada vez menores tenho agora uma sala só minha! MINHA! MINHA!!! MMMHUUUAAAAAAHUHAAA!!!!

Além disso já conheci também minha equipe, o pessoal nível júnior e intermediário que vou liderar. Parecem ser gente boa. Obviamente precisando de uma lapidada, senão já seriam senior e eu não precisaria estar lá, mas acho que têm boa vontade.

Aparentemente o ambiente é razoavelmente homogêneo, o que facilita meus planos de dominar o mundo data center. Já fazia um tempo que estava procurando uma oportunidade de usar o Puppet e acho que agora vai rolar.

Meu chefe é gente boa e aparentemente manja pra cacete. Isso é bom pois vai saber dar valor ao meu trabalho e entender as minhas propostas, mas vou precisar ficar o dobro de esperto pra não dar mancada.

O que ficou um pouco a dever foi meu notebook. Um monstro de 17” que tenho a impressão não vai caber na minha mochila. Mas o chefe já avisou que é temporário. Logo devo receber um menor e mais novo. O smartphone eu pude escolher entre um Palm Treo rodando Palm OS ou um BlackBerry. Como peguei birra do BlackBerry no último trampo optei pelo Palm. Vamos ver se vou me arrepender.

A única coisa que vou evitar no começo é abrir email pessoal, twitter, etc nos primeiros dias. Pelo menos até entender a política da empresa né? Qualquer coisa mandem no email e eu respondo quando der.

Eu nunca tinha trabalhado na área educacional antes e não pretendo voltar a trabalhar jamais. Eu já não era muito fã de Universidades antes e agora então, menos ainda.

Consegui agüentar bastante (10 meses) devido à moleza que é isso aqui. Agora durante as férias dos alunos, por exemplo, estou entrando às 08:00 e saindo às 15:30. Vidão, né?

Não posso dizer que também não gosto de ter minha workstation sentando direto em cima de um link internet sem noção (> 100Mb/s) e ter um IP público direto. NAT é para os fracos.

Outra coisa que eu gostava aqui era da freqüência dos cafés/almoços/jantares. Jantar do presidente, almoço anual dos funcionários, almoço anual do departamento, café da manhã do sindicato, pizza por conta do fornecedor, festa de fim-de-ano, festa de fim-de-verão, campeonato de bolo de cenoura e chilli, dia da patinação no gelo (almoço incluído), cocktail de recepção a novos funcionários, etc, etc, etc.

Lógico, que não passam nem perto dos eventos gastronômicos brasileiros. Canadense realmente acha que uma bandeja de vegetais e algum molho esquisito são comida de festa. Ai que saudades de empadinha….

Acho que o que mais me irritou aqui foi a lerdeza das coisas. Não que o default canadense seja muito ágil, mas aqui é entre parado e dando marcha a ré. Pra mim, que estou acostumado com ambientes “enterprise”, fica pior ainda. Me dá nos nervos vendo coisas que precisam ser feitas não serem feitas.

Felizmente com o balanço entre as coisas ruins e as coisas boas eu consegui me segurar enquanto procurava uma oportunidade interessante. Não sei se já comentei aqui, mas fiz um scriptzin python que fica buscando vagas em sites de emprego da região e gerando um feed RSS que assino no meu Google Reader. Ai eu não preciso ficar perdendo tempo e ainda assim mantenho um olho no mercado.

Finalmente então umas semanas atrás vi uma vaga interessante. A descrição era bacana, parecendo alguma coisa de bastante responsabilidade e os requisitos técnicos caíram como uma luva. Olhei pra vaga e falei: É minha.

Voltei a reler meus posts sobre emprego, peguei mais algumas dicas na Internet e mandei ver uma presentation letter caprichada, CV atualizado e foi só esperar. Estava marcado que a vaga ficaria aberta até uma sexta-feira, mas na quinta já me ligaram marcando a entrevista.

Foi engraçado porquê chegando lá era um painel com três entrevistadores. O cara que vai ser meu chefe ao entrar na sala não olhou na minha cara. Não me cumprimentou e já foi disparando perguntas. Tratamento nos cascos mesmo.

Conforme a entrevista foi evoluindo ele começou a olhar pra mim enquanto conversávamos e na hora da despedida ele até me deu a mão.

Mas engraçado mesmo foi que ao final da entrevista ele já me disse que eu ia ter que passar por uma segunda rodada, o que achei bom, pois não se chama candidato sem condições pra segunda rodada.

Na semana seguinte quando cheguei pra outra reunião o tratamento foi totalmente diferente. Ele foi me buscar na recepção (da outra vez tinha sido outra pessoa), abriu um sorrisão e extendeu a mão pra me cumprimentar. Desnecessário dizer que naquela hora já pensei: To dentro.

A reunião foi com ele e com o CEO da empresa (é uma empresa pequena). Nenhuma pergunta técnica, só coisas relacionadas a trabalho de forma geral. Dava pra perceber que eles estavam tentando descobrir que tipo de profissional eu sou.

Estava indo muito bem a conversa e eu tinha a impressão que ia ser contratado, mas a certeza veio na hora que meu futuro chefe fala, durante a entrevista (!!):

- “Quando a gente terminar aqui vou te levar pra conhecer nosso data-center”

BINGO!

Dois dias depois já tinha negociado salário, benefícios (home office! uhu!) e fui assinar o contrato.

O resumo da ópera é que sexta-feira é meu último dia aqui na Universidade e já começo na segunda-feira no novo trampo. As expectativas são altas.

Então deixa eu explicar como funciona um projeto, não importa se grande ou pequeno, numa empresa assim – e consequentemente como eu estava acostumado:

• Um grupo de arquitetos de soluções conversa com o cliente para entender as necessidades, o ambiente atual e os objetivos
• Os TSA (Technical Solution Architects) montam o budget, estimam as horas necessárias, tamanho da equipe e tecnologias a serem usadas
• O Executivo da conta fazia uma requisição para o time de outsourcing pedindo um gerente de projetos, que por sua conta entra em contato com cada gerente de área e avisa quantos recursos vai precisar e quantas horas de cada para o projeto. É marcada uma reunião de kickoff interna onde o gerente de projetos e os TSA explicam o projeto. O GP escolhe um dos profissionais técnicos (de qualquer uma das áreas) para ser o líder técnico.
• Todos os envolvidos passam seus contatos para o GP (incluindo telefone celular e de casa). Uma lista telefonica pro projeto é criada e distribuida a todos os envolvidos.
• Todo mundo sabe o seu papel e o papel dos outros. Qualquer problema deve ser endereçado diretamente entre os técnicos, exceto em caso de dificuldades maiores ou pendência de decisão, situações onde pode-se envolver o GP.
• Todas as N fases do projeto pré-migração são executadas
• Duas semanas antes da migração final o GP, o líder técnico e todos os técnicos envolvidos no projetos tem que comparecer a uma reunião com o time de change management e risk management. Sabatina é o termo que me vem à cabeça. Experimenta não ter algo definido ou ter alguma coisa pendente e você vai ser publicamente execrado, seu gerente contactado e adeus bônus (best case scenario) ou adeus emprego (worst case scenario)
• No dia da migração você sabe quando começa, mas não quando termina. Enquanto a migração não tiver sido 100% concluída ninguém volta pra casa, ninguém dorme, ninguém escapa. Dê um beijo na esposa e lembre-a que não adianta ligar perguntando que hora você volta. No máximo pode perguntar que dia. Numa dessas eu varei 32 horas acordado, trabalhando.
• Se algum time termina a parte deles e vai embora e você percebe que tem algo faltando ou errado, não interessa que o nego passou 58 acordado trabalhando. Ele pode ter acabado de chegar em casa e deitado na cama, mas você vai ligar pro celular dele, depois pra casa dele e depois pro gerente dele até conseguir falar com o cara. Se nem o gerente do cara conseguir falar com ele, ele vai ter que parir um outro técnico que conheça o sistema e esteja familiarizado com o projeto. Fod**-se. Problema dele.
• O Projeto termina, todo mundo ganha prêmio, bônus, almoço em churrascaria e é publicamente parabenizado durante as reuniões departamentais ou nas “all hands meetings”

Acelera para os dias atuais.

Nossa universidade tem outra faculdade associada, mas é pequena, não tem time de IT e consequentemente nós cuidamos da infra deles por uns trocados.  E meu gerente mandou um email para todo mundo no grupo em algum momento do ano passado, genericamente perguntando se alguém tinha alguma idéia para substituir um Exchange 5.5 nessa faculdade.

Long story short eu abracei o projeto, que acabou virando uma coisa grande. Afinal você não tira o Exchange 5.5 e deixa um NT 4.0 rodando numa máquina de 1998 como controlador de domínio, né?

Gerente de projeto? Solution Architect? Kickoff meeting? Isso é pros fracos. Deixa o rookie (aka eu) tocar o projeto inteiro e seja o que Deus quiser.

Hoje foi o primeiro dia de migração e a primeira coisa a se notar foi o seguinte: Um cara da minha equipe vai embora às 16:00hrs todo dia. Adivinha que horas ele foi embora hoje? 16:00hrs!!!! E daí que menos da metade da migração foi feita? SÃO DEZESSEIS HORAS!

Os outros vão embora às 16:30, então já começaram a olhar no relógio também. Os usuários já começaram a perguntar se ia demorar muito, porquê eles iam embora às 17:00hrs.

Meu… vocês tão falando sério? Assim, vocês tem consciência que tá tudo offline, né? Que metade de vocês não tem email, não consegue autenticar na rede e estão sem acesso aos seus arquivos? Caracas… que povo cuca fresca.

Não teve jeito, tive que falar que a gente continuava amanhã.

Mas como eu não consigo deixar as coisas pela metade, quando cheguei em casa resolvi “dar uma olhadinha” e, lógico, vi que o acesso externo não tá funcionando. Nego fez m* na configuração do firewall.

Passei a mão no telefone e liguei pro gerente (que cuida tanto da minha equipe quanto da equipe de redes) e expliquei pra ele a situação: “Olha… o firewall tá errado. Eles não tão recebendo emails com essa configuração errada. Vamos ligar pro cara de rede??”

E a resposta que quase me fez cair da cadeira: “Ah… não precisa não. Que mal faz não receber email um dia? Amanhã conversa com o pessoal de rede quando chegar no escritório”.

TA QUEO PARIU…