Éléments requis pour que les développeurs exécutent leur propre serveur VM dans un environnement d'entreprise [fermé]

Ce scénario a également été publié sur SO , avec différentes questions pour différents publics - et je suis très heureux de l'avoir fait car j'ai reçu de très bonnes réponses.

Nous tentons de mettre en œuvre un environnement de développement utilisant la virtualisation pour une petite équipe de 4 développeurs au sein d'une organisation d'entreprise. Cela nous permettrait de mettre en place des environnements de développement, de test et de mise en scène séparés - ainsi que de permettre l'accès à de nouveaux systèmes d'exploitation qui sont des exigences pour les systèmes ou les outils que nous évaluons.

Nous avons redéfini une machine existante de classe station de travail, ajouté 24 Go de RAM et RAID-10, et nous nous en sortions bien jusqu'à ce que nous tentions de faire ajouter la machine au domaine.

Maintenant, nous commençons la guerre que tous les développeurs d'entreprise ont dû combattre depuis la nuit des temps - la lutte pour le contrôle local d'un environnement de développement et de test. Le réseau et les administrateurs informatiques ont soulevé un certain nombre de préoccupations allant de "ESX Server est la norme d'entreprise" à "les serveurs ne sont pas autorisés sur les VLAN clients" à "[remplir-le-blanc] n'est pas un ensemble de compétences actuellement l'organisation informatique locale ou d'entreprise ".

Nous pourrions probablement justifier le matériel de production et le support informatique formel (lire: nous pourrions justifier le besoin si nous le devions, mais cela prendrait du temps et impliquerait beaucoup de maux de tête) - mais cela prendrait probablement des mois pour obtenir formellement des ressources informatiques attribué en le traitant comme un système de production - et même si nous le faisions, nous perdrions probablement le contrôle local que nous voulons.

J'imagine que beaucoup d'entre vous ont eu des difficultés similaires avec les développeurs au sein de votre entreprise pour contrôler les environnements de non-production, donc mes questions sont les suivantes:

1. Quels arguments vos développeurs ont-ils avancés pour vous convaincre de permettre à ces types de silos d'exister au sein des entreprises disposant de réseaux et de politiques de sécurité standard qui empêcheraient généralement (et de manière compréhensible) ce type d'infrastructure non gérée (de manière centralisée)?
2. S'agit-il simplement de la justification technique ou commerciale des développeurs et de la garantie de la gestion des correctifs et de l'AV - ou plutôt d'une lutte politique pour le contrôle et la propriété?
3. Si vous avez le choix, préféreriez-vous vous approprier et prendre en charge le matériel / le système d'exploitation tout en accordant aux développeurs les droits d'administrateur local, ou les laisser le gérer entièrement, tout en veillant à ce qu'ils mettent en place la gestion des correctifs / AV et en les chargeant de la responsabilité en cas de problème?
4. Si vous avez réussi à empêcher les développeurs d'avoir le contrôle local des "serveurs escrocs" sur votre infrastructure, les développeurs ont-ils simplement dû le faire ou ont-ils (ou vous) déplacé l'environnement de développement vers un VLAN déconnecté / un réseau entièrement séparé?

Quelques hypothèses pour limiter la portée de cette question:

1. Pour réitérer, c'est pour un environnement de développement - aucune charge de production ou supportabilité n'est requise. Rien accessible de l'extérieur.
2. Ce n'est pas une guerre sainte Hyper-V vs ESX (nous serions d'accord avec les deux - mais Hyper-V a été sélectionné car il est "gratuit" avec MSDN à ces fins [oui, VMWare a aussi des outils gratuits - mais la bonne gestion les outils ne le sont généralement pas], et seraient plus faciles à gérer par les développeurs locaux dans une "boutique Microsoft") - les arguments pour ou contre sont donc hors de portée de cette question.
3. L'équipe de développement a déjà donné l'assurance de gérer la gestion des correctifs et des antivirus, ou de s'intégrer aux systèmes d'entreprise existants si le service informatique le prend en charge - mais il est certainement possible que vous acceptiez cela ou non.

