Pregunta Métricas de rendimiento Sysadmin?


Trabajo en punto com y parte de la responsabilidad de nuestro equipo es mantener la aplicación web de producción y la granja de servidores. Solo recientemente se creó nuestro departamento, y ahora tenemos una gran cantidad de servidores de parches de recuperación, e implementación de monitoreo y copias de seguridad.

Para comenzar con este monstruo, lo hemos dividido en fases, y como parte de nuestra primera fase, estamos reinstalando los sistemas operativos en varios servidores, actualizándolos de las antiguas instalaciones del sistema operativo Redhat 8 (no fedora 8). Como una aplicación web, los servidores necesitan ejecutar apache y php. Los módulos que deben compilarse en estos programas están documentados y se documenta un proceso de compilación anterior.

Como administradores de sistemas, ¿qué es lo que esperan documentar, y qué deberían documentar? Dado que tanto el proceso de compilación como la documentación deben actualizarse, ¿cuál es la mejor manera de diseñar los elementos que deben hacerse? ¿Debería definir los pasos como parte del trabajo del administrador del sistema o parte del trabajo del gerente técnico? ¿Es esto parte de la calificación de ser un "ingeniero senior de Unix" frente a un ingeniero junior? ¿Qué estándar desearía tener para evaluar su desempeño en un proyecto como este si afectara su revisión de desempeño?

Editar: La aplicación está en continuo desarrollo. La mayoría se escribió en PHP4 y continúa ejecutándose en PHP4, sin embargo, un código más reciente que se ejecuta como un servicio web se ejecuta como PHP5. Así que en las mismas cajas hay una instalación php4 y PHP5. Los módulos requeridos para cada construcción están documentados. El administrador del sistema tiene ese documento.


5
2017-10-26 19:02


origen


serverfault.com/questions/11615/… - l0c0b0x
"¿qué es lo que ustedes afuera esperan haber documentado"? Muy poco. "y que deberías estar documentando?" - Todo. :) - John Gardeniers


Respuestas:


Si es un problema único, ¿cómo puede medir si el problema está en la persona o en el problema?

Debería estar documentando todo lo que se requeriría para que su departamento funcione si la mitad de su gente es asesinada / despedida / etc ... si necesita reconstruir el departamento con nuevos administradores, deberían poder hacer que las cosas funcionen nuevamente en un nuevo Ubicación con su documentación.

En la práctica ... jeje! Sí claro. Tienes suerte si los documentos se mantienen actualizados, incluso si se crean en la mayoría de los lugares.

Si está administrando las tareas monstruosas, quizás necesite reunirse con sus administradores y preguntar cómo van las cosas y qué se ha intentado. Si en estas tres semanas se le ha encomendado este problema y no se resuelve, ¿es porque no está trabajando en ello? ¿Qué ha tratado de rectificar el problema?

No puede solucionar el problema o él probablemente comenzará a pelear con usted por eso. Los administradores de sistemas necesitan suficiente libertad para trabajar sin sentir que están siendo examinados a cada paso. Pero si el proyecto o la tarea está muy atrasado, entonces tiene una preocupación legítima. Averigüe de él si hay algo que necesita para hacer el trabajo, o cuál es el problema de que está teniendo dificultades para superar.

Buen libro: Managing Humans por Michael Lopp.

El rendimiento debe basarse en cómo se abordan los problemas de TI para satisfacer las necesidades de los usuarios, junto con el mantenimiento de los servidores y los problemas de infraestructura. No es posible reducir el problema a "resolver X problemas al día" o "escribir X líneas de código" para medir a cada empleado.

Tal vez pueda obtener información de otros miembros del equipo para obtener información sobre cómo se están desempeñando los demás o cuáles son las principales necesidades. Los buenos técnicos quieren trabajar con buenos técnicos. No quieren trabajar con personas que son "felices y agradables" pero incompetentes. Trabajarán con un cachorrito gruñón que odia estar en la habitación con ellos si eso significa que todo funciona bien y el cachorrito sabe lo que hace.


8
2017-10-26 19:14



