Lo que se requiere para que los desarrolladores ejecuten su propio servidor VM en un entorno empresarial [cerrado]

Este escenario también se publicó en SO , con diferentes preguntas para diferentes audiencias, y estoy muy contento de haberlo hecho, ya que recibí algunas muy buenas respuestas.

Estamos intentando implementar un entorno de desarrollo utilizando la virtualización para un pequeño equipo de 4 desarrolladores dentro de una organización empresarial. Esto nos permitiría establecer entornos de desarrollo, prueba y preparación por separado, además de permitir el acceso a nuevos sistemas operativos que son requisitos para los sistemas o herramientas que estamos evaluando.

Cambiamos el propósito de una máquina de clase de estación de trabajo existente, agregamos 24 GB de RAM y RAID-10, y lo estábamos haciendo bien hasta que intentamos agregar la máquina al dominio.

Ahora estamos comenzando la guerra que todos los desarrolladores empresariales desde el principio de los tiempos han tenido que luchar: la lucha por el control local de un entorno de desarrollo y pruebas. La red y los administradores de TI han planteado una serie de inquietudes que van desde "El servidor ESX es el estándar de la empresa" hasta que "los servidores no están permitidos en las VLAN del cliente" a "[rellenar el espacio en blanco] no es un conjunto de habilidades que actualmente posee la organización de TI local o empresarial ".

Probablemente podríamos justificar el hardware de nivel de producción y el soporte formal de TI (léase: podríamos justificar la necesidad si tuviéramos que hacerlo, pero tomaría tiempo e implicaría mucho dolor de cabeza), pero probablemente tomará meses obtener formalmente recursos de TI asignado al tratar esto como un sistema de producción, e incluso si lo hiciéramos, probablemente perderíamos el control local que queremos.

Me imagino que muchos de ustedes han tenido dificultades similares con los desarrolladores dentro de su empresa para el control de desarrolladores de entornos que no son de producción, por lo que mis preguntas son las siguientes:

1. ¿Qué argumentos han hecho sus desarrolladores que lo convencieron para permitir que estos tipos de silos existan dentro de las empresas que tienen políticas estándar de red y seguridad establecidas que generalmente (y comprensiblemente) excluirían este tipo de infraestructura no administrada (centralmente)?
2. ¿Es solo una cuestión de que los desarrolladores hagan una justificación técnica o comercial y se aseguren de que la administración de parches y AV va a suceder, o más que una lucha política por el control y la propiedad?
3. Dada la opción, ¿preferiría asumir la propiedad y el soporte del hardware / sistema operativo mientras otorga a los desarrolladores derechos de administrador local, o dejar que lo administren por completo, al tiempo que se asegura de que instituyan la administración de parches / AV y los cargue con responsabilidad si causan problemas?
4. Si bloqueó con éxito a los desarrolladores para que no tengan el control local de los "servidores deshonestos" en su infraestructura, ¿acaban de cumplir los desarrolladores o ellos (o usted) trasladaron el entorno de desarrollo a una VLAN desconectada / red completamente separada?

Un par de supuestos para limitar el alcance de esta pregunta:

1. Para repetir, esto es para un entorno de desarrollo : no se requieren cargas de producción ni compatibilidad. Nada accesible externamente.
2. Esta no es una guerra santa de Hyper-V vs. ESX (estaríamos bien con cualquiera de ellos, pero Hyper-V fue seleccionado ya que es "gratuito" con MSDN para estos fines [sí, VMWare también tiene herramientas gratuitas, pero la buena administración las herramientas generalmente no lo son], y sería más fácil de administrar por los desarrolladores locales en una "Tienda de Microsoft"), por lo que los argumentos a favor o en contra de ambos están fuera del alcance de esta pregunta.
3. El equipo de desarrollo ya se ha asegurado de administrar la administración de parches y el antivirus, o integrarse con los sistemas empresariales existentes si TI lo admite, pero ciertamente está dentro del alcance si está o no dispuesto a aceptar eso.

En primer lugar, veo algunas razones por las cuales sus administradores tienen razón en retrasar:

