O que é necessário para os desenvolvedores executarem seu próprio servidor VM em um ambiente corporativo [fechado]

Esse cenário também foi publicado no SO , com perguntas diferentes para diferentes públicos - e estou muito feliz por ter recebido algumas respostas muito boas.

Estamos tentando implementar um ambiente de desenvolvimento usando virtualização para uma pequena equipe de 4 desenvolvedores em uma organização corporativa. Isso nos permitirá configurar ambientes separados de desenvolvimento, teste e preparação - além de permitir o acesso a novos sistemas operacionais que são requisitos para sistemas ou ferramentas que estamos avaliando.

Repropomos uma máquina de classe de estação de trabalho existente, instalamos 24 GB de RAM e RAID-10 e estávamos indo bem até tentarmos adicionar a máquina ao domínio.

Agora, estamos começando a guerra que todos os desenvolvedores empresariais, desde o início dos tempos, tiveram que enfrentar - a luta pelo controle local de um ambiente de desenvolvimento e teste. Os administradores de rede e de TI levantaram uma série de preocupações, que variam de "ESX Server é o padrão corporativo" a "servidores não permitidos em VLANs de clientes" a "[preencher o espaço em branco] não é um conjunto de habilidades atualmente possuído em organização de TI local ou empresarial ".

Provavelmente, poderíamos justificar o hardware no nível de produção e o suporte formal de TI (leia-se: justificaríamos a necessidade, se necessário, mas levaria tempo e envolveria muita dor de cabeça) - mas provavelmente levaria meses para obter formalmente os recursos de TI atribuídos tratando isso como um sistema de produção - e mesmo se o fizéssemos, provavelmente perderíamos o controle local que queremos.

Imagino que muitos de vocês tiveram lutas semelhantes com os desenvolvedores da sua empresa pelo controle do desenvolvedor em ambientes de não produção, portanto, minhas perguntas são as seguintes:

1. Quais argumentos seus desenvolvedores fizeram para conquistar esse tipo de silos em empresas que possuem políticas padrão de rede e segurança que geralmente (e compreensivelmente) impedem esse tipo de infraestrutura não (centralmente) gerenciada?
2. Isso é apenas uma questão de os desenvolvedores fazerem uma justificativa técnica ou comercial e garantirem que o gerenciamento de patches e o AV ocorram - ou mais uma luta política por controle e propriedade?
3. Dada a escolha, você prefere se apropriar e apoiar o hardware / sistema operacional enquanto concede direitos de administrador local aos desenvolvedores ou deixa que eles o gerenciem completamente, garantindo que eles instituam o gerenciamento de patches / AV e cobrando a responsabilidade deles, caso causem problemas?
4. Se você impediu os desenvolvedores de terem o controle local de "servidores não autorizados" em sua infraestrutura, eles acabaram de pagar ou moveram (ou você) o ambiente de desenvolvimento para uma VLAN desconectada / rede totalmente separada?

Algumas suposições para limitar o escopo desta pergunta:

1. Para reiterar, isso é para um ambiente de desenvolvimento - nenhuma carga de produção ou suporte é necessário. Nada acessível externamente.
2. Esta não é uma guerra santa entre o Hyper-V e o ESX (não aceitaria isso - mas o Hyper-V foi selecionado porque é "gratuito" com o MSDN para esses fins [sim, o VMWare também possui ferramentas gratuitas - mas o bom gerenciamento as ferramentas geralmente não são] e seria mais fácil de gerenciar pelos desenvolvedores locais em uma "Microsoft Shop"). Portanto, argumentos a favor ou contra estão fora do escopo desta pergunta.
3. A equipe de desenvolvedores já fez garantias para gerenciar o gerenciamento de patches e antivírus ou integrar-se aos sistemas corporativos existentes se a TI oferecer suporte - mas certamente está dentro do escopo se você deseja ou não aceitar isso.

Primeiro de tudo, vejo algumas razões pelas quais seus administradores têm razão em reagir:

• A TI também é responsável por relatar coisas como gerenciamento de patches, software antivírus, conformidade com PCI, auditorias anuais (ou mais frequentes) de segurança, etc. Não se trata apenas de ter a garantia de que isso é resolvido, mas também de poder para provar isso para pessoas de fora.

  Como exemplo, eu administro a rede em uma pequena faculdade e temos um laboratório de física com algumas máquinas de coleta de dados para experiências com os alunos. A única coisa que eles fazem é coletar dados de um instrumento científico e imprimir os resultados (em uma impressora conectada diretamente) para o aluno analisar e entregar ao instrutor. Eles nunca estão na Internet - até as atualizações do AV e do Windows são aplicadas pela rede local. A única razão pela qual eles estão conectados à rede e executam o software AV é o objetivo explícito de relatar ao meu software de monitoramento que eles ainda existem e são atuais. É bobagem, pois, na realidade, eles seriam mais seguros para remover a conexão de rede, mas foram pagos primeiro com uma bolsa de estudos e, portanto, esses são os meus requisitos de relatório.

