Blog

Jun 30, 2023

Repensar la confiabilidad: lo que se puede (y no se puede) aprender de los incidentes

Presentaciones de la página de inicio de InfoQ Repensar la confiabilidad: lo que puede (y no puede) aprender de los incidentes Courtney Nash analiza la investigación recopilada de VOID, que desafía las prácticas estándar de la industria para

Presentaciones de la página de inicio de InfoQ Repensar la confiabilidad: lo que se puede (y no se puede) aprender de los incidentes

Courtney Nash analiza la investigación recopilada de VOID, que desafía las prácticas estándar de la industria para la respuesta y el análisis de incidentes, como el seguimiento de MMTR y el uso de la metodología RCA.

Courtney Nash es una investigadora centrada en la seguridad de los sistemas y las fallas en sistemas sociotécnicos complejos. Siempre le ha fascinado cómo aprende la gente y cómo la memoria influye en la forma en que resuelven problemas. Durante las últimas dos décadas, ha desempeñado diversos cargos editoriales, de gestión de programas, de investigación y de gestión en Holloway, Fastly, O'Reilly Media, Microsoft y Amazon.

QCon Plus es una conferencia virtual para arquitectos e ingenieros de software senior que cubre las tendencias, las mejores prácticas y las soluciones aprovechadas por las organizaciones de software más innovadoras del mundo.

Tome las decisiones correctas descubriendo cómo los desarrolladores de software senior de las empresas pioneras están adoptando las tendencias emergentes. ¡Regístrate ahora!

Nash: Soy Courtney Nash. Estoy aquí para hablarles sobre cómo repensar la confiabilidad, lo que podemos y no podemos aprender de las métricas de incidentes. Soy bibliotecario de incidentes de Internet en Verica. Soy un investigador con una larga trayectoria en muchos lugares diferentes. Solía ​​estudiar el cerebro. Creo que las bicicletas de montaña son la tecnología más genial que jamás hayamos inventado.

Estoy aquí para hablarles sobre esto que hice llamado VOID. La base de datos abierta de incidentes de Verica es un lugar donde se recopilan informes públicos de incidentes relacionados con el software y se ponen a disposición de todos. Nuestro objetivo es crear conciencia y aumentar la comprensión sobre las fallas basadas en software para hacer de Internet un lugar más resiliente y seguro. ¿Por qué nos importa eso? Porque hace tiempo que el software ha ido más allá de alojar imágenes de gatos en línea para administrar el transporte, la infraestructura y el hardware en los sistemas de atención médica, y los dispositivos en los sistemas de votación y los vehículos autónomos. Se espera que estos modernos sistemas en línea funcionen las 24 horas del día, los 7 días de la semana, los 365 días del año. Esas mayores presiones a las que todos ustedes se enfrentan, combinadas con modelos de software de servicios interrelacionados cada vez más automatizados que se ejecutan en la nube, han acelerado la complejidad de estos sistemas. Como probablemente ya sepa, por experiencia directa, cuando esos sistemas complejos fallan, lo hacen de manera inesperada y caótica. Todos tenemos incidentes. Sí, ese es el incendio de un contenedor de basura con un dragón prendiendo fuego a un volcán. Creo que lo que enfrentas probablemente se parece más a Calvin y Hobbes, donde hay como un monstruo debajo de la cama y nunca estás seguro de cuándo va a salir.

