Simplificando los principios de análisis , diseño e implementación de portales. Cercando las necesidades de cada cliente. Afrontando los deseos de los desarrolladores. Luchando por un enfoque ágil arquitectónico.

esc Administracion a0001 - Directrices y Responsabilidades de la Administracion de sistemas

Scripts

01 - Scripts - Base arquitectonica
La historia de la informática está ligada a la automatización de tareas y procesos.

Un programa informático no es más que una sucesión de tareas organizadas de alguna manera, ya sea secuencial, procedimental, con recursión, estructurado, orientado a objetos, enfocado a eventos, etc.

A nivel de sistema, también se puede ver de la misma manera. La administración son tareas, las cuales siempre se podrán organizar, estructurar y finalmente automatizar, como si fuese un programa más.

Realmente todo en la vida son tareas y es absurdo repetirlas si puedes hacer que se hagan solas.

Por ejemplo, te gusta una serie que es a las 4 de la tarde. Un día esperas a que sean las 4 para grabarla, otro igual, pero al tercero ya preparas el aparato reproductor para que te grabe la serie, de forma que tu no necesitas estar atento para ello.

A nivel de sistema es igual, tu preparas un cron para que se ejecute a las 4 de la tarde y grabe la serie, pero haces más cosas, preparas otro cron para que revise que se ha grabado y si no te envíe un correo, preparas otro más para que compruebe el tamaño de las series grabadas y si supera 100Gb, que borre los últimos episodios y finalmente otro último programa para que te envie los últimos cinco minutos de la serie comprimida en mp4 a tu teléfono movil.

Estas tareas que hacemos con la serie sería una analogía de una administración de primer nivel de sistemas, Es la base para empezar a crear la arquitectura. Afortunadamente los sistemas permiten hacer mucho más que nuestro aparato reproductor de series.

¿ Por qué no vamos a aprovecharlo ?

El objetivo debe ser precisamente ese, preparar scripts para grabar (series, películas, dibujos, partidos), luego que los estructure y organice. Ya vamos viendo la necesidad de una estructura.

Que si cambiamos un script para que grabe 7 minutos y no 5, que se haga en un único lugar, y que si cambiamos de plataforma, no haya que cambiar ninguno de los scripts. Hablamos de arquitectura homogénea.

Con lo cual una buena administración debe estar basada en scripts, organizados jerárquicamente por funcionalidades comunes y con los mismos principios que cualquier programa o desarrollo de software :

Máxima cohesión

Minimo acoplamiento

Por tanto debemos abogar por funciones.

Ahora bien, el formato de dichas funciones debe ser lo más compatible posible pero sin nunca perder capacidad de funcionalidad, por tanto debemos tener una fuerte base en la shell de unix sin dejar de lado otros lenguajes de scripting como perl, ruby o python.

Éstas funcionalidades abarcan desde aspectos comunes de cualquier entorno a aspectos específicos, los cuales varían por entorno y plataforma, aquí el arquitecto de sistemas deberá analizar si es más conveniente una política global para todos los sistemas parametrizada o bien hay que hacer excepciones y tener políticas locales paralelas.

Brqx Arquitecturas - Metodologías Ágiles.

Visión

02. Visión directa de los servidores y sites. De un vistazo sabemos donde estamos.

Es primordial que el primer vistazo o apariencia de un servidor o entorno nos cuente cosas, para ello considero ideal aprovecharse de las posibilidades del mismo para aplicar diferencias visuales.

A nivel de shell, basta con ajustar distintos colores a las sesiones, ya sea a nivel de color de letra , fuente o background para tener un primer impacto de dónde vamos a hacer revisiones o modificaciones.

A nivel de consolas de administración, es bastante sencillo hacer modificaciones en CSS y Imágenes estáticas para tener una primera Visual del entorno que estamos administrando.

Aparte de la apariencia inicial, debemos intentar aportarnos más cosas cuando administramos sistemas.

