Cosa è richiesto agli sviluppatori per eseguire il proprio server VM in un ambiente aziendale [chiuso]

Questo scenario è stato anche pubblicato su SO , con domande diverse per un pubblico diverso - e sono molto contento di averlo fatto poiché ho ricevuto delle ottime risposte.

Stiamo tentando di implementare un ambiente di sviluppo utilizzando la virtualizzazione per un piccolo team di 4 sviluppatori all'interno di un'organizzazione aziendale. Ciò ci consentirebbe di creare ambienti di sviluppo, test e staging separati, oltre a consentire l'accesso a nuovi sistemi operativi che sono requisiti per sistemi o strumenti che stiamo valutando.

Abbiamo riproposto una macchina esistente di classe workstation, abbiamo aggiunto 24 GB di RAM e RAID-10 e abbiamo funzionato bene fino a quando non abbiamo tentato di aggiungere la macchina al dominio.

Ora stiamo iniziando la guerra che tutti gli sviluppatori aziendali hanno dovuto combattere dall'inizio del tempo - la lotta per il controllo locale di un ambiente di sviluppo e testing. La rete e gli amministratori IT hanno sollevato una serie di preoccupazioni che vanno da "ESX Server è lo standard aziendale" a "server non consentiti su VLAN client" a "[riempire lo spazio vuoto] non è un insieme di competenze attualmente posseduto in l'organizzazione IT locale o aziendale ".

Probabilmente potremmo giustificare l'hardware a livello di produzione e il supporto IT formale (leggi: potremmo giustificare la necessità se dovessimo farlo, ma ci vorrebbe tempo e comporterebbe un sacco di mal di testa) - ma probabilmente occorrerebbero mesi per ottenere formalmente risorse IT assegnato trattando questo come un sistema di produzione - e anche se lo facessimo, probabilmente perderemmo il controllo locale che desideriamo.

Immagino che molti di voi abbiano avuto lotte simili con gli sviluppatori all'interno dell'azienda per il controllo da parte degli sviluppatori di ambienti non di produzione, quindi le mie domande sono le seguenti:

1. Quali argomenti hanno avanzato i tuoi sviluppatori che ti hanno conquistato per consentire a questi tipi di silos di esistere all'interno di aziende che dispongono di politiche di rete e di sicurezza standard che in genere (e comprensibilmente) precludono questo tipo di infrastruttura non (gestita centralmente)?
2. È solo una questione di giustificazioni tecniche o commerciali degli sviluppatori che garantiscono che la gestione delle patch e l'AV avvengano - o più di una lotta politica per il controllo e la proprietà?
3. Data la scelta, preferiresti assumere la proprietà e il supporto dell'hardware / sistema operativo mentre concedi agli sviluppatori i diritti di amministratore locale o li lascerai gestire completamente, assicurando al contempo che istituiscano la gestione patch / AV e caricandoli con responsabilità se dovessero causare problemi?
4. Se hai impedito con successo agli sviluppatori di avere il controllo locale dei "server non autorizzati" sulla tua infrastruttura, gli sviluppatori si sono appena arresi o hanno spostato (o tu) l'ambiente di sviluppo in una VLAN disconnessa / una rete completamente separata?

Un paio di ipotesi per limitare la portata di questa domanda:

1. Per ripetere, questo è per un ambiente di sviluppo - non sono richiesti carichi di produzione o supporto. Niente accessibile dall'esterno.
2. Questa non è una guerra santa tra Hyper-V e ESX (andremmo bene con entrambi - ma Hyper-V è stato selezionato poiché è "gratuito" con MSDN per questi scopi [sì, VMWare ha anche strumenti gratuiti - ma la buona gestione gli strumenti in genere non lo sono], e sarebbe più facile da gestire dagli sviluppatori locali in un "Microsoft Shop") - quindi gli argomenti a favore o contro non rientrano nell'ambito di questa domanda.
3. Il team di sviluppo ha già assicurato di gestire la gestione delle patch e l'antivirus o di integrarsi con i sistemi aziendali esistenti se l'IT lo supporterà, ma è certamente nell'ambito se si è disposti ad accettarlo o meno.