Tout d'abord, je vois quelques raisons pour lesquelles vos administrateurs ont raison de repousser:

• Le service informatique est également responsable du reporting sur des sujets tels que la gestion des correctifs, les logiciels antivirus, la conformité pci, les audits de sécurité annuels (ou plus fréquents), etc. pour le prouver aux étrangers.

  Par exemple, je gère le réseau dans une petite université et nous avons un laboratoire de physique avec quelques machines de collecte de données pour les expériences des étudiants. La seule chose qu'ils font est de collecter les données d'un instrument scientifique et d'imprimer les résultats (sur une imprimante directement connectée) pour que l'étudiant les analyse et les remette à l'instructeur. Ils ne sont jamais sur Internet - même les mises à jour AV et Windows sont appliquées via le réseau local. La seule raison pour laquelle ils sont connectés au réseau et exécutent un logiciel AV du tout est le but explicite de signaler à mon logiciel de surveillance qu'ils existent toujours et sont à jour. C'est idiot, car ils seraient en réalité plus sûrs de supprimer la connexion réseau, mais ils ont d'abord été payés avec une bourse d'études et ce sont donc mes exigences en matière de rapports.

• Qu'on le veuille ou non, votre serveur de développement est un système de production du point de vue des développeurs. Donnez-lui peut-être un mois, et les développeurs auront du mal à faire le travail s'il tombe en panne à cause des processus que vous allez mettre en place en supposant que le serveur est disponible. Éviter / limiter les situations où les travailleurs sont inactifs en raison de défaillances technologiques est une raison majeure pour laquelle les entreprises utilisent toujours des services informatiques centralisés.
• Si "ESX Server est la norme d'entreprise", vous devez suivre cela. À l'heure actuelle, il existe des différences importantes entre la façon dont hyper-v, vmware, xen et les autres font les choses, et une machine conçue pour l'un ne peut pas simplement être supposée fonctionner correctement sur l'autre. Si vous allez faire cela, le service informatique devra aider à le gérer à un moment donné, et ils ne veulent pas avoir à le convertir en vmware après qu'il y ait un tas de cruches sur la machine qui pourraient causer un problème.
• Un jour, cette machine vieillira et aura besoin d'un entretien plus régulier ou d'un cycle de remplacement standard. Même les nouveaux serveurs ont parfois des parties défectueuses. Cette situation arrive presque toujours sur les genoux de l'informatique seulement après que quelque chose s'est cassé qui empêche les gens de faire leur travail. En assumant tôt la responsabilité du serveur, le service informatique peut faire un bien meilleur travail en évitant les pannes imprévues en cours de route.
• Celui-ci est personnel, mais je peux vous dire que la dernière chose que je veux autour de mon réseau est un autre bureau se faisant passer pour un serveur. J'ai traité assez de ces dernières années pour me durer toute une vie.

Cela dit, l'informatique doit pouvoir soutenir cette initiative. Il ne leur suffit pas de dire "non". Mettez-les au défi de trouver une alternative qui réponde à vos besoins (bien réels). La seule situation politique ici devrait être que leur alternative a probablement un prix plus élevé (car ils prévoient des coûts que vous ne pouvez pas encore voir), et donc la question sera de savoir qui doit payer pour cela. Le service informatique ne le voudra pas, car il n'a pas prévu de budget, mais vous rechignerez parce que c'est 6 fois ce que vous avez dépensé pour une solution qui vous a plu (pour le moment).

