DAS (Servicio de Autonomía de la Base de Datos, Servicio Autónomo de la Base de Datos) está orientado a I + D y DBA.Es un servicio autónomo de la base de datos que brinda a los usuarios análisis del rendimiento de la base de datos, diagnóstico de fallas, administración de seguridad y otras funciones. DAS utiliza métodos de big data, aprendizaje automático y experiencia experta para ayudar a los usuarios a eliminar la complejidad de la administración de la base de datos y las fallas del servicio causadas por las operaciones manuales, y garantizar de manera efectiva la operación estable y eficiente de los servicios de la base de datos. Este artículo describe principalmente los antecedentes históricos, la estrategia de evolución, las funciones importantes y las ideas de implementación de DAS, con la esperanza de ayudar o inspirar a los estudiantes que participan en el desarrollo relacionado.
1 Situación actual y problemas
1.1 Se destaca el desequilibrio entre crecimiento de escala y desarrollo de capacidades de operación y mantenimiento
Con el rápido desarrollo del negocio de Meituan en los últimos años, la escala de la base de datos también ha mantenido un rápido crecimiento. Como "terminal nerviosa" de todo el sistema comercial, una vez que ocurre un problema en la base de datos, la pérdida para el negocio será muy grande. Al mismo tiempo, debido al rápido crecimiento de la escala de la base de datos, la cantidad de problemas también ha aumentado considerablemente y el análisis pasivo y el posicionamiento que dependen completamente de la mano de obra se han visto abrumados. La siguiente figura muestra la tendencia de crecimiento de las instancias de base de datos en los últimos años en ese momento:
1.2 El ideal es muy rellenito, la realidad es muy flaca
La principal contradicción a la que se enfrenta actualmente el equipo de la base de datos de Meituan es el desequilibrio entre el crecimiento de la escala de instancias y el desarrollo de las capacidades de operación y mantenimiento, y la principal contradicción se refleja en los altos requisitos de estabilidad de la base de datos y la falta de datos clave. Debido a las capacidades insuficientes del producto, solo podemos confiar en DBA profesionales para solucionar problemas manualmente, lo que lleva mucho tiempo para manejar las excepciones. Por lo tanto, decidimos completar la información clave, proporcionar capacidades de autoservicio o localización automática de problemas y reducir el tiempo de procesamiento.
Revisamos las fallas y alarmas en el último período de tiempo y analizamos profundamente las causas raíz de estos problemas.Descubrimos que cualquier excepción se puede dividir en tres etapas: prevención de excepciones, manejo de excepciones y recuperación de excepciones. Para estas tres etapas, combinadas con la definición de MTTR, y luego investigamos las soluciones dentro de Meituan y la industria, creamos un panorama que cubre las soluciones de manejo de excepciones de bases de datos. Como se muestra abajo:
Por comparación, encontramos:
- Tenemos herramientas relevantes para respaldar cada enlace, pero las capacidades no son lo suficientemente sólidas. En comparación con las capacidades de los principales fabricantes de la nube, que son alrededor del 20% al 30%, las deficiencias son más obvias.
- Las capacidades de autoservicio y automatización también son insuficientes, aunque hay muchas herramientas, no se ha abierto toda la cadena y no se han formado sinergias.
Entonces, ¿cómo resolver este problema? Después de un análisis profundo y una discusión entre los miembros del equipo, propusimos una solución más acorde con la etapa de desarrollo actual.
2 ideas de solución
2.1 Resolver conflictos a corto plazo y basarse en el desarrollo a largo plazo
De la revisión de fallas históricas, el 80% del tiempo en el 80% de las fallas se dedica a análisis y posicionamiento. El ROI (retorno de la inversión) a corto plazo es más alto para la resolución de análisis de anomalías y la eficiencia de localización. A la larga, solo mejorando el mapa de capacidad se puede mejorar continuamente la estabilidad y la capacidad de garantía de toda la base de datos. Por lo tanto, una de nuestras ideas en ese momento era resolver conflictos a corto plazo y basarnos en el desarrollo a largo plazo (Think Big Picture, Think Long Term). El nuevo plan debería dejar suficiente espacio para el desarrollo en el futuro, no solo para "aliviar el dolor de cabeza y el dolor de pies".
A nivel macro, esperamos que se puedan ubicar automáticamente más funciones y, en función del posicionamiento automático, los cambios se pueden manejar de forma automática o automática, para mejorar la eficiencia de la recuperación anormal y, en última instancia, mejorar la experiencia del usuario. Después de mejorar la eficiencia del manejo de excepciones y la experiencia del usuario, el costo de comunicación del personal de operación y mantenimiento (principalmente DBA) se reducirá en gran medida, por lo que el personal de operación y mantenimiento tendrá más tiempo para invertir en tecnología y podrá manejar más "carne humana". La anormalidad se convierte en autoayuda o procesamiento automático, formando así un "efecto volante". Finalmente, se logra el objetivo de una garantía de estabilidad eficiente.
A nivel micro, en función de los datos existentes, mejoramos la observabilidad a través de la salida de información estructurada y completamos las deficiencias de los datos clave que faltan. Al mismo tiempo, en función de la salida de información perfecta, brindamos capacidades de posicionamiento automático o de autoservicio a través de la cooperación de reglas (experiencia de expertos) e IA, y acortamos el tiempo de procesamiento.
2.2 Consolide las capacidades básicas, potencie los servicios de capa superior y obtenga la autonomía de la base de datos
Con una ideología rectora clara, ¿qué estrategia de desarrollo y qué camino debemos tomar? A juzgar por la situación de la mano de obra del equipo en ese momento, ninguno de los estudiantes tenía experiencia en el desarrollo de la autonomía anormal, y ni siquiera tenían la capacidad de analizar la anomalía en la base de datos. La estructura de talento no podía cumplir con el objetivo final de la producto. Las llamadas "cosas grandes del mundo deben hacerse con detalle, y las cosas difíciles del mundo deben hacerse con facilidad". Nuestra idea es comenzar con funciones pequeñas y sencillas, primero completar funciones simples como monitoreo de indicadores, consulta lenta, sesión activa, y luego profundizar gradualmente en funciones complejas como SQL completo, análisis de causa raíz anormal y sugerencias de optimización de consultas lentas. El trabajo básico se utiliza para "aprender la verdad a través de las falsedades", mejorar continuamente la capacidad del equipo para superar las dificultades y, al mismo tiempo, sentar una buena base para la inteligencia.
El siguiente es nuestro plan de ruta de 2 años basado en la estructura de talento actual y los objetivos futuros (el plan para lograr el objetivo de autonomía de datos se lanzará después de 2022, y esta parte se omitirá de la figura a continuación):
2.3 Establecer un sistema de evaluación científica para realizar un seguimiento continuo de la calidad del producto
El famoso estudioso de la gestión estadounidense Kaplan dijo: "No hay gestión sin medición". Solo estableciendo un sistema de evaluación científica podemos llevar el producto a un nivel superior.¿Cómo evaluar la calidad del producto y mejorarlo continuamente? Hemos hecho muchos indicadores antes, pero todos son incontrolables y no hay forma de guiar nuestro trabajo. Por ejemplo, cuando consideramos por primera vez la localización de la causa raíz, usamos la precisión y el recuerdo del índice de resultados, pero el índice de resultados era incontrolable y difícil de guiar en nuestro trabajo diario. Esto requiere encontrar los factores controlables y mejorarlos continuamente.
Cuando estábamos aprendiendo sobre Amazon, descubrimos que tienen una metodología para métricas de entrada y salida controlables que guían bien nuestro trabajo. Mientras optimicemos y mejoremos continuamente los indicadores de entrada controlables correctos, nuestros indicadores de salida también se pueden mejorar al final (esto también confirma lo que dijo una vez Zeng Guofan: "Trabaja duro en la causa, pero sigue el destino en la fruta"). .
El siguiente es nuestro diseño de índice e ideas de implementación técnica para el posicionamiento de causa raíz (en la parte que se puede mejorar continuamente y controlable en el entorno de simulación, también se mejorará el efecto real de la final en línea. Incluye principalmente "posicionamiento de causa raíz controlable ideas de diseño de índices de entrada y salida” e “Ideas de implementación técnica para obtener indicadores de entrada controlables para la ubicación de la causa raíz”).
Ideas de diseño de índice de entrada y salida controlable de localización de causa raíz
La idea de realización técnica de la adquisición del índice de entrada controlable de la ubicación de la causa raíz
En la Figura 5, simulamos algunas anomalías (la mayoría de las anomalías) que se pueden realizar a bajo costo mediante la reproducción de escenas y medios técnicos. Para anomalías con alto costo de recurrencia (muy pocas), como anomalías de máquina, fallas de hardware, etc., nuestra idea actual es descubrir y optimizar problemas a través de la "operación humana", y esperar hasta que la próxima anomalía en línea ocurra repetidamente, y según a los resultados del diagnóstico optimizado, se determina si se pasa o no la aceptación por comparación con lo esperado.
En el futuro, estableceremos un sistema retrospectivo para guardar los indicadores anormales en el momento del problema, y usaremos los indicadores anormales para ingresar los resultados de salida del sistema retrospectivo para juzgar la efectividad de la mejora del sistema, a fin de construir un método de recurrencia más ligero y de mayor cobertura. La figura 6 es la idea de realización técnica específica del sistema de reproducción.
Con la ideología rectora, la planificación del camino en línea con la etapa de desarrollo actual y el sistema de evaluación científica, hablemos de la idea de la solución técnica.
3 soluciones técnicas
3.1 Diseño de alto nivel de la arquitectura técnica
En el diseño de alto nivel de la arquitectura técnica, nos adherimos a la estrategia de evolución de cuatro pasos de plataforma, autoservicio, inteligencia y automatización.
En primer lugar, necesitamos mejorar la capacidad observable y construir una plataforma de monitoreo de base de datos fácil de usar a través de la visualización de información clave. Luego proporcionamos autorización para cambios (como cambios de datos y cambios de índice) en función de esta información clave, y pasamos parte del trabajo de operación y mantenimiento de alta frecuencia a través de esta información clave estructurada (como cambios de índice, podemos monitorear si hay tráfico de acceso reciente, para garantizar que cambie la seguridad) para permitir que los usuarios tomen sus propias decisiones, es decir, el autoservicio. A continuación, agregamos algunos elementos inteligentes (experiencia de experto + IA) para cubrir aún más los escenarios de autoservicio, y gradualmente automatizar algunas funciones de bajo riesgo, y finalmente llegar a la etapa avanzada o completamente automatizada a través de la mejora continua del sistema.
¿Por qué anteponemos la automatización a la inteligencia? Porque creemos que el objetivo de la inteligencia también es para la automatización, la inteligencia es la premisa de la automatización y la automatización es el resultado de la inteligencia. Solo mejorando continuamente la inteligencia podemos lograr una automatización avanzada o completa. La siguiente figura es nuestro diseño de arquitectura de nivel superior (el lado izquierdo es la estrategia de evolución, el lado derecho es el diseño de nivel superior de la arquitectura técnica y el status quo a fines de 2021):
El diseño de nivel superior es solo el “primer paso de la larga marcha”, a continuación iremos introduciendo de forma paulatina el trabajo específico que realizamos en base al diseño de nivel superior de abajo hacia arriba, comenzando por el diseño de la capa de adquisición de datos , el diseño de la capa de almacenamiento de cálculo, y el diseño de la capa de análisis y toma de decisiones.
3.2 Diseño de la Capa de Adquisición de Datos
En el diagrama de arquitectura anterior, la capa de recopilación de datos es la capa inferior y el enlace más importante de todos los enlaces, y la calidad de los datos recopilados determina directamente la capacidad de todo el sistema. Al mismo tiempo, funciona directamente con las instancias de la base de datos y cualquier defecto de diseño podría provocar fallas masivas. Por lo tanto, la solución técnica debe tener en cuenta la calidad de la recopilación de datos y la estabilidad de la instancia. Cuando no se pueden equilibrar los dos, es mejor sacrificar la calidad de la recopilación para garantizar la estabilidad de la base de datos.
En términos de recopilación de datos, la industria adopta un método basado en el kernel, pero el kernel de desarrollo propio de Meituan es relativamente tardío y el ciclo de implementación es largo, por lo que nuestro método a corto plazo es usar el método de captura de paquetes para hacer una transición. y espere a que la colección basada en kernel se implemente hasta cierto punto. Luego cambie gradualmente. La siguiente es nuestra investigación de solución técnica basada en la idea de capturar paquetes:
| Programa | actuación | generalidad | Observación |
|---|---|---|---|
| pcap | Bajo | alto | El equipo de Meituan Wine and Brigade ya ha practicado online |
| pf_anillo | medio | medio | Necesito renovar MySQL |
| dpdk | alto | Bajo | El controlador NIC debe volver a compilarse |
De la encuesta podemos ver que las soluciones basadas en pf_ring y dpdk tienen grandes dependencias, las cuales son difíciles de implementar a corto plazo, y no hay experiencia previa. Sin embargo, no depende del método basado en pcap, y también tenemos algo de experiencia.Antes, el equipo de Meituan Wine Travel creó una herramienta de recopilación de datos SQL a gran escala basada en el método de captura de paquetes, y se ha verificado para uno año. Por lo tanto, finalmente adoptamos una solución técnica basada en el método de captura de paquetes pcap. El siguiente es el diagrama de arquitectura del esquema de la capa de recopilación, la calidad de la recopilación y el impacto en el rendimiento de la base de datos.
El diseño técnico del agente
Impacto en la base de datos
3.3 Diseño de la capa de almacenamiento computacional
Debido a la gran cantidad y el tráfico de toda la instancia de base de datos de Meituan, y con el rápido desarrollo del negocio, también muestra una tendencia de rápido crecimiento. Por lo tanto, nuestro diseño no solo debe cumplir con los requisitos actuales, sino también considerar los requisitos para los próximos 5 años y más. Al mismo tiempo, para el análisis de fallas de la base de datos, el tiempo real y la integridad de los datos es la clave para localizar problemas de manera rápida y eficiente, y no se puede ignorar el costo de capacidad requerido para garantizar la integridad y el tiempo real de los datos. Por lo tanto, combinado con los requisitos anteriores y algunas otras consideraciones, presentamos algunos principios para esta parte del diseño, que incluyen principalmente:
- Cómputo de memoria completa : asegúrese de que todos los cálculos se realicen con memoria pura en un solo subproceso o en un solo proceso, buscando lo último en rendimiento y rendimiento.
- Informar datos sin procesar : los datos informados por la instancia de MySQL mantienen el estado de los datos originales tanto como sea posible y no procesan los datos o los procesan lo menos posible.
- Compresión de datos : debido a la gran cantidad de informes, es necesario garantizar la compresión extrema de los datos informados.
- Consumo de memoria controlable : es casi imposible que se produzca un desbordamiento de memoria a través de pruebas de esfuerzo teóricas y prácticas.
- Minimice el impacto en la instancia de MySQL : Publique el cálculo tanto como sea posible, no realice cálculos complejos en el Agente y asegúrese de que la producción de la instancia de RDS no se vea muy afectada. El siguiente es el diagrama de arquitectura específico:
El SQL completo (todo el SQL que accede a la base de datos) es la función más desafiante de todo el sistema y una de las informaciones más importantes para el análisis de excepciones de la base de datos. Por lo tanto, se harán algunos puntos clave sobre el método de agregación de SQL completo, el efecto de la agregación y diseño de compresión y compensación.
3.3.1 Método de agregación de SQL completo
Debido a la gran cantidad de datos detallados, adoptamos un método de agregación. El subproceso del consumidor agregará y calculará los mensajes de la misma plantilla SQL por minuto de granularidad, utilizando "RDSIP+DBName+ID de plantilla SQL+minutos donde finaliza la consulta SQL" como clave de agregación. La fórmula de cálculo de la clave agregada es: Aggkey=RDS_IP_DBName_SQL_Template_ID_Time_Minute (El valor de Time_Minute se toma del "año, mes, día, hora, minuto" donde se encuentra la hora de finalización de la consulta SQL)
3.3.2 El efecto de la agregación y compresión completa de datos SQL
En términos de compresión de datos, siguiendo el principio de reducción de flujo capa por capa, la compresión de mensajes, la agregación previa, la diccionarioización y la agregación a nivel de minuto se utilizan para garantizar que el tráfico disminuya a medida que pasa por cada componente, lo que finalmente ahorra ancho de banda. y reduciendo el almacenamiento. Los siguientes son los enlaces de compresión relevantes y el rendimiento de los datos de prueba (los datos confidenciales se han desensibilizado y no representan la situación real de Meituan):
3.3.3 Mecanismo de compensación por datos SQL completos
Como se mencionó anteriormente, en el lado de la agregación de datos, la agregación se realiza cada minuto y se permite un retraso de mensaje adicional de un minuto. Si el retraso del mensaje supera 1 minuto, se descartará directamente, por lo que en el escenario de un retraso comercial grave, se perderá La comparación de una gran cantidad de datos tendrá un mayor impacto en la precisión del análisis posterior de anomalías en la base de datos.
Por lo tanto, hemos agregado un mecanismo de compensación de mensajes retrasados para enviar datos caducados a la cola de compensación (usando el servicio de cola de mensajes Meituan Mafka) y garantizar que los mensajes retrasados también se puedan almacenar normalmente compensando los datos caducados. del posterior análisis de anomalías de la base de datos. El siguiente es el esquema de diseño del mecanismo de compensación de datos:
3.4 Diseño de análisis y toma de decisiones
Después de tener datos más completos, el siguiente paso es tomar decisiones basadas en los datos e inferir posibles causas raíz. En esta parte, utilizamos un método basado en la experiencia de expertos combinado con IA. Dividimos el camino de la evolución en cuatro etapas:
La primera etapa : completamente basada en reglas, acumular experiencia en el campo y explorar caminos factibles. La segunda etapa : explorar escenarios de IA, pero centrándose en la experiencia de expertos, utilizando algoritmos de IA en una pequeña cantidad de escenarios de baja frecuencia para verificar las capacidades de IA. La tercera etapa : la experiencia experta y la IA van de la mano. La experiencia experta continúa iterando y extendiéndose en los escenarios existentes, la IA se implementa en nuevos escenarios y el sistema de doble vía garantiza que las capacidades originales no se degraden.
La cuarta etapa : Completar el reemplazo de la mayor parte de la experiencia experta por IA y usar la IA como la principal experiencia experta como complemento para maximizar las capacidades de la IA.
El siguiente es el diseño técnico general de la parte de análisis y toma de decisiones (nos referimos a un artículo de Huawei: "Exploración y práctica de la recomendación inteligente para las raíces de la red en la nube" ):
En la capa de análisis de decisiones, adoptamos principalmente tanto la experiencia de expertos como los métodos de IA. A continuación, presentaremos la implementación relacionada de la experiencia de expertos (método basado en reglas) y el método de IA (método basado en algoritmos de IA).
3.4.1 Enfoque basado en reglas
En la parte de la experiencia de los expertos, adoptamos la metodología de revisión de GRAI (abreviatura de Goal, Result, Analysis and Insight) para guiar nuestro trabajo. Mejora iterativamente la precisión y la tasa de recuperación. El siguiente es un ejemplo del proceso de refinamiento de la regla de retardo maestro-esclavo:
3.4.2 Método basado en algoritmo de IA
Detección de indicador de base de datos anormal
La detección de anomalías de los indicadores centrales de la base de datos se basa en un modelado razonable de los datos históricos de los indicadores. Al combinar el modelado periódico de procesos fuera de línea con la detección de transmisión de procesos en tiempo real, ayudará a detectar de manera efectiva las instancias de la base de datos en presencia de fallas o riesgos. Para localizar el problema de raíz, a fin de resolver el problema de manera oportuna y eficaz.
El proceso de modelado se divide principalmente en tres procesos. Primero, preprocesamos los datos históricos del indicador a través de algunos módulos de preprocesamiento, incluido el llenado de valores faltantes, el suavizado y la agregación de datos. Posteriormente, creamos ramas posteriores a través del módulo de clasificación, utilizando diferentes medios para modelar diferentes tipos de indicadores. Finalmente, después de serializar y almacenar el modelo, se proporciona la lectura de tareas de Flink para realizar la detección de flujo.
El siguiente es el diagrama de diseño de la detección.
Diagnóstico de causa raíz (en construcción)
Suscríbase a mensajes de alarma (basados en reglas o activados por la detección de anomalías), active el proceso de diagnóstico, recopile y analice datos, infiera la causa raíz y filtre información válida para ayudar a los usuarios a resolver. El resultado del diagnóstico se notifica al usuario a través del elefante, y se proporciona la página de diagnóstico y detalles del diagnóstico, y el usuario puede optimizar la precisión del diagnóstico marcando.
Recopilación de datos : recopile indicadores de rendimiento de la base de datos, captura del estado de la base de datos, indicadores del sistema, problemas de hardware, registros, registros y otros datos. Extracción de características : extraiga características de varios tipos de datos, incluidas características de series temporales extraídas por algoritmos, características de texto y características de dominio extraídas mediante el conocimiento de la base de datos. Clasificación de causa raíz : incluido el preprocesamiento de características, la detección de características, la clasificación de algoritmos, la clasificación de causas raíz y otras partes. Expansión de causa raíz : basada en la categoría de causa raíz, realiza una extracción en profundidad de información relevante para mejorar la eficiencia de los usuarios para hacer frente a los problemas. Específicamente, incluye módulos funcionales como análisis de comportamiento SQL, reglas expertas, asociación de indicadores, desglose de dimensiones y análisis de registros.
4 logros de construcción
4.1 Desempeño del indicador
En la actualidad, adoptamos principalmente el método de circuito cerrado de "combinar los escenarios de activación de alarmas -> simular la escena recurrente -> análisis y diagnóstico de causa raíz -> plan de mejora -> aceptar y mejorar la calidad -> combinar los escenarios de activación de alarmas" (Para más detalles, consulte el artículo anterior para establecer un sistema de evaluación científica, seguimiento continuo de las piezas de calidad del producto), optimización e iteración continuas. A través de la mejora de los indicadores de entrada controlables, los indicadores de salida en la línea se optimizan y mejoran, para garantizar que el sistema continúe desarrollándose en la dirección correcta. Así es como se han comportado recientemente las métricas de recuperación y precisión de la causa raíz.
Precisión de la retroalimentación de la causa raíz de la alarma del usuario
Análisis de diagnóstico de alarma Tasa de recuperación general
4.2 Casos de usuario
En el empuje de los resultados de la causa raíz, nos comunicamos con el sistema de mensajería instantánea (Elephant) dentro de Meituan. Después de que ocurre un problema, podemos encontrar anomalías a través de alarmas -> Causa raíz del diagnóstico del empuje del elefante -> Haga clic en el enlace de diagnóstico para ver los detalles -> Procesamiento del plan con un clic -> seguimiento del efecto del procesamiento de retroalimentación -> ejecución exitosa o reversión para completar el ciclo cerrado de descubrimiento, ubicación, confirmación y procesamiento anormales. El siguiente es un ejemplo de análisis de causa raíz después de que una regla de sesión activa activa una alerta.
Tire automáticamente del grupo y proporcione la causa raíz
Haga clic en el informe de diagnóstico para ver los detalles
El siguiente es un caso de nuestra sugerencia de optimización de consulta lenta empujada después de la alarma de carga (el motivo de la desensibilización, el caso de usar la simulación del entorno de prueba).
5 Conclusión y perspectivas de futuro
Después de aproximadamente 2 años de desarrollo, el servicio autónomo de la base de datos básicamente ha consolidado sus capacidades básicas y ha completado el empoderamiento preliminar en algunos escenarios comerciales (por ejemplo, para SQL problemático, los servicios comerciales se identifican automáticamente antes de que se publiquen y se indican los riesgos potenciales). ; para cambios de índice incorrectos, Detectar automáticamente el tráfico de acceso reciente del índice antes de la ejecución de la orden de trabajo, bloquear los cambios incorrectos, etc.). A continuación, nuestro objetivo es centrarnos en la autonomía de la base de datos, además de seguir profundizando en nuestro trabajo y mejorando nuestras capacidades. La planificación principal del trabajo girará en torno a las siguientes tres direcciones:
(1) Capacidades informáticas y de almacenamiento mejoradas : con el rápido crecimiento continuo de las instancias de bases de datos y el tráfico comercial, así como el enriquecimiento continuo de la información recopilada, es urgente mejorar las capacidades de los canales de datos existentes para garantizar que las capacidades de procesamiento puedan respaldar la próximos 3-5 años.
(2) Las capacidades autónomas se implementan en una pequeña cantidad de escenarios : en términos de capacidades de autonomía de la base de datos, se adoptará una estrategia de tres pasos:
- Paso 1: establecer la asociación entre el diagnóstico de causa raíz y los documentos SOP, y hacer que el diagnóstico y el tratamiento sean transparentes;
- Paso 2: el documento SOP se organiza en una plataforma y el diagnóstico y el procesamiento se simplifican;
- Paso 3: Intervención parcial no tripulada de bajo riesgo, diagnóstico y procesamiento automáticos, y realización gradual de la autonomía de la base de datos.
(3) Sistema retrospectivo de anomalías más flexible : la verificación del algoritmo de localización de la causa raíz de una determinada escena antes o después de que se conecte es muy crítica. Mejoraremos el sistema de verificación, estableceremos un sistema retrospectivo de anomalías flexible y optimizaremos continuamente a través del reproducción basada en información en el sitio y mejorar la precisión de posicionamiento del sistema.
6 Autor y equipo
Jinlong, del Departamento de Tecnología Básica de Meituan/Centro de Investigación y Desarrollo de Bases de Datos/Equipo de Investigación y Desarrollo de Plataformas de Bases de Datos.
Leer más colecciones de artículos técnicos del equipo técnico de Meituan
Frontend | Algoritmo | Backend | Datos | Seguridad | O&M | iOS | Android | Pruebas
| Responda palabras clave como [2021 stock], [2020 stock], [2019 stock], [2018 stock], [2017 stock] en el cuadro de diálogo de la barra de menú de la cuenta pública, puede ver la colección de artículos técnicos por el técnico de Meituan equipo a lo largo de los años.
