Los primeros signos de un mal administrador de sistemas

Estamos a punto de conseguir que nuestro primer administrador de sistemas se ocupe de una multitud de servidores SQL que anteriormente han sido tratados de manera incómoda por una mezcla de desarrolladores y soporte de TI. Hace mucho tiempo que estamos atrasados, y hemos estado tratando de persuadir a los superiores para que acepten uno durante años.
Bueno, finalmente lo hicieron, pero el salario que pudimos ofrecer no fue exactamente inspirador por decir lo menos. Sin embargo, hemos enganchado uno de alguna manera.
Lo que me gustaría saber es cuáles son los primeros signos a tener en cuenta para que un nuevo administrador de sistemas realmente no sepa qué están haciendo o qué hábitos peligrosos buscar, con un enfoque particular en SQL Server. Estoy un poco nervioso de que nuestra caza de ofertas en el sótano no funcione demasiado bien, como ha sido el caso con otros roles.

¿Alguna idea, por favor?

Tome esta primera parte con un grano de sal, porque quizás esté influenciada por mi trabajo como contratista durante tantos años.

Considere consultar a un contratista si su capacidad de pago es tal que no puede atraer a los mejores talentos a tiempo completo. Si paga muy poco y pide demasiado, obtendrá empleados poco calificados, empleados con defectos evidentes que pueden no estar relacionados con las habilidades (habilidades interpersonales deficientes, problemas de abuso de sustancias, etc.), o usted ' Terminaré con una posición de "puerta giratoria" donde los empleados trabajan por un tiempo y se van por una mejor paga.

Si su empresa está obsesionada con pagar muy poco y necesitar a alguien durante un período de tiempo determinado, en lugar de cumplir con un conjunto de tareas, entonces probablemente se encuentre en un escenario desesperado. Del mismo modo, si las tareas mantendrán ocupado a un empleado de tiempo completo y la compañía planea pagar muy poco, entonces tampoco tiene sentido. Usted va a conseguir lo que se paga en el largo plazo, de una manera u otra.

Supongo que realmente no tiene una necesidad a tiempo completo, y la compañía probablemente podría gastar el salario planificado, o menos, en un contratista que haría todo lo que necesita.

Un contratista es mucho más fácil de "deshacerse" si la relación es "mala". Por lo general, un contratista puede ser mucho más flexible que un empleado a tiempo completo en relación con la logística del trabajo (fines de semana, noches, etc.). Un buen contratista tratará las necesidades de su empresa con un alto grado de habilidad y cuidado porque saben con qué facilidad su empresa puede cortar la relación y buscar en otro lado.

Esto va a sonar realmente trillado, pero más que cualquiera de los otros elementos a continuación, preste atención a la capacidad de su administrador de sistemas para comunicarse con los demás. Las habilidades básicas de escritura y habla son importantes y hacen mucho para indicar el estado de los procesos mentales que ocurren "detrás de escena". El trabajo de un administrador de sistemas debe incluir la comunicación con otros empleados de TI y no empleados de TI, y la capacidad de comunicarse de manera efectiva es esencial. Tener la capacidad de formar analogías y comunicar conceptos abstractos es sin duda un buen "guinda del pastel", pero si su administrador de sistemas ni siquiera puede escribir oraciones completas o expresar pensamientos completos, entonces ya no tiene remedio.

Hay puntos en las respuestas de todos los demás que me parecen verdaderos: un "mal ajuste" (ya sea un empleado o un contratista). He sido el tipo que ayuda a las empresas a cerrar la brecha entre despedir a un administrador de sistemas malo y contratar un reemplazo, y he visto que se desarrollan varios escenarios malos. (Ser la persona que está cambiando las contraseñas, buscando "puertas traseras", etc., mientras el administrador del sistema está en la oficina del CEO que es despedido es un trabajo divertido, pero también estresante).

Algunas de las actitudes desagradables "específicas de TI" que he visto (criticando algunas partes de las respuestas de otros carteles aquí, sin vergüenza) en situaciones disfuncionales incluyen:

• Arranca todo y comienza de nuevo : una cosa es identificar algo que es una "bomba de tiempo" y cuidarlo, pero a menudo en TI me encuentro con administradores de sistemas (a menudo inmaduros y de nivel de entrada) que buscan "construir un imperio" a su imagen, y obsesionarse con la eliminación de la infraestructura vieja por el bien de instalar nuevas. Una cosa es hacer un caso de negocios respaldado por hechos y proyecciones de ROI, pero he visto esta disfunción particular como nada más que un fuerte impulso personal para reemplazar los sistemas en aras del reemplazo.

• No puedo decirte eso: Estos son los administradores de sistemas que, si bien toman una fuerte participación personal en su trabajo, van demasiado lejos y se vuelven demasiado posesivos, secretos y paranoicos. Las computadoras pertenecen al negocio, no al administrador del sistema. No documentar el trabajo, revelar contraseñas o ser abierto sobre cómo funcionan (o fallan) los sistemas no es una buena señal. He oído que algunos administradores de sistemas citan "seguridad" como una razón para ser reservado, pero la seguridad por oscuridad no es seguridad. También escuché a los administradores de sistemas con esta actitud decir cosas como "Sí, pero si le doy las contraseñas a tal y tal cosa, simplemente lo arruinarán". Por lo general, esto va acompañado de una declaración velada o abierta de temor por ser culpado si algo sale mal después de la divulgación.

• Culpe a alguien / a todos / a cualquier otra persona : estos son los administradores de sistemas que constantemente citan a terceros, su predecesor o los usuarios que experimentan problemas como la causa de los problemas. Ciertamente, no son problemas causados por todos estos factores, sino un patrón de señalar con el dedo consistente y repetida es una mala señal. Todos hemos tenido que lidiar con erratas de hardware, errores de software y usuarios creando problemas para ellos mismos. Ser capaz de identificar una de estas fuentes como la causa raíz de un problema no lo hace señalar con el dedo. Sin embargo, no estar dispuesto a investigar un problema e identificar una causa raíz, combinado con la reacción de agitar las manos vagamente y decir "Debe ser que el enrutador con errores de Windows / Linux / Cisco / etc ..." es motivo de preocupación.

• Viaje de poder : estos son los administradores de sistemas que se deleitan y establecen obstáculos para los usuarios debido a una agenda personal o una agenda comercial percibida. Una vez más, una cosa es poner limitaciones a los usuarios por razones comerciales justificadas. Sin embargo, es otra forma de ser el "impedidor de los servicios de TI" simplemente por la locura de poder controlar a los demás. He visto esta disfunción particular extenderse a cosas realmente desagradables como el "acecho electrónico" de los empleados al leer su correo electrónico, realizar capturas de pantalla / sesión de forma encubierta, escuchar llamadas telefónicas y, en general, ser una persona "espeluznante" para los demás.

• Las políticas no se aplican a mí : a menudo combinadas con la actitud de "viaje de poder", estos son los administradores de sistemas que se niegan a estar sujetos a las políticas de TI que ellos mismos, de otro modo, imponen o dictan. Si bien puede ser benigno e inofensivo, he visto que esto causa situaciones desagradables como litigios de acoso sexual amenazado (un administrador de sistemas que navega y exhibe de manera prominente contenido inapropiado para el trabajo). Los administradores de sistemas ocupan puestos de confianza y necesitan mantener una actitud de profesionalismo. Parte de esa actitud significa jugar con las mismas reglas y ser responsable como todos los demás. El hecho de que tengamos la capacidad de realizar actividades "extraoficiales" con nuestros permisos y derechos de acceso elevados no significa que debamos hacerlo.

