Hablando de la Gestión de Calidad de Plataformas Masivas

讲师介绍：在互联网电商公司，做质量保障和技术保障10年+，之前在1号店做质量总监和高级技术总监,负责企业信息化平台研发、自动化运维开发、质量保证、工程效率、CI/CD、敏捷开发转型、中间件研发等工作。长期深度参与千人研发团队规模的业务成长、架构演进、敏捷开发转型、工程效能建设、过程改进与度量、软件测试等从0到1、从1到N的多年变革过程和创新实践。担任过多年公司周年庆、双11等大促活动的技术保障总负责人和总指挥。

El tema de hoy no se puede separar de DevOps y agilidad. Desde la perspectiva de la calidad, echemos un vistazo a cómo se realiza la calidad en el ecosistema DevOps. Debido a las limitaciones de tiempo, compartiré mis pensamientos y casos reales desde una perspectiva integral.

1. Comprenda la calidad

Primero mira qué es la calidad. Mire hacia atrás en los accidentes de calidad en la historia.

• El primer accidente fue un satélite japonés, que perdió 1.800 millones debido a una línea de código incorrecto.

• El segundo es mi ejemplo anterior. Tenemos un desarrollo. Necesitamos cambiar la configuración a las dos o tres de la mañana y ajustar el despertador, pero el despertador no suena. La empresa perdió un pedido de 20.000 yuanes.

• El tercero también es cierto equipo nuestro en la historia. Esa vez se conectó sin cambiar ningún código. Como resultado, el pedido bajó unos puntos y la empresa perdió un pedido de 40.000 yuanes.

Excepto por el primer ejemplo, los otros ejemplos parecen no tener nada que ver con el código, y estos son incidentes de calidad ¿Qué es exactamente la calidad? ¿Es una cuestión del departamento de calidad?

Además de la función, ¿qué características hay en las características de calidad? (Interacción en vivo)

Estos aspectos se utilizan a menudo en el desarrollo de software, a saber, función, rendimiento, seguridad, facilidad de uso y fiabilidad. En el departamento de I + D, el enfoque de cada función es diferente. Los ingenieros de I + D prestan más atención a las funciones y el desempeño, el departamento de seguridad presta más atención a la seguridad y el departamento de operación y mantenimiento presta más atención a la confiabilidad y el desempeño, cada uno con su propio enfoque.

El ingeniero de calidad es un rol que puede prestar plena atención a todos los aspectos de la calidad del producto, y también es un rol que promueve otros roles para prestar atención a la calidad de manera integral.

En los últimos tres años, he hecho más para controlar de manera integral los riesgos técnicos en términos de negocio, desarrollo, arquitectura, operación y mantenimiento, y seguridad. El control de riesgos técnicos es responsable del negocio de la empresa, no solo si no hay ningún problema con la función, está bien. Tengo un resumen más completo en un intercambio de garantías técnicas de promoción del comercio electrónico de 2015. Aquí hablaré principalmente sobre el trabajo de control relacionado con la calidad en la actualidad.

Entonces, ¿qué aspectos están involucrados en la gestión de la calidad? No lo discutiremos desde la teoría académica por el momento. Basándome en mi experiencia en la gestión de la calidad de Internet durante los últimos diez años, llegué a la conclusión de que la gestión de la calidad de las aplicaciones de Internet implica principalmente la gestión de versiones, la gestión de cambios, la gestión de riesgos, la gestión de defectos, Estos aspectos de la gestión de la configuración. Desde el panorama del aseguramiento de la calidad que se comentará más adelante, también se puede ver mi punto de vista.

2. Pensamiento, desafíos, tendencias

---

Echemos un vistazo a los desafíos que enfrenta la calidad del sistema de Internet.

En primer lugar, desde la perspectiva del sistema, es una prueba de acceso empresarial masivo.

Para el negocio principal, no hace falta decir que la importancia, una vez que ocurre un error, incluso en unos pocos minutos, puede ser una pérdida de capital directa de varios millones a cada paso. Al mismo tiempo, negocios que no parecen estar en el camino principal, como algunos módulos que pueden reflejar sus propias características y diferencias en la experiencia del usuario, aumentar la adherencia del usuario o aquellos que pueden impulsar la conversión y el crecimiento de los principales negocio.

