Недавно мы начали небольшой проект по очистке того, как части наших систем взаимодействуют за кулисами в Buffer. Небольшой контекст: мы используем так называемую SQS (Amazon Simple Queue Service). Эти очереди действуют как комнаты ожидания для задач. Одна часть нашей системы отправляет сообщение, а другая забирает его позже. Думайте об этом как оставлять записку для коллеги: «Эй, когда у вас будет возможность, обработайте эти данные». Системе, которая отправляет заметку, не нужно ждать, пока ответ. Наш проект заключался в проведении планового обслуживания: обновлении инструментов, которые мы используем для локального тестирования очередей, и очистке их конфигурации. Но пока мы определяли, какие очереди мы на самом деле используем, мы обнаружили то, чего не ожидали: семь различных фоновых процессов (или заданий cron, которые представляют собой запланированные задачи, которые выполняются автоматически) и рабочие процессы, которые работали молча в течение пяти лет. Все они не делали абсолютно ничего полезного. Вот почему это важно, как мы их нашли и что мы с этим сделали. Почему это важно больше, чем вы могли бы подумать. Думаю, да, эксплуатация ненужной инфраструктуры стоит денег. Я быстро подсчитал, и за одного из этих работников мы бы заплатили ~ 360–600 долларов в течение 5 лет. Это скромная сумма в общей схеме наших финансов, но определенно пустая трата для процесса, который ничего не дает. Однако, после этой очистки, я бы сказал, что финансовые затраты на самом деле являются наименьшей частью проблемы. Каждый раз, когда к команде присоединяется новый инженер и исследует наши системы, он сталкивается с этими загадочными процессами: «Что делает этот рабочий. «делать?» становится вопросом, который съедает время адаптации и создает неопределенность. Мы все были там — смотрели на фрагмент кода, боясь прикоснуться к нему, потому что, возможно, он делает что-то важное. Даже «забытая» инфраструктура иногда требует внимания. Обновления безопасности, проблемы с зависимостями, исправления совместимости, когда что-то еще меняется. Это привело к тому, что наша команда тратила циклы обслуживания на пути кода, которые не служили никакой цели. И со временем институциональные знания исчезают. он ушел из компании много лет назад, и контекст ушел вместе с ними. Как это вообще происходит? Легко указывать пальцем, но правда в том, что это происходит естественным образом в любой долгоживущей системе. Функция устаревает, но поддерживающее ее фоновое задание продолжает работать. Кто-то «временно» запускает рабочий процесс для управления миграцией, и его никогда не срывают. Запланированная задача становится избыточной после архитектурного изменения, но никто не думает проверять. Раньше мы отправляли электронные письма о праздновании дня рождения в Buffer. Для этого мы запустили запланированное задание, которое проверило всю базу данных на наличие дней рождения, соответствующих текущей дате, и отправило клиентам персонализированное электронное письмо. Во время рефакторинга в 2020 году мы переключили наш инструмент транзакционной электронной почты, но забыли удалить этого исполнителя — он продолжал работать еще пять лет. Ничто из этого не является сбоем отдельных лиц — это сбой процесса. Без преднамеренной очистки, встроенной в нашу работу, энтропия побеждает. Как наша архитектура помогла нам найти его. Как и многие компании, Buffer использует микросервисы. Движение (популярный подход, при котором компании разделяют свой код на множество небольших независимых сервисов) много лет назад. Мы разделили наш монолит на отдельные сервисы, каждый со своим собственным репозиторием, конвейером развертывания и инфраструктурой. В то время это имело смысл: каждый сервис можно было развернуть отдельно, с четкими границами между командами. Но с годами мы обнаружили, что накладные расходы на управление десятками репозиториев перевешивают преимущества для команды нашего размера, поэтому мы объединились в единый мультисервисный репозиторий, но они все еще существуют. жить вместе в одном месте. Именно это и сделало открытие возможным. В мире микросервисов каждый репозиторий — это отдельный остров. Забытый работник в одном репозитории может никогда не быть замеченным инженерами, работающими в другом. Не существует единого места для поиска имен очередей, нет единого представления о том, что и где происходит. Собрав все в один репозиторий, мы наконец смогли увидеть полную картину. Мы могли отслеживать каждую очередь до ее потребителей и производителей. Мы могли обнаружить очереди с производителями, но не ссылающиеся на очереди. существовало дольше. Объединение не было предназначено для того, чтобы помочь нам найти зомби-инфраструктуру — но оно сделало этоОткрытие почти неизбежно. Что мы на самом деле сделали Как только мы определили бесхозные процессы, нам пришлось решить, что с ними делать. Вот как мы к этому подошли. Во-первых, мы проследили происхождение каждого из них. Мы изучили историю git и старую документацию, чтобы понять, почему каждый рабочий процесс был создан вообще. В большинстве случаев первоначальная цель была ясна: однократная миграция данных, функция, которая больше не используется, временный обходной путь, который изжил себя. Затем мы подтвердили, что они действительно не используются. Прежде чем что-либо удалять, мы добавили ведение журнала, чтобы убедиться, что эти процессы не делают незаметно что-то важное, что мы пропустили. В течение нескольких дней мы следили за тем, чтобы они вообще не вызывались, и постепенно удаляли их. Мы не удалили все сразу. Мы удалили процессы один за другим, отслеживая любые неожиданные побочные эффекты. (К счастью, их не было.) Наконец, мы задокументировали то, что узнали. Мы добавили в нашу внутреннюю документацию примечания о том, что изначально делал каждый процесс и почему он был удален, чтобы будущие инженеры не задавались вопросом, не пропало ли что-то важное. Что изменилось после очистки. Мы все еще находимся на ранней стадии измерения полного воздействия, но вот что мы уже видели. Наша инвентаризация инфраструктуры теперь точна. Когда кто-то спрашивает: «Какими работниками мы пользуемся?» мы действительно можем с уверенностью ответить на этот вопрос. Обсуждения в рамках адаптации также стали проще. Новые инженеры не сталкиваются с загадочными процессами и не задаются вопросом, не упускают ли они контекст. Кодовая база отражает то, что мы на самом деле делаем, а не то, что мы делали пять лет назад. Относитесь к рефакторингу как к археологии и предотвращению. Мой самый большой вывод из этого проекта: каждый значительный рефакторинг — это возможность для археологии. Когда вы глубоко погружены в систему и действительно понимаете, как ее части связаны между собой, вы находитесь в идеальной позиции, чтобы задаться вопросом, что еще необходимо. Эта очередь из какого-то старого проекта? Рабочий, который кто-то создал для однократной миграции данных? Запланированное задание, которое ссылается на функцию, о которой вы никогда не слышали? Они, возможно, все еще работают. Вот что мы встраиваем в наш процесс в будущем: Во время любого рефакторинга спросите: что еще касается этой системы, на что мы давно не смотрели? При объявлении устаревшей функции отслеживайте ее вплоть до ее фоновых процессов, а не только кода, работающего с пользователем. Когда кто-то покидает команду, документируйте то, за что он отвечал, особенно то, что работает в фоновом режиме. У нас все еще есть старые части нашей кодовой базы, которые не были перенесены в единый репозиторий. еще. Продолжая объединяться, мы уверены, что найдем еще больше этих скрытых реликвий. Но теперь мы настроены ловить их и предотвращать образование новых. Когда весь ваш код находится в одном месте, бесхозной инфраструктуре негде спрятаться.
Чему мы научились, обнаружив 7 забытых вакансий, работавших в течение 5 лет
By Social Media
·
·
6 min read
·
550 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
