Se sabe que la competencia CTO se prueba solo por segunda vez que se juega este papel. Porque una cosa es trabajar en una empresa durante varios años, evolucionar con ella y, al estar en el mismo contexto cultural, ganar gradualmente más responsabilidad. Y es otra cosa: asumir de inmediato el puesto de director técnico en una empresa con equipaje heredado y un montón de problemas perfectamente notados debajo de la alfombra.

En este sentido, la experiencia de Leon Fayer, que compartió en DevOpsConf , no solo es directamente única, sino que multiplicada por la experiencia y la cantidad de roles diferentes que logró probar por sí mismo durante 20 años es muy útil. Debajo del corte, una cronología de los eventos de más de 90 días y muchos cuentos de los que es agradable reírse cuando le suceden a otra persona, pero que no son tan divertidos de enfrentar en persona.

Leon es muy colorido en ruso, así que si tienes 35-40 minutos, te recomiendo ver el video. Versión de texto para ahorrar tiempo a continuación.


La primera versión del informe fue una descripción bien estructurada del trabajo con personas y procesos, que contiene recomendaciones útiles. Pero ella no transmitió todas las sorpresas que se encontraron en el camino. Por lo tanto, cambié el formato y describí los problemas que la nueva compañía surgió frente a mí como una caja de rapé, y los métodos para resolverlos en orden cronológico.

Un mes antes

Como muchas buenas historias, esta comenzó con alcohol. Nos sentamos con amigos en el bar y, como debería ser entre las personas de TI, todos lloraron por sus problemas. Uno de ellos simplemente cambió de trabajo y habló sobre sus problemas con la tecnología, con las personas y con el equipo. Mientras más escuchaba, más me daba cuenta de que solo necesitaba contratarme, porque precisamente esos problemas había estado resolviendo durante los últimos 15 años. Se lo dije, y al día siguiente ya nos conocimos en un ambiente de trabajo. La compañía se llamaba Estrategias de enseñanza.

Teaching Strategies lidera el mercado de programas educativos para niños muy pequeños, desde el nacimiento hasta los tres años. La compañía tradicional de "papel" ya tiene 40 años, y la versión digital SaaS de la plataforma 10. Hace relativamente poco tiempo, ha comenzado el proceso de adaptación de la tecnología digital a los estándares de la compañía. La versión "nueva" se lanzó en 2017 y era casi como la anterior, solo que funcionó peor.

Lo más interesante es que el tráfico de esta empresa es muy predecible: día a día, año tras año, se puede predecir claramente cuántas personas vendrán y cuándo. Por ejemplo, entre la 1 p.m. y las 3 p.m., todos los niños en los jardines de infantes se duermen y los maestros comienzan a ingresar información. Y esto sucede todos los días excepto los fines de semana, porque los fines de semana casi nadie trabaja.



Mirando un poco más adelante, comencé mi trabajo durante el período de mayor tráfico anual, lo cual es interesante por varias razones.

La plataforma, que parecía tener solo 2 años, tenía una pila peculiar: ColdFusion y SQL Server 2008. ColdFusion, si no lo sabe, pero lo más probable es que no lo sepa, es un PHP empresarial que surgió a mediados de los 90, y desde entonces ni siquiera he oído hablar de él. También hubo: Ruby, MySQL, PostgreSQL, Java, Go, Python. Pero el monolito principal funcionó en ColdFusion y SQL Server.

Los problemas

Mientras más hablaba con los empleados de la compañía sobre el trabajo y los problemas que se encuentran, más me di cuenta de que los problemas no son solo de naturaleza técnica. De acuerdo, la tecnología es antigua, y no funcionaron en eso, pero hubo problemas con el equipo y con los procesos, y la compañía comenzó a entender esto.

Tradicionalmente, los técnicos estaban sentados en la esquina y haciendo parte de su trabajo. Pero cada vez más negocios comenzaron a pasar por la versión digital. Por lo tanto, en la empresa durante el último año antes del inicio de mi trabajo, aparecieron otros nuevos: el consejo de administración, CTO, CPO y QA-director. Es decir, la empresa comenzó a invertir en el campo tecnológico.

Las huellas de la herencia pesada no solo estaban en los sistemas. La empresa tenía procesos heredados, personas heredadas, cultura heredada. Todo esto tuvo que ser cambiado. Pensé que definitivamente no sería aburrido, y decidí probarlo.

Dos dias antes

