¿Qué cosas de administrador de sistemas debe saber todo programador?

Como programador, tendemos a dar por sentado los administradores de sistemas. Las pocas veces que he estado sin un buen administrador de sistemas realmente me han hecho apreciar lo que ustedes hacen. Cuando nos aventuramos en un entorno sin un administrador de sistemas, ¿qué palabras de sabiduría nos puede ofrecer?

Yo comenzaría con:

1. Siempre tenga un sistema de respaldo de algún tipo. Aún mejor si tiene una historia.
2. Considere puntos únicos de falla y cómo lidiar con ellos si fallan.
3. Dependiendo de la cantidad de computadoras involucradas, buscar alguna forma de crear y crear una imagen estándar en las computadoras hará que la vida de todos sea más fácil, no "funciona en la mía" porque tienen un programa que normalmente no está instalado.
4. Documentar todo, aunque sólo sea porque se va a olvidar cómo configurar algo.
5. Mantente al tanto de las actualizaciones de seguridad.

<inserte el descargo de responsabilidad de la publicación grande aquí>

Algunos de estos se han dicho antes, pero vale la pena repetirlos.

Documentación:

• Documentar todo Si no tiene uno, instale una wiki oculta, pero asegúrese de hacer una copia de seguridad. Comience con la recopilación de datos, y un día, se formará una gran imagen.

• Cree diagramas para cada fragmento lógico y manténgalos actualizados. No pude contar la cantidad de veces que un mapa de red o diagrama de clúster me ha salvado.

• Mantenga registros de compilación para cada sistema, incluso si solo se trata de copiar y pegar comandos sobre cómo compilarlo.

• Al construir su sistema, instale y configure sus aplicaciones, pruebe que funciona y realice su evaluación comparativa. Ahora, limpie los discos. Seriamente. 'dd' el primer megabyte fuera de la parte frontal de los discos o de lo contrario hace que la caja no se pueda arrancar. El tiempo corre: pruebe que su documentación puede reconstruirlo desde cero (o, mejor aún, pruebe que su colega puede hacerlo con nada más que su documentación). Esto formará la mitad de su plan de recuperación de desastres.

• Ahora que tiene la primera mitad de su plan de recuperación de desastres, documente el resto; cómo recuperar el estado de su aplicación (restaurar archivos desde cinta, volver a cargar bases de datos desde vertederos), detalles del proveedor / soporte, requisitos de red, cómo y dónde obtener hardware de reemplazo; cualquier cosa que se le ocurra ayudará a que su sistema vuelva a funcionar.

Automatización:

• Automatiza todo lo que puedas. Si tiene que hacer algo tres veces, asegúrese de que el segundo se dedique a desarrollar su automatización para que el tercero esté completamente automatizado. Si no puede automatizarlo, documentelo. Existen suites de automatización, vea si puede hacer que funcionen para usted.

Vigilancia:

• La instrumentación de la aplicación es oro puro. Ser capaz de ver las transacciones que pasan por el sistema hace que la depuración y la resolución de problemas sean mucho más fáciles.

• Cree pruebas de extremo a extremo que prueben no solo que la aplicación está activa, sino que realmente hace lo que se supone que debe hacer. Los puntos son suyos si se pueden conectar al sistema de monitoreo con fines de alerta. Esto sirve doble deber; Además de demostrar que la aplicación funciona, hace que las actualizaciones del sistema sean significativamente más fáciles (el sistema de monitoreo informa en verde, la actualización funcionó, es hora de volver a casa).

• Compare, monitoree y recopile métricas sobre todo lo que sea sensato para hacerlo. Los puntos de referencia le dicen cuándo esperar que algo deje escapar el humo mágico. El monitoreo te dice cuándo lo ha hecho. Las métricas y estadísticas hacen que sea más fácil obtener un nuevo kit (con humo mágico fresco) a través de la administración.

• Si no tiene un sistema de monitoreo, implemente uno. Puntos de bonificación si realmente le aplicas las pruebas de extremo a extremo anteriores.

Seguridad:

• "chmod 777" (también conocido como otorgar todos los accesos / privilegios) nunca es la solución.

