Feda /dev/ - No Javascript allowed | Página 1558

Kaledros #46711 Jun '23

#46709 Pues estamos igual, la mía ha conectado cinco minutos y luego ha decidido que iba a caerse cada tres segundos, conectando y desconectando en bucle y dejándome hasta sin internet. Muy divertido.

1

Wei-Yu #46712 Jun '23

los que curráis haciendo devops, cuánto os responsabilizáis de la infra?

estamos transicionando a una setup algo más estándar (equipo de SREs dando soporte de plataforma y consolidando + devs encargados de ops) y tengo tener ownership de todo lo que no sea infra genérica como elastic search (ej, hacer cambios de IaC para tocar los recursos o config del cloud es cosa mía)

que me parece bien pero tengo curiosidad por saber qué cosas toca la gente

2 respuestas

Zoko #46713 Jun '23

#46702

Pues he mirado ahi y a un Principal le pagan más de lo que estabas pidiendo :/ no?

1 respuesta

wdaoajw #46714 Jun '23

#46712 lo ideal es que seas responsable de mi que haces, osea tus microservicios.

Vamos, que hay una incidencia porque tú microservicio funciona mal? El first responder Eres tu, y si necesitas soporte de devops/infra/etc pues ya lo pides.

Esto no pasa casi en ningún sitio y suele haber un team que se encarga de todo y mal, porque obviamente no tienen ni idea de que coño pasa en todas partes

3 respuestas

JuAn4k4 #46715 Jun '23

#46713 Si pero no he sido Principal en mi vida hulio, a un Principal le tienen que pagar 150-200K. Que no estaría mal pero para Principal me descartan en l primera.

Lifecasi0 #46716 Jun '23

#46712 En mi caso, todos somos responsables de todo. Teniendo especial responsabilidad el que esté de guardia.

Wei-Yu #46717 Jun '23

#46714 sí, si estamos virando a tener esa praxis 100% y yo encantado, para mí siempre tuvo todo el sentido. Pero me da la sensación de que los devs de normal tienen muy poco conocimiento operativo en términos generales y aún menos de cosas de IaC.

Yo estos días que me estuve poniendo las pilas me lo he estado pasando teta la verdad

1 respuesta

desu #46718 Jun '23

#46714wdaoajw:
Esto no pasa casi en ningún sitio

Yo lo hago.

Como os gusta generalizar.

Kaledros #46719 Jun '23

#46717 En mi curro hacemos lo mismo que #46714 y cuando me tuve que poner las pilas para responder yo a incidencias me di cuenta de que hay dos cosas que son imprescindibles: observabilidad y alertas. Si te curras bien un sistema de alertas en flujos críticos y tienes claro dónde pueden darse esos fallos tienes medio trabajo hecho.

Vamos, que el objetivo es que cuando un sistema falle te llegue una alerta lo antes posible que te diga de la manera más clara qué está pasando. Esto, que puede parecer evidente, en realidad significa que mucho ojo con enmascarar errores. No te sirve de nada que tu alerta te diga que estás devolviendo códigos 400 al cliente si lo que falla es una API de terceros que te está devolviendo a ti un 500 porque se ha caído.

1 1 respuesta

Wei-Yu #46720 Jun '23

yo tengo logs critical/fatal enchufados a un webhook directamente, es un poco guarro porque a veces con un poco de presión sobre la db ya te salta el ping (aunque la tasa de error sea literalmente 0.0005%), pero también creo que merece la pena estar atento a los patrones de consumo a ver si hay algo que merezca la pena

de observabilidad sí que vamos flojitos, quería meter segmentos propios en el observability sink de azure pero la verdad que soy el único que se preocupa de estas cosas y ya voy cargadito

edit: ah y esto será una mala práctica supongo pero si es dep externa con un fallo irrecuperable siempre tiro un 502 aunque a nivel de status http no sea lo 100% correcto o lo que sea, me parece super útil para filtrar y navegar rápido

2 respuestas

wdaoajw #46721 Jun '23

