“Mañana es el 20, lo que significa que habrá una tormenta nuevamente. Es imposible detenerlo, solo prepárese y espere que esta vez explote, suceda un milagro y nuestro ferry del lago conquistará el océano ” . Tales pensamientos dominaron al equipo involucrado en el apoyo al portal de servicios municipales hace varios años. A continuación, se describirá cómo nos metimos en esta situación y cómo encontramos una salida.
Como empezó todo
En la lejana década de 1990, el sector de la vivienda y los servicios públicos experimentó un auge en el desarrollo, se introdujeron nuevas tecnologías, se automatizaron sistemas de información y se compraron nuevos equipos. Pero algo permaneció durante mucho tiempo prácticamente sin cambios, a saber, los pagos por el apartamento. Sí, sí, esos mismos recibos de un departamento, que se transformaron en documentos de pago, adquirieron códigos de barras, un descifrado detallado, quedaron como pedazos de papel. El esquema de trabajo típico del centro de asentamiento de la empresa de vivienda y servicios comunales o empresa de suministro de recursos fue el siguiente:
Poco a poco, el módem de Internet fue reemplazado por el acceso de banda ancha, surgió la idea: ¿por qué no recibir documentos de pago en línea en forma electrónica? Al mismo tiempo, el sector de la vivienda y los servicios comunales se sacudía en una forma organizativa, las viviendas MPP y los servicios comunales (empresa de producción municipal de viviendas y servicios comunales) fueron reemplazados por empresas municipales unitarias (empresas municipales unitarias), DEZ (direcciones de un solo cliente). Como resultado de todas las transformaciones, los departamentos de TI de las empresas de vivienda y servicios comunales fueron enajenados, y varios centros de asentamiento nacieron sobre su base. La esencia de los centros de asentamiento era, de hecho, el cálculo de la renta y el soporte de información de la población.
Etapa de crecimiento, 00s
Fue entonces cuando nacieron los primeros portales de información que proporcionaron a la población servicios electrónicos. El número de primeros usuarios se midió en docenas, no todos confiaban en los documentos de pago electrónico, otros no habían escuchado sobre las innovaciones, las aplicaciones móviles en el campo de los servicios públicos eran raras. El trabajo de los portales de información no difería mucho del trabajo de los sistemas de información familiares y, por supuesto, nunca fue una arquitectura de alta carga.
Pasaron los años, los portales mejoraron, hubo oportunidades para tomar lecturas de dispositivos de medición, generar certificados, etc. Fue en este momento que aparecieron las primeras "nubes" en el horizonte, cada vez más usuarios comenzaron a registrarse en los portales y solicitar datos. A lo lejos, apareció la primera ola de cargas que se acercaban.
El equipo (en adelante, el Equipo 1) tomó las siguientes medidas de optimización:
- Cambiar el tamaño de un documento de pago en PDF de 0.5MB a 0.2MB
- Crear una cola para la formación de documentos de pago.
- Almacenamiento de documentos de pago generados para solicitud repetida
- Crear una réplica de la base de datos principal, solo para las necesidades del portal
Durante varios años, la situación parecía estable, el número de usuarios de portales individuales se midió en miles, todavía no había tormenta, pero se sacudió significativamente, la descentralización de los centros de compensación jugó en manos de los desarrolladores.
Big Jump Stage
Un nuevo hito en la historia fue el desarrollo de un portal de servicios municipales a nivel regional. La inclusión de un único punto de entrada para cualquier residente de la república era una idea tentadora; además, esto aumentaría la calificación del sitio estatal al nivel de los mejores sitios comerciales o bancarios, donde cada residente de la región recibiría muchos tipos diferentes de servicios. Uno de los más populares podría ser el pago de viviendas y servicios comunales y la inclusión de lecturas de medidores.
Por lo tanto, el siguiente paso fue la separación de la información operativa de los centros de liquidación de la información que se muestra en el documento de pago. Para esto, se desarrolló un formato simple de transferencia de datos y una base de datos para almacenar información, y se realizó el cálculo del espacio requerido para el almacenamiento durante 5 años de operación.
Decisiones clave tomadas en esta etapa:
- Departamento de información parte de la base de datos operativa;
- Desarrollo de una base de datos para almacenar este formato;
- Combinar los datos de los centros de asentamiento de las regiones en una sola base de datos;
- Integración con procesos de portal, desarrollo de servicios.
En esta etapa, la solución pasó de ser un sistema completo a un back-end, ya que el portal proporcionaba a los usuarios una única interfaz. El portal tenía su propio equipo, que lo desarrolló independientemente de la solución actual de los centros de liquidación. En nuestra historia, aparece el
segundo equipo (en adelante, el Equipo 2) y un nuevo proveedor. Como veremos más adelante, esto ha afectado significativamente el desarrollo y la resolución de problemas. La esencia de la solución de diseño fue la siguiente:
Al diseñar la base de datos, se aceptó una asignación simple del formato a la base de datos, se seleccionó PostgreSQL 9.3 como DBMS (en ese momento era una versión muy actual). El formato consistía en 9 archivos planos, cada uno de los cuales fue cargado por el comando COPIA (lo leímos muy rápidamente) en las muchas tablas de un centro de liquidación específico (cada centro de liquidación tenía su propio número de registro) de la base de datos del portal. En algunos centros de liquidación, el número de registros requeridos para la formación de documentos de pago llegó a 1,000,000. En un año esto ascendió a 12,000,000, durante 5 años -60,000,000. El número de solicitudes a esta base de datos aumentó a la suma de todos los usuarios de los portales de distrito y podría conforman decenas de miles. Había algo en que pensar.
Al no tener esa experiencia, el
Equipo 1 tomó los siguientes pasos para reducir la carga potencial:
- Las tablas se dividieron por centros de asentamiento y meses de partición;
- El proceso de carga de datos tiene un espacio de tiempo para diferentes centros de facturación.
Desafíos de crecimiento demasiado rápido
Se lanzó el portal y los planes preparados se enfrentaron a la realidad:
- El número de usuarios superó la estimación muy rápidamente.
- Las consultas fueron a la tabla maestra, pero el DBMS aún sondeó todas las tablas
- Carga espuria en el servidor de bases de datos. En este servidor había otras bases de datos incomparablemente grandes, cuya información llegaba en momentos aleatorios, al cargarla se tomaron todos los recursos disponibles.
- El servicio de formación de un documento de pago se ralentizó debido a una implementación ineficiente
- La carga de los usuarios no se distribuyó uniformemente durante todo el mes, sino que se concentró en dos períodos:
Este momento se describe al comienzo de la publicación. Fue difícil diagnosticar el problema, porque los problemas parecían aparecer en todos los lugares a la vez. El equipo 1 y el equipo 2, igualmente amados por su liderazgo, tomaron medidas para salir de la situación, pero prácticamente no hubo comunicación entre ellos:
El equipo 2 , al parecer, dio un paso lógico y útil: la formación de un documento de pago comenzó a solicitarse inmediatamente después de que el usuario ingresó al sistema, con la expectativa de que mientras llegaba a las páginas en las páginas, el AP ya estaba formado y el documento terminado podía extraerse rápidamente.
En este momento, el
Equipo 1 resolvió heroicamente un problema por mes cada mes, cada vez convenciendo al cliente de que estaba allí donde se ocultaba la raíz del problema:
- SQL optimizado (recibió un aumento de rendimiento a veces);
- Separó el servidor de bases de datos para el portal del resto de las bases de datos;
- Llevamos a cabo la formación de un documento de pago en una aplicación separada y también lo optimizamos;
- Revisamos la apelación a la tabla maestra, cambiamos la versión de PostgreSQL;
- Una vez más, revisamos la apelación (ahora solo se solicitó 1 partición particular de la tabla maestra, incluso la aceleración a veces).
Los heroicos esfuerzos de los equipos llevaron a éxitos locales (durante 2-3 meses parecía que el problema estaba resuelto). Pero la realidad arrojaba nuevas notas introductorias todo el tiempo:
- La base de datos ya ha contenido varios años y ha crecido más de 1 TB;
- El número de usuarios ya era de cientos de miles.
Mientras la lucha estaba en marcha, el
Equipo 2 estableció una prueba de servicio automática, de modo que cualquier problema de rendimiento se conoció en cuestión de minutos y el problema se intensificó automáticamente a los niveles más altos de control por correo electrónico.
En este momento en el
Equipo 1 :
- El tiempo de archivo de la base de datos comenzó a exceder los límites permitidos (el servicio dejó de estar disponible);
- Una llamada al servicio afectó inmediatamente muchos meses, respectivamente, generó muchas solicitudes;
- DBMS ha empeorado en el cumplimiento de consultas debido a un aumento en el número de tablas (particiones);
- Los usuarios que solo querían hacer lecturas de instrumentos aún solicitaban la formación de documentos de pago (recuerden la decisión del Equipo 2).
Quedó claro que, desde un punto de vista técnico, la solución había alcanzado su límite y que era hora de comenzar a analizar el comportamiento del usuario para optimizar procesos o cambiar radicalmente las tecnologías.
Como resultado del análisis (aquí está el tema para un artículo separado), se tomaron las siguientes acciones:
- Los datos se cortaron hasta los últimos 3 años, ya que no hubo llamadas en el período anterior; Desde entonces, el antiguo período se ha interrumpido anualmente.
- Rediseñamos la apelación a la tabla maestra para hacer referencia a una partición particular directamente (redujo la carga en el DBMS).
Presente
Ahora el sistema es bastante estable, se ajusta al marco de tiempo regulatorio y a los requisitos para las características no funcionales, pero las nubes aparecieron nuevamente en el horizonte:
- Un aumento adicional en el número de usuarios;
- Crecimiento en el número de hogares atendidos;
- Aumentar la complejidad de los servicios prestados;
- Mayor granularidad de datos disponibles para los usuarios.
Por lo tanto, se elabora un plan y se está preparando la implementación de las siguientes medidas:
- Análisis del comportamiento del usuario: cuántos de ellos están realmente viendo el documento de pago, y cuántos simplemente pagan la cantidad, como por ejemplo un teléfono celular;
- Formación preliminar de documentos de pago para aquellos usuarios que generalmente ven los documentos de pago en el momento de la menor carga;
- Transición a tecnologías alternativas (sí, muchos de los que llegaron a este punto tienen soluciones mucho más avanzadas que resolvieron todos los problemas inicialmente, en los recursos de un teléfono móvil).
Parece que esto puede poner un gran punto optimista. Todo bien hecho: aquellos que lo hicieron y aquellos que lo habrían hecho mejor de inmediato. Pero mañana habrá nuevos proyectos de Highload, nuevos problemas desconocidos. ¿Cómo prepararse para ellos ahora? ¿Qué se puede prever cuando todavía no hay datos?
Un enfoque sistemático para resolver problemas.
¿Podemos convertir la experiencia en una metodología para abordar problemas en proyectos Highload? Por extraño que parezca, la respuesta es SÍ, todo ya ha sido inventado para nosotros y está dentro del marco
de la Teoría de la restricción TOC . Solo 5 pasos simples:
- Encuentre las limitaciones del sistema.
- Decida cómo aprovechar al máximo las limitaciones del sistema.
- Subordinar todo lo demás a esta decisión.
- Expanda las restricciones del sistema.
- ATENCION! Si la restricción se ha eliminado en los 4 pasos anteriores, regrese al paso 1, pero no permita que la inercia provoque una restricción del sistema.
La descripción de esta teoría y la esencia de los pasos están bastante bien descritos en la literatura al final del artículo, pero escribiré mi visión en el marco del proceso actual:
- Restricción: tiempo de formación del documento de pago.
- Solución: genere todos los documentos de pago por adelantado al descargar datos.
- Subordinado a la decisión: cuando contacte al usuario, emita un documento terminado.
- Extienda la restricción: optimice el tiempo para la formación del documento de pago.
- Abandone el sistema de preformación para TODOS los hogares, defina una nueva restricción.
Tal enfoque reduciría el tiempo de solución en varios años, con costos laborales mínimos para los programadores. La publicación indica lejos de todos los problemas que han surgido y no hay algunos detalles de las soluciones, ya que no son tan importantes en el enfoque propuesto.
Qué leer sobre el tema:
- “El objetivo. Proceso de mejora continua ", Eliyahu Goldratt
- “Teoría de las restricciones. Enfoques básicos, herramientas y soluciones " , Dmitry Egorov
- "La teoría de las restricciones de Goldratt. Un enfoque de sistemas para la mejora continua ", William Detmer