CMG impacto 2016 revisión de la conferencia

Este artículo está dedicado a la conferencia, que se celebró hace casi 2 años. ¿Por qué escribir sobre eventos tan antiguos? En primer lugar, en mi opinión, no mucha gente sabe acerca de esta conferencia. En segundo lugar, mis impresiones personales sobre ella son tan fuertes, incluso después de dos años, que no puedo evitar compartirlas. En tercer lugar, realmente quería escribir, pero no estaba muy claro cómo hacerlo, ya que nunca antes había escrito críticas, este es mi tercer intento de escribir sobre esta conferencia. Y, por supuesto, quiero agradecer a la compañía Distillery, en la que trabajaba en ese momento, y a mi supervisor Sergei Meshcheryakov por la oportunidad de asistir a esta conferencia.



La conferencia internacional de impacto CMG se lleva a cabo anualmente por la Asociación Americana de Especialistas en el campo de la mejora del rendimiento de los sistemas de TI. La conferencia anual de CMG se lleva a cabo desde 1980.

La conferencia está dedicada a la ingeniería de rendimiento y la planificación de la capacidad. Los organizadores, oradores y participantes de la conferencia son especialistas altamente calificados en TI o en el campo de la planificación de la capacidad, muchos de los cuales comenzaron a trabajar en mainframes, luego fueron a sistemas distribuidos y actualmente continúan trabajando en empresas líderes en la industria. La calificación de muchos de ellos es asombrosa. Hubo empresas o sus representantes en la conferencia relacionados con el monitoreo o las pruebas del desempeño de Dynatrace, NewRelic, Soasta, Jmeter, BMC, Moviri, BezNext y muchos otros.

En la conferencia se presentaron 120 informes de más de 15 países del mundo, principalmente Estados Unidos, Canadá y países europeos. Se llevó a cabo durante cinco días del 7 al 11 de noviembre de 2016. El modo de operación fue el siguiente: los informes en la sesión plenaria comenzaron a partir de las 8.00 de la mañana y continuaron con informes seccionales en 8 salas hasta las 19.00 de la tarde con un breve descanso para almorzar en la zona de la tarde. Cada día hábil de la conferencia finalizaba con un bufé general, durante el cual era posible comunicarse personalmente con todos los oradores y discutir los informes presentados. Fue bastante difícil elegir a qué informe asistir, ya que en sesiones paralelas los informes de interés se encontraban simultáneamente en diferentes salas.

En este artículo describiré brevemente los informes que más me gustaron.

La Asociación Estadounidense de Especialistas en Mejora del Desempeño del Grupo de Administración de Computadores de Sistemas de TI en 1974 estableció el Premio anual Abraham Michelson por su contribución profesional a la evaluación del desempeño del sistema. Este premio se otorga tradicionalmente en la conferencia de impacto CMG.

Apertura de la conferencia y presentación del Premio Michelson AA

La conferencia se inauguró con el Premio Andrei Bondi AA Michelson, un consultor independiente, autor de Fundamentos de ingeniería de rendimiento de software y sistemas: proceso, modelado de rendimiento, requisitos, pruebas, escalabilidad y práctica.
La primera sesión plenaria comenzó con un informe de Andre Bondi. La idea clave del informe era que el ajuste nunca conducirá a mejoras de rendimiento en ocasiones. Según el autor del informe, el mayor incremento en la productividad puede obtenerse eliminando errores arquitectónicos en el sistema. Creo que muchos de ustedes saben esto por experiencia personal. En el transcurso de mi carrera, he llegado a la misma conclusión. Por ejemplo, pasar de un sistema aparentemente más productivo a un sistema de código abierto más modesto puede aumentar el rendimiento si, durante la transferencia, el equipo elimina los errores arquitectónicos de la versión anterior del sistema.

Logro de escalabilidad y rendimiento> 1 millón de usuarios simultáneos a la vez
Lukas Sliwka, Grindr

