Aquí hay una historia que cambió para siempre mi enfoque del trabajo devops. En la época anterior a Covid, mucho, mucho antes de ellos, cuando los muchachos y yo estábamos planificando nuestro propio negocio y trabajándonos independientemente en pedidos aleatorios, una oferta cayó en mi carrito.
La empresa que escribió esto fue una empresa de análisis de datos. Procesaba miles de solicitudes diariamente. Vinieron a nosotros con las palabras: chicos, tenemos ClickHouse y queremos automatizar su configuración e instalación. Queremos que Ansible, Terraform, Docker y todo se almacenen en Git. Queremos un grupo de cuatro nodos con dos réplicas cada uno.
Es una solicitud estándar, hay docenas de ellas y necesita una solución estándar igualmente buena. Dijimos "ok" y después de 2-3 semanas todo estaba listo. Aceptaron el trabajo y comenzaron a mudarse a un nuevo clúster de Clickhouse utilizando nuestra utilidad.
Nadie quería ni sabía cómo jugar con Clickhouse. Entonces pensamos que ese era su principal problema, y por eso la estación de servicio de la empresa simplemente dio luz verde a mi equipo para automatizar el trabajo al máximo, para no volver a ir allí nunca más.
Acompañamos la mudanza, surgieron otras tareas: realizar copias de seguridad y monitorear. Al mismo tiempo, la estación de servicio de esta empresa se fusionó con otro proyecto, dejándonos a uno de los nuestros, Leonid, como comandante. Lenya no era un tipo muy talentoso. Un simple desarrollador que de repente fue puesto a cargo de Clickhouse. Parece que esta fue su primera tarea para administrar algo, y el abrumador honor lo dejó deslumbrado.
Juntos nos propusimos hacer copias de seguridad. Sugerí hacer una copia de seguridad de los datos originales de inmediato. Simplemente tómalo, ciérralo y tíralo elegantemente a un c3. Los datos brutos son oro. Había otra opción: hacer una copia de seguridad de las tablas en Clickhouse, mediante congelación y copia. Pero a Lenya se le ocurrió su propia solución.
Anunció que necesitamos un segundo clúster de Clickhouse. Y a partir de ahora escribiremos datos en dos grupos: el principal y el de respaldo. Le digo, Lenya, que no será una copia de seguridad, sino una réplica activa. Y si los datos comienzan a perderse en producción, sucederá lo mismo en su copia de seguridad.
Pero Lenya agarró con fuerza el volante y se negó a escuchar mis argumentos. Charlamos con él durante mucho tiempo en el chat, pero no había nada que hacer: Lenya estaba a cargo del proyecto, solo éramos niños contratados de la calle.
Monitoreamos el estado del clúster y cobramos solo por el trabajo de los administradores. Pura administración de Clickhouse sin entrar en los datos. El clúster estaba disponible, los discos estaban bien, los nodos estaban bien.
No sabíamos que recibimos este pedido debido a un terrible malentendido dentro de su equipo.
El gerente no estaba contento porque Clickhouse era lento y a veces se perdían datos. Encomendó a su estación de servicio la tarea de resolverlo. Lo resolvió lo mejor que pudo y concluyó que solo necesitábamos automatizar Clickhouse, eso es todo. Pero pronto quedó claro que no necesitaban ningún equipo de desarrollo.
Todo esto resultó ser muy, muy doloroso. Y lo más ofensivo fue que fue el día de mi cumpleaños.
Viernes por la tarde. Hice una reserva en mi bar de vinos favorito e invité a mis amigos.
Casi antes de partir, recibimos la tarea de crear un alter, lo completamos, todo está bien. Alter pasó, confirmó Clickhouse. Ya vamos al bar y nos escriben que no hay datos suficientes. Calculamos que todo parece ser suficiente. Y se fueron a celebrar.
El restaurante era ruidoso un viernes. Después de pedir bebidas y comida, nos tumbamos en los sofás. Durante todo este tiempo, mi holgura se fue inundando lentamente de mensajes. Escribieron algo sobre la falta de datos. Pensé: la mañana es más sabia que la tarde. Especialmente hoy.
Más cerca de las once empezaron a llamar. Era el director de la empresa... “Probablemente decidió felicitarme”, pensé muy vacilante y cogí el teléfono.
Y escuché algo como: “¡Arruinaste nuestros datos! ¡Te pago, pero nada funciona! ¡Eras responsable de las copias de seguridad y no hiciste nada! ¡Vamos a arreglarlo!". - sólo que aún más grosero.
- ¿Sabes qué? ¡Vete a la mierda! ¡Hoy es mi cumpleaños y ahora beberé y no me ocuparé de tus productos caseros de basura y palos de junio!
Eso es lo que no dije. En lugar de eso, saqué mi computadora portátil y me puse a trabajar.
¡No, bombardeé, bombardeé como el infierno! Derramó un cáustico "Te lo dije" en el chat, porque la copia de seguridad, que no era una copia de seguridad en absoluto, por supuesto no guardó nada.
Los chicos y yo descubrimos cómo detener manualmente la grabación y comprobar todo. De hecho, nos aseguramos de que algunos de los datos no estuvieran escritos.
Dejamos de grabar y contamos la cantidad de eventos que había por día. Subieron más datos, de los cuales sólo un tercio no quedó registrado. Tres fragmentos con 2 réplicas cada uno. Inserta 100.000 filas; 33.000 no se registran.
Hubo una completa confusión. Todos se dijeron por turnos que se fueran a la mierda: Lenya fue primero, seguida por mí y el fundador de la empresa. Sólo la estación de servicio que se unió intentó desviar nuestras llamadas y correspondencia hacia la búsqueda de una solución al problema.
Nadie entendió lo que realmente estaba pasando.
Los chicos y yo quedamos impresionados cuando nos dimos cuenta de que un tercio de todos los datos no sólo no se registraban, sino que se perdían. Resultó que el orden en la empresa era el siguiente: después de la inserción, los datos se eliminaban irrevocablemente y los eventos se desperdiciaban en lotes. Me imaginé cómo Sergei convertiría todo eso en rublos perdidos.
Mi cumpleaños también fue tirado a la basura. Nos sentamos en la barra y generamos ideas, tratando de resolver el rompecabezas que nos habían lanzado. El motivo de la caída de Clickhouse no era obvio. Tal vez sea la red, tal vez sea la configuración de Linux. Sí, como quieras, ha habido suficientes hipótesis.
No hice el juramento del desarrollador, pero fue deshonesto abandonar a los chicos al otro lado de la línea, incluso si nos culpaban de todo. Estaba 99% seguro de que el problema no estaba en nuestras decisiones, ni en nuestro lado. El 1% de posibilidades de que hubiéramos cometido un error ardía de ansiedad. Pero no importaba de qué lado estuviera el problema, había que solucionarlo. Dejar a los clientes, sin importar quiénes sean, con una filtración de datos tan terrible es demasiado cruel.
Trabajamos en la mesa del restaurante hasta las tres de la madrugada. Agregamos eventos, insertamos selección y comenzamos a llenar los vacíos. Cuando arruinas los datos, se hace así: tomas los datos promedio de los días anteriores y los insertas en los arruinados.
Pasadas las tres de la mañana, mi amigo y yo fuimos a mi casa y pedimos una cerveza en el mercado de alcohol. Estaba sentado con una computadora portátil y problemas con Clickhouse, un amigo me decía algo. Como resultado, después de una hora se ofendió porque yo estaba trabajando y no bebiendo cerveza con él, y se fue. Clásico: era amigo de Devops.
A las 6 de la mañana, volví a crear la tabla y los datos comenzaron a inundarse. Todo funcionó sin pérdidas.
Entonces fue difícil. Todos se culparon unos a otros por la pérdida de datos. Si hubiera ocurrido un nuevo error, estoy seguro de que habría habido un tiroteo.
En estas peleas, finalmente comenzamos a entender: la empresa pensó que éramos los que trabajamos con datos y monitoreamos la estructura de las tablas. Confundieron a los administradores con los distribuidores. Y vinieron a preguntarnos algo diferente a los administradores.
Su principal queja es: qué diablos, tú eras responsable de las copias de seguridad y no las hiciste correctamente, continuaste desperdiciando los datos. Y todo ello con alfombras de rebobinado.
Quería justicia. Desenterré la correspondencia y adjunté capturas de pantalla de todos, donde Leonid con todas sus fuerzas los obliga a hacer la copia de seguridad que se hizo. Su estación de servicio se puso de nuestro lado después de mi llamada telefónica. Más tarde, Lenya admitió su culpa.
El director de la empresa, por el contrario, no quiso culpar a su propia gente. Las capturas de pantalla y las palabras no tuvieron ningún efecto en él. Creía que como aquí éramos expertos, teníamos que convencer a todos e insistir en nuestra decisión. Al parecer, nuestra tarea era enseñarle a Lenya y, además, pasar por alto a él, quien fue designado como gerente del proyecto, para llegar a lo principal y expresarle personalmente todas nuestras dudas sobre el concepto de copias de seguridad.
La charla rezumaba odio, agresión oculta y no oculta. No sabía qué hacer. Todo se ha paralizado. Y luego me aconsejaron la forma más sencilla: escribir un mensaje personal al gerente y concertar una reunión con él. Vasya, la gente en la vida real no es tan rápida como en el chat. El jefe respondió a mi mensaje: ven, no hay duda.
Fue el encuentro más aterrador de mi carrera. Mi aliado del cliente, STO, no encontró tiempo. Fui a la reunión con el jefe y Lena.
Una y otra vez repetía en mi cabeza nuestro posible diálogo. Logré llegar muy temprano, con media hora de anticipación. Empecé a ponerme nervioso, fumé 10 cigarrillos, lo entendí, eso es todo, estoy jodidamente solo. No podré convencerlos. Y entró en el ascensor.
Mientras se levantaba, golpeó con tanta fuerza el encendedor que lo rompió.
Como resultado, Lenya no estuvo en la reunión. ¡Y tuvimos una gran conversación sobre todo con el jefe! Sergei me habló de su dolor. No quería "automatizar Clickhouse", quería "hacer que las consultas funcionaran".
No vi una cabra, sino un buen tipo, preocupado por su negocio, inmerso en el trabajo 24 horas al día, 7 días a la semana. El chat a menudo nos atrae a villanos, sinvergüenzas y gente estúpida. Pero en la vida estas son personas como tú.
Sergei no necesitaba contratar a un par de desarrolladores. El problema que tenían resultó ser mucho mayor.
Le dije que podía resolver sus problemas; es simplemente un trabajo completamente diferente y tengo un amigo que trabaja para ello. Si hubiéramos sabido desde el principio que se trataba de un trato para ellos, habríamos evitado muchas cosas. Es tarde, pero nos dimos cuenta de que el problema radicaba en la mala gestión de los datos, no en la infraestructura.
Nos dimos la mano, nos aumentaron el sueldo dos veces y media, pero con la condición de que yo me hiciera cargo de todo el lío con sus datos y Clickhouse. En el ascensor, me comuniqué con el mismo DI, Max, y lo conecté al trabajo. Fue necesario palear todo el racimo.
Había mucha basura en el proyecto adoptado. Empezando por la mencionada “copia de seguridad”. Resultó que este mismo grupo de “respaldo” no estaba aislado. Probaron todo en él, a veces incluso lo pusieron en producción.
Nuestros desarrolladores internos han creado su propio insertador de datos personalizado. Trabajó así: agrupó los archivos, ejecutó el script y fusionó los datos en una tabla. Pero el principal problema fue que se aceptó una gran cantidad de datos para una simple solicitud. La solicitud unía los datos cada segundo. Todo por un solo número: la cantidad por día.
Los desarrolladores internos utilizaron incorrectamente la herramienta de análisis. Fueron a la grafana y escribieron su petición real. Subió datos durante 2 semanas. Resultó ser un hermoso gráfico. Pero en realidad la solicitud de datos era cada 10 segundos. Todo esto se fue acumulando en una cola porque Clickhouse simplemente no realizó el procesamiento. Aquí es donde se escondía la razón principal. Nada funcionó en Grafana, las solicitudes estaban en cola y constantemente llegaban datos antiguos e irrelevantes.
Reconfiguramos el clúster, rehicimos la inserción. Los desarrolladores internos reescribieron su "insertor" y comenzaron a fragmentar los datos correctamente.
Max realizó una auditoría completa de la infraestructura. Delineó un plan para la transición a un backend completo. Pero esto no le convenía a la empresa. Esperaban un secreto mágico de Max que les permitiera trabajar a la antigua usanza, pero sólo de manera eficiente. Lenya todavía estaba a cargo del proyecto y no aprendió nada. De todo lo que se le ofreció, volvió a elegir su alternativa. Como siempre, esta fue la decisión más selectiva... audaz. Lenya creía que su empresa tenía un camino especial. Espinoso y lleno de icebergs.
En realidad, ahí es donde nos separamos: hicimos lo que pudimos.
Llenos de conocimiento y sabiduría de esta historia, abrimos nuestro propio negocio y formamos varios principios para nosotros mismos. Nunca empezaremos a trabajar de la misma manera que entonces.
DJ Max se unió a nosotros después de este proyecto y todavía trabajamos muy bien juntos. El caso de Clickhouse me enseñó cómo realizar una auditoría de infraestructura completa y exhaustiva antes de empezar a trabajar. Entendemos cómo funciona todo y sólo entonces aceptamos las tareas. Y si antes nos apresurábamos a mantener la infraestructura, ahora primero hacemos un proyecto único, que nos ayuda a entender cómo ponerla en condiciones de funcionamiento.
Y sí, evitamos proyectos con infraestructura de mala calidad. Aunque sea por mucho dinero, aunque sea por amistad. No es rentable ejecutar proyectos enfermos. Darnos cuenta de esto nos ayudó a crecer. O un proyecto único para poner en orden la infraestructura y luego un contrato de mantenimiento, o simplemente pasamos volando. Más allá de otro iceberg.
PD Entonces, si tiene preguntas sobre su infraestructura, .
Disponemos de 2 auditorías gratuitas al mes, quizás tu proyecto sea uno de ellos.
Fuente: habr.com