En la shell podemos preparar unos profiles que nos aporten información, como puede ser los montajes generados, espacio ocupado para los sistemas de ficheros, versiones implantadas, etc..

Datos

03. Datos homogéneos y significativos

Es mucho más importante introducir valores que aporten al administrador que la típica tipografía ascii que sólo dice de que empresa es el sistema y que no aporta nada.

Por tanto nuestra arquitectura de scripts deberá tener funcionalidades de análisis de entorno y estas mismas deberán ser invocadas en el acceso a los sistemas.

Por tanto, se trata de información, que además de ser visualizada en la entrada a las máquinas, también podrá ser invocada en cualquier momento con funciones conocidas por los administradores que eviten múltiples consultas para conocer el estado del entorno.

Ésta solución homogénea permitirá tener una visión conjunta entre todos los administradores de cualquier información relevante para tener esa visual del sistema, como puede ser espacio ocupado, memoria, variables definidas, procesos corriendo, etc.

Alarmas

04. Checkers y alarmas bien planificadas

Es importante que el sistema nos ayude a diagnosticar problemas. Los sistemas, como cualquier autómata, pueden programarse para hacer chequeos periódicos con objeto de diagnosticar el estado del sistema y servicios relacionados.

Ésta información puede reportarse vía logs a nivel del propio sistema y podrá además dependiendo de la criticidad e importancia del problema, podremos habilitar sistemas de reporte a nivel de correo, a nivel de entrada en algún sistema de control como puede ser un cuadro de mando, o bien a nivel de alerta vía movil.

El objetivo de éstas alarmas es que sean precisas y que aporten información en razón a la periodicidad de las mismas.

No aporta información una alarma cada hora, pues si en la primera hora no se ha solucionado, es absurdo volver a recordar el problema, si puede ser un recuerdo continuo en un cuadro de mando, pero a nivel de alertas hay que establecer sistemas progresivos.

Por ejemplo :

1. Las tres primeras horas

2. Luego cada 2 horas dos veces,

3. Luego cada 3 horas otras dos veces

4. Dos veces al día durante dos días

5. Una vez al día

Para poder implementar éste sistema, cada alarma debe considerarse como una entidad en si misma y en razón a ello, implementar un flujo con su funcionalidad asociada.

Estructura

05. Estructura solventes y robustas
01_Subpagina - Estructura
Cualquier sistema aporta una estructuras por defecto, ya sea a nivel de carpetas, procesos, variables, etc...
Ésta es la base, pero una buena administración de sistema debe buscar homogeneidad entre los sistemas, y para ello estructuras paralelas entre los mismos, de forma que se debe intentar ajustar esas configuraciones por defecto a rutas más acordes a una administración global.
La finalidad es que el administrador tenga que pensar lo mínimo posible y que los comportamientos habituales en todos los sistemas sean similares.
Por ejemplo, si tenemos una ruta por defecto donde las aplicaciones van a una estructura como:
<ruta_servidor>/bin/cfg/apps/<aplicaciones_1_n> 
 
<proveedor>/<version>/<ruta_servidor>/<cfg>/<apps>/<aplicaciones_1_n> 
03_Subpagina - Estructura
El objetivo del arquitecto de sistemas es preparar, o bien a nivel de las propias aplicaciones, o bien a nivel de sistema vía enlaces simbólicos rutas más generales como :
/base/apps/<aplicaciones_1_n>
05_Subpagina - Estructura
De manera que siempre las aplicaciones estén en la misma ruta. De ésta forma se puede habilitar funciones genéricas de listado, acceso, proceso de esas mismas rutas.
Así podemos implantar rutas comunes para software, trazas y logs, configuración , datos y por supuesto scripts.
Para dar una visión más práctica, por ejemplo preparar lo que serían "mini alias" como W - T - L - D - S - X
Es decir :
Software - Asociado con la W
06_Subpagina - Estructura
Trazas - Asociado con la T
Logs - Asociado con la L
Datos - Asociado con la D
Configuraciones (settings) - Asociado con la S
Scripts (execution) - Asociado con la X
07_Subpagina - Estructura
Basándonos en nuestra propia implementación definida en scriptingunix.com, tendríamos un ejemplo :
Alias :
Alias : 
 