De plus, il semble que vous essayiez de courir avant de pouvoir marcher. Vous souhaitez réorganiser votre processus de développement. En tant qu'ancien développeur, je pense que c'est super. Mais ne vous contentez pas de jeter un tas de machines virtuelles et d '"environnements" (par exemple: dev, stage, qa, etc.). Planifiez à quoi ressembleront les nouveaux processus - comment les développeurs feront leur travail. Allez-vous utiliser l'intégration continue? Constructions automatisées? En utilisant quel logiciel pour les soutenir? Les développeurs seront-ils autorisés à déplacer le code vers la production ou la mise en scène, ou seul le contrôle qualité aura-t-il cette capacité? Avez-vous besoin d'une mise en scène séparée? Qu'en est-il de deux branches de développement (une pour vNext, une pour les bogues avec vCurrent)?

Vous pourriez avoir besoin d'un serveur juste pour que le responsable du développement ou le gestionnaire puisse travailler tout cela, mais si c'est le cas, cela doit être la première étape, et la configuration et la conception du processus initial doivent être effectuées avant que les développeurs ne mettent la main dessus pour de vrai utilisation.

1) Quels arguments vos développeurs ont-ils avancés pour vous convaincre de permettre à ces types de silos d'exister dans des entreprises qui ont des politiques de réseau et de sécurité standard en place qui empêcheraient généralement (et de manière compréhensible) ce type d'infrastructure non gérée (de manière centralisée) ?

Aucune - principalement parce que je ne joue pas de rôle de gestion dans mon organisation, donc aucune de ces "choses politiques" ne m'implique vraiment. Le seul argument qui pourrait vraiment me convaincre est d'autoriser quelque chose qui est explicitement contraire à la politique du réseau et exempté à la fois du contrôle et de la visibilité de l'équipe d'exploitation du système est un espace aérien et une lettre de l'ACY du patron de mon patron.

Ce n'est pas que je veuille vraiment être une entreprise de dire "Non", c'est juste qu'il n'y a pas de bon moyen pour que cela se termine bien du point de vue de l'équipe d'exploitation.

1. Nous nous retrouvons avec des serveurs gérés par des personnes dont l'ensemble de compétences principal n'est pas la gestion de serveurs sur le réseau qui n'ont pas de visibilité sur l'ensemble du réseau et son espace de problème associé. Ce n'est pas seulement une préoccupation politique de «protéger» le gazon; comme exemple banal, imaginez ce qui se passe lorsqu'un développeur active DHCP pour une raison quelconque.
2. Nous finissons par gérer les serveurs de l'équipe de développement pour eux. C'est désordonné pour la raison opposée. Les développeurs sont constamment ennuyés que nous corrigions cela (brisant quelque chose qu'ils connaissent mais que nous ne savons pas), ou qu'ils se battent pour nous afin d'activer des fonctionnalités que, pour diverses bonnes raisons, nous ne voulons pas activer. Cela se transforme rapidement en une impasse où l'équipe des opérations se sent accablée et harcelée et l'équipe de développement se sent frustrée et ignorée.
3. Il y a des conséquences politiques - car alors vous devez expliquer à un autre département pourquoi les développeurs sont "spéciaux" et pourquoi ils sont exemptés de la politique de réseau.

2) S'agit-il simplement de la justification technique ou commerciale des développeurs et de la garantie de la gestion des correctifs et de l'AV - ou plutôt d'une lutte politique pour le contrôle et la propriété?

Je ne pense pas que les développeurs aient besoin de faire une analyse de rentabilisation - il est assez clair que les développeurs doivent développer et pour ce faire, ils ont besoin d'un environnement de développement d'une certaine sorte. En ce qui concerne la gestion des correctifs et AV - c'est le travail de l'équipe d'exploitation et nous veillerons à ce que cela soit fait. Ce n'est pas que nous pensons que les développeurs ne peuvent pas le faire. C'est juste que nous n'avons pas confiance que vous le faites correctement - les administrateurs système restent des administrateurs système car ils ne font confiance à rien pour faire quoi que ce soit de bien, donc ce n'est rien de personnel. Bien sûr, il y a un problème politique évident de se sentir comme si quelqu'un d'autre "faisait son travail", mais ce n'est pas vraiment un problème technique et est donc hors de portée de SF.