#46720 en nuestro caso, he montado el sistema de tal forma que puedes crear alertas en base a métricas/logs desde el fichero de config del propio deployment del servicio.

También puedes configurar healthchecks sobre dependencias de terceros y recibir alertas en base a eso

2 respuestas

Wei-Yu #46722 Jun '23

#46721 la segmentación que tenía en mente era en base a reglas de negocio aunque en realidad creo que lo podría reducir al tenant de alguna forma si hago algo de magia negra

lo que dices suena guay, tienes algún ejemplo?

2 respuestas

isvidal #46723 Jun '23

#46722 muy bien, product oriented development, llegaras alto!

Wei-Yu #46724 Jun '23

metro ochenta de pura soja, todo lo que veo desde aquí está por debajo

Kaledros #46725 Jun '23

#46720Wei-Yu:
edit: ah y esto será una mala práctica supongo pero si es dep externa con un fallo irrecuperable siempre tiro un 502 aunque a nivel de status http no sea lo 100% correcto o lo que sea, me parece super útil para filtrar y navegar rápido

Ahí ya nos podemos poner todo lo culoduros que quieras, pero yo siempre he pensado que no es lo mismo un error que una operación que ha terminado correctamente con un resultado de error. Por ejemplo, un 400 no es un error, yo puedo ir a buscar un hilo en MV y que un admin se lo haya cepillado. Eso no es un error, es un comportamiento correcto de la aplicación. Pero si se cae imgur y no puedo ver ninguna imagen de ningún hilo eso sí es un error, y ahí ya depende de lo granular que te quieras poner.

De hecho, hablando de malas practicas, yo devuelvo el I'm a teapot cuando estoy desarrollando y aún no tengo claro qué error devolver. Ya lo decidiré luego, pero al picar no pierdo tiempo.

JuAn4k4 #46726 Jun '23

#46721 No usáis DataDog o algo por el estilo que te lo da todo hecho ya prácticamente y se integra con PagerDuty ?

2 1 respuesta

wdaoajw #46727 Jun '23

#46726 no, intentamos usar OpenSource en la medida de lo posible, en nuestro caso integrado con Opsgenie.

Además encaja perfect con nuestro sistema porque hacemos todo gitops de una forma concreta y permite meter todas estas integraciones de forma transparente para los devs en el mismo fichero donde le pueden subir la CPU o cambiar las env vars

Te sorprendería la factura se los servicios de monitoring como Datadog/NewRelic/Dynatrace, especialmente cuando empiezas a escalar. Son caros no, carísimos.

2 3 respuestas

Kaledros #46728 Jun '23

#46727wdaoajw:
Te sorprendería la factura

Es aterradora de verdad, eh.

En mi curro, por lo que tengo entendido, es en lo único en lo que existe un acuerdo tácito para no pedirnos nunca que ahorremos. El otro día por ejemplo acabamos el proceso de downscaling para todos los servicios en los que se podía hacer y se ve que Bezos ha dejado de ver una señora pasta por nuestra parte, pero en observabilidad no se toca. Supongo que se han dado cuenta de que recuperar el servicio en una webapp con decenas de millones de visitas diarias a los diez minutos desde que salta la alerta vale más que lo que cuesta el Datadog.

1 respuesta

desu #46729 Jun '23

#46722Wei-Yu:
lo que dices suena guay, tienes algún ejemplo?

circuit breaker que envuelva la llamada a la dependencia y cuando esta abierto tira un page

wdaoajw #46730 Jun '23

#46728 nono, desde luego. La gente se sorprende siempre de lo caro que es el monitoring.

En nuestro caso tiramos siempre que podemos de proyectos de la CNCF, para el monitoring tenemos Prometheus, thanos, etc

1

GaN2 #46731 Jun '23 Inocente

#46727

Te sorprendería la factura se los servicios de monitoring como Datadog/NewRelic/Dynatrace, especialmente cuando empiezas a escalar. Son caros no, carísimos.

Que se lo digan al cliente de DataDog que paga $65 millones anuales...

1 respuesta