• No puedo admitir debilidad: Se necesita una persona fuerte para decir "No sé la respuesta a eso, pero puedo encontrarla para ti". Todos tienen vacíos en su conocimiento y experiencia. Esta disfunción particular a menudo resulta en situaciones en las que un administrador de sistemas termina por encima de su cabeza. Es importante asumir riesgos calculados en el desarrollo profesional, y se puede decir que un gran crecimiento personal ocurre cuando las personas "muerden más de lo que pueden masticar" y tienen éxito. Por otro lado, un gran gasto (o una falla total) para una empresa podría ocurrir fácilmente cuando un administrador de sistemas decide abordar problemas importantes como la recuperación de desastres o la seguridad de TI y falla por falta de capacidad. Los gerentes que no permiten irrazonablemente el acceso de sus empleados a recursos / capacitación / apoyo de terceros pueden ayudar a crear este tipo de cultura.

• Estos son mis juguetes: Este es el administrador de sistemas que trata la infraestructura de TI empresarial como un juguete emocionante. Una cosa es identificar una tecnología particularmente interesante que satisfaga bien las necesidades de una empresa, pero otra muy distinta es influir en una empresa para gastar dinero en tecnología con el propósito no declarado de ser algo divertido para jugar. He visto situaciones en las que los administradores de sistemas se enamoraron de una tecnología determinada y deciden incorporar esa tecnología para resolver un problema no porque sea adecuado para las necesidades del negocio, sino porque es algo con lo que les gustaría jugar. He visto que esto sucede todo tipo de cosas: fibra óptica, virtualización, equipo SAN, redes inalámbricas, etc. La administración debe mantener esto bajo control tanto como sea posible,

