Ya son mas de 1.000.

Hace menos de tres años escribí en esta entrada que ya teníamos localizados más de 500 candidatos a exoplanetas. Desde 1992 hasta esa fecha se habían localizados 500 planetas fuera del Sistema Solar. Menos de tres años después, ese número supera los 1.000. En concreto, en el catálogo de exoplanets.eu dice que hay:

• 782 sistemas planetarios, de los que 170 son múltiples (más de un planeta)
• 1028 planetas

Hemos pasado de detectar 27 planetas al año a detectar más de 150. Antes se localizaban planetas del tamaño de Júpiter o muy superiores y ahora se han localizados planetas con una masa 2-3 veces superior a la de la Tierra. 

El el futuro supongo que se seguirán localizando nuevos plantetas, se afinaran los ya conocidos, algunos se caerán de la lista, otros se incorporarán (en más de 600 casos solo se ha localizado un planeta en su sistema) y aparecerán mas sistemas con múltiples planetas.

Todavía queda mucho para el salto a las estrellas (si es que se produce alguna vez) pero antes de ellos, habrá que hacer el mapa ¿no? Pues eso es esta lista de exoplanetas.

Cosillas que no te cuentan cuando estás estudiando informática.

En las entradas anteriores vimos como a la hora de emprender un proyecto ni las cosas son tan simples ni tan baratas como se piensa. De hecho, cuando alguien te dice que "yo tengo una web por cuatro duros" (como este blog por ejemplo) obvia el hecho de que detrás hay a serie de horas de trabajo y muchísimas más horas de estudio, preparación y experiencia. Pues aparte de esos, en la vida hay una serie de "sorpresas" que no te suelen contar y con las que posiblemente te vas a encontrar tarde o temprano.

El backup, ese gran desconocido.

Seguramente te habrán dicho millones de veces que es necesario un backup ... y nada más. Te imaginarás que el backup es una cosa sencilla, estandarizada, simplona, barata ..... ¡y una mierda!

Para empezar se pueden hacer copias de muchas cosas. Lo interesante es hacer copias de la cosa correcta y no por ejemplo, de los links simbólicos (ha pasado) 

Se puede hacer copias de muchas cosas:

- Datos. Parece lo mas lógico ¿no? Pues si, el o mas lógico, pero claro hay que saber qué tipos de datos porque no es lo mismo hacer una copia de ficheros de texto o de Word que copiar los datos de una base de datos. Según lo que tengas que sacar, se hace una forma u otra y las hay harto complicadas.

- Fuentes. Cuando están trabajando en un proyecto de desarrollo parece lógico hacer copia de los fuentes, no sirve con dejarlos en el repositorio CVS, hay que salvaguardar éste. La no protección de estos datos te puede dar  lugar a situaciones surrealista como alguien que le dijo a su jefe "Oye, que he perdido los fuentes pero no te preocupes, que tengo los ejecutables"  Lo malo de esto es que no es coña (bueno, pasó hace bastantes años) También recuerdo de una aplicación en mainframe que en lugar de COBOL estaba en ensamblador. La explicación oficial era que estaba así para mejorar las prestaciones. La extraoficial era que se habían perdido los fuentes y se había desensamblado para poder parchear el efecto 2000.Por cierto, ese sistema se quería haber sustituido a principios de los años 90 (por antiguo) y por el 2005 creo que seguía dando guerra.
- Configuraciones. Aunque no lo parezca, hay veces que hace falta reinstalar un sistema y el volverlo a configurar (si ha perdido la configuración o se está creando un nuevo entorno) es de lo más doloroso.
- El Sistemas Operativo. Pues aunque no lo parezca pues puede interesar para recuperar el sistema completo. En virtualización el lanzar un snapshot es na manera sencilla de obtener un backup. En virtualización se hace más o menos bien, pero ojo con las máquinas físicas que si no se sabe lo que hace es fácil obtener ... una máquina lista para formatear y reinstalar, y aunque no lo parezca, el trabajo ese, junto con el lucro cesante por  no tener la máquina operativa puede ser más oneroso que el coste de la máquina.