3) Si vous avez le choix, préféreriez-vous vous approprier et prendre en charge le matériel / le système d'exploitation tout en accordant aux développeurs les droits d'administrateur local, ou les laisser le gérer entièrement, tout en veillant à ce qu'ils instituent la gestion des correctifs / AV et en les chargeant de la responsabilité s'ils causent problèmes?

Ni pour les raisons décrites ci-dessus.

4) Si vous avez réussi à empêcher les développeurs d'avoir le contrôle local des "serveurs escrocs" sur votre infrastructure, les développeurs ont-ils simplement dû le faire ou ont-ils (ou vous) déplacé l'environnement de développement vers un VLAN déconnecté / un réseau entièrement séparé?

Trou d'air. La meilleure façon de gérer cette situation est de donner aux développeurs leur environnement (et le contrôle de celui-ci), puis de créer un espace d'air ou d'utiliser une autre méthode robuste pour le séparer du réseau. C'est essentiellement ainsi que nous gérons le wifi public. Vous souhaitez des services wifi? Sûr. Vous payez pour la connexion réseau, nous gérerons les WAP, mais cela ne touchera jamais notre réseau. Désolé. Vos besoins ne sont que l'un des centaines. Il y a d'autres préoccupations que nous devons considérer.

Vous ne voulez pas dire non, car les développeurs (qui sont particulièrement intelligents sur le plan technique) trouveront de toute façon des moyens d'obtenir ce qu'ils veulent. Alors, offrez-leur un environnement qui convient à leurs besoins, faites-leur plaisir et trouvez un moyen d'empêcher que tout ce qu'ils font dans l'environnement de développement ne touche le reste de votre réseau d'entreprise.

TL; DR: Je vous donnerais un serveur avec la plate-forme de virtualisation que vous vouliez sur un réseau physique séparé ou un VLAN. L'accès à votre environnement de développement se ferait via un hôte bastion unique que l'équipe d'exploitation contrôlerait et surveillerait. Ce que vous en faites dans votre entreprise - Il ne sera pas pris en charge, mais nous vous fournirons des conseils et de l'aide si le temps le permet pour l'administration des serveurs.

Si vous veniez à moi avec une machine de classe station de travail chargée sur la poignée avec une RAM de qualité grand public, des disques durs de qualité grand public, une alimentation de qualité grand public et un RAID grand public, je refuserais de le mettre sur le réseau du serveur aussi.

Il y a beaucoup de choses que vous devez comprendre pour mettre quelque chose comme ça sur le VLAN du serveur.

1. Le VLAN serveur peut très bien être une DMZ. Dans une DMZ, vous ne mettez rien qui ne soit durci et sécurisé. C'est juste une machine que vous leur avez remise, ils n'ont aucune idée de ce que vous en avez fait. Cela signifie également des correctifs et des mises à jour réguliers, ce qui signifie une gestion centralisée. Je suis sûr que je ne vais pas me connecter à chaque serveur non géré et appliquer des correctifs à la main.

2. Les composants de cette machine vont échouer. Je promets. Dans 6 ou 12, 24 mois, ça va remonter. Alors, où sont les sauvegardes? Oh, tu ne les as pas installés? Mais, je pensais que c'était un serveur? Oh, c'est un serveur que quelqu'un d'autre a provisionné? ... et le jeu du blâme recommence

3. Qui va prendre la responsabilité quand ça tombe en panne et que la merde frappe le fan? Dans la plupart des organisations, «je l'ai donné aux développeurs pour qu'ils s'en occupent» ne va pas voler.

4. Où vont-ils le mettre? Les serveurs sont tous montés en rack de nos jours et placer une tour dans un rack gaspille de l'espace et leurs racks peuvent ne pas être conçus pour cela.

Ainsi, le service informatique a tout à fait raison de ne pas mettre cet ordinateur aléatoire sur son réseau de serveurs.

