Métricas de desempenho do Sysadmin?

Question

Eu trabalho em um pontocom e parte da responsabilidade de nossa equipe é manter o aplicativo da web de produção e o farm de servidores. Apenas recentemente nosso departamento foi criado, e agora temos uma enorme quantidade de servidores de atualização de rastreamento e a implementação de monitoramento e backups.

Para começar neste monstro, nós o dividimos em fases, e como parte de nossa primeira fase, estamos reinstalando os SO's em vários servidores, fazendo com que eles sejam atualizados a partir de antigas instalações do SO Redhat 8 (não fedora 8). Como um webapp, os servidores precisam executar o apache e o php. Os módulos que precisam ser compilados nesses programas são documentados e um processo antigo de compilação é documentado.

Como administradores de sistemas, o que vocês esperam documentar, e o que você deveria estar documentando? Como tanto o processo de criação quanto a documentação precisam ser atualizados, qual é a melhor maneira de apresentar os itens que precisam ser feitos? A definição das etapas deve fazer parte do trabalho do administrador do sistema ou parte do trabalho do gerente técnico? Isso faz parte da qualificação de ser um "engenheiro sênior de unix" contra um engenheiro júnior? Qual padrão você gostaria de ter para avaliar seu desempenho em um projeto como este se isso afetasse sua avaliação de desempenho?

Editar: O aplicativo está em desenvolvimento contínuo. A maior parte foi escrita em PHP4 e continua rodando em PHP4, no entanto, um código mais novo rodando como um serviço web é executado como PHP5. Portanto, nas mesmas caixas há uma instalação do php4 e do PHP5. Os módulos necessários para cada construção são documentados. O sysadmin tem esse doc.

    

Answer 1

Se é um problema único, como você pode avaliar se o problema está na pessoa ou no problema?

Você deve documentar tudo o que seria necessário para que seu departamento funcionasse se metade de seu pessoal fosse morto / demitido / etc ... se você precisasse reconstruir o departamento com novos administradores, eles poderiam fazer as coisas funcionarem novamente em um novo local com sua documentação.

Na prática ... hee! Okay, certo. Você tem sorte se os documentos forem mantidos atualizados se forem criados na maioria dos lugares.

Se você está gerenciando as tarefas monstruosas, talvez precise apenas encontrar seus administradores e perguntar como estão as coisas e o que foi tentado. Se nestas três semanas ele foi encarregado apenas deste problema e não está sendo resolvido, é porque ele não está trabalhando nisso? O que ele tentou corrigir a questão?

Você não pode microgerenciar o problema ou ele provavelmente vai começar a lutar contra você. Os sysadmins precisam de liberdade suficiente para trabalhar sem sentir que estão sendo examinados a cada passo. Mas se o projeto ou tarefa está muito atrasado, você tem uma preocupação legítima. Descubra com ele se há algo de que ele precisa para realizar o trabalho, ou qual é o problema que ele está tendo dificuldade em superar.

Bom livro: Gerenciando seres humanos por Michael Lopp.

O desempenho deve ser baseado em como os problemas de TI são abordados para atender às necessidades dos usuários, juntamente com a manutenção dos servidores e problemas de infraestrutura. Você não pode reduzir o problema até "resolver X questões por dia" ou "escrever X linhas de código" para medir cada funcionário.

Talvez você possa receber comentários de outras pessoas da equipe para obter algum feedback sobre o que cada um está fazendo ou quais são as principais necessidades. Bons técnicos querem trabalhar com bons técnicos. Eles não querem trabalhar com pessoas que são "felizes e legais", mas incompetentes. Eles vão trabalhar com um rabugento rabugento que odeia estar na sala com eles, se isso significa que tudo funciona bem e o rabugento sabe o seu material.

    

Answer 2

Coisas antigas (legadas) podem ser difíceis:
Se eu leio corretamente, você tem versões antigas de software e está tentando executá-lo em construções recentes do sistema operacional. Red hat 8 tem 7 anos agora, então eu diria que o aplicativo também deve ser atualizado (talvez esses módulos não tenham sido atualizados desde então). Então parece uma bagunça difícil como você diz.

