SysAdmin & Developer: Responsabilidades [cerrado]

Cuando se trata de algo así como un servidor web de producción, ¿cuál es la mejor práctica para las responsabilidades del administrador del sistema y el desarrollador? Específicamente, estoy pensando en actualizar / instalar software. (En mi opinión, el desarrollador no debería tener acceso de root en el servidor de producción).

Por lo tanto, un servidor web de producción ejecuta Wordpress, y debe actualizarse a la última versión. ¿Quién es responsable de mantenerlo actualizado?

¿Qué sucede si los desarrolladores tienen complementos pirateados personalizados o archivos principales personalizados en la aplicación (en este ejemplo, WP)?

He descubierto que, en la mayoría de los casos, si USTED es el responsable del servidor físico, lo mejor es NO dar acceso a la raíz de los desarrolladores.

Este es un poco un debate de "guerra santa", ya que estoy seguro de que encontrarás desarrolladores que no están de acuerdo. Personalmente he estado en ambos lados de ese debate.

Mi razonamiento PRINCIPAL para no dar acceso a los desarrolladores (incluso a los desarrolladores 100% confiables) es porque la mayoría de las veces hay algún paquete que necesitan para que XYZ funcione correctamente. Continúan y lo instalan ... o reconfiguran algo que ya está en su lugar para que funcione ... o ... bueno ... ya entiendes la idea.

Pasan los meses ... el servidor necesita ser reinstalado o recreado ... y de repente nadie sabe por qué "Funciona en el servidor anterior, pero no en el nuevo".

La respuesta, por supuesto, es que la documentación que está viendo no incluye todos esos pequeños paquetes y ajustes que los desarrolladores hicieron para que el sistema funcione la primera vez.

Puede ser una molestia en el a $$ para ambos lados ... pero si el administrador del sistema es responsable del servidor, los paquetes y la documentación ... y el desarrollador es responsable del desarrollo y el software ... creo que usted ' Descubriré que valió la pena al final.

Si el desarrollador necesita un complemento, módulo, configuración, ajuste personalizado ... no hay problema ... hágalo por ellos ... pero DOCÚNTELO para que pueda reproducirlo la próxima vez.

Regla de oro : no dejes que los no administradores toquen algo que no quieras que se rompa y del que seas responsable

Los desarrolladores deben tener acceso a un entorno de prueba. Una vez que su trabajo esté listo para ser puesto en la máquina de producción, debe ser entregado al administrador del sistema. Si los desarrolladores han hecho su trabajo y documentado correctamente el procedimiento, todo irá bien. Si no es así, necesitan que les pateen la espalda para no realizar pruebas adecuadamente.

He estado en esta batalla también. Mi respuesta es que quien sea responsable del tiempo de actividad del servidor es el responsable de todas las actualizaciones, cambios, etc., etc. Nobodoy debería tener la capacidad de realizar este tipo de funciones en el servidor. Si es su trabajo asegurarse de que el servidor esté funcionando y si el jefe lo responsabiliza por el servidor, entonces es su responsabilidad mantenerlo y protegerlo.

La mayoría de los desarrolladores le dirán que necesitan acceso de nivel de administrador al servidor y la mayoría de ellos no estarán de acuerdo conmigo, pero yo soy quien tiene que reiniciarlo a las 2 AM cuando cuelga, tiene que reconstruirlo después una actualización fallida, el tiempo de inactividad se carga contra mi departamento, etc., etc. Tengo que responder al CIO por cualquier cosa que afecte nuestro SLA, por lo tanto, soy el único que tiene acceso de nivel administrativo al servidor y yo ' Soy responsable de todos los componentes, actualizaciones, cambios, etc.

Estoy 100% de acuerdo. La mayoría de las veces, los desarrolladores no son conscientes de cómo funcionan las cosas syadmin. Si necesitan algo, te preguntan, eso es todo. Piensa en cómo y cuándo y les entrega un paquete utilizable. (como necesitan enviar correos electrónicos, USTED es el que configurará el postfix). Además, tenderán a pensar que, en la mayoría de los casos, el acceso raíz hará que las cosas funcionen si no pueden hacerlo con el acceso normal. Estoy de acuerdo con otros aquí, no estarán contigo a las 2 am cuando veas un problema. Tuve el caso hace unas semanas, un desarrollador quería actualizar su wordpress. Le dije que cambiara el registro de RTF, para él, eso era inútil, el proceso de actualización se realiza a través de una hermosa interfaz. Bueno, la actualización no funcionó, tenía su aplicación guardada, hice el script de copia de seguridad, no él. Sin mí, no podría haber podido restaurar el sitio.