Cependant, il incombe aux services informatiques de s'assurer que VOUS pouvez faire VOTRE travail correctement. Ils doivent s'assurer que vous avez ce dont vous avez besoin, quand vous en avez besoin. Si vous avez un logiciel que les affaires besoins pour continuer à courir, ils ont à fournir une plate - forme pour qu'il fonctionne sur. Voilà leur description de poste. Mais vous devez vous assurer qu'ils disposent des informations dont ils ont besoin pour faire leur travail.

Si vous étiez venu me voir, dans mon organisation, m'aviez dit que vous démarriez un nouveau projet, je vous aurais donné trois VM: Dev, Live et Staging. Vous auriez tous les droits d'administrateur sur Dev, et nous discuterions de ce dont vous avez besoin pour faire votre travail pour les deux autres. Si vous aviez besoin de tous les droits d'administrateur sur eux et que vous pouviez le justifier, vous l'obtiendrez. Nous avons notre déploiement de machine virtuelle vers le bas. VMWare rend cela incroyablement simple - il ne prend que 5 minutes par VM pour le déployer.

Il semble que votre service informatique souffre de ce dont souffrent à peu près tous les services informatiques d'une grande entreprise. Construire de petits châteaux et les défendre avec votre vie, ne pas laisser entrer les autres, être autoritaire, etc. En tant que personne qui traite quotidiennement avec les services informatiques des autres, je le vois tout le temps. Et c'est frustrant.