• Suscríbete al principio del "mínimo bit"; Si no está instalado, copiado o de otra manera viviendo en el disco, no puede verse comprometido. Las instalaciones de SO y de "fregadero de cocina" pueden facilitar la vida durante la fase de construcción, pero terminas pagando por ello en el futuro.

• Sepa para qué sirve cada puerto abierto en un servidor. Audítelos con frecuencia para asegurarse de que no aparezcan nuevos.

• No intente limpiar un servidor comprometido; necesita ser reconstruido desde cero. Reconstruya a un servidor de repuesto con medios recién descargados, restaurando solo los datos de las copias de seguridad (ya que los archivos binarios pueden verse comprometidos) o clone el host comprometido en un lugar aislado para su análisis para que pueda reconstruir en el mismo kit. Hay toda una pesadilla legal en torno a esto, así que errar por el lado de la preservación en caso de que necesites buscar vías legales. (Nota: IANAL).

Hardware:

• Nunca asumas que algo hará lo que dice en la caja. Demuestre que hace lo que necesita, por si acaso no lo hace. Te encontrarás diciendo "casi funciona" con más frecuencia de lo que esperas.

• No escatime en la gestión remota de hardware. La gestión de consolas seriales y luces apagadas debe considerarse obligatoria. Puntos de bonificación para regletas de control remoto para esos momentos en que no tiene opciones.

(Aparte: hay dos formas de solucionar un problema a las 3 a.m., una involucra estar caliente, trabajar en una computadora portátil a través de una VPN en pijama, la otra involucra una chaqueta gruesa y conducir al centro de datos / oficina. Sé cuál preferir.)

Gestión de proyectos:

• Involucre a las personas que mantendrán el sistema desde el primer día del ciclo de vida del proyecto. Los plazos de entrega del kit y el tiempo del cerebro pueden y sorprenderán, y no hay duda de que tendrán (¿deberían?) Tener estándares o requisitos que se convertirán en dependencias del proyecto.

• La documentación es parte del proyecto. Nunca tendrá tiempo para escribir todo después de que el proyecto se haya cerrado y el sistema haya pasado al mantenimiento, así que asegúrese de incluirlo como un esfuerzo en el cronograma al comienzo.

• Implemente la obsolescencia planificada en el proyecto desde el primer día e inicie el ciclo de actualización seis meses antes del día de apagado que especificó en la documentación del proyecto.

Los servidores tienen una vida útil definida cuando son adecuados para su uso en producción. El final de esta vida útil generalmente se define como cuando el proveedor comienza a cobrar más en mantenimiento anual de lo que costaría actualizar el kit, o alrededor de tres años, lo que sea más corto. Después de este tiempo, son excelentes para entornos de desarrollo / prueba, pero no debe confiar en ellos para administrar el negocio. Volver a visitar el entorno a los dos años y medio le da tiempo de sobra para pasar por los aros de gestión y finanzas necesarios para pedir un nuevo kit e implementar una migración sin problemas antes de enviar el kit antiguo al gran vendedor en el cielo.

Desarrollo:

• Asegúrese de que sus sistemas de desarrollo y preparación se parezcan a la producción. Las máquinas virtuales u otras técnicas de virtualización (zonas, LDOM, servidores v) facilitan los clones de producción en el mundo real en todos los sentidos, pero con rendimiento.

Copias de seguridad

• Los datos que no está respaldando son datos que no desea. Esta es una ley inmutable. Asegúrate de que tu realidad coincida con esto.

• Las copias de seguridad son más difíciles de lo que parecen; algunos archivos estarán abiertos o bloqueados, mientras que otros deben estar inactivos para tener alguna esperanza de recuperación, y todos estos problemas deben abordarse. Algunos paquetes de respaldo tienen agentes u otros métodos para manejar archivos abiertos / bloqueados, otros paquetes no. Volcar las bases de datos en el disco y respaldarlas cuenta como una forma de "inmovilización", pero no es el único método.

• Las copias de seguridad no tienen valor a menos que se prueben. Cada pocos meses, extraiga una cinta aleatoria de los archivos, asegúrese de que realmente tenga datos y que los datos sean consistentes.

Y más importante...

Elija sus modos de falla, o Murphy lo hará ... y Murphy no funciona en su horario.

Diseñe para fallar, documente los puntos débiles diseñados de cada sistema, qué los desencadena y cómo recuperarse. Hará toda la diferencia cuando algo salga mal.

