Se você é um Sysadmin das antigas que está migrando para o novo mundo DevOPs deve ficar como eu, se perguntando de onde as pessoas tirararam automatizar nunca foi nossa missão principal.
Desde que me entendo por profissional nesta área automatizar foi o ponto chave de qualquer trabalho. Criar scripts para tornar o trabalho repetitivo uma tarefa que fosse feita somente por um comando era a minha meta. Daí apareciam scripts que automatizavam desde a criação de um usuário no sistema até lógico, configuravam um servidor inteiro ( ou faziam o hardening ) rapidão.
Lógico que esta gênese da automatização como é hoje nem pode ser comparada com o que acontecia no passado, mas, usar a criatividade nos processos atuais usando o gitlab-ci ou github-actions é algo lindo né ?
E hoje lendo a FedoraMagazine vi um ótimo artigo falando sobre alguns erros comuns ao automatizar. Vale a pena a leitura ( está em inglês ) mas resolvi jogar um pouco mais de lenha na fogueira escrevendo um tipo de adendo ao artigo deles. Vou falar sobre os pontos que eles colocaram mas, também, soubre outros pontos também já pensando em esteiras.
Testa esta disgrama
Primeiro problema, principalmente quando pensamos em Sysadmins iniciantes é a certeza que vai funcionar. Eu cometi um erro a anos atrás em que eu precisava copiar os diretórios de um Qmail para outro Qmail. Em teoria fácl mas, lógico, passível de erros.
Naquela ânsia de ver tudo pronto rapidão, cometi um erro no script que levou emails de usuários para a caixa de outros e .. com isto, deu aquele pequeno problema.
Para isto teste. Seja sua estrutura pequena ou grande, suba um número pequeno de máquinas virtuais e teste. A partir da certeza rode o seu script.
O mesmo vale quando estamos falando de pipelines . Pensar em todos os passos de forma mais abrangente e testá-los de forma mais assertiva é um passo importante para o Sysadmin. A grande vantagem quando falamos de equipes que já contam com esta cultura DevOps é que temos também um QA na equipe.
Estar próximo dos QAs ( vulgo equipe de testes ) para quem está iniciando rumo a automação é muito, mas muito importante mesmo. E, por experiência própria acho as equipes de QA muito legais pois eles tem idéias super fora da caixa. E nos ajudam a chegar a testes muito mais efetivos que nunca pensaríamos.
Desabilita o que você num precisa, infeliz
Eu poderia ter dado a esta seção o nome de Padronize para ser feliz, mas achei legal pensar sobre desabilitar serviços e qualquer outra coisa desnecessária nos servidores.
Porque ? Porque ter um parque de servidores instalados cada um de um modo é uma loucura. E, se pensamos ainda em estruturas como as atuais em clouds públicas a coisa desanda ainda mais.
Por este motivo, manter os padrões é uma chave para o sucesso ( evidente que isto vale uma discussão em outro post quando estamos falando de times usando o devops ). E é aí que a automação entra.
Após o entendimento do que deve rodar ou não nos servidores e o seu padrão a ser usado você roda o script de hardening ( lembra que eu falei acima dele ? ) e a partir daí seus servidores seguirão um padrão específico.
Documente
Nem precisa dizer né ? Documentação apesar de ser a parte mais chata que existe na vida de uma pessoa é, sem dúvida, a parte mais importante. O motivo nem precisa dizer já que qualquer um que nunca tenha documentado um código já sofreu com isto.
Reza a lenda que ao escrever algo, naquele momento somente você e Deus conhecem o porque daquilo. Dias ou meses depois, somente Deus. Para que você não precise contar com uma intervenção divina ao tentar efetuar uma manutenção em algo que fez no passado lembre-se de documentar.
E é bom lembrar que não somos eternos. Nós estamos hoje numa empresa e amanhã podemos não estar mais lá. Mas, muitos dos nossos scripts estarão rodando durante muitos e muitos anos lá. Portanto, documente pensando no próximo Sysadmin que estará perdendo noites com eles devido a algum comportamento esgtranho na infraestrutura.
E como aprender a documentar já que isto é uma grande fraqueza para todos os técnicos ? O primeiro passo é ir ao eu líder direto para saber se a empresa já tem alguma forma de documentar já definida. Isto acontece muito quando a empresa tem que seguir alguns padrões de mercado devido a alguma certificação que a empresa possua.
Caso não tenha é tentar pegar os padrões mais usados pelo mercado e, criando a primeira documentação da equipe e, a partir daí usar isto. Ah, e vale lembrar que tal qual seu código a sua documentação deve sempre ser versionada e atualizada sempre que houver uma mudança na sua automação.
Nunca se ache esperto demais
Apesar do pessoal do Fedora focar na falta de experiência acho que é sempre bom lembrar que o EGO nunca deve ser seu companheiro no trabalho diário. Somos eternos juniores, sempre.
Evidente que o advento do COVID e a necessidade de profissionais de TI para todos os lados causou um fenômeno complicado. Muitos profissionais cairam em ambientes para administrar ou até, automatizar algo para sistemas que eles nem conhecem de forma mais aprofundada. Isto pode ser um problema pois automatizar algo que não se conhece ( ou tem documentação fraca ) é um trabalho que pode, ou vai, dar errado.
Mas eu quero focar num outro ponto. Quando alcançamos um patamar razoável na carreira temos a mania de achar que somos pequenos deuses administrando estruturas. E, com isto nosso ego fica um pouco inchado.
Neste momento que os erros acontecem porque mesmo com grande experiência e conhecimento podemos cometer erros.
A dica é, sempre, ao fazer qualquer coisa, não se ache esperto demais. Somos humanos e VAMOS ERRAR. E para limitar o erro mate o pequeno deus que habita seu corpo e faça tudo com plena atenção e cuidado.
Com este cuidado e esta morte do ego corre o perigo de mesmo com pouca experiência em algo … você conseguir entregar algo mais operacional que alguém com grande experiência.
Converse …
Somos eternos rabugentos. Em geral Sysadmins não curtem muito conversar. Principalmente gente velha e idosa como eu. hahahaha
Mas é sempre bom conversar com o seu cliente direto. Uma das grandes vantagens do mundo atual é que as barreiras entre os Ops e os Devs morreram. E no fim, são eles os nossos clientes.
Sentar e definir com eles o que será feito e, até, entender os anseios e necessidades pode fazer com que uma automação seja muito mais efetiva.
Portanto crie um canal direto com os seus desenvolvedores. Um canal direto com seus DBAs. Ou seja, um canal direto com quem você for atender.
E nem pense nos gerentes. Não, nem sempre a liderança sabe o que seu desenvolvedor quer. Sente na mesa com o cara, desenhe com ele o fluxo. Teste cada passo com o mesmo e, ainda, ouça o que ele tem a dizer.
Muitas vezes ele pode não entender o processo como um todo mas, pode ter uma idéia tão doida que pode lhe ecomizar alguns dias de trabalho.
Devops
Apesar de ser algo que eu não entendo ( pois desde que entrei na graduação defendo que o Sysadmin deve programar ) é , para quem é Sysadmin e não programa começar a ver o que o mundo DevOps tem a fornecer para suas automações.
A muitos anos atrás gastávamos muito tempo nos emails observando o que deu erro e o que não deu. Uma tarefa tediosa que hoje pode ser facilmente resolvida com ferramentas como o próprio Jenkins que pode rodar seus scripts de automação e lhe dar os resultados rapidamente em uma interface.
E isto é só um dos pontos que estas ferramentas podem lhe fornecer. Portanto, bota o pé neste mundinho. Vai ser legal. Pois ser um sysadmin experiente e ainda aprender mais sobre o mundo DevOps vai ser um chamariz muito grande para o seu currículo e ainda, para facilitar o seu trabalho diário.
Fim
Era para ter uma conclusão aqui mas ao contrário do artigo da FedoraMagazine isto aqui nasceu as pressas, portanto nem tem uma conclusão final. A iéia foi mesmo fazer adendos ao artigo e, ainda, colocar esta última parte que deve ser preocupação tanto de administradores antigos quanto novos.
Automação é uma obrigação a anos para qualquer Sysadmin. Programar, algo que eu nunca entendi não ser o forte para esta profissão já deveria ser a anos algo praticado por todos nós.
Portanto aproveita que a FedoraMagazine nos provocou e pegue tudo que você fez mais de uma vez, do mesmo jeito nos últimos dias, saca a sua linguagem preferida e transforma isto em um comando ou uma pipeline.
O mundo agradece e sua sanidade mental também .