Existem anti-padrões bem conhecidos no campo da administração do sistema? [fechadas]

Conheço alguns padrões comuns que parecem perturbar quase todos os projetos em algum momento do seu ciclo de vida:

1. Incapacidade de sofrer interrupções
2. Componentes de terceiros bloqueando atualizações
3. Ambientes não uniformes
4. Falta de monitoramento e alerta
5. Redundância ausente
6. Falta de capacidade
7. Má Gestão de Mudanças
8. Políticas de acesso demasiado liberais ou restritas
9. Mudanças organizacionais prejudicam a propriedade da infraestrutura

Eu esperava que houvesse uma biblioteca bem articulada desses antipadrões resumida em um livro ou site. Estou quase certo de que muitas organizações estão aprendendo através de métodos de teste por fogo. Se não, vamos começar um.

Deixar que as tarefas automatizáveis ​​sejam automatizadas até executá-las manualmente leva tempo suficiente para que não possam ser automatizadas, porque a execução manual das tarefas consome o tempo todo.

Por outro lado, automação prematura. Não há absolutamente nenhuma necessidade de gastar 3N horas automatizando uma tarefa única que leva N horas para ser executada manualmente (mesmo que seja mais divertido automatizar do que trabalhar com as coisas manualmente).

A. não está testando a restauração - um backup pode ser verificado e ok, mas como restaurar?

Quanto tempo leva, o que leva? Você tem que saber fazer isso em uma situação estressada ...

B. sem gerenciamento de configuração, sem uniformidade - apenas uma mudança aqui e ali e acho que sintonizei alguns aqui ...

Quem sabe como replicar um servidor bem-feito se todas as peculiaridades não estiverem escritas e não houver configurações idênticas na loja? E se você conseguir restaurar aplicativos de dados, mas não de configuração?

C. sem monitoramento - sem ter idéia de como e o que as caixas estão fazendo

Isso é duplo: a) você precisa monitorar os alarmes para reagir a tempo, antes de ficar sem algum recurso ou comportamento estranho eb) você deve monitorar as tendências de longo prazo para gerenciar a capacidade (disco, CPU, RAM, rede,. ..)

D. sem redundância no seu cfg - o que acontece quando XX morre

Isso significa planejar com antecedência o que você deseja do seu administrador de sistemas.

Para mim, estes são os mais importantes.

O padrão mais importante é quando o departamento de administração do sistema (ou toda a TI) se torna um participante passivo na empresa. Ou seja, eles são vistos como um autoatendimento, onde todos vêm com idéias já formadas sobre como as coisas devem ser feitas, o que leva em consideração exclusivamente as necessidades do usuário e não as necessidades do ecossistema de TI completo como um todo.

O segundo padrão mais comum é quando o departamento de administração do sistema se transforma em vários botões, ou seja, todos os softwares / ferramentas são comprados ou desenvolvidos e instalados por terceiros e a administração do sistema recebe um treinamento e um manual oficiais e depois segue apenas os manuais de operação e encaminhar para o fornecedor tudo o que não estiver explicitamente no manual. Essa situação pode ser muito confortável para (alguns, se não a maioria) administradores de sistemas, mas isso é um desastre esperando para acontecer quando o fato de que ninguém realmente sabe como todo o sistema realmente funciona o levará ao terreno (pense em interações sutis entre componentes e o jogo da culpa entre os fornecedores).

1) excesso de promessas e resultados insuficientes (ou seja, manter as expectativas do usuário realistas)

2) Não verificando backups até que sejam necessários.

editar: pretendia que o número 2 incluísse a restauração de arquivos / dados

Não monitorando os padrões de uso da conta do AD, como o último horário de logon> 30 dias

(Temos que fazer isso por motivos de auditoria, mas os resultados são bastante chocantes)

• Manter as principais informações na pasta de uma pessoa / caixa de entrada / documentos. Se for importante, como detalhes de contato do fornecedor, chaves de licença, instruções de configuração, ele deve estar disponível para todos no departamento que possui autoridade e pode precisar acessá-lo e em um local padrão.

• Pedir à pessoa que conhece algo para documentá-lo. Isso soa bem porque eles são a pessoa que tem o conhecimento, mas na verdade é ruim porque eles não podem dizer facilmente qual é o conhecimento importante. É melhor ter alguém novo para lidar com isso, pedindo à pessoa qualificada qualquer informação de que precisa e solicitando que ela documente.

• Documentação pouco clara. Qualquer pessoa pode resolver um problema de prioridade média durante o dia com todo o departamento de TI disponível para conversar. Outra questão é resolver um problema de alta prioridade tarde da noite, quando você está quase sozinho e não tem idéia do porquê o sistema está configurado como está ou por que não corresponde ao que a documentação diz.

• Não acompanha bem as senhas. Portanto, você precisa rapidamente de uma conta, crie uma com uma senha aleatória e, 18 meses depois, ela ainda esteja em uso e ninguém sabe a senha ou quais serviços serão quebrados se ela for alterada.

• Não comprar suporte do fornecedor para os principais sistemas, porque é "muito caro".

• Prioridades inadequadas. O pessoal de TI deve ser orientado pelo gerenciamento - um acordo sobre quais projetos são prioritários ou, em caso de emergência, quais sistemas são necessários primeiro. Se a TI está tentando consertar o sistema comercial, o gerenciamento exige email e os usuários exigem processamento de pedidos, é uma receita para uma bagunça.

• Soluções inadequadas - é muito fácil para a TI ficar presa na mentalidade de "corrigi-la, o sistema de TI deve estar funcionando como antes", quando pode ser mais apropriado ter um contrato de gerenciamento e TI para "tentar por 2" horas, se não for corrigido, pare mesmo que pareça promissor e passe para a recuperação de um backup ".

• Cópias de arquivos de teste em todos os lugares. Você não deseja abrir uma pasta que execute um sistema ou site comercial e consulte "site-novo /, site-atual /, site-cópia /, site-teste /, site-teste-dave /, site-uso- Dev, produção e teste devem existir e devem ser separados com todos os departamentos envolvidos (TI, desenvolvedor, gerenciamento de projetos, etc), sabendo o que deve ser onde e com que concordância as mudanças são feitas. são aprovados.Também para arquivos de configuração.

• Altere a aprovação - mesmo que você tenha apenas uma discussão verbal primeiro, não mude a maneira como coisas importantes funcionam sem que ninguém mais saiba. Você decide o que é "importante" para a sua situação.

• Soluções incorporadas deixadas em vigor a longo prazo. Sei que você corrigiu este servidor naquela rede com fio telefônico antigo rapidamente, para que você pudesse resolver um problema urgente. Eu sei que você não tem tempo para refazê-lo corretamente. Faça o tempo.

• Más relações com o resto da empresa. A TI é um serviço que ajuda o resto da empresa a fazer seu trabalho. Se eles precisam de arquivos enormes rapidamente, faça isso acontecer. Se você precisar de aprovação administrativa para comprar hardware, obtenha-o. Se você não conseguir, comunique claramente que os arquivos enormes não podem se mover rapidamente porque o gerenciamento priorizou outras despesas. Se você precisar arquivar por motivos legais, mas não tiver orçamento, precisará ajustar o arquivamento no seu sistema da melhor maneira possível.