Thread by @zorroperu

Voy a traducir un (EXTENSO) hilo de un ingeniero de plataforma (@MosquitoCapital), que explica por qué es grave lo que está sucediendo en Twitter, y por qué una plataforma que funciona 24/7 que se queda de pronto sin personal corre peligro (1/n)
#ChauTwitter #AdiosTwitter

He oído a mucha gente preguntar "¿Por qué todos creen que Twitter está perdido?"
Como admin. de sistemas e ingeniero de confiabilidad, quiero detallar algunos de los escenarios que pondrán en peligro la integridad de Twitter en las semanas que vienen. (2/n)

Como contexto, personalmente he visto algunas variantes de cada uno de estos problemas plantear un riesgo real a aplicaciones con más de un billón de usuarios. Incluso he causado por error alguno de los más técnicos, y estado envuelto en la solución de muchos más. (3/n)

1) Se llenan los discos duros. No tienen idea de lo común que es que a un servidor le suceda algo así, causando fallas en cascada entre sistemas, incluso para sistemas tolerantes a fallos y bien mantenidos. ¿Dónde está el servidor? ¿Qué lo está llenando? ¿Quién averigua? (4/n)

2) Problemas físicos con la red se pueden traer abajo un Data Center. A pesar de que Twitter posee todos sus sistemas internamente, he visto suceder cómo un árbol puede caerse y tumbar una fibra óptica crítica durante un evento importante. (5/n)

3) Código con problemas puede traerse abajo la plataforma. Prevenir eso era mi trabajo diario, y les puedo decir que es uno de los escenarios más atemorizantes para un equipo de Ingeniería de Confiabilidad de Plataforma, y con mayor razón para uno sin gente y cansado. (6/n)

4) Código con problemas puede traerse abajo la plataforma, y a la vez evitar que sea posible reemplazarlo por código bueno. Pesadilla absoluta. Cuando algo como esto sucede, todos deben participar. Sin un profundo conocimiento, podría ser imposible de recuperar. (7/n)

5) Evento (SEV) Catastrófico Misterioso. Repentinamente, nada funciona. Las alertas en rojo. Todo se fue al cuerno. Y no hay pistas de por qué. Hora de llamar a los vaqueros. Equipos cuyos nombres terminan en "Foundation". ¿Quiénes son? ¿Cómo haces para llamarlos? (8/n)

6) Se jodió la Base de Datos. Esta es grave. Un incendio. ¿Quién es el experto aquí? (9/n)

7) Alguien, hipotéticamente digamos que @wongmjane, encuentra una vulnerabilidad crítica en tu app iOS en Producción. Necesitas un parche, RÁPIDO. Y tener un equipo de expertos en convencer a la burocracia de Apple de lanzar la actualización rápidamente. Lo tienes, ¿no? (10/n)

8) Alguien descubre que es posible leer los DMs de todo el mundo, tan sólo con cargar una URL específica. Esto es un Evento Crítico tipo 1, masivo. Necesitas gente que entienda en profundidad cómo funcionan tus abstracciones de seguridad y cómo arreglarlas. (11/n)

9) La plataforma se cae a las 4 am. La gente de guardia no tiene idea de qué está mal. Necesitas un IMOC (Gestor de Incidentes de Guardia) que sepa a quién despertar y por qué. Alguien que entienda todos los sistemas, pueda comunicar rápidamente y coordinar esfuerzos. (12/n)

10) El "sistema que encuentra otros sistemas" internamente se cae. Ninguno de tus sistemas pueden hablar entre sí. La plataforma y todas tus herramientas fallan inmediatamente. Y las necesitas para revertir los cambios, pero están JODIDAS. ¿Puedes resolverlo sin personal? (13/n)

11) 5 pm del viernes. Todas las alertas se ponen en rojo. Los servidores web empiezan a reiniciarse en cascada. Los discos duros se han estado llenando desde el miércoles. Múltiples sistemas entrelazados han recibido cambios desde entonces. ¿Te atreves a deshacer cambios? (14/n)

12) Mierda. Te atreviste a deshacer uno de los cambios. Ahora todas las cuentas privadas y sus respectivos tweets son visibles para todo el mundo. Algunas personas literalmente serán agarradas a machetazos por sus publicaciones. Son las 9 pm. ¿A quién vas a llamar?(15/n)

13) El sistema que garantiza que los cambios al servidor son seguros está fallando. Hay 30,000 cambios pendientes esperando ser revisados. Una de las pruebas es la culpable. ¿Sabes cómo encontrarla? Ah, es el Mundial. Y la plataforma está caída. (16/n)

