DESENV. OU INFRA.QUEM PODE MEXER NO SERVIDOR ???
Boa tarde, colegas!
Colegas, estamos com um problema aqui na TI de divisão de responsabilidades.
E peço, se possÃÂvel a opinião dos colegas:
O caso:
Somos uma empresa grande que tem dois setores de TI.
Uma TI(Infraestrutura) e outro setor de TI(Desenvolvimento).
Existe um pouco de atrito, devido ao fato de que a Infraestrutura
não quer permitir que o setor de desenvolvimento tenha acesso
aos servidores.(Por motivo de segurança).
Inclusive o setor de infra defende que o setor de desenvolvimento
não deve ter acesso a nenhuma senha de acesso aos servidores.
Minha pergunta:
Imagine que o setor de desenvolvimento crie uma aplicação Web e
tenha que hospedar a mesma num servidor qualquer da empresa.
Qual (No entender de voces) deverá ser a responsabilidade de cada setor:
1. O setor de infra deverá receber o projeto Web e colocará o mesmo em produção, ou a implantação
do projeto no servidor deve ser feita pelo própio setor de desenvolvimento?
2.) Qual é a divisão de responsabilidades que é utilizada no mercado nestes casos?
Colegas, estamos com um problema aqui na TI de divisão de responsabilidades.
E peço, se possÃÂvel a opinião dos colegas:
O caso:
Somos uma empresa grande que tem dois setores de TI.
Uma TI(Infraestrutura) e outro setor de TI(Desenvolvimento).
Existe um pouco de atrito, devido ao fato de que a Infraestrutura
não quer permitir que o setor de desenvolvimento tenha acesso
aos servidores.(Por motivo de segurança).
Inclusive o setor de infra defende que o setor de desenvolvimento
não deve ter acesso a nenhuma senha de acesso aos servidores.
Minha pergunta:
Imagine que o setor de desenvolvimento crie uma aplicação Web e
tenha que hospedar a mesma num servidor qualquer da empresa.
Qual (No entender de voces) deverá ser a responsabilidade de cada setor:
1. O setor de infra deverá receber o projeto Web e colocará o mesmo em produção, ou a implantação
do projeto no servidor deve ser feita pelo própio setor de desenvolvimento?
2.) Qual é a divisão de responsabilidades que é utilizada no mercado nestes casos?
Eu trabalhei em uma corretora de seguros que era desenvolvedor e N1 dos servidores. Depois fui para uma empresa de telecom que era desenvolvedor e cuidava do servidor de uma área que eu trabalhava.
Onde eu estou, engenheiro de dados e faço gestão (em parte) do servidor cloud. Tudo depende de onde voce trabalha. Já teve empresa que trabalhei que nem sabia onde estava o servidor.
Onde eu estou, engenheiro de dados e faço gestão (em parte) do servidor cloud. Tudo depende de onde voce trabalha. Já teve empresa que trabalhei que nem sabia onde estava o servidor.
Minha visão:
Tecnicamente, nem um, nem outro. Infra cuida de infraestrutura, desenvolvimento de desenvolver. Nenhum dos dois deveria ter acesso admin ao servidor, isso é responsabilidade de outra equipe(a de devops). Quando houver um deploy, requisita-se um ticket para o responsável pelo servidor em questão, que vai designar um implementer. Esse implementer, terá um acesso temporário de admin para o servidor e vai executar o script de implementação. Ele pode ou não ser assistido(visualmente mesmo, por call) pelos dois times(desenvolvimento e infra) e se reserva o direito de não executar tarefas que julgar perigosas. O script de deploy pode ou não ter passos manuais(qualquer coisa que não tem como ser automatizada), mas preferencialmente tudo deve ser automático, o implementer, simplesmente roda um script e repassa o resultado(algum log, também feito por quem quer que tenha feito o script de deploy).
O caso é, que desenvolvimento, mesmo tendo alguma conexão com infra, gera software. Software, pode ser sempre "empacotado" e sempre é possÃÂvel fazer uma cópia do mesmo e um script de implementação, caso necessário. Então no seu caso, acho que o time de infra(se é que são eles que cuidam fisicamente do servidor), é que tem o acesso e penso estar correto a atitude de não liberar acesso.
Por essas e outras, que uso muito docker e assemelhados. É um container que tenho total controle, faço nele o que quiser e simplesmente sobe ele pra produção e morreu o assunto.
Tecnicamente, nem um, nem outro. Infra cuida de infraestrutura, desenvolvimento de desenvolver. Nenhum dos dois deveria ter acesso admin ao servidor, isso é responsabilidade de outra equipe(a de devops). Quando houver um deploy, requisita-se um ticket para o responsável pelo servidor em questão, que vai designar um implementer. Esse implementer, terá um acesso temporário de admin para o servidor e vai executar o script de implementação. Ele pode ou não ser assistido(visualmente mesmo, por call) pelos dois times(desenvolvimento e infra) e se reserva o direito de não executar tarefas que julgar perigosas. O script de deploy pode ou não ter passos manuais(qualquer coisa que não tem como ser automatizada), mas preferencialmente tudo deve ser automático, o implementer, simplesmente roda um script e repassa o resultado(algum log, também feito por quem quer que tenha feito o script de deploy).
O caso é, que desenvolvimento, mesmo tendo alguma conexão com infra, gera software. Software, pode ser sempre "empacotado" e sempre é possÃÂvel fazer uma cópia do mesmo e um script de implementação, caso necessário. Então no seu caso, acho que o time de infra(se é que são eles que cuidam fisicamente do servidor), é que tem o acesso e penso estar correto a atitude de não liberar acesso.
Por essas e outras, que uso muito docker e assemelhados. É um container que tenho total controle, faço nele o que quiser e simplesmente sobe ele pra produção e morreu o assunto.
kERPLUNK,
Te agradeço por uma resposta tão detalhada.
No entanto, como voce bem sabe,são muito poucas
empresas no mercado que tem condição de ter uma
equipe de TI tão bem organizada. Desenvolvimento,
Infraestrutura e outra equipe somente para devops.
Mas,entendi sua intensão ao explicar que o acesso
ao servidor de aplicação deve ser somente do pessoal
que "cuida" dos servidores (No caso Aqui é a infra).
Te agradeço por uma resposta tão detalhada.
No entanto, como voce bem sabe,são muito poucas
empresas no mercado que tem condição de ter uma
equipe de TI tão bem organizada. Desenvolvimento,
Infraestrutura e outra equipe somente para devops.
Mas,entendi sua intensão ao explicar que o acesso
ao servidor de aplicação deve ser somente do pessoal
que "cuida" dos servidores (No caso Aqui é a infra).
Colega,
Em meu caso, que trabalho majoritariamente com clientes ISP (Internet Service Provider), há 3 servidores: o de fornecimento e atualização de torres, em que fica o Mkrotik, o servidor de aplicação interna (ERP) e o servidor Bastião (onde os hackers esbarram, a primeira "muralha", que soa o alerta para tentativas de invasão).
O ERP, que é minha parte, está intimamente ligado ao servidor ERP (óbvio), mas também ao servidor Mikrotik, uma vez que o ERP ao identificar pagamento ou falta de pagamento de um boleto, por exemplo, deve enviar comandos ao Mikrotik para liberar ou cortar acesso àinternet, ou mesmo direcionar o cliente para "área do cliente", uma vez que não se pode tirar totalmente a internet do cliente, senão ele não consegue acessar a área do cliente para reimprimir o boleto de pagamento ou fazer PIX.
Isto é só uma parte do problema, mas que para resolver isto, criou-se algo que funcionou para tudo: os desenvolvedores dos App, que são outra equipe de outra empresa, eu com o ERP e o pessoal do próprio cliente com a "central do cliente" (em PHP) temos um servidor de homologação, lá podemos fazer o que quiser, inclusive bagunçar dados. Cada um tem um login e dados próprios, então se eu bagunçar meus testes, não irei bagunçar os testes dos outros. E bagunçar é parte do desenvolvimento, até para testar integridade dos dados, por exemplo.
Em resumo: ao menos aqui um servidor de homologação de desenvolvimento funcionou. Quando a aplicação chega no estágio em que pode ter a versão liberada, é avisado ao coordenador de TI (que por coincidencia sou eu mesmo), que libera a atualização.
Em meu caso, que trabalho majoritariamente com clientes ISP (Internet Service Provider), há 3 servidores: o de fornecimento e atualização de torres, em que fica o Mkrotik, o servidor de aplicação interna (ERP) e o servidor Bastião (onde os hackers esbarram, a primeira "muralha", que soa o alerta para tentativas de invasão).
O ERP, que é minha parte, está intimamente ligado ao servidor ERP (óbvio), mas também ao servidor Mikrotik, uma vez que o ERP ao identificar pagamento ou falta de pagamento de um boleto, por exemplo, deve enviar comandos ao Mikrotik para liberar ou cortar acesso àinternet, ou mesmo direcionar o cliente para "área do cliente", uma vez que não se pode tirar totalmente a internet do cliente, senão ele não consegue acessar a área do cliente para reimprimir o boleto de pagamento ou fazer PIX.
Isto é só uma parte do problema, mas que para resolver isto, criou-se algo que funcionou para tudo: os desenvolvedores dos App, que são outra equipe de outra empresa, eu com o ERP e o pessoal do próprio cliente com a "central do cliente" (em PHP) temos um servidor de homologação, lá podemos fazer o que quiser, inclusive bagunçar dados. Cada um tem um login e dados próprios, então se eu bagunçar meus testes, não irei bagunçar os testes dos outros. E bagunçar é parte do desenvolvimento, até para testar integridade dos dados, por exemplo.
Em resumo: ao menos aqui um servidor de homologação de desenvolvimento funcionou. Quando a aplicação chega no estágio em que pode ter a versão liberada, é avisado ao coordenador de TI (que por coincidencia sou eu mesmo), que libera a atualização.
Na verdade,
Me corrijam os colegas se eu estiver errado.
"Não existe um procedimento padrão"
Cada empresa, define baseada no seu contexto, o que julgar mais
adequado.
Aproveito aqui , para fazer um severa critica as faculdades e
universidades de tecnologia de da informação aqui no Brasil.
Me lembro que na faculdade e mesmo depois na pós-graduação
vc é obrigado a estudar toneladas de conteúdo que jamais serão
úteis no mercado de trabalho. Mas, procedimentos básicos como estes
sobre como colocar uma aplicação com segurança em produção, sequer
são mencionados na grade curricular.
Me corrijam os colegas se eu estiver errado.
"Não existe um procedimento padrão"
Cada empresa, define baseada no seu contexto, o que julgar mais
adequado.
Aproveito aqui , para fazer um severa critica as faculdades e
universidades de tecnologia de da informação aqui no Brasil.
Me lembro que na faculdade e mesmo depois na pós-graduação
vc é obrigado a estudar toneladas de conteúdo que jamais serão
úteis no mercado de trabalho. Mas, procedimentos básicos como estes
sobre como colocar uma aplicação com segurança em produção, sequer
são mencionados na grade curricular.
Tópico encerrado , respostas não são mais permitidas