La siguiente presentación interesante para mí fue el informe de aquellos. Director de Grindr, Lucas Cream. Grindr es una aplicación de citas en línea. Lukash habló simultáneamente sobre la transformación de la empresa, y la cultura de desarrollo (cambiaron a scrum), y sobre la transformación técnica del sistema. Grindr tiene más de 2.5 millones de usuarios, de los cuales 1 millón está activo. Los principales usuarios antes de la conversión estaban en los EE. UU. Y Canadá, a medida que se alejaban de los EE. UU., La cantidad de usuarios disminuyó.



Los servidores y los almacenes de datos también se ubicaron principalmente en los Estados Unidos. Además, la aplicación ya se ha trasladado al servidor más potente posible en el alojamiento, y la empresa se enfrenta al grave problema de la optimización y el escalado. El problema de la optimización y el escalado se resolvió radicalmente: el equipo reescribió por completo todo el proyecto desde Ruby on Rails hasta Scala, tomó seis meses. Se eligió Scala por dos razones: en primer lugar, era posible escribir código limpio con buen rendimiento; en segundo lugar, los desarrolladores de Java estaban más disponibles para contratar, a diferencia de los desarrolladores de Node.js que eran caros y todos trabajaban en Facebook.

La interesante experiencia de Grindr demuestra que para un desarrollo exitoso, a veces se necesita una nueva arquitectura. A continuación, se realizó un análisis de la duración de la respuesta en el contexto de cada país, y resultó que cuanto más larga es la respuesta, menos usuarios hay en este país. El equipo de desarrollo ha optimizado el tiempo de respuesta, reduciéndolo significativamente usando CDN y distribuyendo el almacén de datos en servidores en la nube con centros en Europa, Asia y América Latina. Después de que se resolvieron los problemas de rendimiento, el número de usuarios de la aplicación aumentó en todo el mundo. Este ejemplo demuestra una relación directa entre tiempos de respuesta cortos y el número de usuarios.

La segunda parte del informe se dedicó a la gestión del equipo. Grindr trabaja en Scrum. La separación de los equipos se realiza por producto, es decir, cada equipo es totalmente responsable de algún servicio o producto para el usuario y del valor comercial que recibe el usuario. La empresa es una empresa basada en métricas, y cada equipo tiene sus propias métricas y KPI que deben alcanzar. La gestión de nivel medio está completamente ausente. La empresa tiene una estructura plana y el equipo decide qué debe hacerse y cómo lograr sus objetivos. Los informes de Lukash están en YouTube . La entrevista de Lucas está disponible aquí .

¿Su capacidad está disponible?
Igor Trubin, Capital One Bank

Es interesante que el autor comenzó su informe con información de que el banco Capital One decidió convertirse en una empresa abierta a la información. Es bien sabido que los bancos generalmente no hablan de tecnologías y procesos. Utilizado en su trabajo, considerando esta información confidencial. Sin embargo, en el mundo moderno, para competir por los principales especialistas y sus talentos, que generalmente funcionan en Google y Facebook, los bancos deben ser más abiertos.

El informe se dedicó a evaluar la combinación de la disponibilidad del sistema y su margen de rendimiento. Dado que nadie necesita ancho de banda que no se pueda usar.

Igor describe una forma específica de cómo puede medir su capacidad y su disponibilidad. Tiene métricas como el tiempo promedio entre caídas, el tiempo promedio de recuperación, el tiempo de inactividad por un año y otros. Igor ofrece una fórmula con la que puede calcular la disponibilidad de toda su infraestructura para los usuarios. Puedes ver su informe con más detalle.

Planificación de capacidad de experiencia digital
Amy Spellmann y Richard Gimark

Charla de planificación para métricas de negocios de IoT, métricas de TI y métricas de instalaciones.