alias sofware='cd <ruta_software>' 
 
Mini alias : 
 
alias S='software' 
09_Subpagina - Estructura
Ésto lo implementaríamos en ficheros .ma .a y .v para las definiciones , pero ésta parte prefiero delegarla al portal de <a href="http://scriptingunix.com">Scripting Unix</a>.
Un saludo.
Ricardo Cabello Torres / Brqx

Todo en Uno

06. Todo unido: Arquitectura

Una arquitectura de scripts unix es un conjunto de programas y definiciones correctamente organizados de forma jerárquica y basándose en funcionalidades comunes.

La idea es que se definan funciones y recursos a utilizar en N sistemas. Habrá funcionalidades válidas para todos los sistemas y existirán algunas más específicas.

A nivel técnico lo tengo definido en scriptingunix.com, pero aquí vamos a enfocarlo más a nivel conceptual.

Una arquitectura se puede ver como un árbol de forma que las funcionalidades de las hojas (scripts/funciones) siempre son más específicas que las de las ramas (scripts/listas).

Éste árbol debe definirse de manera que los cambios en las ramas sean los menos posibles, siempre que se pueda pero a su vez que la funcionalidad definida en las hojas de la misma pueda acoplarse a susceptibles cambios en las ramas del árbol.

Lo explicamos. Una primera posible estructura sería.

Rama A : Funciones de Unix

Rama B : Funciones de Internet

Rama C : Funciones de BBDD

Rama D : Funciones de Drupal

Pues los scripts (hojas) invocados por las listas (ramas) deben poder cambiar de rama y estar en la nueva arquitectura sin necesidad de tener que cambiar los propios ficheros.

Rama A : Funciones de Unix

Rama B : Funciones de Internet (Incluye Drupal / WordPress / Genérica Internet)

Rama C : Funciones de BBDD

Ésta estructura y su maleabilidad es una de las claves para una robusta arquitectura de lo que sea (scripts).

Todo esto es debido a que las definiciones / conocimientos / capacidades iniciales no tienen por qué ser las mismas que las actuales, ni que las futuras.

Es por ello que todo arquitectura que se precie debe permitir cambios en la misma.

Comunicación

07. Comunicación con otras personas y grupos sosegada y apacible. Fines comunes

No a las guerras entre departamentos.

Es finalidad de todos luchar por la mejora del software que estamos administrando.

Todos debemos ser responsables para que una aplicación funcione mejor o para que un sistema de más facilidades en su uso.

Por ello para un buen administrador de sistema, los desarrolladores son sus "amigos" y el debe ser amigo de ellos y cuanto más conozcca de los desarrollos que se están haciendo y de la forma en la que están trabajando los equipos de desarrollo, mejor administrador de sistema será.

Está en el espíritu de mejora continua intentar hacer cada vez más sencillo y agradable el uso de los sistemas.

En ese mismo espíritu deben incluirse todos los departamentos de la empresa, pues lo que es bueno para unos, debe ser bueno para todos.

A su vez el conocer como funcionan y de que forma trabajan los equipos de desarrollo, marketing, dirección, etc. ayudará a los administradores de sistema para poder improvisar mejoras que aporten facilidad o funcionalidad adicional a la organización.

Aparte, no considero que sea una buena técnica ocultar detalles técnicos de la infraestructura a los otros equipos.

Considero que la transparencia en las estructuras el compartimento de información ayuda a mejorar y a sentirse más integrado a todos los departamentos y personas de la empresa.

Por tanto, no veo necesidad de colocar barreras entre desarrollo y sistemas y apostaré por una transición ágil y completa de información entre departamentos, con objeto de solucionar entre "todos" cualquier problema o nueva funcionalidad que se desee implantar.