• Siempre lo he hecho de esta manera: Este es el administrador de sistemas que está muerto en su camino. Por lo general, también he encontrado esto combinado con una actitud de "No quiero aprender sobre cosas nuevas". Nuestro campo está cambiando. Parte del trabajo que hicimos hace 10 años está automatizado hoy, y parte sigue siendo "lo mismo de siempre". Todo lo relacionado con nuestra industria se revisa, actualiza y actualiza constantemente. Las mejores prácticas cambian más lentamente, pero incluso ellas también cambian. No es razonable esperar que cada administrador de sistemas se mantenga al día con la "tecnología de punta" de la tecnología, pero también es inaceptable que un administrador de sistemas languidezca en tecnología de hace años que no muestra signos de interés en la actualización de habilidades. Si una empresa es una preocupación creciente, su operación de TI debe ser prospectiva. (Obviamente, también hay un equilibrio aquí.

• Sin comprensión de los negocios : los negocios "hacen TI" porque ayudan a hacer negocios de manera eficiente. Cualquier otro uso de TI en los negocios es contraproducente. Con demasiada frecuencia he visto administradores de sistemas que desconocen los conceptos básicos de contabilidad y negocios (los ingresos menos los gastos equivalen a ganancias, etc.). Nunca esperaría que un administrador de sistemas fuera un experto en contabilidad, pero esperaría que entendieran la forma básica en que una empresa incurre en gastos con el fin de obtener ganancias. En tiempos económicos pobres, especialmente, es bueno que su administrador de sistemas entienda de dónde proviene el dinero y por qué el negocio toma las decisiones que toma en relación con el destino del dinero. Un administrador de sistemas que cree que TI se distingue de la parte "comercial" del negocio no es un activo.

• Sin deseo de continuidad : en la cultura laboral actual, se debe suponer que todos trabajaremos para una variedad de empleadores. Nuestro trabajo hoy, estadísticamente, no será nuestro trabajo para siempre. Un buen administrador de sistemas debe preparar la documentación no porque "puedan ser atropellados por un autobús", sino porque su reemplazo eventual lo necesitará. La falta de voluntad para preparar la documentación debido a la "seguridad laboral" percibida apesta, para mí, a un individuo que no desea la movilidad ascendente. Ya no trabajo para un solo empleador, pero si lo hiciera, estaría planeando lo que iba a hacer a continuación, y manteniendo la documentación actualizada para que mi reemplazo tenga un mejor tiempo (al igual que yo me gustaría de mi predecesor en mi próximo trabajo).

Franqueza. Desea poder ver lo que está haciendo y cómo lo está haciendo.

Diría que el síntoma número uno de un choque de trenes en progreso es si el tipo bloquea todo y le prohíbe a cualquier otra persona tener acceso a los sistemas.

Puede dar todo tipo de advertencias relacionadas con la "Seguridad" sobre permitir que otras personas tengan acceso y cuentas y privilegios de root en otras máquinas, pero a menudo es una cortina de humo para alguien que quiere parecer importante y poner su basura en un vicio. Es fácil administrar el acceso de tal manera que permita el acceso pero mantenga la seguridad y la responsabilidad de un sistema.

Curiosamente, las personas hacen un mejor trabajo cuando saben que alguien más lo verá ...

Algunas respuestas excelentes hasta ahora; Me gustaría agregar:

Tener miedo al trabajo duro y / o sucio. Por supuesto, no se debe hacer todo lo posible para invitar a un trabajo duro y / o sucio, pero cuando se necesita hacer un trabajo desagradable, es una buena señal si la persona muestra la voluntad de arremangarse y meterse.

No darse cuenta de que la razón por la que hacen su trabajo es para los clientes. En definitiva, de esto se trata; la gente necesita poder venir cada mañana, iniciar sesión y obtener sus cosas. Un administrador que no tiene esto en mente está fallando en su trabajo.

Permitiéndose desconectarse de la gente. Es fácil dejarse engañar por pensar que estás en una torre de marfil, y que no necesitas tratar con usuarios o responder llamadas. Los usuarios son una fuente valiosa e importante de comentarios, y una oportunidad para saber si algo que ha implementado funciona bien o no. Organizar pasar algún tiempo cada mes trabajando con el servicio de asistencia es genial.

Ser demasiado de una persona "por el libro". De acuerdo, hay muchas formas perfectamente buenas y documentadas de hacer las cosas, por lo que esta definitivamente NO es un caso de un extremo u otro. Me refiero al tipo de persona que se aferra a sus manuales MCSE y trata todo lo que hay allí como si fuera la forma Única, Verdadera y Única.

No adoptar un enfoque proactivo. Un buen administrador siempre estará anticipando posibles fuentes de problemas y lidiando con ellos antes de que se conviertan en un problema. Un administrador malo simplemente se sentará y se alejará, dejando que las cosas se desintegran lentamente a su alrededor hasta el temido día en que algo colapsa durante las horas de oficina en un momento crítico.

Ser un evangelista tecnológico. Me refiero al tipo de persona que trataría de forzar su sistema operativo, aplicaciones o plataformas favoritas sin tener en cuenta. Usted dice que tiene SQL Server (lo que significa que es una casa de Windows), así que esté atento a alguien que constantemente ensalza las virtudes de Linux o Lotus Domino, por ejemplo.

Olvidando cubrir las cosas básicas. Es un campo bastante grande, y para ser bueno en las complejas cosas complicadas, uno necesita una base decente en lo básico. Una buena persona le preguntará casi de inmediato sobre cosas como su estrategia de copia de seguridad, su repositorio central de documentación, si tiene una imagen de PC estándar, cuándo fue la última vez que verificó el estado de su firewall, y así sucesivamente. Estas son las cosas que te mantienen en el día a día, y son tan importantes como cualquier otra cosa.

Diría que las dos cosas más importantes que debe buscar en un buen administrador de sistemas es la estructura en su trabajo y la sed de conocimiento, por lo que la ausencia de uno o ambos sería una señal de advertencia temprana.

Casi nadie podrá caminar y hacer todo el día uno, pero si tienes tiempo para que recojan las cosas, entonces no te enfoques en la falta de ninguna habilidad / experiencia en particular, si son un buen administrador de sistemas, ellos ' Investigaré las partes que no conocen a los pocos minutos de haber entrado por la puerta y se pondrán al día rápidamente.

También deberían estar interesados ​​en qué sistemas / herramientas de 'referencia / prueba' tienen: esto demostrará que quieren probar cosas nuevas sin arriesgar el entorno de producción, pueden querer DEMASIADO de este kit, pero mejor que lo quieran todo ninguno en absoluto.

Ah, y considera usar http://jobs.serverfault.com/ para encontrar a alguien bien;)

Chopper3 y damorg hacen muy buenos puntos. Además, destacaría dar tiempo al nuevo administrador del sistema para instalarse y sentirse cómodo tanto en el puesto como en la empresa. Hay un aspecto humano que debe considerarse, ya que generalmente es incómodo y los nervios son el "chico nuevo". Necesitarán tiempo para "descubrir" lo que tienes, cómo está configurado, etc., etc. y necesitarán tiempo para comenzar a sentirte cómodo con las personas y la cultura de la empresa. No se apresure a evaluar o hacer juicios sobre las habilidades o los rasgos de personalidad que ve en ellos que en realidad podrían ser el resultado de nerviosismo, etc.

Documentación de trabajo. Y algo más de documentación de trabajo.

Editar: Eso salió mal, pero entiendes la idea. Eso es lo que hace un buen administrador de sistemas, para que pueda verificar su trabajo.

Cuando ocurre un problema, ya sea en producción o en un entorno de prueba, ¿esta persona investiga la causa raíz o asume que fue un incidente único?

Dado que esta persona no tendrá todas las respuestas, ¿tiene las habilidades interpersonales y la modestia para buscar ayuda de los demás?

Como dijo @ Chopper3 , sed de conocimiento.

Los primeros signos de un mal administrador de sistemas ...

1. Duerme en la sala del servidor
2. Sale de la sala de servidores diciendo '¡Por favor, dime que tenemos buenas copias de seguridad!'

Agregaré más mientras pienso en ellos.

Me gustaría agregar algo, es un tipo de administrador. Por lo general, nivel de entrada y sin experiencia.

Los llamo mejorador de escopeta

De vez en cuando, en los ciclos de actualización, los sistemas que funcionaron se detienen y se pierden varias horas, a veces días. El mejorador de escopeta ha vuelto a atacar. Un buen administrador de sistemas debe conocer las dependencias necesarias para que su sistema de producción se ejecute y no interrumpirlo cada vez que una actualización tenga el potencial de hacerlo. Una vez atrapé uno en el acto.

Estaba en el proceso de hacer una actualización dist "desatendida" de uno de nuestros sistemas Debian. aptitude -y dist-upgrade> / dev / null 2> & 1 (Es horrible, nunca lo intentes, lo más probable es que no arranque de nuevo)

Le pregunté, ¿qué estás haciendo? Respondió redirigiendo a / dev / null, ¡obstruye la pantalla!

Como lo mencionó Chopper3, la evidencia de un enfoque estructurado y disciplinado y la voluntad de aprender son buenas señales.

Por otro lado, los primeros signos de un mal conjunto de habilidades o "ajuste" pueden incluir falta de paciencia con las preguntas, falta de voluntad para explicar el razonamiento técnico, defensa constante y agresiva, señalamientos interminables a colegas y / o antecesores (si hay mérito) a esto, no hay razón para azotarlo hasta la muerte una y otra vez).