No asumas que es fácil. Conozco a muchos programadores que piensan que solo porque pueden configurar IIS o Apache en su caja de desarrollo pueden ejecutar una granja web. Comprenda lo que implica el trabajo y haga su investigación y planificación, no solo piense que el trabajo del administrador de sistemas es lo fácil que puede hacer en 10 minutos para implementar su aplicación.

• Tenga en cuenta que, para bien o para mal, muchos de los servidores y / o equipos de red que tienden a parecerse mucho a los niños de una segunda familia. Estos son sus bebés. Los atienden, los ayudan cuando están enfermos y los vigilan atentamente en busca de problemas. Esto no debería ser así, pero después de muchos años, a menudo lo es . Tenga esto en cuenta cuando les comunique sus inquietudes acerca de que el equipo no funciona correctamente o según lo esperado. Y si recibe una respuesta que no comprende, intente filtrarla a través de esta visión del mundo.
• Estar en buenas condiciones de trabajo. Suena descarado, pero vale su peso en oro. Algún día, necesitarás un favor especial. Y algún día, ese administrador de sistemas estará feliz de hacer todo lo posible para hacerte la vida un poco más fácil, solo esta vez.
• Esa relación de trabajo va en ambos sentidos. Si el administrador del sistema está muy ocupado y puede hacer la vida un poco más fácil escribiendo un pequeño script o programa, ¡hágalo! Lo apreciarán más de lo que sabes.
• Se muy claro. "Esto apesta" no es tan claro como "tener una conexión de red intermitente es un poco molesto, ¿hay alguna posibilidad de que puedas verlo?"
• Si cree que su aplicación escalará, pregúntele al administrador antes de asumir que lo hará. Es posible que "vean" algo que usted no conoce o sepan algo sobre los límites de rendimiento del equipo en el que va a implementar.
• Si su aplicación necesita ser ajustada, pero no parece ser un problema de código, pregunte amablemente cómo están funcionando los servidores. Los administradores de sistemas atienden sus máquinas con amoroso cuidado y no se sienten complacidos cuando están "enfermos" o "mal portados". Preguntar bien hará que una máquina esté en mal estado (o la reparará / reemplazará).
• (como se menciona en otra parte) documente la configuración que usa y por qué la usa. Simplemente tener "establecer casilla de verificación X" o "descomentar línea de archivo de configuración Y" no ayuda. Podría configurar la opción que borra todos sus datos en el próximo reinicio para todo lo que sabe.
• Si no tiene tiempo para documentar la configuración en papel, intente documentarla en el sistema si es posible. Con los archivos de configuración, esto debería ser casi una práctica estándar: cada cambio de configuración debe tener una fecha, con las iniciales, el efecto esperado de esa configuración y la razón por la que se modificó (consulte el punto anterior). Este pequeño hábito me ha salvado el tocino más de una vez durante el tiempo de crisis. "¿Por qué hicimos eso?" "Porque exigimos la política X, y la configuración Y nos da el comportamiento que necesitamos para la política X".
• Cerveza. O cola. O incluso agua. Las bebidas son siempre bienvenidas. Ser un administrador de sistemas es un trabajo sediento.

La seguridad no es una ocurrencia tardía. Si bien una aplicación pirateada puede hacer que el programador parezca incompetente, es (al menos) un fin de semana perdido dedicado a verificar, limpiar y / o restaurar las copias de seguridad de un administrador de sistemas.

Por lo demás, no trate las copias de seguridad como control de versiones. Son para la recuperación ante desastres y no están realmente diseñados para restaurar su código porque olvidó lo que cambió.

Y deja de culpar ciegamente a las actualizaciones de Windows por que tu código se haya roto. No me importa que haya funcionado antes, dime por qué no funciona ahora, entonces podemos ver de quién es la culpa.

Cómo depurar problemas de red y ver cómo se ejecuta su programa con herramientas sysadmin. Como programador que comenzó a administrar el sistema, me sorprende lo impotentes que se vuelven muchos programadores una vez que la red "simplemente se detiene".

