Brevenotas Falla en el sistema de Migraciones - pérdida de datos

Harima dijo:

Según entiendo por temas no se si legales o de otro aspecto, la data no puede salir del País, si ellos tuvieran un datacenter en Chile fisico se podria utilizar ese modelo, creo que en algunas partes usan un modelo hibrido de servidores propios y Azure por ejemplo que esta diseñado para estos casos, pero ya sabemos como van los arreglines en las empresas estatales.

Haz clic para expandir...

Hay algunas instituciones estatales que tienen algunos servicios menores en Amazon pero efectivamente lo que dice @Harima es cierto, que por un tema estratégico nacional los datos no pueden estar en un datacenter fuera de la ley chilena.

Igual ya hay clouds acá con nodos en Chile: por lo menos Oracle y Microsoft fueron unos de los que me tocó evaluar.

Zuljin dijo:

Hay algunas instituciones estatales que tienen algunos servicios menores en Amazon pero efectivamente lo que dice @Harima es cierto, que por un tema estratégico nacional los datos no pueden estar en un datacenter fuera de la ley chilena.

Igual ya hay clouds acá con nodos en Chile: por lo menos Oracle y Microsoft fueron unos de los que me tocó evaluar.

Haz clic para expandir...

En todo caso yo tengo la impresion de que el tema no es tecnico, sino que de gestion y responsabilidades, al final la pega la puedes hacer en la nube o en el on-premise, ahora lo que no puede pasar es que nadie responsable del boliche supervise, y si hubo 2 meses sin cobertura en el contrato, a mi me huele a que simplemente era un servicio a la deriva en manos de quien no correspondia.

hace muchos años trabajé en una importante empresa nacional.

En el proceso de selección una vez me preguntaron: "te ha tocado velar por la continuidad operacional de un sistema masivo"?

Y yo no les conté del gordo chanta, no les conté de cuando borré la BBDD, no les conté de cuando nos hackearon y luego
un reportero cuyo nombre nadie recuerda se aprovechó de un hackeo para leer el foro admins y se enteró que ya todos lo encontrábamos turbio incluso antes que hiciera esa ordinariez. No mencioné que después del macoy123 el sitio se restauró con un dvd regrabable en donde le rogué a Diosito que no hubiera rastros de porno, o que al menos fuera porno mainstream.

Algo bueno debo haber dicho. Me contrataron. Lo malo es que en esta empresa lo importante era parecer, no ser. Como jefe de continuidad empecé a meterme a entender todos los sistemas que tenían que continuar. Me dijeron que no hiciera eso. Que chicoteara a los cabros en el turno de continuidad (tenía 3 turnos) y que "me diera una vuelta por la base" en las noches. El horario de salida era a las 17:00, y de mi casa a la base era fácilmente 1 hora si hacia ese viaje de madrugada. Nunca lo hice, pero sí estuve online para varios cagazos.

Insistí en que era preocupante que la estructura de la información que subyacía a la continuidad fuera un misterio. Lo importante era que tuviera continuidad, supongo. De nuevo, mientras pareciera que la weá andaba, daba lo mismo qué weá tuviéramos andando. Como esa información era Oracle y en ese tiempo era bueno pal EXECUTE INMEDIATE, me fui metiendo en eso y tuve algunos aciertos que nos ahorraron tiempo y malos entendidos.



Sin embargo el mensaje siguió siendo: "no es tu pega, deja que eso lo haga el DBA externo". Ese DBA externo era un viejo bien sabio, pero nadie lo pescaba. Coincidió conmigo en que debiéramos tener encendido los recycle bins, pero cuando levanté el problema me dijeron que había un ambiente de recuperación de desastres a prueba de misiles nucleares, que no weviara y dejara que la empresa externa hiciera lo suyo.


Los muchachos de los turnos de continuidad iban al sacrificio y muchas veces por su injerencia (pero también por su conocimiento) tenían que responder por un problema y por detrás levantar un ticket al proveedor, con todo lo penca que es ser el buffer entre el usuario histérico y el proveedor pajero. Yo los tenía en chat y por teléfono, con lo cual algo podía apoyar. Además tenía contacto con el proveedor externo de QA, que eran los que corrían de noche las consultas que el DBA diseñaba de día.


Mi tésis quedó parcialmente demostrada cuando un parche del proveedor de un software botó un ambiente de pruebas porque la data de prueba existente generaba un conflicto bajo ciertas condiciones. El error era críptico, pero investigable. Mi jefe me puteaba para que puteara a otro wn cuya pega era putear no sé a quien, y así hasta que el proveedor recibiera una puteada. Convencí a gente de otra área para probar algo y funcionó, pero el parche no se pudo aplicar esa vez. El comentario de alivio era "se arregló". Porque mi jefe no entendía qué había salido mal, o cómo arreglarlo ni prevenirlo. Él dormía tranquilo mientras tuviera en quién descargar la presión.

Finalmente una DBA del proveedor (una negra más simpática que la chucha bien parecida a Whoopy Goldberg) me dio un diagnóstico más preciso y comprobé que tenía toda la razón. Pero su conclusión era: borren todo y apliquen el parche.

Borrar todo era perder mucha información. Eventualmente significaría no sólo puteadas en cadena para conseguir los respaldos sino diseñar muchas consultas para repoblar el ambiente parchado selectivamente. Si no se podía putear suficientemente rápido pasaría un día completo y el respaldo ya no serviría (yo conociendo ya la estructura del contenido les expliqué que el respaldo de antes de ayer servía perfectamente). Entonces se me ocurrió plantearle a la negra y al DBA externo el proceso contrario. Borrar los registros que impedían dropear los objetos que finalmente impedían aplicar el parche. Hicimos pruebas en los mini-ambientes desechables dispuestos para ese fin, y funcionó: eliminándolos, el parche quedaba andando flor sin downtimes.

A esta altura mi jefe ya no tenía idea dónde andaba ni qué hacía. Pero en fin, generé la consulta definitiva y la mandé. Por esas cosas de la vida esa noche no estaban los de QA así que un muchacho de mi turno corrió la query. Al otro día supe que había copiado toda la parte "DELETE FROM xxxxx" pero no cachó que justo debajo tenía un "WHERE (mil condiciones)". Los DROP a continuación corrieron de lo más bien, obvio. La BBDD había quedado en un estado inconsistente, todos los sistemas del ambiente de desarrollo estaban con errores. Los recycler bin nunca se encendieron (ergo, no podía restaurar lo dropeado y luego poblar las tablas truncadas).

Yo me enteré antes que mi jefe así que él estaba orgulloso porque no había tenido que recibir una puteada para putearme a mí. Pero la política de mi gerencia no consideraba en ningún caso mitigar futuras ocurrencias procurando internalizar parte del conocimiento. Así que, sabiendo cómo venía la mano, y cuánto demoraría la restauración y la cadena de puteadas que involucraba, renuncié.

y aquí podemos ver los peligros de la externalización extrema, por suerte en los procesos que hacemos con clientes siempre tenemos una contraparte interna que maneja los datos y cómo funcionan, que además corta el queque al momento de hacer trabajos (horarios o quien maneja que cosas)

Amenadiel dijo:

con todo lo penca que es ser el buffer entre el usuario histérico y el proveedor pajero.

Haz clic para expandir...

Oh por la cresta madre, tanta verdad en una sola frase.