El punto realmente importante es que la industria tecnológica tiene un inmenso conjunto de conocimientos mercantilizados que podríamos compartir para aprender unos de otros e impulsar la resiliencia y la seguridad del software. Si eres escéptico al respecto, lo entiendo, es posible que lo seas. Hay un precedente histórico para esto. No es nuestra industria, es una industria diferente. En la década de 1990, en Estados Unidos, nuestra industria de la aviación estaba en una especie de crisis, teníamos un historial de seguridad horrible. Regularmente se producían importantes accidentes con graves consecuencias. La industria colectivamente y desde cero decidió unirse e intentar hacer algo al respecto. Primero, una variedad de pilotos de diferentes aerolíneas se reunieron y comenzaron a compartir los datos de sus incidentes. Comenzaron a compartir sus historias y sus patrones de lo que estaban viendo. Con el tiempo, una mayor parte de esa industria se unió, los organismos reguladores, la gente de los controladores de tránsito aéreo, una gran cantidad de personas se involucraron para compartir sus incidentes y encontrar puntos en común y patrones. En el transcurso de esa actividad, y obviamente de otras actividades, el historial de seguridad de nuestra industria aérea mejoró considerablemente. De hecho, no tuvimos un incidente significativo hasta que sucedieron algunas de las cosas del Boeing MAX de los últimos años. Es posible hacerlo desde cero como profesionales antes incluso de que aparecieran personas reguladoras. Eso es importante.

Estamos tratando de recopilar ese tipo de incidentes juntos. No ha habido ningún lugar en el pasado donde hayamos tenido todos estos, lo que podríamos llamar incidentes de disponibilidad. Hay varias personas que han caminado por este terreno antes que yo. No estoy afirmando que esta fuera mi idea. He tenido la suerte de reunir a más de ellos en un solo lugar. En este momento, tenemos casi 10.000 informes públicos de incidentes de más de 600 organizaciones, que abarcan desde aproximadamente 2008 hasta básicamente ahora en una variedad de formatos. Esto es importante. Los estamos recopilando en publicaciones de redes sociales, páginas de estado, publicaciones de blogs, charlas de conferencias, tweets y revisiones completas posteriores a incidentes, donde todos se sientan y escriben mucha más información sobre estas cosas. . Queremos todo eso porque queremos una imagen realmente completa no solo de cómo ves estas cosas, sino también de cómo las ven otras personas. Allí también se incluyen cosas como artículos de medios.

Lo que hay allí es un montón de metadatos que hemos recopilado, cosas como la organización, la fecha del incidente, la fecha del informe y un montón de cosas más. En lo que realmente nos vamos a centrar principalmente en esta charla es en la duración y su relación con una métrica que es muy influyente en nuestra industria, que es el tiempo medio para responder, o MTTR. Primero, profundicemos en la duración. La duración es lo que me gusta llamar datos grises. Tiene una alta variabilidad y una baja fidelidad. Está borroso, ¿cuándo empieza, cuándo termina? ¿Cómo se deciden y registran esas cosas? A veces está automatizado, a menudo no. A veces se actualiza, a veces no. En última instancia, es un indicador rezagado de lo que sucedió en sus sistemas. Es inherentemente subjetivo. Nosotros decidimos estas cosas. Creemos que son expulsados ​​de nuestros sistemas, pero eso no es del todo cierto. La realidad es que, cuando tomas todas estas áreas grises, las usas como objetivo, las promedias y tratas de pensar que es algún indicador clave de desempeño, obtienes una gran mancha gris. No puedes confiar en eso.

Quiero mostrarles un poco de estos datos grises en acción. Estos son tiempos difíciles para responder que hemos recopilado en base a casi 7000 datos de duración de incidentes de VOID. Es realmente tentador mirarlos e intentar usarlos como algún indicador, tal vez Cloudflare y New Relic simplemente sean mejores en la respuesta a incidentes, o tal vez sus sistemas sean menos complejos o tengan suerte con más frecuencia. No, estos datos no son indicativos de ninguna de esas cosas. Como puede ver, existe una gran variabilidad entre estos, incluso dentro de una empresa, durante un cierto período de tiempo, dependiendo de la ventana en la que se intenta calcular algo así como una media sobre estos datos. El problema de intentar utilizar números como estos derivados de los datos grises de duración se ve exacerbado por la distribución inherente de esos datos de duración.