Afortunadamente hoy en día hay sistemas de backup que simplifican mucho esta labor, pero en el pasado muchos sistemas operaban con una política de backup muy deficiente o casi sin ella (copias semanales o mensuales) Lo malo es que precisamente no son baratos.

Un detalle curioso. Muchos sistemas de esos de cierta empresa de tres letras que no voy a nombrar y que presumen de sus five nines y de que nunca se paran resulta que paran todos los días un par de horas para hacer el backup ....

El restore o ¡que tutto, prefiero la muette!

Que le recupere ¿qué?

Creo que hay por ahí una estadística que afirma que un muy alto porcentaje de los backup que se hacen no se pueden recuperar. No soy yo quien vaya a llevar la contraria al estudio ... pero me lo creo. Dado que por lo general, no se hacen recuperaciones más de que de manera puntual la dificultad de recuperar un dato de un backup aumenta exponencialmente a medida que pasa el tiempo. Es fácil recuperar el último hecho (machacando todo el trabajo) pero como tengas que recuperar información de hace algún tiempo la cosa se complica y mucho. No solo el acceder a la BD de objetos preservado puede ser increíblemente complicado por su número y versiones. El localizar un fichero determinado de hace unos meses que se haya volcado a cinta puede costar varias horas. Afortunadamente, los usuarios  no suelen ser conscientes de estas capacidad, por lo que el tener que restaurar cosas antiguas no suele ser lo normal, aunque en ciertos ámbitos, puede ser normal. Por ejemplo, en un hospital te pueden reclamar una radiografía de hacer un montón de años para ver si una manchita que te han visto estaba allí hace años o es nueva.

Si es posible, o mejor es restaurar en otro sitio aparte y luego, te llevas lo que quieres al sitio correcto.

El firmware y la madre que lo parió.

Al parecer a la gente que se dedica al software no le mola mucho el meterse en las cosas del firmware. Les parecen cosas raras, frikies, .... de muy bajo nivel. Bueno, razón no les falta pero tampoco hay que olvidar que tiene su importancia. Las actualizaciones de firmware puede solventar diversos problemas que no te tienen por qué afectar directamente pero tienen su importancia en dos aspectos claves:

- El fabricante no te da soporte si no tienes la última versión del firmware. Dado que por lo general, una actualización de firmware suele precisar tener el sistema parado a los responsables de explotación no les suele gustar demasiado ... hasta que peta algo, momento en el que se remueve Roma con Santiago para dejarlo todo como se debe en un tiempo record. La frase "como pollos sin cabeza" suele aplicar bastante bien en estas circunstancias.

A ver, tengo que actualizar el firmware del blade,
del switch, de la cabina, del ....

- Las matrices de compatibilidad. Es un sub-caso del anterior, pero un poco más cabrón. Tu puedes tener tu sistemilla funcionando de p.m., sin interrupción y amplias el HW con una cabina ultimo modelo, unos servidores nuevos, unas cabinas de discos superguays .... y de repente te dicen que si quieres soporte es con una versión de firmware determinada .... y entonces es cuando te tiemblas las piernas porque para poner un blade nuevo tienes que actualizar el firmware de la cabinas, pero como esta conectada a un switch de fibra tienes que actualizar el firmware de los SFP y del switch, que por simpatía arrastra el cambio de firmware de otra cabina de disco .... total, que al final acabas actualizado hasta los interruptores de la luz, el extintor de incendios y la cafetera Nespresso. Y no veas el miedito que da todo eso. Eso sí, después de tomar todas las precauciones habidas y por haber, preparar alternativas, HW redundante, comunicaciones alternativas ... va el firmware y actualiza a la primera en 10 minutos dejándote con cara de tonto y pensando "¿y hacía falta todo esto?" Pues sí. Te en cuenta que como se te olvidara algo, te iba a petar ahí. Y por cierto, el caso que acabo de contar ... no me lo he inventado.

No obstante, el numero de máquinas con un firmware obsoleto que ya no existe ni en la fábrica como recuerdo es mucho mayor de lo parece.

