software de base. Funciones y responsabilidades. Control de cambios de los programas de una instalación. Sistemas y comunicaciones
Guión-resumen
1. Introducción 3. Funciones y responsabilidades
2. Administración del Sistema 3.1. Rutinarias Operativo y “software” de base 3.2. Incidencias 3.3. Herramientas y protocolos 4. Control de cambios de los programas de una instalación
1-2 Administración del Sistema operativo y software de base
1. Introducción La administración de sistemas puede definirse como el conjunto de actividades orientadas a configurar y gestionar un conjunto de equipos informáticos en su aspecto físico y lógico.
La administración de un sistema de información comprende también tareas como la
elaboración de documentación o el establecimiento de procedimientos. Por tanto, desde el punto de vista de la organización, se requiere autoridad y responsabilidad y desde el punto de vista del usuario, servicio y cooperación.
El SO es el “software” que sirve de interfaz entre el usuario y la máquina. El “softwa-
re” base es el conjunto de programas que controlan e interactúan con el SO, ofreciendo control sobre el “hardware” y soporte a otros programas.
Mucho “software” base está incluido en el SO. Por tanto, suelen usarse casi como sinónimos los términos “software” de base o “software” de sistema, y entenderse por ello, estos programas y el sistema operativo.
Ejemplos de “software” base serían los demonios que controlan la temperatura de la
CPU o las bibliotecas del sistema gráfico. Lo suyo sería hablar de dos tipos de “software” según el criterio del administrador: “software” de sistema y de aplicación. El primero sería el que se acaba de definir y el segundo, el dirigido al usuario.
La generalidad de acciones de la administración del “software” base consiste en la ges-
tión de usuarios, el control del rendimiento del sistema, copias de seguridad, adición de “hardware”, instalación o actualización de “sw”, monitorización del sistema, entre otras.
La dificultad reina en la administración del “software” de sistema es la diversidad de
plataformas tecnológicas, que suelen agruparse en entornos WS y Unix y la distribución de sistemas. Por tanto, la administración tiende a centralizar su actividad, para ganar en homogeneidad, estandarización y control.
Otra actividad destacable es la gestión de incidencias y cambios. Su registro y solu-
ción. Y las herramientas y métodos que se disponen para la tarea.
Por fin, por su tendencia a la centralización, la administración del “sw” de sistema ya
oculta otra idea, la administración remota, que difumina la frontera entre la administración de “sw” de sistema y la gestión de redes y el “sw” de red, para lo que se dispone y muchas veces se integran herramientas de gestión y administración.
2. Administración del Sistema Operativo y “software” de base
La administración del “sw” de sistema (SO y “sw” base) la realiza una persona que se da en llamar administrador del sistema, precisamente por administrar el “sw” de sistema.
Por tanto, configura y gestiona el sistema, y en muchas ocasiones lo rea-
liza compatibilizando esta tarea con otras. Lo ideal es dedicación exclusiva a tareas de administración.
1-3 Sistemas y comunicaciones
De un administrador se exigen amplios conocimientos del sistema administrado,
capacidad de toma de decisiones, filosofía de mejora continua, eficacia y responsabilidad. Como se introdujo, las acciones de la administración del “sw” de sistema incluye la ges- tión de usuarios, el control del rendimiento del sistema, copias de seguridad, adición de “hard- ware”, instalación o actualización de “sw”, monitorización del sistema, entre otras tareas. Para realizarlas, el administrador debe seguir una estrategia. De forma similar al ciclo de mejora de calidad de Demming, podría identificarse esta estrategia como PDCA, es decir, planificar, hacer, verificar y mejorar. Lo peligroso, quizá es “hacer”. Es recomendable, tener la posibilidad de hacer una tarea o cambio reversible, contando con copias de seguridad o mecanismos similares. Del mismo modo interesa hacer cambios pequeños e incrementales, probándose en caso que se pudiera. Para las pruebas, es conveniente contar con un entorno de preproducción o maqueta. Un entorno de prueba. Una vez verificados los cambios, se aplicarían y se monitorizan, auditan y analizan para seguir buscando mejoras y anticipación a problemas. Se ha definido la acción de la administración de “sw” de sistema. El sujeto, el admi- nistrador. Su estrategia. Y queda por tanto presentar su relación con la máquina: su perfil en el sistema. Al perfil de usuario del administrador, se le suele denominar también administrador o superusuario. Más original no podría ser la terminología. Este perfil posee todos los privilegios sobre el sistema. Esto implica control sobre todo archivo y comando de sistema. En entornos Unix también se conoce como ‘root’ y se aso- cia al grupo ‘root’. En entornos WS se conoce como Administrador o Administrador de Dominio y se asocia al grupo administradores. En los entornos Unix, la herramienta sudo (hacer del superusuario, en inglés) permi- te a otros usuarios ejecutar comandos con el perfil del administrador. La configuración de esta funcionalidad se hace en el fichero /etc/sudoers y al ejecutar un comando en la forma sudo se pedirá contraseña de administrador. Esto es debido a que no debe usarse una cuen- ta privilegiada para acciones rutinarias, por lo que sudo, es una opción ágil. La administración del “sw” de sistema puede identificar dentro del conjunto de sus tare- as, las que son más rutinarias, o planificadas, que se exponen en el siguiente punto, y tareas aleatorias, que se pueden englobar en lo que se conoce como gestión de incidencias. La gestión de incidencias es el proceso tendente a minimizar el impacto de un hecho que se materializa sobre el sistema y afecta a su funcionalidad. Así, las incidencias son situaciones anormales en el funcionamiento del sistema. Podría decirse también, de forma irónica, que son más normales que anor- males, por su frecuencia, pero ese es otro debate. Ejemplos de incidencias son la pérdida de conexión de red de un usuario, su imposibilidad para imprimir o la pérdida u olvido de una contraseña.
1-4 Administración del Sistema operativo y software de base
Por su “normalidad”, a veces, la gestión de incidencias, o el “soporte informático” se
externaliza por parte de una organización y esto obliga a establecer unos acuerdos con- tractuales para definir responsabilidades y niveles de atención.
A este contrato o acuerdo se le llama SLA acrónimo inglés de Service Layer Agreement o acuerdo de nivel de servicio. Si el SLA se da entre departamentos de una misma organi- zación, como en un grupo de empresas, puede recibir otros nombres similares.
El SLA debe recoger los objetivos a los que se compromete la función informática mediante indicadores concretos, como el tanto por ciento de disponibilidad, tiempo y hora- rio de respuesta, tiempo medio entre fallos (MTBF), número de incidencias pendientes, etc. También se incluyen las responsabilidades y penalidades en caso de incumplimiento.
3. Funciones y responsabilidades Las funciones y responsabilidades rutinarias en la administración de “sw” de sistema poseen un carácter local, en cuanto que administración de una máquina concreta y otro glo- bal, en lo que se refiere al “sw” de sistema del entorno de red. La tendencia es la integración de esos dos aspectos. Y se suele concretar en utilidades y herramientas con un único interfaz.
3.1. Rutinarias Entre las funciones y responsabilidades rutinarias de la administración del “sw” de sis- tema pueden identificarse las que se exponen a continuación.
3.1.1. Inventario Una correcta gestión del “sw” de sistema comienza con un inventario de los recursos “hw” y “sw” de la organización. De especial interés será el caso de externalización, cuando habrá que reflejarlo en el SLA correspondiente. El nivel de detalle variará en función de las necesidades, aunque al menos deben incluirse elementos “hw”, “sw” y de red.
Los elementos “hw” incluirán equipos y su configuración. Los “sw” incluirán aplica- ciones y componentes “sw” usados en cada equipo en su respectiva versión. Los recursos de red incluirán los mapas y grupos de trabajo conectados.
La elaboración de los inventarios se puede realizar con herramientas automáticas que
exploran los equipos extrayendo la información requerida. La instalación de nuevos compo- nentes es habitual, por tanto, junto a cada actualización, se debe actualizar el inventario.
3.1.2. Distribución de “sw” y control de licencias. Antivirus
La distribución de “sw” suele automatizarse con herramientas integradas, en general, con soporte para varios tipos de entornos y redes, registro de ope- raciones y actualización de inventario.
1-5 Sistemas y comunicaciones
En caso “sw” comercial deben controlarse las licencias “sw” para no incurrir en pro- blemas legales. La gestión de licencias en equipos locales, puede ser más sencillo, pero en sistemas distribuidos el control debe verificar que el número de ejecuciones simultáneas no supere el número de licencias autorizadas.
Como ayuda para el control de licencias se pueden usar herramientas de inventario
que indiquen cuántas instalaciones de cada aplicación existen en los equipos. También son útiles herramientas específicas de control de licencias, que ofrecen la posibilidad de blo- quear la ejecución si se sobrepasan las condiciones del contrato. Otras posibilidades son la reubicación de licencias entre servidores, gestión de colas de usuarios para licencia, libera- ción de licencias no usadas, etc. El uso de estas herramientas reduce los costes de adquisi- ción de licencias y evita los problemas legales.
Estos aspectos, por su constante actualización son de especial cuidado en lo referente
al “sw” antivirus. La actualización y distribución de antivirus se suele hacer en entornos de Internet. Por ello, la organización establecerá si se usan antivirus en local, en servidor o en ambos.
3.1.3. Contabilidad Se entiende por contabilidad la obtención de datos y estadísticas de uso de los siste- mas como puedan ser el tiempo de conexión de usuario, uso de cuotas de almacena- miento, tiempos de acceso, carga de procesador y de red, o datos del estilo, considerados de interés. El análisis de la información permitirá dimensionar los sistemas, ajustándolos a las necesidades reales.
3.1.4. Gestión de sistemas y comunicaciones
La gestión de sistemas se basa en su monitorización para el control de la operativa. Su acción clave es establecer las condiciones umbral que marcan la normalidad del funciona- miento. Superados los umbrales se podría identificar alguna anomalía que diera origen a un análisis de la situación. La situación anómala, se podrá tratar como incidencia, que será tratada según los procesos documentados (los procedimientos) de la organización.
Las herramientas gráficas de mapas de red ofrecen una visión panorámica de la topo- logía de red que facilitan a los administradores información valiosa para la gestión de la red, en particular para identificar rápidamente anomalías que puedan suponer problemas.
La administración de sistemas y comunicaciones genera su integración natural. Y a la
vez surge la facilidad de la administración remota. Las herramientas que permiten control remoto de los sistemas permiten la centralización de la gestión, con el incremento de pro- ductividad que supone. Se engloban en lo que se conoce como RAT (Remote Administra- tion Tool) y el ejemplo paradigmático es VNC (Virtual Network Computing) de AT&T Laboratories Cambridge, de libre distribución o la propietaria PCAnywhere de Symantec.
1-6 Administración del Sistema operativo y software de base
3.1.5. Otras funciones
Otras actividades relacionadas con la administración del “sw” de sistema, que por su extensión, no se desarrollan aquí, son la gestión de colas de impresión e impresoras, del almacenamiento, la planificación de copias de seguridad (backups o respaldos) o la gestión de cuentas de usuarios, por citar las más inmediatas. Algunas de estas tareas se exponen en los temas de administración de redes de área local.
3.2. Incidencias Cuando se dan situaciones anómalas, no necesariamente de gravedad, la administra- ción de “sw” de sistemas, el administrador, realiza funciones y adquiere responsabilidades en relación a la situación planteada.
El punto de partida de estas funciones y responsabilidades hay que buscarlo en el SLA, el
acuerdo del nivel de servicio, que puede ser interno o, como se ha comentado, responder a un contrato entre organizaciones. Las funciones que se suelen identificar, entre otras son:
— Resolución de incidencias y cambios con seguimiento trazado de principio a fin.
— Informar a usuarios y entidades que se establezcan de las acciones sobre el siste- ma. — Informar a la dirección sobre situaciones excepcionales o de especial gravedad. — Analizar el grado de satisfacción del usuario y la calidad del servicio percibida. — Estandarización y centralización de los procedimientos de gestión. Además de las métricas de seguimiento es interesante obtener una valoración del usuario sobre la percepción de la calidad del servicio mediante una “encuesta de satisfac- ción de usuarios” (CSS, Customer Satisfaction Survey). El análisis del resultado contribui- rá a la mejora del servicio.
Para el tratamiento de incidencias, se hace necesario centralizar las operaciones y per-
sonal, de forma que la categorización de las incidencias asigne el personal indicado al pro- blema concreto. La categorización de incidencias consiste en su clasificación por criterio de gravedad, de forma que la respuesta sea lo más eficiente posible. Una categorización típi- ca, de menor a mayor grado de gravedad puede ser la siguiente.
— Categoría 4. Incidencias rutinarias o que en un futuro podrían ocasionar proble-
mas. — Categoría 3. Incidencias de fácil solución. En el peor caso afectarían a pocos usuarios. — Categoría 2. Incidencias de riesgo grave predecible. En caso de pro- ducirse llevan asociado un largo proceso de recuperación o podrían detener un sistema o aplicación.
1-7 Sistemas y comunicaciones
— Categoría 1. Incidencias urgentes. Problema complejo que paraliza la operación
y afecta a muchos usuarios. La situación puede no tener vuelta atrás o proceder de la combinación o evolución de incidencias de categorías inferiores. — Categoría 0. Incidencias de emergencia. Situación grave que paraliza todo el servicio. La gestión de incidencias puede automatizarse con herramientas especializadas. Éstas permitirán la apertura de incidencias, seguimiento y solución, entre otras funcionalidades. Cada incidencia se identifica con un código o, en el argot, tique. Son herramientas comu- nes en los departamentos de atención al cliente y soporte técnico (help desk). Se pueden clasificar en:
— Control de llamadas. Son las más básicas. Permiten abrir, gestionar y cerrar inci- dencias y la posibilidad de elaborar estadísticas e informes. — Gestión de problemas. Disponen de una BBDD de configuración, incidencias y cambios. Permiten realizar inventarios y responder a una escala de problemas con control de flujo. — Herramientas integradas. Son las más completas y costosas. Integran gestión de configuración e incluyen sistemas basados en el conocimiento. Estos sistemas asesoran en la resolución de incidencias analizando incidencias previas resueltas. Entre las empresas que desarrollan herramientas de incidencias y cambios destacan Remedy (herramienta ARS), Artistry, Astea, Applix y Platinum.
3.3. Herramientas y protocolos
Es difícil encontrar un “sw” que integre el soporte a todas las funciones y responsabi- lidades expuestas. Esto obliga a los administradores a manejar distintas herramientas. Sin embargo, existen plataformas de gestión muy adaptadas, que presentan características comunes, como son el interfaz gráfico de usuario, protocolos estándar de monitorización y gestión remota de dispositivos, soporte para BBDD o interfaces de programación de apli- caciones (API).
Es conveniente que la plataforma soporte varios protocolos. La arquitectura de gestión
suele ser cliente servidor. El dispositivo monta un servidor (llamado agente), que respon- de con su información a la parte cliente de la estación gestora. El servidor del dispositivo, el agente puede enviar alarmas en función de la configuración de sus umbrales. Los pro- tocolos típicos de gestión suelen ser SNMP o CMIP.
Las plataformas permiten incrementar su funcionalidad con aplicaciones de terceros
para gestionar “sw” de base o dispositivos propios. En general son más potentes en entor- nos Unix. De las propietarias más conocidas destacan HP Openview, Spectrum de Cable- tron Systems, Tivoli de IBM, LMS (Landesk Management Suite, de Intel), SMS (Systems Management Server, de Microsoft), SunNet Manager (Sun) o Unicenter de Computer Associates. Entre las plataformas libres citar Scotty/Tkined, OpenNMS y gxsnmp.
1-8 Administración del Sistema operativo y software de base
Los protocolos de gestión establecen las normas de comunicación entre agentes y
estaciones de gestión. Hay que conocer los siguientes:
— SNMP (Simple Network Management Protocol). Es un protocolo simple, cons-
tituido como estándar. Sus archivos de BBDD se denominan MIBs (Manage- ment Information Base). — CMIP (Common Management Information Protocol). Cuando en 1987 se plan- teó el desarrollo de protocolos para gestión de red se propuso SNMP como solu- ción a corto plazo y CMIP como solución a largo. CMIP, es más formal y poten- te que SNMP, aunque menos usado. La implementación de CMIP sobre TCP/IP se llama CMOT y su adaptación sobre LLC, CMOL. — DMI (Desktop Management Interface). Está definido por un consorcio llamado Desktop Management Task Force. El objetivo es definir una arquitectura abierta para gestión de equipos y “sw”. Usa archivos de interfaz de gestión (MIF, Mana- gement Information Format) para especificar las características de los productos. Es compatible con Plug and Play para configuración de sus archivos de BBDD y con SNMP. Por su importancia, deben conocerse algunos aspectos de SNMP. El entorno de ges- tión SNMP está formado por procesos agente (en dispositivos) y procesos gestores (en estaciones de gestión) que se comunican con SNMP. Los agentes recopilan información del dispositivo de red en que se ejecuta, creando una estructura jerárquica de información lla- mada MIB.
Las estaciones de gestión acceden a las MIB con operaciones de lectura y escritura. Los agentes pueden enviar alertas (mensajes trap) a las estaciones de gestión para notificar inci- dencias.
SNMP usa los puertos 161 y 162 UDP para recibir los trap. Una comunidad SNMP (SNMP community) es un grupo formado por dispositivos y las estaciones que los gestio- nan. Se usa un nombre de comunidad para identificar cada grupo y asociar las operacio- nes soportadas por los agentes. Los dispositivos pueden pertenecer a una o varias comu- nidades, pero no responderán a estaciones de otra comunidad a la que no pertenezcan. Las comunidades SNMP son cadenas de texto que suelen usarse a modo de claves de auten- tificación. Es habitual usar las comunidades predeterminadas “public” (lectura) o “private” (escritura).
Existen 3 versiones de SNMP: SNMPv1 fue la primera versión, SNMPv2 es la más usada y SNMPv3 se espera que sea el futuro estándar. Los puestos de trabajo también pueden monitorizarse con SNMP. A continuación se muestra un ejemplo de listado de una MIB:
SNMPv2-MIB::sysDescr.0 = STRING: “hardware”: x86 Family 6 Model 9 Stepping 5
AT/AT COMPATIBLE - “software”: Windows 2000 v 5.1 (Build 2600
IF-MIB::ifDescr.1 = STRING: MS TCP Loopback interface
IF-MIB::ifDescr.2 = STRING: Intel(R) PRO/Wireless LAN 2100 3B Mini PCI Adapter
IF-MIB::ifDescr.3 = STRING: NIC Fast Ethernet PCI Familia RTL8139 de Realtek
[…]
IF-MIB::ifPhysAddress.2 = STRING: 0:4:23:66:ee:ad
IF-MIB::ifPhysAddress.3 = STRING: 0:c:6e:8a:f8:39
4. Control de cambios de los programas de una instalación
El control de cambios de un programa instalado es el método de evaluación y apro- bación de las modificaciones que se realizan a los elementos de la configuración “sw” durante su ciclo de vida.
Para abordar el control de cambios, hay que definir primero el concepto de EC o ele- mento de configuración. Es aquél elemento de un sistema sin el cual se pierde una fun- cionalidad identificada. La definición de EC depende de los gestores y podrá tener mayor o menor nivel de detalle. Hay que valorarlo. La gestión de configuración es el control de los elementos de configuración del sistema.
Se suelen distinguir 3 tipos de control, el individual, el de gestión y el formal. El pri-
mero tiene lugar antes de aprobarse un nuevo elemento, el de gestión aprueba el cambio y el control formal es el realizado en la fase de mantenimiento.
— Control individual. O informal. Un elemento de configuración bajo control indi-
vidual, permite que se cambie la documentación sin más. Aunque se mantiene un registro informal de revisiones, no se incluyen, en general, en la documenta- ción. El control individual se aplica en las etapas importantes del desarrollo del documento y se caracteriza por cambios frecuentes. — Control de gestión. Implica un procedimiento de revisión y aproba- ción de cada cambio en la configuración. Como en el anterior, el control a nivel de proyecto se da en el proceso de desarrollo pero se
![Vasconcelos, José Mauro de - Las Confesiones de Fray Calabaza [pdf]](https://imgv2-2-f.scribdassets.com/img/document/119185109/149x198/7998be9c47/1594152446?v=1)