No sé cuántos de ustedes realmente observaron la distribución, trazaron un histograma de los datos de duración de sus incidentes, si los recopilaron. Retrocedamos un poco. Esta es una distribución normal, algo a lo que estás muy acostumbrado a ver. Es tu clásica curva de campana. Hay un punto medio muy claro. Hay curvas similares en ambos lados. Puedes clavar la media en el medio. Puedes obtener desviaciones estándar. Puedes hacer todo tipo de cosas estadísticas súper sofisticadas con esto. Eso no es lo que parecían sus datos, según casi 10.000 incidentes que tenemos en VOID. Así es como se ven realmente los datos de su incidente. A medida que esto sucede, estos son histogramas de la distribución de datos de duración en una variedad de empresas que tenemos que tienen suficientes datos para hacer esto realmente, cientos, al menos de incidentes. Están torcidos, como podrás notar. Están en lo alto del lado izquierdo del gráfico y luego descienden y tienen una cola larga y bonita allí. El problema con distribuciones sesgadas como esta es que no se pueden describir bien mediante métricas de tendencia central como la media. Algunos de ustedes van a empezar a pensar: usaremos la mediana y llegaremos allí. Incluso cuando hay tanta variabilidad en los datos, detectar las diferencias también es muy difícil. Eso es lo que muchas veces intentamos hacer. Estamos tratando de decir que nuestro MTTR mejoró. Nuestro MTTR empeoró, ¿qué pasó? Resulta que esto simplemente no tiene significado.

El año pasado analizamos un informe de un ingeniero de Google que tenía muchos datos muy similares a los nuestros. Realizó un montón de simulaciones de Monte Carlo en este informe que está en el informe de O'Reilly que mostré allí. Descubrió que cuando simuló una disminución en el MTTR en una gran parte de las simulaciones de Monte Carlo, había tanta variabilidad en los datos que realmente resultó en una incapacidad para detectar ese cambio. En realidad, estás restando un 10% de tu duración, estás disminuyendo tu MTTR. Ejecutas un montón de simulaciones de los datos originales con esas duraciones más cortas y en realidad no puedes detectar una diferencia. Te mostraré un gráfico de esto. Lo que encontró, y también lo replicamos cuando hicimos lo mismo con más empresas en más incidentes, fue que incluso cuando se introducen mejoras, se encuentra que casi un tercio de las veces el cambio detectado en MTTR fue negativo. Es un poco contradictorio, pero digamos que eso significa que las cosas empeoraron. Así es como se ven esos datos. Restas los datos originales de los datos modificados. Un positivo significa que las cosas han mejorado. Estos son nuestros resultados que replican las simulaciones de Monte Carlo de Davidovic. Cualquier cosa en el lado derecho significa que mejoró, y cualquier cosa en el lado izquierdo significa que empeoró, que su MTTR en realidad aumentó. Lo que verá es que en una gran parte de la mayoría de esas curvas que ve, hay lugares en los que cree que obtuvo incluso más del 10% y lugares en los que podría haber obtenido incluso peor que el 10%. Eso es realmente lo importante. Hay demasiada variación para confiar en la media. Aquellos de ustedes que han prestado atención a la distribución y saben un poco o mucho sobre estas cosas, incluso podrían decir que podríamos usar la mediana. Realizamos estas simulaciones con los datos medianos y los resultados fueron increíblemente similares. Todavía hay demasiada variabilidad y no hay suficiente tamaño de muestra en la mayoría de estos datos para detectar algo.

Hablemos del tamaño de la muestra. Esa empresa que tenía el gran rojo, tiene la mayor cantidad de incidentes que nadie, en todos los datos que teníamos. Tienen suficientes datos para que puedas comenzar a obtener cierta fidelidad de cosas como ejecutar este tipo de simulaciones de Monte Carlo y todo ese tipo de cosas. Eso realmente significa que la única manera de obtener una mayor fidelidad de los datos de sus incidentes es tener más incidentes. Realmente eso no es lo que ninguno de nosotros quiere. Tienes que llegar a los cientos superiores, casi miles, para empezar a ver curvas más cerradas y ser capaz de detectar diferencias entre las cosas. Nadie quiere eso. No queremos tener más incidentes.