+1. Ser un administrador de sistemas es una meritocracia técnica. - Sam Halicke
Entonces, en una meritocracia técnica, ¿los otros técnicos pueden votar si conservas tu trabajo? - Zak
@ Zak: si lo odian lo suficiente, encontrarán la manera de hacer que abandone el trabajo ... o el negocio tiene una alta rotación hasta que alguien competente asuma el cargo u otros incompetentes ocupen el departamento, lo que los hace ineficaces en general. - Bart Silverstrim
@ zak-it también depende del entorno laboral ... para los técnicos, todo se trata de respeto. Si se respetan entre sí (y tiende a ser una meritocracia técnica), entonces tendrán un lugar donde les gusta trabajar. Si no, su equipo tenderá a ser ineficaz y hostil. Un departamento orientado a la tecnología tiene una dinámica muy diferente a la mayoría de los otros departamentos en la forma en que las personas se relacionan entre sí. - Bart Silverstrim
@zak: lo que quise decir es más o menos lo que Bart dijo anteriormente, se trata de respeto. Las personas admiran a los hackers reales en su equipo y, lo que es más, se dispusieron a aprender de ellos. Esto fomenta una actitud de respeto mutuo y tutoría: todos están contentos. Lo contrario es que el administrador sénior no es respetado, y todos los integrantes de su equipo se encontrarán con insubordinación y dudas, lo que no lleva a todos precisamente a ninguna parte. Además, a los técnicos les gusta ser reconocidos; Demostramos que el trabajo que hacemos es valioso. Bajo la sombra de un administrador superior incompetente, puede hacer que todo el equipo se vea mal. - Sam Halicke


Cosas viejas (legado) pueden ser difíciles:
Si leo correctamente, tienes versiones de software antiguas e intentas ponerlo en funcionamiento en edificios recientes del sistema operativo. Red hat 8 tiene 7 años ahora, así que diría que la aplicación también debería actualizarse (tal vez estos módulos no se hayan actualizado desde entonces). Así que suena como un desastre difícil como dices.

Documentación y expectativas:
Depende, pero realmente deberías exponer lo que esperas en general. Haz todo lo que quieras muy claro. Entonces deberías poder confiar en el administrador para que siga con eso y te actualice si no pueden por alguna razón. Puede consultar con ellos y asegurarse de que estén haciendo esto. La administración del sistema es extraña, ya que varía mucho de una posición a otra, por lo que puede llevar algún tiempo entender qué esperas de ellos.

Mi recomendación, ¡Comunícate !:
Creo que no podemos decirte si estos son problemas difíciles no lo son. Los desarrolladores no deben estar tan lejos de los administradores de sistemas, por lo que si tiene problemas, consiga un desarrollador de confianza para que se siente con el administrador y lo ayude a resolver estos problemas. Ese desarrollador debe ser capaz de dar algo de retroalimentación.

En cuanto a la actualización de todo:
Algunos pensamientos que pueden o no ser útiles:

  • ¿En qué medida se utiliza esto? Tal vez sería mejor virtualizarlo y olvidarlo :-P
  • ¿Qué tan complicada es la aplicación? ¿Podría ser más barato y tomar menos tiempo simplemente reconstruirlo? Esto también se remonta a la actualización de la aplicación, tal vez si estos módulos están desactualizados, esas partes deben sacarse y recodificarse. También regresa a la comunicación, a los administradores de sistemas de equipo y a los desarrolladores para encontrar la mejor solución, si es posible.

5
2017-10-26 19:17



Es heredado, pero es solo el código php4 que necesita una compilación php4 para ejecutarse en un servidor apache. Nada como llamar a llamadas específicas del sistema operativo que hacen que el código PHP en sí falle; simplemente no tiene la compilación binaria de php correcta, por lo que el código no se ejecutará debido a las llamadas fallidas de la biblioteca (es decir, syck_load). Y definitivamente no es más barato reconstruir la aplicación ... llevaría meses. - Zak
Si es tan simple, ¿por qué no lo has construido TÚ, Zak? Me parece que usted es un gerente no técnico que trata de gestionar personal técnico. Deje de sentirse frustrado con sus empleados y rediríjalo a donde pertenece, en el espejo. Entonces ve a contratar un gerente técnico. - toppledwagon
Gracias por ese comentario derribado. Terminé yendo y construyéndolo yo mismo. Dejé caer las otras 10 cosas que tenía porque se estaba estancando otros 3 proyectos. Me tomó 2 días, pero no 3 semanas. ¿Y ahora que? - Zak