Hay una tendencia a difuminar la distinción entre desarrollo y operaciones. Haga que sus desarrolladores sean administradores de sistemas y sus desarrolladores de administradores de sistemas.

En este sentido, WordPress podría beneficiarse de algún trabajo en la provisión automática (y programática) de blog. Muchos usuarios de WordPress mantienen más de unas pocas instancias de WP / WPMU y actualizarlas a tiempo es al menos engorroso.

Puede encontrar una visión general agradable (y divertida) de la filosofía en las diapositivas de Agile Infrastructure de Agile 2009

Los desarrolladores no deberían tener raíces en la producción; todos, excepto los desarrolladores, están de acuerdo en esto. Pero los desarrolladores pueden tener su pastel y comérselo también. Estoy algo sorprendido de que nadie mencione esto explícitamente:

Uno de mis clientes de pequeñas empresas desde hace mucho tiempo tiene un sitio web con una instalación de Drupal, varios sitios de WordPress, un foro SMF y algunas otras aplicaciones web pequeñas al azar. Soy el administrador del sistema de contratos (y por razones históricas también actualizo / pirateo de WordPress y SMF cuando sea necesario) y mi cliente tiene su propio desarrollador de contratos de Drupal. El entorno es varias máquinas virtuales VMware en un proveedor de nube pública.

Los desarrolladores realmente quieren tener acceso de root y lo necesitan. Es su responsabilidad escribir las reglas de reescritura de nginx para que todas sus cosas personalizadas de Drupal funcionen, por ejemplo. Pero de ninguna manera les estoy dando acceso a la raíz en el servidor de producción, y mi cliente está de acuerdo conmigo en eso.

Así que nos comprometimos: obtienen acceso raíz en el servidor web de prueba (que generalmente es idéntico a la producción, excepto por su dirección IP y está en la misma nube). Lo cual, como la producción, tiene etckeeper para que pueda ver los cambios que necesitaban hacer y los paquetes que instalaron. Entonces puedo llevar los cambios a producción o decirles lo que está mal con lo que quieran hacer. Y si realmente se equivocaron (aún no lo han hecho, gracias a Dios) puedo revertir fácilmente sus cambios.

No tienen ningún acceso al servidor de base de datos de producción; Ni siquiera tienen inicios de sesión de usuario. Solo mi cliente y yo lo hacemos.

(La aplicación web en sí, se implementan directamente con git, y si la rompen, pueden arreglarla y explicarle a mi cliente por qué deberían seguir siendo sus desarrolladores. Aunque mi cliente me enviaba un correo electrónico en ese correo electrónico para que yo pudiera reírse de ellos o facepalm.)

Root == Administrador del sistema.

Usuarios == Desarrolladores, DBA o Usuarios.

Root no sabe dormir cuando un servidor está inactivo, root protege a los usuarios de sí mismos, root protege los datos de los usuarios de la red, root pone la salud del servidor por encima de todos los usuarios. El culo de Root está en la línea cuando el servidor está fuera de línea. Servidor feliz, root feliz!

Razones comunes para el tiempo de inactividad no programado: usuarios, cambios no documentados en el entorno y retroexcavadoras. Los servidores hacen exactamente lo que se les dice que no se rompen al azar. Hackers preguntan, no es si, es cuando ... por lo tanto, la necesidad de una "raíz".

00:33 CDT, ¿sabe dónde están sus copias de seguridad y documentos de recuperación ante desastres? :-pags

Los administradores de sistemas deberían tener acceso de administrador (como dice el título). Nadie más necesita acceso a los servidores de producción. Si los desarrolladores necesitan solucionar un problema en un sistema de producción, ese problema debe ser reproducible en el entorno de desarrollo. Si no es así, pueden sentarse con el administrador del sistema y mirar a través del sistema.

A los desarrolladores no les gusta no poder tocar la producción, pero ese no es el trabajo. Su trabajo es escribir el software y entregarlo a los administradores del sistema para un lanzamiento de producción. Si han documentado todo (y tienen en cuenta que en la mayoría de las tiendas la documentación es una mala palabra), entonces los lanzamientos deberían funcionar bien.

En las empresas públicas aquí en los EE. UU., Tiene que lidiar con SOX, HIPPA, etc. La mayoría de estas regulaciones olvidadas en realidad ayudan con este argumento. SOX dicta la separación de tareas, lo que requiere que los desarrolladores mantengan las manos fuera de los sistemas de producción.