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.

Nele dá pra assistir todos os episódios atuais das séries que estão rolando pelo micro. Sem precisar assinar TV a cabo, de graça e com comerciais limitados (normalmente apenas 30 segundos).

Além de ser possível assistir pelo browser você também pode usar, por exemplo, o Boxee para isso. E é exatamente o que eu queria. Instalei o Boxee na minha AppleTV e quero assisitir programação do Hulu.

A pegadinha? O Hulu só transmite nos USA. Assim que tentei acessar aqui do Canadá tomei uma invertida e o site me mandou procurar minha turma.

Se por acaso você também quiser assistir o Hulu de fora dos USA eu tenho a solução (não, proxy não funciona!). Você vai precisar dos seguintes ingredientes:

• 1 servidor Linux em território americano (acesso root)
• 1 máquina virtual Linux na rede local
• OpenVPN
• Capacidade de editar as configurações de rede do seu media-center

No meu caso tanto o servidor nos USA como a máquina virtual estão rodando Debian então foi assim a configuração:

Servidor:

# apt-get install openvpn
# cd /etc/openvpn/
# openvpn --genkey --secret static.key
# echo -e "dev tun\nifconfig 10.8.0.1 10.8.0.2\nsecret static.key" \
> tun0.conf
# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables --table nat --append POSTROUTING --out-interface \
eth0 -j MASQUERADE
# iptables --append FORWARD --in-interface tun0 -j ACCEPT
# nohup openvpn --config /etc/openvpn/tun0.conf &

Máquina virtual:

# apt-get install openvpn
# cd /etc/openvpn/
# scp user@server:/etc/openvpn/static.key .
# echo -e "dev tun\nifconfig 10.8.0.2 10.8.0.1\nsecret static.key" \
> tun0.conf
# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables --table nat --append POSTROUTING --out-interface \
 tun0 -j MASQUERADE
# iptables --append FORWARD --in-interface eth0 -j ACCEPT
# nohup openvpn --redirect-gateway --config /etc/openvpn/tun0.conf &

Media Center:

A partir de agora você deve configurar o default gateway do seu media center para ser o IP local da sua máquina virtual.

Pronto. Agora a única coisa que te impede de assistir de fora dos USA é a latência da sua conexão internet e sua largura de banda. Ah, sim… e caso você já tenha acessado o Hulu alguma vez sem usar essa gambi você precisa limpar cache/cookie do seu media center antes de tentar pelo túnel.

E agora que você já entendeu o processo, tavez queira melhorar um pouco a configuração da VPN, talvez se tiver um firewall mais bacana fazer uma configuração melhor no iptables principal e coisas do tipo. Se tiverem idéias para melhorar postem nos comentários.

Balança, mas não cai

Acho que não tem nada mais subjetivo do que a reclamação “está lento”. E um dia, ainda naquele cliente que falei anteriormente e – de novo – com localidade no Brasil, recebo um ticket com reclamação de que “a rede está lenta”.

Olhei nas ferramentas e não tinha nenhum alerta. Os gráficos mostravam que o uso do link estava abaixo ou na média do uso normal dos últimos 12 meses. Nada estranho… Mas mesmo assim peguei uma das ferramentas de test e mandei um burst pra cima do router pra ver o troughput. Tudo normal. Só pode ser frescura de usuário, pensei.

Liguei pra localidade e falei com o responsável técnico, que fez aquela voz de “não, logo depois que abri o chamado voltou ao normal”. Maldito.

Uns dias depois outro chamado, mesmo diagnóstico, mesma conversa. “logo depois voltou ao normal”. E isso aconteceu umas 3 ou 4 vezes até eu resolver olhar mais fundo no problema e descobrir um monte de erros de CRC no roteador. E ai pude ver que realmente, cada vez que tinha um chamado eu podia olhar que o número de erros de CRC tinham aumentado. Resolvi abrir um chamado com a telco.

Técnico da telco vai até o local, umas 4 ou 5 vezes e nunca acha nada. Por via das dúvidas trocam o router. E nada. E o tempo (meses) se passam sem solução. Nego resolve então trocar o CSU/DSU. E nada. Depois disso a telco apelou. Trocaram TODO o equipamento de rádio, exceto pela antena, e NADA.

Bom… como a única coisa que não tinha sido trocada era a antena, o problema só poderia ser lá. A Telco resolveu arcar com a despesa e mandou uma nova, para ser instalada no topo do prédio, igual a outra. No dia da substituição a equipe chega lá, arranca a antena velha, coloca a antena nova e desce pra sala de comunicação pra fazer os testes.