Estos módulos comerciales tienen errores. Si se observa todo el mercado comercial de la empresa, solo hay una tasa de error del 1%. De hecho, afecta a decenas de miles a cientos de miles de DAU. Si agrega la amplificación del factor pico, el número de usuarios será muy grande.

Yo llamo a estos puntos de garantía empresarial de cola larga. Por lo tanto, ya sea el negocio principal o el negocio de cola larga, afecta el desempeño de una determinada parte del negocio y los productos de la empresa.

Para el equipo de I + D, especialmente el de calidad, no se puede ignorar la probabilidad del 1%, aquí es donde los tradicionales "Veintiocho Principios" no pueden guiarnos. Ésta es la presión y el desafío que suponen los servicios masivos para garantizar la calidad. Esta es también la tendencia inevitable de la industria del desarrollo de software en el futuro.

En segundo lugar, desde una perspectiva empresarial. El año pasado, JD.com propuso la estrategia "*** retail" El nuevo modelo de negocio es también un nuevo desafío para el equipo de I + D.

• En primer lugar, sus necesidades comerciales provienen de una variedad de usuarios, incluidas empresas internas, comerciantes externos y clientes en línea ...

• En segundo lugar, con el enorme volumen, el negocio seguirá creciendo rápidamente;

• En tercer lugar, en términos de complejidad técnica, el terminal que transporta los servicios no es solo la aplicación principal, sino también WeChat, QQ, mini programas y otros productos de aplicaciones extendidos. El auge del Internet de las cosas inteligente ha permitido que los productos de software se desarrollen desde el terminal de telefonía móvil a otros terminales, como refrigeradores, altavoces, televisores, etc.

• Al mismo tiempo, en términos de eficiencia de ingeniería, se plantean requisitos más altos para una implementación ágil: la respuesta comercial y la entrega deben ser rápidas, mientras que la calidad y la experiencia deben estar garantizadas.

• Además, la escala de investigación y desarrollo de miles de personas significa que hay una gran cantidad de departamentos trabajando juntos, por lo que los requisitos para la eficiencia colaborativa también son altos.

  Como puede ver, en realidad hay muchos conflictos aquí. A veces, para ponerse al día y conectarse en línea, debe sacrificar un poco de calidad, y a veces hay problemas de eficiencia en la comunicación entre departamentos y el ciclo de programación es muy ajustado. Entonces esto es algo muy difícil.

En tercer lugar, el desafío de la transformación ágil.

Este es el desafío que experimenté personalmente cuando estaba haciendo una transformación ágil en 2013. Como se mencionó anteriormente, el negocio de la compañía está creciendo rápidamente, el equipo de I + D está cerca de mil personas, la complejidad de la tecnología del sistema está aumentando y la eficiencia de la colaboración entre equipos enfrenta desafíos ... Por lo tanto, para mejorar las capacidades de entrega, no se puede expandir la escala indefinidamente Resuelva el problema de la mejora de la eficiencia.

En el proceso de transformación ágil de pruebas, los medios técnicos y la división de roles están cambiando, por lo que el número de personas también está cambiando.

La siguiente figura muestra los cambios en el personal del equipo de prueba ágil. Los números en la imagen pueden ser tristes para el equipo de prueba. Por supuesto, al jefe le gusta más este número porque los costos laborales de la empresa están disminuyendo o el negocio está creciendo, pero los costos laborales están efectivamente controlados.

Entonces, a partir de la situación general, debemos darnos cuenta de que esta es una tendencia, y también es el objetivo correcto de la reforma ágil y la eficiencia de la construcción.

3. Construir un sistema de calidad de plataforma masiva

3.1 Cómo construir un sistema de garantía

Ante tales desafíos, ¿cómo construir un sistema de aseguramiento de la calidad?

1. En primer lugar, desde la dirección, en el diseño de la estructura organizativa, debe haber cambios y ajustes. Este es el formulario requerido por la estructura de la organización de gestión de la calidad, incluido el grupo de prueba empresarial, el grupo de apoyo de aceptación, el grupo de plataforma marco, el grupo de gestión de la configuración, el grupo de auditoría de procesos, el grupo de planificación de procesos y el grupo de riesgo técnico. Todos ellos están involucrados en los equipos que he traído antes. Dependiendo de la situación y etapa del departamento de I + D, las figuras enumeradas en la figura pueden ser personajes virtuales o una organización física.