Sólo para resumir un poco esto, MTTR no es un indicador de la confiabilidad de su sistema. Creo que este es un mito muy común en nuestra industria, que te dice cuán confiable eres. No hay nada confiable en esos datos que acabas de ver. No desea utilizar una métrica poco confiable para hablar sobre la confiabilidad o la resiliencia o cualquiera de esas palabras de sus sistemas. No puede decirle qué tan ágil o efectivo es su equipo u organización, porque no puede predecir estas cosas. Definitivamente no se puede predecir cuáles son sorprendentes, y todas lo son. El MTTR no le dirá si está mejorando en su respuesta a los incidentes, si el próximo será más largo o más corto, ni siquiera qué tan grave es un incidente determinado. Quiero dedicar un poco de tiempo a esto, sólo una ligera desviación. Porque la mayoría de la gente alberga alguna sospecha, como que los más largos son peores, o los más largos no son tan malos porque arrojamos a todos a los malos, y se acaban antes. Los más largos son como, lo que sea, podemos dejarlos funcionar. Nuestros datos tampoco lo demuestran. Tuvimos alrededor de 7000 incidentes de los que pudimos recopilar la duración y la gravedad; en su mayoría son páginas de estado de esas empresas. Lo que ves en este gráfico es lo que realmente parece para la mayoría de las personas. Tienes otros largos que son más severos. Están en amarillo, rojo. Son los 1 y 2. Tienes unos cortos que son 1 y 2. Tienes unos largos que son 3 y 4, son verdes y azules, no son tan malos. El aspecto de este gráfico es lo que encontramos estadísticamente. Realizamos una correlación de rango de Spearman, para cualquiera que realmente quiera meterse en la maleza, en función de la gravedad y la duración, y solo dos de las empresas que analizamos mostraron lo que cualquiera consideraría correlaciones súper débiles entre la duración y la gravedad, -0,18. , -.17 valores de R, sí tenían valores de p significativos. En ese rango de análisis correlacionales de hasta 0,2, 0,3, es un efecto muy pequeño. Es posible que algunos se vean un poco, pero también es necesario tener muchos datos para que aparezca un efecto como ese.

Estas cosas, duración, MTTR, gravedad, son lo que John Allspaw y muchos de nosotros ahora llamamos métricas superficiales, porque confunden los detalles confusos que son realmente informativos sobre los incidentes. Sólo quería dar una metáfora sobre esto, que probablemente sea bastante relevante para cualquiera de nosotros que vivimos en el oeste de los Estados Unidos en este momento. Sus sistemas son intrínsecamente complejos, y tratar de medir la respuesta a incidentes de esos sistemas por aspectos como la duración o el MTTR es como evaluar cómo los equipos están combatiendo los incendios forestales en el oeste de EE. UU. contando el número de incendios o cuánto tiempo les lleva apagarlos. , versus comprender lo que les está sucediendo a los equipos en el terreno en su realidad, y cada uno es notablemente diferente. Esa no es la respuesta que quieres. Entiendo. Si no es MTTR, que no cunda el pánico. Si no es MTTR, ¿qué es? La respuesta a esto, desde mi perspectiva, es el análisis de incidentes. Te vas a enojar mucho conmigo y vas a gritar, eso no es una métrica. No, no es. Es lo mejor que puede informarle sobre la resiliencia y la confiabilidad de sus sistemas.

¿Cómo son ese tipo de cosas? ¿Qué tipo de datos se obtienen de los análisis de incidentes? Sé que pensamos que los datos son números, observabilidad y lo que surge de Grafana. Tenemos estas expectativas sobre cómo se verá eso. Hay números y métricas que aún puede obtener de este tipo de enfoques para estudiar sus sistemas. Sus sistemas son sociotécnicos. Son una combinación de humanos y computadoras y lo que esperamos que hagan, lo que significa que es necesario recopilar datos sociotécnicos. Algunas de las cosas que reuní aquí para que ustedes piensen son el costo de la coordinación, ¿cuántas personas estuvieron involucradas? ¿Fueron llamados durante la noche? ¿Tuvieron que despertarse en medio de la noche para lidiar con esto? ¿En cuántos equipos únicos había? ¿Cuántas personas estaban involucradas? Relaciones públicas y comunicaciones, ¿tenían que involucrarse? ¿Cuántas herramientas, cuántos canales? Hay tantas cosas que le dicen si un incidente determinado tiene un gran impacto interno, junto con cuál cree que es el impacto externo, y qué tan bien sus equipos están lidiando con eso o cuánto tiene que dedicar su organización a algo para poder lograrlo. tratar con él.