• TI también es responsable de informar sobre cosas como la administración de parches, el software antivirus, el cumplimiento de pci, las auditorías de seguridad anuales (o más frecuentes), etc. No se trata solo de tener la seguridad de que esto se soluciona, sino también de poder para demostrarlo a los extraños.

  Como ejemplo, administro la red en una pequeña universidad y tenemos un laboratorio de física con algunas máquinas de recolección de datos para experimentos de estudiantes. Lo único que hacen es recopilar datos de un instrumento científico e imprimir los resultados (en una impresora conectada directamente) para que el alumno los analice y los entregue al instructor. Nunca están en Internet, incluso las actualizaciones de AV y Windows se aplican a través de la red local. La única razón por la que están conectados a la red y ejecutan software AV es el propósito explícito de informar a mi software de monitoreo que todavía existen y que están actualizados. Es una tontería, ya que en realidad sería más seguro eliminar la conexión de red, pero primero se pagaron con una beca de educación y, por lo tanto, esos son mis requisitos de informes.

• Nos guste o no, su servidor de desarrollo es un sistema de producción desde el punto de vista de los desarrolladores. Espere tal vez un mes, y los desarrolladores tendrán dificultades para hacer el trabajo si se cae debido a los procesos que configurará y supondrá que el servidor está disponible. Evitar / limitar situaciones en las que los trabajadores permanecen inactivos debido a fallas tecnológicas es una gran razón por la cual las empresas aún usan departamentos de TI centralizados.
• Si "ESX Server es el estándar empresarial", debe seguirlo. En este momento, existen diferencias significativas entre la forma en que hyper-v, vmware, xen y otros hacen las cosas, y no se puede suponer que una máquina construida para uno funcione bien en el otro. Si va a hacer esto, TI necesitará ayudarlo a administrarlo en algún momento, y no quieren tener que convertirlo a vmware después de que haya un montón de problemas en la máquina que puedan causar un problema.
• Algún día esta máquina envejecerá y necesitará un mantenimiento más regular o establecerá un ciclo de reemplazo estándar. Incluso los nuevos servidores a veces tienen partes vacías. Esta situación casi siempre cae en el regazo de TI solo después de que algo se ha roto que impide que las personas hagan su trabajo. Al asumir la responsabilidad del servidor temprano, TI puede hacer un trabajo mucho mejor asegurándose de evitar interrupciones no planificadas en el futuro.
• Este es personal, pero puedo decirte que lo último que quiero en mi red es otro escritorio disfrazado de servidor. He tratado con suficientes de esos en los últimos dos años para que me duren toda la vida.

Dicho esto, TI debe ser capaz de apoyar esta iniciativa. No les basta con decir simplemente "No". Desafíelos a encontrar una alternativa que satisfaga sus necesidades (muy reales). La única situación política aquí debería ser que es probable que su alternativa tenga un precio más alto (porque están planeando costos que aún no puede ver), por lo que la pregunta será quién tiene que pagarlo. No querrá hacerlo porque no lo presupuestaron, pero se negará porque es 6 veces más de lo que gastó en una solución con la que estaba satisfecho (por el momento).

Además, parece que podría estar intentando correr antes de poder caminar. Desea renovar su proceso de desarrollo. Como ex desarrollador, creo que es genial. Pero no solo arroje un montón de máquinas virtuales y "entornos" (es decir: dev, stage, qa, etc.). Planifique cómo serán los nuevos procesos: cómo los desarrolladores realizarán el trabajo. ¿Usarás integración continua? Construcciones automatizadas? ¿Usando qué software para apoyarlos? ¿Se permitirá a los desarrolladores mover código a producción o puesta en escena, o solo QA tendrá esa capacidad? ¿Necesitas una puesta en escena por separado? ¿Qué pasa con dos ramas de desarrollo (una para vNext, una para errores con vCurrent)?

Es posible que necesite un servidor solo para que el líder o gerente de desarrollo pueda resolver todo eso, pero si es así, ese debe ser el primer paso, y la configuración y el diseño del proceso inicial deben hacerse antes de que los desarrolladores lo tengan en cuenta. utilizar.

1) ¿Qué argumentos han hecho sus desarrolladores que lo convencieron de permitir que estos tipos de silos existan dentro de las empresas que tienen políticas estándar de red y seguridad en su lugar que generalmente (y comprensiblemente) impedirían este tipo de infraestructura no administrada (centralmente) ?

Ninguno, principalmente porque no desempeño un papel de gestión en mi organización, por lo que ninguna de estas "cosas políticas" realmente no me involucra. El único argumento que realmente me convencería es permitir algo que esté explícitamente en contra de la política de red y exento tanto del control como de la visibilidad del equipo de operaciones del sistema, es un espacio vacío y una carta CYA del jefe de mi jefe.