Uns vinte minutos depois, com tudo funcionando 100% tasca-lhe erro de CRC. Mandam o nego pra cima do telhado de novo, ele começa a diagnosticar a antena, quando percebe que apesar de uma árvore na entrada da empresa não estar na frente da antena, cada vez que batia um vento um galho bem grande e carregado de folhas/frutas entrava na frente do link.

Sem vento, sem problema. Com vento, galhos na frente da antena. Um problema tão simples demorou quase 6 meses para ser resolvido simplesmente porquê ninguém sequer imaginava que poderia ser isso.

Desculpas (válidas) para não resolver problemas

No time de WAN muitos problemas que tínhamos eram unicamente relacionados a coisas físicas. É muito mais comum faltar energia numa localidade do que um router Cisco perder a configuração. E isso é péssimo, pois tínhamos um SLA com o cliente e sofríamos uma pressão enorme de tudo quanto é canto para resolver problemas impossíveis dentro de um período de tempo ridículo.

Todas as vezes que tínhamos um chamado prioridade 2 ou prioridade 1, no dia seguinte tínhamos que comparecer a uma reunião de “chamados críticos”. E ai de você se o chamado tinha estourado. E PIOR AINDA se o chamado ainda estivesse aberto quando você chegasse na reunião.

E como se isso não fosse o bastante, seguindo uma mistura de ITIL e outras metodologias, era preciso que todos os chamados fechados tivesse: Trigger, Workaround, Impact, Root Cause e Prevention.

Vou dar alguns exemplo de explicações que tive que dar em algumas reuniões e vocês, por favor, me ajudem a identificar os pontos acima. Principalmente a parte de “Prevention”:

- A localidade está fora do ar porquê roubaram os cabos dos postes (adivinha em que país foi isso?)

- Não pudemos restaurar a conectividade da fábrica porque passou um furacão e destruiu o POP da Telco (Flórida/EUA)

- O ticket estourou porquê o carro da telco foi roubado e os técnicos feitos reféns durante a noite (México)

- Perdemos o SLA porquê está tendo uma revolução popular e os técnicos se recusam a trabalhar (Bolívia)

- Um trem descarrilhou e quebrou a fibra óptica que passava do lado dos trilhos. (Brasil)

- Sem previsão para essa localidade voltar. O last mile é subterrâneo e por causa da enchente que teve foi tudo pro quiabo. (EUA)

- A telco não trabalha de final-de-semana (wtf?!) (Porto Rico)

- O escritório nessa localidade foi fechado. No final de semana desligaram tudo e não avisaram ninguém. (Chile ou Bolívia. Não lembro)

- Um caminhão derrubou o poste na frente da empresa. (Brasil)

- A mesma tempestade de neve que derrubou o link fechou as estradas e os técnicos não puderam ir pra localidade resolver o problema (Canadá).

Os causos aqui aconteceram mesmo.

Outage em feriado

Minha equipe na época (eu ainda morava no Brasil) era composta de 10 pessoas dedicadas à WAN de um grande cliente multinacional. Para ninguém ficar muito de saco cheio de problema do dia-a-dia nem muitos projetos ficarem empacados a gente revezava a posição de on-call. Eu, como nunca fui muito de viajar ou passear não ligava de pegar on-call de feriado e por isso peguei quase em seqüencia uns 3 ou 4 feriados prolongados nacionais.

Bom… e ai tinha uma localidade, em São Paulo, que dava pire-paque toda vez que eu tava de on-call. E pior: todos os telefones de contato que eu tinha para a localidade tocavam até cair durante esses outages.

Eu tinha a escalation list, então quando eu não conseguia falar com o responsável por IT da localidade eu ligava pro on-call do time local (cada país tinha sua lista de on-call, então eu tinha um on-call Brasil. Nosso time era uma instância superior aos países).

Ai já sabe… ligar pra on-call brasileiro durante feriado prolongado nacional é pedir pra fazer inimigo.  Isso QUANDO atendem o telefone.

Só que se o on-call regional atende o telefone e fala: “Dane-se. Vê isso segunda-feira.” eu podia suspender o ticket e esperar. Mas quando eu não conseguia falar com infeliz eu tinha que voltar pra minha escalation list e continuar subindo. E ai liga pra gerente de rede no feriado e na segunda vez o nego também já não atende… e vai subindo… cheguei a falar com o infeliz do diretor de IT numa dessas só porque ninguém queria atender o telefone e dizer: deixa pra segunda.

E pior: Você segue o procedimento e escala até o diretor por causa de uma localidade ridícula que não tem ninguém trabalhando no feriado e na segunda-feira tem um email daqueles elogiando até sua mãe por ter perdido o tempo do cara. Ou seja: se seguir o procedimento você toma. Se não seguir… toma também.

