Con 1200 personas, repartidas por Nantes, Lille y París, SNCF Connect & Tech, una subsidiaria de la National Railway Company, es una mercantilía electrónica de la web francesa, por un total de 1.300 millones de visitas y 209 millones de boletos vendidos en 2023, y una agencia creativa de soluciones digitales primero para el SNCF (pantallas de estación, herramientas para recortes, etc.) de transporte organizaciones u otras compañías.

En 2021, la compañía completó su migración en la nube de AWS, una operación masiva completada en 18 meses. Una elección radical que ha cambiado las prácticas operativas internas, como Emmanuel Thys, el director de producción de SNCF Connect & Tech desde mediados de 2012, le dice a un equipo de quince personas dedicadas a los procesos de calidad y operación.

¿Ha completado su migración en AWS en 2021?

Emmanuel Thys: Solo tenemos un operador de la nube en nuestra aplicación de producción, AWS, incluso si, más anecdóticamente, tenemos algunas aplicaciones internas alojadas en Azure. Esta elección de mono-nube no se cuestiona. Dada la importancia de los volúmenes que representamos, blandir una presencia en otro proveedor no necesariamente sería una buena palanca de negociación. Incluso si pudiera ofrecer una solución alternativa en caso de un descanso con AWS. Esta elección de mono-nube, que no ha sido fácil, resulta de un sesgo asertivo, que llega a basarse en los detalles de las arquitecturas de este proveedor.

¿Cómo gestiona los enlaces con sistemas externos, como la gestión de las reservas de SNCF?

Desde su rediseño en SNCF Connect, nuestro sitio de comercio electrónico ha registrado más visitas para encontrar rutas punto a punto y la agregación de la información del viajero, que puede provenir de fuentes muy variadas, que para la distribución de boletos estrictamente hablados. Para producir SNCF Connect, pero también todos los demás servicios digitales, una gran cantidad de interacciones con sistemas de tercera parte y/o alojados por otra entidad son, por lo tanto, es esencial.

En nuestro contexto marcado por volúmenes muy grandes, tratamos la cuestión de los tiempos de respuesta de terceros principalmente con cortes de circuito. Por ejemplo, en un saludo, además de un boleto de tren, el sitio puede ofrecer un servicio de alquiler de automóviles, a través de una llamada a terceros. Pero, si el tiempo de respuesta no es satisfactorio, esta llamada se cortará automáticamente para no degradar nuestro propio servicio. Cuando un servicio externo está directamente en el viaje de compra de un título de transporte o en el curso de consulta de la información del viajero, lo que implica la solicitud de socios internos para el grupo con mayor frecuencia, los recortes de circuitos ya no pueden ser automáticos, dependiendo de los escenarios. Porque, en algunos casos, un corte puede tener un impacto en las propuestas comerciales en el corazón de nuestra actividad. Por ejemplo, si la desaceleración afecta a uno de los sistemas de reserva SNCF - Inoui, Ouigo, Ouigo España SNCF, el corte se activaría solo por decisión, en caso de un incidente grave.

Sin estos cortes de circuito, debido a los volúmenes que recolectamos, cualquier degradación de los tiempos de respuesta dará como resultado una acumulación de solicitudes en la aplicación. Por lo tanto, es necesario encontrar un equilibrio. Cortar el circuito le permite vaciar la bañera.

¿Cómo se calcula este punto de equilibrio y se asegura de que sea relevante?

Experimentamos estos mecanismos con disparos de carga, permitiendo simular la temperatura extrema y las condiciones de presión, y al introducir perturbaciones de acuerdo con los principios del caos de ingeniería. Este enfoque está muy anclado en nuestras prácticas de producción, porque las rutas: cálculo de rutas, canasta, pago, etc. implementadas en nuestra solicitud de solicitud muchos ladrillos de aplicación, ya sea que estemos hablando de capas de seguridad, componentes de la oficina principal o back office. Cada equipo de DevOps a cargo de un componente es responsable de llevar a cabo sus propias tomas de carga para cumplir con sus niveles de servicio. Y, por supuesto, estamos completando pruebas de extremo a extremo, para validar que toda la cadena se comporta bien.

¿Cómo evolucionan los usos del caos de ingeniería interna?

Durante los últimos dos años, hemos estado trabajando mucho en desgloses de desgloses y disturbios, a menudo inspirados en hechos reales. Lo usamos para experimentar la resistencia de los sistemas y equipos, para medir cómo reaccionan a estos escenarios. Además, incluso si no lo habíamos anticipado necesariamente, estos escenarios también sirven mucho en capacitación para operaciones y equipos de apoyo.

Por el momento, las tomas de carga se llevan a cabo tanto en la producción como en los entornos de preproducción, incluso si es un poco más ligero en el primero, mientras que los escenarios de ingeniería del caos solo se juegan fuera de producción. ¡Pero nuestro objetivo es extenderlos a la producción también!

En la arquitectura del 100% en la nube, ¿cuáles son los principales problemas del equipo de producción?

Ser 100% en la nube nos permite ir más allá en la búsqueda de la calidad del servicio. Debido a que nos detenemos los problemas de las averías físicas (discos, complementos de red, etc.) a través de entornos extremadamente resistentes por construcción. También heredamos muchos mecanismos de resiliencia, a través del alojamiento en tres zonas de AWS, y a escala automática, mediante el uso de Kubernetes esencialmente. Por lo tanto, podemos dedicarnos a nuestros procesos de producción, como cambiar los cambios. Asegure su robustez, para la gestión de un incidente o una crisis. Trabaje en nuestros comentarios de la experiencia después de un evento o un montón de campaña de carga. Configure los mecanismos de retorno trasero derecho o la definición correcta de estándares de hipervisión. La vida diaria de mi equipo es centrarse en la calidad.

