Arquitectura IT: Investigando para implementar nuevos componentes en una infraestructura

Tu organización IT tiene en mente actualizar un componente de la arquitectura en la infraestructura en producción.


Digamos, en los nuevos servers Linux a instalar, en vez de utilizar filesystems estándars (EXT4, etc.), van a utilizar volúmenes lógicos (LVM, etc.), sobre los cuales luego recien crearan los filesystems.



¿Qué es lo primero que vas a intentar aprender sobre el componente que se quiere introducir?


- ¿cómo se instala?
- ¿cómo se configura?
- ¿cual es la última versión estable?
- ¿cual es la última versión soportada por las versiones de sistemas operativos en producción en la infraestructura?
- si esta es anterior a la última versión estable, ¿cuales son los potenciales problemas que podría haber (que están solucionados en la nueva versión estable)?
- ¿paquetes disponibles ?
- ¿source a compilar (no recomendado en gral. esto último)?
- si la versión del OS es la última, hay algun service pack disponible, que no se está usando - todavía - en producción y se podría introducir (testear, aprobar, promover a producción, etc.), que brinde versiones más nuevas o la última estable?
- etc.

más otras posibles preguntas y temas a considerar.


En realidad lo más importante a considerar al comenzar la investigación de un componente nuevo para la infraestructura es verificar cómo se arregla ese componente cuando deja de funcionar.


Todos los demás issues empalidecen gravemente cuando surge la simple pregunta de "..y si deja de funcionar ¿cómo se arregla?"


Esa pregunta no suele surgir de inmediato en el IT guy, pero suele ser de las primeras (viene luego de "cuanto cuesta"), que preguntan los jefes, especialmente cuando los jefes no son del ámbito informático, ahí incluso suele ser la primer pregunta.


No se trata normalmente de falta de confianza en el IT guy - a veces sí - sino de sentido común: vas a meter algo nuevo en la infra, ok, ¿sabés arreglarlo?.


En otras palabras nos están pidiendo un procedimiento de resolución de problemas y recuperación de servicio. Material similar al que iría directo a diversas carpetas de procedimiento en la documentación de la infraestructura, incluída la política - y plan - de Disaster Recovery (inserto en el Business Continuity Plan, ya que estamos).


Una respuesta a bocajarro del IT guy puede ser algo tan simple como "sí, hay procedimientos claros en la documentación", siguiendo un enfoque optimista en cuanto a haber leído a vuelo de águila algun capítulo "Troubleshooting" en algun libro o manual disponible.


Eso no es un procedimiento de resolución de problemas y recuperación de servicio, lo que hace falta es implementar el componente en un ambiente de testing, romperlo y probar los procedimientos estandár de solución de problemas y recuperación, aquí muy probablemente van a aparecer las particularidades relacionadas con el entorno particular (limitaciones, posibles soluciones alternativas más simples/rápidas/seguras, workarounds relacionados con lo anterior, por ej. impulsando alguna modificación a la política de backup actual, etc.), y de claro, al efectivamente probar las técnicas, veremos qué tan bien funcionan.


Recien luego de ese trabajo existe una respuesta real a "¿sabés arreglarlo?", no antes, ni con la mejor buena intención y proactividad del SA.


Más de un jefe IT ya sabe esto de antemano y se va encargar de recordárselo al SA si hiciera falta. Si por las dudas, ello no ocurriera, la proactividad técnicamente correcta, debería ser probar primero y verificar que los procedimientos de reparación del componente funcionarán cuando se los tenga que aplicar.


Luego de tener lo anterior en firme, la idea de implementar un nuevo componente en la infraestructura, recien podremos realizar una propuesta firme hacia arriba y podremos empezar a afinar detalles respecto a todo lo demás...


..que claro, por cierto, ya habremos visto bastante durante las fases de prueba de troubleshooting procedures ;-)