• Wireshark , para ver su código correr en una caja negra, paquete por paquete
• Herramientas para conectarse directamente a servicios de red:
  • Telnet, netcat o socat para conexiones simples a través de TCP o UDP
  • OpenSSL para lo mismo con cifrado (pista: intente openssl s_client -connect target-host:portalguna vez), para conectarse manualmente a servicios de red
• dig (en el paquete BIND 9) para depurar la resolución de nombres
• Ser capaz de determinar qué parte de la pila de red falló en función del tiempo y otras características de una conexión fallida
• Posiblemente HTTPFox y / o Firebug

Sepa cómo solucionar problemas.

Es muy fácil pasar el dinero (por ejemplo, su red está manejando mi comunicación con la base de datos). Puede ser culpa de la red, pero debe tener registros de aplicaciones con errores que, usando Google o SO, puedan revelar un problema en la configuración de una aplicación.

A todos les gusta culpar al hardware, el sistema operativo o la red, por lo que si practicas un poco más de diligencia debida, harás que el administrador de sistemas sea una persona feliz. Porque, como mínimo, es posible que pueda señalarlos en una dirección específica sobre lo que podría estar mal (en lugar de decir "su red apesta" o algo igualmente útil).

Documente todo lo que pueda. No puedo decirle cuántas veces el último administrador de sistemas pensó que sería lindo no documentar algo para 'seguridad laboral' o alguien solo quería entrar y salir. Al igual que un programador debe dejar buenos comentarios, los administradores de sistemas deben documentar. Un diagrama de la topología también sería bueno.

Plan B.

Siempre tenga en mente un plan de recuperación ante desastres cuando diseñe y desarrolle una solución. Reconozca los puntos únicos de falla que pueden conducir a una interrupción.

Documentación: no es necesario volverse loco, sino cómo funciona la aplicación, un diagrama que muestra cómo encajan los bits y las formas de probar cada componente cuando todo sale mal. La muestra de datos y resultados es agradable.

Requisitos: ¿en qué módulos se basa? Versiones OS?

Monitoreo: idealmente, los desarrolladores incluirían información de monitoreo y pruebas con la aplicación.

Hablando de embalaje, EMBALAJE! Nada peor que un "despliegue" que significa revisar una nueva revisión de un archivo desde VCS y copiarlo en un montón de servidores. Con demasiada frecuencia, los programadores no aprecian la complejidad de la implementación de software: hay razones por las cuales el software versionado y empaquetado constituye la columna vertebral de la mayoría de los sistemas operativos.

Si un desarrollador viniera a mí con un RPM que se instaló por primera vez con documentación concisa y completa y algunas pruebas de Nagios, sería mi nuevo mejor amigo.

Me sorprende que ninguna de las 17 respuestas dadas aquí hasta ahora incluya nada sobre garantizar que su aplicación se ejecute cuando inicie sesión como usuario estándar.

Aparte del proceso de instalación, la aplicación debería funcionar bien cuando inicie sesión con una cuenta de usuario estándar.

Copia de seguridad Copia de seguridad Copia de seguridad ... Pruebe la copia de seguridad ... Siempre esté listo para retroceder

Esto puede aplicarse solo a los programadores principiantes, pero trato con algunas cosas en cada proyecto con algunos programadores.

1. "Funciona en mi máquina" nunca es una declaración válida. Es responsabilidad del programador crear un programa de instalación para usar en el servidor, o al menos documentar cada conexión y dll y complemento que se requerirán en el servidor.

2. (He escuchado esto varias veces, así que no te rías) Ejecuto el exe en el servidor desde mi máquina y funciona. Pero, cuando lo ejecuto en el servidor (Citrix, Terminal Server, etc.) no funciona. Por favor, comprenda dll's y ocx's y cualquier otra cosa que requiera su programa y dónde y cómo están registrados, y cómo los usa su programa.

Esto puede parecer simple, pero lo trato constantemente.

Brian

