Me eché solo

--

Micrófono: Rode Videomic NTG
Cámara: Sony A7 Mark III
Lente: Sony 28-70mm 3.5
Laptop: Macbook M1 Pro 14'' 2021

[primiti]

Esta anécdota nos terminó pasando a todos, en distintos niveles o formas pero siempre te cargas la db jajaja. Aprendes Kung Fu ese día y la próximas haces hasta backup de la instancia de testing jajaja

[orvitocom]

El que decidió parar los backups también es responsable. Saludos.

[natsax]

Coincido absolutamente Pela.
Debo decir que como senior, es verdad, los errores son menos... pero también suelen ser errores MUY gruesos. Por eso siempre hay que tener procesos, siempre hay que tener humildad para confiar en el equipo y pedirles ayuda, asi sean juniors todos los demás... el junior esta fresco y puede ver cosas que uno no ve.

[casabasari]

El trabajo en pareja ayuda mucho a reducir los riesgos de error. Ese es un buen tip que aplicamos en mi trabajo, todas las tareas en servidores de producción que pueden tener impacto mayor las realizamos en pareja, uno ejecutando los comando y el otro observando y confirmando que hacemos lo correcto/indicado.

[davidwebchile]

ahora menos mal que trabaja en Crowdstrike. Gracias por el video sr Pelado

[mightyocean]

Un desastre la empresa, encima comunican que el problema fue un juniors. Alta lavada de manos de todos los que estaban arriba haciendo mal su trabajo, dejando que el junior tenga acceso a prod de esa forma ridicula.

Que triste cuando toda una estructura finge demencia.

[gonzalobonora]

Responsable es la empresa que tiene una BD de prod sin backup!!!

[rgyoyo]

Gracias Pablo, siempre aportando consejos para nuestro trabajo, no vamos a hacer leña del árbol caído, ya lo hicieron varios, cada tanto es necesario repasar estos "casos de fracaso" para analizarlos y estar prevenidos, no entrar en monotonía, repartir la carga de trabajo, compartir el stress, como decís en otros videos "la presión se comparte" es mucho mas llevadero cuando tenes al menos un compañero que te ayude a resolver un problema, muchos de tus consejos lo he puesto en practica en mi trabajo, gracias Sensey

[Van-Helssen]

Así es pelado, muy buena respuesta.
Deberías montar un vídeo de *BUENAS PRÁCTICAS en DevOps* mil gracias Pelado

[savagedove]

Ohh ese segundo dónde te das cuenta de que te la mandaste es eternooo...

[aaavilaaa]

En mi primer trabajo como desarrollador junior, me dieron total acceso a DB y contenedores en producción, sumado a responsabilidades del tipo interacción directa con el cliente (digamos que me explotaron un poco jaja, pero ese es otro tema). Un día me eché un moco en una tabla importante producción, no muy grave pero error al fin y al cabo. Por suerte no tuvo repercusiones en mi contra ni para la empresa, porque claramente fue primero responsabilidad del tech lead que estaba a cargo y me delegó dichas responsabilidades. En retrospectiva, creo que fue un gran descuido de la empresa darle tanta responsabilidad a alguien que recién entraba el rubro y al proyecto, pero por otro lado fue una experiencia en la que aprendí muchísimo.

[germail]

Me pongo en abogado: diferenciemos la culpa de la responsabilidad. La culpa la tuvo el programador pero la responsabilidad es de quien permite que este proceso funcione así. La responsabilidad no se delega.

[devjaime]

hace muchos años habíamos echo un procedimiento de traducción a diferentes idioms por base de datos, y lo borre desde ese momento tengo mucha precaución en borrar cosas. Pero siempre hay que tener cuidado y tener respaldos.

[bb]

5:50 es cierto. No hay que confiar en Tucumanos 😂

[KubeletKhan]

Esos perros con conocimientos sql se usan mucho, si!
Les llaman Datadogs

[angelcilfone]

Que buen video!
Ahora solo falta verlo

a todos nos ha pasado algo así, y justo como dice el pelado es cuando aprendes de la importancia de los procesos sobre todo en ambientes productivos

[MonoJaviX]

El problema, creo yo, es en los procesos, que un dev haga pruebas en una base de produccion me parece un error grave, una forma de resolver eso es que cuando se tenga que hacer una prueba, se replique esa base (o las tablas necesarias) de produccion a otro ambiente (si se requieren datos sensibles, obfuscarlos) y las pruebas las hacen en esta copia de la base y no en la real. El error fue del desarrollador pero la culpa es de la falta de procesos mas seguros que eviten que el error humano (que es algo que va a pasar tarde o temprano) genere un impacto grande.

[gmat]

Gran anecdota! Todos siendo humanos podemos cometer errores y aprener de ellos, lo que en ese caso esta mal el control de daños que la empresa tiene para prevenir que ese error humano, ponga en peligro al negocio. No se trata de algo puntual solo como tener backup y sino de tener metas claras para reducir los daños al maximo ( tener definido procesos/runbook, revisiones de codigo, acceso restringido a produccion, pruebas de codigo en ambientes de UAT/preprod) y por sobre todas las cosas un proceso de mejora continua (basado en Post-Mortem reports con un plan de accion para evitar que eso vuelva a suceder, si aun asi fallaron los mecanismos existentes)

[sergiodiaz]

Una locura total. IRREAL. ¿Como no van a hacer backups varias veces al dia de lo que es el corazon de la empresa? Sin contar la temeridad y descuido con que se manejaba LA DB DE PRODUCCION.