2. Si el negocio correspondiente de I + D involucra múltiples plataformas, en este momento, un equipo de prueba solo puede apuntar a una determinada plataforma vertical, que requiere el apoyo de un equipo horizontal que no sea el vertical. Este es el propósito del grupo de apoyo para la aceptación del diseño.

3. La auditoría de proceso es auditar el proceso de I + D. La planificación del proceso es planificar la plataforma de gestión y la mejora del proceso. El grupo de riesgo falta en muchos equipos. Los requisitos para este equipo son relativamente altos y requieren capacidades integrales.

4. Los otros grupos son más fáciles de entender literalmente, así que no diré más.

3.2 Sistema de garantía de calidad de JD

Para la recepción de Jingdong Mall, la línea de productos involucrada es muy rica y lo mencioné cuando hablé sobre los desafíos. Los objetos probados que llevan el negocio se extienden desde APP, dongdong, applet, etc. Este diagrama esquemático describe esta complicada situación. ¿Qué se incluye en la garantía de calidad en este momento?

Aquí trato de resumir y resumir un conjunto de sistemas adecuados para la referencia de la industria de pruebas de Internet.

La siguiente imagen es una imagen panorámica del sistema de garantía de calidad que pensé y resolví. Permítanme hablar un poco sobre ello.

Hay dos aspectos: el izquierdo se basa en la tecnología, el derecho se basa en la gestión y los dos lados son complementarios. En la esquina superior izquierda está la estrategia de prueba. Cada empresa formulará su propia estrategia de prueba basada en su propia experiencia, lecciones y características comerciales. El modelo de estrategia que resumí aquí espera ser una referencia para mis compañeros.

Comenzando desde la prueba de caja blanca, hasta la prueba especial de función de la aplicación, rendimiento, API y microservicios, experiencia de usuario y personalización. Esta es la tarea central y principal del equipo de prueba. Estas definiciones pueden resolver la cuestión de si la estrategia está completa. Entonces, si se puede implementar y si se puede implementar de manera efectiva es el problema que la plataforma de calidad y la gestión de procesos del lado derecho deben ayudar a resolver.

La plataforma de calidad incluye una plataforma de gestión de la calidad, una plataforma de ejecución de pruebas y una plataforma de seguimiento de pruebas. Hay una pequeña diferencia entre monitoreo y operación y mantenimiento: una parte es para el código y la otra es para el monitoreo de la calidad del servicio. La gestión y mejora de procesos incluyen especificaciones estándar de procesos, gestión de problemas de incidentes, medición y mejora de procesos, gestión de ejercicios, auditoría de cumplimiento e implementación de enfoques ágiles. La gestión cuantitativa incluye un modelo de evaluación de capacidades, un modelo de medición ágil, un modelo de medición de productos de plataforma y una plataforma de medición de calidad.

Los productos de plataforma son que tenemos una gran cantidad de plataformas, ¿cómo medimos la calidad de estos productos? Esto también debe tenerse en cuenta, se trata de un conjunto de productos que respalda todo el proceso de I + D.

3.3 Construcción de las "Cuatro Modernizaciones" de JD

Mi resumen de la construcción de eficiencia de ingeniería es: Construcción de "cuatro modernizaciones", a saber, estandarización, automatización, bloques de construcción e inteligencia.

3.3.1 Construcción de estandarización

La construcción de la estandarización incluye sistemas, aplicaciones, configuraciones, personas, roles, así como organización, equipo y desempeño. El establecimiento de la mayoría de los estándares y normas está dirigido por una organización de definición de procesos, como un equipo de control de calidad. Lo más difícil es organizar el equipo y el desempeño, esto solo se puede resolver de manera efectiva trabajando desde el nivel de toma de decisiones de gestión de I + D y requiere innovación en la gestión.

Déjame darte el ejemplo de Yihaodian. En el trabajo diario, a menudo implica solicitar que una aplicación esté en línea, ampliar su capacidad o solicitar acceso a la biblioteca de códigos, etc. Estos enlaces deben revisarse y aprobarse. Cuando estamos trabajando en plataformas como plataformas de lanzamiento de operación y mantenimiento, plataformas de administración de base de código, etc., quién debe aprobar estos enlaces de auditoría, lo que involucra el tema de la estructura organizacional.

