☠️Однажды мне пришлось проектировать и разрабатывать... Могильные камни.☠️

И нет, я не подрабатывала проектировщиком в похоронном бюро. Хотя...

В своей практике я сталкивалась с двумя видами «могильных камней». В обоих случаях дело касалось данных.

1️⃣ В первом случае, нужно было не удалять данные физически полностью, а сохранить возможность их восстановления. При этом данные должны были стать недоступны в системе для пользователей и не восстанавливаться при следующей репликации. Стандартных механизмов в нашей БД не было. С одной стороны, задача оказалась не слишком сложной, всё было решено с помощью «перемещения» данных в специальную область на заданное время. Но с другой, это начинало влиять на репликацию, особенно если пользователи каким-то образом добирались в эту особую область и начинали использовать её как корзину.

2️⃣ Во втором случае, уже в некоторых БД, преимущественно NoSQL, подобная фишка была встроена либо в саму БД, либо через плагины. Там данные действительно удалялись физически, но на узле сохранялась специальная метка о том, что данные были удалены. Уcловно key:{Ключ данных} deleted_at: <timestamp> Это помогало предотвратить их восстановление при репликации и сохраняло целостность системы.

К несчастью, я узнала о могильных камнях не в начале пути, а когда успела реализовать несколько решений, связанных с удалением. Жила себе в счастливом неведении, почему удаление одна из самых сложных CRUD операций. А потом столкнулась со вторым кейсом. Пользователи не могли удалить данные: на одной реплике данные удалялясь, но один из серверов игнорировал метки об удалении и восстанавливал их при репликации. В результате получалась прекрасная картина: данные есть, метка об их удалении тоже есть. Особое веселье начиналось при массовых операциях удаления. Всё это, конечно, привело к рассогласованию узлов и понижению моей самооценки🙈😂

С тех пор «могильные камни» в работе напоминание, что прошлое может внезапно вернуться…
Если не похоронено правильно.

А с какой "чернухой" приходилось столкнуться в работе вам?

#системныйанализ #базыданных #удалениеданных #репликация #itюмор

Инструкция как заставить команду плакать или как работает авторитет


Однажды я случайно удалила спецификацию OpenAPI всего продукта и это попало 🥁на прод 🥁

✏️Инструкция:✏️ удалить спеку, проверить третьем глазом, залить это в гит и отправить на ревью лиду бэков в пятницу вечером, как же без этого? А если добавить что вам срочно в отпуск, то: лид апрувит и смерджит всё в мастер. Вы счастливые уходите в отпуск. В понедельник QA, конечно, вашего счастья разделять не будут.

Как так вышло?

Во-первых, сыграл мой авторитет. Я на тот момент лучше всех понимала наше API и как раз настраивала процесс работы с ним и сваггером. После моего пул реквеста лид что-то заподозрил и пришёл ко мне с вопросом «Что за фигня, Катя?». Но я с полной уверенность «Тоже видела, как-то странно отображается, да, но я всё проверила, и там всё хорошо» убедила его не копать дальше. Ну а зачем копать глубже, если я вроде бы одна из немногих, кто вообще в этом шарит, и единственная, кто отвечает?

Во-вторых, чтобы процесс ревью работал, нужно, чтобы ревьюер очень чётко понимал, что от него ждут. В нашем случае цель была — отсеять новичков. Те меня процесс ревью как то не учитывал.

Очень неудачная спека на 30 тысяч строк. В гитоподобных системах в процессе ревью с таким тяжело работать.

Я собиралась в отпуск, было срочно. Поэтому сама не стала вникать, а почему всё светится красным? И коллега тоже не хотел меня подставлять перед отпуском (подставил в итоге себя).

Так, на два дня, мой авторитет, неудачный YAML и неотлаженные процессы затормозили разработку. После этого случая я стала замечать, что опытные тоже ошибаются, часто (Вот здесь можно почитать о другом фейле), но из-за авторитета и возможно лени, это чаще пропускают. Только вот задачи такие специалисты делают более важные, которые чаще могут что-то сломать.

В вашей практике как? Часто с таким сталкиваетесь? Что было самым фатальным?

Меня подвело… моё собственное тело.

