Feda /dev/ - No Javascript allowed

#54722 Ya, y a su público le da igual y hasta le parecerá bien, pero a cualquiera que sepa de esto le parece una chorrada.

Al vende humos se le atraganta tener algo en producción en el mundo real.

Cuando en toda tu vida lo máximo que has logrado es alinear 4 divs en un tutorial de react para estafar a estudiantes de instituto... poco se puede sacar.

HAHAHAHAHAHAHA

Oye, ¿ como hacen en vuestras empresas para ver qué ha sido desplegado ? Es decir, cuando hay un incidente, el 80-90% de las veces es culpa de algún equipo que ha desplegado algo y afecta a vuestro servicio.
He mirado, y no he visto ningún servicio saas que lo haga, en plan aglutinar cambios en deploys de software, cambios en la configuración X, cambios en infraestructura, cambios manuales, automáticos, etc.. en toda la empresa en un solo freaking sitio, de forma que cuando tu servicio empieza a fallar a una hora determinada, puedas mirar que se ha desplegado en el rango de tiempo en cuestión de servicios que os afectan.

Nosotros al final tenemos unas cosas en un sitio, otras en otro, y las de otros equipos a veces ni nos enteramos.

Lo que me extraña es que no haya nada, ya que creo que es algo que se vendería fácil a empresas grandes yo diría, para pequeñas con 5-10 servicios no tiene sentido pero cuando llegan a un tamaño considerable tiene mucho sentido, al menos así lo veo yo.

Y ya con eso tenéis todo ? Incluidos cambios en infra o cambios de configuración que no vayan por GitOps, en plan cambiar en una UI cierto cambio de plataforma, etc

#54737 #54738 nosotros tenemos todo lo que se puede por gitops, quitando una app de API Mgnt (apigee) que es una basura y para la cual estamos construyendo un operador de k8s para poder desplegar los objetos de la misma forma

#54739 Como yo lo entiendo, me acabo de levantar:

0) Observabilidad y alarmas => Básico y necesario, me lo salto.
1) Prevención => No interesa
2) Detección => Que ha pasado y porque, lo que estamos hablando.
3) Resolución => No interesa

• Lo segundo es un problema NP para cualquier empresa grande.
• Lo segundo es trivial para cualquier empresa que haga un par de deploys al día. Te voy a decir que es sobre enginieria y gastar dinero en devops.

Sobre lo que no interesa:

• Lo primero es imposible.
• Lo tercero se necesitaría tener todo el sistema funcional con Nix/Flox y hacer despliegues green/blue, y TODOS LOS SERVICIOS ser a prueba de grandes "outages", seguramente replicados multi-zone, una locura a nivel de costes.

Sobre detección (y también su resolución). Te pongo un ejemplo externo, peta AWS eu-x, todo tu tráfico se tiene que re-dirigir a us-x y usar servicios en us-x o tendrás downtime e incidentes provocados por este.
Y el ejemplo interno son los famosos cambios de DNS, tocar runners, actualizar versiones de k8s, etc, que muchas veces es IMPOSIBLE hacer rollback del cambio fácilmente.
La conclusión es que 1 hay que detectar esa cambio de infraestructura loco, y segundo querer arreglarlo, ambos chungos.

Así que si empiezas a pensar punto por punto, problema a problema, lo que quiere Juanaka, 3/4 no vale la pena, y el otro 1/4 si que es posible, pero es necesario? Quien te pagara esa herramienta?

Existen herramientas así centrándose solo en cambios internos o cambios externos. Datadog mismo tiene un detector para cambios internos en su explorador.