Aquí hay una historia que cambió para siempre mi enfoque del trabajo en DevOps. En los tiempos previos a la pandemia, mucho antes de eso, cuando mis compañeros y yo apenas estábamos considerando nuestro propio negocio y freelanceábamos en trabajos esporádicos, me llegó una propuesta por Telegram.
La empresa que la redactó se dedicaba a la analítica de datos. Diariamente procesaba miles de consultas. Se acercaron a nosotros diciendo: chicos, tenemos ClickHouse y queremos automatizar su configuración e instalación. Queremos Ansible, Terraform, Docker y que todo esto esté almacenado en Git. Queremos un clúster de cuatro nodos con dos réplicas en cada uno.
Una solicitud estándar, de las que hay decenas, y necesitábamos una solución estándar igual de buena. Dijimos 'okey' y en 2-3 semanas todo estaba listo. Aceptaron el trabajo y comenzaron a migrar a un nuevo clúster de ClickHouse con nuestra utilidad.
Nadie en su equipo quería o sabía cómo trabajar con ClickHouse. En ese momento pensábamos que ese era su principal problema y, por eso, el CTO de la empresa simplemente dio luz verde a mi equipo para automatizar el trabajo al máximo, para nunca tener que meterse allí de nuevo.
Asistimos con la migración y surgieron otras tareas: configurar copias de seguridad y monitoreo. En ese mismo momento, el CTO de la empresa se apartó para otro proyecto, dejándonos al mando a uno de sus hombres: Leonid. León no era un chico muy dotado. Un simple desarrollador al que de repente pusieron a cargo de ClickHouse. Parecía que era su primer nombramiento para dirigir algo y del honor repentino le surgió el síndrome de la estrella.
Juntos comenzamos a trabajar en las copias de seguridad. Yo propuse hacer copias de seguridad de los datos originales de inmediato. Simplemente tomar, comprimir y elegantemente subir a algún S3. Los datos originales son oro. También había otra opción: hacer copias de seguridad de las mismas tablas en ClickHouse, utilizando congelación y copiado. Pero León ideó su propia solución.
Anunció que necesitábamos un segundo clúster de ClickHouse. Y a partir de ahora, escribiríamos los datos en dos clústeres: uno principal y uno de respaldo. Le dije, León, no va a ser un respaldo, sino una réplica activa. Y si los datos comienzan a perderse en producción, en tu respaldo será lo mismo.
Pero León se aferró firmemente al timón y se negó a escuchar mis argumentos. Tuvimos muchas discusiones en el chat, pero no había nada que hacer: León estaba al mando en el proyecto, nosotros éramos solo chicos contratados de la calle.
Estuvimos monitoreando el estado del clúster y solo cobramos por el trabajo de los administradores. Administración pura de ClickHouse sin interferir en los datos. El clúster estaba disponible, los discos en orden, y los nodos funcionaban correctamente.
Aún no sospechábamos que habíamos recibido este pedido debido a un terrible malentendido dentro de su equipo.
El gerente estaba descontento porque ClickHouse funcionaba lentamente y, a veces, se perdían datos. Le asignó la tarea a su CTO de resolverlo. Este hizo lo que pudo y concluyó que solo había que automatizar ClickHouse — y ya. Pero como se descubrió poco después, no necesitaban un equipo de DevOps.
Todo esto se aclaró de una manera muy, muy dolorosa. Y lo más molesto, fue en mi cumpleaños.
Viernes por la noche. Reservé una mesa en mi bar de vinos favorito y llamé a mis amigos.
Casi antes de salir, nos llega la tarea de hacer un alter, lo completamos, todo bien. El alter pasó, ClickHouse lo confirmó. Ya estábamos listos para ir al bar, y nos escriben que faltan datos. Contamos y, al parecer, estaba todo en orden. Y nos fuimos a celebrar.
El restaurante estaba ruidoso, como suele ser un viernes. Pedimos bebidas y comida, y nos acomodamos en los sillones. Todo este tiempo, mi Slack se llenaba lentamente de mensajes. Hablaban de la falta de datos. Pensé: 'Mañana será un día más sabio'. Especialmente hoy.
Cerca de las once, comenzaron a llamarnos. Era el gerente de la empresa… 'Seguramente decidió felicitarme', pensé con mucha inseguridad, recogí el teléfono.
Y escuché algo como: '¡Ustedes han perdido nuestros datos! Les estoy pagando, pero ¡nada funciona! Ustedes eran responsables de los backups y no hicieron nada. ¡Vamos a arreglarlo!' — solo que en un tono mucho más grosero.
— Sabes qué, ¡vete al diablo! Hoy es mi cumpleaños, y ahora voy a beber, en lugar de lidiar con sus chapuzas de novatos que son un desastre.
Así es como no lo dije. En su lugar, saqué la computadora portátil y me puse a trabajar.
No, estaba furioso, ¡estaba extremadamente furioso! Llené el chat con ácidas 'te lo dije' — porque el backup, que no era un backup en absoluto, por supuesto, no salvó nada.
Mis amigos y yo ideamos cómo detener manualmente la grabación y verificar todo. Realmente nos aseguramos de que parte de los datos no se estaban escribiendo.
Detuvimos la grabación, contamos el número de eventos que había allí durante el día. Añadimos más datos, de los cuales solo un tercio no se grabó. Tres shards con 2 réplicas. Insertas 100.000 filas — 33.000 no se graban.
Se desató un completo caos. Todos se enviaban al infierno por turnos: el primero en ir fue León, seguido de mí mismo y del fundador de la empresa. Solo el CTO recién incorporado intentaba sacar nuestras llamadas con gritos y la conversación hacia la búsqueda de una solución al problema.
Nadie entendía lo que estaba sucediendo realmente.
Nosotros, los chicos, simplemente nos quedamos boquiabiertos cuando entendimos que un tercio de todos los datos no solo no se grababan, ¡sino que se perdían! Resultó que el orden en la empresa era tal que, después de la inserción, los datos se eliminaban de forma irreversible, y los eventos se perdían por montones. Imaginé cómo Sergio convertiría todo esto en rublos no obtenidos.
Mi cumpleaños también iba a la basura. Estábamos sentados en un bar desarrollando ideas, tratando de resolver el enigma planteado. La razón de la caída de ClickHouse no era obvia. Tal vez fuera la red, tal vez los ajustes de Linux. Podría ser cualquier cosa, se presentaron bastantes hipótesis.
No había hecho un juramento de desarrollador, pero dejar a los chicos al otro lado del cable era deshonesto, incluso si ellos nos culpaban por todo. Estaba un 99% seguro de que el problema no estaba en nuestras soluciones, no de nuestra parte. El 1% de posibilidad de que realmente nos equivocáramos me quemaba con ansiedad. Pero, de cualquier modo, no importa de qué lado estuviera el problema, había que solucionarlo. Dejar a los clientes, fueran quienes fueran, con una fuga de datos tan terrible — eso era demasiado cruel.
Trabajamos hasta las tres de la mañana en una mesa de restaurante. Estábamos agregando eventos, insert select — y comenzamos a llenar los huecos. Cuando has perdido datos, se hace así: tomas los datos promedio de los días anteriores y los insertas en los que se han perdido.
Después de las tres de la mañana, un amigo y yo fuimos a mi casa, pedimos unas cervezas de la tienda. Yo estaba sentado con el portátil y los problemas de ClickHouse, mi amigo me contaba algo. Al final, después de una hora, se molestó porque estaba trabajando y no bebiendo cervezas con él, y se fue. Clásico — pasé de ser amigo del DevOps.
Para las 6 de la mañana, recreé la tabla desde cero y los datos comenzaron a cargarse. Todo funcionó sin pérdidas.
Después fue difícil. Todos se culpaban mutuamente por la pérdida de datos. Si surgía un nuevo error, estoy seguro de que comenzaría un tiroteo.
En estos enfrentamientos finalmente comenzamos a entender que en la empresa pensaban que éramos los tipos que trabajan con datos y supervisan la estructura de las tablas. Confundieron a los administradores con los DBA. Y vinieron a preguntarnos no como administradores.
Su principal queja era: ¿por qué demonios, ustedes eran responsables de las copias de seguridad y no las hicieron correctamente, perdiendo datos? Y todo esto con muchas maldiciones.
Yo quería justicia. Desenterré la correspondencia y presenté todas las capturas de pantalla donde Leonid insiste con todas sus fuerzas en hacer la copia de seguridad tal como se hizo. Su CTO se puso de nuestro lado después de mi llamada telefónica. Después, Leonid también reconoció su culpa.
El director de la empresa, por el contrario, no quería culpar a los suyos. Las capturas y las palabras no le afectaban. Pensaba que, como nosotros éramos los expertos, debíamos haber convencido a todos y insistido en nuestra decisión. Al parecer, nuestra tarea era enseñar a Leonid y, además, pasar por alto a él, designado como líder del proyecto, llegar al jefe y descargar todas nuestras dudas sobre el concepto de copias de seguridad.
El chat se impregnó de odio, con agresión oculta y manifiesta. No sabía qué hacer. Todo había llegado a un punto muerto. Entonces, me sugirieron la manera más simple: escribirle en privado al director y acordar una reunión. Vasya, las personas en la vida real no son tan descaradas como en el chat. A mi mensaje, el jefe respondió: ven, no hay problema.
Fue la reunión más incómoda de mi carrera. Mi aliado del cliente, el CTO, no pudo encontrar tiempo. En la reunión iba con el jefe y Leonid.
Una y otra vez, repetía en mi cabeza nuestro posible diálogo. Logré llegar muy temprano, media hora antes. Comenzó la ansiedad, fumé 10 cigarrillos. Sabía que estaba completamente solo. No podría convencerlos. Y pisé el ascensor.
Mientras subía, encendí el encendedor tantas veces que se rompió.
Al final, Leonid no estaba en la reunión. ¡Y hablamos muy bien sobre todo con el jefe! Sergey me habló de su dolor. No quería 'automatizar ClickHouse', quería 'que las consultas funcionaran'.
No vi a un villano, sino a un buen tipo preocupado por su negocio, inmerso en su trabajo 24/7. A menudo, los chats nos retratan como villanos, canallas y tontos. Pero en la vida real, son las mismas personas que tú.
Sergey no necesitaba un par de devops contratados. El problema que tenían resultó ser mucho más grande.
Dije que podía resolver sus problemas, solo que era un trabajo completamente diferente y tengo un conocido DBA para ello. Si hubiéramos sabido desde el principio que esto era un asunto para ellos, nos habríamos ahorrado mucho. Tarde, pero entendimos que el problema estaba en el mal manejo de datos, no en la infraestructura.
Nos estrechamos las manos, nos aumentaron la tarifa a dos veces y media, pero con la condición de que yo asuma toda la carga de sus datos y ClickHouse. En el ascensor me puse en contacto con ese DBA, Max, y lo involucré en el trabajo. Teníamos que revisar todo el clúster.
Había un montón de basura en el proyecto aceptado. Empezando por el mencionado "backup". Resultó que este mismo clúster de "backup" no era aislado. Se probaba de todo, a veces incluso se ponía en producción.
Los desarrolladores internos crearon su propio "inserter" de datos. Funcionaba así: agrupaba archivos, ejecutaba un script y volcaba los datos en una tabla. Pero el principal problema era que se recibía una cantidad enorme de datos para una petición muy sencilla. La consulta unía los datos por segundo. Todo por un solo número: el total del día.
Los desarrolladores internos utilizaron incorrectamente la herramienta de análisis. Iban a Grafana y escribían su solicitud real. Extrajo datos de las últimas 2 semanas. Se generaba un gráfico bonito. Pero en realidad, la consulta de datos se realizaba cada 10 segundos. Todo esto se acumulaba en la cola, ya que ClickHouse no podía procesar. Aquí se escondía la causa principal. En Grafana nada funcionaba, las consultas estaban en cola y constantemente llegaban datos antiguos y no relevantes.
Reconfiguramos el clúster, rehaciendo la inserción. Los desarrolladores internos reescribieron su "inserter" y comenzó a particionar datos correctamente.
Max realizó una auditoría completa de la infraestructura. Elaboró un plan para pasar a un backend completo. Pero a la empresa no le gustó. Esperaban de Max un secreto mágico que permitiera trabajar como antes, pero de manera efectiva. Leonya seguía siendo responsable del proyecto, quien no aprendió nada. De todo lo propuesto, nuevamente eligió su alternativa. Como siempre, fue la solución más... atrevida. Leonya pensaba que su empresa tenía un camino especial. Áspero y lleno de icebergs.
En realidad, así nos despedimos: hicimos lo que pudimos.
Con experiencias difíciles y aprendidos de esta historia, abrimos nuestro negocio y establecimos algunos principios. Ahora nunca comenzamos un trabajo de la misma manera que lo hicimos entonces.
El desarrollador Max se unió a nosotros después de este proyecto, y seguimos trabajando muy bien juntos. El caso con ClickHouse nos enseñó a realizar una auditoría completa y exhaustiva de la infraestructura antes de comenzar el trabajo. Nos sumergimos en cómo funciona todo y solo después aceptamos las tareas. Y si antes nos lanzábamos a gestionar la infraestructura de inmediato, ahora primero realizamos un proyecto puntual que nos ayuda a comprender cómo ponerla en funcionamiento.
Y sí, evitamos proyectos con infraestructuras deficientes. Incluso si son bien remunerados, incluso si es por amistad. Mantener proyectos problemáticos no es rentable. Darse cuenta de esto nos ha ayudado a crecer. O se hace un proyecto puntual para arreglar la infraestructura y luego un contrato de mantenimiento, o simplemente pasamos de largo. Pasando de otro iceberg.
P.D. Así que, si tiene preguntas sobre su infraestructura, .
Tenemos 2 auditorías gratuitas al mes, tal vez su proyecto sea uno de ellos.
Fuente: habr.com