Lá pela terceira ou quarta vez que aconteceu eu já não queria mais levar comida de toco e ao invés de seguir pelos canais oficiais de comunicação eu fiz algo diferente. Peguei a lista telefônica e procurei o telefone da localidade. E o número que eu achei era totalmente diferente do número oficial. Liguei lá e me atende um tiozinho:

- “Segurança, boa noite”

- Bingo! Ahãn, quer dizer, boa noite. Meu nome é Eri trabalho pro time de redes da empresa, departamento XYZ, blablabla e eu recebi um alerta de que um dos nossos sistemas está fora do ar. Isso normalmente acontece quando falta energia. Vocês tão sem força ai?

- Tamo não senhor. Só lá no prédio principal.

- (WTF?) Como assim? Queimou algum transformador lá?

- Não senhor. Como ninguém tá trabalhando lá eu desliguei a chave geral pra economizar, né?

- ( FDP, FDP). Ah, tá…. Mas isso não é procedimento normal, né?

- Não sei não senhor. Eu sou folguista. Só trabalho de feriado

- (FDP, FDP, FDP, FDP, FDP, FDP). Ah, tá OK. O Sr. faz uma gentileza pra mim, então? Religa a energia lá que ai o sistema volta e pára de alarmar, OK? Desculpa o incômodo, OK?

Bom… não preciso nem falar o tamanho do email que mandei pro time do Brasil falando sobre procedimento, normas da empresa e números de recursos despediçados durante esses outages. Mas o problema foi resolvido e nunca mais tivemos outages de feriado naquela localidade.

Mas o que me chamou a atenção foi um link dentro do artigo sobre latência. Latência é um fato da vida e um conceito muito simples para quem trabalhar com redes ou até com servidores, mas é incrivivelmente difícil de explicar para desenvolvedores, alguns sysadmin, gerentes de IT e, principalmente, leigos.

Neste documento de 1996 Stuart Cheshire explica com detalhes e perfeição o que é a latência e como os fabricantes de equipamento tentam enganar os consumidores tentando vender capacidade como se fosse velocidade. É uma leitura muito interessante e pode dar alguma luz para quem não entende como uma conexão via satélite de 4Mb/s pode ser mais lenta do que uma conexão via fibra óptica de 1Mb/s.

Não é o tipo de conhecimento que você vai precisar usar todo o tempo, mas pode facilmente salvar seu traseiro quando aquele projeto que você está trabalhando começa a dar m* por causa do desempenho.

Um dos meus colegas aparece hoje com o seguinte desafio: Instalar Linux num servidor IBM Netfinity antigão que está jogado nos fundos do data center. O problema é que o leitor de CD está bem zoado e depois de uns 2 minutos funcionando ele simplesmente pára de ler. Sem contar que ele não consegue dar boot de jeito nenhum.

Comecei pensando em dar boot pelo floppy e depois instalar o resto via CD até descobrir que o leitor estava mais bichado do que eu tinha imaginado.

A solução então foi instalar usando floppy + netinstall

Posso estar errado, mas aparentemente não tenho a opção de netinstall via floppy no Ubuntu e precisei baixar o mini-iso para fazer isso.

Mas como o CD não dá boot também precisei usar o Smart Boot Manager para conseguir bootar a máquina.

As referências caso você precise passar pela mesma situação:

How To Install Ubuntu Locally Over The Network

Smart Boot Manager

Mas por motivos que nem vale a pena citar, afinal não quero uma gastrite, o bagulho não aceita autenticação.

A forma que eu arranjei para resolver isso foi simples: A porta do serviço original é bloqueada via iptables e instalei o lighttpd para servir como proxy, já me aproveitando das features de autenticação dele.

Caso precise fazer algo parecido com isso um dia, segue abaixo como fiz:

Na sessão server.modules adicione:

            "mod_proxy",

E logo depois dessa sessão adicione:

auth.backend = "htpasswd"
auth.backend.htpasswd.userfile = "/etc/lighttpd/.htpasswd"
auth.require = ( "/" =>
  (
    "method"  => "basic",
    "realm"   => "status",
    "require" => "valid-user"
  )
)

$HTTP["remoteip"] == "192.168.0.0/24" {
          proxy.server  = ( "" => (
          ( "host" => "127.0.0.1", "port" => 8080 )
           )
      )
}

Onde:

192.168.0.0/24 = Rede que poderá acessar a aplicação

“host” => “127.0.0.1″, “port” => 8080 = IP e porta originais da sua aplicação.

Para facilitar minha busca fiz um script que disponibilizo aqui para quem tiver interesse.

Além do script vai precisar também do arquivo contendo a lista de IP vs País que pode ser baixado aqui.