Actualizaciones de software. Más peligro que una piraña en un bidé.

Se dice que el hardware es algo que puedes partir de un hachazo, al softwre sólo lo puedes maldecir. Pues es igual de cabrón que el firmware, si no más. Encima, tiene la manía de hacer gracias como cambiar APIS y funcionalidades como hace el JAVA, dejar de funcionar cosas (muy de Windows Update) cambiarte la configuración de red como hace el Linux, .... eso cuando no tenemos la costumbre de reiniciar el ordenador o como poco la aplicación. En aplicaciones que deben funcionar en 7x24 (cada vez más) se hace en horas tan bonitas como la noche del lunes al martes entre las 02:00 y las 03:00 y cosas similares.

- Creo que tenemos un problema ¿actualizamos?
- Nada, tu sigue, que de momento, no hay problemas

Al igual que con el firmware, hay sistemas corriendo en sistemas obsoletos por todas partes con los que los informáticos sudan la gota gorda cuando hay que montar, por ejemplo, un entorno igual para hacer desarrollo, pruebas o sencillamente, cambiar el sistema dónde está corriendo porque es viejo. Vete a buscar el SW que tiene instalado.

Este software tiene bugs ... vamos a actualizarlo.

Esta frase tan inocente es uno de los mayores quebraderos de cabeza con que se suelen encontrar los responsables de los sistemas. No es lo mismo actualizar un PC que un SGBD pero vamos, lo dicho antes aplica aquí. Y al igual que con lo anterior, hay auténticas reliquias por esos mundos de dios.

No busques al enemigo fuera ... lo tienes en casa.

A todo el mundo le suenan los  peligro de la Internet, los hackers y demás mandanga. Pues eso, por lo general, con una buena política de seguridad, un buen firewall y un poco de sentido común añadido todo ello a un buen equipo de BOFHers (no vale el sobrino del jefe) suele estar bien controlado.

No me refiero a eso ... me refiero al enemigo interior. A los errores de la capa 8 del modelo OSI ... y a algo peor, la capa 9 (los jefes de la capa 8)

Cuando hablo de los errores de capa 8 no me estoy refiriendo a las chiquillerías de algunos usuarios inexpertos que se narran magistralmente en algunos blog si no a otros bastante más peligrosos que son perpetrados por presuntos sysadmin que en el mejor de los casos no están preparados para las tareas encomendadas (porque el que sabía ha sido despedido porque el economista de turno ha dicho que era muy caro "y total, eso lo hace cualquiera") Y no solo hablo de conocimientos técnicos (sistemas operativos, bases de datos, administración de redes y demás) sino de conocer un poco la aplicación y su entorno.

Usuario agazapado esperando armarla sin que le pillen.

Para dar algunos ejemplos, hay sitios donde está directamente prohibido instalar nada la última semana del mes (periodo de facturación) ... vete a saber por qué, a saber que gloriosas experiencias habrán tenido.

Hay una gloriosa frase emitida por una directora de una gran empresa ante el error de uno de sus subordinados por "exceso de iniciativa" (vamos, que se saltó todos los procedimientos y metió en producción un parche que no había pasado siquiera por pruebas de sistemas)

¡¡¡ Es que tengo el enemigo en casa !!!

Por cierto, ni que decir tiene que el enemigo llegó muy alto (pero muy, muy alto)

El miedo a cagarla.

Esto podría parecer lógico pero en realidad no lo es tanto. Es como si un electricista le tuviera miedo a un cable y por eso no lo toca. Por supuesto que hay que tener precaución con lo que se hace, preparar las cosas muy bien, revisar los procesos (mejor entre varios que uno solo) pero de un tiempo a esta parte se detecta en el personal en general un miedo a cagarla que por lo general, se avanza muy poquito.

Cierto es que no se puede hacer lo del ejemplo anterior, pero entre la informática kamikaze y el (a mi juicio) exceso de prudencia existente hay un mundo. Se pueden hacer cosas teniendo las precauciones adecuadas y con planes de contingencia se puede hacer cosas, pero últimamente parece que hay tal temor a meter la pata que parece que no se hace nada por no equivocarse. Claro que habida cuenta que muchos de los profesionales que mantenían esos sistemas ya no están (o se han ido o los han ido)

