Recientemente comenzamos un pequeño proyecto para limpiar cómo partes de nuestros sistemas se comunican detrás de escena en Buffer. Un contexto rápido: usamos algo llamado SQS (Amazon Simple Queue Service). Estas colas actúan como salas de espera para tareas. Una parte de nuestro sistema deja un mensaje y otra lo recoge más tarde. Piense en ello como dejar una nota para un compañero de trabajo: "Oye, cuando tengas la oportunidad, procesa estos datos". El sistema que envía la nota no tiene que esperar una respuesta. Nuestro proyecto Era realizar un mantenimiento de rutina: actualizar las herramientas que utilizamos para probar las colas localmente y limpiar su configuración. Pero mientras estábamos mapeando qué colas usamos realmente, encontramos algo que no esperábamos: siete procesos en segundo plano diferentes (o trabajos cron, que son tareas programadas que se ejecutan automáticamente) y trabajadores que habían estado ejecutándose en silencio durante hasta cinco años. Todos ellos sin hacer absolutamente nada útil. Aquí le explicamos por qué eso es importante, cómo los encontramos y qué hicimos al respecto. La infraestructura cuesta dinero. Hice un cálculo rápido y por uno de esos trabajadores, habríamos pagado entre 360 y 600 dólares en 5 años. Esta es una cantidad modesta en el gran esquema de nuestras finanzas, pero definitivamente es un desperdicio para un proceso que no hace nada. Sin embargo, después de realizar esta limpieza, yo diría que el costo financiero es en realidad la parte más pequeña del problema. Cada vez que un nuevo ingeniero se une al equipo y explora nuestros sistemas, se encuentra con estos procesos misteriosos. Consume tiempo de incorporación y crea incertidumbre. Todos hemos estado allí: mirando un fragmento de código, con miedo de tocarlo porque tal vez esté haciendo algo importante. Incluso la infraestructura "olvidada" ocasionalmente necesita atención. Actualizaciones de seguridad, problemas de dependencia, correcciones de compatibilidad cuando algo más cambia. Hace, y el contexto se fue con ellos. ¿Cómo sucede esto? Es fácil señalar con el dedo, pero la verdad es que esto sucede naturalmente en cualquier sistema de larga duración. Una característica queda obsoleta, pero el trabajo en segundo plano que la respaldaba sigue ejecutándose. Alguien activa un trabajador "temporalmente" para manejar una migración, y nunca se cancela. Una tarea programada se vuelve redundante después de un cambio arquitectónico, pero nadie piensa en verificar. tarea que verificó toda la base de datos en busca de cumpleaños que coincidieran con la fecha actual y envió a los clientes un correo electrónico personalizado. Durante una refactorización en 2020, cambiamos nuestra herramienta de correo electrónico transaccional, pero olvidamos eliminar a este trabajador; siguió funcionando durante cinco años más. Ninguno de estos son fallos de individuos: son fallos de proceso sin una limpieza intencional integrada en nuestra forma de trabajar, la entropía gana. Cómo nuestra arquitectura nos ayudó a encontrarlo Como muchas empresas, Buffer adoptó el movimiento de microservicios (un enfoque popular en el que las empresas dividen sus cuentas). código en muchos servicios pequeños e independientes) hace años. Dividimos nuestro monolito en servicios separados, cada uno con su propio repositorio, canal de implementación e infraestructura. En ese momento, tenía sentido: cada servicio podía implementarse por sí solo, con límites claros entre los equipos. Pero con el paso de los años, descubrimos que la sobrecarga de administrar docenas de repositorios superaba los beneficios para un equipo de nuestro tamaño. resultó ser lo que hizo posible el descubrimiento. En el mundo de los microservicios, cada repositorio es su propia isla. Es posible que los ingenieros que trabajan en otro nunca noten un trabajador olvidado en otro. No hay un lugar único para buscar nombres de cola, ni una vista unificada de qué se está ejecutando y dónde. Ya no existía. La consolidación no fue diseñada para ayudarnos a encontrar infraestructura zombie, pero lo hizo.El descubrimiento es casi inevitable. Lo que realmente hicimos Una vez que identificamos los procesos huérfanos, tuvimos que decidir qué hacer con ellos. Así es como lo abordamos. Primero, rastreamos cada uno hasta su origen. Examinamos el historial de git y la documentación antigua para comprender por qué se creó cada trabajador en primer lugar. En la mayoría de los casos, el propósito original era claro: una migración de datos única, una característica que dejó de funcionar, una solución temporal que dejó de ser útil. Luego confirmamos que realmente no estaban en uso. Antes de eliminar algo, agregamos registros para verificar que estos procesos no estuvieran haciendo algo importante que nos habíamos perdido. Supervisamos durante unos días para asegurarnos de que no recibieran ninguna llamada y los eliminamos gradualmente. No eliminamos todo de una vez. Eliminamos los procesos uno por uno, atentos a cualquier efecto secundario inesperado. (Afortunadamente, no hubo ninguno). Finalmente, documentamos lo que aprendimos. Agregamos notas a nuestros documentos internos sobre lo que cada proceso había hecho originalmente y por qué se eliminó, para que los futuros ingenieros no se pregunten si falta algo importante. Qué cambió después de la limpieza Aún estamos en las primeras etapas de medir el impacto total, pero esto es lo que hemos visto hasta ahora. Nuestro inventario de infraestructura ahora es preciso. Cuando alguien pregunta: "¿Qué trabajadores tenemos?" De hecho, podemos responder esa pregunta con confianza. Las conversaciones de incorporación también se han vuelto más sencillas. Los nuevos ingenieros no se topan con procesos misteriosos y se preguntan si les falta contexto. El código base refleja lo que realmente hacemos, no lo que hicimos hace cinco años. Trate los refactores como arqueología y prevención. Mi mayor conclusión de este proyecto: cada refactor significativo es una oportunidad para la arqueología. Cuando estás en lo profundo de un sistema, entendiendo realmente cómo se conectan las piezas, estás en la posición perfecta para cuestionar lo que aún se necesita. ¿Esa cola de algún proyecto antiguo? ¿El trabajador que alguien creó para una migración de datos única? ¿La tarea programada que hace referencia a una característica de la que nunca has oído hablar? Es posible que todavía se estén ejecutando. Esto es lo que estamos incorporando a nuestro proceso en el futuro: Durante cualquier refactor, pregunte: ¿qué más afecta a este sistema que no hayamos visto en un tiempo? Al desaprobar una característica, rastree hasta sus procesos en segundo plano, no solo el código de cara al usuario. Cuando alguien deja el equipo, documente de qué estaba a cargo, especialmente las cosas que se ejecutan en segundo plano. Todavía tenemos partes más antiguas de nuestra base de código que no se han migrado al repositorio único. todavía. A medida que continuamos consolidándonos, estamos seguros de que encontraremos más de estas reliquias ocultas. Pero ahora estamos preparados para detectarlos y evitar que se formen otros nuevos. Cuando todo el código reside en un solo lugar, la infraestructura huérfana no tiene dónde esconderse.
Lo que aprendimos después de encontrar 7 trabajos olvidados que estuvieron funcionando durante 5 años
By Social Media
·
·
6 min read
·
183 views
Read in:
aa
ace
af
ak
alz
am
ar
as
awa
ay
az
ba
ban
be
bew
+191 more
bg
bho
bik
bm
bn
brx
bs
bug
ca
ceb
cgg
ckb
co
crh
cs
cv
cy
da
de
din
doi
dv
dyu
dz
ee
el
en
eo
es
et
eu
fa
ff
fi
fj
fo
fr
fur
fy
ga
gd
gl
gom
gn
gu
ha
haw
he
hi
hil
hne
hmn
hr
hrx
ht
hu
hy
id
ig
ilo
is
it
ja
jam
jv
ka
kab
kbp
kg
kha
kk
kl
km
kn
ko
kri
ku
ktu
ky
la
lb
lg
li
lij
ln
lo
lmo
lt
ltg
lua
luo
lus
lv
mai
mak
mg
mi
min
mk
ml
mn
mni-mtei
mos
mr
ms
mt
my
nd
ne
nl
nn
no
nr
nso
nus
ny
oc
om
or
pa
pag
pam
pap
pl
ps
pt
pt-br
qu
rn
ro
ru
rw
sa
sah
sat
sc
scn
sg
si
sk
sl
sm
sn
so
sq
sr
ss
st
su
sus
sv
sw
szl
ta
tcy
te
tg
th
ti
tiv
tk
tl
tn
to
tpi
tr
trp
ts
tt
tum
ty
udm
ug
uk
ur
uz
ve
vec
vi
war
wo
xh
yi
yo
yua
yue
zap
zh
zh-hk
zh-tw
zu