Dos días antes de comenzar un nuevo trabajo, llegué a la oficina, completé los últimos documentos, me familiaricé con el equipo y descubrí que el equipo estaba luchando con el problema en ese momento. Consistió en el hecho de que el tiempo promedio de carga de la página saltó a 4 s, es decir, 2 veces.



A juzgar por el horario, obviamente sucedió algo, y no está claro qué. Resultó que el problema estaba en la latencia de la red en el centro de datos: la latencia de 5 ms en el centro de datos se convirtió a 2 s para los usuarios. No sabía por qué sucedió esto, pero en cualquier caso se supo que el problema está en el centro de datos.

Primer dia

Pasaron dos días y en mi primer día de trabajo descubrí que el problema no desapareció.



Durante dos días, los usuarios de la página cargaron en promedio 4 s. Les pregunto si encontraron cuál es el problema.

- Sí, abrimos un boleto.
- y?
"Bueno, todavía no nos han respondido".

Entonces me di cuenta de que todo lo que me habían contado antes era solo la pequeña punta del iceberg con el que tenía que luchar.

Hay una buena cita que es muy adecuada para este caso:

"A veces es necesario cambiar la organización para cambiar la tecnología".

Pero desde que comencé a trabajar en la época más ocupada del año, tuve que buscar ambas opciones para resolver el problema: tanto rápido como a largo plazo. Y comience con lo que es crítico en este momento.

Día tres

Entonces, la carga tarda 4 segundos, y de 13 a 15 los picos más grandes.



El tercer día, en este intervalo de tiempo, la velocidad de descarga se veía así:



Desde mi punto de vista, nada funcionó en absoluto. Desde el punto de vista de todos los demás, funcionó un poco más lento de lo habitual. Pero no sucede de esa manera: este es un problema grave.

Traté de convencer al equipo, a lo que respondieron que solo necesitaban más servidores. Esta, por supuesto, es la solución al problema, pero de ninguna manera siempre es la única y más efectiva. Le pregunté por qué no hay suficientes servidores, cuánto tráfico. Extrapolé los datos y obtuve que tenemos alrededor de 150 solicitudes por segundo, lo que básicamente se ajusta a límites razonables.

Pero no debemos olvidar que antes de obtener la respuesta correcta, debe hacer la pregunta correcta. Mi siguiente pregunta fue: ¿cuántos servidores frontend tenemos? La respuesta "me desconcertó": ¡teníamos 17 servidores frontend!

- Me da vergüenza preguntar, 150 dividido entre 17, ¿resultará aproximadamente 8? ¿Quiere decir que cada servidor omite 8 solicitudes por segundo, y si mañana hay 160 solicitudes por segundo, necesitaremos 2 servidores más?

Por supuesto, no necesitábamos servidores adicionales. La solución estaba en el código mismo y en la superficie:

var currentClass = classes.getCurrentClass(); return currentClass; 

Había una función getCurrentClass() , porque todo en el sitio funciona en el contexto de la clase, correctamente. Y para esta función en cada página había más de 200 solicitudes .

La solución de esta manera fue muy simple, no había necesidad de reescribir nada: simplemente no solicite la misma información nuevamente.

 if ( !isDefined("REQUEST.currentClass") ) { var classes = new api.private.classes.base(); REQUEST.currentClass = classes.getCurrentClass(); } return REQUEST.currentClass; 

Estaba muy feliz porque decidí que solo al tercer día encontré el problema principal. Como era ingenuo, este era solo uno de tantos problemas.



Pero la solución a este primer problema redujo el horario mucho más bajo.

Al mismo tiempo, nos dedicamos a otras optimizaciones. A la vista había mucho de todo lo que se puede reparar. Por ejemplo, el mismo tercer día descubrí que todavía había un caché en el sistema (al principio pensé que todas las solicitudes iban directamente de la base de datos). Cuando pienso en un caché, presento el estándar Redis o Memcached. Pero solo pensé que sí, porque para el almacenamiento en caché en ese sistema se usaron MongoDB y SQL Server, el mismo del que se acababan de leer los datos.

Día diez

La primera semana estaba lidiando con problemas que debían resolverse en este momento. En algún momento de la segunda semana llegué por primera vez al stand-up para hablar con el equipo, ver qué está pasando y cómo va todo el proceso.