En el mismo departamento, decenas de personas o incluso cientos de personas, algunas están en Beijing, otras en Shanghai y el jefe de departamento es la misma persona. La estructura organizativa del personal es relativamente plana y solo hay departamentos de tres niveles como máximo, y no hay departamento de cuatro niveles.

No es necesario involucrarlo en estos asuntos de aprobación y confirmación, solo la confirmación del líder de un equipo en Shanghai o Beijing. O, a veces, es un proyecto de equipo cruzado que involucra múltiples líneas de negocio, y el ciclo del proyecto no es corto, y varios departamentos transfieren personal para completarlo juntos.

En este proyecto, hay una persona a cargo. En términos de relaciones administrativas, él puede ser solo el superior de una determinada parte del proyecto, y otras personas en el proyecto no pertenecen al equipo bajo su jurisdicción, y la revisión y aprobación pertinente de este proyecto necesita que el líder sea responsable.

Entonces no hay forma de resolver el problema de la cadena de aprobación a través de los datos actuales del personal de la organización administrativa ¿Qué debo hacer? De hecho, si lo piensas de nuevo, la situación mencionada anteriormente no es solo una cuestión de aprobación, sino que también involucra todos los aspectos de la comunicación, la colaboración, la toma de decisiones y la gestión diaria del equipo durante todo el proceso de I + D.

Por tanto, la solución más completa es encontrar una solución en la estructura organizativa. Creamos una nueva organización de entidad llamada Dominio. Esta organización se basa en la estructura organizativa de personal existente para derivar una nueva estructura de equipo de entidad. El tamaño y la división del Dominio lo determina el gerente de acuerdo con ciertos estándares. Los datos del dominio no son mantenidos por el departamento de personal, pero son mantenidos y administrados por un equipo en el departamento de I + D.

Este ejemplo es un ejemplo de cómo promovimos el desacoplamiento de sistemas en el proceso de implementación ágil en 2014. A menudo escuchamos que cierto sistema está desordenado y hay muchos problemas, específicamente dónde está el problema.Solo un pequeño número de ingenieros de primera línea en este equipo que están familiarizados con la situación saben dónde está el pozo. Pero hay muchas aplicaciones involucradas y no es realista exigirles que dediquen mucho tiempo a resolverlas.

Es casi imposible para un equipo así implementar prácticas ágiles como la entrega en 2 semanas y el desmantelamiento de historias. Dejo que la administración de la configuración complete la estandarización de la ingeniería de código y la compilación y construcción. Después de tener esta imagen, miraré al equipo. Todos pueden ver muy claramente en quién se basan todas las aplicaciones. El jefe también lo ve, el nuevo programador junior También he visto que ha llegado el momento del desacoplamiento y refactorización de la arquitectura, y también se reduce la dificultad de promover todas las partes.

Al final, este equipo se convirtió en un equipo típico con una transformación ágil exitosa, y su eficiencia en la entrega de I + D estuvo entre las mejores.

La tabla de la figura siguiente ha sido compartida por colegas como una práctica de DevOps en conferencias relevantes en los últimos dos años. Esta mesa es la creación original de nuestro equipo de calidad en 2013. Tenemos muchas líneas de negocio, con diversas características de negocio, algunas para finanzas y otras para front office, no es factible utilizar un estándar de calidad de código unificado. Por lo tanto, le pedí al equipo de eficiencia de ingeniería que respaldara el uso de diferentes funciones para hacer diferentes acuerdos durante el diseño inicial, y el equipo de control de calidad también debería formular especificaciones en consecuencia. Para muchos de los detalles de implementación, la relación de tiempo no comenzará y la comunicación fuera de línea es bienvenida.

3.3.2 Construcción de automatización

La construcción automatizada es de dos eslabones. La estrategia de automatización de pruebas se basa en el diseño en capas y la ejecución coordinada. Este es ahora un consenso general en la industria, por lo que no lo explicaré. Veamos algunos ejemplos.

Por ejemplo, el escaneo de código de JD.com es un oso hormiguero, con un promedio de más de 240 servicios de inspección por día y un promedio de 40 problemas por día encontrados, y las reglas de inspección se pueden configurar de manera flexible.