Острый приступ остеохондроза буквально сказал: Галя, у нас отмена! Летний пляж - отмена. Внерабоче-профессиональные активности - тоже отмена. Да, даже повторение воркшопа по EventStorming(

Надолго? Пока непонятно. Даже с крутым ДМС оперативно и качественно получить лечение не получается.

Конечно, я очень расстроена. Немножко в шоке. И в большой обиде. Но поплакать хотелось не об этом.

Вчера на приёме врач предложил открыть больничный. А у нас в компании он полностью оплачивается — как говорится, кэш не проблема. Что сделала я?
👎 ОТКАЗАЛАСЬ!!! 👎
А потом весь день хотела позвонить в клинику и сказать: «Я передумала, откройте, пожалуйста, больничный».

Причины отказа казались рациональными: Мне сейчас важно запустить один проект-функционал в разработку, чтобы потом не подставить команду, и, что важнее, саму себя. И вроде как… работать могу. Да и, честно, боюсь, что пойдёт что-то не так на самом старте.

Но остеохондроз в острой фазе очень выматывает. Усталость, пониженная концентрация, даже думается хуже. Возможно поэтому др меня медленно начало доходить: Я болею. Мне положен больничный. На работе никто бы не сказал ни слова. У нас нет культа «работай всегда». Есть коллеги, которые берут больничные, отпуска и их работу по-прежнему высоко ценят.

И вот тогда стало по-настоящему грустно. Я зачем-то поставила проект выше самого важного: заботы о себе.

Искренне завидую и восхищаюсь людьми, которые умеют расставлять приоритеты и при этом остаются крутыми специалистами. Когда вырасту по-настоящему, хочу стать как вы.

Можно ли на одном мероприятии поговорить про базы данных, процессы в разработке, переместиться в 2008, чуть не стать жертвой слэма, а затем всю ночь тусить в арбузном шатре Альфа-Банка?

НУЖНО! На ULCamp!
Да, это я отошла от выходных и готова поделиться с вами впечатлениями.

🛠 Доклады🛠
Было много лёгких, болтательных, практических докладов. Лёгкость подачи и вся атмосфера вокруг позволяли легко общаться с профессионалами в своей области. Момент он или она рассказывают о том, как круто сделали, следующий кадр вы вместе идёте в бар и обсуждаете боли (и не только). А за прослушивание некоторых докладов вас еще и коктелем угостят!

🦄 Активности🦄
Очень много. Совершенно разных. От ИТ-компаний, художников и даже яхт-клуба. Покататься под парусом с яхтсменом? Легко. Но ему будет не больше 10 лет :) Лично меня больше всего зацепила площадка Postgres Pro, именно поэтому я только их доклады и успела послушать между попытками покататься на быке из ковбойских фильмов. И даже не слететь!
Можно ехать с семьёй и с друзьями, не связанными с ИТ: активностей хватит на всех.

🎧 Музыка и танцы🎧
К музыкальной программе мы подготовились. Стразы и светящиеся браслеты наше всё! Танцевала вопреки больной спине и простуде. Успела и оценить юмор группы ГУДТАЙМС, словить ассоциации с Безумным Максом от выступления Jane Air, чилила под уже любимого DJ Kradson из Ульяновска.

Поэтому слегка неловко сегодня на защите перед архкомитетом объясняла причину своего сорвавшегося голоса.
Но и это того стоило.

🫨 Минусы тоже были🫨
Санитарный блок и палатки в поле возвращали на землю. Ну не самым лучшим образом было организовано.

В остальном даже почти полное отсутствие интернета не смущало, просто было решительно некогда им пользоваться. И, возможно, это слегка сэкономило мне деньги, когда при попытке покупки очередной безделушки у меня не проходил платёж.

Так что запоминайте:
Ульяновск. Лето. ULCamp.
И давайте повторим в следующем году!

PS Если были на подобных мероприятиях делитесь в комментариях. А то может следующем летом устроим турне)
#ULCamp #alfamusicnight

Если вам кажется, что вы понимаете, что такое транзакции - вам кажется.

Несколько лет назад в знаменитом «кабанчике» Клеппмана я прочитала:

"Транзакции оказались главной жертвой" NoSQL БД: "многие базы нового поколения полностью отказались или поменяли значение термина — теперь он стал означать намного более слабый набор функциональных гарантий."

Хм, интересно, подумала я, но тогда не придала этому значения. Позже я начала работать с 389 Directory Server - иерархической БД на протоколе LDAP.

😮И... сюрприз, сюрприз: 😮 в базовой комплектации в ней нет транзакционности в привычном для SQL-разработчика смысле.

Что это значит:

- Как только произошла операция над объектом (в LDAP это ADD, MODIFY, DELETE) и она подтверждена сервером — она фиксируется.
- Нет отката изменений для группы объектов.
- Можно накрутить костылей вокруг changelog, чтобы имитировать транзакцию, но это будет уже backend-код, а не гарантия от самой БД.

При более детальном разборе оказалось, что в каком-то виде транзакционность (а точнее часть A из ACID) всё же есть, если речь о нескольких изменениях в рамках одной команды, обращённой к одному объекту.

В Пример 1, это обрабатывается как единая операция: либо применяется всё, либо ничего.

 в группе Editors
ADD UserA, UserB  
DELETE UserX, UserY  

С этого момента жить стало проще… до тех пор, пока ко мне не принесли пачку запросов с неконсистентными данными, которые такими быть не долждны были (в нашем понимании).

Причина в том, что к одному объекту можно атомарно обратиться по-разному:

Как в примере 1, или же сделать те же действия, но двумя отдельными командами (пример 2, каждое объявление группы начинает новую операцию):

в группе Editors
ADD UserA, UserB
в группе Editors
DELETE UserX, UserY

При работе на одном сервере: в первом случае атомарность гарантируется на уровне операции, во втором за счет транзакции уровня backend-хранилища (DBTxn). В целом зная об этом, у нас частенько встречались оба варианта операций.

⚠️Вот только⚠️, при репликации каждая команда получает свой CSN (номер изменения) и всегда выполняется отдельно. В результате в Примере 2 первая операция может примениться, а вторая - нет. Хотя на одном сервере, они всегда выполняются вместе.

Когда, казалось бы, я уже понимаю этим важные моменты, мне пришлось столкнуться с RFC 5805 (LDAP Transactions), который открывает перед LDAP возможности транзакционности при использовании специальных патчей. Но это уже совсем другая история.

Так что, если вы уверены, что уже хорошо разбираетесь в транзакциях, но работали только с реляционными СУБД, вас ждёт немало сюрпризов.

💬 Ну а те кто уже хлебнул разных систем, поделитесь с какой «недо»-транзакционностью сталкивались? К чему это приводило? Что было самым необычным?

Участвую в конкурсе #продолжи_мысль_SE от @systems_education

#LDAP #транзакции #СУБД