De nuevo, se descubrió algo interesante. El equipo consistió en: 18 desarrolladores; 8 probadores; 3 gerentes; 2 arquitectos. Y todos participaron en rituales comunes, es decir, más de 30 personas vinieron al stand todas las mañanas y contaron lo que estaban haciendo. Está claro que la reunión no duró 5 o 15 minutos. Nadie escuchó a nadie, porque todos trabajan en sistemas diferentes. De esta forma, 2-3 boletos por hora en la sesión de aseo ya eran un buen resultado.

Lo primero que hicimos fue dividir al equipo en varios a lo largo de la línea de productos. Para diferentes secciones y sistemas, identificamos equipos separados que incluían desarrolladores, probadores, gerentes de producto, analistas de negocios.

Como resultado, recibimos:

• Reducción de stand-ups y rallyes.
• Conocimiento del producto.
• Un sentido de propiedad. Cuando antes las personas solían hablar siempre de sistemas, sabían que alguien probablemente tendría que trabajar con sus errores, pero no ellos mismos.
• Colaboración entre grupos. No puede decir que el control de calidad no se comunicó mucho con los programadores antes, el producto hizo lo suyo, etc. Ahora tienen un punto de responsabilidad común.

Nos centramos principalmente en la eficiencia, la productividad y la calidad: estos son los problemas que intentamos resolver mediante la transformación del equipo.

Undécimo día

En el proceso de cambiar la estructura del equipo, descubrí cómo se cuentan los Story Points . 1 SP era igual a un día, y cada boleto que tenían contenía SP para desarrollo y QA, es decir, al menos 2 SP.

¿Cómo encontré esto?



Se encontró un error: en uno de los informes, donde se ingresa la fecha de inicio y finalización del período para el que se necesita el informe, el último día no se tiene en cuenta. Es decir, en algún lugar de la solicitud no estaba <=, sino simplemente <. Me dijeron que estos son tres puntos de historia, es decir, 3 días .

Después de eso nosotros:

• Se revisó el sistema de calificación de Story Points. Ahora, la reparación de errores menores que pueden pasar rápidamente a través del sistema llega rápidamente al usuario.
• Comenzamos a combinar tickets relacionados para el desarrollo y las pruebas. Anteriormente, cada boleto, cada error era un ecosistema cerrado, no unido a nada más. Cambiar tres botones en una página podría ser tres tickets diferentes con tres procesos de control de calidad diferentes en lugar de una prueba automática en una página.
• Comenzaron a trabajar con los desarrolladores en un enfoque para evaluar los costos laborales. Tres días para cambiar un botón no es divertido.

Vigésimo día

En algún lugar a mediados del primer mes, la situación se había estabilizado un poco, descubrí lo que estaba sucediendo principalmente y ya comencé a mirar hacia el futuro y pensar en soluciones a largo plazo.

Metas a largo plazo:

• Plataforma gestionada Cientos de solicitudes en cada página, esto no es serio.
• Tendencias predecibles. Hubo picos de tráfico periódicos que a primera vista no se correlacionaron con otras métricas; era necesario comprender por qué sucede esto y aprender a predecir.
• Extensión de plataforma. El negocio está en constante crecimiento, cada vez llegan más usuarios y el tráfico aumenta.

A menudo se decía en el pasado: "¡Reescribamos todo en [idioma / marco], todo funcionará mejor!"

En la mayoría de los casos, esto no funciona, bueno, si el reescrito funcionará. Por lo tanto, necesitábamos crear una hoja de ruta: una estrategia concreta que ilustre paso a paso cómo se alcanzarán los objetivos comerciales (qué haremos y por qué), que:

• refleja la misión y los objetivos del proyecto;
• prioriza objetivos clave;
• contiene un horario para su logro.

Antes de esto, nadie había hablado con el equipo sobre qué propósito se hicieron los cambios. Esto requiere las tasas de éxito correctas. Por primera vez en la historia de la compañía, establecimos KPI para un grupo técnico, y estos indicadores estaban vinculados a los de la organización.



Es decir, los KPI de la organización son compatibles con los equipos, y los KPI del equipo ya son compatibles con los individuales. De lo contrario, si los KPI tecnológicos no están de acuerdo con los organizativos, entonces todos se cubren por sí mismos.

Por ejemplo, uno de los KPI organizacionales es aumentar la participación de mercado a través de nuevos productos.

¿Cómo puede apoyar el objetivo de tener más productos nuevos?

