Funções e responsabilidades para um sistema de produção hospedado na Web

Question

Fui convidado para documentar o que eu acho que deveria ser a quebra de papéis e responsabilidades para o nosso sistema de produção que hospeda o aplicativo da web das empresas. Isso é em parte para começarmos a atribuir responsabilidade um pouco mais formalmente e, assim, podemos evitar que as coisas não passem pela lacuna "Achei que você fez isso". Então ...

Eu pensei em perguntar o que você acha que eles deveriam ser.

Como evidência de algum trabalho da minha parte, esta é uma visão geral do meu pensamento atual. Cada linha é uma função / responsabilidade separada. Embora uma pessoa possa ter um ou mais papéis, se um papel for dividido em várias pessoas, seria razoável ter um ponto de contato principal para ele.

• DBA
• SO etc instalado em novas máquinas
• Configuração de rede
• Software instalado como parte do nosso serviço (Tomcat etc)
• Instalando / configurando nosso software
• Solução de problemas / investigação de incidentes (pode ligar para outras pessoas com conhecimento especializado)
• Monitoramento, ou seja, instalar um software de monitoramento de configuração para apoiar outras pessoas em suas funções
• Planejamento de capacidade
• Responsabilidade geral, o cara com suas bolas no preto como eles dizem

Existem várias responsabilidades transversais (por exemplo, segurança) que talvez sejam coordenadas por alguém responsável, mesmo que o trabalho seja feito por várias pessoas.

Quaisquer pensamentos, acréscimos, remoções ou ajustes dos itens acima. Eu livremente admito estar em algum lugar fora da minha esfera de especialização neste assunto.

    

Answer 1

O tamanho da empresa e do setor influencia em grande parte a estrutura do departamento de TI. Em alguns casos, um pouco demais. Meu foco profissional é uma infra-estrutura de tecnologia da Internet.

Incentivo a separação de tarefas entre a produção primária e o suporte interno à intranet. Mesmo com uma empresa de tecnologia, haverá apenas aplicativos internos e demandas de suporte. Frequentemente, o helpdesk caberia no suporte interno da intranet. Dependendo do tamanho do seu ambiente, você poderia justificar a separação das tarefas em produção entre arquitetura e manutenção.

Eu gosto da abordagem júnior a sênior, que é bem documentada pelas descrições de cargo do SAGE para administradores de sistema . Esta é uma regra prática a seguir em geral.

Em um ambiente menor, separar as tarefas em excesso não será justificado e pode incentivar a siloing dentro de um departamento. Ambientes menores se beneficiam de conhecimentos e responsabilidades compartilhados. À medida que a empresa e o departamento de TI crescem, pode fazer sentido começar a separar as tarefas mais especificamente.

Áreas-chave, que geralmente se beneficiam de alguma separação de responsabilidades:

• Pilhas de aplicativos
• Banco de dados
• Rede
• Segurança

Eu sugeriria criar uma planilha listando as principais responsabilidades dentro de seu departamento. Isso poderia ser mais geral e identificar áreas específicas que tenham mais suporte associado a elas, como o sistema telefônico ou o sistema de tickets. Ter pessoal designado como primário e secundário, para que o conhecimento imediato possa ser compartilhado além da documentação. Isso esclarecerá as responsabilidades e elas podem ser movidas para evitar o aborrecimento, além de possibilitar o aprendizado dentro do grupo. Algumas categorias de exemplo para a matriz de responsabilidade seriam:

• Responsabilidade de SLA
  • Relatórios de tempo de atividade
  • Alterar processos de controle

• Backups

  • Políticas
  • Sistemas
  • Banco de dados

• Sistemas Operacionais

  • Windows
    • Pequenos patches
    • Grandes atualizações
    • Ajuste de desempenho
  • Linux
    • Pequenos patches
    • Grandes atualizações
    • Ajuste de desempenho
• Monitoramento
  • Sistema de alerta
  • Monitoramento histórico
  • Web analytics
• e-mail
  • Caixa de spam
  • Caixa de usuário final
  • Relé do aplicativo de produção

Essa lista continua, que será específica para sua infraestrutura e para as necessidades da sua empresa.

Eu também recomendaria considerar uma análise de habilidades, solicitando que sua equipe classificasse seu nível de habilidade em diferentes tecnologias compiladas em uma planilha. A classificação não é definitiva e não afetaria as avaliações de desempenho. Isso pode identificar possíveis lacunas em seu conjunto atual de habilidades, que é onde o foco pode ser para treinamento e contratação futura.

    

Answer 2

Você está muito perto de um primeiro rascunho, sem mais detalhes sobre seu aplicativo. Veja como obter o restante das lacunas: Crie um diagrama com cada componente ou que suporte / feeds / dependa de seu aplicativo. Certifique-se de que você tenha um nome ou equipe responsável por cada peça. Ter pelo menos outra pessoa, e de preferência não em sua equipe, fazer a mesma coisa do zero - certifique-se de ter perspectivas diferentes. Isso inclui o gerenciamento - eles provavelmente terão um ponto de vista totalmente diferente do pessoal de TI, e isso pode ser muito válido. Pode ser também uma porcaria do CYA, e isso ainda pode ser válido: -)

Veja algumas outras ideias que podem ou não se aplicar a você:

1. AV / Segurança / patches / conformidade com regulamentações. Parte disso pode já se sobrepor ao seu sistema operacional / monitoramento / pessoal de rede. A segurança e / ou a conformidade regulamentar podem precisar ser sua própria equipe.

2. Documentação - ou cada equipe pode ser obrigada a fazer o seu próprio.

3. Quem lida com comunicações com os clientes? Existe um sistema de emissão de bilhetes para os problemas do cliente? Existe uma equipe designada que lida com anúncios de manutenção ou tempo de inatividade não planejado? Se os clientes são externos, existe uma equipe interna de contas ou vendedores que gostam de ser notificados sobre essas coisas?

4. Quem lida com decisões sobre atualizações, solicitações de aprimoramento e relatórios de bugs? Isso poderia ser "produto" ou "gerenciamento de portfólio" e provavelmente se sobrepõe aos negócios.

Answer 3

Talvez não esteja dentro do escopo do que você quer, mas e o aplicativo em si? Por exemplo.: 1) E quanto ao conteúdo (se houver)? Ou seja, quais funções podem redigir, aprovar e liberar conteúdo.

2) Qual papel decide quem pode redigir / aprovar / liberar conteúdo? Qual papel então implementa isso, ie. configura os usuários com acesso apropriado para rascunho / aprovação / liberação

3) Também controle de acesso. Que papel é responsável por aprovar novos usuários e decidir o acesso que recebem e, em seguida, qual o papel é responsável pela implementação que uma vez que foi decidido? Ou seja na verdade, concedendo as permissões apropriadas para permitir que o usuário tenha acesso.