• Goste ou não, seu servidor de desenvolvimento é um sistema de produção do ponto de vista dos desenvolvedores. Reserve um mês, talvez, e os desenvolvedores terão dificuldade em realizar o trabalho se for interrompido por causa dos processos que você configurará e assumem que o servidor está disponível. Evitar / limitar situações em que os funcionários ficam ociosos devido a falhas de tecnologia é um grande motivo para as empresas ainda usarem departamentos de TI centralizados.
• Se "ESX Server for o Enterprise Standard", você precisará seguir isso. No momento, existem diferenças significativas entre como o hyper-v, o vmware, o xen e os outros fazem as coisas, e não se pode presumir que uma máquina criada para um funcione bem no outro. Se você fizer isso, a TI precisará ajudar a gerenciá-lo em algum momento, e eles não querem convertê-lo em vmware depois que houver um monte de lixo na máquina que possa causar um problema.
• Algum dia, esta máquina ficará velha e precisará de manutenção mais regular ou da criação de um ciclo de substituição padrão. Até novos servidores às vezes têm partes ruins. Essa situação quase sempre cai no colo da TI somente depois que algo quebra que impede as pessoas de fazerem seu trabalho. Ao assumir a responsabilidade pelo servidor mais cedo, a TI pode fazer um trabalho muito melhor, evitando interrupções não planejadas no caminho.
• Isso é pessoal, mas posso dizer que a última coisa que quero na minha rede é outra área de trabalho disfarçada de servidor. Eu lidei com o suficiente deles nos últimos dois anos para durar uma vida inteira.

Dito isto, a TI precisa ser capaz de apoiar esta iniciativa. Não basta dizer apenas "não". Desafie-os a encontrar uma alternativa que atenda às suas necessidades (muito reais). A única situação política aqui deve ser que a alternativa deles provavelmente terá um preço maior de etiqueta (porque eles estão planejando custos que você ainda não pode ver) e, portanto, a questão será quem deve pagar por isso. A TI não vai querer, porque eles não fizeram um orçamento para isso, mas você vai recusar porque é 6 vezes o que você gastou em uma solução com a qual estava feliz (no momento).

Além disso, parece que você pode estar tentando correr antes de poder andar. Você deseja renovar seu processo de desenvolvimento. Como ex-desenvolvedor, acho isso ótimo. Mas não jogue fora apenas um monte de VMs e "ambientes" (ou seja: dev, stage, qa, etc). Planeje como serão os novos processos - como os desenvolvedores farão o trabalho. Você usará a integração contínua? Compilações automatizadas? Usando qual software para apoiá-los? Os desenvolvedores terão permissão para mover o código para produção ou preparação, ou apenas o controle de qualidade terá essa capacidade? Você precisa de uma preparação separada? Que tal duas ramificações de desenvolvimento (uma para vNext e outra para bugs com vCurrent)?

Você pode precisar de um servidor apenas para que o líder ou gerente de desenvolvimento possa resolver tudo isso, mas, nesse caso, esse deve ser o primeiro passo, e a configuração e o design do processo inicial precisam ser feitos antes que os desenvolvedores o coloquem em prática. usar.

1) Quais argumentos seus desenvolvedores fizeram para conquistar esses tipos de silos em empresas que possuem políticas padrão de rede e segurança que geralmente (e compreensivelmente) impedem esse tipo de infraestrutura não gerenciada (centralmente) ?

Nenhuma - principalmente porque eu não desempenho um papel de gerenciamento em minha organização, para que nenhuma dessas "coisas políticas" realmente me envolva. O único argumento que realmente me convenceu é permitir algo que seja explicitamente contrário à política de rede e isento do controle e da visibilidade da equipe de operações do sistema é uma lacuna de ar e uma carta do CYA do chefe do meu chefe.

Não é que eu realmente queira dizer "Não", é apenas que não há uma maneira boa de que isso termine bem do ponto de vista da equipe de operação.

