O Stakeholder Negligenciadas a.k.a Administrador do Sistema

Question

Algum tempo atrás eu vim a perceber que o projeto quase todos os clientes que tenho vindo a trabalhar sobre até agora tem negligenciado um importante grupo de partes interessadas:. Os administradores de sistema

Estes heróis silenciosos geralmente só são envolvidos no final de um projeto e são deixados com uma caixa preta executável de bits que têm de instalar, apoio, e manter para os próximos anos. Sempre que ocorrer um problema com esta caixa preta que eles têm que encontrar uma maneira de resolvê-lo usando qualquer peça aleatória de suporte de informação e uma ferramenta que lhes seja disponibilizada pela caixa preta ou a plataforma subjacente, e se isso não for suficiente, então eles têm que improvisar .

Se eles tivessem sido envolvido como parte interessada no projeto desde o início eles teriam tido uma chance para prever possíveis problemas e informar a equipe do projeto sobre o assunto. Mas a realidade é diferente e mesmo que eu como um desenvolvedor gostaria de envolver o administrador do sistema como parte interessada extra, fatores externos podem impedir que isto aconteça.

Nestas situações gostaria de ajudar nossos heróis silenciosos tão bom quanto eu posso. Então, minha pergunta é:

O que seria um desejo administrador do sistema a partir de nós desenvolvedores quando desenvolvemos os sistemas terão que manter?

Se você é um administrador de sistema por favor, contar uma história de guerra sobre um problema difícil que você já teve e que os desenvolvedores poderiam ter feito para tornar mais fácil para você para resolvê-lo.

Answer 1

Várias coisas, incluindo (mas improvável de ser limitado a) esses, que não estão em ordem de prioridade:

• Sem exigência de utilização privilegiada instalar
• Opção para usar privilegiada instalar
• Opção para distribuídos instalação (para que possa ser instalado em um servidor e usado em outras máquinas)
• Limpe desinstalar
• padrões de atualização Sensible
• Opção para escolher o local de instalação
• dependências mínimo em outros software
• dispersão mínima de dados em todo o sistema (não despejar o material em / etc, / usr / lib, / var / adm, ...)
• No logs sempre crescentes
• Instalação silenciosa
• instalar Scripted
• Documentação on-line (na máquina - assim como na internet)
• páginas homem talvez
• Fácil de configure
• Fácil de tornar acessível aos usuários finais
• Não há riscos de segurança
• Não há usuários especiais ou grupos (ou número limitado - no máximo um usuário especial, um grupo especial é um alvo, embora nem sempre atingível)
• Ou nenhuma funcionalidade 'telefone casa' ou apenas se explicitamente configurado (não deve ser padrão)
• Boa registro de diagnóstico, quando há um problema
• Boa suporte técnico disponível se houver um problema
• Não há requisito para obter o código de ativação durante a instalação
• Não há requisito para reiniciar a máquina depois de uma instalação
• Capacidade de paralelo executar versões antigas e novas

Depende muito de que o software é e como ele é usado. Os requisitos para um programa GUI que funciona em Windows, Linux e MacOS X são radicalmente diferentes dos requisitos para um daemon rede -. Mas a meta ainda deve ser estável, software confiável e facilmente gerenciada

Tenha em mente que existem grandes diferenças entre software preparado por um departamento in-house para uso dentro de uma empresa e software preparado para ser utilizado por clientes externos à empresa que desenvolve o software.

Answer 2

Quando um problema ocorre inevitavelmente, prestar atenção ao que o sysadmin diz e acreditar nele. Não basta rejeitá-lo fora de mão, se ele não se encaixa com a sua avaliação inicial.

história War: Back cerca de 6 anos atrás, eu estava sysadminning para uma empresa de fabricação de pequeno e eles decidiram comprar algum software para programação punho de manutenção preventiva em seus equipamentos. Uma das suas características era a importação de solicitações de manutenção de e-mail, mas tivemos problemas ocasionais com erros falando ao servidor de correio durante este processo e eu acabou por ser chamado para dar uma olhada nele durante um telefonema com o desenvolvedor. A conversa envolveu várias iterações de

Desenvolvedor: Eu nunca ouvi falar de alguém ter esse tipo de conversa problemas para o servidor de correio. Tem que ser uma problema de firewall.

Me: Eu estou conectado ao firewall, execução de um packet sniffer, e assistindo o tráfego do seu aplicativo passar sem qualquer problemas. Está ficando através do firewall muito bem.