Documentação e Expectativas:
Depende, mas você realmente deve definir o que você espera em geral. Faça tudo que você quer muito claro. Então você deve ser capaz de confiar no administrador para continuar com isso e atualizá-lo se não puder por algum motivo. Você pode checar com eles e ter certeza de que eles estão fazendo essas coisas. A administração do sistema é estranha, pois varia muito de posição para posição, portanto, pode levar algum tempo para que eles entendam o que você espera deles.

Minha recomendação, Comunique-se:
Acho que não podemos dizer se esses são problemas difíceis, não. Os desenvolvedores não devem estar tão distantes dos administradores do sistema, portanto, se você estiver com problemas, peça a um desenvolvedor em quem você confie para se sentar com o administrador e ajudá-lo a resolver esses problemas. Esse desenvolvedor deve ser capaz de fornecer algum feedback.

Sobre a atualização de tudo:
Alguns pensamentos que podem ou não ser úteis:

• Com que intensidade isso é usado? Talvez seja melhor virtualizar e esquecer :-P
• Quão complicado é o aplicativo? Pode ser mais barato e levar menos tempo apenas reconstruí-lo? Isso volta a atualizar o aplicativo também, talvez se esses módulos estiverem desatualizados, essas partes devem ser removidas e recodificadas. Ele também volta para a comunicação, os administradores do sistema de equipe e os desenvolvedores juntos para chegar à melhor solução, se possível.

Answer 3

Eu diria que se o seu administrador de sistemas não conseguir uma instalação de SO personalizada concluída após 3 semanas, ele / ela é incompetente ou então você está de alguma forma confundindo-o, resultando em atrasos sem fim. No cenário descrito, um fluxo de trabalho básico / básico deve ser: a equipe de gerenciamento e / ou implantação apresenta uma lista de requisitos e dependências. Os requisitos incluirão prazo, escalabilidade, tolerância a falhas, robustez, limites de disponibilidade, etc. As dependências cobrirão quais aplicativos precisam ser executados no servidor e, opcionalmente, qual software é necessário para suportar esses aplicativos. O administrador de sistema possivelmente poderia lidar com este último, a menos que você tivesse necessidades muito específicas e conhecidas relacionadas a versões de software e software. De qualquer forma, tudo deve ser documentado, com processos de aprovação em vigor para que o "cara no final do corredor" não possa fazer mudanças nas costas das pessoas e acabar atrapalhando o fluxo de trabalho e as expectativas do administrador de sistema. Uma vez que toda a informação é dada ao administrador de sistema, ele deve ser capaz de fornecer uma estimativa de tempo mais ou menos sólida.

Pelo que você disse, parece que essa pessoa nem está testando as compilações para ver se tudo funciona. Em um ambiente ideal, um conjunto de scripts de teste seria implementado para que uma compilação possa ser verificada como correta ou não, executando os scripts mencionados. Eles verificariam não apenas a funcionalidade, mas também se as versões corretas do software foram incluídas (isso inclui bibliotecas de sistemas e aplicativos). Em ambientes maiores, não é incomum ter uma equipe inteira dedicada aos testes de desempenho, assim, uma vez que um servidor e seus aplicativos instalados tenham sido implantados, você pode ter certeza de que ele funcionará e escalará tão bem quanto, se não melhor do que em um ambiente de laboratório ou de teste. Isso é outra coisa: um ambiente de preparação é a chave. Você pode ter políticas em vigor que exijam que os servidores passem de um ambiente de laboratório para um ambiente de preparação e, finalmente, para um ambiente de produção.

Eu não me importo se um administrador de sistema leva tempo para estudar cuidadosamente as coisas, de modo que quando um servidor é colocado em produção, ele funciona perfeitamente. Eu costumava conhecer um cara que fazia isso. Não era que ele fosse incompetente; em vez disso, ele estava ciente da gravidade das implantações fracassadas e, por isso, dedicou um pouco mais de tempo para ter 100% de certeza de que tudo era kosher. Sua reputação até agora é quase impecável, e eu o recomendaria a qualquer equipe de administração de sistemas. No entanto, repetidos deslizes em tarefas triviais devem levantar bandeiras laranja (ainda não vermelhas). Um administrador de sistema básico deve conhecer seus sistemas operacionais e bibliotecas de aplicativos comumente usadas, para que, quando chegar a hora de construir um sistema, haja poucas perguntas em mente sobre qual sistema operacional usar e quais bibliotecas e aplicativos implantar. Em relação a um servidor personalizado construído para um conjunto de aplicativos personalizados, levaria cerca de um ou dois dias para que a instalação e configuração básicas (mais ajustes de desempenho, proteção, etc.) fossem concluídas. Depois disso, isso dependeria do que precisa ser instalado. Quanto maior o número de requisitos de software, mais tempo será necessário para construir, instalar e testar, e talvez seja o que está segurando o seu administrador de sistema. Eu não posso dizer com certeza, já que você não forneceu informações suficientes.

