Los PEORES ERRORES que cometí como SRE 🙀
HTML-код
- Опубликовано: 15 сен 2024
- Hoy hablo de 4 experiencias en donde cometi errores graves trabajando como SRE en diferentes ámbitos. Cuales fueron las consecuencias, y qué aprendí de cada una de esas experiencias.
Espero que estas experiencias les sirvan para evitar cometer estos errores, o al menos evitar que afecten a sus clientes de forma grave.
--
merch.peladone...
Repo con todos los archivos que uso: github.com/pab...
Link para registrarse en Digital Ocean (50 USD de Regalo!): bit.ly/digital...
Micrófono: Blue Snowball ICE
Cámara: Canon Rebel SL2
Lente: Canon 18-55mm f/4-5.6
Laptop: Macbook Pro 15'' 2017
Kit completo: bit.ly/kit-pel...
Mi canal de vlogs: bit.ly/youtube...
Comunidad de Reddit: bit.ly/reddit-...
Comunidad en Slack: bit.ly/slack-pe...
Comprame un cafecito: bit.ly/kofi-pe...
Varios han preguntado que significa "Runbook", por mas que mi pronunciación haya sido perfecta, no quedó bien claro a qué me refiero, acá les dejo una pequeña wiki: es.wikipedia.org/wiki/Runbook
Gracias Pédalo.
Tu pronunsiasión mendosina no afectó para nada. Jaja. Runbook. Está claro. Runbook
Jaja
No me gustó. Yo uso rambox en mi contenedor windows.
Peladus sucks.
dale no me gusta si cuando escribís el runbook, lo volves a leer y no entendes ni vos lo que estas haciendo o va a pasar.
Genio!! En un parte decís, cuando lo reinicié había un "taipo" (en criollo), como se llama eso ?
jeje, Pablete... buenos consejos! Como compañero y complice en la anecdota del viaje a San Luis... sumo 3 cosas MUY imporantes: 1) El cliente valoró mucho la ACTITUD de ir y solucionar el problema incluso viajando 2) Te conté en el viaje toda la historia detallada de MetallicA (volviste más fanatico de lo que eras) 3) El lomo q nos morfamos en San Luis estaba moooouyyy bouuuueno . Un abrazo !
Completamente de acuerdo. Normalmente los clientes, aunque obviamente les va a molestar que algo falle, normalmente valoran la acittud de querer resolver el problema lo antes posible; y sobre todo ser honesto con lo que ha sucedido y cómo se ha solucionado.
Intentar engañar al final suele ser lo peor y se termina por descubrir.
El que no falla, no aprende.
Yo agregaria. El que falla y no aprende del mismo error, nunca mejorara.
@@geovannyquiros5080 Yo agregaría.... PUTOS ACCENTOS.
🤔el que no falla es porque no hace nada
a veces sale caro "aprender" en produccion jajaj
Yo aprendo cada día como 3 o 4 veces 😅
Cito a mi tio bob: "The first attitude that we need to change in our profession is the notion that speed is the same as rushing. You don’t get done faster by rushing. You get done faster by being careful. The only way to go fast, is to go well". Buen video, suerte!
Me estoy pegando una viciada con tus videos, como programador te digo me resultan todos muy interesantes y útiles! Saludos
Pelado, puedes hacer un video explicando el proceso RCA, que es como funciona. he trabajado para varias empresas y el factor comun en los problemas es el proceso
7:26 Esto es memorable para la reciente caída de Facebook (aunque tengo entendido que el propio guion de emergencia creado para evitar la caída, pues también falló, tenía una excepción no controlada -"error"- *sin embargo sigue siendo válido el no haber probado ese* _runbook_ ). *He actualizado la Wikipedia con ese artículo.*
Yo también hago RunBooks porque mi memoria es horrible y también lo llevo todo con calma porque ser SRE requiere mucho cuidado para evitar la mayor cantidad de errores... Eres de los míos, lento pero seguro!!! Un abrazo hermano!
Yo solia protegerme trabajando con poco esfuerzo, ya que asi podía justificarme mis errores a mi mismo como que estoy trabajando a media potencia y tengo margen de mejora. Lamentablemente ahora trabajo al 120% (hago hasta mas horas) y como suponía, cada error me frustra en exceso ya que siento que estoy dando ya mi máximo y sigo cada dia cometiendo errores y al final uno pierde la confianza en si mismo, porque cuando lo das todo sin resultados uno se viene abajo. Esta bien por eso ver qué otros también cometen errores, a veces uno se siente solo cuando se equivoca
En el minuto 1:38 cuando dijiste que pusiste ; y enter sentí un vacío en el estómago, vaya amigo cuanta experiencia ahora tenemos, pero igual mucho cuidado ahora y respaldos antes de los cambios debemos.
Mi primer laburo referido a la informatica fue en una pasantia en una casa de ventas y reparacion de PC, un dia me mandaron a formatear la maquina de la jefa/dueña, como siempre Windows necesitando ser formateado para solucionar problemas. Cuando contecte el disco de la PC en una externa para copiar la info, lo hice con una IDE de 80 y el disco soportaba solo de 40, algo raro que nunca mas me paso en la vida, pero bueh. Le perdi la información de 7 años de trabajo, a partin de ahi nunca mas hice algo sin pensar 3 veces.
yo antes de cambiar algo en produccion, saco backups de rapida restauracion, snapshots, files, que me permitan hacer rollbacks rapidos. No me fio de que ya exista un backup automatico, saco mis propias copias.
Excelente Pablo, como comentario y regla genereal, siempre pero SIEMPRE, antes de un ABM en la BD hago un BEGIN, observo los registros cambiados, y luego cuando estoy seguro hago el COMMIT.
Muy buen vídeo Pablo. Podrías hacer un próximo vid explicando buenas practicas para hacer runbook efficient, effective y reliable. Abrazo Palado!!!!
El problema es cuando el entorno de Prod es distinto al de No Prod, para reducir costo obviamente.
Lo mismo me pasó con MySQL, cambié la BD, me metí a bañar, en la ducha me di cuenta el penal que me mandé
Capo Pelado, yo tambien empece con counter strike y linux, poniendo un ranking hlstat con apache y mysql, saludos !
Sos un groso, pelado !!! Me encantaron las anécdotas y el mensaje transmitido: las cosas hay que hacerlas con cuidado y en el caso de que se cometa un error, siempre se aprende de esa experiencia.
Todo buen profesional en su inicios cometió el error del update o delete sin where, lo que nos ayudo a ser muy meticuloso y metódico posteriormente. Pero el que no falla nunca no aprende que hacer cuando sucede. Exelente video.
La primer enseñanza es cuándo te mandás un moco y no le contaste a nadie, cuándo sucede la corrección por parte de otros se hace difícil, asumir el error hace que los fallos sean mucho mas simples de solucionar.
Lo estoy viendo ahora y en verdad que calma mucho el escuchar de un profesional que el equivocarse es completamente normal gracias !🙂
9:09 lo que se usa tambien es un backout plan, es decir, cada vez que haces un cambio debe existir un plan B para volver eso atras en caso de que no funcione (y si, esto incluye tambien el borrado de archivos y su eventual restauracion por parte de BUR o BUaaS o lo que sea que haya en funcionamiento en la infraestructura).
Poderoso ZFS !!!! En mis tiempos lo hice andar en FreeBSD 8.1 y fue un golazo, y es cierto el SR. Te da experiencia para casos fuera de lo normal en el.work !!! Un abrazo pablosky
que lindos que son esos segundos en los que te das cuenta que hiciste cracker todo!.. En mis comienzos recuerdo haber escrito un validador de entrada y como no tenia experiencia, se me escapo un caso... menores a xxx ok, menores aca, alla, mayor pero hubo un set de valores, un hermoso gris y despues de dos semanas se dio ese caso gris.... recuerdo que se arreglo, tuve que decir, el famoso YO FUI!!!. y dar explicaciones RCA... luego me regalaron un free pass a rrhh...que lindo...de esas cosas si que se aprende. y es ahi cuando te das cuenta quien te ayuda, y quien no.
De las malas experiencias es que se aprende a trillar un camino hacia el éxito. El pedir ayuda para lograr hacer algo bien te hace más humilde y así ayudar con tú experiencia a darle la mano a otro para que no comentan el mismo error.
yo cometí un erro en un servidor de producción estaba borrando unas carpetas y por equivocación le di rm -rf *, fue el peor día de mi vida y lo peor de todo es que yo era el líder de infraestructura y el backup de ese contenedor no subió tampoco, que día.
Si y no , trabaje con gente que era demasiado cuidadosa para hacer cambios o liberar algo a producción y lo probaban muchas veces , pero sabes cuanto demoraban en hacer algo? , bueno aveces demasiado tiempo y eso nos podia costar el proyecto , en fin .Hay que tener la experiencia suficiente para saber cuando hacer las cosas con cuidado.
Porqueee? bueno imaginemos que estamos a 1 mes del día de la madre y te piden hacer los cambios en el código pertinentes para que el negocio vaya bien en esos días, no puedes ser tan delicado , el time to market te come .
En fin hay que saber cuando ocuparlo, y cuando aplicar... y eso lo da la experiencia.
Un día destruí un ambiente de una App completamente tener que reconstruir todo me causo todo un conflicto emocional ya que era demasiado y muchas configuraciones. Cuando termine de levantar todo el ambiente de nuevo me dije JAMAS me va volver a pasar algo así y ahí comencé a buscar sobre IaC y acabe conociendo al pelado. A mi alguien me dijo, tu no te equivocas seguido pero el día que lo haces lo haces en grande.
Gracias por los consejos, me sentí identificado con algunas situaciones que tuviste, y pues muchas gracias. Saludos desde Monterrey, México!
Yo vengo haciendo runbooks desde hace años, pero jamás los había llamado runbooks, los llamaba "manual de implementación" o "APB"... Me gustó runbook, me lo llevo.
Yo le digo "documentacion" al papel garabateado donde explico la idea de lo que hay que hacer y sus alcances funcionales
..
Una vez me llegué a esa página (por casualidad) y era re turbia. Vi el "we are hiring" y me pregunté quién podría trabajar ahí, ahora ya se que era el pelade.
Gracias por compartir estas experiencias. La humildad nos hace mas fuertes y denota la madurez de la persona. Cuando somos conscientes de nuestras limitaciones (entorno, herramientas y condicion animica) es claro que necesitamos de procesos para reducir el error humano. Personalmente, siempre que toco un servidor documento el proceso que deberia seguir para recuperarlo en caso de error en adicion a correr la instrumentacion en los ambientes de prueba.
Hey Pablo... hablando de runbooks... una lectura tremendamente recomendada: The Checklist Manifesto....
Jajajaj! Algo parecido me pasó una vez. Estaba laburando sobre una mainframe en el ambiente DEV de la empresa y tenía que hacer un debug de un programa que tenía miles de lineas de código. La cuestión es que después de estar un rato debuggeando voy al baño y dejé el programa para seguir después. El tema es que al hacer ese tipo de debug no permitía que otras operaciones o "pruebas" en el server puedan continuar por lo que quedaba todo pausado y nadie entendía por qué. Cuando volví del baño (10 minutos después) estaban todos agarrándose la cabeza pensando que todo estaba caído porque no andaba nada. Seguí debuggeando y uno grita desde el fondo: "Se arregló!!" y todo siguió como si nada. Cuando les dije a mis compañeros se cagaron de risa.
Hola Pablo vengo de parte de Fazt muy interesante tu canal, yo una vez reinicie un windows server porque iban muy lentos los aplicativos y tardo 15 minutos en iniciar todo, para mi ese tiempo fueron como 2 horas y como recién iniciaba me espante y sude frío y todo nervioso, ahora con 21 años ya se configurar aws y digital ocean, creo respaldo de todo, automatizo lo que más puedo o lo que se, lo primero que hice fue ssl de lets encrypt con cerbot
Sería bueno un video de los diferentes puestos y sus límites o sus actividades
Support IT
Help desk
Developer
Scrum
Arquitecto
Etc
Yo borre la tabla de cliente de una empresa, tambien con el delete from sin where....:D suerte era la que usabamos en testing
EXCELENTE VIDEO, Y ESTOY TOTALMENTE DE ACUERDO CONTIGO
Aprendí que MySQL no tiene rollback como Oracle a la mala. Buenos tus videos pelado. Saludos de San Juan
Por eso me da pavor cuando debo hacer algo en prod. Trato de ser lo más cuidadoso posible, antes de cometer una cagada de las grandes. Gracias pelón.
Excelente video! Bajo mi punto de vista de lo mejor! Se nota que eres un gran profesional. Se agradece mucho que compartas tus conocimientos. Un abrazo desde España.
Me pasó una vez, que deje inutilizado un servidor de Exchange 2016 por cambiar el certificado. Menos mal que eso me pasó en la etapa de test y no en producción. XD
Gracias por compartir tus experiencias!
Buen vídeo, ¿podrías compartir o hacer un vídeo de la estructura del rsa?
Buena idea, lo voy a tener en cuenta
Pelado, excelente video, el hecho de comentar los errores y dar consejos lo encuentro genial. Te sigo de hace muy poco y encuentro muy bueno tu canal.
Muy interesante tu video, en un mundo donde todos nos callamos como perros cada vez que casca algo por nuestra culpa !
Yo hago un runbook para cualquier cosa que no sea un ls en un servidor de producción . Y luego hay un compañero que me lo aprueba.. es verídico.
Me ha pasado , pero creo que después de una equivocación nos ayudan a mejorar procesos, experiencia como profesionales, y hacer de esos mas precavidos. Mi error mas horrible fue parecido al que hizo el senior de gitlab
Buena charla Pealo Nerd.... También el exceso de confianza es una arma de doble filo...
Gracias por compartir y aconsejar bro! en verdad, ayudas a esta comunidad!
Bien dicho, tienes que equivocarte y aprender de esos errores, te ganaste un suscriptor más, interesante tu canal, sabes sería genial si haces mas videos de Linux, que versiones usas de manera personal, sugerencias para empezar en Linux, distribuciones, etc, para que más personas se interesen en Linux. Muchas gracias.👍
Qué gran vídeo. Curioso por los casos que contaste. Y muy muy grandes tus consejos y reflexiones.
Me encantan tus vídeos, siento que escuchar tu experiencia y asimilar tus consejos me permite avanzar un poco más.
Gracias desde Bogotá.
Me encantan tus videos Pelado !
Cómo me he reído con tus anécdotas jaja. Una masa este canal. Y te pasaste con esa remera!!
Es verdad, mil veces es mejor asegurarte en un entorno de prueba y luego correr todo en produccion, unos minutos de mas que te brindaran paz y no esa ansiedad de revertir lo hecho de forma apurada. Un Fuerte Abrazo.
En muchas empresas ese ambiente se llama pre-prod. Suele tener lo mismo que prod (hasta el último deploy hecho), pero con algunas configuraciones que hagan que todo transcurra en un ambiente cerrado (no salgan mails, llamados, etc).
El anio pasado trabaje en el desarrollo de un programa que administra servidores de juegos en un local arcade de multijugadores VR, un dia me fui a mi casa tranquilo y me escribe el duenio del local (En Mexico es peligroso usar el movil en la calle debido a la alta criminalidad). Total que el duenio me comenta que el programa no jalaba y que se trababa, total que en todos los ordenadores tenia configurado una suerte de TeamViewer en todos lados llamado DWService, en pleno viaje me puse a revisar cada uno de los 16 ordenadores y el servidor del local remotamente para ver que pasaba... habia un archivo que no se habia copiado a los clientes.
Esperaba un final, como que prefieres escribirlo a papel que en un block de notas de windows, pero va, estuvo bueno el video (y)
Me identifique con la descripción de los que no somos tan inteligente, por eso mismo trato de ser muy cuidadoso.
Lo más importantes de cometer errores es aprender de ellos. Y, obviamente, quien no hace nada no comete errores y por tanto, tampoco aprende.
UPDATE sin WHERE. Error muy normal. Siempre hay que escribir la parte WHERE; y antes de hacer un UPDATE o un DELETE, ejecutar una consulta SELECT para ver qué nos va a devolver y sabremos a qué registros se va a afectar.
Humilde, pelado y tan buenos vídeos te ganaste un sub. Desde San Juan un abrazo!
Crack, llegué aquí por Fazt. Excelentes anécdotas.
Buenisimos tus videos, recien acabo de conocer tu canal, tu honestidad y las buenas anecdotas hicieron que me suscribiera, PERFECTO!
Excelente! Siempre aprendemos! y muchas veces nos equivocamos! Segui asi! Un abrazo!
Muy bueno che, el que dice que nunca se equivocó miente. Suerte con el canal. abrazo
Muy bueno el vídeo, estarían bien más videos como estos de procedimientos o experiencias, enhorabuena x el vídeo.
se me puso la sangre fria de solo pensar en el update de tarjetas ese
10:15 jajaja, como se ve que nunca has trabajado en un banco (NO lo hagas), el cambio mas simple toma 15 dias en llegar a produccion (desarrollo 2 dias/pruebas de calidad 10dias / aplicarlo a produccion 2 Horas), y tu no eres el que hace las pruebas de calidad ni tu eres el que aplica el cambio en produccion... y si algo sale mal debes tener un script de RollBack (tambien probado en calidad IT) para reversar todos los cambios. y hay que llenar una tonelada de documentos y obtener muchas firmas de autorizacion.
una vez me toco cambiar una variable de "VARIABLE_A" a "VARIABLE_B" todo el proceso duro 1 MES porque tenia que correr toda la contabilidad del banco para validar el cambio.
Todos los pelados son genios? Jaja na le verdad SOS un groso viejo. Tus vídeos son lo más ❤️
Por aquí en España llamamos “guiaburros” a los Runbook 🤣 yo siempre he encajado más en el segundo grupo aunque tenga menos glamour 😁
Me hiciste acordar a lo que me pasó cuando no existía internet... (para darte una idea de mi edad)... eran las 11:50 de un viernes en Formosa y a las 12:00 tenía que salir para el aeropuerto, estaba desde las 9:00 haciendo un programa que tenía que dejar andando (imagínate la presion). Cuando lo terminó felizmente con mi edición (en vi obvio), intento :x (salvar y salir) pero me salió:X (encriptar y salir) ( creo que el vi de Linux ya no tiene eso)... encima seguí escribiendo sin mirar el teclado....conclusiones, luego de que el mundo se me caiga encima, obviamente perdí el avión, tuve que hacer todo de 0 (la segunda vez es mucho más rapido) y me llevaron en auto hasta el aeropuerto del chaco, donde a las 21:30 salió el avión rumbo a mi dulce hogar....
Pelado nerd te admiro mucho capo
*Impresionante*
Quizás este es (para mí) tu mejor video hasta ahora.
Groso pelado, saludos desde Villa Mercedes San Luis
Esa sención de infarto luego de poner rm -rf * y darle enter en file incorrecto D:
Groso pela, excelentes consejos y tu remera también 🤘abrazo!!
Me encantó el video, muchas bendiciones crack
Excelentes consejos, gracias Pablo!
Ese calorcito en todo el cuerpo que te agarra cuando la re contra cagaste habiendote olvidado el WHERE. No hay CTRL+C ni padre nuestro que te salve.
Yo laburo en desarrollo, pero estoy mas tiempo haciendo tareas de DevOps. Se aprende mucho haciendo cagadas y experimentando. Pero como decis vos, siempre hay que ser cuidadoso antes de meter mano.
En mi caso leo muchisimo la documentacion antes de empezar a meter mano. Y si es posible me levanto un server local y tiro todas las pruebas ahi.
Pero del UPDATE sin WHERE no se salva nadie. Ese sensacion de despido inminente mientras uno se queda en el molde.
Chingón Pelado!
Cuanta razón tienes, muy bueno !!!
Que software recomiendas para documentación y runbook para infraestrutura de TI?
Buenas! Nada q ver con el video pero recomendarías estudiar ingeniería en sistemas o siendo autodidacta tendría las mismas oportunidades laborales? Abrazo hermano mendocino ja
Estimado pelado nerd, le sugiero que su regla de oro sea un respaldo antes de modificar algo y de acuerdo a su experiencia los cambios se realicen en horario fuera de oficina o programar ese horario de mantenimiento, éxito colega
Gracias por compartir estas experiencias :D, Saludos desde México
No soy el unico entonces, a partir de eso siempre hago un Backup al usar el UPDATE/ DELETE
Grande, muy buenos consejos. Muchas gracias 😊
Hola,que te parecé proxmox
lo haz usado???
Excelente tus videos
Excelente contenido! Sigue asi..
veo tu video recomendado por fazt , muy bueno
Buenos consejos y buenas anecdotas a considerar 😎
👏👏👏 muy buena data. Grax
Hola peladete. Tengo 2 grandes problemas con Docker, que no se ni como buscar.
1. Cada vez que arranco mis máquinas, lo hace con todos los contenedores levantados de todos mis clientes, y es un sin sentido. Incluso cuando he movido una carpeta con docker-compose, al siguiente arranque me sigue creando la carpeta antigua con los volumenes antiguos.
2. Cuando un proyecto dentro de docker crea un fichero, por ejemplo, django con un startapp, le tengo que dar un 777 para que el ide pueda guardar cambios en él.
En este punto 2 si que he encontrado cosas por internet, pero no llego a comprenderlo, me habla de guid y no se que, estoy muy pegado en ese nivel.
Tiene solución lo mío? jajajajaja
Muy bueno, tal cual todo lo que decís
Totalmente cierto.
Objetivo: Transferir una repo privada a otra cuenta organización gratuita en github.
Dato: fue el año pasado y las org gratuitas no se pueden aceptar transferencias de repos privadas.
Mis pasos:
- clone la repo privada
- borre la repo
- cree la repo en la nueva org en modo PUBLICO
- push del clone al org nueva
- cambiar a modo privado la repo.
Mi pesadilla: la repo tenia keys de aws que nadie me habia dicho y mi jefe tenia miedo que algun crawler de keys ya lo haya mapeado y me llamo la atencion feo, juraba que alli nomas era mi final 😉.
Final: las keys ya no servían pero le di trabajo a un tercero incluyendo a mi jefe de varias horas. No me botaron 😌
Buena camiseta!
Muy interesante video! El laburo de un sysadmin es ser invisible a sus usuarios!
Excelentes consejos!!!
+1 a la escritura de runbooks y al peer review!!