Vamos a diseñar un sistema informático (III)

En las entradas previas estuve contando un poco como suelen ser las cosas a la hora de montar un sistema informático. Está redactado en clave de humor pero si alguien ha estado metido en dicha vorágine, sabe que las cosas se parecen más a la realidad de lo que le podría parecer a un profano. 

Los sistemas son en realidad más complejos de lo que piensa la gente o más simples de lo que piensan algunos. Para un buen ingeniero informático el sistema tendrá su trabajo y su complejidad pero está controlado. Para un profano lo que empieza como algo simple como un vídeo para cambiar un grifo de Bricomanía se puede acabar complicando más que la Sagrada Familia. Al final, zapatero a tus zapatos y deja al profesional hacer su trabajo que es lo mejor y en la informática no hay excepciones a esta regla. 

Con base en el texto hay una serie preguntas que pueden surgir al respecto:

1.- ¿Son los sistemas informáticos tan caros como parecen?

Pues depende, como diría el gallego.  Depende de lo que incluyan (lo de las licencias de Oracle que puse antes no es coña, es un precio auténtico) Los sistemas hechos a medida son caros porque se hacen desde cero. si se pudieran reutilizar varias veces el precio bajaría en picado. Luego, el número de veces que el cliente cambie de opinión es un sobrecoste, al igual que los cambios no previsto (legislativos, de negocio, ...) Por ejemplo, la empresa MultiEnterprise en el país A y el país B comparten un sistema para dar servicio a sus clientes. El sistema está ubicado en A, pero por la Ley de protección de datos de B, éstos deben residir en éste. Consecuencia, te montas una nueva instancia de la aplicación en el otro país, con todo el coste asociado. Obviamente, un tema legal aquí ha repercutido claramente en el coste de explotación.

Vale, repito gráfico, pero como lo he hecho
yo no pago derechos a nadie.

Otro ejemplo es cierta comunidad que sacó hace años un sistema por unos 7 millones de € ¿es caro? Pues habida cuenta que primero había que descontar el IVA y que luego incluía el precio de las licencias de cierta sistema cuyo importe ascendía 3,6 millones resultó que no era precisamente un chollo. Y la empresa que se lo llevó no acabó en plazo ni de coña, pero eso es otra historia.

Al final, depende de lo que haga, el tiempo, lo que incluya, .... Un sistema de 10 millones de € puede ser barato y otro de 50.000 € puede ser caro. A priori y sin conecer el asunto, no se puede decir. Además, no hay que olvidar que lo que sale en prensa no tiene por qué corresponderse con la realidad. No cuesta lo mismo por ejemplo, montar y explotar una aplicación relativamente simple con una BD en una sitio que no haya nada (lo pagas todo) que aprovechar una infraestructura existente.

2.- ¿Es un sistema una Web y poco más?

Ni de coña. Las web es sólo la capa de presentación de la aplicación. Es cierto que una mala web te puede arruinar la aplicación y merece su trabajo, pero por detrás hay un potente trabajo de análisis, un diseño de la aplicación, una fase de pruebas y una explotación. El uso de metodologías ágiles no evita que como algo nazca torcido sea muy jodido enderezarlo (como todo, cuanto antes detectes el fallo, antes lo arreglas) El problema es cuando el cliente no tiene muy claro lo que quiere o presiona para que las cosas se hagan a toda prisa (el famoso "Si funciona no lo toques") Aquí sale un ejemplo de ello en clave de humor. Claro que cuando has sufrido algo similar ya te hace menos gracia.

3.- Si funciona, no lo toques.

