Нещодавно ми розпочали невеликий проект, щоб очистити те, як частини наших систем взаємодіють за лаштунками в Buffer. Трохи короткого контексту: ми використовуємо щось під назвою SQS (Amazon Simple Queue Service. Ці черги діють як кімнати очікування для завдань. Одна частина нашої системи надсилає повідомлення, а інша забирає його пізніше. Подумайте про це як про те, щоб залишити записку для колеги: «Гей, коли буде можливість, обробіть ці дані». Система, яка надсилає note не потрібно чекати відповіді.Наш проект полягав у виконанні планового обслуговування: оновленні інструментів, які ми використовуємо для локального тестування черг, і очищення їхньої конфігурації.Але поки ми визначали, які черги ми насправді використовуємо, ми виявили те, чого не очікували: сім різних фонових процесів (або завдань cron, які виконуються автоматично за розкладом) і воркерів, які працювали безшумно протягом п’яти років. Усі вони абсолютно нічого не робили Ось чому це важливо, як ми їх знайшли та що ми з цим зробили. Чому це важливіше, ніж ви думаєте. Так, використання непотрібної інфраструктури коштує грошей, і за одного з цих працівників ми заплатили б ~360-600 доларів США за 5 років. Це скромна сума в нашій фінансовій схемі, але безперечно марнотратство для процесу, який нічого не дає. Щоразу, коли новий інженер приєднується до нашої команди, він стикається з цими таємничими процесами. «Що робить цей працівник?» Стає питанням, яке з’їдає час на підготовку та створює невизначеність оновлення, помилки сумісності, коли щось інше змінюється. Це призвело до того, що наша команда витрачала цикли обслуговування на шляхи коду, які не мали сенсу. Чи це було критичним, але це було тимчасове виправлення, яке пішло з компанії багато років тому. Функція стає застарілою, але фонове завдання продовжує працювати. Хтось запускає робочу функцію для обробки міграції, і вона ніколи не стає зайвою після зміни архітектури. Раніше ми надсилали електронні листи для святкування днів народження в Buffer дні народження, що збігаються з поточною датою, і надсилають клієнтам персоналізовану електронну пошту. У 2020 році ми змінили наш інструмент транзакційної електронної пошти, але забули видалити цей робочий файл — він продовжував працювати ще п’ять років. Це несправності окремих людей — без навмисного очищення, вбудованого в нашу роботу, ентропія виграє. Як наша архітектура допомогла нам знайти це, як і багато компаній, Buffer рух мікросервісів (популярний підхід, коли компанії розділяють свій код на безліч невеликих незалежних сервісів) багато років тому. Ми розділили наш моноліт на окремі сервіси, кожен з яких мав власний репозиторій, конвеєр розгортання та інфраструктуру. На той час це мало сенс: кожен сервіс можна було розгортати самостійно, з чіткими межами між командами. Але з роками ми виявили, що накладні витрати на керування десятками репозиторіїв переважують переваги для. Команда нашого розміру. Сервіси все ще існують як логічні межі, але вони живуть разом. Це стало можливим у світі мікросервісів. Інженери, які працюють в іншому, можуть ніколи не помітити забутого працівника Маючи все в одному репозиторії, ми могли відстежити кожну чергу до її споживачів і виробників. Ми могли виявити черги з виробниками, але не могли знайти працівників, які посилаються на черги, яких більше не існує.Відкриття майже неминуче. Що ми насправді зробили. Коли ми визначили загублені процеси, нам потрібно було вирішити, що з ними робити. Ось як ми підійшли до цього. Спочатку ми відстежили походження кожного з них. Ми переглянули історію git і стару документацію, щоб зрозуміти, чому взагалі було створено кожного воркера. У більшості випадків початкова мета була зрозумілою: одноразова міграція даних, функція, яка припинила свою дію, тимчасовий обхідний шлях, який пережив свою корисність. Потім ми підтвердили, що вони справді не використовувалися. Перш ніж щось видаляти, ми додали журналювання, щоб переконатися, що ці процеси тихо не виконують щось важливе, що ми пропустили. Ми спостерігали протягом кількох днів, щоб переконатися, що їх взагалі не викликали, і ми поступово видаляли їх. Ми не видаляли все відразу. Ми видаляли процеси один за одним, спостерігаючи за будь-якими неочікуваними побічними ефектами. (На щастя, їх не було.) Нарешті ми задокументували те, що дізналися. Ми додали примітки до наших внутрішніх документів про те, що спочатку робив кожен процес і чому його було видалено, щоб майбутні інженери не задавалися питанням, якщо щось важливе пропало. Що змінилося після очищення. Ми ще на початку вимірювання повного впливу, але ось що ми бачили наразі. Наша інвентаризація інфраструктури тепер точна. Коли хтось запитає: "Яких працівників ми запускаємо?" насправді ми можемо з упевненістю відповісти на це запитання. Розмови про адаптацію також стали простішими. Початківці інженери не натрапляють на таємничі процеси й не думають, чи не втрачають вони контексту. База коду відображає те, що ми насправді робимо, а не те, що ми робили п’ять років тому. Сприймайте рефактори як археологію та профілактику. Мій найбільший висновок із цього проекту: кожен значний рефактор — це можливість для археології. Коли ви глибоко в системі, справді розуміючи, як її частини з’єднуються, ви знаходитесь у ідеальній позиції, щоб поставити під сумнів те, що ще потрібно. Ця черга з якогось старого проекту? Робочий файл, який хтось створив для одноразової міграції даних? Заплановане завдання, яке посилається на функцію, про яку ви ніколи не чули? Вони можуть усе ще працювати. Ось що ми вбудовуємо в наш подальший процес: під час будь-якої рефакторингу запитайте: що ще стосується цієї системи, на що ми давно не звертали уваги? Під час припинення підтримки функції простежте її до її фонових процесів, а не лише до коду, який відкриває користувач. Коли хтось залишає команду, документуйте, за що вони відповідали, особливо те, що працює у фоновому режимі. У нас все ще є старіші частини нашого кодової бази, які ще не перенесено до єдиного репозиторію. Продовжуючи консолідацію, ми впевнені, що знайдемо більше цих прихованих реліквій. Але тепер ми налаштовані ловити їх і запобігати утворенню нових. Коли весь ваш код живе в одному місці, осиротілій інфраструктурі ніде сховатися.
Чого ми навчилися, знайшовши 7 забутих вакансій, які працювали протягом 5 років
By Social Media
·
·
6 min read
·
529 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