Estudio de cuasi accidentes. ¿Cuántos cuasi accidentes tiene en comparación con cuántos incidentes tiene? Es mucho más, lo que significa que su proporción de éxito y fracaso es mucho mayor de lo que cree. Te dicen cosas que no obtienes de métricas como la duración o el MTTR. Luego, hay otros efectos secundarios realmente interesantes de invertir en análisis de incidentes, y es, ¿cuánto comienza la gente a invertir y participar en estas cosas? ¿Cuántas personas están leyendo esto? Puedes rastrearlo totalmente y no te asustes por eso. ¿La cantidad de personas que realmente asisten a este tipo de revisiones posteriores al incidente y asisten para escuchar lo que está sucediendo? ¿Se comparten estas cosas? ¿Dónde más aparecen? ¿Se hace referencia a ellos en las relaciones públicas? ¿Se hace referencia a ellos en las revisiones de código? Hay todo tipo de lugares, y puedes poner un número en cualquiera de ellos si realmente necesitas poner un número en una diapositiva para alguien más arriba en la cadena.

Quiero hablar un poco más sobre la parte de los cuasi accidentes, que es que los cuasi accidentes son éxitos. Cuando nos fijamos en los informes de estos pocos cuasi accidentes, no tenemos casi ninguno, menos del uno por ciento de ellos en el VOID. Hablan del tipo de cosas que encuentran en los cuasi accidentes y que ni siquiera encuentran en las revisiones de incidentes. Estas son ricas fuentes de datos sobre dónde existen focos de adaptación en su organización o en su equipo. Carl Macrae tiene un libro realmente fantástico llamado "Close Calls", donde habla de los cuasi accidentes como fuente de materiales para interrogar a lo desconocido. Puede probar suposiciones y validar expectativas, tomar conciencia de la ignorancia y también observar la experiencia tal como se desarrolla en su organización. También destacan dónde las personas aprovechan su experiencia y brindan capacidad de adaptación cuando su sistema se comporta de manera inesperada o esperada, que es lo que son los incidentes. A menudo incluyen información mucho más rica sobre los sistemas sociotécnicos, incluyendo cosas como lagunas en el conocimiento y fallas en la comunicación, e incluso cosas como fuerzas culturales o políticas en sus sistemas.

A continuación quiero hablar sobre otra cosa que rastreamos en VOID hasta ahora, que son los métodos de análisis que usa la gente. Estamos realmente interesados ​​en el uso del análisis de causa raíz o RCA. Hablaré del por qué. El año pasado, vimos alrededor de una tasa del 26% de organizaciones que declararon formalmente que utilizan un análisis de causa raíz o que tienen alguna causa raíz identificada en sus informes. Ese número bajó mucho este año. Sólo quiero aclarar que pasamos de unos 2.000 incidentes a unos 10.000 incidentes, por lo que el denominador cambió. Ese número del 6% no lo vimos en el mismo conjunto de informes. Quiero ser muy claro aquí. Estamos empezando a construir este corpus en el VACÍO. Ese es un resultado espurio. Quiero hablar sobre por qué nos preocupamos por la causa raíz y algunos desarrollos interesantes que han ocurrido desde el último informe VOID. Un análisis de causa raíz muy formal postula que un incidente tiene una única causa o desencadenante específico, sin el cual no habría ocurrido. Es muy lineal. Una vez que se descubre el desencadenante, se deriva una solución y la organización puede tomar medidas para garantizar que no vuelva a suceder. Esta mentalidad de secuencia lineal de eventos, que también se conoce como modelo dominó, tiene su origen en la teoría de los accidentes industriales. Lo hemos adoptado, lo hemos asumido. Porque no las buscamos hasta después del hecho, la realidad es que no encontramos las causas, las construimos. Cómo los construyes y a partir de qué evidencia depende de dónde mires, qué buscas, con quién hablas, a quién has visto antes y probablemente para quién trabajas.

