David Dzhalaev | Blog

Админу сегодня исполнилось двадцать один годик, так что разыграем премиум среди падпищеков 😴

It depends on 🤓

Хочу поделиться одним вредным советом, а может, и невредным

При проектировании системы нужно собирать не только требования, но и внешние ограничения.

Причём важно не просто думать в формате «есть ограничение — значит, мы обязаны его выполнить».

Важно задать вопрос: «Что будет, если не соблюсти это ограничение?»

Для меня это было неочевидным, но иногда оказывается, что нарушить ограничение дешевле, чем его выполнить.

Например, мы пилим международный продукт, работающий, в том числе и с пользователями из РФ.
С точки зрения регулятора, нам необходимо локализовать ПД. Штраф за несоблюдение от 1 до 6 млн руб., а стоимость рабочего решения и его поддержки может быть в разы больше.

Поэтому проще либо вообще ничего не делать, и тогда нас заблокируют, как LinkedIn через какое-то время и при должном желании. Либо принять иное решение, которое выгодно нам.

Ключевое это оценить стоимость выполнения, оценить стоимость нарушения и уже на основе этого принять архитектурное решение.

Более того, некоторые ограничения никак не влияют на систему, поэтому можно осознанно идти на риск. Но как всегда есть много нюансов и подводных камней, но хотелось передать именно общую концепцию

Тут недавно каналу исполнилось пять лет🎉

Было бы символично написать этот пост в дату создания, но тогда я был занят делами 😎

А так немного истории: изначально канал создавался для отслеживания прогресса в обучение, а потом тгк резко начали становиться мейнстримом, и я подумал, что надо тоже сделать его публичным. Конечно, хотелось бы уделять больше времени, а не как сейчас, но что-то мне постоянно мешает…

Кроме того, я открыл для себя новое занятие — менторство, от процесса которого получаю удовольствие. Однозначно оно не станет основным видом деятельности, потому что это билет в один конец.

Плюс для меня лично это полезно: лучше структурируются знания 🧠

Уже по традиции хочу поздравить всех с наступающим или уже наступившим Новым годом и пожелать, чтобы в 2026 году у вас было больше поводов чувствовать себя живыми, любимыми и нужными 🥂

➖➖➖➖➖

А еще хочу поблагодарить себя любимого. Спасибо, что несмотря ни на что продолжал потихоньку улучшаться, начал наконец-то уделять себе время и ценить себя чуть больше.
В этом году удалось встретить по-настоящему суперских людей, не все остались рядом, правда, но с этим ничего не поделаешь.
Главное, что эти встречи были, и они сделали год ярче.
И я очень рад, что нет ощущения: «ну вот, очередной год прошёл, а ничего не изменилось».

Пусть следующий год будет лучше текущего во всех аспектах: побольше внутреннего спокойствия, здоровья и побольше стабильности, хотя бы в рамках своей жизни

➖➖➖➖➖➖➖➖

Недавно выбрался на True Tech Arch. Давно хотел посетить этот митап, но все время как-то не складывалось, и мне удалось добраться только к восьмому.

Доклады были достаточно сложными, но мне понравилось, как спикеры смогли на доступном языке преподнести материал. Я не особо погружен в тему AI-агентов и RAG, и поэтому было интересно послушать реальный опыт разных команд.

А ещё наша команда заняла второе место на архитектурной кате. Нужно было спроектировать архитектуру Data Lakehouse для агентовой службы поддержки облачного провайдера. Мы залутали мерч, хотя в целом я уже не охочусь за ним так, как раньше, но все равно приятно.

На почитать:
— Кейс на архитектурную кату

Давно сюда ничего не писал, по причине: то одно, то другое 🤷‍♂️

Выдалась довольно насыщенная осень: путешествия, работа, свидания и учеба. Мне наконец-то удалось закрыть курс, который дался нелегко, я вложил в него много времени, нервов и трудов. И вот прислали сертификатик. Недавно еще узнал о такой технике как Dragon Dreaming, которая учит праздновать всё: и поражения, и промежуточные результаты, и маленькие победы. Поэтому хочу отпраздновать сертификатик и осень в целом.

Сейчас планирую как-то закрыть семак и задачи на работе. Сгонять в другой город и удержаться наплаву при этом 🥃

Фотоотчет с конференции

Нашел для себя интересный момент в работе Kubernetes: по умолчанию kubeadm откажется поднимать кластер, если включен swap и потребует его отключения перед тем как продолжить.

Эта штука может понадобиться, когда наш под потребляет больше оперативной памяти, чем ожидали. Представим, что у нас настроен региональный кластер с тремя зонами, в котором есть под, потребляющий на пиках более 30 гб. Без swap нужны ноды на более 40 гб в каждой из трёх зон. С тремя продакшен кластерами и десятью тестовыми это уже 25+ нод и расходы на инфраструктуру улетают в космос. Без swap kubelet убьет под с OOMKilled, а с ним он сможет какое-то время прожить. Этот механизм может ещё пригодится в edge-node, где без swap ворклоады вообще не запустятся. Но есть нюанс: перекладывание данных на диск это I/O операция и из-за этого кластер может тормозить.

Но есть пару технических нюансов:
— Если swap включен, то при нехватке памяти под будет записан на диск, а это вызовет деградацию перформанса всей VM или сервера, особенно, при rolling update.
— Если swap отключен, kubelet не поднимет под и в его описании напишет — Insufficient memory. Дальше ответственность за правильный scheduling подод ложится на инженеров через механизмы распределения нагрузки. А с v1.22 в k8s появилась поддержка swap в альфа-режиме, а с v1.28 — в бета. То есть теперь kubelet может быть запущен на ноде с включенным swap, если указать это в конфиге.

Опять же технические нюансы:
— swap доступен только Pod с Burstable QoS
— Guaranteed, BestEffort и высокоприоритетные Pods использовать его не могут
— объём swap рассчитывается автоматически, пропорционально memoryRequest
По сути swap как бы включён, но использовать его может только часть ворклоадов — и то не в полном объёме.

В итоге всё сводится к вопросу trade-off: swap иногда может спасти с сэкономить ресурсы, но может тормозить и снижать изоляцию подов, особенно если неправильно приготовить

На почитать:
— Swap Linux Improvements
— Swap memory management
— Performing a Rolling Update