Le fait fondamental est cependant que le changement doit se produire au sein du service informatique, et il doit être initié par le dessus. Et si vous pouvez faire en sorte que l'informatique se rende compte qu'ils ne sont pas une force en eux-mêmes (car la plupart d'entre eux ne génèrent pas de revenus pour leurs entreprises, cela peut être une gifle) et qu'ils sont là pour soutenir le personnel existant et améliorer l'entreprise, alors vous constaterez que vos questions deviennent inutiles, car tout le monde jouera des familles heureuses.

Pourquoi voulez-vous l'ajouter au domaine? En d'autres termes, ce qui répond mieux à la question: vous pouvez configurer un laboratoire pour faire ce que vous voulez, tant qu'il n'est pas connecté au réseau local de l'entreprise. (Si vous avez besoin d'un accès Internet, vous pouvez peut-être obtenir un VLAN DMZ-ed; cela ne devrait pas être un problème, surtout si vous ne l'utilisez que pour sortir , comme pour les téléchargements.)

C'est une réponse parmi tant d'autres à la question.

Vous obtiendrez BEAUCOUP de réponses ici, pour et contre les développeurs ayant un accès administrateur à n'importe quelle partie de l'environnement (probablement contre), mais voici le résultat:

Le groupe sysadmin est chargé de maintenir les systèmes de production en cours d'exécution, stables et sécurisés et est chargé de s'assurer que ces systèmes fournissent les services que l'entreprise paie (car ils les paient) aux niveaux qu'ils attendent.

De même, l'équipe de développement a été chargée de fournir des services à l'entreprise (web, applications, etc.), bien que dans un domaine différent. Se battre pour le contrôle de l'environnement de développement est contre-productif et ne sert à rien de part et d'autre.

Je travaille dans un petit ISV / ASP. Nous avons un développeur et un administrateur système (moi). Nous avons une relation basée sur le respect mutuel et la confiance. Nous devons travailler en équipe pour aider à atteindre les objectifs globaux de l'entreprise. Je donne au développeur un accès complet et sans entrave à son environnement de développement, qui comprend des postes de travail et des serveurs. Je gère les systèmes de développement pour la sécurité, les mises à jour, l'AV et le matériel et le développeur fait le reste. Lorsque son code est prêt pour la production, il me le remet, m'aide avec toute configuration nécessaire et recule. Nous nous aidons mutuellement.

Les développeurs doivent être les maîtres de l'environnement de développement et les administrateurs système doivent être les maîtres de l'environnement de production, dans des limites raisonnables et avec des contrôles, des équilibres et des contrôles raisonnables. Lorsque l'une ou l'autre des parties doit "traverser", cela devrait être en coopération et en concertation avec la partie "régnante" sous leur responsabilité et sous leur direction.

Tout d'abord, mon expérience est strictement dans une organisation plus petite, mais ce problème se pose dans les entreprises de toutes tailles, alors ...

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

De mon point de vue, le seul argument que les développeurs doivent faire valoir est "nous en avons besoin". S'ils venaient à moi en premier, j'essaierais de comprendre leurs besoins et de voir ce que nous pourrions trouver. Mais, en fin de compte, s'ils disent «nous en avons besoin», je leur donnerais le bénéfice du doute et je serais convaincu qu'ils savent ce qu'ils font.

Mais ce n'est que le début - c'est le côté "Pro" de l'équation. Le "Con" est l'endroit où nous entrons dans la dispute ...

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

Sauf que "juste" est un euphémisme incroyable, oui, si les développeurs peuvent faire une justification technique et commerciale, il n'y aurait pas de problème. D'autres ici et sur programmers.SE (où votre question SO a été migrée) ont signalé une tonne d'embûches à votre configuration, donc je ne les répéterai pas. Si vous proposez un plan pour faire face à tous ces problèmes et à tous ceux auxquels votre service informatique pense et justifier TOUS les coûts, alors il est logique d'aller de l'avant.

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

Celui-ci n'est pas un débutant, vous ne pouvez pas avoir deux groupes avec des objectifs et des responsabilités différents essayant de gérer les mêmes systèmes. Cela ne se terminera pas seulement mal, cela commencera mal et se terminera par un bain de sang.

(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?

Je pense que cela est couvert par ma réponse au 2: ce sont des détails techniques pour lesquels ils devraient trouver des solutions.

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?

Je suis d'accord avec kce: "Air-gap"

S'ils peuvent justifier les frais supplémentaires qu'ils assument (en devenant des administrateurs de leur environnement), les développeurs peuvent avoir leur propre mini-réseau où ils ont toute liberté, MAIS c'est complètement en quarantaine: rien ne touche le reste du réseau. Ils doivent donc trouver des justifications plus techniques et commerciales, par exemple pour "comment allons-nous sauvegarder les données critiques?"

Encore une fois, je dois être d'accord avec kce: "Les administrateurs système restent des administrateurs système car ils ne font confiance à rien pour faire quoi que ce soit de bien". une douzaine de choses qu'un administrateur système expérimenté sait être incroyablement feuilletées vont avoir une forte réaction négative.

D'après les réponses et les commentaires ici et sur programmers.se, je pense qu'il est clair qu'il y a des aspects à cela que vous n'avez pas pris en compte. Même si cela va prendre plus de temps, je pense que vous devez vraiment aller parler à vos informaticiens et présenter les choses différemment: "voici ce que nous devons faire, existe-t-il un moyen d'intégrer cela dans l'infrastructure et les opérations existantes?"

Le problème général, dans votre cas et dans des millions de cas similaires, est le suivant:

1) Responsabilité floue - il n'y a pas de lien direct entre les actions d'un travailleur social et ses bénéfices. Il est payé par mois, et non par effets, qui sont plus difficiles à mesurer, plus l'organisation est grande. Cela s'applique à la sécurité, aux gestionnaires, etc. S'ils paralysent votre travail, ils s'en moquent.

2) Les décideurs et la sécurité ont généralement peu ou pas de connaissances sur la programmation. Ils ne pouvaient pas comprendre qu'ils paralysaient votre travail même s'ils s'en souciaient (ce qui ne s'applique généralement pas).

3) Le profil psychologique préféré pour le travail dans la sécurité est la personnalité paranoïaque ou le trouble obsessionnel-compulsif. Ces gens voient la conspiration partout. Si les développeurs veulent quelque chose, comme un nouveau serveur, ils veulent sûrement l'utiliser pour voler des données d'entreprise et les publier dans WikiLeaks, ou vendre en Corée du Nord.