Algo curioso sucedió entre el último informe y este, porque el año pasado tuvimos dos empresas realmente grandes en VOID, que estaban haciendo análisis de causa raíz, eran Google y Microsoft, agregamos Atlassian este año, que mantuvo el número al menos. un poquito más arriba. Entre ese último informe y junio de este año, Microsoft dejó de realizar análisis de causa raíz. Creo que es fascinante, porque si una organización del tamaño de Microsoft Azure, una organización muy grande, puede cambiar su forma de pensar y su enfoque, cualquiera de nosotros puede hacerlo. Cualquiera de nosotros puede cambiar nuestra forma de pensar y nuestro enfoque en cualquiera de las formas en que pensamos y observamos cómo los incidentes nos informan sobre nuestras organizaciones. Creo que el idioma importa. Microsoft se dio cuenta de eso. Se dieron cuenta de que cuando se identifica una serie de factores contribuyentes, especialmente si son de naturaleza sociotécnica, entonces se está modelando un enfoque muy diferente sobre cómo piensa su equipo sobre los sistemas con los que trata. Si vas y lees estos nuevos informes, los llaman informes posteriores al incidente, PIR, porque todos todavía necesitamos un acrónimo. También son muy diferentes, como los detalles de esos informes, el enfoque, la forma de pensar sobre sus sistemas ha cambiado. No estoy diciendo solo porque el equipo de Microsoft Azure de repente dijo, no vamos a abordar la causa raíz, todo eso fue parte de la forma en que eligieron cambiar su enfoque. Sólo tengo que decir que si Microsoft puede hacerlo, tú también puedes.

Necesitamos un nuevo enfoque sobre cómo pensamos, analizamos, hablamos y estudiamos los incidentes, y cómo compartimos la información de ellos. Lo más importante es tratar los incidentes como una oportunidad para aprender, no para sentir vergüenza o culpa. Estoy muy emocionado de ver tantas más empresas compartiendo sus incidentes y no verlo como un lugar donde las relaciones públicas o el marketing tienen que andar de un lado a otro y preocuparse. También favorecen el análisis en profundidad frente a las métricas superficiales. Vamos a dejar atrás el MTTR y a preocuparnos por la duración y la gravedad, y vamos a profundizar en lo que está sucediendo. Vamos a escuchar las historias de los profesionales que están en la vanguardia, que están cerca de cómo funcionan estos sistemas. Usaremos eso para comprender mejor esos sistemas. Vamos a tratar a esos profesionales y a esas personas como soluciones, no como problemas, y estudiaremos lo que va bien y lo que va mal. Sospecho que este nuevo enfoque tiene una ventaja competitiva. Creo que las empresas que hagan esto tendrán mayor capacidad de respuesta y capacidad de adaptación que otras no, lo que les dará una ventaja sobre las empresas que no ven el mundo de esta manera.

Me gustaría animaros a analizar vuestras incidencias. Hay un par de recursos aquí para pensar en cómo hacerlo. Me encantaría que los enviaras al VOID. Hay un foro, un foro muy útil, si no tienes mucho, si tienes mucho, puedes ponerte en contacto y te ayudaremos a incorporarlo. De hecho, puedes convertirte en miembro y participar de diversas formas más involucradas si estás interesado. Algunos de estos datos los mencioné en el informe anterior del año pasado, muchas de las cosas de las que hablé y muchas más estarán en el próximo informe que se publicará próximamente.

Rosenthal: Mencionaste que pronto se publicará otro informe VOID, ¿tienes una fecha ahora?

Nash: Sí. El mundo está trabajando a mi favor ahora. Saldrá el día 13. Las personas pueden ir al sitio web de VOID y habrá un botón grande y útil para descargar el informe.