Esta es la mayor falacia en el mundo de la informática. Funcionar funciona pero ¿funciona bien? No es lo mismo funcionar (hacer algo) que funcionar bien (y rápido, claro) Si una aplicación interactiva tarda cinco minutos en resolver una consulta a la BD la cosa no funciona bien aunque la respuesta sea excelente. Recuerdo haber tenido un compañero que era un fiera del SQL pero no dominaba tanto las bases de datos con lo que le gustaba más el JOIN que a un tonto una tiza. La consecuencia es que la BD tiraba a hacer FULL SCAN por menos de nada. Alguien podrá decir "pues mete un índice" y la idea de no es mala ... salvo cuando los administradores de la BD no te dejan (pasa y mucho)

A priori, un sistema, hasta que no ha pasado un tiempo en producción y es estable, va rápido, no pierde iformación, ... no se le puede considerar que funciona (y aún así) De hecho, a los errores y/o problemas que se encuentra un sistema en sus inicios se les conoce como errores de infancia.

4.- Esto falla y no he hecho nada. Ayer iba bien ¿qué ha pasado?

Yo no toco nada ... además, las fotos de gaticos
atraen visitas al blog.

No has tocado nada ... ¡LOS COJONES! no has hecho nada cachoperrohijodemilpadres ¿a quién quieres engañar? Las cosas no pasan por que sí. Siempre hay una relación causa efecto y las cosas no se estropean de un día para otro porque sí. O bien degeneran poco a poco (véase el ejemplo del punto anterior) o si no fallan desde el primer día, no fallan de golpe. Algo han hecho. Volviendo al modo abuelo Cebolleta, recuerdo un caso es que un sistema se nos empezó a caer de un día para otro. El número de usuarios no había cambiado. La última actualización había sido hacía tres meses al menos ... y el cliente no había hecho nada ¡Y UNA MIERDA! El muy perro había desplegado otro sistema que atacaba nuestra BD cada dos minutos con una consulta sin índice. Eso sí, la culpa había sido nuestra, no suya ni de los otros que ni siquiera lo habían probado. Por suerte, se hizo un índice y asunto resuelto tras un rapapolvo por no ser proactivos, no cuidar al cliente ..... (exacto. Como puta por rastrojo)

5.- Un sistema ¿funciona solo, sin nadie que le moleste?

Pues que suerte has tenido ya que desde que comencé a trabajar con entornos en red la mayor pesadilla se encuentra en una cosa llamada interfaces. Incluso cuando trabajábamos con sistemas stand-alone ya tenían interfaces muy simples, a base de ficheros y demás para por ejemplo llevar las facturas del sistema de gestión al de contabilidad.

¿Qué estarás tramando, cacho perro?

Los sistemas han nacido de su padre y de su madre con la tecnología de moda en cada momento y con los presupuestos de cada empresa/departamento. Entonces ¿qué le espera al informático del S.XIX? Pues un batiburrillo de interfaces entre los diversos sistemas de cuidado, eso cuando no se mete un sistema a hacer lo que no debe en la BD del otro o te encuentras que cuatro departamentos, porque ellos lo valen, hacen cuatro aplicaciones similares, cada una personalizada para ellos. Al final, las cuatro van una BD central, sacan una serie de datos de la tabla y se los presentan como les interesa ¿consecuencia? La empresa paga a cuatro equipos de desarrolladores, cuatro instancias de BD (de la buena, de la caras, no de esas baratitas) y explota cuatro sistemas (eso si, creo que al menos compartían algunas máquinas) ¿te piensas que es coña? Pues te aseguro que no.

6. No hay nadie imprescindible. Todo el mundo puede ser sustituido.

Eso es una gran verdad. Lo que no se cuenta es el dolor que lleva detrás esa sustitución. Lo que suele haber es un economista que no tiene ni idea de otra que de números. Esa persona es muy cara ... pon otra más barata. Y te cepillas al que llevaba dos años y se conocía el sistema de pe a pá y te resolvía los problemas en dos horas. El/los sustitutos salen más baratos por jornada pero resulta que lo que el anterior hacía en dos días a estos les lleva dos semanas (y a veces más) y no te digo cuando se hace el off-shroring a la India. Esos ingenieros que cambian de empresa cada seis meses ... lo ideal para la estabilidad de un proyecto.

Vamos, si hay que sustituir a alguien, se le sustituye, pero sustituir por vicio, es tontería.

