Feda /dev/ - No Javascript allowed

#35190 luego te paso mis slides. Tengo la intro hecha.

#35193 oye te has preguntado alguna vez como habiendo malformaciones genéticas super raras nunca se ha visto a una persona cuyos pelos de las piernas fueran gruesos como los pelos de la cabeza? Es curioso

#35200 viernes, 21h, a fuera la gente en el estadio de futbol gritando, escucho la gente en las terracitas bebiendo sus champus y pidiendose algo pa cenar.

yo aqui, haciendo un deploy para que me dejen de llegar putos pages de mierda

me cago en los fperos sin toque de s3 que cojones habran tocado

#35201 ¿Pero si a S3 no le pasa nada no ? Vamos nos hubiéramos enterado todos.

#35203 pues ayer con el support de aws salio que java por defecto no hay exponential backoff, lo he puesto en un hotfix que aun no he desplegado .. XD

es algo de S3 muy sutil, porque no hemos cambiado nada de trafico pero de repente en algunas availability zones tenemos bursts de 500.

han tocado algo por su lado pero es tan peque;o para su trafico que siguen estando al 100% de availability, e imagino que poca gente tiene el trafico que tenemos nosotros para que se note.

si tirandoles su maximo de req/s permitidas nunca hemos tenido problemas, el mismo numero de POST, el mismo tama;o de payload etc etc xq desde ayer peta?

esto lo hablo en mi talk de metricas por cierto que le comento abajo a @wdaoajw esto seria un claro ejemplo de detectar un cambio externo a tu poblacion de sampleo. siendo tu poblacion todos los datos que tu generas internamente. si un user cambia su patron de trafico esto no deberia afectar a tu CPU media por ejemplo, porque deberias tenre un sistema auto escalable. en este caso han tocado algo sutil a s3, que nos ha obligado a empeorar nuestro servicio con exponentials backoffs y seguramente tendremos que tocar algunos timeouts.

#35204 si eso tambein lo hago en las slides crack, el burn rate a que te refiers? a un rate de errores? o calcular el % de errores que esta bien dejar pasar? ese concepto lo lei en el libro de SRE de google, los budget, no me gusto mucho esa idea y no la recomiendo para nadie, ni siquiera google XD eso no deberia venir de negocio sino analisis de datos.

esto lo ense;o usando data science / data analytics. ya puse un ejemplo, si tengo N request/s, que % de error es asumible? que ventanas para calcular medias tiene sentido? cada cuanto tengo que cambiar los thresholds? como detecto AUTOMATICAMENTE que un threshold de alerta se ha quedado anticuado... Esto ultimo no lo hace nadie salvo yo que soy un puto dios.

como poner thresholds de alertas segun el tipo de distribucion. es la clave. esto son cosas que la gente hace a ojo o por experiencia, yo explicaba un poco las mates. al final es data science muy muy basico...

si quieres un dia abro stream y comentamos las mias.

lo de planificar en sprint de devs no he entendido que es.

#35205 básicamente un team define un SLO, que no es más que decir, voy a tener 99% de availability por ejemplo. A partir de eso definen como medir availability, que podría ser simplemente N de request 5xx / request totales.

Todo lo que no cumpla el umbral del 99% empezará a quemar error budget (a un determinado Burn rate en base a la cantidad de errores) y si consumes todo tu error budget el team "no puede" sacar nuevas features a prod sin arreglar el veneno que hayan metido que este generando esos errores 5xx

#35208 empresa alemana top 1 de seguros a nivel Europa, pequeña pequeña no es.

Estamos en fase de escalar tanto a nivel de features como de equipos y desde management llegan estos requisitos así que toca aplicarlos

#35214 Siempre he pensado que era parodia exagerada, no se, imagino que será más de lo mismo.