Un informe sobre el hecho de que muchas infraestructuras ahora están trabajando cerca del límite de su ancho de banda, y lo que sucederá cuando IoT funcione en todas partes. Para mí, lo más interesante en el informe fue su escala. Es decir, hay profesionales que planifican el sitio, la organización, y esta es toda una industria. ¿Con qué frecuencia llegamos a una visión a gran escala?

Aseguramiento del rendimiento empresarial basado en análisis BigData
Boris Zibitsker

Boris habla sobre BigData y enfoques para trabajar con big data. Identifica las siguientes etapas de trabajo con datos. Análisis predictivo, ya que una empresa debe tomar decisiones basadas en datos actuales. El tiempo es dinero y nada ha cambiado con los años, excepto que el tiempo se ha vuelto aún más caro ahora. La información es costosa si es relevante.
Trabajar con grandes grupos de datos le permite realizar el análisis necesario a tiempo. Boris luego describe los pasos. Dos enfoques principales son hacer análisis de datos en tiempo real en una secuencia o recopilarlos en DataLake.

El informe describe el enfoque de utilizar algoritmos de procesamiento de big data y aprendizaje automático para llevar a cabo RCA en caso de fallas, así como también construir pronósticos basados ​​en dichos informes sobre el comportamiento adicional del sistema.

Un punto importante es verificar la confiabilidad de los resultados, comparando el comportamiento real con el predicho.

Los 10 principales defectos de rendimiento que cuestan millones de organizaciones en línea
Craig Hyde, Rigor y Rigor

Craig describe los 10 errores más caros que afectan el rendimiento del sitio. Craig cita cifras de que, en promedio, una compañía pierde $ 102 millones en potencial por 1 segundo de espera del usuario. Interesante, ¿eh? La compañía hizo un análisis de aproximadamente 500 sitios web y compiló los 10 principales problemas principales que conducen a un bajo rendimiento. Las recomendaciones de Craig sobre el uso de cachés, CDN, configuración de la resolución de imagen correcta, uso de compresión. Pero lo principal es probar lo que sucedió, ya que resultó que muchas personas piensan que usan el caché, pero alrededor del 70% del contenido puede no almacenarse en caché debido a una configuración incorrecta. Craig recomienda establecer una línea de base de rendimiento y apegarse a ella, estableciendo un objetivo de rendimiento para alcanzar, probar y optimizar los cuellos de botella. Prueba de herramientas de prueba de página web, google analytics, velocidad de página, informe sin rigor. Lo más divertido para mí fueron las imágenes en sitios en una gran extensión, mientras que el tamaño no me permite evaluar esto, por lo que una disminución en la resolución no conduce a un deterioro en la calidad.

No pude encontrar las diapositivas de Craig, pero aquí hay un informe sobre el mismo tema de uno de los empleados de la compañía.

Negocio arriesgado
Jeff Buzen

Algunas palabras sobre Jeff: es profesor en Harvard, autor de 3 libros, el primero se publicó en 71 y el último en 2015 - Repensar la aleatoriedad: una nueva fundación para el modelado estocástico, artículo wiki , Entrevista con Jeff .

Informe sobre el rendimiento de modelado y pronóstico. Jeff describe los riesgos que surgen al modelar un sistema (riesgo de modelo, riesgo de parámetros de carga del sistema, riesgo de pronóstico, riesgo de aplicación, riesgo de uso) en el trabajo. Jeff describe en detalle todos los riesgos posibles que surgen al modelar el sistema e intenta predecir cuántos recursos se requerirán y qué tipo de disponibilidad del sistema se necesita. Opciones, ya que no es necesario escribir SLA: el 90% de las solicitudes se ejecutan en 0,5 segundos. Menos riesgoso: la longitud de la cola es inferior al 33x90% del tiempo. Su libro es sobre eso. El pronóstico que usamos de las matemáticas clásicas no siempre da los resultados correctos aplicables, aunque las fórmulas pueden ser correctas. Las predicciones dependen mucho de los supuestos del modelo. Es más preferible usar un pronóstico basado en un análisis de alternativas (AoA, Análisis de Alternativas).