1. Terminamos com servidores gerenciados por pessoas cujo conjunto de habilidades principal não está gerenciando servidores na rede que não têm visibilidade de toda a rede e seu espaço de problemas associado. Esta não é apenas uma preocupação política de "proteger" o território; como um exemplo trivial, imagine o que acontece quando um desenvolvedor ativa o DHCP por algum motivo.
2. Acabamos gerenciando os servidores da equipe de desenvolvimento para eles. Isso é confuso pela razão oposta. Os desenvolvedores estão constantemente irritados com o fato de estarmos corrigindo isso (quebrando algo que eles sabem, mas não sabemos), ou a luta deles por ativar recursos que, por uma variedade de boas razões, não queremos ser ativados. Isso rapidamente se transforma em um impasse, onde a equipe de operações se sente sobrecarregada e assediada e a equipe de desenvolvimento se sente frustrada e ignorada.
3. Há consequências políticas - porque você precisa explicar a outro departamento por que os desenvolvedores são "especiais" e por que são isentos da política de rede.

2) Isso é apenas uma questão de os desenvolvedores fazerem uma justificativa técnica ou comercial e garantirem que o gerenciamento de patches e o AV ocorram - ou mais uma luta política por controle e propriedade?

Eu não acho que os desenvolvedores precisem apresentar um caso de negócios - é bastante claro que eles precisam desenvolver um ambiente de desenvolvimento de algum tipo. Quanto ao gerenciamento de patches e AV - esse é o trabalho da equipe de operações e garantiremos que isso seja feito. Não é que pensemos que os desenvolvedores não possam fazer isso. Só não confiamos que você faça o que é certo - os Administradores do Sistema permanecem como Administradores do Sistema, porque não confiam em nada para fazer o que é certo, por isso não é nada pessoal. É claro que há uma questão política óbvia de sentir que alguém está "fazendo seu trabalho", mas isso não é realmente um problema técnico e, portanto, está fora do escopo do SF.

3) Dada a escolha, você prefere assumir a propriedade e o suporte do hardware / sistema operacional enquanto concede direitos de administrador local aos desenvolvedores, ou permite que eles o gerenciem completamente, garantindo que eles instituam o gerenciamento de patches / AV e cobrando-os de responsabilidade caso causem problemas?

Nem pelas razões descritas acima.

4) Se você bloqueou com êxito os desenvolvedores de terem controle local de "servidores não autorizados" em sua infraestrutura, os desenvolvedores acabaram de pagar ou moveram (ou você) o ambiente de desenvolvimento para uma VLAN desconectada / rede totalmente separada?

Abertura de ar. A melhor maneira de lidar com essa situação é fornecer aos desenvolvedores seu ambiente (e controle) e, em seguida, fazer uma brecha no ar ou usar outro método robusto para separá-lo da rede. É essencialmente assim que lidamos com o wifi público. Você quer serviços wifi? Certo. Se você pagar pela conexão de rede, gerenciaremos os WAPs, mas isso nunca afetará nossa rede. Desculpa. Suas necessidades são apenas uma das centenas. Há outras preocupações que devemos considerar.

Você não quer dizer não, porque os desenvolvedores (que são particularmente tecnicamente inteligentes) encontrarão maneiras de conseguir o que querem de qualquer maneira. Portanto, forneça a eles um ambiente que atenda às suas necessidades, faça-os felizes e, em seguida, encontre uma maneira de impedir que qualquer coisa que eles façam no ambiente de desenvolvimento toque no restante da sua rede de negócios.

TL; DR: eu daria a você um servidor com qualquer plataforma de virtualização que você quisesse em uma rede física separada ou em uma VLAN. O acesso ao seu ambiente de desenvolvimento seria através de um único host bastião que a equipe de operações controlaria e monitoraria. O que você faz com o seu negócio - ele não será suportado, mas forneceremos conselhos e ajuda sempre que o tempo permitir para a administração do servidor.

Se você viesse a mim com uma máquina de classe de estação de trabalho carregada ao máximo com RAM, HDDs, PSU e RAID de consumo, eu me recusaria a colocá-lo também na rede de servidores.

Você precisa entender muito sobre colocar algo assim na VLAN do servidor.

1. A VLAN do servidor pode muito bem ser uma DMZ. Em uma DMZ, você não coloca nada que não seja reforçado e protegido. Esta é apenas uma máquina que você entregou a eles, eles não têm idéia do que você fez com ela. Também significa atualizações e patches regulares, o que significa ser gerenciado centralmente. Tenho certeza de que não vou entrar em cada servidor não gerenciado e aplicar patches manualmente.