Rosenthal: Básicamente, defendió en su presentación que no existe ninguna métrica que pueda utilizar para comunicar la confiabilidad o resiliencia de un sitio o una aplicación. ¿Existe alguna manera de crear una métrica combinada para resumir como un número o algo que pueda usar para representar la resiliencia o confiabilidad de su sitio o aplicación?

Nash: No. Ojalá. ¿No sería eso mágico y no querríamos todos tener ese número, coleccionarlo y celebrarlo? Desafortunadamente, no, tenemos que hacer el arduo trabajo de profundizar en estas cosas.

Rosenthal: Mencionaste que replicaste la simulación de Monte Carlo que hizo alguien de Google. ¿Puedes decir un poco más sobre cómo replicaste eso? ¿Tenías un equipo haciendo eso? ¿Qué hay involucrado allí?

Nash: Sí, lo hicimos. En primer lugar, se trataba de alguien que escribe mejor código R que yo. De hecho, tuvimos un pasante de la Universidad de Columbia Británica, cuyo nombre es William Wu. De hecho, nos ayudó con esto. Está obteniendo su doctorado en ecología evolutiva, estudia sistemas biológicos grandes y complejos, lo cual es realmente genial. Estaba realmente interesado en cómo funcionan nuestros complejos sistemas sociotécnicos. Lo que hicimos fue tomar todos esos datos de incidentes y colocarlos en dos grupos. Luego podrás ejecutar experimentos sobre eso, como pruebas A/B. No hace falta mucha gente para hacer esto. Tuve una persona que escribió un código realmente excelente y eso también nos permitió explorar mucho. Nos fijamos mucho en las distribuciones. Intentó adaptar las leyes de potencia a las cosas. Una vez que tuvimos todos estos datos, pudimos separarlos en diferentes grupos y luego probar todas estas teorías con ellos pero, desafortunadamente, algunas de ellas fracasaron.

Rosenthal: Mencionaste que Microsoft ya no hace RCA al menos con el de Azure.

Nash: La página de estado de salud de Azure para todos sus diversos servicios, sí.

Rosenthal: Si trabajo en una empresa que no es Microsoft Azure, ¿qué sería lo que me recomendarían para mejorar mi proceso de disponibilidad, no MTTR? Si solo pudiera cambiar una cosa, ¿sería dejar de hacer RCA o algo más?

Nash: Aquí es donde digo que el idioma importa. Incluso si está haciendo lo que su equipo llama oficialmente RCA, lo que realmente desea poder hacer es tener a alguien o a la gente de alguien que tenga las habilidades dedicadas para investigar este tipo de incidentes. He visto a personas capaces de hacer este trabajo en entornos donde todavía se cree que se puede encontrar una causa. Estamos viendo una tendencia en la que las personas contratan analistas de incidentes o contratan a personas que han estado en el equipo de SRE o todo eso. El conjunto de habilidades que se debe invertir en la investigación de sus incidentes es muy diferente del conjunto de habilidades que se necesita para construir y ejecutar estos sistemas. Si tuviera que hacer algo, invertiría en una persona o un equipo de personas capacitadas para investigar incidentes y distribuir esa información a la organización para que las personas puedan aprender de ella. Ese conjunto de habilidades se desarrolló dentro del equipo de Azure y eso llevó a una mayor conciencia al respecto. Creo que el cambio de mentalidad se debió a la inversión en las personas y a la adopción de un enfoque realmente diferente para aprender de los incidentes. Luego, finalmente, dijeron, ahora haremos esta otra cosa. Podemos llamarlo de otra manera y veremos qué piensa el mundo de eso. De hecho, pidieron comentarios al respecto, lo cual creo que es fascinante. Lo único es tener gente que sea realmente buena investigando incidentes.

Rosenthal: ¿Qué piensa sobre el enfoque de corrección de errores que utiliza Amazon? ¿Tiene alguna idea al respecto en relación con RCA?

