QUÉ ES UN RCA (o POSTMORTEM) y CÓMO ESCRIBIR UNO
Ғылым және технология
Hoy hablamos de RCAs, también llamados Postmortems, son unos informes que se escriben después de que haya un incidente y tengas que reportar qué pasó, cómo lo resolviste y qué vas a hacer para que no vuelva pasar.
--
Repo con todos los archivos que uso: github.com/pablokbs/peladonerd
Merchandising Pelado Nerd: merch.peladonerd.com
Micrófono: Rode VideoMicro + Zoom H1N
Cámara: Sony A7 Mark III
Lente: Sony 28-70mm 3.5
Laptop: Macbook Pro 16'' 2019
Puedes encontrar todos mis links en peladonerd.com
Пікірлер: 44
3:03, aparte de las 5 Why, tengo entendido que tambien se aplica las 5W , When, Who, Where, What, Why, así se aborda el problema del todo.
el mejor video de todos, estas son las cosas que hacen las diferencias entre un Junior y un Senior
Siempre aprendo cosas nuevas. Sos un capo Pelado!
Excelente vídeo master pelado, sigo aprendiendo... saludos.
Excelente video Pelado, saludos desde Mexico,
VScode tiene muy buenos addons de Markdown que te permiten ver el preview directo, así ya puedes automatizar el proceso de que cuando hagas un commit en el archivo se presente la nueva info donde desees.
Excelente video. Recursos Humanos está muy interesado en el error humano.
Slack se fue a tomar viento hace unos días. Puedes empezar por ahí :3
Buen video. Gracias
IM PRE SIO NAN TE Muy bueno Pelado!
GRande pelado, Muy bueno
Muy bueno Pablo ! No conocia hackMd...
Muy bueno
Excelente video, supongo que las 5W, no hace tanto referencia al periodismo sino al hecho de que la combinación de cosas que pueden ir mal hace que una gran conjunto de casos caigan a las 5 primeras preguntas, si has preguntado correctamente, algo parecido a la teoría de 6 grados de separación, si sabes a quien preguntar quizás en 7 pasos llegas a Bill Gates, sino quizás no salgas de tu cuadra.
muy bueno ese equipo detectando Y solucionando en 35 minutos jaja muy bueno pelado!! los RCA que he visto normalmente son de RedHat y le buscan la vuelta para decir "no, no fue el servidor, fue un cambio de hace un mes"
Buena info, tengo que hacer 3 por día, me lleno el hdd de RCAs. Pero buena info. ¡Gracias!
con que herramientas administras configuraciones?
5:04 Causa raíz _"five whys"._
pela los 50 dolares son por tres dias como el periodo de prueba de upcloud?
Muy bueno Pelado! A mí personalmente me gustaría saber tu opinión en el flujo que debería seguir un RCA. Por ejemplo se me vienen algunas preguntas a la cabeza: - No necesariamente en el momento en que solucionaste el problema, por ahi con un parche, tenes la información de como prevenirlo en el futuro. O por ahi tenes el plan de como prevenirlo pero todavía no lo llevaste a cabo. ¿Cómo crees que debería ser un flujo saludable para trabajar en la prevención? - En el video mencionas de que algunas empresas comparten los RCA para que otros equipos conozcan de eso. En mi experiencia particular esto no ha tenido el resultado esperado en principio por 2 razones: no todos los equipos prestan la atención a situaciones que se podrían cruzar en el futuro / los equipos que se enfrentan al problema están compuestos por gente que ingresó luego de que el primer incidente ocurran con lo cual no se enteraron de que es ya pasó. Dicho eso, me gustaría saber si has tenido experiencia con alguna herramienta o flujo que permita de una forma útil hacer que los RCA se conviertan de alguna forma parte del runbook ante incidentes. Desde ya muchas gracias, y realmente este material es diamante en bruto!
@PeladoNerd
3 жыл бұрын
Buenas preguntas! - Con respecto a lo primero, a veces pasa que un RCA no tiene la respuesta al problema raiz, y eso está bien, mientras se cree un ticket para hacer esa investigación y terminarla (y agregar una actualización al RCA al final) sirve. En el caso de que no haya forma de encontrar el problema, dependiendo de la gravedad del asunto, hay que poner a un equipo para que siga investigando y esté atento por si vuelve a pasar para rápidamente aplicar un parche (por ejemplo, reiniciar el servicio) en el caso de que vuelva a pasar. - Eso es dificil, en mi experiencia, la unica forma de que todos tengan esto en la cabeza, es hacerles leer RCAs cuando entren a la empresa, o al menos tener un par de los mas importantes y tener reuniones para comentar estos problemas. Lamentablemente es probable que se vuelva a repetir el problema y la gente pierda tiempo investigando, teniendo la respuesta en el RCA, tal vez podrías hacer algo para que lo primero que se hace antes de empezar a investigar, es pegarle una mirada a los RCA anteriores a ver si ha pasado. No hay una respuesta facil. Saludos!
@facundocapua
3 жыл бұрын
@@PeladoNerd Muchas gracias por tu respuestas!! El segundo escenario es algo que se da bastante, al menos en mi experiencia, y es algo en lo que me gustaría trabajar durante el 2021: Optimizar los tiempos de troubleshooting cuando ese problema ya se resolvió por otro equipo. Tengo algunas ideas dando vuelta como por ejemplo implementar algún sistema de tags y luego sugerir RCAs asociados a un problema particular como parte del runbook... y mejor aún si se asocia a alertas de alguna manera... Hasta creo que puede ser un buen ámbito para utilizar algoritmos de ML que ayuden a acortar el camino sobre la causa de los problemas. Definitivamente no es un tema sencillo, y creo que nos queda mucho por aprender en eso!!
gracias!!! tengo una consulta... en la empresa donde trabajo tenemos este proceso de revicion decambios fallidos, RCA y 5 why. Pero aveces es complicado que pase esta info aprendidaa todos los que deberiamos tener este conocimiento... tienes alguna idea o en tu experiencia... como podria hacerse esta tarea?, por ejemplo: - Reuniones semanales con las "lecciones aprendidas" - Correos con "El culpable esta semana es" - Mensajes en algun grupo de slack llamado "la cagada de la semana fue" jajajaja gracias!
@rafaelcampoverde
3 жыл бұрын
joder, me respondiste: kzread.info/dash/bejne/d6aWsahuZranh6g.html jajajajaj
3:52 *«¿Por qué estaba mal confgurado?»* _Porque no ven (y si lo ven no le hacen caso) al @PeladoNerd :_ kzread.info/dash/bejne/mKeXpJSxiqSYp7Q.html 🔗
Yo tengo un dicho que me inventé que dice: "En una red no existen fantasmas, solo cosas mal hechas"
yo tengo una pregunta mas ahi...quien debería escribirlo el RCA?
@PeladoNerd
3 жыл бұрын
El equipo responsable del servicio afectado, si son varios, en conjunto
messirve
Si si pero sigues sin tu vídeo de GeoIp2 en Docker para Raspberry
Hola pelade...que empresas hacen públicos sus RCA ? tenés algún link para bicharlos?
@javicarrara
3 жыл бұрын
about.gitlab.com/blog/2017/02/10/postmortem-of-database-outage-of-january-31/ acá hay un ejemplo real
@nicolasruiz4210
3 жыл бұрын
@@javicarrara muchas gracias !!
en mi empresa estoy tratando de que se haga esto pero no a todos les parece valioso :(
No estas hosteando hackmd lo que estas hosteando es codimd que a sido renombrado a hedgedoc
No tenés lo que hay que tenés Docker nginex proxy GeoIp2 en Raspberry.
detallada? a mi me hacen hacerlo con tiempo y print .... horrible xD
¿Que diferencia hay entre un RCA y un Postmortem?
@PeladoNerd
3 жыл бұрын
Es lo mismo
9:47 Quiso decir "RCA" no "RCE"
es un privilegio hacer un RCA .... solo ´pocos entenderan ... P.D yo si detallo hasta que se logearon como un restart/reload ... #paranoic
Woow woow 😍💋 💝💖❤️