Me senté y pensé, ¿qué tan lejos está esto de mi experiencia? Oh, todavía tenemos un margen de productividad en 2 veces, ¿qué? ¿Cómo te enteraste? Bueno, hubo un pico y las colas ya se estaban acumulando en el sistema, tomemos un servidor más grande. Que decir Bueno, ¿cuáles son las líneas? Bueno, antes de comenzar a usarlos, el sistema simplemente se cayó. Aquí hay un enfoque de planificación del rendimiento que comienza con un modelo de sistema: algún otro planeta.

¿Cómo obtener valor de BigData?
Renato Bonomini, Stefano Doni, Moviri

El siguiente fue un taller de Moviri . Moviri es una empresa fundada por un profesor de la Universidad Politécnica de Milán, con oficinas en Milán y Boston, especializada en análisis de rendimiento y rendimiento. Acerca de lo importante que es no solo recopilar muchos datos, sino también beneficiarse de ellos. Stack Yarn, HDFS, Pig, Hive, Spark, Zookeeper, Cassandra, Cloudera, Kubernetes. El informe mostró cuánto más conveniente se volvió trabajar con cambios en el rendimiento con sistemas que se ejecutan en contenedores.

Moviri me invitó a mi oficina, lo cual aproveché, ya que aproximadamente un mes después fui a Italia. Fue genial conocer a Stefano Doni y conocer a Luca Forni, ver la oficina y hablar sobre todo lo relacionado con el análisis de desempeño, comenzando con el análisis de desempeño y terminando con los problemas que enfrentan los consultores al comunicarse con el equipo del cliente.

Blog de Moviri .

¿Rendimiento o capacidad? Diferentes enfoques para diferentes tareas
Alexander Gilgur, Facebook

El informe será útil para quienes participan en la predicción del rendimiento y la planificación del ancho de banda. Alexander da ejemplos y enfoques que deberían usarse para cada uno de los casos. En general, aunque los conceptos de capacidad y rendimiento son cercanos, se deben utilizar diferentes métodos para los pronósticos, con énfasis en el objetivo final del trabajo. ¿Por qué estamos haciendo esto? Queremos comprender cuánto equipo necesitamos y qué ancho de banda queremos proporcionar o queremos predecir el rendimiento del sistema.

Aquí puedes leer el artículo de Alexander .
Toboganes

Cómo comenzar cuando no sabes por dónde empezar.
Justin Martin, Cerner

Acerca de por qué en general es necesario hacer un monitoreo del desempeño. Pero la verdad es! Muchos viven sin monitoreo y todo parece estar bien con ellos. De hecho, muchos no lo necesitan. Hasta que publiquen un artículo sobre su maravilloso sitio en el centro, y la gente no vaya a ellos para ver qué hay allí. O hasta que algo más no conduzca a muchos, muchos usuarios.



En el informe, Justin dice simplemente qué se puede hacer para comenzar. Gestión de capacidad en 90 días.

Pasos

1. Determine las horas pico para su sistema
2. Examine los límites de rendimiento de su proyecto (el momento en que el sistema ya deja de procesar solicitudes y el rendimiento comienza a degradarse)
3. Reduce las pérdidas de productividad
4. Equilibre la necesidad: tal vez pueda transferir algunas cargas de las horas pico a las horas menos ocupadas.

Linkedin Justin . Las diapositivas se pueden ver en el artículo sobre la conferencia, que publicaré al final.

Balanceo dinámico de carga y entrega continua de servicios en una infraestructura de Big Cloud
Yuri Ardulov, RingCentral