14) Un usuario en Filipinas está a punto de publicar Pornografía Infantil. NO PUEDES PERMITIR que ese contenido se mantenga en línea. ¿Tienes empleados en conexión con la policía de Filipinas? ¿Tu sistema de moderación de contenido funciona? ¿Tienes moderadores siquiera? (17/n)

15) El FBI desea revisar los DMs de alguien que potencialmente puede cometer el 11/9 Parte 2: Versión Atómica. ¿Tienes un sistema para darles acceso? ¿Se los das? ¿Cómo sabes si realmente son ellos? (18/n)

16) Les das acceso. Ahora alguien de un país conocido por atentar contra los Derechos Humanos te toca la puerta. Parecen tener una orden judicial válida. ¿Los dejas ver los DMs? ¿Puedes argumentar por qué? Espero que sí, para cuando estés un juicio en la corte de DDHH (19/n)

17) Otro país te exige que los datos de sus ciudadanos estén almacenados localmente en su territorio. ¿Tienes expertos en políticas de ese país? ¿Tienes muchos abogados "bien motivados"? ¿Tienes siquiera un equipo de infraestructura que sabe cómo hacer lo que te piden? (20/n)

18) GDPR. Violaste la norma. Tomó un equipo de cientos de ingenieros, abogados, expertos, diseñadores y gerentes durante meses de "ingeniería salvaje" para lograr cumplirla en principio. ¿Puedes solucionarlo? Te aseguro que las consecuencias de no hacerlo serán graves. (21/n)

19) Una vez al día, todos los días, a las 12:13 am, un servicio específico se pone terriblemente lento. No parece estar causando problemas, pero sí parece ir empeorando. ¿Asignas a un Ingeniero de Plataforma para que lo revise? ¿Sigues teniendo alguno? (22/n)

20) El servicio que usas para encontrar otros servicios funciona bien, pero uno de tus mejores ingenieros hace unos cálculos y te confirma que no soportará más usuarios dentro de poco. Y justo tú querías lanzar un nuevo servicio X. ¿Lo reescribes? ¿O qué? (23/n)

21) Decides reescribirlo. 8 meses después (ja ja, seguro) tu nuevo sistema está listo. ¿Quién coordina la migración? ¿Realmente entienden sistemas complejos? ¿Son buenos gestionando gente? ¿Son efectivos? ¿Tienen el conocimiento de dominio necesario? (24/n)

22) Acabas de contratar un (aparentemente) gran director de ingeniería de Microsoft. Lentamente, la productividad disminuye y el desgaste se dispara. El director jura que todo está bien. Si lo despides, de pronto uno de tus vicepresidentes quedará sobrecargado. ¿Qué hacer? (25/n)

23) Un ingeniero acaba de lanzar un comando que reinició todos los servidores. Oops, pero no usó --slow. Ahora todas las cachés están vacías y las bases de datos revientan instantáneamente por exceso de carga, se reinician y vuelven a morir. ¿Cómo se soluciona? (26/n)

24) Mundial de Fútbol. Es EL evento definitivo. Teníamos equipos de observación del tráfico de la plataforma. La cantidad que podías obtener en una semana es sorprendente. Prueba cada sistema que tienes en sus límites. Si alguno cae, reza para que no sea en cascada. (27/n)

25) Noche de Año Nuevo, Costa Este de USA. Cada año. Sentado afuera de la oficina, con los fuegos artificiales en la distancia, llamando desesperadamente a la Guardia de Video. TODOS publican videos de sus fuegos artificiales. Eso llena las redes y discos al máximo. (28/n)

26) Ya lo mencioné, pero... Pornografía Infantil. Si se maneja inapropiadamente, acabarás frente al Congreso, a los jueces, los noticieros, y lugares donde no habrás querido estar si diriges una red social. (29/n)

27) Seguridad física en las oficinas. Los guardias de seguridad tienen largas listas de "locos" que memorizan. Gente que quiere matar a Zuck. Al estilo ritual satánico, con velitas y todo. Se aparecen en la oficina todo el tiempo. ¿El equipo de seguridad está listo? (30/n)

28) Genocidio. La gente usa tu plataforma para orquestar asesinatos en masa, al estilo machetes y antorchas. Y rápido. Jodidamente rápido. Necesitas estar preparado desde antes. Si no tienes un equipo capaz de manejar y detener esto, acabarás enjuiciado en La Haya. (31/n)