Espero que ajude.

Michael

    

Answer 4

Excelentes respostas acima. Eu gostaria especialmente de enfatizar este ponto do post de Bart:

You should be documenting everything that would be required to get your department running if half your people are killed/fired/etc...if you needed to rebuild the department with new admins, they should be able to get things running again at a new location with your documentation.

Isso é absolutamente vital para algumas práticas de negócios e deve ser um requisito, não uma opção. E se "o único que conhece o sistema vital XYZ" se deparar com você ou tiver que ser demitido? Pessoas são pessoas - essas coisas acontecem. Documente os principais sistemas e processos, quaisquer requisitos especiais, advertências, quais servidores são responsáveis por quê. Isso é pelo menos o básico - os administradores mais decentes descobrirão os detalhes menores como parte do trabalho deles.

No entanto, como ecoado acima, na "vida real", você teria sorte de ter esses documentos criados, muito menos atuais e corretos. IMO vale a pena retirar um admin do projeto e fazer com que ele recupere a documentação, se é que é possível.

Espero que as coisas funcionem.

    

Answer 5

O cara provavelmente está pirando porque parece que seu ambiente de TI é um pesadelo, baseado em sua breve explicação de como as coisas funcionam.

Eu estaria disposto a apostar um centavo que as instruções que o seu SA está recebendo das pessoas do tipo devs / business unit também são terríveis. Peça a alguém para se sentar entre as pessoas que enviam pedidos e o cara que está fazendo o trabalho. Deixe-os rejeitar os pedidos que não fazem sentido e o documento que está sendo feito.

Einstein disse: "A insanidade está fazendo a mesma coisa repetidas vezes e esperando resultados diferentes"

    

Answer 6

Eu fiz muito trabalho de sysadmin para startups, e devo dizer que a documentação antiga é pior do que nenhuma documentação. Eu não posso contar as vezes em que examinei a documentação do sistema existente para ter uma ideia de como as coisas são unidas apenas para descobrir que o sistema foi totalmente reprojetado.

Essa situação geralmente surge quando um administrador de sistema deixa a empresa e sua última tarefa é documentar os sistemas. Com um pé para fora da porta, a qualidade da informação gerada é frequentemente fraca. E se o sysadmin não for substituído imediatamente (o caso usual), os sistemas geralmente são gerenciados pelo desenvolvedor menos consistente e / ou júnior (já que ele tem tempo). O que significa que os sistemas podem ficar fora de sincronia, não documentados e - no pior dos casos - variar de máquina para máquina (uma dor real com um cluster de aplicativos da web em que um é diferente dos outros).

Eu abomino a sintaxe wiki, mas eu gosto da documentação do sistema para residir em um wiki, então eu pelo menos tenho um registro de data e hora e um nome de quem documentou o que e quando. Uma instalação do MediaWiki é fácil de configurar e perfeita para coisas do sistema.

Quanto a quão bom é seu sr. sysadmin é, é difícil dizer. Muitos de nós chupam e muitos de nós desaparecem no fundo apenas fazendo o nosso trabalho. E todos nós temos nossos dias ruins.

Não muito tempo atrás eu passei uma quantidade insana de tempo (como dias ) tentando fazer o Ganglia compilar em uma máquina de 64 bits apenas para descobrir que era um bug na ligação. Tenho certeza que eu parecia um completo idiota para essas pessoas ...

Mais sr. sysadmin são muito bons codificadores, na minha experiência. Descobrir as opções de compilação para fazer com que a coisa funcione não deve ser um problema, a menos que seja algo não óbvio. Parece que seu sysadmin tem tudo o que é necessário para fazer o trabalho, mas o diabo está nos detalhes.

Meu conselho - seja direto e pergunte qual é o problema. E confira o livro "Managing Humans" que alguém sugeriu - é muito bom.