Volviendo a la investigación

Tras muchos meses de parón (pero muchos, muchos), por fin me he decidido a volver a mi investigación. Ya lo puse por Twitter y parece que os gustó la idea, así que os voy a ir contando los avances que vaya haciendo.

Así que para esta primera entrada, os voy a poner en antecedentes de cómo empecé con este tema, por qué me gustó y los motivos por los que voy a hacerlo de nuevo y de la manera que quiero hacerlo.

¿Preparados? Porque allá vamos.

Primera parte: la misión del administrador de Sistemas

Tengo una visión un poco singular de nuestra profesión: creo que los administradores de sistemas tenemos dos tareas fundamentales, y da lo mismo si administras bases de datos, tiras cable, haces despliegues de aplicaciones web o asignas almacenamiento en una cabina:

1. La información debe estar disponible todo el tiempo que sea posible.
2. Que sólo la gente que necesita la información tenga acceso a la misma.

En esencia, un administrador de sistemas es un guardián de secretos, el conserje que tiene todas las llaves, conoce todos los pasillos, los puntos débiles de su arquitectura, quiénes son los inquilinos que dan más problemas y con quién hablar cuando aparecen problemas que no puede solucionar.

Dicho de otra manera, la clase de persona a la que nadie quiere enfadar porque puede hacer tu vida muy complicada.

Segunda parte: el origen

Empecé a investigar intentando solucionar un problema: no teníamos sistema de backup y había un peligro real de que se perdiese información importante, así que el jefe de sistemas me encargó, como recién llegado al departamento, que investigara un poco qué software de backup había disponible y que preparase unas notas sobre alternativas para discutirlas en una reunión.

Lo que iba a ser una semana de investigación se alargó a casi dos meses (porque nunca había tiempo para esa reunión) y lo que iban a ser unas notas se convirtió en un informe de 20 folios con 15 alternativas de backup gratuito.

Me dieron el visto bueno para empezar a investigar sobre Bacula, un software bastante veterano de backup para entorno *NIX y con cliente en Windows. Con un portátil viejo con un procesador cutre y módulos de RAM que saqué de otros equipos conseguí montar varias máquinas virtuales y empezar a hacer pruebas. Al cabo de tres meses ya tenía una demo más o menos funcional (que falló con kernel panic y pude arreglar en la presentación ante el departamento) y la presentación que debía durar 10 minutos pasó a no tener final porque el jefe de sistemas dijo "no te preocupes, esto me parece muy interesante, no imaginaba que tendrías este nivel de demostración y quiero saber más".

Este proyecto fue mi "puesta de largo" como administrador de sistemas: entré a aquella reunión como técnico de microinformática y salí como sysadmin.

Durante los siguientes meses, puse en marcha y documenté procedimientos de despliegue, generé archivos de configuración, los generalicé para despliegue con Jenkins, monté los sistemas lógicos de almacenamiento y suspendí (dos veces) una certificación de Linux, porque no todo podía ser bueno.

Hice más cosas mientras, como aprender a administrar (y migrar) Nagios, pero esa es otra historia.

Cuando dejé la empresa, había una arquitectura funcional (aunque incompleta) y documentada de backup basada en Bacula. Los servidores estaban monitorizados, los procesos de backup supervisados y con sistema de alerta integrado en Nagios, y mis "notas de despliegue" tenían formato de manual y más de 100 folios.

Ya en el nuevo trabajo intenté seguir investigando, pero entre coger los nuevos procedimientos y las claúsulas de mi nuevo contrato (infinitamente más rigurosas y restrictivas que en el anterior, que ni siquiera tenía NDA) decidí que era mejor esperar al momento oportuno.

Ha pasado más de un año desde aquello, me he acomodado en mi trabajo, he aprendido nuevos trucos y quiero ponerlos en marchas, así que vuelvo a poner mi laboratorio en marcha, pero esta vez para subir de nivel.

Tercera parte: objetivos

Ya he dicho que mi objetivo es subir de nivel pero, ¿a cuál? Todo lo arriba que pueda. ¿Backup? Por supuesto. ¿Redes y routing? Desde luego. ¿Virtualización? No te quepa duda. ¿Sistemas? La duda ofende. ¿Bases de datos? Por favor. ¿Alta disponibilidad? Claro que sí. ¿Scripting? Vamos a pegarnos con BASH, PowerShell y todo lo que se nos ponga por delante.