Además, un deseo de "arrancarlo todo" o rehacer todo "de la manera correcta" son tendencias a observar.

Una cierta cantidad de "bien lo habría hecho de esta manera" puede ser natural, pero a menos que también haya una evaluación del entorno actual y sus debilidades, y un plan razonable para corregir esos problemas y cumplir con cualquier otro requisito que pueda existir, y mucha discusión, sería cauteloso.

Ya ha habido algunas respuestas excelentes, por lo que no repetiré ninguna de ellas, pero agregaré que si bien esto no necesariamente indicará un mal administrador del sistema, se puede esperar que alguien que trabaja para el maní se sienta insatisfecho, o al menos muy rápidamente. con el trabajo Esa persona inevitablemente estará pensando tanto en el próximo trabajo y en cómo conseguirlo, como el que tiene actualmente. ¿Puede esperar de manera realista que alguien lo dé todo en tal circunstancia? Con eso en mente, asegúrese de que la documentación esté a la altura.

Me parece que su instinto ya le ha dicho que ha hecho una mala contratación y está buscando evidencia para reforzar ese instinto.

Aquí hay algunos malos hábitos de SQL Server. En mi humilde opinión, puede ser un signo de un DBA sin experiencia.

• reiniciar el servidor o reiniciar el servicio del servidor sql para 'solucionar' problemas
• agregar archivos de registro de transacciones adicionales en diferentes unidades, porque el registro actual se está quedando sin espacio en disco
• reducir el registro de transacciones es una parte regular del mantenimiento para controlar el tamaño del registro (eludir los archivos de datos es aún peor)
• usando la opción de mesa abierta en SSMS (puntos de bonificación triples por usar contra producción)
• ser completamente dependiente de la GUI de SSMS para realizar copias de seguridad y restaurar
• no comprende la diferencia entre un inicio de sesión del servidor sql y un usuario del servidor sql