Nash: Cuando investigas un incidente, no estás corrigiendo errores. Estás aprendiendo cómo funcionan tus sistemas. En el camino, es posible que arregles algunas cosas técnicas y, con suerte, cambies algunas cosas sociotécnicas. Creo que el lenguaje tiene una mentalidad similar a la que tiene RCA. Corregiremos los errores y corregiremos los errores. ¿Cuáles fueron esos errores? Creo que es una visión muy estrecha la que refleja el lenguaje.

Rosenthal: Incluye cinco porqués y elementos de acción, y otras cosas que se han demostrado de otras formas no necesariamente mejoran la confiabilidad de un sistema, aunque sí nos mantienen ocupados.

¿Qué piensa sobre la confiabilidad percibida por el negocio versus tener datos de incidentes?

Nash: Usé esta frase en la charla y es un término científico de seguridad. Quizás sea un poco obtuso. Hablamos de personas con el extremo afilado y luego con el extremo romo, es una cuña. Las personas que se encuentran en el extremo más agudo tienen una percepción y una comprensión típicamente diferentes de la confiabilidad de sus sistemas que las personas que se encuentran en el extremo más contundente y alejado del negocio. A menudo hay una gran desconexión entre esos dos. Hablo con mucha gente de SRE. Hablo con muchas personas que ejecutan este tipo de sistemas y que a menudo se sienten muy frustradas por la falta de comprensión en el aspecto comercial de las cosas. Idealmente, algunas prácticas de SRE apuntan a conectarlos un poco mejor, tratando de usar cosas como SLO que están diseñados en teoría para alinear el rendimiento de su sistema con las expectativas de sus clientes, cualesquiera que sean, como clientes internos o similares. Suele estar bastante desconectado. Lo interesante de las empresas que realmente invierten en ese análisis detallado de incidentes es que revela esa realidad, si puede hacer el trabajo para llevar esa información a su organización.

Mi ejemplo favorito de esto es David Lee en IBM. Está en la oficina del CIO, una organización gigantesca dentro de una organización gigantesca. IBM es enorme. Creo que la oficina del CIO tiene, en última instancia, unas 12.000 personas. Ha logrado incorporar el proceso de análisis y revisión de incidentes y crear un entorno en el que los ejecutivos acuden a ellos para aprender de las revisiones de incidentes, creo que son mensuales. De hecho, está rastreando algunos de esos datos de los que hablé, sobre cuántas personas asisten a las reuniones, cuántas personas leen los informes y todo eso. Está observando cómo esto gana terreno dentro de la organización de CIO. Él está tomando los datos del extremo afilado y los está incorporando al negocio, y están comenzando a ver cuál es la realidad sobre el terreno. Me recuerda a los primeros días de DevOps, donde intentábamos conectar estos dos lados de la organización. Todavía veo mucho poder en construir una cultura en torno a estos análisis de incidentes, revelan tanto que, por lo general, a cierta distancia de lo que ocurre en el lado comercial de la casa, rara vez se ve. Hay una brecha que la gente tiene que salvar. Hay trabajo por hacer para alinear a esos dos grupos.

Rosenthal: Mencionaste dos formas de no hacerlo. Describiste un proceso un poco mejor para invertir en análisis de incidentes. Voy a publicar el documento de Howie, que es la opinión de una empresa sobre un mejor proceso para el análisis de incidentes.

Nash: El mejor proceso es el que usted crea para su propia organización. No hay una plantilla. No hay un foro. Eso también es muy frustrante. He observado que esto sucede en bastantes organizaciones donde simplemente comienzas a hacer esto, y un proceso que desarrollas si inviertes en esto, en aprender de los incidentes, será el que evoluciones, refines y cambies. trabajar para su empresa. Esa es la opinión de una empresa que es muy buena en esto. Eso tampoco significa que tenga que ser exactamente así. Sólo tienes que empezar.

Ver más presentaciones con transcripciones

Grabado en:

31 de agosto de 2023

por

Courtney Nash

Empresa Redis. La solución ideal de almacenamiento en caché y mensajería asincrónica para aplicaciones basadas en microservicios. Descargue el resumen de la solución ahora.