7. Se ha caído ¿cómo es que no hay un sistema de respaldo, una copia, un plan B?

Pues por una sencilla razón: eso es caro. Las empresas serias suelen tener sus sistemas duplicados o al menos con copias. La cosa no es simple ni barata (el precio anterior en HW y licencias, pues multiplicado por dos)  precisamente con lo que me temo que hay muchas empresas y aplicaciones que están ligeramente (por decirlo de manera eufemística) en precario. Y aunque el HW suele ser bastante decentito a veces se cae y luego vienen los lloros. Cierto es que no nos podemos blindar ante todas las circunstancias, pero si se puede hacer una protección bastante razonable, aunque como he dicho, eso es caro pero no veas la tranquilidad que da cuando sientes que tu CPD está seguro.

Responsable de IT cuando confía en el sistema de respaldo.

Eso sí, los sistemas de la empresa funcionando en precario, pero luego el economista presume de la pasta que ha ahorrado en esos derrochadores de IT.

8. Pero si cruzar una base de datos con otra es solo apretar un botón.

No sé quien fue el genio que dijo esto, pero cruzar BD de ayuntamientos (por poner un ejemplo) con las de Hacienda para detectar el fraude puede ser una de las cosas más complicadas que existan (con gran alivio de Bárcenas, Fabra, Ignacio González y otros) Supongo que la cosa habrá mejorado algo, pero claro, cada ayuntamiento (en este caso) ha elegido una tecnología según le han dado entender en cada caso, con un esquema de BD, con una serie de datos, con una serie de relaciones entre los datos que han sido las que necesitaban en cada caso. Ahora alguien puede pensar ¿y no había nadie para poner orden? Pues no y olvídalo, aunque lo hubiera habido, hubiera seguido siendo un caos. El Ayuntamiento de Madrid ya estaba informatizado cuando al Ayuntamiento de Bustelfollado ni siquiera había llegado el teléfono. Por aquella época las posibilidades de haber caído con IBM eran muy altas, ahora vamos a SW libre, BD relacionales cuando no a otras cosas más avanzadas. Casi hay que hacer los interfaces entre ellos uno a uno. Se pueden intentar definir una serie de interfaces estándar, pero en ocasiones, hay información de éstos que no hay de dónde sacarla.

9. Si esto es un decálogo ¿cómo es que no hay 10 puntos?

Bueno, nunca dije que fuera un decálogo. A cambio te pongo esta foto (trucada por si alguien no se ha dado cuenta) que le tiré a la última luna llena.

Pues si, el otro día estuve viendo Los Pitufos.

10. Vale, esto es un desastre ¿se puede mejorar?

Pues por supuesto que se puede mejorar, como casi todas las cosas. No es demasiado complicado .... o sí. Todos los costes que hemos visto en el Ayuntamiento de Busltelfollado son bastante elevados y muy complicados de reducir ... para un sólo ayuntamiento. Si en lugar de utilizar el sistema en exclusiva para un solo sitio lo hacemos para dos, los costes bajan no a la mitad, pero bastante cerca, depende de la complejidad que tenga el otro Ayuntamiento pero gran parte de las cosas que hacen los ayuntamientos son las mismas, con lo que mucho se puede reutilizar. El HW por lo general está ocioso, con lo que con el mismo HW se puede dar servicio a más de un ayuntamiento (quizás si son pequeños hasta tres o cuatro) con lo que el coste de las carísimas licencias se diluye entre varios eso sin contar que no es lo mismo llegar a VMware y comprarle media docena de licencias que pedirle cien al comercial (se te puede hacer pis encima de la emoción)

Pero claro, una vez que los ratones han visto la solución a los problemas surge la otra pregunta ¿quien le pone el cascabel al gato? O lo que es lo mismo ¿quien va a coordinar a diversos ayuntamientos para que compartan infraestructura? Y esto no pasa sólo en las AAPP, pasa también en las grandes empresas, cuando más grandes, más atomizadas y con mayores reinos de taifas.

Alguna foto de ordenadores tenía que poner ¿no?