No es que realmente quiera ser el negocio de decir "No", es solo que no hay una buena manera de que esto termine bien desde el punto de vista del equipo de operaciones.

1. Terminamos con servidores administrados por personas cuyo conjunto de habilidades primarias no es administrar servidores en la red que no tienen visibilidad de toda la red y su espacio de problemas asociado. Esto no es solo una preocupación política de "proteger" el césped; Como un ejemplo trillado, imagine lo que sucede cuando un desarrollador activa DHCP por alguna razón.
2. Terminamos administrando los servidores del equipo de desarrollo para ellos. Esto es desordenado por la razón opuesta. Los desarrolladores están constantemente molestos de que estemos parcheando esto (rompiendo algo que ellos saben pero nosotros no), o que luchan por nosotros para habilitar funciones que por una variedad de buenas razones no queremos habilitar. Esto rápidamente se convierte en un punto muerto donde el equipo de operaciones se siente agobiado y acosado y el equipo de desarrollo se siente frustrado e ignorado.
3. Hay consecuencias políticas, porque entonces debe explicar a otro departamento por qué los desarrolladores son "especiales" y por qué están exentos de la política de red.

2) ¿Es solo una cuestión de que los desarrolladores hagan una justificación técnica o comercial y se aseguren de que la administración de parches y AV va a suceder, o más que una lucha política por el control y la propiedad?

No creo que los desarrolladores necesiten hacer un caso de negocios; está bastante claro que los desarrolladores deben desarrollarse y, para hacerlo, necesitan un entorno de desarrollo de algún tipo. En cuanto a la administración de parches y AV, ese es el trabajo del equipo de operaciones y nos aseguraremos de que se haga. No es que pensemos que los desarrolladores no pueden hacerlo. Es solo que no confiamos en que lo haga bien: los administradores del sistema siguen siendo administradores del sistema porque no confían en nada para hacer nada bien, por lo que no es nada personal. Por supuesto, hay una cuestión política obvia de sentir que alguien más está "haciendo tu trabajo", pero eso no es realmente un problema técnico y, por lo tanto, está fuera del alcance de SF.

3) Dada la opción, ¿preferiría asumir la propiedad y el soporte del hardware / sistema operativo mientras otorga a los desarrolladores derechos de administrador local, o dejar que lo administren por completo, al tiempo que se asegura de que instituyan la administración de parches / AV y los acuse de responsabilidad si causan ¿problemas?

Tampoco por los motivos descritos anteriormente.

4) Si bloqueó con éxito a los desarrolladores para que no tengan el control local de los "servidores corruptos" en su infraestructura, ¿acaban de cumplir los desarrolladores o ellos (o usted) trasladaron el entorno de desarrollo a una VLAN desconectada / red completamente separada?

Espacio de aire. La mejor manera de manejar esta situación es darles a los desarrolladores su entorno (y controlarlo) y luego dejar espacio de aire o usar algún otro método robusto para separarlo de la red. Esto es esencialmente cómo manejamos el wifi público. ¿Quieres servicios wifi? Seguro. Si paga la conexión de red, administraremos los WAP, pero nunca tocará nuestra red. Lo siento. Sus necesidades son solo una de cientos. Hay otras preocupaciones que debemos tener en cuenta.

No quiere estar en el negocio de decir que no, porque los desarrolladores (que son particularmente inteligentes desde el punto de vista técnico) encontrarán formas de obtener lo que quieren de todos modos. Así que bríndeles un entorno que se adapte a sus necesidades, hágales felices y luego encuentre alguna forma de evitar que cualquier cosa que hagan en el entorno de desarrollo afecte al resto de su red comercial.

TL; DR: Le daría un servidor con cualquier plataforma de virtualización que quisiera en una red física o VLAN separada. El acceso a su entorno de desarrollo sería a través de un único servidor de bastión que el equipo de operaciones controlaría y supervisaría. Lo que hace con su negocio: no será compatible, pero le brindaremos asesoramiento y ayuda cuando el tiempo lo permita para el lado de la administración del servidor.

Si viniera a mí con una máquina de clase de estación de trabajo cargada hasta el tope con RAM de grado de consumidor, HDD de grado de consumidor, PSU de grado de consumidor y RAID de grado de consumidor, me negaría a ponerlo en la red del servidor también.

Hay mucho que debes entender sobre cómo poner algo así en la VLAN del servidor.