• Primero, queremos pasar más tiempo desarrollando nuevos productos en lugar de corregir errores. Esta es una solución lógica que es fácil de medir.
• En segundo lugar, queremos respaldar un aumento en el volumen de transacciones, porque cuanto mayor sea la cuota de mercado, más usuarios y, en consecuencia, más tráfico.

Entonces, los KPI individuales que se pueden ejecutar dentro del grupo estarán, por ejemplo, en el lugar de donde provienen los defectos principales. Si se enfoca en esta sección en particular, puede hacer que la cantidad de defectos sea mucho menor, y luego aumentar el tiempo para desarrollar nuevos productos y nuevamente para respaldar los KPI organizacionales.

Por lo tanto, cada decisión, incluida la reescritura del código, debe respaldar los objetivos específicos que la empresa nos ha establecido (el crecimiento de la organización, nuevas funciones, reclutamiento).

Durante este proceso, surgió algo interesante que se convirtió en noticia no solo para los expertos en tecnología, sino en general en la empresa: todas las entradas deberían centrarse en al menos un KPI. Es decir, si el producto dice que quiere hacer una nueva función, la primera pregunta debe hacerse: "¿Qué KPI admite esta función?" Si no hay ninguna, lo siento, parece que esta es una función innecesaria.

Trigésimo día

A finales de mes, descubrí un matiz más de que ninguno de mi equipo de Operaciones había visto los contratos que concluimos con los clientes. Puede preguntar por qué ver contactos.

• En primer lugar, porque los SLA están registrados en los contratos.
• En segundo lugar, los SLA son todos diferentes. Cada cliente llegó con sus requisitos, y el departamento de ventas firmó sin mirar.

Otro matiz interesante: en el contrato con uno de los mayores clientes, está escrito que todas las versiones de software que admite la plataforma deben ser n-1, es decir, no la última versión, sino la penúltima.

Está claro cuán lejos estábamos de n-1 si la plataforma estaba en ColdFusion y SQL Server 2008, que en julio dejó de ser compatible.

Cuadragésimo quinto día

En algún lugar a mediados del segundo mes, tuve suficiente tiempo libre para sentarme y hacer un mapeo de flujo de valor por completo para todo el proceso. Estos son los pasos necesarios que deben tomarse, desde la creación del producto hasta la entrega al consumidor, y debe pintarlos con el mayor detalle posible.

Divide el proceso en pedazos pequeños y ve lo que lleva demasiado tiempo, lo que se puede optimizar, mejorar, etc. Por ejemplo, cuánto tarda la solicitud del producto, pasando por la preparación, cuando alcanza el ticket que el desarrollador puede tomar, QA, etc. Observa cada paso en detalle y piensa que puede optimizar.

Cuando hice esto, dos cosas me llamaron la atención:

• alto porcentaje de boletos de regreso de QA a los desarrolladores;
• La revisión de la solicitud de extracción tomó demasiado tiempo.

El problema era que se trataba de conclusiones como: parece que lleva mucho tiempo, pero no estamos seguros de cuánto.

"Es imposible mejorar lo que no se puede medir".

¿Cómo corroborar la gravedad del problema? ¿Pasa días u horas?

Para medir esto, agregamos un par de pasos al proceso de Jira: "listo para el desarrollo" y "listo para el control de calidad", para medir cuánto tiempo espera cada boleto y cuántas veces regresa a un determinado paso.



También agregamos "en revisión" para saber cuántas entradas están en revisión en promedio, y es por eso que ya están bailando. Teníamos métricas del sistema, ahora agregamos nuevas métricas y comenzamos a medir:

• Eficiencia del proceso: rendimiento y planificado / entregado.
• Calidad del proceso: número de defectos, defectos de QA.

Realmente ayuda a entender qué está yendo bien y qué está mal.

Quincuagésimo día

Todo esto es, por supuesto, bueno e interesante, pero hacia el final del segundo mes sucedió algo que, en principio, era predecible, aunque no esperaba tal escala. La gente comenzó a irse, porque la parte superior ha cambiado. Llegaron nuevas personas al liderazgo que comenzaron a cambiarlo todo, y los viejos renunciaron. Y generalmente en una empresa que tiene varios años, todos los amigos y todos se conocen.

Esto era de esperar, pero la escala de despidos fue inesperada. Por ejemplo, en una semana, dos líderes de equipo presentaron simultáneamente su propio despido. Por lo tanto, no tuve que olvidarme de otros problemas, sino concentrarme en crear un equipo . Este es un problema largo y difícil, pero tuvo que lidiar con él porque quería salvar a las personas que quedaban (o la mayoría de ellas). Era necesario reaccionar de alguna manera al hecho de que la gente se fue para mantener la moralidad en el equipo.