Prima di tutto, vedo alcuni motivi per cui i tuoi amministratori hanno ragione a respingere:

• L'IT è anche responsabile per la segnalazione di cose come la gestione delle patch, il software antivirus, la conformità PCI, i controlli di sicurezza annuali (o più frequenti), ecc. Non è solo una questione di avere la certezza che questo è curato, ma anche di essere in grado per dimostrarlo agli estranei.

  Ad esempio, gestisco la rete in un piccolo college e abbiamo un laboratorio di fisica con alcune macchine per la raccolta di dati per gli esperimenti degli studenti. L'unica cosa che fanno è raccogliere dati da uno strumento scientifico e stampare i risultati (su una stampante collegata direttamente) affinché gli studenti possano analizzarli e consegnarli all'istruttore. Non sono mai su Internet - anche gli aggiornamenti AV e Windows vengono applicati tramite la rete locale. L'unico motivo per cui sono collegati alla rete ed eseguono software AV è lo scopo esplicito di segnalare al mio software di monitoraggio che esistono ancora e sono attuali. È sciocco, poiché in realtà sarebbero più sicuri per rimuovere la connessione di rete, ma sono stati inizialmente pagati con una borsa di studio e quindi questi sono i miei requisiti di segnalazione.

• Piaccia o no, il tuo server di sviluppo è un sistema di produzione dal punto di vista degli sviluppatori. Dagli forse un mese e gli sviluppatori avranno difficoltà a svolgere il lavoro se si interrompe a causa dei processi che imposterai e suppongono che il server sia disponibile. Evitare / limitare situazioni in cui i lavoratori sono inattivi a causa di guasti tecnologici è una delle ragioni principali per cui le aziende utilizzano ancora dipartimenti IT centralizzati.
• Se "ESX Server è lo standard Enterprise", è necessario seguirlo. In questo momento, ci sono differenze significative tra il modo in cui hyper-v, vmware, xen e altri fanno le cose, e una macchina costruita per uno non può semplicemente supporre che funzioni bene sull'altro. Se hai intenzione di farlo, l'IT dovrà aiutare a gestirlo ad un certo punto, e non vogliono convertirlo in vmware dopo che c'è un sacco di cruft sulla macchina che potrebbe causare un problema.
• Un giorno questa macchina invecchia e richiede una manutenzione più regolare o l'impostazione di un ciclo di sostituzione standard. Perfino i nuovi server a volte hanno parti vaganti. Questa situazione atterra quasi sempre in grembo IT solo dopo che qualcosa si è rotto che impedisce alle persone di svolgere il proprio lavoro. Assumendosi tempestivamente la responsabilità del server, l'IT può fare un lavoro molto migliore, evitando di evitare interruzioni impreviste lungo la strada.
• Questo è personale, ma posso dirti che l' ultima cosa che voglio sulla mia rete è un altro desktop mascherato da server. Ho affrontato abbastanza di quegli ultimi due anni per durarmi una vita.

Detto questo, l'IT deve essere in grado di supportare questa iniziativa. Per loro non è sufficiente dire "No". Sfidali a trovare un'alternativa che soddisfi le tue esigenze (molto reali). L'unica situazione politica qui dovrebbe essere che la loro alternativa avrà probabilmente un prezzo maggiore per l'adesivo (perché stanno pianificando costi che non puoi ancora vedere), e quindi la domanda sarà chi dovrà pagarlo. L'IT non vorrà farlo perché non ha previsto il budget, ma ti perderai perché è 6 volte quello che hai speso per una soluzione di cui eri felice (per il momento).

