Recentemente iniciamos un pequeno proxecto para limpar como se comunican partes dos nosos sistemas entre bastidores en Buffer. Algún contexto rápido: usamos algo chamado SQS (Amazon Simple Queue Service. Estas filas actúan como salas de espera para tarefas. Unha parte do noso sistema deixa unha mensaxe e outra recollea máis tarde. Pense niso como deixar unha nota para un compañeiro de traballo cando recibe estes datos: note non ten que esperar unha resposta. O noso proxecto consistía en realizar un mantemento rutineiro: actualizar as ferramentas que usamos para probar as colas localmente e limpar a súa configuración. Pero mentres estabamos a mapear as colas que usamos realmente, atopamos algo que non esperabamos: sete procesos en segundo plano diferentes (ou traballos cron, que son tarefas programadas que se executan automaticamente) e os traballadores non levaban feito nada durante cinco anos útil. Aquí tes por que importa, como os atopamos e o que fixemos. Por que isto é máis importante do que pensas. Si, executar unha infraestrutura innecesaria custa diñeiro, fixen un cálculo rápido e para un deses traballadores, pagaríamos entre 360 e 600 $ durante 5 anos. Cada vez que un novo enxeñeiro se une ao equipo e explora os nosos sistemas, atópanse con estes procesos misteriosos. "¿Que fai este traballador convértese nunha pregunta que consume o tempo de incorporación e crea incerteza? Todos estivemos aí, mirando algo importante. A infraestrutura "esquecida" de cando en vez precisa de atención ás actualizacións de seguridade, problemas de dependencia, correccións de compatibilidade cando algo máis cambiou. a verdade é que isto ocorre de forma natural en calquera sistema de longa duración. Unha función queda obsoleta, pero o traballo en segundo plano que a admitiu segue funcionando "temporalmente" para xestionar unha migración e nunca se derrumba base de datos enteira para os aniversarios que coincide coa data actual e enviamos aos clientes un correo electrónico personalizado. Durante un refactor en 2020, cambiamos a nosa ferramenta de correo electrónico transaccional, pero esquecémonos de eliminar este traballador; seguiu funcionando durante cinco anos máis. Ningún destes son fallos de procesos. Sen unha limpeza intencionada integrada na forma en que traballamos, a entropía axudou a moitas empresas a atopar a solución. Movemento de microservizos (un enfoque popular onde as empresas dividiron o seu código en moitos servizos pequenos e independentes) hai anos. Dividimos o noso monolito en servizos separados, cada un co seu propio repositorio, canalización de implantación e infraestrutura. Naquel momento, tiña sentido: cada servizo podíase implantar por si mesmo, con límites claros entre os equipos nun único repositorio multiservizo. Os servizos aínda existen como límites lóxicos, pero conviven nun só lugar. Isto resultou ser o que fixo posible o descubrimento. No mundo dos microservizos, cada repositorio é a súa propia illa. Os enxeñeiros que traballan nun repositorio nunca se decatarán dun único lugar onde buscar un repositorio único. Por fin puidemos ver a imaxe completa. Puidemos rastrexar cada cola ata os seus consumidores e produtores. Puidemos detectar colas con produtores, pero sen consumidores. Podemos atopar traballadores con colas que xa non existían. A consolidación non foi deseñada para axudarnos a atopar unha infraestrutura zombie.descubrimento case inevitable.O que realmente fixemosUnha vez identificados os procesos orfos, tivemos que decidir que facer con eles. Velaquí como o abordamos.En primeiro lugar, rastrexamos cada un ata a súa orixe. Exploramos a historia de git e a documentación antiga para entender por que se creou cada traballador en primeiro lugar. Na maioría dos casos, o propósito orixinal era claro: unha migración de datos única, unha función que conseguiu o solpor, unha solución temporal que sobreviviu á súa utilidade. Despois confirmamos que estaban realmente sen usar. Antes de eliminar calquera cousa, engadimos o rexistro para verificar que estes procesos non estaban facendo en silencio algo importante que nos perdemos. Vixiamos durante uns días para asegurarnos de que non fosen chamados en absoluto e eliminámolos gradualmente. Non eliminamos todo á vez. Eliminamos os procesos un por un, observando os efectos secundarios inesperados. (Por sorte, non houbo.)Finalmente, documentamos o que aprendemos. Engadimos notas aos nosos documentos internos sobre o que cada proceso fixera orixinalmente e por que se eliminou, para que os futuros enxeñeiros non se preguntaran se faltou algo importante. O que cambiou despois da limpeza. Cando alguén pregunta: "Que traballadores diriximos?" de feito podemos responder a esa pregunta con confianza. As conversacións de incorporación tamén se fixeron máis sinxelas. Os novos enxeñeiros non tropezan con procesos misteriosos e se preguntan se lles falta contexto. O código base reflicte o que realmente facemos, non o que fixemos hai cinco anos. Trata os refactores como arqueoloxía e prevención. A miña maior conclusión deste proxecto: cada refactor significativo é unha oportunidade para a arqueoloxía. Cando estás profundamente nun sistema, entendendo realmente como se conectan as pezas, estás na posición perfecta para cuestionar o que aínda se necesita. Esa cola dalgún proxecto vello? O traballador creado por alguén para unha única migración de datos? A tarefa programada que fai referencia a unha función da que nunca escoitou falar? Poden aínda estar en execución.Aquí está o que estamos incorporando no noso proceso de cara ao futuro:Durante calquera refactorización, pregunte: que máis afecta a este sistema que hai tempo que non miramos? Cando deixemos de usar unha función, rastrexala ata os seus procesos en segundo plano, non só o código orientado ao usuario. Cando alguén abandone o equipo, documente o que estaba a cargo das pezas que aínda temos en segundo plano. base de código que aínda non se migraron ao repositorio único. A medida que seguimos consolidando, estamos seguros de que atoparemos máis destas reliquias ocultas. Pero agora estamos preparados para atrapalos e evitar que se formen outros novos. Cando todo o teu código vive nun só lugar, a infraestrutura orfa non ten onde esconderse.
O que aprendemos despois de atopar 7 traballos esquecidos durante 5 anos
By Social Media
·
·
6 min read
·
500 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