En teoría, esto es bueno: entra una nueva persona que tiene una carta blanca completa que puede evaluar las habilidades del equipo y reemplazar al personal. De hecho, no puedes simplemente traer gente nueva por tantas razones. Siempre necesito un equilibrio.

• Viejos y nuevos. Necesitamos mantener personas mayores que puedan cambiar y apoyar la misión. Pero al mismo tiempo, necesitamos traer sangre nueva, hablaremos de esto un poco más tarde.
• Experiencia. Hablé mucho con buenos jóvenes que ardían y querían trabajar para nosotros. Pero no pude llevarlos, porque no había suficientes señores que pudieran apoyar a los jóvenes y ser mentores para ellos. Primero fue necesario ganar la cima y solo luego la juventud.
• Zanahoria y palo.

No tengo una buena respuesta a la pregunta de qué equilibrio es correcto, cómo mantenerlo, cuántas personas dejar y cuánto empujar. Este es un proceso puramente individual.

Día cincuenta primero

Comencé a mirar de cerca al equipo para comprender quién tengo, y una vez más recordé:

"La mayoría de los problemas son problemas con las personas".

Descubrí que en el equipo, como tal, tanto los desarrolladores como Ops, tienen tres grandes problemas:

• Satisfacción con el estado actual de las cosas.
• Falta de responsabilidad , porque nadie ha aportado nunca los resultados del trabajo de los artistas para influir en el negocio.
• Miedo al cambio.

El cambio siempre lo saca de su zona de confort, y cuanto más jóvenes son, más no les gusta el cambio porque no entienden por qué y no entienden cómo. La respuesta más común que escuché fue: "Nunca hicimos eso". Y llegó al punto de ser completamente absurdo: los más mínimos cambios no pasaron sin que alguien se indignara. Y no importa cuánto los cambios conciernen a su trabajo, la gente dijo: "No, ¿por qué? No funcionará ".

Pero no puedes mejorar sin cambiar nada.

Tuve una conversación absolutamente absurda con un empleado, le conté mis ideas para la optimización, a lo que él me dijo:
- ¡Ah, no viste lo que teníamos el año pasado!
"¿Y qué?"
"Ahora mucho mejor de lo que era".
"¿Entonces no podría ser mejor?"
- por qué?

Buena pregunta, ¿por qué? Como si ahora fuera mejor de lo que era, entonces todo es lo suficientemente bueno. Esto lleva a una falta de responsabilidad, lo cual es absolutamente normal en principio. Como dije, el equipo técnico fue un poco distante. La compañía creía que deberían serlo, pero nadie estableció estándares . Nunca vieron SLA en soporte técnico, por lo que fue bastante "aceptable" para el grupo (y me llamó la atención):

• Descarga de 12 segundos;
• 5-10 minutos de tiempo de inactividad cada lanzamiento;
• La resolución de problemas críticos lleva días y semanas;
• falta de servicio 24x7 / de guardia.

Nadie intentó preguntar por qué no deberíamos hacerlo mejor, y nadie se dio cuenta de que no debería ser así.

Como beneficio adicional, había otro problema: falta de experiencia . Los mayores se fueron, y el equipo joven restante creció bajo el régimen anterior y fue envenenado por él.

A todo esto, la gente también temía fallar, parecer incompetente. Esto se expresa en el hecho de que, en primer lugar, en ningún caso solicitaron ayuda . ¿Cuántas veces hemos hablado en grupo e individualmente y dije: "Haga una pregunta si no sabe cómo hacer algo". Tengo confianza en mí mismo y sé que puedo resolver cualquier problema, pero llevará tiempo. Por lo tanto, si puede preguntarle a alguien que sepa cómo resolverlo en 10 minutos, lo preguntaré. Cuanta menos experiencia tenga, más miedo tendrá de preguntar porque cree que se lo considerará incompetente.

Este miedo a hacer una pregunta se manifiesta en formas interesantes. Por ejemplo, usted pregunta: "¿Cómo le está yendo con esta tarea?" - "Faltan un par de horas, ya la estoy terminando". Al día siguiente, si vuelve a preguntar, obtiene la respuesta de que todo está bien, pero hubo un problema, estará listo al final del día. Pasa otro día, y hasta que presionas contra la pared y obligas a alguien a hablar, todo continúa. Una persona quiere resolver el problema por sí mismo, cree que si no lo resuelve, será un gran fracaso.