¿Ha desplegado mecanismos de auto reparación para su infraestructura (autoinforme)?

Estos escenarios son bastante fáciles de implementar en desgloses simples, como expulsar y reconstruir una entidad que no responde incorrectamente dentro de un grupo de recursos. Como estamos al 100% como arquitecturas de infraestructura de código desde la migración de la nube, incluso si hemos pasado de la tecnología de hogar a Terraform, solo fuera de esta entidad del flujo y reconstruye otra.

Pero, muy a menudo, los incidentes que tienen un impacto real en la producción resultan de varios factores o son la combinación de varios eventos. El análisis de uno o más expertos es a menudo necesario. De ahí el interés en pensar en estos escenarios y simularlos. Especialmente porque a menudo son escritos por las personas más experimentadas de la organización e implementadas por el resto del equipo, lo que permite una transmisión de conocimiento.

¿Cómo se gestiona los picos de carga, ya sea que estén planeados, debido a la apertura de la venta de boletos de tren durante un período o resultado de eventos imprevistos, como los incendios que afectaron las líneas TGV aguas arriba de la ceremonia de apertura olímpica?

Hemos definido tres plantillas estándar, documentadas y activadas: una plantilla normal, una plantilla de apertura de ventas y un viajero orientado orientado a las ventas. Cuando el 31 de julio, por ejemplo, las líneas se cortaron debido a eventos meteorológicos, este tamaño se activó para garantizar intercambios y reembolsos y entregar información del viajero. Estas plantillas se activan relativamente rápido, en menos de una hora. Entonces, incluso cuando estamos sorprendidos por un evento, podemos reaccionar relativamente rápido. Además, tenemos un cierto margen en nuestra plantilla estándar, junto con mecanismos de protección como salas de espera.

Con el tiempo, estas plantillas tienen cada vez menos recursos debido a la adaptación de nuestras arquitecturas para adoptar las tecnologías de la nube. Por ejemplo, pasar de VM a entornos Kubernete, en esencia listos para la escala automática. Por nuestra parte, tenemos cada vez menos acciones que hacer en la implementación de estas plantillas.

¿Estas arquitecturas también se han adaptado a las especificidades de su proveedor de nubes? ¿Y cuál es el impacto de este trabajo en términos de costos?

Podemos esquematizar esta adaptación de las arquitecturas con tres generaciones de cargas de trabajo: VM en la nube, los grupos de orquestadores de contenedores y la función como servicio, como los servicios Lambda en AWS. Muchos pasajes de VM a los grupos de Kubernetes tuvieron lugar tan pronto como la migración a la nube. Además, durante tres años, algunos proyectos que se ejecutan en VM cambian a la segunda o tercera generación. Y cualquier proyecto nuevo se está desarrollando en estas dos últimas generaciones. [Actuellement, l'infrastructure de SNCF Connect & Tech tourne sur environ 35% de VM, 50% de clusters Kubernetes et 15% de serverless, NDLR].

Estas refactorizaciones permiten efectivamente los recursos para el uso más justo, por lo tanto, una reducción en los costos, asociado con los mecanismos de escala automática. La transición de máquinas virtuales a Kubernetes se promueve a equipos de aplicación a través de las economías sustanciales que genera, ahorrando variable dependiendo de los proyectos. Pero, muy a menudo, estamos hablando de una división por dos de la factura. Sin embargo, son los equipos de aplicación los que llevan su presupuesto en la nube.

En realidad, se asocian dos palancas finas grandes. El primer enfoque en el uso de la mecánica contractual de nuestro proveedor, que ofrece varios planes de optimización. Y el segundo consiste en ajustar el consumo a la más justo, un ejercicio con un rendimiento decreciente con el tiempo. Encontrar las ganancias superiores a las primeras evidencias requiere ingeniería.

A menudo presenciamos la fricción entre los equipos de producción y la aplicación sobre este tema, ¿el reflejo del primero es maximizar el rendimiento para garantizar la disponibilidad?

Este es uno de los elementos que me llamó la atención al llegar al grupo: somos lo suficientemente resistentes como para escucharnos con los finos. Desde mi llegada, no he asistido a un desglose significativo. En 2023, mostramos una duración promedio de incidentes de 50 minutos. Por lo tanto, estos incidentes se cierran o se omiten muy rápidamente, incluso si el problema puede dar lugar a un proyecto de mejora implementado más adelante. Más del 90% de los principales incidentes de SO, que se caracterizan en umbrales muy bajos, como una tasa de falla más del 10% en la respuesta de un servicio, provienen de perturbaciones provenientes de los socios.

Además, como la cultura de producción se difunde ampliamente en los equipos de DevOps, incluso entre los perfiles de desarrolladores, las discusiones son bastante naturales. Si las recomendaciones de Finops se han reducido demasiado justas, tenemos la capacidad de regresar tomando momentáneamente la carga a través de nuestros mecanismos de resiliencia.

¿En qué proyectos de innovación estás trabajando en este momento?

Trabajamos mucho en Hypervision, la supervisión de los canales de servicio en la transacción en lugar de en indicadores globales y umbrales de alerta. Y esto, de principio a fin. El objetivo es tener una visión en un lugar en el viaje del cliente, con las métricas de los componentes solicitados, pero también de sus interfaces. Esta transición a la hipervisión debe ayudar a acelerar el diagnóstico de perturbaciones, a través de una visión orientada al servicio. El proyecto, llevado a cabo por el momento en la tecnología Datadog, está en desarrollo. La hipervisión de los primeros canales de servicio debe implementarse durante el cuarto trimestre, a más tardar.