2. Os componentes nessa máquina irão falhar. Eu prometo. Dentro de 6 ou 12, 24 meses, ele vai ficar de barriga para cima. Então, onde estão os backups? Oh, você não os configurou? Mas, eu pensei que era um servidor? Ah, é um servidor que outra pessoa provisionou? ... e o jogo da culpa começa de novo

3. Quem assumirá a responsabilidade quando bater e a merda atingir o ventilador? Na maioria das organizações, "eu dei para os desenvolvedores cuidarem" não vai voar.

4. Onde eles vão colocá-lo? Atualmente, os servidores estão montados em rack e colocar uma torre em um rack desperdiça espaço e seus racks podem não ser projetados para isso.

Portanto, o departamento de TI tem muita justificativa para não colocar esse computador aleatório em sua rede de servidores.

No entanto , é tarefa dos departamentos de TI garantir que VOCÊ possa fazer SEU trabalho corretamente. Eles precisam garantir que você tenha o que precisa, quando precisar. Se você possui um software que a empresa precisa para continuar funcionando, eles precisam fornecer uma plataforma para que ele funcione. Essa é a descrição do trabalho deles. Mas você precisa garantir que eles tenham as informações necessárias para realizar seu trabalho.

Se você tivesse vindo até mim, na minha organização, me dissesse que estava iniciando um novo projeto, eu lhe daria três VMs: Dev, Live e Staging. Você teria direitos totais de administrador para o Dev e discutiríamos o que você precisava fazer no seu trabalho pelos outros dois. Se você precisasse de todos os direitos de administrador e pudesse justificá-lo, você o conseguiria. Temos nossa implantação de VM inativa. O VMWare torna isso incrivelmente simples - leva apenas 5 minutos por VM para implementá-lo.

Parece que seu departamento de TI sofre com o que praticamente todos os departamentos de TI de uma grande empresa sofrem. Construir pequenos castelos e defendê-los com a sua vida, sem deixar os outros entrarem, ser mandão, etc. Como alguém que lida com os departamentos de TI de outras pessoas todos os dias, eu vejo isso o tempo todo. E é frustrante.

O fato básico é que a mudança precisa ocorrer de dentro do departamento de TI e deve ser iniciada de cima deles. E se você conseguir que a TI perceba que eles não são uma força para si mesmos (como a maioria deles não gera renda para seus negócios, isso pode ser um tapa na cara) e que eles estão lá para apoiar a equipe existente e aprimore os negócios, você descobrirá que suas perguntas se tornam irrelevantes, porque todo mundo estará representando famílias felizes.

Por que você deseja adicioná-lo ao domínio? Em outras palavras, que responde melhor à pergunta: você pode configurar um laboratório para fazer o que quiser, desde que não esteja conectado à LAN corporativa. (Se você precisou de acesso à Internet, talvez possa obter uma VLAN com DMZ-ed; isso não deve ser um problema, especialmente se você estiver usando apenas para sair , como para downloads.)

Essa é uma, de muitas, muitas respostas diferentes para a pergunta.

Você receberá muitas respostas aqui, a favor e contra desenvolvedores com acesso de administrador a qualquer parte do ambiente (provavelmente principalmente contra), mas aqui está a linha de fundo:

O grupo sysadmin é encarregado de manter os sistemas de produção em funcionamento, estáveis ​​e seguros e é responsável por garantir que esses sistemas forneçam os serviços pelos quais a empresa está pagando (porque eles estão pagando por eles) nos níveis esperados.

Da mesma forma, a equipe de desenvolvimento foi encarregada de fornecer serviços à empresa (web, aplicativos etc.), embora em uma arena diferente. Lutar pelo controle do ambiente de desenvolvimento é contraproducente e não serve a nenhum propósito útil para nenhum dos lados.

Eu trabalho em um pequeno ISV / ASP. Temos um desenvolvedor e um administrador de sistemas (eu). Temos um relacionamento baseado em respeito e confiança mútuos. Precisamos trabalhar em equipe para ajudar a alcançar os objetivos gerais da empresa. Eu concedo ao desenvolvedor acesso completo e sem restrições ao seu ambiente de desenvolvimento, que inclui estações de trabalho e servidores. Eu gerencio os sistemas de desenvolvimento para segurança, atualizações, antivírus e hardware, e o desenvolvedor faz o resto. Quando seu código está pronto para produção, ele me entrega, me ajuda com qualquer configuração necessária e recua. Prestamos assistência mútua.

