Portada
mis comunidades
otras secciones
#13:
Se le suele echar la culpa al último mono siempre: piloto de Spanair, conductor del Alvia, operador de red, etc. pero cuando se produce un desastre no es culpa de una persona, detrás hay presiones, recortes, malas arquitecturas.
En este caso parece que un crecimiento demasiado acelerado ha creado una arquitectura poco resistente a fallos. Y eso no es problema del operador, administrador, etc. porque las artquitecturas tienen que diseñarse para que sean resistentes al fallo humano que, inevitablemente, va a ocurrir.
En este caso parece que un crecimiento demasiado acelerado ha creado una arquitectura poco resistente a fallos. Y eso no es problema del operador, administrador, etc. porque las artquitecturas tienen que diseñarse para que sean resistentes al fallo humano que, inevitablemente, va a ocurrir.
#1:
Un simple typo.
Dios mío, llévame pronto.
Dios mío, llévame pronto.
#7:
Desafortunadamente, una de las entradas del comando se ingresó incorrectamente y eliminó un conjunto de servidores más grande que el previsto.
Está claro, olvidó el where en el delete from .
Está claro, olvidó el where en el delete from .
#45:
#6 Si, una dejadez tremenda. Mantengamos la salida del producto congelada hasta que no hayamos testeado bien. Pero no mal, ¡bien!
- Hacer la batería de test habituales
- Luego pasaremos los test buenos (no los habituales) los test buenos buenos.
- Más tarde haremos los test de esos fallos que sólo se producen cuando un equipo está en producción: Traigan a un millardo de usuarios repartidos por 4 regiones mundiales y póngalos a tocar las teclas como los monos en noche de luna llena mientras suena de fondo Kandinsky. ¿Pero Kandinsky es un pintor? Eso, eso no se lo esperarán.
- Una vez pasado esos test, haremos las pruebas de fallos que pueden surgir pero que no estaban dentro del protocolo, para ello preguntale a Paco. ¿A Paco? Si, a Paco. Que te haga una lista.
- Llama a Google, Microsoft, Oracle y que te den los fuentes de esas librerías que linkamos, estudialas y prueba cualquier posible error de aquí a los próximo 15 años.
- Hacer la batería de test habituales
- Luego pasaremos los test buenos (no los habituales) los test buenos buenos.
- Más tarde haremos los test de esos fallos que sólo se producen cuando un equipo está en producción: Traigan a un millardo de usuarios repartidos por 4 regiones mundiales y póngalos a tocar las teclas como los monos en noche de luna llena mientras suena de fondo Kandinsky. ¿Pero Kandinsky es un pintor? Eso, eso no se lo esperarán.
- Una vez pasado esos test, haremos las pruebas de fallos que pueden surgir pero que no estaban dentro del protocolo, para ello preguntale a Paco. ¿A Paco? Si, a Paco. Que te haga una lista.
- Llama a Google, Microsoft, Oracle y que te den los fuentes de esas librerías que linkamos, estudialas y prueba cualquier posible error de aquí a los próximo 15 años.
#26:
#13 totalmente de acuerdo. El recurso fácil siempre es culpar al soldado raso. Que una multinacional como Amazon, dando servicios críticos a miles de clientes, facturando cientos de millones de euros, no disponga de una infraestructura sujeta a unos protocolos básicos de calidad y seguridad no debe tener nada que ver. Que alguien pueda ejecutar un comando que fulmine el sistema sin que salte ninguna alarma es una fatalidad del destino. En fin, el pobre ingeniero que metió la pata se ira al paro, mientras los responsables que cobran millones por gestionar una infraestructura de la que no tienen ni idea dan una rueda de prensa para comunicar que la culpa no fue de Amazon. Ya nos sabemos el rollo: "Ese ingeniero del que usted me habla ya no está en nuestra empresa y no tenemos nada que decir sobre sus actos"
#15:
#2 Tenemos la culpa de TODO porque no nos dejais terminar las cosas.
Y recuerda... https://m.youtube.com/watch?v=udhd9fmOdCs
Y recuerda... https://m.youtube.com/watch?v=udhd9fmOdCs
#10:
rm -rf /
- mierda! Le dado al entre antes de tiempo...
- Ya da igual, déjalo que terminé
Si no que le pregunten al de gitlab, que le paso eso hace unas semanas.
- mierda! Le dado al entre antes de tiempo...
- Ya da igual, déjalo que terminé
Si no que le pregunten al de gitlab, que le paso eso hace unas semanas.
Comentarios
Un simple typo.
Dios mío, llévame pronto.
Malditos informáticos tenéis la culpa de todo. (Ironía)
Lo que me fascina y aterroriza a partes iguales es la evidencia de lo frágil que es este tipo de plataformas, de las que cada vez dependemos más.
#3 es el problema de ejecutar mierda en producción.
#3 bueno...
Si tu tuvieras esos servidores la podrias cagar igual....
#3 Más bien no la dejadez de no testear bien en calidad antes de subir a productivo,
Desafortunadamente, una de las entradas del comando se ingresó incorrectamente y eliminó un conjunto de servidores más grande que el previsto.
Está claro, olvidó el where en el delete from .
#2 Informático aquí: no tienes ni idea
#5 No seas así y le subestimes. Todos podemos cagarla así ¡y mejor!
rm -rf /
- mierda! Le dado al entre antes de tiempo...
- Ya da igual, déjalo que terminé
Si no que le pregunten al de gitlab, que le paso eso hace unas semanas.
#7
#10 como si en un entorno de discos virtuales en cabinas SAN de alto rendimiento eso tardase mas que un parpadeo
Se le suele echar la culpa al último mono siempre: piloto de Spanair, conductor del Alvia, operador de red, etc. pero cuando se produce un desastre no es culpa de una persona, detrás hay presiones, recortes, malas arquitecturas.
En este caso parece que un crecimiento demasiado acelerado ha creado una arquitectura poco resistente a fallos. Y eso no es problema del operador, administrador, etc. porque las artquitecturas tienen que diseñarse para que sean resistentes al fallo humano que, inevitablemente, va a ocurrir.
Os lo traigo en exclusiva:
10 print "Manuela t kiero muxo"
20 GO TO 10.
#2 Tenemos la culpa de TODO porque no nos dejais terminar las cosas.
Y recuerda...
#1 Just one errata.
#7 DELETE FROM users WHERE true; -- ejem... >;)
#6 no has tenido que mantener algo en producción en tu vida?
En castellano, gazapo.
#18 ¿Teniendo miles de usuarios por debajo? Jamás. Hablamos de un ERP.
#2 Y cada vez más. El caso es cuando vidas dependan de un error informatico...va a ser entretenido.
"buena parte de internet"
como le gusta a los medios dramatizar todo.. nada, otra que voto sensacionalista, por las formas
#10 Pero no tienes sudo
La he liao parda. Version digital.
#10 para que eso funcione te falta la opcion "--no-preserve-root", ya que "--preserve-root" está por defecto desde hace bastante tiempo.
https://ss64.com/bash/rm.html
#13 totalmente de acuerdo. El recurso fácil siempre es culpar al soldado raso. Que una multinacional como Amazon, dando servicios críticos a miles de clientes, facturando cientos de millones de euros, no disponga de una infraestructura sujeta a unos protocolos básicos de calidad y seguridad no debe tener nada que ver. Que alguien pueda ejecutar un comando que fulmine el sistema sin que salte ninguna alarma es una fatalidad del destino. En fin, el pobre ingeniero que metió la pata se ira al paro, mientras los responsables que cobran millones por gestionar una infraestructura de la que no tienen ni idea dan una rueda de prensa para comunicar que la culpa no fue de Amazon. Ya nos sabemos el rollo: "Ese ingeniero del que usted me habla ya no está en nuestra empresa y no tenemos nada que decir sobre sus actos"
#25 Prueba prueba, ya verás que gracioso. De todas formas, dudo que tengan los datos restrigidos solo a root y los servicios que ejecutan lo hagan con permisos de root.
#12 Si hablamos de la cantidad de datos de Amazon, posiblemente eso si que tarde más de un parpadeo.
#9 "la estupidez real siempre ganará a la inteligencia artificial."
- Terry P
#13 Si. No deja de ser curioso que una empresa tan opaca como Amazon, que nunca facilita datos sobre sus negocios, en este caso facilite tantos para echarle la culpa al informático.
#3 Eso no debería pasar nunca si se hacen las cosas bien. Y aunque todos tenemos un poco romantizadas a las empresas grandes, en todos sitios cuecen habas y se hacen cosas a lo loco, puedes tener tu mercurial, tus entornos currados, CI, pruebas de unidad a muerte y validaciones complejas y al final viene un tio con un comando (una instrucción, no un grupo especial de militares) y te revienta el chiringuito.
#22 Lo mismo digo, estos titulares clickbait...
#13 Ya te digo. Y no sabemos si el tipo o la tipa en question habia trabajado más de la cuenta esa semana, o estaba enfermo porque en USA las bajas por enfermedad no existen o vete a saber.
Lo de buena parte de internet me hace gracia. Es cuando menos alucinante que empresas como airbnb o bussines insider no tengan planes de backup por si su proveedor principal cae.
Al final volverá el "Está seguro?" que tanto se ha criticado de windows
#4 Es que cuando se dan problemas en producción se tienen que resolver en producción.
#21 si por que a los coches toyota no les ha pasado nunca nada en en acelerador relacionaldo con algo informatico
#37 Si no lo retwittea D. Trump no existe!
Malditos ;;;;;;;;;;;;;;;;;
Noob.
#28 realmente no, en cabinas EMC puedes tardar menos de un segundo en cepillarte todas las lun's
#38 tengo un gato en la cabeza y me he pasado una bolsa de chetos por la cara JAQUE MATE
Y todos los listillos de meneame intentando dar clases de administración de servidores
#3 La fragilidad de los sistemas siempre ha estado ahí.
Recuerda la leyenda del primer bug https://es.wikipedia.org/wiki/Error_de_software#/media/File:H96566k.jpg
#6 Si, una dejadez tremenda. Mantengamos la salida del producto congelada hasta que no hayamos testeado bien. Pero no mal, ¡bien!
- Hacer la batería de test habituales
- Luego pasaremos los test buenos (no los habituales) los test buenos buenos.
- Más tarde haremos los test de esos fallos que sólo se producen cuando un equipo está en producción: Traigan a un millardo de usuarios repartidos por 4 regiones mundiales y póngalos a tocar las teclas como los monos en noche de luna llena mientras suena de fondo Kandinsky. ¿Pero Kandinsky es un pintor? Eso, eso no se lo esperarán.
- Una vez pasado esos test, haremos las pruebas de fallos que pueden surgir pero que no estaban dentro del protocolo, para ello preguntale a Paco. ¿A Paco? Si, a Paco. Que te haga una lista.
- Llama a Google, Microsoft, Oracle y que te den los fuentes de esas librerías que linkamos, estudialas y prueba cualquier posible error de aquí a los próximo 15 años.
#45 Oye, si les compensa tirar media red por subir rápido a producción ¿quien soy yo para cuestionarlo? para ti la perra gorda,
#22 O sea, se caen unas cuantas páginas, de las cuales yo NO USO NINGUNA, y para ellos se ha caído, "buena parte de internet". Si, Objetivos e imparciales, y sobretodo NADA sensacionalistas.
Me parece que tienen lustre como sistema de ficheros, por lo que sé el proceso de arranque es bastante lento.
#45 pues lo que hace Google precisamente es tener una batería de tests automáticos inmensa. Antes de mover a producción hay que pasar todos los tests.
Escribir tests no es complicado pero hay que tener el hábito
#7 se le olvidó el where 1=1
Resumiendo
"Internet se diseñó para aguantar una guerra"
pero no una tecla.
#34 Claro, solo tienes que pagar y mantener dos infraestructuras.
Btw, se suponte que esto es algo excepcional y que no debería pasar en una empresa como Amazon
#31 Aunque si viene un tio con un comando militar también te revienta el chiringuito...
#49 Si, y al final siempre habrá un problema en producción o habrá que tratar una optimización del sistema en producción. No hay nada 100% fiable. Y no por eso ha tenido que haber dejadez. Vaya que dudo mucho que la gente de Amazon no tenga los mismos sistemas de testeo que los de Google.
Es lo que pasa cuando se permiten teclear comandos básicos desde consola para ciertas tareas.
¡Por dios! Para eso se hacen interfaces de usuario para controlar lo que se puede hacer, cuándo, se den advertencias, incluso se requieran acciones y se envíen alertas a un superior o supervisor, etc, etc.
Lo de los comandos está bien para trastear, pero para ciertas cosas..., buff
#46 No, me refiero a que tildas muy rápidamente de dejadez un fallo en producción dando por sentado que no hacen suficientes test en el proceso de calidad. Cuando esto siempre va a ocurrir en cualquier sistema ya que no se pueden controlar todas la variables de un entorno. Si no los aviones no caerían jamás.
#55 claro, pero entonces hay un test más que tienes que escribir
#57 Se pueden colar fallos de todo tipo por muy bien que pruebes, ¿pero de este calibre?
Que ganas que tengo de ver una huelga en Informática.
#56 con los comandos puedes hacer lo mismo loco
#46 Deberías leerte la noticia porque el problema no ha sido que hayan subido rápido a producción sin testear.
#27 el root de --no-preserve-root se refiere a /, no al usuario root
#61 Con los comandos no, con los scripts en todo caso. Y un script no deja de ser una interfaz en este supuesto caso.
#13 Dudo que nada de eso se aplique a Amazon Engineering (a otras brancas de la empresa sí y mucho, pero en Eng todo el mundo dice que se curra muy bien). Pero bueno, comentario populista y a disfrutar del karma!
#36 Testeando primero en un entorno de pruebas... si eso.
#63 Vale, quien pone / , pone /data o /srv o /mnt o /donde/quiera/que/tengas/los/datos/
Falta esto: https://aws.amazon.com/es/message/41926/
"The Amazon Simple Storage Service (S3) team was debugging an issue causing the S3 billing system to progress more slowly than expected."
"At 9:37AM PST, an authorized S3 team member using an established playbook executed a command which was intended to remove a small number of servers for one of the S3 subsystems that is used by the S3 billing process. "
"Unfortunately, one of the inputs to the command was entered incorrectly and a larger set of servers was removed than intended."
"The servers that were inadvertently removed supported two other S3 subsystems. One of these subsystems, the index subsystem, manages the metadata and location information of all S3 objects in the region."
"Removing a significant portion of the capacity caused each of these systems to require a full restart. While these subsystems were being restarted, S3 was unable to service requests. "
" While this is an operation that we have relied on to maintain our systems since the launch of S3, we have not completely restarted the index subsystem or the placement subsystem in our larger regions for many years"
"S3 has experienced massive growth over the last several years and the process of restarting these services and running the necessary safety checks to validate the integrity of the metadata took longer than expected"
"The placement subsystem began recovery when the index subsystem was functional and finished recovery at 1:54PM PST."
"We are making several changes as a result of this operational event."
Decir que el desastre fue causado por un typo, es como decir que el accidente de Spanair fue por culpa del piloto. Jamás de los jamases la causa es única.
Menos mal que Amazon tiene claro que tiene que hacer varios cambios en la operativa.
#47 Claro, porque tu usas "buena parte de Internet". La caida de S3 us-west se ha notado bastante en el Internet de EEUU, que me atrevería a definir "buena parte de Internet"
No probaron a reiniciar el sistema?......o internet?
#69 Claro, y si se colapsa la m30, se ha colapsado buena parte de las carreteras españolas, porque hay muchos que la usan, pero a mi me que vivo en alicante, plim
A ver, si con analogias lo pillas mejor.
Aparte, es que ¿internet son solo las webs? Joder, pues se ve que si se caen las webs, yo no puedo hacer nada....
#66 No siempre es posible. Y menos cuando hablamos de optimización ya que en el entorno de pruebas no se reproduce el problema.
#3 no existe nada 100% infalible. Hay formas de testar automáticamente la plataforma como la que usa Netflix https://github.com/Netflix/SimianArmy pero contra el factor humano no hay nada que hacer.
#71 Te estás contradiciendo sólo. Si dejara de funcionar la M30 no sería nada sensacionalista (sin ironía) decir que ha dejado de funcionar buena parte/una parte importante de la infraestructura viaria española.
Comunicado oficial de Amazon: https://aws.amazon.com/message/41926/
#16 De hecho no sé cómo no se ha generalizado la errata, que en el fondo es como un "bug" que se te ha colado al escribir con el teclado... una e-rata.
#1 Un tipo sencillo... ea
#65 Nunca he tenido claro para que sirve tener más o menos karma. ¿Cómo puedo disfrutar de él, lo puedo cambiar por euros para irme de cena?
Little Bobby Tables
https://xkcd.com/327/
https://www.explainxkcd.com/wiki/index.php/Little_Bobby_Tables
Query
https://xkcd.com/1409/
#64 rm passwords.txt
rm - ¿Borrar el fichero regular "passwords.txt"? (s/n)
#74 Claro, la m30, que pueden ser ¿100km? tirando a lo alto ¿200km?. Los otros 15000km que hay en españa no cuentan, y que se colapsen 200km (como mucho) es una parte importante de la infraestructura viaria española.
Sabes que eso es la definicion de sensacionalismo ¿verdad?
En todo caso no sería sensacionalista si pusiesen "parte importante de la infraestructura viaria madrileña."
Y no, no me contradigo. Que deje de funcionar unas cuantas webs, no es "buena parte de internet", igual que que deje de funcionar una via, no es una buena parte de la infraestructura viaria española.
#62 Si tienes razón. Con instrucción había entendido instrucción dentro del código. Se cepilló los servidores, entendido.
#56 Totalmente de acuerdo. Aunque no se puede descartar que error tipografico haya sido una forma de llamar a un error de procedimiento u otro tipo menos "fortuito". Es como cuando en otras empresas uno toca lo que no debe y luego dicen que "ha habido un error informatico". AWS no puede permitirse el lujo de usar esa excusa
#73 En cierto sentido Chaos Monkey es una forma de testar contra el factor humano: lo peor que puede pasar es que una parte del sistema deje de funcionar, como le ha pasado a Amazon, y si el resto del sistema es capaz de aislarse de la parte caída y recuperarse sin problemas, entonces por mucho que el factor humano la cague, el sistema en su conjunto seguirá funcionando.
Los mismos de Amazon dicen que los sistemas caídos tardaron "más de lo esperado" en reiniciarse... o sea que no los reiniciaban de forma rutinaria, que es lo que les habría dado un Chaos Monkey, y no se enteraron del problema hasta que fue demasiado tarde.
#78 Imagínate que mirando la cola de envíos ves algo que no te gusta. Quien lo ha enviado tiene 7 de karma y, como tienes 18, le mandas a -11 de un click.
Ahora solo te queda mirar cómo el resto de la gente le vota negativo con la esperanza de que la descarte y ganar un poco de karma.
Ahí tienes un ejemplo de para qué sirve el karma.
#14 SYNTAX ERROR
#1 Era un tipo el que se equivocó al escribirlo, si hubiera sido una mujer sería una "persona".
Toda mi vida me acordare de mis 3 días de trabajo perdidos buscando por que un programa no funcionaba como debía.
Y tras días de búsqueda descubrí que había una línea en la que había escrito un "0" en lugar de una "o" mira, para volverse loco.
#81 La importancia de una infraestructura (y de los servicios de Internet) no es sólo en los kilómetros sino sobre todo en el número de usuarios afectados. Está claro que no ha caído toda Internet por los problemas de una zona de S3, pero ha sido una caída importante, que se ha notado y de la que vale la pena discutir.
#68 Hombre, causado fue causado por un typo. Que no hubieran sistemas para paliar/bloquear este error, o que no hubiesen hecho pruebas de reinicio controlado en años es otro tema. Nadie (ni el articulista) está echándole la culpa al sysop/sysadmin/SRE/llamale_como_quieras que le ha dado "enter" al comando equivocado
Ahora venid a defenderme mierdas como Javascript, Ruby, Python y demás lenguajes sin tipado.
#89 ¿No entiendes, que hay una diferencia entre global y local? Para la zona sera grave, para el resto de españa, pues mira, se han colapsado los "centralistas".
Que no todo el mundo gira en torno a "Madrid" (pongasé ahí lo que se quiera, como si quieres poner ombligo).
#53 Cuando precisamente a Amazon se les paga una pasta para que estas cosas excepcionales no pasen
¿Pero qué clase de typo es este ingeniero?
#c-27" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2742293/order/27">#27
"# rm -fr /
rm: es peligroso operar recursivamente sobre '/'
rm: utilice --no-preserve-root para saltarse esta medida de seguridad"
Como puedes ver, estaba como root al intentar el borrado recursivo del raíz del sistema. En la imagen adjunta puedes ver el comando y lo que responde rm.
Como te indica #63, el preserve-root no es para el directorio personal del usuario root, se refiere al raíz del sistema de ficheros("/").
#85 jajajajaa me lo creo, la gente hace unas cosas increibles para incrementar su contador de lo que sea. Supongo que somos esencialmente competitivos, aunque no sirva para nada real.
Yo voto noticias en karma negativo si me interesan. De lo que sí me di cuenta hace años es que si se vota indiscriminadamente se acaba el karma (menos de 6 creo que fué) y no deja votar. Y como le he cogido vicio a eso de votar lo que me gusta me cuido un poco más.
Votar negativa una noticia creo que lo he hecho un par de veces. Algún caso muy insultante, no recuerdo. No le veo mucho sentido a eso en general.
#80 Qué simple, una pregunta de sí o no. Das a S y estamos en las mismas, como control es el más básico de todos.
Te pregunta si quieres hacer lo que le has dicho que haga.
El ejemplo sería si en vez de preguntarme eso me dijera que si borro ese fichero va a repercutir en A, B y C. Y si ya nos ponemos más exquisitos que se necesita que esa operación tendrá que ser validada por tal operador para hacerla efectiva.
Pero tú mismo, don erre que erre.
#23 Incluso con sudo, no funciona sin la opción que le indiqué en #25 como puedes ver en #95.
Ahí no use "sudo" porque directamente pasé a root con "su"(ademas de que nunca tengo "sudo" instalado).
#72 Si tienes un problema en producción, pero en tu entorno de pruebas no se reproduce, tu entorno de pruebas es una mierda y no te sirve para testear cosas antes de pasarlas a prod.
#27: Me recuerda al "fork bomb", también conocidas como "bomba bifurcación" o "bomba tenedor" que ejecuté en GNU/Linux, el administrador casi me pwnea porque encima se corrompió el sistema de archivos al tener que reiniciar de forma brusca. Bendito sistema RAID 1 con redundancia, me salvo de un pwneamiento seguro.
Yo creía que el sistema estaba preparado para absorber ese tipo de ataque... se conoce que no.
Un consejo: es mejor prevenir que pwnear, en este caso al $luser que haga experimentos.