Que itens de configuração você rastreia para o gerenciamento de configuração adequado? [fechadas]

Question

Como administrador profissional do sistema, que itens de configuração você considera essencial monitorar para realizar a configuração adequada ou o gerenciamento de alterações?

Por exemplo, no Windows, você rastreia alterações no registro, além de hardware ou software? No Linux, você diff arquivos de configuração?

EDIT: Para esclarecimento, eu estou procurando o que especificamente para acompanhar (ou não acompanhar) - se você quiser recomendar ferramentas além para os itens que você acha que valem a pena acompanhar, vá à frente.

    

Answer 1

[Principalmente viés de Linux / Unix, eu não trabalho em sistemas Windows: -)]

Qualquer coisa que, uma vez modificada, altera o estado do sistema em execução precisa ser rastreada. A configuração deve ser armazenada em um repositório que suporte o histórico completo de alterações, por exemplo, Git ou Subversion, e deve ser implementado de maneira automatizada, como com Chef do Opscode ou Puppet dos Reductive Labs .

Alguns exemplos de itens que alteram o estado do sistema:

• Versões de pacote / patch instaladas.
• Aplicativos implantados, bibliotecas de aplicativos.
• Usuários administrativos e de aplicativos.
• Configuração de hardware e drivers / módulos de dispositivo.
• Tarefas de manutenção agendadas (cron no Unix / Linux).
• Serviços e componentes monitorados por ferramentas externas.

Esse acompanhamento precisa ser feito com ferramentas automatizadas que fornecem registro suficiente para alterações de auditoria. Um histórico do repositório de software mostrará, [...] o histórico de mudanças nos arquivos de configuração armazenados no repositório. Em uma ferramenta de configuração declarativa como Chef ou Puppet, cada arquivo de configuração representa um conjunto de recursos, como usuários, pacotes ou serviços, e o histórico do repositório indicará alterações neles.

    

Answer 2

Do ponto de vista da aplicação, é fundamental documentar

• SO e nível de patch
• Quais produtos em camadas estão instalados e quais correções foram aplicadas
• Quais produtos e bibliotecas personalizados e / ou de terceiros estão instalados, incluindo a versão
• Onde instalar as fontes de instalação dos itens personalizados / de terceiros
• Chaves do produto / SNs para todos os itens acima
• Configuração do servidor no nível do aplicativo (ou seja, web, correio, etc)
• Uma lista de contatos, se houver uma equipe de desenvolvimento separada responsável no nível do aplicativo
• Configuração de backup

Nota - em resposta ao comentário de romandas na questão, sei que não é exatamente um item, mas considero o documento geral um item neste caso

    

Answer 3

Para as janelas, você não precisa "rastrear" os níveis de patch do sistema operacional, pois isso pode ser consultado a qualquer momento via WMI. Se você estiver seguindo o gerenciamento de alterações, poderá fazer uma consulta global antes e depois de uma alteração para verificar os resultados de um patch do sistema operacional. (verifique se o provedor MSI está instalado)

As atualizações do driver devem ser rastreadas (o wmi pode ser usado para consultá-las, mas não vale a pena tentar pegá-las todas) As atualizações de aplicativos de software devem ser mantidas no CMDB, mas (exceto inicialmente) devem vir do gerenciamento de mudanças Se você realmente quisesse acompanhar as alterações no registro, defina uma política de grupo para habilitar o acesso a objetos e arquivos e escolha quais chaves auditar ( link ). Isso não é para um CMDB, mas permitirá que você acompanhe quem está fazendo alterações.

É isso que as pessoas geralmente querem rastrear em um CMDB e por que às vezes não é uma boa ideia, então o que deve entrar em um CMDB. A resposta é que depende. Um CMDB definido pela ITIL pode ou não se importar com as configurações da máquina, a menos que essa configuração específica da máquina esteja relacionada a um serviço. O ACMDB também pode conter uma solução de rastreamento de ativos (para coisas como localização de configuração de hardware e informações de garantia), mas é mais sobre relacionamentos de um item de configuração específico com outro IC. Relacionamentos incluem coisas como "é responsável por", "está ligado a", "depende de" e (mais difícil, mas em muitos casos mais importante) "necessário para o nível SLA_". Resumindo, grave o que é necessário para recriar o serviço - não o servidor.

Por exemplo. Se o email fosse o serviço, listaria coisas como:

Hardware: CPU de 64 bits, 3gb de memória RAM (com base no número de usuários no @today) 7gb de espaço para instalação do servidor, 100 gb de armazenamento para troca de dbs e recuperação (com base no uso a partir de @dia), dvd rom drive. >

Software: Server 2003 R2, Exchange 2007 SP2, drivers MPIO para a SAN

etc ...

Os CMDBs normalmente não são usados pelo administrador do servidor. Os administradores ficarão muito mais felizes com uma solução de gerenciamento de recursos.

    

Answer 4

Nível de patch do sistema operacional. O que pode significar muitas coisas. Idealmente, você rastreia quais patches individuais estão em quais máquinas, em uma matriz. A versão do pobre homem é uma "última data de patch" para cada servidor (o que pressupõe que você apenas obtenha todas as atualizações de cada vez, por atacado).

    

Answer 5

Para UNIX / Linux, divido os arquivos de configuração em dois grupos: aqueles fornecidos pelo sistema operacional e aqueles que fazem parte de nossos aplicativos personalizados.

Todos os arquivos de configuração do aplicativo são mantidos em nosso repositório de origem. Eu tenho cópias padrão diferentes para cada instalação (dev, QA, produção, pré-produção, demonstração ...). Quando determinamos que precisamos fazer uma alteração em qualquer um desses, a alteração ocorre primeiro na cópia do repositório de origem e, em seguida, é implantada nos servidores necessários. Também abrimos uma solicitação de alteração correspondente no rastreador de problemas.

Para arquivos de configuração do tipo OS, podemos ou não tê-los no repositório de origem. Se eles são, então usamos o processo acima. Se não, nós os colocaremos no repo se o número de alterações atingir um certo limite arbitrário. Até lá, pelo menos, abrimos um ticket no rastreador de problemas para rastrear essa mudança.

Além disso, um ótimo recurso do nosso rastreador de problemas é a capacidade de indexar confirmações de repositório de origem. Ele liga seus tickets às suas alterações de configuração muito bem.

    

Answer 6

Para dispositivos de rede, como switches da Cisco, gosto de coletar e rastrear suas configurações de inicialização e execução em um sistema de controle de versão. Se possível, eu guardo o nome de usuário que fez a edição também.

Eu puxo isso via um script Perl normalmente, a menos que eu tenha a opção de monitorar automaticamente os logs e acionar a coleção de configuração dos dados de log.

    

Answer 7

Para dispositivos de rede, o RANCID (o grabber automático de configuração) é ideal.

Para servidores, uma combinação de algo como o etckeeper (mantendo o / etc / em um VCS) e o fantoche (com sua configuração em um VCS).

    

Answer 8

Windows:

• Versão do SO
• Service Pack do OS
• Patches de segurança
• Política de auditoria (deve ser aplicada via GPO)
• Membros de administradores, usuários avançados e usuários da área de trabalho remota
• Lista de aplicativos instalados
• Compartilhamentos de rede