Pregunta ¿Qué cosas debería saber cada administrador de sistemas?


Como programador, tendemos a tomar los administradores de sistemas por sentado. 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?


96


origen




Respuestas:


Yo empezaría con:

  1. Siempre tener un sistema de copia de seguridad de algún tipo. Aún mejor si tiene una historia.
  2. Considere los puntos únicos de falla y cómo tratarlos si fracasan.
  3. Dependiendo de la cantidad de computadoras involucradas, buscar la forma de crear y crear una imagen estándar en todas las computadoras hará que la vida de todos sea más fácil, no "funciona en la mía" porque tienen tal o cual programa que normalmente no está instalado.
  4. Documenta todo, aunque solo sea porque tu será Olvida cómo configuras algo.
  5. Mantente al tanto de las actualizaciones de seguridad.

70



documentar todos los pasos es algo que he visto hacer a buenos administradores de sistemas, y comencé a hacerlo yo mismo. Muy útil, por cierto. - Nathan DeWitt
Considerar sistemas de auto-documentación. Por ejemplo, ¿por qué mantener una lista de nombres de host en un archivo de texto o wiki en algún lugar cuando un archivo de zona bien comentado es la fuente canónica de información? - Dave Cheney
Dave, ¿ese archivo de zona bien comentado es accesible para todos? Si soy una persona nueva, no es más fácil que me digan "vaya a este wiki para obtener todas sus respuestas" en lugar de "todo está documentado en todas partes. El DNS está documentado en la configuración del DNS. El whozit está documentado en el whozit archivo de configuración. La base de datos está documentada en el archivo de configuración de la base de datos ". Eso parece muy ... antipático para mí. - Nathan DeWitt
Nathan, Dave: El truco es, por supuesto, usar un script para actualizar el wiki desde la fuente canónica. Ha funcionado de maravilla para mí, realmente lamento no poder usarlo donde trabajo ahora. - Anders Eurenius
Me gustaría añadir a esto: construir un sistema de prueba. Necesita un entorno donde el fracaso es una opción. Tengo un servidor que ejecuta VirtualBox para esto, pero he usado mi estación de trabajo personal cuando los servidores no están disponibles - Mark Porter


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

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

Documentación:

  • Documentar todo. Si no tiene uno, instale un wiki debajo del radar, pero asegúrese de realizar una copia de seguridad. Comience con la recopilación de datos y, un día, se formará un panorama general.

  • Cree diagramas para cada parte lógica y manténgalos actualizados. No pude contar la cantidad de veces que un mapa de red preciso o un diagrama de grupo me han salvado.

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

  • Cuando construya su sistema, instale y configure sus aplicaciones, pruébelo y realice su evaluación comparativa. Ahora, limpie los discos. Seriamente. 'dd' el primer megabyte de la parte frontal de los discos o, de lo contrario, deja el cuadro sin inicio. El reloj no se detiene: demuestre que su documentación puede reconstruirlo desde cero (o, mejor aún, que su colega no puede 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 una cinta, volver a cargar bases de datos desde volcados), detalles del proveedor / soporte, requisitos de red, cómo y dónde obtener hardware de reemplazo: cualquier cosa que pueda pensar le ayudará a recuperar su sistema.

Automatización:

  • Automatiza tanto como puedas. Si tiene que hacer algo tres veces, asegúrese de gastar el segundo en desarrollar su automatización para que el tercero esté completamente automatizado. Si no puede automatizarlo, documéntelo. Hay suites de automatización por ahí, vea si puede hacer que funcionen para usted.

Vigilancia:

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

  • Cree pruebas de extremo a extremo que comprueben 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 cumple doble función; Además de probar que la aplicación funciona, hace que las actualizaciones del sistema sean mucho más sencillas (el monitoreo del sistema informa que la actualización ha funcionado, el momento de volver a casa).

  • Realice evaluaciones comparativas, monitoree y recopile métricas sobre todo lo que sea sensato para hacerlo. Los puntos de referencia le dicen cuándo esperar que algo saldrá humo mágico. El seguimiento te avisa cuando tiene. Las métricas y las estadísticas facilitan la obtención de nuevos kits (con humo mágico fresco) a través de la administración.

  • Si no tiene un sistema de monitoreo, implemente uno. Los puntos de bonificación si realmente lleva las pruebas anteriores de extremo a extremo.