1. La VLAN del servidor puede muy bien ser una DMZ. En una DMZ no coloca nada que no esté endurecido y asegurado. Esta es solo una máquina que les diste, no tienen idea de lo que hiciste con ella. También significa parches y actualizaciones regulares, lo que significa ser administrado centralmente. Estoy seguro de que no voy a iniciar sesión en cada servidor no administrado y aplicar parches a mano.

2. Los componentes en esa máquina van a fallar. Lo prometo. Dentro de 6 o 12, 24 meses, se va a poner boca abajo. Entonces, ¿dónde están las copias de seguridad? Oh, no los configuraste? Pero, pensé que era un servidor? Oh, ¿es un servidor que alguien más ha provisto? ... y el juego de la culpa comienza de nuevo

3. ¿Quién se responsabilizará cuando se cuelgue y la mierda golpee al fanático? En la mayoría de las organizaciones, "se lo di a los desarrolladores para que lo cuiden" no va a volar.

4. ¿Dónde lo van a poner? En la actualidad, todos los servidores están montados en bastidores y colocar una torre en un bastidor desperdicia espacio y sus bastidores pueden no estar diseñados para ello.

Entonces, el departamento de TI está muy justificado en no poner esta computadora aleatoria en su red de servidores.

Sin embargo , el trabajo de los departamentos de TI es garantizar que USTED pueda hacer SU trabajo correctamente. Deben asegurarse de que tiene lo que necesita, cuando lo necesita. Si tiene una pieza de software que la empresa necesita para seguir ejecutándose, tienen que proporcionar una plataforma para que se ejecute. Esa es la descripción de su trabajo. Pero debe asegurarse de que tengan la información que necesitan para hacer su trabajo.

Si hubiera venido a mí, en mi organización, me hubiera dicho que está comenzando un nuevo proyecto, le habría dado tres VM: Dev, Live y Staging. Tendría derechos de administrador completos para Dev, y discutiríamos lo que necesitaba para hacer su trabajo para los otros dos. Si necesitaras derechos de administrador completos para ellos y pudieras justificarlo, entonces lo obtendrías. Tenemos nuestro despliegue de VM de baja resolución. VMWare hace esto increíblemente simple: solo toma alrededor de 5 minutos por VM para implementarlo.

Parece que su departamento de TI sufre de lo que sufren casi todos los departamentos de TI en una gran empresa. Construir pequeños castillos y defenderlos con su vida, no dejar que otros entren, ser mandones, etc. Como alguien que trata con los departamentos de TI de otras personas todos los días, lo veo todo el tiempo. Y es frustrante.

Sin embargo, el hecho básico es que el cambio debe ocurrir dentro del departamento de TI, y debe iniciarse desde arriba. Y si puede hacer que TI se dé cuenta de que no son una fuerza en sí mismos (ya que la mayoría de ellos no generan ingresos para sus negocios, esto puede ser una bofetada), y que están allí para apoyar al personal existente y mejorar el negocio, entonces encontrará que sus preguntas se vuelven irrelevantes, porque todos jugarán familias felices.

¿Por qué quieres que se agregue al dominio? Para decirlo de otra manera, que responde mejor a la pregunta: puede configurar un laboratorio para hacer lo que quiera, siempre que no esté conectado a la LAN corporativa. (Si necesita acceso a Internet, tal vez pueda obtener una VLAN DMZ-ed; eso no debería ser un problema, especialmente si solo lo está usando para salir , como para descargas).

Esa es una, de muchas, muchas, diferentes respuestas a la pregunta.

Obtendrá MUCHAS respuestas aquí, a favor y en contra de los desarrolladores que tienen acceso de administrador a cualquier parte del entorno (probablemente principalmente en contra), pero aquí está el resultado final:

El grupo sysadmin tiene la tarea de mantener los sistemas de producción en funcionamiento, estables y seguros, y son responsables de asegurarse de que esos sistemas brinden los servicios que la empresa está pagando (porque los están pagando) en los niveles que esperan.

Del mismo modo, el equipo de desarrollo se ha encargado de proporcionar servicios a la empresa (web, aplicaciones, etc.), aunque en un ámbito diferente. La lucha por el control del entorno de desarrollo es contraproducente y no tiene ningún propósito útil para ninguna de las partes.

