Menu English version
Blog Infra como Código

Problemas espinhosos da administração de sistemas

 

espinhos

Profissionais que já têm uma certa experiência certamente já se depararam com certas características problemáticas que, infelizmente, existem na grande maioria das empresas.

Diversos setores de Tecnologia da Informação têm uma visão relativamente negativa dos Administradores de Sistemas e profissionais que trabalham em atividades correlatas. Esses profissionais geralmente são sobrecarregados e estão sob constante pressão, pois as organizações precisam que suas redes, sistemas e serviços estejam sempre disponíveis.

Essa visão negativa tem um certo fundamento, pois existem algumas características que são comuns.

Aversão a mudanças

Por ter que garantir que tudo esteja sempre funcionando, o administrador é muito conservador quando analisa qualquer tipo de mudança no ambiente, por menor que seja. Geralmente a resposta padrão, antes mesmo de terminar de ouvir uma demanda, é não.

Sem dúvida esse comportamento vem de experiências anteriores, onde muitas vezes alterações a princípio simples e inocentes causaram sérias consequências. Os mais precavidos não fazem nenhuma alteração antes de se montar um plano para que, em caso de qualquer imprevisto, mesmo que manualmente, as alterações possam ser revertidas.

Lentidão na entrega de novos serviços

Por estarmos sempre sob pressão para garantir a disponibilidade e qualidade dos serviços que já estão na rede, novos serviços ou a atualização dos já em funcionamento geralmente não são prioridade.

Existem ambientes tão problemáticos onde praticamente o trabalho da equipe é constantemente remediar e apagar incêndios, lutando para garantir que tudo continue funcionando apenas como está.

Compartilhamento de informações é tabu

Em organizações onde exista uma equipe de administradores, é muito comum encontrar rachas dentro da equipe do tipo: Fulano cuida das máquinas A, B e C, Ciclano cuida das máquinas X, Y e Z e Beltrano de M, N e O. E nenhum deles se ajuda ou sabe claramente o quê ou como o outro configurou.

Não só isso, muitas vezes os membros da equipe tentam o máximo possível isolar seu trabalho e até mesmo os sistemas sob sua responsabilidade, com a justificativa de que querem ser mais independentes.

E, pior ainda, quando Fulano precisa intervir nas máquinas de Ciclano, por exemplo em uma situação de férias, sobram críticas do tipo “Lógico que deu problema, olha como ele fez!” ou “Onde está a documentação disso?” e, ainda por cima, “A documentação toda errada!”. Certamente bate-papos no café sobre as atividades de cada um ajudariam em situações como essas.

Permissões de acesso são vistas como troféu

Nada como ter plenos poderes. Para muitos administradores, infelizmente, conseguir acesso a servidores que anteriormente ele não tinha é uma conquista. Mais por questões sociais do que técnicas. Afinal, muitos encaram isso como a derrota do colega que anteriormente tinha acesso exclusivo a um determinado servidor e agora perdeu esse “privilégio”.

As organizações fazem o que podem para solucionar esses problemas, mas não é uma tarefa fácil. Muitos acreditam que o principal método para solucionar essas questões é a criação de uma boa documentação sobre o ambiente. Porém, o próprio administrador geralmente é extremamente cético sobre a eficácia dele documentar suas atividades, configurações e planos. Quem documenta acredita que ninguém vai ler, e quem lê a documentação acredita de antemão que ela está incorreta.

Das diversas soluções que existem para documentação, talvez a menos pior seja a equipe utilizar uma wiki. Utilizando qualquer wiki, de graça vem o versionamento e mecanismo de busca. Porém, mesmo utilizando a wiki, ao longo do tempo a documentação apresentará diversas limitações.

Validação e atualização de documentação

Como testar se todos os comandos e arquivos documentados na wiki (ou qualquer outro mecanismo, como um simples arquivo texto) estão corretos? Provavelmente não houve má fé quando registrou-se o como se chegou ao estado de um servidor com Apache, PHP e PostgreSQL, mas basta que apenas um dos passos seja deixado de lado para que ninguém mais consiga repetir com sucesso a instalação e configuração.

O que fazer? Ordenar que outro administrador valide tudo o que o colega fez? Não será nada divertido de se fazer, mas muitas vezes é um mal necessário.

É natural que, ao longo do dia-a-dia da área de TI, emergências surjam e sejam necessárias intervenções imediatas no ambiente. Ajustes como limites de conexões, espaço alocado, etc. A questão é, depois da emergência, alguém se lembrará de atualizar a documentação com as mudanças? Provavelmente não.

Mesmo com todos os problemas apresentados anteriormente, muitos sistemas continuam funcionando. Existem soluções para essas questões, porém elas demandam uma combinação de mudança de cultura e ferramentas para gerenciamento de configuração e automação.

Nos próximos artigos falaremos de DevOps e também como a utilização do Puppet e outras ferramentas podem tornar a administração de sistemas mais confiável e ágil.