29) Rebelión. Millones de personas usan tu plataforma para orquestar rebeliones contra sus gobiernos. ¿Usas las herramientas del #28 para detenerlos? ¿Les permites continuar? ¿Cómo decides? ¿Y si la próxima semana sucede en un país donde no estás de acuerdo? (32/n)

30) Factor Bus. Digamos que tienes 3 ingenieros senior en tu unidad central de servicios. Absolutamente indispensables. ¿Cómo los mantienes a los 3 VIVOS? ¿Pueden estar en el mismo avión? ¿Y si de todas maneras se mueren? (33/n)

31) Invasores. Un servidor en tu datacenter es conectado por error a Internet y olvidado ahí por años (esto REALMENTE sucede, en serio). Alguien encuentra el servidor. Se meten. ¿Cómo lo detectas? ¿Qué haces una vez que lo detectas? (34/n)

32) Invasores. Los silenciosos. Están en tu red. Tan sólo "observando" y esperando. Sin hacer nada. Un buen equipo de seguridad puede detectar esto. Pero si ya los despediste a todos, ¿qué daño pueden ocasionar los "observadores"? ¿Robo de tarjetas? ¿DMs? ¿Passwords? (35/n)

33) Invasores. Países. Los chinos acaban de hackearte. Si no te das cuenta, se quedarán permanentemente. ¿Tu equipo de seguridad los encontrará? ¿Cómo los erradicará y sus puertas traseras? ¿Cómo proteges los DMs y tweets privados? Si no lo haces, gente puede MORIR. (36/n)

34) Invasores. Los caóticos. Están aquí para causar daño. Podrían borrar datos, reiniciar los servidores, traerse abajo la plataforma por semanas, publicar amenazas nucleares como si fueran el Presidente de USA, etc. Ojalá tengas un buen equipo de seguridad listo... (37/n)

35) Hablando de invasores... ¿qué harás si le roban una laptop a uno de tus ingenieros? ¿Podrás detectar el robo antes de que sea reportado? ¿Puedes borrar los datos remotamente? ¿Invalidar las llaves de acceso? (38/n)

36) Y de nuevo... ¿cómo está tu equipo de seguridad? Definitivamente alguien intentará conectar un Raspberry Pi a la red corporativa, suplantar el wifi, poner micrófonos en las oficinas ejecutivas, etc. Cosas de película. No es broma. (39/n)

37) Moderación de contenido. Necesitas 3 cosas: un equipo enorme revisando reportes 24/7, otro creando las herramientas para ayudar a ese equipo, y un equipo psiquiátrico para atender al primero. No es broma. La humanidad es OSCURA. Tus moderadores pueden suicidarse. (40/n)

38) Ups! Despediste a todo tu equipo de moderación. La plataforma se llena de cosas malignas. Todos se van porque es desagradable o (mucho peor) acabas ante un juez, por quebrar todo tipo de leyes de decencia, piratería, acoso y privacidad. (41/n)

39) Ups! Despediste al equipo que elabora las herramientas para los moderadores. Los moderadores se saturan por los millones de reportes por atender. Se agotan, renuncian y no los puedes reponer suficientemente rápido. #38 sucede de todas formas. (42/n)

40) Ups! No le diste atención psiquiátrica a tus moderadores. En el mejor de los casos, renuncian llenos de traumas. En el peor de los casos, se suicidan. Acabas en la corte o en los noticieros. Ok, el peor caso es si uno de ellos se aparece en la oficina con una pistola. (43/n)

41) Velocidad: Solicitudes de servidores. Un pequeño cambio incrementa los tiempo de red. Ahora toma algunos milisegundos más en cargar la página. ¿Alguna vez han visto las estadísticas de cuántos usuarios se pierden así? Ahora imaginen que cada día empeore un poco... (44/n)

42) Velocidad: Desplazamiento. No creerían cuántas decenas de miles de personas dejarán de usar tu app, para siempre, si algún cambio en Android añade el más mínimo retraso en el desplazamiento. Tienes expertos en Desempeño aún contratados? No? Y si sigue empeorando? (45/n)

43) Velocidad: Arranque en frío. Si añades 5 segundos al tiempo que tarda tu app en arrancar en frío, se irá al diablo tu tasa de adquisición de usuarios. A velocidades increíbles. Hasta el suelo. Y nunca más intentarán probarla. ¿Tienes los expertos necesarios? (46/n)

44) Velocidad: Arranque en caliente. Algunos cambios en Android hacen la carga del app 1 segundo más lenta. Ahora pierdes 25000 usuarios cada día por esta causa. Y ese número empieza a aumentar. En serio. ¿Rastreas tus tiempos de arranque? (47/n)