Incapacidad para priorizar, y multitarea.

Gestión del tiempo.

Programa actividades alrededor de un plan de trabajo. Sabe que el mantenimiento debe realizarse en el tiempo de inactividad. Gestiona copias de seguridad. Pruebas de copias de seguridad / restauración. Tiene un plan de recuperación activo, no se trata de si, sino cuándo fallará el hardware. Deben estar interesados ​​en saber si las cosas se rompen o se salen de control antes de que lo note. Piensa que nagios o viento solar es imprescindible para saber si los sistemas están vivos o muertos.

Documentación.

Debería funcionar con un sistema de tickets. Coloca tickets en nombre de usuarios que no pueden hacerlo para rastrear problemas.

Actitud.

Totalmente abierto para ayudar al negocio. No hay no se puede abrir. Dice que puedo hacer esto si me das estos recursos.

Mira las preguntas que hacen. Parece que tienes un sistema bastante complejo (multitud de servidores SQL), así que si fuera yo, lo primero que estaría haciendo es molestar a cualquiera y a todos los que me hablarán sobre lo que hacen, quién depende de ellos y por qué y tomando abundantes notas. Estaría haciendo esto lo más cerca posible de una pizarra blanca.

Se debe intentar encontrar y probar las copias de seguridad. Si hay problemas de rendimiento, estaría ejecutando el perfilador y perfmon (o herramientas similares) para tratar de averiguar qué consultas los están causando. Estaría revisando el hardware para asegurarme de que las multitudes de servidores SQL tengan al menos un espejo de hardware cada uno.

Comprobando que hay algún tipo de sistema de monitoreo e implementando uno si no lo hay. Nagios y cacti / rrdtool / mrtg vienen a la mente.

Sobre todo, si ve que alguien comienza a tomar medidas para cambiar sus servidores SQL reales (con la excepción de la medición) antes de que tengan una comprensión profunda ... bueno, esto es más inexperiencia que falta de habilidad, pero me asustaría.

Habrá algunos dolores de crecimiento, al igual que los frenillos son dolorosos pero gradualmente tiran de los dientes en una alineación buena y correcta. El administrador deberá instalarse y luego habrá algunos ajustes a medida que alinee las cosas correctamente.

La mayor señal de un administrador bueno o malo es cómo ocurren los cambios. ¿Involucra a los usuarios en la discusión sobre QUÉ y POR QUÉ las cosas deben cambiar? ¿Hay alguna razón por la que quiera bloquear a ciertas personas de un sistema en particular? Como cualquier cosa en un negocio, tiene que tener una razón y un vaporoso "por seguridad" no es suficiente. ¿Cuáles son los riesgos de dejarlo como está? ¿Por qué es lo que quiere hacer mejor?

Si los usuarios se sienten involucrados en el proceso y tienen la oportunidad de explicar por qué las cosas son como son y pueden explorar las alternativas, estarán mucho más dispuestos a ayudar y pueden ofrecer ideas como razones históricas para cosas extrañas en el sistema. Me encuentro a menudo consultando con algunas de nuestras personas de finanzas que han estado en mi empresa durante décadas sobre por qué diablos es algo tan extraño.

En realidad, esto se aplica a cualquier posición, incluso fuera de TI.