El control de calidad de la imagen siguiente muestra que los sitios web de comercio electrónico realizan muchas actividades para hacer frente a diferentes consumidores. Estas actividades toman 20 personas a la semana para realizar inspecciones La plataforma de monitoreo de operación y mantenimiento se enfoca en el nivel de la plataforma del sistema, y ​​este monitoreo se enfoca en los problemas de calidad en un nivel de negocio específico.

Tenemos muchas plataformas, este canal de actividad corresponde a APP, pero no a WeChat. Desafortunadamente, este evento se lanzó en el canal WeChat y también realizaremos verificaciones de adaptación de la plataforma.

3.3.3 Construcción de bloques de construcción

Según tengo entendido, la construcción de bloques de construcción es la ley de evolución de la arquitectura de plataformas. Building blocks es la evolución de las capacidades comerciales de una empresa y la evolución de las capacidades técnicas de un equipo de I + D.

A juzgar por la experiencia en la construcción de plataformas de eficiencia de ingeniería, plataformas de operación y mantenimiento automatizadas, plataformas de middleware y plataformas de calidad que he liderado, debe ser una serie de pequeñas herramientas, prototipos de frameworks, scripts dispersos, a través de modularización, servicio y visualización. El proceso de transformación formará gradualmente un nuevo ecosistema flexible, conectable y combinable para brindar servicios externos, este es el proceso de nuestra evolución.

Este proceso también ha alcanzado el objetivo final de construir bloques: el empoderamiento. De cara a nuevos negocios y nuevas aplicaciones, necesitamos brindar soluciones. Solo tenemos que seleccionar lo que necesitamos, hacer algunas transformaciones y configuraciones simples, y está listo para el mundo exterior.

Por ejemplo, en este ejemplo, el sistema existente tiene sus propios módulos originales funcionando, ¿cómo colaborar? Esta es la construcción de tal bloque de construcción.

El servicio en la nube de eficiencia de ingeniería de YHD lo hago yo en la tienda número uno. A través de una serie de transformaciones de servicio funcional, estandarización de datos y automatización de procesos del sistema cerrado original en cada enlace, finalmente se forma un conjunto completo de servicios orgánicos de gestión de I + D.

El contenido es relativamente rico, la relación temporal, en resumen, dos.

Primera persona. Cuando los ingenieros ingresan a la empresa, todo, incluidos los permisos del código base, las aplicaciones que se pueden ver, los lanzamientos que hacen, etc., se controlan automáticamente.

En segundo lugar, el producto. Cuando un ingeniero de I + D produce una línea de código, dónde se almacena el código, dónde está empaquetado, cómo salir, qué se ha cambiado, qué pruebas se han superado, los resultados del lanzamiento, los comentarios de seguimiento, los costes de las pruebas de I + D y beneficios, calidad / eficiencia del proceso, etc.

3.3.4 Construcción inteligente

Construcción inteligente, todavía estamos en camino.

No hay muchos casos compartidos ahora. Esta es la retroalimentación de nuestros usuarios, pero para la recopilación, es necesario enviar diferentes preguntas a los diferentes departamentos. Se analizan las preguntas de retroalimentación enviadas por los usuarios en línea, y se utilizan concordancia semántica y análisis de clústeres. Por ejemplo, ciertos tipos de problemas se retroalimentan al departamento de operaciones y algunos problemas se retroalimentan a I + D.

4. Resumen y perspectivas

De adelante hacia atrás, una perspectiva completa. Debido a que DevOps rompe la pared y forma una administración general, las contradicciones internas deben equilibrarse y el objetivo final es buscar lo último en administración de calidad.

Esta es la experiencia de un gerente de calidad antes que yo, creo que resuena bien y la compartiré con todos al final. Muchas empresas tienen equipos que construyen plataformas, al igual que el departamento de calidad.

Hoy en día, cuando DevOps es popular, todo el mundo parece estar interesado en él, mientras se ignora a los ingenieros que realmente luchan por la garantía de calidad en la primera línea del negocio. No trabaje por herramientas, nosotros hacemos herramientas para resolver problemas. No importa cuán grande sea la habilidad, las herramientas altas no pueden caer al suelo y se harán en vano. Haciendo hincapié en la calidad, nuestra intención original es darnos cuenta del valor que los productos aportan a los usuarios.