Mas não basta remover o Exchange. Minha impressão é que se o e-mail é a ferramenta número um usada na empresa o calendário é a número dois. Ah, sim… BlackBerry. Tem que sincronizar com essa criatura. E iPhone. E Android. Sim: O email e o calendário. E nem ouse perder os contatos. Devem sincronizar e estar sempre disponíveis.

Ai ferrou, né? Basicamente consegui pensar só em um servidor alternativo ao Exchange: Zimbra. É sensacional e já usei antes. Mas cá entre nós: Eu já tenho tanto trampo e minha equipe foi reduzida recentemente com um dos técnicos pulando pro time de vendas. Que tal passar o problema pra outro?

Pesquisei um pouco e por coincidência fui contactado por um empresa parceira do Google quase ao mesmo tempo e partimos pro Google Enterprise com direito a Postini e tudo.

Não foi nem de longe a migração simples e suave que eu planejava e o fato de ter múltiplos domínios sendo migrados em datas diferentes fez a coisa ficar ainda mais complicada. Mas o que mais me impressionou mesmo é a resistência a mudança que as pessoas tem.

Mesmo com todas as maravilhosas features disponíveis na interface web do Gmail cerca de 90% da minha base de usuários pediu pra que o Outlook fosse configurado. Literalmente meia dúzia de pessoas abraçou a interface web. O que, na minha opinião, é ridículo.

No lado da migração já fica a dica pra quem for pelo mesmo caminho: Esquece a opção de deixar os usuários migrarem seus próprios emails: A ferramenta é um lixo, trava o diversas vezes e é incrivelmente lenta. Vá direto pra opção de migrar direto do Exchange pro Gmail e seja feliz. Esse foi meu principal erro… Quis deixar meus usuários migrarem seus emails (menos problema pra mim, né?) e foi um tiro no pé. Tive um dia do cão ouvindo xingos variados, a internet ficou uma carroça (todos os usuários tentando subir suas várias centenas de MBs de emails ao mesmo tempo) e logo de cara causou uma imensa má impressão do produto que deve durar ainda por um bom tempo.
No final acabei tendo que migrar (ou re-migrar, se isso existe) quase todo mundo usando o Exchange.

E minhas aventuras de migração estão longe de terminar. Se você anda se perguntando porquê não apareço mais no Google Talk nem no Twitter e nem aqui no blog fica aqui minha lista de projetos em andamento:

• Migrar minha server farm (produção) para um Data Center (atualmente temos nosso próprio mini-DC) até o final de Junho
• Coordenar a mudança (aka montar a infra-estrutura) para a nova sede da empresa até o final de Julho
• Adquirir novo sistema de PABX para a nova localidade (acima) até o começo de Junho

E nem estou contando coisas “pequenas” tipo migrar um cliente de grande porte de self-hosted para SaaS nesse final de semana.

Vou apenas dizer que ando bem cansado…

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.

o Zmanda está instalado num servidor PowerEdge da Dell rodando numa tape library também da Dell.

Infelizmente eu caí na besteira de deixar o sysadmin júnior responsável pelo backup por um bom tempo e descobri que tinha uma monte de cagada no sistema e apesar de ter conseguido arrumar a maior parte precisei entrar contato com o suporte do Zmanda. Chega o email de resposta deles assinado por um Eduardo Kazuo Miyazaki. Pô… nome mais brasileiro que esse só se o cara chamasse José da Silva. Pesquisa no Linkedn e batata.

Parte dos problemas resolvidos descobri que o backup não estava sendo mandado pra tape library por algum problema de hardware. Como eu estava de férias encaminhei pro pessoal do meu time e pedi pra alguém ligar na Dell.

Ai me respondem encaminhando o email vindo da Dell, cujo engenheiro responsável era um tal de Luiz Dunham. Escuta… Luiz com Z e sobrenome com N seguido de H só pode ser brasileiro, né? Mais uma pesquisada rápida e pá: confirmado.

Agora me explica quais as chances eu, brasileiro morando no Canadá, tentando resolver um problema num único sistema (backup) ligar em duas empresas diferentes nos Estados Unidos e ser atendido por um brasileiro em ambas?

Sensacional. Isso só mostra que nós, brasileiros, somos realmente bons nessa história de IT.

Se você já precisou acessar um servidor Linux atrás de um NAT sobre qual você não tem controle sabe como seria bom poder iniciar a conexão do lado do servidor conectando de volta em você.

