Los que no saben cómo administrar sistemas

Administrar sistemas es parecido a cocinar, cada tarea a realizar tiene una serie de requerimientos, cada componente a integrar tiene características particulares, cualidades importantes a tener en cuenta al integrarlos en el sistema.

En gral. quienes no entienden o no se amigan con administrar sistemas tienden a entender la metáfora anterior, sin embargo intentan aplicar la administración como recetas fijas, siguiendo el paso a paso intentan llegar a un resultado.

Es algo que se da cuando se dispone de un escenario controlado, donde disponemos de todos los ingredientes y en cantidades necesarias, en una cocina, ello ocurre en gral. en restoranes. En administración de sistemas, un escenario totalmente controlado es raro, casi siempre tiene que ver con implementaciones que realizan desde cero (teniendo la infra física preparada, y los componentes de software listos para deployar, ya habiendo testeado en ambientes de testing).

La administración típica en cambio, tiene más que ver con el día a día, y es muy parecido a cocinar de entre casa, en la cocina propia. Un día lunes, luego del trabajo, se suele cocinar algo rápido, no se tiene todos los ingredientes, no hay ganas de salir a comprarlos así que se improvisa, se revisa qué hay, y se decide qué cocinar. Luego sí, se procede ordenadamente.

Administrando en el día a día, tenemos el buen recuerdo del escenario controlado, cuando implementamos algo desde cero. Sin embargo los escenarios reales implican deployments ya en producción, servidores que no se pueden apagar durante el día, versiones de software que son la causa raíz de un problema que se solucionó solo en la siguiente inmediata versión más nueva del mismo software (que no podremos instalar porque una policy prohibe actualizar el software), etc.

Entonces la administración típica se realiza dentro de los límites de las circunstancias, y hay que recurrir a "trucos", en realidad, esos "trucos" son la metodología estándar, es lo que - al cabo de un tiempo de estar administrando sistemas - vemos son el modo práctico y ordenado de proceder para resolver un problema.

Por ej.troubleshootear una instalación en un servidor que no se puede apagar se resuelve tomando un snapshot (vía vólumenes lógicos, vía snapshots de hipervisor, vía snapshots de herramientas de hard de storage, lo que esté disponible). Luego se copia ese snapshot y se monta un servidor donde se va a testear la solución para nuestro server inapagable.

Por ej. si no tenemos las herramientas necesarias para trabajar en un server - por policy restringiendo instalación de soft - entonces se monta en entorno de compilación replicando versiones y librerías del server donde se va a correr el soft necesario, se compila las aplicaciones necesarias para que los binarios estén ubicados en un directorio de donde luego serán borrados ($HOME/bin, /usr/local/bin, etc.), pero utilizando las librerías del sistema. Luego se copia el soft compilado al server a troubleshootear y se procede.

Digamos, la gente que no se adapta a la dinámica de administrar sistemas la podemos ver rápidamente porque son "buscadores de recetas", quieren soluciones fijas, pasos secuenciales para resolver los problemas, cuando en realidad, los pasos secuenciales solamente sirven cuando se hace instalaciones, deployments. En el troubleshooting del día a día en administración, no hay recetas, como máximo, tenemos ciertas metodologías de resolución de problemas, pero no hay recetas, porque no se puede enumerar los pasos a realizar cuando no se sabe cuales pasos habrá que seguir.

Todo lo anterior vale para administración Windows, Linux, Unix, AS400, y cualquier otra plataforma.