Inoltre, sembra che potresti provare a correre prima di poter camminare. Vuoi rinnovare il tuo processo di sviluppo. Come ex sviluppatore, penso che sia grandioso. Ma non buttare via un sacco di macchine virtuali e "ambienti" (es: dev, stage, qa, ecc.). Pianifica come appariranno i nuovi processi: in che modo gli sviluppatori lavoreranno. Userete l'integrazione continua? Build automatici? Usando quale software per supportarli? Gli sviluppatori potranno spostare il codice in produzione o stadiazione o solo il QA avrà tale capacità? Hai bisogno di una messa in scena separata? Che dire di due rami di sviluppo (uno per vNext, uno per i bug con vCurrent)?

Potrebbe essere necessario un server in modo che il responsabile dello sviluppo o il manager possano risolvere tutto ciò, ma in tal caso deve essere il primo passo e la configurazione e la progettazione del processo iniziale devono essere eseguite prima che gli sviluppatori lo mettano per mano uso.

1) Quali argomenti hanno avanzato i tuoi sviluppatori che ti hanno conquistato per consentire a questi tipi di silos di esistere all'interno di aziende che hanno in atto politiche di rete e di sicurezza standard che generalmente (e comprensibilmente) precludono questo tipo di infrastruttura non (centralmente) gestita ?

Nessuna, soprattutto perché non ricopro un ruolo manageriale nella mia organizzazione, quindi nessuna di queste "cose ​​politiche" non mi coinvolge davvero. L'unico argomento che mi persuaderebbe davvero è quello di consentire qualcosa che sia esplicitamente contrario alla politica di rete ed esentato sia dal controllo che dalla visibilità del team operativo del sistema sia un gap aereo e una lettera del CYA dal capo del mio capo.

Non è che voglio davvero essere il business di dire "No", è solo che non c'è un buon modo per farla finita bene dal punto di vista del team operativo.

1. Finiamo con i server gestiti da persone il cui set di competenze primarie non gestisce i server della rete che non hanno visibilità dell'intera rete e del relativo spazio problematico. Questa non è solo una preoccupazione politica della "protezione" del territorio; ad esempio, immagina cosa succede quando uno sviluppatore attiva DHCP per qualche motivo.
2. Finiamo per gestire i server del team di sviluppo per loro. Questo è disordinato per il motivo opposto. Gli sviluppatori sono costantemente infastiditi dal fatto che stiamo correggendo questo problema (rompendo qualcosa di cui sono a conoscenza ma non lo facciamo), o che combattono per noi per abilitare funzionalità che per una serie di buoni motivi che non vogliamo abilitare. Ciò si trasforma rapidamente in un punto morto in cui il team operativo si sente gravato e molestato e il team di sviluppo si sente frustrato e ignorato.
3. Ci sono conseguenze politiche - perché poi devi spiegare a un altro dipartimento perché gli sviluppatori sono "speciali" e perché sono esentati dalla politica di rete.

2) È solo una questione di giustificazioni tecniche o commerciali degli sviluppatori che assicurano che la gestione delle patch e l'AV stiano per accadere - o più di una lotta politica per il controllo e la proprietà?

Non credo che gli sviluppatori debbano presentare un caso aziendale: è abbastanza chiaro che gli sviluppatori devono svilupparsi e per farlo hanno bisogno di un ambiente di sviluppo di qualche tipo. Per quanto riguarda la gestione delle patch e l'AV: questo è il lavoro del team operativo e faremo in modo che sia fatto. Non è che pensiamo che gli sviluppatori non possano farlo. È solo che non ci fidiamo che lo facciate bene: gli amministratori di sistema rimangono amministratori di sistema perché non si fidano di nulla per fare qualcosa di giusto, quindi non è nulla di personale. Ovviamente c'è un ovvio problema politico di sentirsi come se qualcun altro stesse "facendo il tuo lavoro", ma questo non è davvero un problema tecnico e quindi è al di fuori dell'ambito di SF.