Isso é possível com um túnel SSH reverso. A idéia é que o servidor que você deseja acessar inicia a conexão do lado dele, conecta-se na sua máquina e disponibiliza, via túnel SSH uma porta de volta pra ele.

Eu uso isso como um acesso rápido de casa para a empresa naqueles casos onde preciso só acessar rapidamente alguma coisa vinha linha de comando. Tenho acesso VPN se precisar de email, Terminal Services, etc. Seria possível fazer tudo via túnel, mas ai o desempenho não fica grandes coisas e nem é tão conveniente.

O comando (a ser executado do servidor atrás do NAT) é:

ssh -nNT -R 2222:localhost:22 username@suamaquina

Uma vez estabelecido o túnel você pode conectar de volta à partir da sua máquina utilizando:

ssh -p 2222 username@localhost

Como é possível que a conexão caia, o processo trave ou sei lá o que mais, recomendo os seguintes truques:

• Use chaves públicas para autenticação, assim não precisa de senha
• Rode a sessão inicial dentro do screen, isso evita perder o console
• Rode o túnel dentro de um loop while, pro processo poder ser restaurado caso morra
• Pra evitar alguém te sacanear crie um usuário dedicado pra essa conexão e aponte o shell dele para /bin/false

Mesmo com a a infra-estrutura toda virtualizada e clusterizada nos ESXi fazer um cluster de MySQL ainda é uma boa idéia.

Não só você pode colocar as duas máquinas em storages diferentes e eliminar mais um ponto de falha mas também você pode dedicar uma (ou mais) VM(s) para read-only.

Isso quer dizer que seus usuários rodando reports e chamando estatísticas/gráficos no meio do dia não vão afetar o desempenho de quem está entrando operações em produção.

Isso dito entra em cena o MySQL Multi Master Replication Manager (MMM): Um conjunto de scripts Perl que facilita a replicação e gerenciamento do seu cluster MySQL.

Abaixo os passos que utilizei para criar um cluster de 2 máquinas CentOS 5.5. Vou assumir que você já tem as máquinas em pé com MySQL devidamente instalado.

Além das máquinas rodando o MySQL você vai precisar de uma terceira, que é o monitor. É esse cara que vai manter os olhos no cluster, decidir quando uma máquina morreu e gerenciar os papéis de cada uma.

Nem idéia ainda dos requisitos mínimos desse servidor, visto que apenas fiz um teste pequeno aqui. Mas tá rodando sem reclamar em 1 processador e 512 de RAM.

Cenário:

IP Leitura/Gravação MySQL -> 10.0.0.1

IP Somente Leitura MySQL -> 10.0.0.100

IP Servidor MySQL 1 (hostname master) -> 10.0.0.2

IP Servidor MySQL 2 (hostname master2) -> 10.0.0.3

IP Monitor (hostname mon) -> 10.0.0.10

Editando a configuração do MySQL:

Em cada um dos servidores adicione as seguintes linhas embaixo da sessão [mysqld] do /etc/my.cnf:

#MMM
read-only
replicate-ignore-db = mysql
binlog-ignore-db = mysql
log-bin=master-binary
relay-log=master-relay
server-id=2

#MMM
read-only
replicate-ignore-db = mysql
binlog-ignore-db = mysql
log-bin=master2-binary
relay-log=master2-relay
server-id=2

Instalando o MMM:

rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
yum -y install perl-Algorithm-Diff perl-Class-Singleton perl-DBD-MySQL perl-Log-Log4perl perl-Log-Dispatch perl-Proc-Daemon perl-MailTools
yum install mysql-mmm.noarch mysql-mmm-agent.noarch mysql-mmm-tools.noarch

Configurando os Usuários:

Dentro de cada servidor precisamos criar 3 usuários: replication, agent e monitor. Abra seu console do MySQL e mande:

GRANT REPLICATION CLIENT                 ON *.* TO 'mmm_monitor'@'10.0.0.%' IDENTIFIED BY 'monitor_password';
GRANT SUPER, REPLICATION CLIENT, PROCESS ON *.* TO 'mmm_agent'@'10.0.0.%'   IDENTIFIED BY 'agent_password';
GRANT REPLICATION SLAVE                  ON *.* TO 'replication'@'10.0.0.%' IDENTIFIED BY 'replication_password';
FLUSH PRIVILEGES;
FLUSH TABLES WITH READ LOCK;

Abra duas sessões (uma em cada MySQL) e não as feche depois de rodar os comandos acima. Com eles executados faça a seguir:

SHOW MASTER STATUS;

E o resultado vai ser algo como:

mysql> SHOW MASTER STATUS;
+-----------------------+----------+--------------+------------------+
| File                  | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-----------------------+----------+--------------+------------------+
| master2-binary.000003 |       98 |              | mysql            |
+-----------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

mysql>

Você vai usar essa informação nos comandos abaixo. Note que você deve utilizar o output da execução em uma máquina no input da outra, de forma que crie uma cross-reference entre elas:

change master to master_host = '10.0.0.3', master_user='replication', master_password='replication_password', master_log_file='master2-binary.000001', master_log_pos=98;

A seguir vamos editar o /etc/mysql-mmm/mmm_common.conf:

active_master_role      writer

<host default>
    cluster_interface       eth1
    pid_path                /var/run/mysql-mmm/mmm_agentd.pid
    bin_path                /usr/libexec/mysql-mmm/
    replication_user        replication
    replication_password    replication_password
    agent_user              mmm_agent
    agent_password          agent_password
</host>

<host master>
    ip      10.0.0.2
    mode    master
    peer    master2
</host>

<host master2>
    ip      10.0.0.3
    mode    master
    peer    master
</host>

<role writer>
    hosts   master,master2
    ips     10.0.0.1
    mode    exclusive
</role>

<role reader>
    hosts   master,master2
    ips     10.0.0.100
    mode    balanced
</role>

Este arquivo deve ser exatamente o mesmo nos dois lados do cluster!

E só fica faltando agora editar o /etc/mysql-mmm/mmm_agent.conf:

include mmm_common.conf
this master

Com tudo isso pronto vamos no servidor de monitoramento e fazemos:

rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
yum install mysql-mmm-monitor.noarch

Copiamos nele também o /etc/mysql-mmm/mmm_common.conf.

E depois editamos o /etc/mysql-mmm/mmm_mon.conf:

<monitor>
    ip                  127.0.0.1
    pid_path            /var/run/mysql-mmm/mmm_mond.pid
    bin_path            /usr/libexec/mysql-mmm
    status_path         /var/lib/mysql-mmm/mmm_mond.status
    ping_ips            10.0.0.1,10.0.0.2,10.0.0.3,10.0.0.100
    auto_set_online     60

    # The kill_host_bin does not exist by default, though the monitor will
    # throw a warning about it missing.  See the section 5.10 "Kill Host
    # Functionality" in the PDF documentation.
    #
    # kill_host_bin     /usr/libexec/mysql-mmm/monitor/kill_host
    #
</monitor>

<host default>
    monitor_user        mmm_monitor
    monitor_password    monitor_password
</host>

debug 0

Iniciando os serviços:

Nos servidores MySQL:

service mysql-mmm-agent start
chkconfig mysql-mmm-agent on

No servidor de monitoração:

service mysql-mmm-monitor start
chkconfig mysql-mmm-monitor on

Se tudo correu bem em alguns segundos você vai ter os serviços rodando e pode ver o status deles à partir do servidor de monitoração com o seguinte comando:

[root@mon ~]# mmm_control show
  master(10.0.0.2) master/ONLINE. Roles: writer(10.0.0.1)
  master2(10.0.0.3) master/ONLINE. Roles: reader(10.0.0.100)

Referências:

http://www.packtpub.com/article/install-manage-use-mmm-for-mysql-high-availability

http://www.packtpub.com/article/setting-up-mysql-replication-for-high-availability?utm_source=rk_mysql_cb_abr2_0510&utm_medium=content&utm_campaign=ramsai

http://fedoraproject.org/wiki/EPEL/FAQ#What_is_EPEL.3F

http://mysql-mmm.org/mmm2:guide

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.

Cenário: Um servidor que estava rodando e funcional há mais de um ano teve um reboot agendado  de madrugada. Depois do reboot recebo alertas que o tal não voltou automaticamente como esperado.

Servidor: Dell PE 2850 com 3 NICs: 2 Intel + 1 DLink rodando CentOS 5.2

Remotamente acessei o KVM e vi que o servidor estava OK, no tela de login. Nenhuma mensagem de erro e as interfaces em pé. Como já sou macaco velho na hora pensei que as interfaces de rede tinham mudado de lugar (já vi isso várias vezes), mas não tinha como testar pois elas estão em redes físicas separadas (não dava só pra reconfigurar uma vlan no switch), então tive que vir pra empresa mesmo.

Chegando aqui, dito e feito. As interfaces (eth0 e eth2) alternaram de posição. Eu já tinha visto isso acontecer antes, mas não sem um upgrade de kernel.