Desenvolvedor: Não, não - tem que ser um problema de firewall.

(No final, descobriu-se que o problema era que o aplicativo abriu uma ligação POP3, leia todo o correio, esperou para o usuário agendar as tarefas, em seguida, enviou um comando POP para apagar o e-mail depois de todos os pedidos tiveram foi agendada. Se o usuário levou mais de 15 minutos para fazer o agendamento, a conexão POP expirou e o aplicativo não foi capaz de recuperar, por isso morreu em seu lugar. e, em seguida, o usuário teve que repetir a programação, o que significa que, provavelmente, tomar o tempo suficiente para o tempo limite de novo ...)

Answer 3

Eu acho que uma combinação dos seguintes:

1) Limiar de capacidade -> O que máquinas que é necessário para executar este software e quais métricas devem ser usadas para determinar quando esse número pode mudar, por exemplo, indo de 2 a 3 servidores de banco de dados ou ir de 10 a 15 servidores web. Como musculoso acontece com a necessidade de hardware para ser e faz uma parte mais matéria do que o outro, por exemplo, faz CPU importa mais de RAM, o que sobre a configuração do disco rígido e do espaço?

2) solução de problemas estilo Cookbook -.> Se algo der errado quão facilmente isso pode ser categorizados em código, de dados ou erro de rede

3) Diagrama de ambientes -> O que as instâncias dev, teste e produção deste Look software como? Existem estes e possivelmente outros ambientes funcionando agora?

4) Manutenção -> Há arquivos de log para analisar em relatórios, logs de erros semanais para enviar ao redor, ou algum tipo de limpeza a ver com o software, por exemplo, reiniciar o semanário servidor.

5) Segurança -.> Existem contas a ser criado e gerido e uma política de segurança para delinear quem tem o nível de autoridade no sistema

Esses seriam os principais que vêm à minha mente.

Answer 4

Os administradores de sistema geralmente querem o seguinte:

• A transparência em operação do sistema. Então algum tipo de interface gráfica que as configurações do sistema shows e talvez um histórico de problemas no sistema, bem como listas do que o sistema tenha processado corretamente.
• A caminho de escalonamento sensível ao contexto claro para os problemas. Com isto quero dizer que cada tipo de problema tem algumas notas sobre a fixação, e uma pessoa ou equipe que pode ser contactado se o problema não pode ser corrigido de forma rápida e escalada é necessária.
• Para ser pró-ativo, ou seja, capaz de informar os utilizadores finais sobre um problema do sistema antes de um usuário final informa. Então algum tipo de alerta imediato para qualquer problema no sistema onde isso é possível,
• Não deve ser inundada por alertas. Assim uma vez que um alerta chegou, há mais alertas para o mesmo problema; apenas uma outra mensagem quando o sistema está operacional novamente.
• detalhado registro usando algo parecido com o registo de eventos (no Windows) para investigação mais profunda de um problema.

Answer 5

Que o sistema funciona apenas para que ele possa ir para casa para crianças.

Answer 6

dependências que vêm embalados com o software

Bem documentado, se minhas experiências Admin Home são qualquer coisa ir perto.

Answer 7

Bem, mais um horror do que uma história do tempo da guerra:. Manter um aplicativo que para nenhuma exigência razão aparente para ser executado sob uma conta de usuário do administrador

Algumas coisas aleatórias que eu acho que seria bom ter em um aplicativo:

• significativas argumentos de linha de comando
• Algum tipo de recursos de script (se apropriado)
• Qualquer tipo de indicador de progresso por muito tempo correndo operações
• logging Erro
• UI consistente

Answer 8

fácil manutenção pacote!

Deve ser simples com morte cerebral para instalar e atualizar o software, e isso vale para dependências também. Se há um monte de dependências e sub-dependências, e você não está inclinado a dominar as nuances da metodologia de gerenciamento de pacotes de cada sistema operacional, que seria bom para oferecer uma versão do pacote com todas as dependências necessárias agrupados em um tarball gigante . Executar o script, Chuck tudo em / usr / / YourProject local, e dizer-lhes onde está a startup / shutdown / restart script.

Answer 9

Cada projeto tem 'planejamento de capacidade', juntamente com a sua arquitectura do sistema. Os administradores de sistema devem ser envolvidos no processo de planejamento de capacidade, bem como na revisão final da arquitetura do sistema. Isso irá ajudá-lo a entender melhor o sistema e estar preparado para a implantação e suporte.