(Sé que estos últimos problemas no parecen amenazas existenciales, pero créanme que cualquiera de esos problemas puede ser la diferencia entre el éxito o el fracaso del app. Algo que parece insignificante puede ser una bola de nieve) (48/n)

(Y Dios los ayude si es que tienen que lidiar con más de uno de esos problemas en simultáneo. ESPECIALMENTE si es que has perdido la mayor parte de tu equipo técnico, con una fuga masiva de conocimiento tribal de tu organización) (49/n)

45) PÉRDIDA DE DATOS. Diablos. Pérdida de datos. ¿La gente que entiende tus respaldos aún no ha sido despedida? ¿Respaldos en frío? ¿En caliente? ¿Redundancia entre regiones? Si pierdes tus datos, Game Over. La confianza se pierde... permanentemente. (50/n)

46) Otra vez pérdida de datos. ¿Tienes respaldos de sólo lectura? Un mal actor podría intentar borrar todos tus discos. ¿Pueden dañar las cintas de respaldo desde el software? ¿Cuánto tiempo tardarías en restaurar las copias? (Pista: semanas, con algo de suerte) (51/n)

47) Borrado. Debes estar 100% seguro de que ciertos datos se borran completamente. Es más importante de lo que crees. Si un usuario borra un post, ¿se borra del caché? ¿Y si ese post ya está en un respaldo de sólo lectura (imborrable)? Mete la pata y acabarás en la corte. (52/n)

48) Agotamiento de los empleados. Parece increíble, pero sucede y mucho. Revisa los artículos de HBR. Perderás empleados críticos que no puedes reemplazar. Sin importar cuánto quieras pagarles. Gente que no querías perder. Buenas personas, trabajadoras. (53/n)

49) Intromisión gubernamental. ¿Y si Brasil decide prohibir Twitter? ¿Estados Unidos? ¿Arabia Saudita? ¿Tienes expertos en políticas, abogados, lobbystas, ex-diplomáticos, etc? ¿Apelarás? ¿Y los países con intereses en conflicto? ¿A quién escoges? (54/n)

50) Replicación. Demonios. Hmmmmm... Digamos que tienes 5 regiones primarias. Cada región tiene una copia de datos críticos para la plataforma. Y un día algún ingeniero descubre que la data de A es diferente a la de B. Esto es apocalípticamente malo. ¿Cómo lo arreglas? (55/n)

51) Privilegios de cuenta de los empleados. ¿Todos deben poder reiniciar los servidores? ¿Un empleado de Soporte al Cliente debe poder ver las tarjetas de crédito? ¿Cómo das acceso a los diversos tipos de usuario? ¿Alguien puede robarse una cuenta automatizada? (56/n)

52) ¡DNS! Si jodes tu configuración DNS de alguna manera, todo en tu plataforma se caerá. Y me refiero a TODO. Herramientas internas, la web completa, literalmente las PUERTAS DE LA OFICINA (no es exageración). Y si tu registro DNS se vence, se lo robarán y lo perderás. (57/n)

53) Certificados digitales. La mágica "s" en "https" que previene que Bobby Joe en el wifi del café se robe los datos de tu tarjeta de crédito. Si el proceso de certificación de tu web tiene problemas, puede ser DOLOROSO lo que te puede pasar. Impersonaciones, etc. (58/n)

54) ¡Pruebas! No, no es broma. Sin alguien supervisando tus pruebas de integración y unitarias de cabo a rabo, puedes: Malograr todos tus cambios a la aplicación y nunca entregar nada nuevo. Poner en público defectos potencialmente ilegales, y afectar a los usuarios. (59/n)

55) Pagos. Existen TANTAS leyes, regulaciones y políticas alrededor de sistemas de pago que absolutamente deben ser cumplidas. Cualquier metida de pata, y puedes ser retirado del sistema financiero. No cobranzas, no suscripciones, no publicidad, nada. (60/n)

56) ¡Spam! El spam es un peligro existencial. Necesitas sistemas automatizados, agrupamiento basado en Inteligencia Artificial, equipos haciendo revisiones manuales e ingenieros creativos, capaces de ponerse en los zapatos de los atacantes antes de que ataquen. (61/n)

Ok, este ha sido el extenso pero increíblemente ilustrativo hilo de @MosquitoCapital. Espero que sirva para ayudar a entender que Twitter no es una paginita web que mantiene un egresado de programación. Requiere equipos expertos y extensos 24/7. (62/62)

https://twitter.com/MosquitoCapital/status/1593541177965678592?s=20&t=vf17c3I2kL1Hy5bduj4Eew