A questão é que o servidor estava up há mais de 1 ano, enquanto eu só tenho 8 meses de empresa. Isso significa que meus antecessores podem ter feito upgrade de kernel em um determinado momento, mas nunca deram boot na versão nova. Eu nunca vou saber.

Mas na verdade o problema poderia ter sido evitado facilmente se as interfaces tivessem sido configuradas adequadamente logo de cara.

No RHEL e no CentOS as interfaces são ativadas pelo /etc/sysconfig/network-scripts/ifcfg-ethX. Onde X é o número da interface. Um dos parâmetros que pode ser configurado é HWADDR, onde você amarra o endereço físico (MAC Address) à interface, de forma que na hora de subir a mesma o Linux saberá exatamente qual é qual.

Aqui tem mais detalhes desse arquivo de configuração, enquanto aqui tem uma excelente explicação de porquê as interfaces podem alternar de posição.

Dizem que a Xerox contratou uma consultoria para melhorar o serviço de suporte ao cliente. Depois de muito dinheiro gasto, um imenso (e complexo) sistema desenvolvido e nem tanta melhora assim resolveram investigar. Para fazer isso começaram a analisar número de chamados fechados e feedback dos clientes para determinar quem eram os bam-bam-bans do suporte e usá-los como fonte de estudo para melhorar os outros.

Uma semana de análise depois chegaram à conclusão que dois funcionários eram imensamente superiores – tanto na quantidade de chamados fechados como no resultado positivo de acordo com os cliente.

Um deles era o funcionário mais antigo do suporte. Com 15 anos de casa ele não só sabia como resolver grande parte dos problemas de cabeça como mantinha sua próprias anotações que utilizava como base de conhecimentos. Ele nem sequer usava o novo sistema.

A surpresa, porém, foi que o segundo melhor foi um novo estagiário, recém-começado na empresa e que ainda nem sequer tinha usuário e senha para acessar a base de conhecimentos. Porém ele sentava do lado do melhor funcionário do suporte e não tinha medo de perguntar.

(in)Felizmente eu já estou nessa vida de sysadmin a tempo suficiente para me encaixar mais no perfil do primeiro sujeito, mas para manter minha sanidade eu fiz outsource do meu cérebro na maior parte das coisas. E tem funcionado bem até o momento. Explico:

A maior parte das coisas que precisamos saber nos nossos trabalhos se encaixam em uma dessas três categorias: As que fazemos muitas vezes, as que fazemos com uma certa freqüencia e as que nunca vimos antes na vida.

Via de regra eu tento fazer outsource do meu cérebro (e francamente do meu tempo) para as três opções e aqui vão algumas dicas. São voltadas para os sysadmins, mas provavelmente podem ser adaptadas para outros profissionais.

Coisas que fazemos todos os dias

Emails

Crie filtros para seus emails de forma que eles automaticamente caiam em pastas diferentes. Via de regra é possível identificar de forma arbitrária emails que você recebe diariamente e filtrá-los. Pra que perder seu tempo (e sua sanidade) olhando, apagando e filtrando emails manualmente se isso pode ser feito automaticamente? Não vou me aprofundar no assunto se o Augusto fez um excelente post no Efetividade sobre isso.

Logins e acessos

Acessar servidores para um sysadmin é tão certo quanto atender telefones para uma secretária. A diferença é que podemos faciltar nossa vida aqui.

Ao invés de ficar batendo usuário e senha, que tal utilizar autenticação via chave pública? Com o tamanho da minha senha acho que teria LER se ficasse digitando ela cada vez que preciso acessar um servidor.

E porquê raios gerenciar senhas se você pode fazer outsource da sua autenticação para a uma chave pública? Na real, eu nem sei mais qual a senha do meu usuário no meu provedor.

Em alguns casos, porém, usar chave pública não funciona por motivos técnicos (tenho esse problema em alguns servidores aqui). Nesse caso ainda é possível apelar para alguma coisa tipo o sshpass e criar uma pequena função no seu .basrhrc

goto () {
 [ -z $SSHPASS ] && read -s -p "Password: " SSHPASS && export SSHPASS
 sshpass -e ssh -o StrictHostKeyChecking=no $1
}

E simplesmente mandar:

goto hostname

Ele vai te pedir a senha só a primeira vez e depois vai mantê-la na memória enquanto você tiver aquela sessão do shell aberta.

Comandos

Use aliases. Use e abuse, aliás. Só não fique retardado (conheço gente que não consegue rodar um ps com parâmetros básicos sem o alias que tem embaixo de seu perfil).