• hable con su administrador tanto formal como informalmente sobre lo que está haciendo. Por lo general, estarán interesados ​​y pueden expresar posibles impactos sobre la producción desde el principio. No tiene que estar de acuerdo, pero ayuda a identificar los puntos problemáticos.
• No, no puede tener todo el servidor para usted ... Si lo necesita, es una decisión política, independientemente de lo técnicamente sólido que sea. Si quieres trabajar en política, adelante.
• El hardware de producción a menudo se ve diferente a su servidor de desarrollo, e incluso dentro de las granjas, las especificaciones en las máquinas son diferentes.
• Aprenda cómo se configura la producción, ya que es probable que no pueda replicarla en su escritorio, esto evita que haga suposiciones deficientes.
• El hecho de que pueda almacenar cosas en la memoria caché no significa que deba hacerlo, espere primero el cuello de botella (en pruebas unitarias o pruebas de rendimiento de preproducción)
• Si está pegando datos en una base de datos, piense cómo podría dividir los datos en datos de solo lectura (que podrían escalarse horizontalmente) y datos de lectura-escritura (que generalmente solo se escalan verticalmente).
• si está pegando datos en una base de datos, ¿debe ser realmente un RDBMS? existen otros sistemas de pares clave-valor que escalan mejor (netcache).
• No piense que AJAX es la solución final, se ve genial, pero limita las posibilidades de monitoreo y automatización. No digo que no lo uses, solo piénsalo dos veces.

OK esto es un poco despotricar pero:

a) Al codificar, suponga que la infraestructura subyacente podría fallar, y que no proviene de una tierra feliz, siempre feliz. O Google

b) Probablemente no tengamos los recursos para implementar algo como la infraestructura sobre la que ha leído, así que no se preocupe cuando las cosas se caigan. Es probable que sepamos lo que hay que hacer, pero por alguna razón, todavía no ha sucedido. Somos sus socios!

c) Como dijo jhs anteriormente, realmente ayudaría si tuviera una familiaridad pasajera con las herramientas para solucionar problemas de la infraestructura, como ping, traceroute (o la combinación de ambas: mtr), excavación, etc. Puntos de bonificación masivos por saber incluso sobre Wireshark.

d) Si programa una computadora, realmente debería saber cómo se conecta a la red y los conceptos básicos como poder analizar la salida de ipconfig / all o ifconfig. Debería poder poner en funcionamiento su conexión a Internet con una ayuda mínima.

De lo contrario, creo que Avery lo logró. ¡Los desarrolladores que hacen un poco de administrador de sistemas valen su peso en oro! Pero igualmente, los administradores de sistemas que entienden cómo los desarrolladores se ocupan de las cosas (incluidas las versiones, etc.) son bastante esenciales en la actualidad.

Esto parece estar en el aire en este momento, he notado más discusión sobre la relación entre desarrolladores y operaciones en los blogs.

Mantener Twitter Twittering

Particiones y Guerra

Prueba primero en operaciones

Que ningún grupo o función es 'mejor' que otro y que ninguno requiere 'cerebros más grandes' que el otro tampoco. He visto a ambas partes obtener toda la prima donativa en la compañía del otro, todos están tratando de lograr los mismos objetivos, enfóquense en estas similitudes y no en el hecho de que utilizan diferentes herramientas.

El arquitecto de infraestructura se convirtió en programador, aunque es posible que desee revertir esa transacción en el futuro :)

1. Hablen entre ellos, temprano y con frecuencia. Revise los diseños con los chicos que administrarán la infraestructura en la que se implementará su aplicación (si sabe quién será).
2. La pérdida de datos cero es posible, pero es una responsabilidad compartida por los desarrolladores y administradores de sistemas. Una vez más, hablar entre ellos puede ayudar aquí.
3. Su personal de infraestructura debería haber estado involucrado en la determinación de los requisitos no funcionales.
4. Organice cerveza (cuando el trabajo esté hecho) y pizza (mientras estamos trabajando). De alguna manera, la presencia de ese tipo de alimentos afecta nuestra capacidad de hacer que nuestras pequeñas cajas de 32 CPU hagan lo que quieras que hagan :)

Como alguien que ha sido administrador de sistemas para desarrolladores, y yo mismo como desarrollador, el consejo que se brinda aquí no solo es oro, sino que debería ser parte de la documentación de contratación de nuevos desarrolladores para empresas de todo el mundo.

Algo que no he visto (todavía) explicado es que los desarrolladores realmente deberían conocer los productos que usarán para crear los programas por los que se les paga. La cantidad de veces que he tenido que explicar y configurar servidores apache, eclipse e instalaciones de Visual Studio, y la base de datos en las máquinas de desarrollo es un poco preocupante.