3) Data la scelta, preferiresti assumere la proprietà e il supporto dell'hardware / sistema operativo mentre dai agli sviluppatori i diritti di amministratore locale o li lasceresti gestire completamente, assicurando al contempo che istituiscano la gestione delle patch / AV e caricandoli con responsabilità qualora dovessero causare i problemi?

Né per i motivi indicati sopra.

4) Se hai impedito con successo agli sviluppatori di avere il controllo locale dei "server non autorizzati" sulla tua infrastruttura, gli sviluppatori si sono appena arresi o hanno spostato (o tu) l'ambiente di sviluppo su una VLAN disconnessa / una rete completamente separata?

Vuoto d'aria. Il modo migliore per gestire questa situazione è fornire agli sviluppatori il loro ambiente (e il suo controllo) e quindi intercapedine d'aria o utilizzare un altro metodo robusto per separarlo dalla rete. Questo è essenzialmente il modo in cui gestiamo il wifi pubblico. Vuoi servizi wifi? Sicuro. Paghi per la connessione di rete, gestiremo i WAP, ma non toccherà mai la nostra rete. Scusate. Le tue esigenze sono solo una delle centinaia. Ci sono altre preoccupazioni che dobbiamo considerare.

Non vuoi essere nel business di dire di no, perché gli sviluppatori (che sono particolarmente tecnicamente intelligenti) troveranno comunque il modo di ottenere ciò che vogliono. Quindi fornire loro un ambiente adatto alle loro esigenze, renderli felici e quindi trovare un modo per impedire a tutto ciò che fanno nell'ambiente di sviluppo di toccare il resto della rete aziendale.

TL; DR: ti darei un server con qualunque piattaforma di virtualizzazione tu voglia su una rete fisica separata o VLAN. L'accesso al proprio ambiente di sviluppo avverrebbe tramite un singolo host bastionato che il team operativo controllerebbe e monitorerebbe. Cosa fai con la tua attività - Non sarà supportato, ma forniremo consigli e assistenza quando il tempo lo permetterà per l'amministrazione del server.

Se venissi da me con una macchina di classe workstation caricata fino in fondo con RAM consumer, HDD di qualità consumer, PSU di qualità consumer e RAID di qualità consumer, rifiuterei di inserirla anche nella rete del server.

C'è molto che devi capire sul mettere qualcosa del genere sulla VLAN del server.

1. La VLAN del server potrebbe benissimo essere una DMZ. In una DMZ non si inserisce nulla che non sia indurito e protetto. Questa è solo una macchina che hai consegnato loro, non hanno idea di cosa ci hai fatto. Significa anche patch e aggiornamenti regolari, il che significa essere gestiti centralmente. Sono sicuro che non accederò a ciascun server non gestito e applicheremo le patch a mano.

2. I componenti in quella macchina falliranno. Lo prometto. Entro 6 o 12, 24 mesi, andrà a pancia in su. Quindi, dove sono i backup? Oh, non li hai impostati? Ma ho pensato che fosse un server? Oh, è un server fornito da qualcun altro? ... e il gioco della colpa ricomincia

3. Chi si assumerà la responsabilità quando si schianta e la merda colpisce il fan? Nella maggior parte delle organizzazioni "l'ho dato agli sviluppatori di occuparsene" non volerà.

4. Dove lo metteranno? Oggi i server sono tutti montati su rack e mettere una torre in un rack spreca spazio e i loro rack potrebbero non essere progettati per questo.

Quindi, il reparto IT è molto giustificato nel non mettere questo computer casuale sulla propria rete di server.

Tuttavia , è compito dei dipartimenti IT garantire che TU possa svolgere correttamente il TUO lavoro. Devono assicurarsi di avere ciò di cui hai bisogno, quando ne hai bisogno. Se disponi di un software che l'azienda deve mantenere in esecuzione, deve fornire una piattaforma per il suo funzionamento. Questa è la descrizione del loro lavoro. Ma devi assicurarti che abbiano le informazioni di cui hanno bisogno per fare il loro lavoro.

