¿Con qué frecuencia se cometen errores graves en Piper en Google, que terminan interrumpiendo el trabajo diario de una gran cantidad de desarrolladores de Google?

Solo trabajé en Google durante 7 meses (2 pasantías), pero dado que me pidieron que respondiera, proporcionaré mi perspectiva: los errores graves que perturban a muchos ingenieros de Google son bastante raros.

Solo recuerdo que sucedió una vez. Lamentablemente, escribí ese error, que pasó desapercibido en la revisión del código, y requirió una sala de guerra con varios equipos trabajando para solucionar las consecuencias lo antes posible.

En comparación, los errores graves son mucho más frecuentes en Facebook. Creo que esto es por diseño. La filosofía de desarrollo de Google y Facebook es bastante diferente. Los ingenieros de Google pasan mucho más tiempo en la revisión del código (tanto para verificar el código como para exigir pruebas) y herramientas (por ejemplo, sistemas de monitoreo). Facebook todavía está bajo la influencia del mantra Mover rápido y romper cosas (lo bueno es una velocidad de desarrollo mucho más rápida).

Las herramientas de Google son de primera categoría, muy por encima de cualquier otra cosa que haya visto en otros lugares. El problema causado por el error que mencioné fue rápidamente detectado por los sistemas de monitoreo.

Una mala confirmación que rompe la compilación o tiene malas pruebas se revierte rápidamente si no se corrige rápidamente. Los ingenieros de Google se enorgullecen de las buenas pruebas y las pruebas / compilaciones ecológicas (lo que significa que no fallan las pruebas debido a una mala confirmación).

PD: cuando digo que solo lo vi una vez, significa 1 error que afecta a mi división, no a todo Google (de lo que sería ajeno, a menos que fuera algo catastrófico que afectara a toda la empresa).

No he estado en Google el tiempo suficiente para decir con qué frecuencia sucede (aunque supongo que esa declaración en sí misma da un límite superior; no puede suceder con demasiada frecuencia, ¡o tendría suficientes datos para estimar una frecuencia! ) Supongo que puedo recordar dos casos en los que un commit rompió la compilación o la prueba de una fracción significativa del árbol de compilación por orden por hora; en ambos casos hubo un buen post-mortem posterior que identificó el atajo que se había implementado para sortear los mecanismos que normalmente evitan que esto suceda, y concluyó que el atajo no había sido realmente una buena idea , y se eliminaría (o se haría significativamente más seguro).

Tenga en cuenta que en ninguno de los casos fue realmente algo malo. 🙂 Probablemente cada uno causó nominalmente miles de millones de dólares en tiempo perdido de ingeniero, pero en ambos casos la gente se divirtió recitándose mutuamente en hilos de mensajes, recordando los saltos de compilación en conciertos anteriores, haciendo memes lindos, etc. Supongo que la mejora general de la productividad de unos pocos miles de ingenieros que tuvieron un breve descanso no programado probablemente superó la interrupción a largo plazo.

(¡O tal vez solo disfruto un poco de caos!)

Creo que hay informes aquí y allá sobre toda la inteligencia normal que tienen los sistemas de desarrollo de Google para evitar que esto suceda en el curso normal de la operación (cada confirmación se prueba hipotéticamente antes de que se permita, natch). Y el lugar también es lo suficientemente flexible como para permitir que se omita donde parece requerido (y para poder deshacer esa decisión cuando una autopsia lo solicita).