Decidi que não me importo com a sintaxe de diversos comandos e não me interessa o full path de diversos diretórios. Dâne-se… alias neles para comandos simples de lembrar e já era.

Criar funções como o goto acima ou usar outras já prontas, como o Funções ZZ, são outro exemplo de simplificar comandos e deixar as complicações cerebrais para outros. Seu chefe perguntou que dia foi o último reboot de um server com uptime de 209 dias? Outsource:

$ zzdata hoje - 209

01/08/2009

Atividades diárias

Você tem uma série de atividades que precisa fazer todo dia? Coloque no seu calendário alertas automáticos para te lembrar de executar cada uma delas e pare de se preocupar. Manja aquela tensão que a gente sente quando tem alguma coisa importante pra fazer e não pode esquecer? Faça outsource pro seu calendário e durma tranquilo sabendo que ele vai te avisar.

Outra coisa que faço às vezes é configurar o celular para despertar ou algo assim. Não quero ficar olhando no relógio pra lembrar de alguma coisa. Outsource!

E não vou nem falar de automação, né? Aqui vale a dica para qualquer profissão: Conheça suas ferramentas e os softwares envolvidos nas suas atividades. Mesmo se você for um advogado ou um contador conhecer o Office apenas um pouco mais do que a maioria das pessoas já vai te dar uma imensa vantagem. Garanto que muita coisa que você usa seu cérebro para fazer poderiam ser feitas automaticamente (sem nem pensar) pelo Office.

Agora, se você é sysadmin, isso é obrigatório! Aprenda shell script e sua vida vai ser muito, muito mais fácil.

Só de vez em quando

Essa categoria de coisas é a pior de todas. Primeiro porquê normalmente coisas que precisam ser feitas com menos frequência tendem a ser complexas ou chatas ou obscuras ou tomarem muito tempo. Mas normalmente é uma combinação de todas.

O que eu faço aqui é manter minha própria base de conhecimentos (quando é algo que vai servir para todo e qualquer emprego que eu tiver) ou criar meus próprios documentos na base de conhecimentos da empresa que eu trabalho no momento.

Mas ao invés de um documento longo e descritivo, como invariavelmente encontramos por ai, eu faço algo que pode ser lido rapidamente e com todos os comandos prontos para copiar/colar.

Exemplo:

Precisamos de uma configuração específica para o sendmail aqui. Os documentos que tinham aqui antes de eu chegar eram algo como:

Passo 1: Dê login no servidor

Passo 2: Vire root

Passo 3: Abra o arquivo /etc/mail/sendmail.cf com o editor de texto

Passo 4: Vá até a linha que diz BLABLABLA

Passo 5: Troque BLABLABLA por XXXX

Passo 6: Salve o arquivo

Passo 7: Reinicie o sendmail

Fica claro que apesar de haver um documento explicando o procedimento você não pode fazer outsource do seu cérebro para ele. Você ainda precisa ler e interpretar muita coisa.

Por isso a minha versão desse documento é:

Como root rode o seguinte:

sed -i "s/BLABLABLA/XXXX/g" /etc/mail/sendmail.cf && /etc/init.d/sendmail restart

Pensamento ZERO. CTRL+C/CTRL+V. Outsource feito.

O importante aqui é o seguinte: A primeira vez que você precisar fazer essa atividade sinistra analise quais passos podem ser automatizados ou simplificados e pense como você pode documentar isso de uma forma que nunca mais precisa PENSAR. Só agir. Essa primeira vez vai dar muito mais trabalho do que daria normalmente, mas vale muito a pena.

Mas de nada adianta essa base de conhecimentos se você não conseguir achar as coisas que você documentou. Nesse caso eu preciso dizer que fiz outsource disso para o Google.

Além do Google Desktop, do Gmail e do Gtalk eu uso também o Notebook, que tem opção de tags, busca, etc.

Também uso a TiddlyWiki, que tem opção de search interna e é fenomenal. Recomendo fortemente.

Nunca antes (ou uma vez na vida e outra na morte)

Aqui nem preciso falar, né? GOOGLE.

Porém é importante aprender a usar o Google corretamente. Sabe comunicar-se com ele. Às vezes olho algumas pessoas fazendo pesquisa no Google e fico imaginando se algum dia conseguiram algum tipo de resultado útil. Tente aprender melhor a interagir com o Google e verá que seus resultados vão ser muito melhores e você vai poder fazer outsource de muito mais coisa para ele.

