¿Hay algún antipatrón bien conocido en el campo de la administración del sistema? [cerrado]

Conozco algunos patrones comunes que parecen perjudicar a casi todos los proyectos en algún momento de su ciclo de vida:

1. Incapacidad para tomar interrupciones
2. Componentes de terceros que bloquean las actualizaciones
3. Ambientes no uniformes
4. Falta de monitoreo y alerta
5. Falta redundancia
6. Falta de capacidad
7. Mala gestión del cambio
8. Políticas demasiado liberales o de acceso limitado
9. Los cambios organizacionales afectan negativamente la propiedad de la infraestructura

Esperaba que haya una biblioteca bien articulada de estos antipatrones resumida en un libro o sitio web. Estoy casi seguro de que muchas organizaciones están aprendiendo a través de la prueba por métodos de fuego. Si no, comencemos uno.

Dejar que las tareas automatizables se automaticen hasta que se realicen manualmente lleva suficiente tiempo como para que no se puedan automatizar, porque realizar las tareas manualmente se come todo el tiempo.

Por el contrario, la automatización prematura. No hay absolutamente ninguna necesidad de pasar 3N horas automatizando una tarea de una sola toma que lleva N horas realizarla manualmente (incluso si es más divertido automatizar que trabajar a mano).

A. no prueba la restauración: una copia de seguridad se puede verificar y aceptar, pero ¿cómo restaurarla?

¿Cuánto se tarda, lo que se necesita? Tienes que saber hacer eso en una situación estresada ...

B. sin gestión de configuración, sin uniformidad, solo un cambio aquí y allá y creo que he ajustado algunos aquí ...

¿Quién sabe cómo replicar un servidor bien hecho si todas las peculiaridades no están escritas y no hay configuraciones idénticas en la tienda? ¿Qué sucede si logra restaurar las aplicaciones, pero no la configuración?

C. sin monitoreo - sin tener idea de cómo y qué están haciendo las cajas

Esto es doble: a) debe monitorear las alarmas para reaccionar a tiempo antes de quedarse sin recursos o comportamientos extraños yb) debe monitorear la tendencia a largo plazo para administrar la capacidad (disco, CPU, RAM, red, etc.). ..).

D. no hay redundancia en tu cfg: ¿qué sucede cuando XX muere?

Esto significa planificar con anticipación lo que desea de su administrador de sistemas.

Para mí estos son los más importantes.

El patrón más mortal es cuando el departamento de administración del sistema (o todo el departamento de TI) se convierte en un participante pasivo en la empresa. Es decir, son vistos como un autoservicio en el que todos vienen con ideas ya formadas de cómo se deben hacer las cosas, lo que toma en consideración exclusivamente las necesidades del usuario y no las necesidades del ecosistema de TI completo en su conjunto.

El segundo patrón más asesino es cuando el departamento de administración del sistema se convierte en un grupo de botones, es decir, todo el software / herramientas son comprados o desarrollados e instalados por un tercero y la administración del sistema obtiene una capacitación oficial y un manual y luego solo sigue los manuales operativos y escalar al vendedor todo lo que no está explícitamente en el manual. Esta situación puede ser muy cómoda para (algunos, si no la mayoría) de los administradores del sistema, pero esto es un desastre a la espera de que suceda cuando el hecho de que nadie sepa realmente cómo funciona realmente todo el sistema lo llevará a la realidad (piense en las interacciones sutiles entre los componentes y El juego de la culpa entre los vendedores).

1) demasiado prometedor y bajo rendimiento (es decir, mantener realistas las expectativas de los usuarios)

2) No verificar las copias de seguridad hasta que sean necesarias.

editar: pretendía que el número 2 incluyera la restauración de archivos / datos

No supervisa los patrones de uso de la cuenta de AD, como el último tiempo de inicio de sesión> 30 días

(Tenemos que hacer esto por razones de auditoría, pero los resultados son bastante impactantes)

• Mantener información clave en la cabeza / bandeja de entrada / carpeta de documentos de una persona. Si es importante, como los detalles de contacto del proveedor, las claves de licencia, las instrucciones de configuración, debe estar disponible para todos en el departamento que tengan autoridad y puedan necesitar acceder a él, y en un lugar estándar.

• Pídale a la persona que sabe algo que lo documente. Esto suena bien porque son la persona que tiene el conocimiento, pero en realidad es malo porque no pueden decir fácilmente cuál es el conocimiento importante. Es mejor tener a alguien nuevo con él, preguntándole a la persona conocedora cualquier información que necesite y haciéndola documentar mientras lo hace.

• Documentación poco clara. Cualquiera puede solucionar un problema de prioridad media durante el día con todo el departamento de TI disponible para hablar. Otra cuestión es solucionar un problema de alta prioridad a altas horas de la noche cuando está casi solo y no tiene idea de por qué el sistema está configurado como está o por qué no coincide con lo que dice la documentación.

• No rastrea bien las contraseñas. Entonces, rápidamente necesita una cuenta, crear una con una contraseña aleatoria y luego, 18 meses después, todavía está en uso y nadie sabe la contraseña o qué servicios se romperán si se cambia.

• No comprar soporte de proveedores para sistemas clave porque es "demasiado caro".

• Prioridades inapropiadas El personal de TI debe guiarse por la administración: debe establecerse un acuerdo sobre qué proyectos son prioritarios o, en caso de emergencia, qué sistemas se requieren primero. Si TI está tratando de arreglar el sistema comercial, la administración exige un correo electrónico y los usuarios exigen que el procesamiento de pedidos sea una receta para un desastre.

• Soluciones inadecuadas: es muy fácil para TI quedarse atascado en la mentalidad de "solucionarlo, el sistema de TI debe estar funcionando como antes", cuando puede ser más apropiado tener un acuerdo de gestión de TI para "intentarlo por 2 horas, si no está arreglado, deténgase incluso si parece prometedor y continúe para recuperarse de una copia de seguridad ".

• Copias de archivos de prueba en todas partes. No desea abrir una carpeta que ejecute un sistema comercial o sitio web y ver "sitio web nuevo / sitio web actual / copia sitio web / prueba web / sitio web prueba-dave / uso-sitio web- this-one /, website-from-feb /, etc.) El desarrollo, la producción y las pruebas deben existir y deben separarse con cada departamento involucrado (TI, desarrollo, gestión de proyectos, etc.) sabiendo qué debe estar dónde y acordado cómo los cambios están aprobados. También para archivos de configuración.

• Cambie la aprobación: incluso si primero tiene una discusión verbal, no cambie la forma en que funcionan las cosas importantes sin que nadie más lo sepa. Depende de usted decidir qué cubre "importante" para su situación.

• Soluciones con cuerpo dejadas en su lugar a largo plazo. Sé que conectó este servidor a esa red con un cable telefónico antiguo rápidamente para poder solucionar un problema urgente. Sé que no tienes tiempo para rehacerlo correctamente. Haz el tiempo

• Mala relación con el resto de la empresa. TI es un servicio que ayuda al resto de la empresa a hacer su trabajo. Si necesitan archivos enormes rápidamente, haz que suceda. Si necesita aprobación administrativa para comprar hardware, consígalo. Si no puede obtenerlo, comunique claramente que los archivos enormes no pueden moverse rápidamente porque la administración ha priorizado otros gastos. Si necesita archivar por razones legales pero no tiene un presupuesto, entonces debe ajustar el archivado en su sistema lo mejor que pueda.