Planificación

08. Planificación de cambios y mejoras. Anticipación y reporte. Información completa. No sesgada

La implantación de sistemas no es sencilla ni rápida. Reálmente no conozco nada que sea rápido de implementar, ni lenguajes, ni arquitecturas, ni sistemas, ni palitos de chocolate.

Si deseamos que una estructura sea completa y de calidad, las prisas son nuestro enemigo.

Ninguna arquitectura de scripts ni ninguna mejora en un sistema se puede llevar a corto plazo.

Ésto es utópico y lo único que va a generar son sistemas con inconsistencias, llenos de ñapas y malos rollos entre los que lo han implantado

A su vez, es mejor plantear un modelo evolutivo. Apuesto firmemente por una política de bazar y no de catedral también para scripts. Considero que las políticas de catedral donde todo se especifica al principio son un retraso y un impedimento para que la arquitectura de scripts definida e implantada sea ágil , dinámica y potente.

Cualquier política de catedral implantada en las empresas sólo tiene como resultado una mal implantación de sistemas, pues los cambios que son necesarios tardan mucho en llegar a producirse y la arquitectura realmente no contempla las necesidades del entorno.

Actualización

09. Actualización de versiones y componentes. Arquitectura "viva"

En la misma idea que las planificaciones, hay que poner hincapié en las actualizaciones, pues tanto el software como los propios departamentos cambian, entonces hay que adaptarse continuamente a las tecnologías actuales.

Una actualización implica, nuevos sistemas, nuevos productos, nuevas estructuras y por supuesto nuevas arquitecturas.

La finalidad es que nuestra estructura pueda ser facilmente adaptable a cualesquiera requerimientos y nunca una adaptación a una nueva funcionalidad debería pararse por problemas de ajuste de los mecanismos actuales.

Por tanto toda nuestra jerarquía de funcionalidades y componentes debe ser dinámica de forma que los cambios sean viables en todo momento.

No debe haber motivos ni políticos ni económicos que impidan una actualización de los sistemas y que eviten que la organización utilice los componentes más acordes para su funcionamiento en cada etapa.

Perspectiva

10. La administración de sistemas propuesta concuerda 100% con las bases definidas de lo que es un desarrollo ágil.

El objetivo es eliminar burocracia y centrarse en la solución de problemas de forma proactiva y preventiva, para ello pongo énfasis en lo que sería la automatización de tareas.

Aunque cada entorno es heterogéneo, los problemas de los administradores de sistema son comunes.

- Problemas de estructura ( logs, sistemas de ficheros que se llenan , montajes inapropiados , permisos , etc )

- Problemas de comunicaciones ( accesos a otros sites bloqueados, filtros por IP , políticas de ASM , etc )

- Problemas de aplicación ( errores que dan las aplicaciones potenciados por un configuración de sistemas inadecuada o mejorable )

A su vez las soluciones también son siempre las mismas :

- 1. Conocer el entorno

- 2. Conocer las necesidades del proyecto

- 3. En base a ello agilizar tareas

- 4. Automatizar esas tareas con un planteamiento arquitectónico y evolutivo

Entonces, hemos hablado de entornos , de estructura y de arquitectura, lo que implica que los buenos administradores de sistema deben ser perfiles mixtos ( desarrollo /sistema ) y deben abanderar las labores de scripting.

Un arquitectura de scripts es la mejor inversión que puede hacer cualquier empresa para sus sistemas.

Una arquitectura debe evolutiva para irse adaptando a todas las necesidades y mejoras que se propongan

Por tanto, como conclusión, la objetivo de una buena administración de sistema acaba totalmente ligada a una buena política de scripting y profiling de los propios sistemas, y para ello pues requiere de arquitectos de sistema que sean capaces de implementarla, documentarla y fomentarla.

EspañaInglaterra