Eu perdi as contas de quantas vezes paguei de Ninja ou de top-senior-bambambam simplemente por saber fazer pesquisas no Google. No começo do ano fechei um chamado que estava aberto há 2 anos aqui na empresa com uma busca de 2 min no Google. E ainda levei trocentos elogios pra casa.

Mas não só Google. Uma outra ferramenta que tem ajudado é o Twitter. Lógico que sempre temos aqueles amigos online no Instant Messenger e que podemos pedir ajuda quando a coisa aperta, mas jogar uma pergunta no Twitter tem sido uma boa opção, já que se alguém lê e sabe a resposta na ponta da língua normalmente manda um reply logo de cara. Enquanto perguntar para alguém no IM sempre tem um overhead (E ai, mano… Beleza? Tá ocupado? Seguinte… to precisando de uma ajuda. O que? Não. Não sei…. onde você almoçou ontem? Putz… que massa. Quanto? Cacete… que caro. Legal, hein? Bora… vamo um dia sim. Ahãn.. Não, não planejei ainda. Ah… então… o que eu ia pergunta era _________ )

E lógico, sempre mantenha aquele cara ninja da sua empresa ou aquele gênio com que estudou ou que conheceu num fórum na sua quick list. E não tenha medo de perguntar. Só tenha medo de perguntar DE NOVO a mesma coisa.

Eu adoro quando meus colegas vem com dúvidas novas. Mas abomino quando vem com dúvidas que já respondi. Sinal que eles não conseguem lembrar e também não fizeram outsource de seus cérebros…

Na época eu estava no time de redes e era minha responsabilidade alocar subnets, IPs, Vlans, etc. Até que era divertido fazer toda a engenharia de uma rede razoavelmente grande e complexa, até que chegavam os malditos clusteres.

Não manjo nada de AIX, mas toda vez que precisávamos implementar um cluster de System P era a mesma coisa:”Ô, Eri… precisamos de uma rede exclusiva pra comunicação entre sei-lá-o-que e a repimboca da parafuseta.”

Tocava eu criar uma Vlan só pra isso.

E onde tem AIX tem o que? Oracle… (sempre andam juntos ou é impressão?). Ai vem também o DBA e larga: “O Oracl RAC precisa de uma rede exclusiva pra heart beating…”

Ô minha nossa… uma rede feita com tanto capricho e cuidado, com subnets bem definidas, máscaras de rede escolhidas com cuidado, numeração IP feita com esmero o suficiente para ser possível saber o hostname baseado no IP sem precisar de DNS… E me aparecem esses filhotes de cruz-credo criando redes isoladas e horrível de documentar num diagrama. O que fazer?

Bom… Eu fazia o seguinte: Para não estragar a minha alocação de redes privadas tão bem planejada eu simplesmente alocava 1.1.1.x/xx para essas tranqueiras. Ficava limpo, bonito e todo mundo que pegava o cliente depois que eu tinha saído do projeto sabia, apenas de bater o olho, do que se tratava aquela subnet: Era isolada e não precisavam se preocupar com ela.

Até ai tudo bem… Exceto por um problema: Dia 20 de Janeiro de 2010 a rede 1.0.0.0/8 foi alocada para Asia Pacific Network Information Center.  Oops… Foi mal, hein?

O quanto isso vai ser um problema na prática eu não sei dizer, pois a maioria dessas redes que eu implementei não eram acessíveis via internet de qualquer forma… Mas potencialmente falando é um problema.

Bom…. vivendo e aprendendo… De qualquer forma, desculpa qualquer coisa.

Uma forma simples de conseguir uma segurança bacana é utilizar o modo restrito do bash. Com isso habilitado o shell irá desabilitar as seguintes funções:

• Mudar o diretório (cd)
• Mudar o valor das variáveis SHELL, PATH, ENV, or BASH_ENV
• Comandos que incluem /
• Especificar um arquivo que contenha / como fonte para o comando “.”
• Usar redirecionamento de output (>, >>, |)
• etc (man bash para todas as features)

Colocando para rodar:

Crie um link do bash para o rbash e adicione o mesmo em /etc/shells:

ln -s /bin/bash /bin/rbash
echo /bin/rbash >> /etc/shells

Depois é só mudar o shell do usuário a ser restringido para usar o rbash:

usermod -s /bin/rbash username

Combinando isso com traps (do CTRL+C, por exemplo) você consegue criar um ambiente seguro o suficiente para fornecer serviços e acessos aos seus servidores e ainda assim dormir à noite.

Como diria o SuSE: Have a lot of fun!