Diría que si su administrador del sistema no puede completar una instalación personalizada del sistema operativo después de 3 semanas, es incompetente o está confundiéndolo de alguna manera, lo que provoca retrasos interminables. En el escenario que describió, un flujo de trabajo básico / básico debe ser: el equipo de administración y / o implementación presenta una lista de requisitos y dependencias. Los requisitos incluirían plazos, escalabilidad, tolerancia a fallos, robustez, umbrales de disponibilidad, etc. Las dependencias cubrirían qué aplicaciones necesitan ejecutarse en el servidor y, opcionalmente, qué software se requiere para admitir esas aplicaciones. El administrador del sistema posiblemente podría manejar este último a menos que tuviera necesidades específicas muy específicas relacionadas con el software y las versiones de software. De cualquier manera, todo debe estar documentado, con procesos de aprobación establecidos para que el "chico del pasillo" no pueda hacer cambios a la espalda de la gente y termine metiéndose con el flujo de trabajo y las expectativas del administrador de sistemas. Una vez que toda la información se le da al administrador del sistema, él / ella debe poder proporcionar una estimación de tiempo más o menos sólida.

Por lo que has dicho, parece que esta persona ni siquiera está probando las versiones para ver si todo funciona. En un entorno ideal, se establecería un conjunto de scripts de prueba para que una compilación pueda verificarse como correcta o no ejecutando dichos scripts. Ellos verificarían no solo la funcionalidad, sino también si se han incluido o no las versiones de software correctas (esto incluye las bibliotecas de sistemas y aplicaciones). En entornos más grandes, no es raro que un equipo completo se dedique a las pruebas de rendimiento, de modo que una vez que se hayan implementado un servidor y sus aplicaciones instaladas, puede estar seguro de que funcionará y se escalará, así como, si no mejor, que, en un laboratorio o entorno de puesta en escena. Eso es otra cosa: un entorno de ensayo es clave. Podría tener políticas implementadas que requieran que los servidores pasen de un entorno de laboratorio a un entorno de prueba y, finalmente, a un entorno de producción.

No me importa si un administrador de sistemas toma tiempo para estudiar cuidadosamente las cosas, de modo que cuando un servidor se pone en producción, funciona perfectamente. Solía ​​conocer a un chico que hizo eso. No era que fuera incompetente; más bien, era consciente de la seriedad de los despliegues fallidos, por lo que se tomó un poco de tiempo extra para asegurarse al 100% de que todo estaba bien. Su reputación hasta ahora es casi impecable, y lo recomendaría a cualquier equipo de administración de sistemas. Sin embargo, los resbalones repetidos en tareas triviales deben levantar banderas naranjas (aún no rojas). Un administrador de sistemas básico debe conocer sus sistemas operativos y las bibliotecas de aplicaciones de uso común, de modo que cuando llegue el momento de construir un sistema, en su mente hay muy pocas preguntas sobre qué sistema operativo utilizar y qué bibliotecas y aplicaciones implementar. En cuanto a la creación de un servidor personalizado para un conjunto de aplicaciones personalizadas, me llevaría aproximadamente de 1 a 2 días completar la instalación y configuración básica (más los ajustes de rendimiento, el endurecimiento, etc.). Después de eso, dependería de lo que se necesita instalar. Cuanto mayor sea la cantidad de requisitos de software, más tiempo tomará construir, instalar y probar, y tal vez eso es lo que está retrasando a su administrador de sistemas. Sin embargo, no puedo decirlo con seguridad, ya que no proporcionó suficiente información.

Espero que eso ayude.

Miguel


2
2017-10-26 19:34





Grandes respuestas por encima. Me gustaría enfatizar especialmente este punto de la publicación de Bart:

Debería estar documentando todo lo que se requeriría para que su departamento funcione si la mitad de su gente es asesinada / despedida / etc ... si necesita reconstruir el departamento con nuevos administradores, deberían poder hacer que las cosas funcionen nuevamente en un nuevo Ubicación con su documentación.