Yuri describe la transición de RingCentral de un monolito, con un código heredado a microservicios. Los problemas con el código monolítico eran que era difícil cambiar la configuración, no era posible realizar una entrega continua, dificultades para lograr los indicadores de disponibilidad requeridos, no había forma de hacer pruebas A \ B, la capacidad de aplicar nuevas funcionalidades solo para algunos usuarios. El sistema fue rediseñado y se utilizaron contenedores y microservicios en el nuevo diseño, se hizo posible cambiar el tamaño del sistema en línea, la capacidad de cambiar la versión del servicio sin cambiar la configuración. En la arquitectura de microservicio, se asignaron una capa de enrutamiento de aplicación, una capa de equilibrio, una capa de servicio (no almacena el estado). Después de realizar cambios en Ops, los equipos pudieron realizar entregas continuas sobre la marcha, la disponibilidad del sistema aumentó de 4 nueves a 99,998. El tiempo requerido para aumentar el sistema e implementar nuevos servidores se redujo a 4 horas.

Evitar costos, retrasos y lanzamientos fallidos con Lifecycle Virtualization
Todd DeCapua, servicios de marca digital CSC

El informe de Tod se centra en cómo reducir los problemas de lanzamiento y la idea clave es que al probar un programa es importante tener en cuenta todo el ciclo de vida del programa.

4 componentes clave:

1. Usuarios: virtualización de usuarios que simula el comportamiento de los usuarios de su sistema real.
2. Servicios: debe haber una virtualización de servicios para que pueda verificar el funcionamiento de todo el proceso de principio a fin.
3. Red: emula las condiciones de funcionamiento de la red.
4. Datos: virtualización de datos con una venta para simular llamadas de aplicaciones cercanas a lo que sucederá en la realidad.

Según mi experiencia, un gran porcentaje de errores durante la implementación se debe al hecho de que pocas personas cumplen con las 4 condiciones, y el producto siempre tiene algo que nadie esperaba ver, y esto rompe el lanzamiento. Es muy importante utilizar diferentes casos de uso con ventas según los datos y el comportamiento del usuario.

Aquí hay un ejemplo de la presentación de Tod:





Tod - Autor de un libro sobre optimización del rendimiento, pruebas de rendimiento y su interpretación.

El libro cuenta cuán importante es la cultura de las pruebas de desempeño en una organización, cómo se puede incorporar si nadie lo está haciendo ahora. Se dan varios ejemplos de la práctica con una descripción de la tarea que enfrenta el equipo, las opciones para resolverla, el enfoque que eligió el equipo y cuáles fueron las consecuencias en el sistema real. En mi opinión, estas historias a menudo se refieren a lo difícil que es predecir el comportamiento del usuario final, y lo importante que es hacer un pequeño grupo focal de un número finito de usuarios y ver cómo su pronóstico coincide con el comportamiento del grupo focal.

Implementación de DevOps impulsado por métricas: ¡por qué y cómo!
Andreas Grabner, Dynatrace

Informe de Andreas Grabner sobre las prácticas de DevOps en diferentes empresas y por qué es importante el corto plazo2mercado. Andreas utilizó una metáfora muy interesante sobre la fotografía. Muchas personas recuerdan las fotos de la película: tomas una foto, vas a revelar, imprimes y ves que no tiene éxito, pero no tienes forma de volver a tomar la foto, ya que ya estás en el momento equivocado.

Ahora todo es diferente: tomas una foto, la pones en Instagram e inmediatamente recibes comentarios y puedes terminar algo de lo que piden tus suscriptores. Todavía estás en el momento y obtienes una reacción en tiempo real.

Ahora, volviendo al software, como era antes, se planificaron, implementaron, probaron y realizaron nuevas funciones de software, por ejemplo, 1 lanzamiento por año. Y entendieron que dos de cada millones de usuarios necesitaban la funcionalidad que gastaba mucho dinero y esfuerzo. ¿Te ha pasado esto?

Como esta ahora Ágil y la capacidad de hacer lanzamientos al menos todos los días, como lo hace Facebook, es la capacidad de evaluar de inmediato cuánto demandan los usuarios esta funcionalidad, si debe ser ponderada con riffs o mejor tirarla de inmediato y no perder tiempo y energía.

