¡El 16 de enero ocurrió el incidente y recién el 10 de marzo publicaron el informe de post-mortem! Entre medio, ¿qué demonios estuvo haciendo oficialmente durante esos 53 días? ¡Esa era mi gran duda antes de ver el Post-Mortem!
Copio los puntos de tiempo del post-mortem en mi libreta: el ataque ocurrió el 16 de enero; más tarde esa misma noche se suspendió el servicio de puentes (bridge). A finales de enero se completó la consolidación de fondos y la verificación de las direcciones afectadas. Y el 10 de marzo se publicó el post-mortem completo. Antes de copiar el texto de $DUSK , revisé también las marcas de tiempo de actualización en la página de publicación para confirmar que no se hubiera retirado ninguna versión intermedia. Me detuve en el tercer punto: en esos 53 días, la entidad oficial solo actualizó el estado dos veces: una el día del incidente y otra el día en que publicaron el post-mortem.
Abrí el calendario y lo conté: del 16 de enero al 10 de marzo hay 53 días, con 2 actualizaciones. En promedio, se movieron cada 26,5 días. Esa ronda de finales de enero —la consolidación de fondos y la verificación de direcciones— todo quedó escrito después en el post-mortem; en ese momento, hacia afuera no había ni una sola palabra. Yo dividí esos 53 días en cuatro bloques: la congelación a nivel de horas, la verificación a nivel de días, la causa raíz a nivel de semanas, y el post-mortem más auditoría interna ocupando más de un mes. Los tres primeros bloques quedaron vacíos; solo en el último se pronunciaron. Esa es la cuenta de tiempo que saqué, y también fue exactamente lo que al principio me parecía raro.
Pero si desglosamos esos cuatro bloques, el silencio no equivale a negligencia. @Dusk , que la congelación sea de nivel horas, significa que el mismo día del incidente cortaron la expansión del riesgo; que la verificación sea a nivel días, significa que no se retrasaron conciliaciones una por una; y que la causa raíz sea de nivel semanas, significa que las conclusiones pueden verificarse, no son “a ojo”. Cada tramo tiene acciones claras, solo que no se actualizaron al exterior. También comparé cómo se gestionaron los eventos recientes de puentes: algunos proyectos borran el tuit al día siguiente del incidente; otros arrastran seis meses y publican una declaración sin muchos detalles; y otros simplemente no responden. Después de comparar, aún más claro: el proceso de gestión es el material base de la confianza, y este post-mortem es de las pocas veces en que realmente desglosan por completo la línea de tiempo, la causa raíz y las medidas.
Así que ahora voy a vigilar una cosa: la próxima vez que ocurra algo, desde el momento del incidente hasta la publicación del post-mortem, ¿habrá actualizaciones de proceso en el medio? La frecuencia de actualización es la medida de la transparencia. Por mucho que se diga con la boca, no hay nada que valga más que la honestidad de las marcas de tiempo. #dusk
Copio los puntos de tiempo del post-mortem en mi libreta: el ataque ocurrió el 16 de enero; más tarde esa misma noche se suspendió el servicio de puentes (bridge). A finales de enero se completó la consolidación de fondos y la verificación de las direcciones afectadas. Y el 10 de marzo se publicó el post-mortem completo. Antes de copiar el texto de $DUSK , revisé también las marcas de tiempo de actualización en la página de publicación para confirmar que no se hubiera retirado ninguna versión intermedia. Me detuve en el tercer punto: en esos 53 días, la entidad oficial solo actualizó el estado dos veces: una el día del incidente y otra el día en que publicaron el post-mortem.
Abrí el calendario y lo conté: del 16 de enero al 10 de marzo hay 53 días, con 2 actualizaciones. En promedio, se movieron cada 26,5 días. Esa ronda de finales de enero —la consolidación de fondos y la verificación de direcciones— todo quedó escrito después en el post-mortem; en ese momento, hacia afuera no había ni una sola palabra. Yo dividí esos 53 días en cuatro bloques: la congelación a nivel de horas, la verificación a nivel de días, la causa raíz a nivel de semanas, y el post-mortem más auditoría interna ocupando más de un mes. Los tres primeros bloques quedaron vacíos; solo en el último se pronunciaron. Esa es la cuenta de tiempo que saqué, y también fue exactamente lo que al principio me parecía raro.
Pero si desglosamos esos cuatro bloques, el silencio no equivale a negligencia. @Dusk , que la congelación sea de nivel horas, significa que el mismo día del incidente cortaron la expansión del riesgo; que la verificación sea a nivel días, significa que no se retrasaron conciliaciones una por una; y que la causa raíz sea de nivel semanas, significa que las conclusiones pueden verificarse, no son “a ojo”. Cada tramo tiene acciones claras, solo que no se actualizaron al exterior. También comparé cómo se gestionaron los eventos recientes de puentes: algunos proyectos borran el tuit al día siguiente del incidente; otros arrastran seis meses y publican una declaración sin muchos detalles; y otros simplemente no responden. Después de comparar, aún más claro: el proceso de gestión es el material base de la confianza, y este post-mortem es de las pocas veces en que realmente desglosan por completo la línea de tiempo, la causa raíz y las medidas.
Así que ahora voy a vigilar una cosa: la próxima vez que ocurra algo, desde el momento del incidente hasta la publicación del post-mortem, ¿habrá actualizaciones de proceso en el medio? La frecuencia de actualización es la medida de la transparencia. Por mucho que se diga con la boca, no hay nada que valga más que la honestidad de las marcas de tiempo. #dusk