- Google SRE resume su experiencia elevando la confiabilidad desde sus inicios operando con centros de datos pequeños y scripts de Python, hasta un entorno que creció a más de 1,000 veces en escala de cómputo y más de 10,000 veces en escala de red
- En la respuesta a incidentes, la seguridad de las medidas de mitigación va antes que actuar rápido; un procedimiento de recuperación incorrecto puede ampliar fallas en cadena en vez de reducir el incidente
- Los casos de YouTube y Google Calendar muestran la necesidad de despliegues canary que limiten los cambios globales, un Big Red Button que permita revertir de inmediato y pruebas de integración que validen las rutas reales
- Cuando una dependencia crítica colapsa, como en el incidente de tokens OAuth de 2017, no solo se afecta a los usuarios, sino también al sistema interno de respuesta, por lo que se necesitan canales de comunicación de respaldo y degradación gradual
- Los despliegues frecuentes, la mitigación automatizada, los simulacros de recuperación ante desastres y la diversidad de hardware son principios prácticos para reducir el MTTR y evitar puntos únicos de falla en sistemas distribuidos complejos
Los cambios de escala que Google SRE vivió durante 20 años
- Hace 20 años, Google operaba dos centros de datos pequeños; cada uno tenía miles de servidores y dos enlaces de red de 2.4G conectados en forma de anillo
- En ese entonces, las operaciones dependían en gran medida de scripts de Python como
Assigner,AutoreplaceryBabysitter, y de archivos de configuración que incluían nombres de servidores individuales - Una pequeña base de datos de máquinas llamada MDB se usaba para organizar y mantener de forma continua la información de servidores individuales
- Hoy, la potencia de cómputo creció más de 1,000 veces y la red más de 10,000 veces, pero el esfuerzo operativo por servidor disminuyó y la confiabilidad del stack de servicios mejoró
- Las herramientas operativas evolucionaron de un conjunto de scripts a un ecosistema de servicios, y luego a una plataforma integrada que ofrece confiabilidad básica
Principios de respuesta surgidos del incidente de YouTube
- En 2016, YouTube sufrió un incidente global de 15 minutos por un bug en un sistema distribuido de caché en memoria, y se interrumpió la capacidad de servir videos
- Las medidas de mitigación deben estar alineadas con la gravedad del incidente
- Durante el incidente de YouTube, un procedimiento riesgoso de rechazo de carga (load-shedding) no solucionó el problema y provocó fallas en cadena
- Una mitigación riesgosa, en el mejor caso, resuelve el incidente; en el peor, funciona mal y prolonga el tiempo de afectación
- Incluso en una situación que parezca justificar saltarse los procedimientos estándar, primero hay que observar y evaluar la gravedad antes de elegir una acción
- Los mecanismos de recuperación deben probarse lo suficiente antes de una emergencia real
- Ejecutar por primera vez un procedimiento riesgoso de mitigación durante un incidente es como usar una escalera por primera vez mientras se evacua un incendio en un edificio alto
- Hay que verificar de antemano que el procedimiento de recuperación realmente haga lo necesario y que las personas responsables sepan cómo ejecutarlo
- La propia prueba también tiene el efecto de reducir el riesgo al realizar esa medida
- Todos los cambios deben limitar su alcance de impacto con despliegues canary
- Un cambio de configuración de caché dejó al servicio de YouTube gravemente paralizado durante 13 minutos por consecuencias no previstas
- Si el cambio global se hubiera desplegado gradualmente con una estrategia canary, el incidente podría haberse limitado antes de tener impacto global
- Como material relacionado, están el artículo sobre estrategia canary y el video de la charla en SREcon
Rollback y pruebas aprendidos del incidente de Calendar
- Los cambios riesgosos necesitan un Big Red Button definido de antemano
- Big Red Button es un mecanismo de seguridad simple y fácil de ejecutar que revierte la causa que generó un estado no deseado
- Hubo un caso en el que un ingeniero evitó por poco un incidente mayor al desconectar la computadora de escritorio antes de que el cambio se propagara
- Al planear despliegues importantes, se debe considerar “¿cuál es mi Big Red Button?”, y todas las dependencias del servicio deben contar con un mecanismo que pueda ejecutarse en una emergencia
- Como artículo relacionado, está Generic Mitigations
- Las pruebas unitarias no alcanzan; hacen falta pruebas de integración
- Las pruebas unitarias verifican que los componentes individuales funcionen como se espera, pero no reproducen por completo el entorno de ejecución ni los requisitos de producción
- Las pruebas de integración se usan para verificar si los trabajos y tareas pueden hacer cold start, y si los componentes, al trabajar juntos, crean el sistema deseado
- En el incidente de Calendar, la ruta de prueba era distinta de la ruta de uso real, así que aunque había muchas pruebas, no ayudaban a evaluar cómo funcionaría el cambio en la realidad
El incidente de tokens OAuth de 2017 y la continuidad operativa
- En febrero de 2017, tokens OAuth inutilizables hicieron que millones de usuarios cerraran sesión en dispositivos y servicios, y 32,000 dispositivos OnHub y Google WiFi realizaran un restablecimiento de fábrica
- Por las fallas de inicio de sesión, las solicitudes manuales de recuperación de cuentas aumentaron 10 veces, y a Google le tomó unas 12 horas recuperarse por completo del incidente
- La respuesta a incidentes necesita canales de respaldo separados de los canales principales de comunicación
- En ese momento, los equipos esperaban poder gestionar el incidente con Google Hangouts y Google Meet
- Pero con 350 millones de usuarios desconectados de dispositivos y servicios, no era adecuado depender de servicios de Google
- Se deben preparar y probar canales de comunicación de respaldo con dependencias separadas
- Los servicios deben seguir funcionando incluso en situaciones excepcionales mediante degradación gradual (graceful degradation)
- No basta con dividir la disponibilidad solo entre “totalmente normal” y “totalmente interrumpida”
- Mantener una funcionalidad mínima incluso en modo degradado puede ofrecer una experiencia de usuario más consistente
- La degradación puede incluso no ser visible para el usuario, y los servicios deben diseñarse para seguir operando incluso en situaciones excepcionales
Desastres, automatización, despliegues y diversidad de hardware
- La resiliencia ante desastres y las pruebas de recuperación son elementos clave de una estrategia de continuidad del negocio
- Las pruebas de resiliencia verifican si un servicio o sistema puede resistir fallas, latencias e interrupciones
- Las pruebas de recuperación verifican si el servicio puede volver a un estado normal después de un apagado completo
- Como en Weathering the Unexpected, también hay que contemplar situaciones extremas como desastres naturales o ciberataques
- También son útiles actividades en las que el equipo revisa escenarios en formato de juego de mesa, como “¿qué pasa si una parte de la conectividad de red se corta de forma inesperada?”
- Para incidentes con señales claras, la automatización de la mitigación puede ser un medio para reducir el MTTR
- En marzo de 2023, varios equipos de red fallaron casi simultáneamente en múltiples centros de datos, causando una pérdida de paquetes generalizada
- Durante este incidente de 6 días, alrededor del 70% de los servicios se vieron afectados en distintos niveles según la ubicación, la carga del servicio y la configuración al momento de la falla de red
- Porcentaje de servicios afectados: {p:70}
- Si la señal de que ocurrió una falla específica es clara, se pueden iniciar automáticamente medidas de mitigación manuales para reducir el MTTR
- A veces conviene evitar primero el impacto al usuario y luego analizar la causa raíz
- Cuanto más largo es el intervalo entre despliegues, más difícil se vuelve juzgar la seguridad de un cambio
- En marzo de 2022, una falla del sistema de pagos impidió que los clientes completaran transacciones, y el Día de la Comunidad de Pokémon GO se pospuso
- La causa fue la eliminación de un único campo de base de datos; como el uso de ese campo se había eliminado del código, parecía un cambio que debía ser seguro
- Sin embargo, por el ciclo lento de despliegue de algunas partes del sistema, el sistema en vivo todavía usaba ese campo
- En sistemas complejos de múltiples componentes, las demoras largas en los despliegues dificultan mucho evaluar la seguridad de un cambio específico
- Con pruebas adecuadas y despliegues frecuentes, se pueden reducir las fallas inesperadas de este tipo
- Una sola versión global de hardware puede convertirse en un punto único de falla
- Encargar una función crítica a un solo modelo de equipo puede simplificar las operaciones y el mantenimiento
- Pero si ese modelo presenta un problema, esa función crítica deja de ejecutarse
- En marzo de 2020, un equipo de red con un bug zero-day no descubierto expuso el bug ante un cambio en los patrones de tráfico y, como el mismo modelo y versión se usaban en toda la red, se produjo una interrupción regional considerable
- Como había múltiples backbones de red, fue posible enviar el tráfico de alta prioridad por rutas alternativas que seguían funcionando y evitar una interrupción total
- Los bugs potenciales en infraestructura crítica pueden permanecer ocultos hasta que ocurre un evento aparentemente inofensivo; mantener infraestructura diversa puede marcar la diferencia entre una interrupción problemática y una interrupción total
1 comentarios
Comentarios de Hacker News
El texto es excelente y parece ampliamente aplicable. No hay nada que suene a “esto solo funciona en Google”
Los canales de comunicación, los canales de respaldo, y hasta el respaldo del respaldo son realmente importantes. En Netflix, al elegir proveedores para sistemas usados durante incidentes, siempre verificaban que no estuvieran sobre AWS; y en reddit tenían un IRC de respaldo en un servidor de la oficina por si el IRC principal fallaba
También escuché que Google tenía un servidor IRC de respaldo en AWS, aunque eso podría ser solo una leyenda. El punto clave es asegurar un canal de comunicación auxiliar lo más independiente posible de tu propia infraestructura
Ese equipo estaba en una ruta crítica, así que si nos llamaban por culpa de nuestro sistema, no era nada improbable que junto con Google Meet también hubiera caído Google.com. Gmail tampoco serviría para correo, Google Fi tampoco para los teléfonos de trabajo, y hasta el ISP de casa podía ser Google Fiber/Webpass, así que hacía falta una capa de respaldo adicional
Por eso Google sí tiene un servidor IRC de respaldo para comunicaciones. No diré dónde está, pero justamente por esa razón está puesto explícitamente fuera de la infraestructura de Google
En cuanto a que “es ampliamente aplicable y no algo exclusivo de Google”, una cosa que casi no he visto en otros lugares era una sala de pánico operacional: un cuarto seguro con una VPN de respaldo hacia producción
Un día el SAN de producción empezó a fallar, el centro de datos on-premise se cayó y con él también Atlassian. No había Jira ni Confluence, probablemente tampoco CI/CD, y en vez de procedimientos de recuperación bien documentados solo quedaba conocimiento tribal
La gente estaba furiosa, y con razón. Es realmente peligroso poner en la misma canasta los sistemas orientados al cliente y los sistemas de infraestructura
Al menos así era hace dos años, cuando yo todavía trabajaba ahí
Algún día me gustaría escuchar la solución al problema de un arranque en frío completo. Las empresas con un gran stack propio tienen dependencias circulares en su infraestructura central
Las redes definidas por software necesitan que cierto software esté arriba para volver a enrutar paquetes, las máquinas sin disco necesitan almacenamiento para arrancar, y los servicios de autenticación necesitan acceso al almacenamiento para bootstrapear la autorización de seguridad
Hoy esto se maneja operando varias regiones independientes, de modo que un centro de datos completamente apagado se inicializa desde infraestructura ya existente. Pero nunca he oído que hayan vuelto a levantar todo el stack desde un apagón total
Incluso cuando Facebook destrozó por completo su red de producción hace unos años, las máquinas seguían encendidas y todavía quedaba cierta conectividad interna. Si algo como una gran tormenta solar tumbara la red eléctrica global por mucho tiempo y hasta agotara todos los generadores, no hay garantía de que nubes como AWS o GCP necesariamente vuelvan a la vida
Supongo que deben existir pequeños centros de datos dedicados con excelente energía de respaldo y capacidad de aislamiento total frente a sobretensiones de la red eléctrica
En la parte alta del stack era útil para rastrear dependencias que un autor de librerías hubiera agregado silenciosamente, y en la parte baja ayudaba a garantizar que las piezas que debían estar en la base realmente estuvieran en la base
También hacían levantamiento y apagado automatizado de clústeres virtuales para que los procedimientos documentados no se volvieran obsoletos, y en mis seis años como SRE vi cómo esos procedimientos bajaron de 90 días a menos de 1 hora
Para cosas como la gestión global de claves de cifrado, que requieren objetos físicos, también se practicaba regularmente reiniciar desde cero, y los ejercicios anuales de DiRT buscaban verificar que ninguna persona, equipo u oficina fuera una condición indispensable para la continuidad del sistema
Si empiezas tarde, duele muchísimo, pero si lo haces desde el principio te acostumbras rápido y detectas temprano cambios que rompen algo o dependencias raras
Esto también aplica al hardware. La arquitectura cambia para soportar que algo sea desconectado o reinicializado. Se necesita más automatización, control de versiones y gestión de cambios, y eso no solo ayuda a prevenir incidentes y recuperar rápido, sino que además vuelve todo el trabajo más ágil y simple. Es un gran cambio cultural
Hasta donde recuerdo, parte del enfoque se considera información sensible, así que no entraré en más detalle
También sería interesante saber qué red eléctrica ha hecho más arranques en frío. Idealmente, ese lugar ya debería ser bueno en ello. Supongo que podría ser en el Caribe o en algún sitio de África
Aunque un arranque en frío de una red pequeña, como una isla remota con un generador diésel y energía solar, quizá sea demasiado fácil como para servir de buen caso de estudio
Está claro que Internet en sí no puede hacer arranque en frío como una red eléctrica de CA. Hay demasiados AS. Si uno se detiene a pensar un momento qué significa AS, se entiende por qué un arranque en frío coordinado y ensayado es imposible
Para profundizar más en este tema, estoy casi terminando Building Secure and Reliable Systems de Google, y no es una lectura ligera, sino más bien un verdadero libro de texto
Es un libro bastante interesante, y mucho de su contenido parece sentido común, pero como dice esa expresión de que el “sentido común” en sí es una contradicción, me sirvió para refrescar todo ese conocimiento de una sola vez
Últimamente he escuchado que algunas empresas han desarmado sus organizaciones de SRE y movido a sus integrantes a equipos de SWE. Se rumorea que LinkedIn, Adobe y Robinhood hicieron eso
Eso me hace pensar si SRE es un subproducto de la economía de burbuja donde abundaba el dinero fácil. ¿No será posible operar sin gastar tanto en tener un equipo de SRE por separado?
Igual que los administradores de sistemas o los testers de QA casi desaparecieron y muchas de sus funciones pasaron a los equipos de desarrollo de software, me pregunto si SRE seguirá existiendo dentro de 10 años
Pero ahora mismo siguen los despidos, así que no hay muchas empresas preocupadas por eso. La tendencia de la industria de poner a los desarrolladores a resolver problemas aunque no sean su especialidad no va a desaparecer, y será aún más visible en épocas de recesión
Los desarrolladores full stack son un buen ejemplo de cómo se combinan dos roles sin pagar el doble
Aun así, creo que el resto del punto sigue siendo válido. Hoy en día, por DevOps, el rango de habilidades que se les exige a los desarrolladores se ha ampliado y se superpone bastante con SRE. Es muy probable que las empresas reduzcan los equipos de SRE y distribuyan esa responsabilidad entre los desarrolladores
Otra razón importante es la automatización. Si uno pasa tiempo leyendo el sitio enlazado, se da cuenta de que en los primeros años de Google los SRE hacían mucho trabajo manual, como revisar gráficas y desplegar manualmente
En ese entonces, ni siquiera Google tenía suficiente automatización de sistemas, así que los SRE eran indispensables. Si ves la historia de Sisyphus https://www.usenix.org/sites/default/files/conference/protec..., se puede entender hasta cierto punto cómo quedó garantizada la estabilidad laboral de los SRE cuando Google fracasó al introducir por primera vez una automatización estandarizada
No tiene mucha lógica pasarle a otra persona la operación del software que uno mismo escribió. Basta con poner a los SWE de guardia. Si creen que el trabajo manual es lo mejor, que lo hagan ellos mismos, y si ese es su nivel, deberían despedirlos por ser ingenieros mediocres
Es raro que las entrevistas sean tan exigentes y aun así no sepan cómo funciona la computadora en la que programan. Cómo funciona un sistema operativo, por ejemplo, es algo que hasta se ve en pregrado, y también es extraño que eso se termine delegando mediante tantos puestos y títulos a gente que en su mayoría viene de ser administradores de sistemas autodidactas
Todos los buenos SWE que conozco sabían cómo funcionan los sistemas operativos, las computadoras y las redes
El trabajo que hoy hace SRE en automatización general, provisión de herramientas de desarrollo y mejora de la experiencia del desarrollador se está moviendo a los equipos de plataforma. Creo que el rol va a cambiar mucho en el futuro
Un solo equipo de SRE puede apoyar a varios equipos de desarrollo, y muchas veces los equipos de desarrollo casi no dedican tiempo a aspectos de infraestructura compleja o sistemas distribuidos. Simplemente no son áreas que les preocupen en el día a día
Por eso tiene sentido que exista una organización de infraestructura que se mueva como una unidad distinta de los equipos de desarrollo especializados. Ya sea que lo llames SRE, equipo SRE SWE o simplemente infraestructura, a cierta escala empiezan a surgir muchas preocupaciones transversales entre equipos, y separarlo así termina siendo más barato
Si tienes SRE dedicados, hay verdaderos expertos en operación, sistemas relacionados, herramientas y alertas, y además existe una responsabilidad clara sobre los resultados. Pero como no son dueños completos del sistema que mantienen, eso puede generar problemas organizacionales
Puede pasar algo como “queremos lanzar X pero SRE se opone”, o al revés, y también puede ocurrir que la gente que no es SRE termine sin hacerse responsable de código que es difícil de soportar
En cambio, un equipo de ingeniería sin SRE puede reducir ese tipo de problemas organizacionales y sociales, pero la confiabilidad operativa pasa a ser solo una prioridad entre muchas
En la práctica, creo que muchas empresas están decidiendo que la confiabilidad no es tan importante como resultado de negocio. Sobre todo cuando el costo de oportunidad de desarrollar funcionalidades se vuelve más alto
La mitigación automática es algo que de verdad hay que pensar muy bien. En 30 años de carrera he visto varias veces que la mitigación automática empeora el problema. Por eso hay que evaluar con cuidado si la autocuración realmente es necesaria
En 2014 hicimos una solución interna de reportes de crashes móviles, y parte del backend corría en un solo servidor con Redis como punto único de falla. El proceso de failover era semiautomático, así que una persona tenía que confirmar que la alerta era válida antes de iniciarlo
Si se caía, no había pérdida económica real; en el peor de los casos, los desarrolladores de apps móviles se incomodaban un rato. En 10 años de operación, las veces que hubo que hacer failover se podían contar con dos dedos
Aun siendo un sistema sin SLA, tuvo mejor uptime que otros sistemas internos mucho más importantes
En cambio, basta ver los casos de GitHub: https://github.blog/2023-05-16-addressing-githubs-recent-ava..., https://github.blog/2018-10-30-oct21-post-incident-analysis/, https://www.datacenterknowledge.com/archives/2012/12/27/gith...
Claro, GitHub opera a una escala mucho mayor. El punto es que la redundancia y la mitigación automática agregan complejidad y, por definición, suelen actuar en situaciones imprevistas casi sin haber sido probadas
Así que hay que considerar el SLA y el costo de una caída, y equilibrarlos con la complejidad extra que se agregará para evitarla. Mi primera lección fue alrededor de 1998, cuando conectamos dos NetApp en una configuración de alta disponibilidad y, al fallar una, terminó dañando también todos los discos de la otra
Por esa misma época vi algo parecido con dos firewalls Cisco PIX, y desde entonces siempre he sido cauteloso con la alta disponibilidad y con el failover y la mitigación automáticos
Tengo curiosidad por cómo manejan en la práctica el gran botón rojo y la degradación gradual intencional del servicio. En particular, me interesa cómo garantizan que sigan funcionando incluso mientras el sistema está teniendo problemas
Por ejemplo, si usan feature flags basados en base de datos, me pregunto qué hacen cuando la propia base de datos o la API de acceso está sobrecargada
O si usan flags estáticos de arranque, como variables de entorno, también me pregunto cómo garantizan que el despliegue ocurra lo bastante rápido. O si existe un enfoque completamente distinto
Aunque no se use redundancia en algunas partes del camino crítico, puede ser mejor si el sistema es lo bastante simple como para caber en la cabeza de todos los responsables de mantenimiento y es fácil de reiniciar o revertir
Pero cuando una empresa empieza a prometer cosas como “five nines de disponibilidad”, entonces sí se necesita cierto nivel de complejidad para diseñar un sistema que permita seguir desarrollando y mejorando sin romper esa garantía
En Google, si se consideraba que un clúster específico no estaba saludable, era común hacer un “backend drain”, y había sistemas en la capa de API/balanceador de carga para procesarlo rápidamente
En otros lugares también he visto manejarlo con flags a nivel de aplicación. Hacer
kubectl editclaramente no es ideal, pero funcionóPrimero, hay que mantenerlo simple. Lo mejor es algo como una verificación sencilla del flag, sin lógica sofisticada ni almacenes de datos complejos
Segundo, hay que ponerlo lo más cerca posible de la fuente, pero sin confiar demasiado en el cliente. Puede haber versiones viejas, retrasos de propagación o bugs, así que conviene poder activar el modo degradado tanto del lado cliente como del lado servidor; y si solo se puede uno, es mejor que sea del lado servidor
Tercero, hay que probarlo seguido con tráfico real. No confíes en entornos de prueba: hacen falta pruebas periódicas a pequeña escala, como con 0.1%, y pruebas grandes programadas. Si no se ha probado, no va a funcionar cuando se necesite, y si funcionó hace un año, probablemente hoy ya no. Un mecanismo no probado puede causar más daño que la avería que intenta resolver
Por ejemplo, supongamos que agregas a Hacker News una nueva función para mostrar fotos de perfil junto a los comentarios. Como era de esperarse, hiciste todo con microservicios, así que el generador de páginas del frontend hace llamadas al servicio de perfiles, y el servicio de perfiles consulta y devuelve la ubicación de la imagen
Como parte del plan de lanzamiento, documentas un procedimiento de gran botón rojo a seguir si el nuevo componente sobrecarga el servicio de perfiles o el almacenamiento de imágenes. Es decir, ejecutas un comando en la capa de red para limitar la tasa de solicitudes salientes de mi servicio, y en una emergencia probablemente lo pondrías en 0
Las consultas fallan, pero el generador de páginas está diseñado para degradarse gradualmente y seguir renderizando el texto de los comentarios sin la foto de perfil
Esto no es un documento de diseño real ni un consejo sobre qué construir o cómo hacerlo; es solo un dibujo con crayones para ilustrar la idea
Lo he hecho con CDB (constant database) de djb, y también he visto casos con archivos de configuración JSON consultados vía API o usando dbm/gdbm/Berkeleydb/leveldb
Este enfoque también se puede extender a otros grandes botones rojos. No es elegante, pero varias veces he operado servicios que decidían si ofrecer health checks revisando la existencia de un archivo. Sacar un nodo de la rotación del balanceador era tan fácil como crear un archivo
La clave es que, si la base de datos falla, el sistema use por defecto la última configuración válida conocida
De verdad quiero enfatizar la frase “los mecanismos de recuperación deben probarse completamente antes de una emergencia”. En Google terminé siendo SRE de manera inesperada y, como alguien que se volvió conocido en toda la empresa por usar mal una doble negación, esto es algo sumamente importante que hay que hacer bien desde el principio
Si algún Googler siente curiosidad, puede buscar mi nombre de usuario internamente para descubrir cómo logré causar un impacto imposible de medir
La forma más barata de evitar incidentes es detectarlos temprano en el ciclo de vida. Los bugs de software se parecen a los insectos reales. Al principio son huevos, es decir, la idea del cambio; la ninfa recién salida es el primer POC. Para cuando llegan al entorno de producción, ya son adultos
¿Que no hay una etapa antes del adulto? Sí. Una aplicación tiene que pasar por varias etapas antes de madurar. Es mucho más barato encontrar un bug antes de que crezca por completo y empiece a poner huevos
Si los despliegues canary son difíciles y también hay problemas con los rollbacks, entonces hay que agregar más pruebas antes del despliegue a producción. Hay que encontrar los bugs lo antes posible, por todos los medios posibles: linters, pruebas unitarias, pruebas de extremo a extremo, profilers, monitores sintéticos, réplicas de producción de solo lectura, pruebas de rendimiento, etc.
Los feature flags, la compatibilidad hacia atrás y demás también sirven, pero nada le gana a Shift Left
Si te interesa una lista parecida desde la perspectiva de alguien que hizo SRE durante 15 años en FinTech, banca, hedge funds y criptomonedas, recomiendo este texto: https://x.com/alexpotato/status/1432302823383998471?s=20
Un adelanto: “25. Si tienes un motor de reglas donde crear una regla nueva es más fácil que encontrar una regla existente usando condiciones de filtro, al final terminas con un montón de reglas duplicadas”
Eso de “el ingeniero que envió un cambio que casi provoca una caída desconectó la computadora de escritorio antes de que el cambio se propagara y así apenas evitó un incidente mayor”, ¿qué significa exactamente?
Como resultado, los SWE de infraestructura se la pasaban escribiendo CLIs tontísimos todo el día en vez de crear botones de verdad. Para cuando me fui, eso ya estaba cambiando bastante
Creo que Google debería hacer más públicos sus incidentes internos. Este en particular era muy famoso dentro de la empresa
Incluso a una escala enorme, las herramientas de shell y los clientes CLI de RPC pueden llegar bastante rápido a máquinas de todo el mundo
psshFue hace 10 años, así que no sé si todavía lo hacen así, pero era sorprendentemente rápido. Podría haber sido algo de ese estilo
Pero hace 20 años era más común, y hasta hoy todavía puede pasar en organizaciones pequeñas