7.8 KiB
Pregunta 1 (Castellano)
Dentro del marco ITIL, define de forma clara y diferenciada los procesos de Gestión de Incidencias, Gestión de Cambios y Gestión de la Configuración (CMDB). Pon un ejemplo práctico de cómo interactuarían estos tres procesos si un servidor crítico de base de datos sufre una avería de hardware y necesita ser reemplazado.
Respuesta
Esta la voy a responder a ciegas completamente a ver qué sale. La Gestión de Incidencias es la gestión para levantar un servicio lo antes posible ante un parón o interrupción no esperado, a modo de Parche, para la continuidad del servicio; la Gestión de Cambios es el análisis para averiguar las necesidades de cambios que pueda haber en un sistema, ya sea por actualizaciones, cambios de Software o Hardware, etc. Así como analizar su compatibilidad con el ecosistema actual donde se va a integrar; y finalmente, la Gestión de Configuración es la Gestión cara la integración del nuevo componente, ya sea Hardware, Software o ambos a la vez como es el caso de un componente físico con sus Drivers o Software para poder interactuar con éste.
En caso de avería en el Hardware, la Gestión de Incidencias intentará mantener la continuidad del servicio con los medios que tiene presente aunque sea limitando la capacidad de trabajo para los mismos mientras no se llega a una solución; se ha de comprobar la disponibilidad del Hardware de reemplazo, ya sea por otra pieza igual o alternativa que sea compatible con la infraestructura y econsistema actual, tanto en tiempo de adquisición como en las capacidades económicas para adquirirlo, incluyendo si hiciera falta el contrato de un servicio para implementarlo y mantenerlo, o en caso de haberlo ya, hacer uso de dicho recurso para implementar una solución definitiva al problema, sincronizando con el equipo o equipos de trabajo que gestionan o hacen uso de éstos, lo que vendría siendo la Gestión de Cambios; y finalmente, la implementación, instalación y adaptación del nuevo Hardware en la infraestructura y econsistema por parte de la Gestión de Configuración para que el componente funcione acorde al resto y a lo esperado para el mismo.
Corrección
Nota: 6/10
La intuición te ha funcionado muy bien para las dos primeras partes, pero has caído en la trampa clásica de la tercera.
- Aciertos: Has clavado la Gestión de Incidencias. Su objetivo en ITIL es exactamente ese: restaurar el servicio lo antes posible, aunque sea con un parche temporal (workaround). La Gestión de Cambios también la has enfocado bien: es el proceso de evaluar, autorizar y documentar cualquier modificación en la infraestructura minimizando riesgos.
- El error (Gestión de la Configuración): En ITIL, esto no significa "configurar el aparato". Se refiere a la CMDB (Configuration Management Database). Es mantener una base de datos actualizada con todos los elementos de la empresa (CIs - Configuration Items) y sus relaciones.
- El ejemplo corregido para un 10:
- Incidencia: El servidor cae. Se intenta reiniciar o levantar un backup rápido para dar servicio.
- Cambio: Como el hardware está frito, se abre un "Petición de Cambio" (RFC) para comprar e instalar uno nuevo, evaluando el impacto de la parada.
- Configuración: Una vez instalado, se actualiza la CMDB para dar de baja el servidor viejo, registrar el nuevo (IP, modelo, licencias) y vincularlo lógicamente a la "Base de Datos de Producción".
Pregunta 2 (Galego)
No eido do soporte informático, as ferramentas de ticketing son o motor do departamento. Describe as características principais e as diferenzas de enfoque entre dúas das ferramentas de código aberto máis coñecidas: GLPI e OTRS. Cal consideras que ten unha mellor integración nativa para o inventario de activos (Xestión da Configuración)?
Respuesta
Eu manexo GLPi no traballo e podo falar por experiencia dentro deste, mentres que de OTRS só polo que vexo na Web. A nivel de GUI, ámbolos dous son moi similares, aínda que parece máis extendido GLPi. GLPi ten un sistema de configuración moi complexo e profundo incluso con marcas de texto nas contornas de configuración que deixan profundizar enormemente ate onde se quere chegar, e cun sistema de usuarios cun sistema de permisos integrado complexo cunha infraestructura por defecto que permite xestionar Incidencias, Problemas, Inventarios, etc. Quizais, a súa complexidade da lugar a ter problemas de mantemento ou xestión fronte a un entorno aparentemente máis limpo e sinxelo que OTRS, o que vexo máis orientado a resolución de problemas e incidencias directas que GLPi. Polo tanto, cara a resposta diría que GLPi é máis axeitado para Inventario de Activos que OTRS polo meu coñecemento de GLPi e o que atopo de primeiras en Internet de OTRS.
Corrección
Nota: 8.5/10
Aquí notouse moitísimo a túa vantaxe práctica na trincheira. O teu razoamento é practicamente perfecto para un exame oficial.
- Aciertos: Diches no cravo coa Xestión da Configuración/Inventario. GLPI naceu precisamente cun enfoque brutal cara ao inventario de activos (ITAM) e intégrase de forma nativa con axentes como OCS Inventory ou FusionInventory/GLPI Agent. É a súa gran fortaleza.
- Sobre OTRS: Tamén acertaches o seu enfoque. OTRS (Open Ticket Request System) é un sistema de ticketing puro e moi robusto, orientado a fluxos de traballo de atención ao cliente e resolución. Ten módulo ITSM para inventario, pero o seu núcleo é a comunicación, mentres que o núcleo de GLPI adoita ser o parque informático.
- Pequeno detalle para o 10: Mencionar os axentes de recollida de datos (como o GLPI Agent) que automatizan esa CMDB daríache a máxima puntuación.
Pregunta 3 (Castellano)
Analiza el área de monitorización de sistemas comparando Nagios y Zabbix. Describe brevemente la arquitectura básica de ambos y explica las diferencias clave en su forma de recopilar métricas (por ejemplo, el uso de agentes, chequeos activos vs. pasivos) y en la configuración de sus umbrales de alerta.
Respuesta
Nagios requiere de agentes, mientras que Zabbix es Agentless pero requiere de configurar un túnel SSH para que pueda interactuar con la máquina, haciendo que Nagios sea pasivo, o de escucha, y Zabbix sea activo e interactúa directamente con cada una de las máquinas que estén dentro del sistema de monitoreo. Con respecto a sus umbrales de alerta pues la verdad que ando bastante pez y con lo que me costó intentar poner en marcha un Zabbix por ser un Open Source accesible, ni me paro a ver el resto de factores. Estos casos dan una perspectiva de la importancia de un SaaS, pero claro, tiene la contra de descontrol o requerir sincronía que elimina recursos para una gestión adecuada.
Corrección
Nota: 3/10
Aquí la intuición te jugó una mala pasada, pero es normal si no has peleado directamente con ambos en profundidad. ¡Zabbix puede ser un dolor de cabeza al principio! Vamos a aclarar los conceptos para que no se te escapen la próxima vez:
- El uso de agentes: ¡Cuidado! Ambos pueden usar agentes y ambos pueden ser agentless (vía SNMP, SSH, ping). Zabbix es famosísimo precisamente por su potente "Zabbix Agent". Nagios suele usar agentes como NRPE o NCPA.
- Activo vs Pasivo: El concepto clave aquí es quién inicia la comunicación.
- Chequeo Activo: El servidor (Nagios/Zabbix) le pregunta a la máquina: "Oye, ¿cómo está tu CPU?".
- Chequeo Pasivo: El agente en la máquina le manda los datos al servidor sin que este pregunte. El agente activo de Zabbix es excelente para esto (ideal para saltar firewalls).
- Umbrales: Nagios es más estático (configuras un umbral de Warning al 80% y Critical al 90%). Zabbix es infinitamente más complejo; utiliza "Triggers" (disparadores) que evalúan expresiones matemáticas basadas en el historial de datos (ej: "si la media de la CPU en los últimos 5 minutos es > 90%").