Seguridad:

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

  • Suscríbete al principio de 'bit menos'; si no está instalado, copiado o si no vive en el disco, no se puede comprometer. La instalación del SO y del software del "fregadero de la cocina" puede hacer la vida más fácil durante la fase de construcción, pero terminas pagándolo por el camino.

  • 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. Realice la reconstrucción a un servidor de repuesto con medios recién descargados, restaurando solo los datos de las copias de seguridad (ya que los binarios pueden verse comprometidos) o clone el host comprometido en un lugar aislado para su análisis, de modo que pueda reconstruir en el mismo kit. Hay toda una pesadilla legal en torno a esto, por lo que hay que errar por el lado de la preservación en caso de que necesite buscar vías legales. (Nota: IANAL).

Hardware:

  • Nunca asumas que algo hará lo que dice en la caja. Demuestra que hace lo que necesitas, en caso de que no lo haga. Te encontrarás diciendo que "casi funciona" con más frecuencia de lo que esperas.

  • No escatime en la gestión remota de hardware. Las consolas seriales y la gestión de luces deben considerarse obligatorias. Puntos de bonificación por tomas de corriente controladas de forma remota para aquellos momentos en que no tenga opciones.

(Aparte: hay dos maneras de solucionar un problema a las 3 am, una implica estar abrigado, trabajar en una computadora portátil a través de una VPN en su pijama, la otra implica una chaqueta gruesa y un viaje al centro de datos / oficina. 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 del cerebro pueden sorprender, y no hay duda de que tendrán (deberían) estándares o requisitos que se convertirán en dependencias del proyecto.

  • La documentación es parte del proyecto. Nunca tendrás tiempo de escribir todo el asunto después de que el proyecto se haya cerrado y el sistema haya pasado a mantenimiento, así que asegúrate de incluirlo como esfuerzo en la programación al inicio.

  • Implemente la obsolescencia programada 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 cuando el proveedor comienza a cobrar más en el 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 dirigir el negocio. La revisión del entorno a los 2 años y medio le da tiempo suficiente para saltar a través de los aros financieros y de gestión necesarios para que se solicite un nuevo kit y para implementar una migración sin problemas antes de enviar el viejo kit al gran vendedor en el cielo.

Desarrollo:

  • Asegúrese de que sus sistemas de desarrollo y puesta en escena se asemejan a la producción. Las VM u otras técnicas de virtualización (zonas, LDOM, vservers) hacen que los clones de producción del mundo real en todos los sentidos sean fáciles.

Copias de seguridad

  • Los datos de los que no está realizando una copia de seguridad son datos que no desea. Esta es una ley inmutable. Asegúrese de que su realidad coincide 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 en silencio para tener alguna esperanza de recuperación, y todos estos problemas deben abordarse. Algunos paquetes de copia de seguridad tienen agentes u otros métodos para tratar con archivos abiertos / bloqueados, otros paquetes no. Volcar las bases de datos en el disco y respaldarlas cuenta como una forma de "inactividad", pero no es el único método.

  • Las copias de seguridad no tienen valor a menos que se prueben. Cada pocos meses, saque 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 el fracaso, documente los puntos débiles diseñados de cada sistema, qué los desencadena y cómo recuperarlos. Hará toda la diferencia cuando algo salga mal.


44



+1 Es como si alguien me mirara a la mente, y era hermoso; p - Oskar Duveborn
"Realice evaluaciones comparativas, monitoree y recopile métricas en todo lo que está en su sano juicio. Las referencias le indican cuándo esperar que algo salga humo mágico. La supervisión le indica cuándo lo ha hecho. Las métricas y las estadísticas facilitan la obtención de un nuevo kit humo) a través de la gestión ".  Oro puro - T.J. Crowder


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


43



+1 por esto. No es porque lo hagamos. Mira Fácil que en realidad es. - Gert M
Como generalista haciendo trabajo tanto de administración como de programación, entiendo perfectamente su difícil situación. +1 - Avery Payne
Por otra parte, por supuesto, he encontrado algunos tipos de administradores de sistemas que realmente no entienden la diferencia entre el tipo de scripts y los pequeños programas de utilidad que todos podemos eliminar y la programación "real". - Rob Moir
+1 Robert: O el administrador del sistema que dice "es una declaración simple" para solucionar una arquitectura de red mal diseñada. El respeto mutuo y la comprensión es clave. - Steven Evers


  • Tenga en cuenta que, para bien o para mal, muchos de los servidores y / o equipos de red a los que tienden son muy parecidos a los niños de una segunda familia. Estos son sus bebés.  Los cuidan, los ayudan cuando están enfermos y los vigilan atentamente en busca de problemas. Esta no debería así sea, pero después de muchos años, a menudo es. Tenga esto en cuenta cuando les comunique sus inquietudes sobre el equipo que no funciona correctamente o según las expectativas. Y si recibe una respuesta que no comprende, intente filtrarla a través de esta visión del mundo.
  • Estar en buenos términos de trabajo. Suena cheezy, pero vale su peso en oro. Algún día, necesitarás algún favor especial. Y algún día, ese administrador de sistemas se alegrará 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 podría hacer la vida un poco más fácil escribiendo un pequeño script o programa, ¡entonces hágalo! Ellos lo apreciarán más de lo que ustedes saben.
  • 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 pueda verlo?"
  • Si crees que tu aplicación se escalará, pregunta al administrador antes asumiendo va a. Pueden "ver" algo que usted no ve, o saber algo acerca de los límites de rendimiento del equipo que va a implementar.
  • Si su aplicación necesita ajuste, pero no parece ser un problema de código, pregunte amablemente sobre el rendimiento de los servidores. Los administradores de sistemas cuidan sus máquinas con mucho cuidado y no se sienten complacidos cuando están "enfermos" o "mal portados". Preguntar bien hará que una máquina enferma gire (o la repare o reemplace).
  • (como se menciona en otra parte) documente la configuración que usa, y por qué los usas El solo hecho de "establecer casilla de verificación X" o "descomprimir línea de archivo de configuración Y" no ayuda. Podría estar configurando la opción que borra todos sus datos en el próximo reinicio por 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 estar marcado con la fecha, con las iniciales, el efecto esperado de esa configuración y la razón por qué Se cambió (ver punto anterior). Este pequeño hábito ha salvado mi 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 el agua. Las bebidas siempre son bienvenidas. Ser un administrador de sistemas es un trabajo sediento.

27



Para la documentación del archivo de configuración / problema de cambio, recomiendo colocar todos los archivos de configuración en un sistema de control de versiones. Esto debería ser muy fácil para los programadores, ya que es de esperar que ya estén utilizando un sistema de este tipo para su código fuente. Si también agregan un comentario cada vez que realizan un cambio, será fácil volver al historial y ver qué se cambió cuando y por qué. - Anders Sandvig
+1 para eso, ya que "cierra el ciclo" en la gestión de cambios. Gran sugerencia. - Avery Payne
Excelente sugerencia para dar informes claros de error. Nada me frustra más que después de que me digan que hay un problema, y ​​sabiendo que potencialmente podría afectar a mucha gente, tengo que molestar a los detalles con un programador desinteresado. - Dave Cheney


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.

Para el caso, no trate las copias de seguridad como control de versión. Son para la recuperación de desastres, y no están realmente diseñados para restaurar su código porque olvidó lo que cambió.

Y deje de culpar ciegamente a las Actualizaciones de Windows por la ruptura de su código. No me importa si funcionó antes, dime por qué no funciona ahora, entonces podemos ver de quién es la culpa.


23





Cómo depurar problemas de red y ver cómo se ejecuta su programa con las herramientas sysadmin. Como programador que comenzó en la administración de sistemas, me sorprende lo impotentes que muchos programadores se convierten en una vez que la red "simplemente se detiene".

  • Wireshark, para ver su código ejecutarse en una caja negra, paquete por paquete
  • Herramientas para conectarse directamente a los servicios de red:
    • Telnet, netcat o socat para conexiones simples sobre TCP o UDP
    • OpenSSL para lo mismo con el cifrado (pista: prueba openssl s_client -connect target-host:port en algún momento), para conectarse manualmente a servicios de red
  • cavar (en el paquete BIND 9) para depurar la resolución de nombres
  • Ser capaz de decir qué parte de la pila de la red falló en función de la sincronización y otras características de una conexión fallida
  • Posiblemente HTTPFox y / o Firebug

17



+1. Cualquier desarrollador que escriba una aplicación que dependa de un rendimiento de red sólido debe leer 'TCP / IP Illustrated v1', del gran difunto W. Richard Stevens, antes de comenzar a codificar. - Murali Suriar
Gracias por todos los muchachos upvotes. Hace años que me molesta ver a los programadores en una situación de impotencia una vez que falla la red subyacente. Y en estos días, casi toda la programación es programación en red. - jhs


Sepa cómo solucionar problemas.

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

A todo el mundo le gusta culpar al hardware, al sistema operativo oa la red, por lo que si practica un poco más de diligencia debida, hará que el administrador del sistema sea una persona feliz. Porque, si no es nada más, puede señalarlos en una dirección específica en cuanto a lo que podría estar mal (en lugar de decir "su red apesta" o algo igualmente útil).


14



Absolutamente. No puedo comenzar a contar las horas que he pasado buscando problemas en los lugares equivocados debido a que la gente me señala en el incorrecto dirección - Gert M


Documenta todo lo que puedas. No puedo decirle cuántas veces el último administrador de sistemas pensó que sería lindo no documentar algo para 'seguridad laboral' o alguien simplemente 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 sería bueno también.


8