Es por eso que los desarrolladores exageraron . Fue esa broma cuando discutieron una tarea específica, me dieron tal cifra que me sorprendió mucho. A lo que me dijeron que en las estimaciones, el desarrollador incluye el tiempo en que el boleto regresará del control de calidad, porque encontrarán errores allí, y el tiempo que llevará el RP, y el tiempo que las personas que necesitan verlo estarán ocupadas, es decir, todo eso solo es posible.

En segundo lugar, las personas que tienen miedo de parecer incompetentes, analizan innecesariamente . Cuando dices qué es exactamente lo que hay que hacer, comienza: "No, pero ¿qué pasa si pensamos aquí?" En este sentido, nuestra empresa no es única, es un problema juvenil estándar.

En respuesta, presenté las siguientes prácticas:

• La regla es de 30 minutos. Si en media hora no puede resolver el problema, pídale ayuda a alguien. Esto funciona con un éxito variable, porque la gente todavía no pregunta, pero al menos el proceso ha comenzado.
• Excluya todo, excepto la esencia , al estimar el término de la tarea, es decir, considere solo cuánto tiempo lleva escribir el código.
• Educación continua para quienes analizan en exceso. Es solo un trabajo constante con las personas.

Sexagésimo día

Mientras hacía todo esto, es hora de calcular el presupuesto. Por supuesto, encontré muchas cosas interesantes sobre dónde gastamos el dinero. Por ejemplo, teníamos un rack completo en un centro de datos separado, en el que había un servidor FTP que usaba un cliente. Resultó que "... nos mudamos, pero él se quedó, no lo cambiamos". Eso fue hace 2 años.

De particular interés fue la factura del servicio en la nube. Estoy seguro de que la razón principal de la gran factura de los servicios en la nube son los desarrolladores que tienen acceso ilimitado a los servidores por primera vez en sus vidas. No necesitan preguntar: "Por favor, denme un servidor de prueba", pueden responder. Además, los desarrolladores siempre quieren crear un sistema tan genial para que Facebook tenga envidia de Netflix.

Pero los desarrolladores no tienen experiencia en la compra de servidores y la capacidad de determinar el tamaño correcto de los servidores, porque no lo necesitaban antes. Y, por lo general, no comprenden completamente la diferencia entre escalabilidad y rendimiento.

Resultados del inventario:

• Dejamos un centro de datos.
• Terminado el contrato con 3 servicios de registro. Debido a que teníamos 5 de ellos, cada desarrollador que comenzó a jugar con algo tomó uno nuevo.
• Apagó los sistemas 7 AWS. Nuevamente, nadie detuvo los proyectos muertos, todos continuaron trabajando.
• Costes de software reducidos en 6 veces.

Septuagésimo quinto día

Pasó el tiempo y después de dos meses y medio tuve que reunirme con la junta directiva. Nuestra junta directiva no es mejor ni peor que otras; quiere saberlo todo como todas las juntas directivas. Las personas invierten dinero y quieren entender cuánto encaja lo que hacemos en los KPI establecidos.

La Junta Directiva recibe mucha información cada mes: la cantidad de usuarios, su crecimiento, qué servicios usan y cómo, productividad y productividad, y finalmente, la velocidad promedio de carga de la página.

El único problema es que creo que el valor promedio es pura maldad. Pero la junta directiva es muy difícil de explicar. Están acostumbrados a operar con números agregados, y no, por ejemplo, por la extensión del tiempo de carga por segundo.

En este sentido, hubo puntos interesantes. Por ejemplo, dije que necesita dividir el tráfico entre servidores web individuales según el tipo de contenido.



Es decir, ColdFusion pasa por Jetty y nginx y lanza páginas. Y las imágenes, JS y CSS pasan por un nginx separado con sus propias configuraciones. Esta es una práctica bastante estándar sobre la que escribí hace un par de años. , … 200 .



, , Jetty. — . , , , - 12%?

, — . , , .



— , . . - , .

Conclusión

. , , , . , , SEQUENCE . nextID , .

, . , , — .



. , :

• ;
• ;
• ;
• ;
• ;
• ;
• .

.

twitter , facebook medium .

legacy : , . c DevOpsConf , . youtube , , DevOps.