Se tu fossi venuto da me, nella mia organizzazione, mi avessi detto che avvii un nuovo progetto, ti avrei dato tre VM: Dev, Live e Staging. Avresti pieno diritto di amministratore per Dev e discuteremo di cosa hai bisogno per fare il tuo lavoro per gli altri due. Se avessi bisogno di diritti di amministratore completi per loro e potessi giustificarlo, allora lo avresti ottenuto. Abbiamo il down-pat della nostra distribuzione VM. VMWare lo rende incredibilmente semplice: bastano circa 5 minuti per VM per distribuirlo.

Sembra che il tuo reparto IT soffra di ciò di cui soffre praticamente ogni reparto IT di una grande azienda. Costruire piccoli castelli e difenderli con la tua vita, non lasciare entrare gli altri, essere prepotenti, ecc. Come qualcuno che si occupa quotidianamente dei dipartimenti IT di altre persone, lo vedo sempre. Ed è frustrante.

Il fatto di base è tuttavia che il cambiamento deve avvenire all'interno del reparto IT e deve essere avviato dall'alto. E se riesci a far capire all'IT che non sono una forza per se stessi (dal momento che la maggior parte di loro non genera entrate per le loro attività, questo può essere piuttosto uno schiaffo in faccia) e che sono lì per supportare il personale esistente e migliorare il business, poi scoprirai che le tue domande diventano irrilevanti, perché tutti giocheranno famiglie felici.

Perché vuoi aggiungerlo al dominio? Per dirla in un altro modo, che risponde meglio alla domanda: è possibile impostare un laboratorio per fare qualsiasi cosa diavolo vuoi, purché non sia collegato alla LAN aziendale. (Se avessi bisogno di un accesso a Internet, forse potresti ottenere una VLAN basata su DMZ; questo non dovrebbe essere un problema, specialmente se lo stai usando solo per uscire , come per i download.)

Questa è una delle tante, molte, diverse risposte alla domanda.

Riceverai MOLTE risposte qui, a favore e contro gli sviluppatori che hanno accesso come amministratore a qualsiasi parte dell'ambiente (probabilmente per lo più contro), ma ecco la linea di fondo:

Il gruppo sysadmin ha il compito di mantenere i sistemi di produzione funzionanti, stabili e sicuri e sono responsabili di assicurarsi che tali sistemi forniscano i servizi che l'azienda sta pagando (perché li stanno pagando) ai livelli che si aspettano.

Allo stesso modo, il team di sviluppo è stato incaricato di fornire servizi all'azienda (web, app, ecc.), Anche se in un ambito diverso. La lotta per il controllo sull'ambiente di sviluppo è controproducente e non serve a nessuno scopo utile.

Lavoro in un piccolo ISV / ASP. Abbiamo uno sviluppatore e un amministratore di sistema (me). Abbiamo una relazione basata sul rispetto e la fiducia reciproci. Dobbiamo lavorare come una squadra per aiutare a raggiungere gli obiettivi generali dell'azienda. Offro allo sviluppatore un accesso completo e senza restrizioni al suo ambiente di sviluppo, che include workstation e server. Gestisco i sistemi di sviluppo per sicurezza, aggiornamenti, AV e hardware e lo sviluppatore fa il resto. Quando il suo codice è pronto per la produzione, me lo passa, mi assiste con qualsiasi configurazione necessaria e fa un passo indietro. Ci prestiamo reciproca assistenza.

Gli sviluppatori dovrebbero essere i padroni dell'ambiente di sviluppo e gli amministratori di sistema dovrebbero essere i padroni dell'ambiente di produzione, entro limiti ragionevoli e con verifiche, equilibri e controlli ragionevoli. Quando entrambe le parti devono "attraversare", dovrebbero essere in cooperazione e in concerto con la parte "regnante" sotto la loro competenza e guida.