Os desenvolvedores devem ser os donos do ambiente de desenvolvimento e os administradores de sistemas devem ser os donos do ambiente de produção, dentro de limites razoáveis ​​e com verificações, balanços e controles razoáveis. Quando um dos lados precisa "atravessar", ele deve estar em cooperação e em concerto com o partido "reinante", sob sua competência e orientação.

Primeiro de tudo, minha experiência é estritamente em uma organização menor, mas esse problema surge em empresas de todos os tamanhos, então ...

1.  What arguments have your developers made that won you over to
allow these types of silos to exist within enterprises which have
standard network and security policies in

Do meu ponto de vista, o único argumento que os desenvolvedores precisam fazer é "precisamos disso". Se eles me procurassem primeiro, tentaria entender as necessidades deles e ver o que poderíamos resolver. Mas, em última análise, se eles disserem "precisamos disso", eu daria a eles o benefício da dúvida e confiaria que eles sabem o que estão fazendo.

Mas isso é apenas o começo - esse é o lado "Pro" da equação. O "Con" é onde entramos na disputa ...

2. Is this just a matter of the developers making a technical or
business justification

Exceto que "just" é um eufemismo incrível, sim, se os desenvolvedores puderem fazer uma justificativa técnica e comercial, não haveria problema. Outros aqui e nos programadores.SE (para onde sua pergunta de SO foi migrada) apontaram várias armadilhas para sua configuração, por isso não vou repeti-las. Se você elaborar um plano para lidar com todos esses problemas e com qualquer outro em que seu departamento de TI pense e justifique TODOS os custos, faz sentido prosseguir.

3.  Given the choice, would you prefer to take ownership and support
of the hardware/OS while giving devs local admin rights,

Este é um não iniciante, você não pode ter dois grupos com objetivos e responsabilidades diferentes tentando gerenciar os mesmos sistemas. Não terminará mal, começará mal e terminará em derramamento de sangue.

(more of 3.) ... or let them manage it entirely, while ensuring that
they institute patch management/AV and charging them with
responsibility should they cause problems?

Eu acho que isso é coberto pela minha resposta a 2 .: esses são detalhes técnicos para os quais eles teriam que encontrar soluções.

4.  If you successfully blocked developers from having local control
of "rogue servers" on your infrastructure, did the developers just
make due or did they (or you) move the development environment to a
disconnected VLAN/entirely separate network?

Eu concordo com o kce: "Air-gap"

Se eles puderem justificar a sobrecarga adicional que estão assumindo (tornando-se administradores de seu ambiente), os desenvolvedores podem ter sua própria mini-rede onde têm rédea livre, MAS fica completamente em quarentena: nada afeta o resto da rede. Portanto, eles precisam apresentar mais justificativas técnicas e comerciais, por exemplo, para "como vamos fazer backup de dados críticos?"

Novamente, eu tenho que concordar com o kce: "Os administradores de sistema permanecem como administradores do sistema porque não confiam em nada para fazer o que é certo". É nosso trabalho construir os sistemas mais confiáveis ​​que pudermos com componentes não confiáveis, portanto, qualquer proposta que inclua meio dezenas de coisas que um administrador de sistemas experiente sabe que são incrivelmente escamosas terão uma forte reação negativa.

A partir das respostas e comentários aqui e no programmers.se, acho claro que há aspectos que você não considerou. Embora demore mais, acho que você realmente precisa conversar com o pessoal de TI e apresentar as coisas de maneira diferente: "eis o que precisamos fazer: existe alguma maneira de integrar isso à infraestrutura e às operações existentes?"

O problema geral, nos seus e em milhões de casos semelhantes, é:

1) Responsabilidade confusa - não há conexão direta entre as ações de um trabalhador corporativo e seus lucros. Ele é pago por mês, e não pelos efeitos, que são mais difíceis de medir, quanto maior a organização. Isso se aplica à segurança, aos gerentes etc. Se eles paralisarem o seu trabalho, eles não se importarão.

2) Os formuladores de políticas e a segurança geralmente têm pouco ou nenhum conhecimento sobre programação. Eles não conseguiam entender que estão paralisando seu trabalho, mesmo que se importassem (o que geralmente não se aplica).

3) O perfil psicológico preferido para o trabalho em segurança é a personalidade paranóica ou transtorno obsesivo-compulsivo. Essas pessoas veem a conspiração em todos os lugares. Se os desenvolvedores querem algo, como um novo servidor, certamente querem usá-lo para roubar dados corporativos e publicá-los no WikiLeaks, ou vender para a Coréia do Norte.