Yo trabajo en un pequeño ISV / ASP. Tenemos un desarrollador y un administrador de sistemas (yo). Tenemos una relación basada en el respeto y la confianza mutuos. Necesitamos trabajar en equipo para ayudar a lograr los objetivos generales de la empresa. Le doy al desarrollador acceso completo y sin restricciones a su entorno de desarrollo, que incluye estaciones de trabajo y servidores. Administro los sistemas de desarrollo para seguridad, actualizaciones, AV y hardware, y el desarrollador hace el resto. Cuando su código está listo para la producción, me lo entrega, me ayuda con cualquier configuración necesaria y retrocede. Nos brindamos asistencia mutua.

Los desarrolladores deben ser los maestros del entorno de desarrollo y los administradores de sistemas deben ser los maestros del entorno de producción, dentro de límites razonables y con controles, equilibrios y controles razonables. Cuando cualquiera de las partes necesita "cruzar", debe ser en cooperación y concierto con la parte "reinante" bajo su competencia y orientación.

En primer lugar, mi experiencia es estrictamente en una organización más pequeña, pero este problema surge en empresas de todos los tamaños, así que ...

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

Desde mi punto de vista, el único argumento que los desarrolladores deben hacer es "necesitamos esto". Si vinieran a mí primero, trataría de comprender sus necesidades y ver qué podríamos resolver. Pero, en última instancia, si dicen "necesitamos esto", les daría el beneficio de la duda y confiarían en que saben lo que están haciendo.

Pero ese es solo el comienzo, ese es el lado "Pro" de la ecuación. La "estafa" es donde nos metemos en la disputa ...

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

Excepto que "solo" es una subestimación increíble, sí, si los desarrolladores pueden hacer una justificación técnica y comercial, no habría problema. Otros aquí y en programadores. SE (donde se migró su pregunta SO) han señalado un montón de dificultades para su configuración, por lo que no las repetiré. Si se le ocurre un plan para hacer frente a todos esos problemas y cualquier otro en el que piense su departamento de TI, y justificar TODOS los costos, entonces tiene sentido seguir adelante.

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

Este no es un principiante, no puede tener dos grupos con diferentes objetivos y responsabilidades tratando de administrar los mismos sistemas. No solo terminará mal, comenzará mal y terminará en un derramamiento de sangre.

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

Creo que esto está cubierto por mi respuesta a 2 .: estos son detalles técnicos para los que tendrían que encontrar soluciones.

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?

Estoy de acuerdo con kce: "Air-gap"

Si pueden justificar la sobrecarga adicional que están asumiendo (al convertirse en administradores de su entorno), los desarrolladores pueden tener su propia mini red donde tienen rienda suelta, PERO está completamente en cuarentena: nada afecta al resto de la red. Por lo tanto, tienen que encontrar más justificaciones técnicas y comerciales, por ejemplo, "¿cómo vamos a hacer una copia de seguridad de los datos críticos?"

De nuevo, tengo que estar de acuerdo con kce: "Los administradores del sistema siguen siendo administradores del sistema porque no confían en nada para hacer nada bien". Nuestro trabajo es construir los sistemas más confiables que podamos con componentes poco confiables, por lo que cualquier propuesta que incluya medio Una docena de cosas que un experimentado administrador de sistemas sabe que son increíblemente descamadas tendrá una fuerte reacción negativa.

De las respuestas y comentarios aquí y en programmers.se, creo que está claro que hay aspectos de esto que no has considerado. Aunque va a tomar más tiempo, creo que realmente necesita hablar con sus técnicos de TI y presentar las cosas de manera diferente: "esto es lo que debemos hacer, ¿hay alguna forma de integrar esto en la infraestructura y las operaciones existentes?"

El problema general, en su caso y en millones de casos similares, es:

1) Responsabilidad difusa: no existe una conexión directa entre las acciones de un trabajador corporativo y sus ganancias. Se le paga por mes, y no por efectos, que son los más difíciles de medir, cuanto más grande es la organización. Se aplica a seguridad, gerentes, etc. Si paralizan su trabajo, no les importa.

2) Los encargados de formular políticas y la seguridad generalmente tienen poco o ningún conocimiento sobre programación. No podrían entender que están paralizando su trabajo, incluso si les importara (lo que generalmente no se aplica).

3) El perfil psicológico preferido para trabajar en seguridad es la personalidad paranoica o el trastorno obsesivo compulsivo. Estas personas ven la conspiración en todas partes. Si los desarrolladores quieren algo, como un nuevo servidor, seguramente quieren usarlo para robar datos corporativos y publicarlos en WikiLeaks, o venderlos a Corea del Norte.