Prima di tutto, la mia esperienza è strettamente in un'organizzazione più piccola, ma questo problema si presenta in aziende di tutte le dimensioni, quindi ...

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

Dal mio punto di vista, l'unico argomento che gli sviluppatori devono fare è "ne abbiamo bisogno". Se venissero da me per primi, proverei a capire i loro bisogni e vedere cosa potremmo capire. Ma alla fine, se dicono "ne abbiamo bisogno", darei loro il beneficio del dubbio e confiderei che sanno cosa stanno facendo.

Ma questo è solo l'inizio - questo è il lato "Pro" dell'equazione. Il "Con" è dove entriamo nel conflitto ...

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

Solo che "solo" è un eufemismo incredibile, sì, se gli sviluppatori possono fornire una giustificazione tecnica e commerciale, non ci sarebbe un problema. Altri qui e su programmers.SE (dove è stata eseguita la migrazione della tua domanda SO) hanno segnalato una tonnellata di insidie ​​alla tua configurazione, quindi non le ripeterò. Se ti viene in mente un piano per affrontare tutti quei problemi e qualsiasi altro il tuo dipartimento IT pensa e giustifica TUTTI i costi, allora ha senso andare avanti.

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

Questo è un antipasto, non puoi avere due gruppi con obiettivi e responsabilità diversi che cercano di gestire gli stessi sistemi. Non finirà male, inizierà male e finirà in uno spargimento di 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?

Penso che questo sia coperto dalla mia risposta a 2 .: questi sono dettagli tecnici per i quali dovrebbero trovare soluzioni.

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?

Sono d'accordo con kce: "Air-gap"

Se riescono a giustificare il sovraccarico aggiuntivo che stanno assumendo (diventando amministratori del loro ambiente) gli sviluppatori possono avere la propria mini-rete in cui dispongono di risorse gratuite, MA è completamente in quarantena: nulla tocca il resto della rete. Quindi devono trovare ulteriori giustificazioni tecniche e commerciali, ad esempio per "come faremo per eseguire il backup dei dati critici?"

Ancora una volta, sono d'accordo con kce: "Gli amministratori di sistema rimangono amministratori di sistema perché non si fidano di nulla per fare qualcosa di giusto" È nostro compito costruire i sistemi più affidabili che possiamo ricavare da componenti inaffidabili, quindi qualsiasi proposta che includa mezzo una dozzina di cose che un amministratore di sistema esperto sa che sono incredibilmente traballanti riceveranno una forte reazione negativa.

Dalle risposte e dai commenti qui e su programmers.se, penso che sia chiaro che ci sono aspetti che non hai preso in considerazione. Anche se ci vorrà più tempo, penso che tu debba davvero andare a parlare con i tuoi ragazzi IT e presentare le cose in modo diverso: "ecco cosa dobbiamo fare, c'è un modo per integrarlo nell'infrastruttura e nelle operazioni esistenti?"

Il problema generale, nel tuo e in milioni di casi simili, è:

1) Responsabilità fuzzy: non esiste un collegamento diretto tra le azioni di un lavoratore aziendale e i suoi profitti. Viene pagato per mese e non per effetti, che sono più difficili da misurare, più grande è l'organizzazione. Si applica a sicurezza, manager, ecc. Se paralizzano il tuo lavoro, non se ne curano.

2) I responsabili delle politiche e la sicurezza di solito hanno poca o nessuna conoscenza della programmazione. Non riuscivano a capire che stavano paralizzando il tuo lavoro anche se gliene sarebbe importato (cosa che di solito non si applica).

3) Il profilo psicologico preferito per il lavoro in sicurezza è la personalità paranoica o il disturbo ossessivo-compulsivo. Queste persone vedono la cospirazione ovunque. Se gli sviluppatori vogliono qualcosa, come un nuovo server, sicuramente vogliono usarlo per rubare dati aziendali e pubblicarli su WikiLeaks o venderli in Corea del Nord.