En mi próxima entrada os daré un primer esquema de la arquitectura que voy a montar, qué decisiones he tomado y los motivos para hacerlo, pero vamos a montar una arquitectura completa de backup, con sus daemon, sus bases de datos, su puesta a punto, sus esquemas de backup, su monitorización... Todo lo que podamos, y todo lo anterior en alta disponibilidad siempre que se pueda. Y voy a hacerlo paso a paso y desde cero para aprender yo y que vosotros veáis que, por mucho que digan, no es tan complicado como parece.

Vamos a tomárnoslos como esta escena de "Aterriza como puedas":

"¿Vamos?" Sí, en plural. No se trata de que solamente aprenda yo, sino de que otros puedan seguir  mi camino y así aprender más deprisa. Mucha gente tiene la idea de que para un novato aprenda debe pasar las mismas penurias que pasaron, con una idea equivocada de "meritocracia". A mí eso no me vale: ¿de qué sirve el conocimiento si no puedes compartirlo? ¿Acaso lo hace más válido obtenerlo por haber sufrido innecesariamente? Y pensando egoístamente, si mañana te tienes que ausentar porque te has puesto malo y el novato no sabe porque no le has querido enseñar, ¿de quién es la culpa si algo deja de funcionar?

La verdad es que sólo sé un poco de Sistemas. No soy un gran experto, ni arquitecto: llevo 10 años arreglando portátiles y apenas 5 trabajando, y no todos como administrador. Tengo mucho por aprender, quiero hacerlo y quiero que todos los que puedan aprendan conmigo: soy autodidacta en la mayoría y sé lo difícil que es aprender sin ayuda leyendo apuntes en un metro abarrotado.

Por eso quiero compartir esto con vosotros, porque no tiene ningún sentido cargaros con una macheta para despejar un camino que alguien ya ha abierto antes.

Cuarta parte: avisos

Si la terminal te da miedo, no te quedará otra que perderlo: no soy administrador de la "vieja escuela", pero admiro a esos veteranos que parece que nacieron con un teclado en las manos, que tienen el ratón de adorno y para los que la terminal es su segundo hogar. Por eso voy a intentar usar terminal siempre que sea posible: vamos a aprender a manejarnos en ella, con editores de texto y a ver cómo se puede ser más eficaz para que la interfaz deje de ser "un paso más" del proceso y podamos concentrarnos en lo que queremos hacer.

Una parte muy importante del aprendizaje es saber de qué información dispones y buscar la información que te falta. Vamos a ver trucos y "manías" que es recomendable que cojamos para saber qué ha pasado, pero encontrar el error es nuestro trabajo como sysadmin lo que significa que, en general, estarás solo ante el peligro. No quiere decir que te deje abandonado, pero la forma de aprender es darse cabezazos contra el problema y además, cada uno tiene que desarrollar su estilo: yo puedo enseñarte la puerta, pero es cosa tuya si quieres cruzarla andando, haciendo el pino o con un caballito en la moto.

Por último, como ya habrás visto en el post, a veces divago. No me lo tengas demasiado en cuenta, es la forma que tengo de organizar las ideas.

Quinta parte: agradecimientos

La lista de gente a la que estoy agradecido es inmensa, pero voy a citar solamente a tres y por sus alias de Twitter:

1. A mi buen amigo @Pollonidas, por haber estado ahí, por haberme llamado mono cuando me lo merecía y por haber sido un referente en la forma de ver la informática. Creo que nunca podré darle las gracias lo suficiente por haberme escuchado, nunca haberme llamado inútil y decirme cuando algo no merecía la pena (aunque es de las pocas personas en esta profesión de las que acepto que me diga que algo es imposible).
2. A @helleworld_ , por la inspiración para atreverme a hacer esto. Siempre he querido enseñar y pensaba que no tenía nada para hacerlo, pero ella me ha demostrado que no hay que ser un gran gurú para poder ser profe. Solamente saber un poco y querer hacerlo. Es la clase de energía (y de persona) de la que necesitamos más en esta profesión, y no sé si se hay un cumplido mejor.
3. A @AnastasiaKnt, porque me recuerda mucho a mí cuando empecé y eso me ha animado a hacer lo que me hubiera gustado encontrarme cuando empecé: montar un proyecto complejo desde cero y compartirlo. Demostrar que estudiar comandos es sólo el primer paso para hacer cosas infinitamente más grandes e interesantes. Que hay vida más allá de los manuales.

Por último, quiero daros las gracias si habéis llegado hasta aquí. No sé hasta dónde llegaré, pero quiero intentarlo.

Y esta vez estaría bien no hacerlo solo.