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.
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!
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 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!
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!
@@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!!
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"
el mejor video de todos, estas son las cosas que hacen las diferencias entre un Junior y un Senior
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.
con que herramientas administras configuraciones?
pela los 50 dolares son por tres dias como el periodo de prueba de upcloud?
Excelente video. Recursos Humanos está muy interesado en el error humano.
Siempre aprendo cosas nuevas. Sos un capo Pelado!
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.
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!
joder, me respondiste: ruclips.net/video/ErbOF56SAWE/видео.html jajajajaj
Excelente vídeo master pelado, sigo aprendiendo... saludos.
Excelente video Pelado, saludos desde Mexico,
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 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!
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!
@@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!!
Slack se fue a tomar viento hace unos días. Puedes empezar por ahí :3
Muy bueno Pablo ! No conocia hackMd...
Buena info, tengo que hacer 3 por día, me lleno el hdd de RCAs. Pero buena info. ¡Gracias!
IM PRE SIO NAN TE
Muy bueno Pelado!
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"
Hola pelade...que empresas hacen públicos sus RCA ? tenés algún link para bicharlos?
about.gitlab.com/blog/2017/02/10/postmortem-of-database-outage-of-january-31/ acá hay un ejemplo real
@@javicarrara muchas gracias !!
3:52 *«¿Por qué estaba mal confgurado?»* _Porque no ven (y si lo ven no le hacen caso) al @PeladoNerd :_ ruclips.net/video/fscB2xZA2wQ/видео.html 🔗
yo tengo una pregunta mas ahi...quien debería escribirlo el RCA?
El equipo responsable del servicio afectado, si son varios, en conjunto
5:04 Causa raíz _"five whys"._
GRande pelado,
Muy bueno
Buen video. Gracias
Muy bueno
Si si pero sigues sin tu vídeo de GeoIp2 en Docker para Raspberry
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.
en mi empresa estoy tratando de que se haga esto pero no a todos les parece valioso :(
Yo tengo un dicho que me inventé que dice: "En una red no existen fantasmas, solo cosas mal hechas"
es un privilegio hacer un RCA .... solo ´pocos entenderan ... P.D yo si detallo hasta que se logearon como un restart/reload ... #paranoic
¿Que diferencia hay entre un RCA y un Postmortem?
Es lo mismo
9:47 Quiso decir "RCA" no "RCE"
messirve
detallada? a mi me hacen hacerlo con tiempo y print .... horrible xD