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.
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 .
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.
#1 Just one errata.
#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.
#7
#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"
#5 No seas así y le subestimes. Todos podemos cagarla así ¡y mejor!
#4 Es que cuando se dan problemas en producción se tienen que resolver en producción.
#2 Tenemos la culpa de TODO porque no nos dejais terminar las cosas.
Y recuerda...
#14 SYNTAX ERROR
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.
#9 "la estupidez real siempre ganará a la inteligencia artificial."
- Terry P
Malditos informáticos tenéis la culpa de todo. (Ironía)
#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!
#7 DELETE FROM users WHERE true; -- ejem... >;)
#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.
#46 Deberías leerte la noticia porque el problema no ha sido que hayan subido rápido a producción sin testear.
#3 es el problema de ejecutar mierda en producción.
#2 Informático aquí: no tienes ni idea
#31 Aunque si viene un tio con un comando militar también te revienta el chiringuito...
#6 no has tenido que mantener algo en producción en tu vida?
#1 Era un tipo el que se equivocó al escribirlo, si hubiera sido una mujer sería una "persona".
#10 como si en un entorno de discos virtuales en cabinas SAN de alto rendimiento eso tardase mas que un parpadeo
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.
#1 Un tipo sencillo... ea
#3 bueno...
Si tu tuvieras esos servidores la podrias cagar igual....
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 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.
#7 se le olvidó el where 1=1
#21 ¿Como por ejemplo esa batería antimisiles patriot que tenía error acumulativo en el contador de tiempo que hizo que fallara al detener un ataque y murieran varios soldados?
http://embeddedgurus.com/barr-code/2014/03/lethal-software-defects-patriot-missile-failure/
¿O ese que hacía a los f35 los mas pacifistas del mundo hasta el 2019? https://tabloidenoticias.wordpress.com/2015/01/04/fallo-en-el-software-de-la-computadora-de-armamento-de-los-f-35-impide-que-puedan-disparar-sus-ametralladoras/
Aunque siempre les quedarían el resto de armas del avión.
¿O el que dejo un barco de la marina estadounidense a la deriva porque alguien puso un 0 en un campo de la base de datos MS-SQL causando una división por cero?
https://en.wikipedia.org/wiki/USS_Yorktown_(CG-48)#Smart_ship_testbed
#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,
#27 el root de --no-preserve-root se refiere a /, no al usuario root
#102 Visto en la publicidad de una tienda de informática: "Oferta válida hasta fin de existencias, salvo error topográfico".
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
#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("/").
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"
#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.
#16 realmente "error tipográfico"
#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?
#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.
#100 El sistema tiene ulimit y sysctl, con el cual puedes limitar la cantidad de procesos que ejecuta un usuario, o la ram que puede utilizar(ademas de otros límites).
http://www.linuxhowtos.org/tips%20and%20tricks/ulimit.htm
Tampoco hace falta reiniciar el sistema, solo hacerle un "killall -STOP" y cuando están todos bien dormidos un "killall -9". Aunque esto seguramente solo podrás hacerlo si ya tienes una consola abierta.
Otra opción es utilizar las "magic keys" si están activas te permitirán matar todos los procesos(todos es todos que quede claro), sincronizara los discos, remontar en solo lectura los discos y reiniciar el sistema.
https://en.wikipedia.org/wiki/Magic_SysRq_key
REISUB
R-Teclado en raw
E-Terminar procesos
I-Matar procesos
S-Sincronizar discos
U-Montar en solo lectura
B-Reiniciar
Por otra parte, si es por un proceso que consume mucha ram y te está hiperpaginado hay una tecla que elige uno al alzar entre los que mas ram estén ocupando y lo mata(creo que es f).
#1 Me quedo con las ganas de saber si se trataba de un simple tipo, o un simple topo.
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.
#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
#36 Testeando primero en un entorno de pruebas... si eso.
#95 Viviendo al límite
#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.
#28 realmente no, en cabinas EMC puedes tardar menos de un segundo en cepillarte todas las lun's
#63 Vale, quien pone / , pone /data o /srv o /mnt o /donde/quiera/que/tengas/los/datos/
"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
#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....
#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.
En castellano, gazapo.
#38 tengo un gato en la cabeza y me he pasado una bolsa de chetos por la cara JAQUE MATE
Os lo traigo en exclusiva:
10 print "Manuela t kiero muxo"
20 GO TO 10.
Resumiendo
Que ganas que tengo de ver una huelga en Informática.
Los informaticos tenemos mucho poder, pero todavia muchos no se han dado cuenta
#1 ya tío, lo llaman typo debe tener relación con que los "informáticos" nunca ponen tíldes
#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.
#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.
#111 jajajajaja mola
Little Bobby Tables
https://xkcd.com/327/
https://www.explainxkcd.com/wiki/index.php/Little_Bobby_Tables
Query
https://xkcd.com/1409/
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.
¿Pero qué clase de typo es este ingeniero?
#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.
#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.
Eso dicen, pero ¿Es verdad?
O igual creen que es verdad, pero el ingeniero o ingeniera habia sido "hipnotizado" para escribir mal el comando o comandos. Es como un caso en que hipnotizaron a una cajera de banco para que diera billetes de 100 pensando que eran de 10. El hipnotizador ladron la hipnotizó, o la preparó antes de alguna forma, despues, cuando fue a sacar dinero de su cuenta, la activo con la palabra clave o el chasquido como suelen hacer, y entonces le pidio x dinero. La cajera pensaba que estaba dando billetes de 10 pero realmente estaba dando billetes de 100. Despues la cajera sigue y ni siquiera se habia dado cuenta de lo que habia pasado.
#104: No lo conocía, de todas formas lo que hizo ese administrador fue poner límite al número de procesos por usuario.
"Internet se diseñó para aguantar una guerra"
pero no una tecla.
#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.
#66 No siempre es posible. Y menos cuando hablamos de optimización ya que en el entorno de pruebas no se reproduce el problema.
#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).
#101 ¿Acaso quieres vivir eternamente?
Eso hay que hacerlo con esto de fondo.
Recuerdo cuando hice algo parecido en el S/36. ¡Que tiempos aquellos!
#66 No es lo mismo un bug que un crash. El entorno de pruebas está antes de llegar a producción, cuando se produce un crash en produccion se tienen que resolver en producción.
#22 Lo mismo digo, estos titulares clickbait...
Al final volverá el "Está seguro?" que tanto se ha criticado de windows
Noob.
#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/
#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
#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
#53 Cuando precisamente a Amazon se les paga una pasta para que estas cosas excepcionales no pasen
Hacer pruebas en el entorno de desarrollo es muy lento.
Siempre es más rápido subir el código nuevo a producción y que te encuentren el error miles de usuarios concurrentes
#3 Más bien no la dejadez de no testear bien en calidad antes de subir a productivo,
#18 ¿Teniendo miles de usuarios por debajo? Jamás. Hablamos de un ERP.
#21 si por que a los coches toyota no les ha pasado nunca nada en en acelerador relacionaldo con algo informatico
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
#57 Se pueden colar fallos de todo tipo por muy bien que pruebes, ¿pero de este calibre?
#62 Si tienes razón. Con instrucción había entendido instrucción dentro del código. Se cepilló los servidores, entendido.
No probaron a reiniciar el sistema?......o internet?