Esto es absolutamente vital para algunas prácticas comerciales y debería ser un requisito, no una opción. ¿Qué pasa si "el único que sabe que el sistema vital XYZ" se cierra en ti o tiene que ser despedido? Las personas son personas, estas cosas suceden. Documentar los principales sistemas y procesos, cualquier requisito especial, advertencias, qué servidores son responsables de qué. Eso es al menos lo básico: los administradores más decentes descubrirán los detalles más pequeños como parte de su trabajo.

Sin embargo, como se mencionó anteriormente, en la "vida real", de hecho, sería una suerte tener estos documentos creados, mucho menos actuales y correctos. En mi opinión, vale la pena sacar a un administrador del proyecto y encargarle que se ponga al día con la documentación del mismo, si es posible.

Espero que las cosas funcionen.


1
2017-10-26 19:25





El tipo probablemente se está volviendo loco porque parece que su entorno de TI es una pesadilla, según su breve explicación de cómo funcionan las cosas.

Estaría dispuesto a apostar un centavo a que las instrucciones que recibe su SA de los desarrolladores / personas de tipo unidad de negocios también son terribles. Haga que alguien se siente entre las personas que envían las solicitudes y el tipo que está trabajando. Permítales rechazar las solicitudes que no tienen sentido y el documento que se está haciendo.

Einstein dijo: "La locura es hacer lo mismo una y otra vez y esperar resultados diferentes"


1
2017-10-26 20:27



Lo configuramos en fases como lo mencioné anteriormente exactamente por la razón de limitar el alcance. Toda esta parte del proyecto es tomar una aplicación PHP4 en servidores redhat 8 y hacer que se ejecute en servidores CentOS actualizados. Ahí es un entorno de escenario para que todo sea probado, así que tampoco es como prueba de fuego ... - Zak
@Zak: la única forma de saber realmente es reunirse con el departamento. No tenemos idea de cómo es su entorno (trabajo) ... la administración puede tener una vista de 10,000 pies y ver las cosas de una manera, pero en las trincheras hay un ambiente muy diferente. Necesita trabajar con su gente para averiguar cuál es realmente el problema. Es por eso que fueron contratados para el puesto en primer lugar, ¿verdad? :-) - Bart Silverstrim


He hecho un montón de trabajo de administrador de sistemas para startups, y debo decir que la documentación antigua es peor que ninguna documentación. No puedo contar las veces que revisé la documentación del sistema existente para tener una idea de cómo se unen las cosas solo para encontrar que el sistema ha sido totalmente rediseñado.

Esta situación generalmente surge cuando un administrador del sistema deja la compañía y su última tarea es documentar los sistemas. Con un pie fuera de la puerta, la calidad de la información generada suele ser deficiente. Y si el administrador del sistema no se reemplaza de inmediato (el caso habitual), los sistemas generalmente son administrados por el desarrollador menos competente y / o menor (ya que tiene tiempo). Lo que significa que los sistemas pueden desincronizarse, no estar documentados y, en el peor de los casos, variar de una máquina a otra (un dolor real con un conjunto de aplicaciones web donde una es diferente de las otras).

Aborrezco la sintaxis de la wiki, pero me gusta que la documentación del sistema resida en una wiki, así que al menos tengo una marca de tiempo y un nombre de quién documentó qué y cuándo. Una instalación de MediaWiki es trivial para la configuración y perfecta para las cosas del sistema.

En cuanto a lo bueno que es tu sr. sysadmin es, es difícil de decir. Muchos de nosotros apestamos y muchos de nosotros pasamos a un segundo plano simplemente haciendo nuestro trabajo. Y todos tenemos nuestros días malos.

No hace mucho tiempo pasé una loca cantidad de tiempo (como dias) tratando de hacer que Ganglia compile en una máquina de 64 bits solo para encontrar que era un error en el enlace. Estoy seguro de que me parecía un completo idiota para esas personas ...

La mayoría sr. sysadmin son programadores bastante buenos, en mi experiencia. Averiguar las opciones de compilación para que algo funcione no debería ser un problema, a menos que sea algo que no sea obvio. Parece que su administrador de sistemas tiene todo lo necesario para hacer el trabajo, pero el diablo está en los detalles.

Mi consejo: sé directo y pregunta cuál es el problema. Y echa un vistazo al libro "Managing Humans" que alguien más sugirió, es muy bueno.


1
2017-10-26 21:50