¡Recomiendo el informe a una empresa que está tratando de explicarle a su equipo por qué necesitan Scrum y Agile! Ahora, muchas empresas empresariales con lanzamientos 3 veces al año intentan volverse más rápidas, más delgadas y más ruidosas.



En general, el informe no se trata de esto, sino de cómo construir prácticas DevOps, hacer lanzamientos es a menudo y bueno. Si, eso pasa. Es importante utilizar métricas y monitorear la situación con la aplicación, la carga, realizar la implementación correcta en el proceso. Andreas es un defensor del rendimiento y tiene bastantes informes útiles sobre este tema con diapositivas inusuales y pegadizas.
Aquí hay un informe de Andreas con diapositivas ligeramente diferentes.

Pruebas de rendimiento en nuevos contextos
Eric Proegler, Soasta

Al comienzo de la charla, Eric describió retrospectivamente cómo ha cambiado la arquitectura de sistemas desde 2000, cómo ha cambiado o debería haber cambiado la transición a la nube, y cómo están diseñados los sistemas con la posibilidad de escalar en la nube. Eric da un ejemplo de la práctica cuando una de las compañías de televisión lanzó la votación en una aplicación móvil y solo durante el programa, cuando los usuarios tenían que votar, el sistema no podía soportar la carga y era inaccesible. Con la cultura de las startups, es difícil predecir cuántos usuarios habrá, tal vez se planearon 20 mil y la aplicación alcanzará rápidamente los 50 mil. Hay muchas aplicaciones para probar el rendimiento en la nube BlazeMeter (Jmeter), Selenium, Gatling, Grinder. Son gratuitos, pero visualizar los resultados no es muy conveniente.Por lo tanto, se recomienda usar otra herramienta de visualización (Tableau) o usar su propia base de datos para luego analizar lo que sucedió. Al probar aplicaciones web, es importante asegurarse de que los usuarios de prueba entrantes estén geodistribuidos. Es aconsejable realizar pequeñas pruebas de rendimiento para cada ensamblaje y compararlas con los resultados básicos.

Las diapositivas de Eric se pueden ver en slideshare.

Eric es el autor del blog .

Además de las presentaciones realizadas en la conferencia, también se organizaron varios debates en forma de mesa redonda. Varios expertos condenaron el tema en el formato de un diálogo activo y activo con la audiencia. En mi opinión, este es un formato muy interesante, ya que los participantes de la conferencia podrían compartir su experiencia a menudo impresionante, y uno podría hablar con cada experto y participante, discutiendo temas de interés.

Conversaciones fuera de escena y entre bastidores

Una parte especial de mis impresiones de la conferencia es la comunicación informal con oradores y participantes. Gracias al formato de debates, cenas, mesas redondas y recepciones, puede conocer personas de todo el mundo de diferentes empresas e intercambiar experiencias. Mucha comunicación dentro de la conferencia. Las personas son muy abiertas y están dispuestas a compartir experiencias.

También me gustaría mencionar a Debbie Sheetz. Debbie trabajó en BMC y comenzó su análisis de rendimiento en mainframes. Luego cambió a sistemas distribuidos. Su experiencia en monitoreo es vasta y muy interesante.

También tuve la suerte de chatear con Anush Najarian de MathWorks, cuya experiencia también merece atención.

Desafortunadamente, la cantidad de informes no permite visitarlos a todos, y los informes no se guardan, es decir, no hay forma de revisarlos en casa. Los organizadores usan los artículos para seleccionar oradores, y estos artículos luego se pasan a los participantes de la conferencia, pero no hay materiales de oradores invitados en la colección.

Aquí está el artículo de Anush sobre la conferencia .

El impacto de CMG es una conferencia muy útil e interesante con un excelente ambiente de intercambio de experiencias, al cual recomiendo asistir.