Call for papers: принимаем заявки от докладчиков на infra.conf до 5 апреля
Мы готовимся к infra.conf 2025 — летней конференции про создание инфраструктуры и эксплуатацию высоконагруженных систем от команды Yandex Infrastructure. 5 июня обсудим список наиболее интересных хардкорных тем:
базы данных: шины, брокеры, OLAP, хранение и обработка данных;
платформы разработки / инфраструктура разработки;
инфраструктура для мобильной разработки;
инфраструктура для фронтенда;
ML‑инфраструктура;
виртуальные машины, гибридные облака, контейнеры;
мониторинг, observability;
ДЦ/ЦОДы, железо, аппаратное обеспечение;
умные устройства, системная разработка.
В 2025 году событие пройдёт во второй раз — смотрите в нашем плейлисте, как это было прошлым летом.
До 5 апреля вы можете подать заявку на доклад infra.conf 2025 — для этого нужно заполнить форму. На этапе заявки достаточно черновых тезисов и общего плана выступления. Программный комитет будет готов обсудить ваши идеи и предложения. Финальное решение по докладам примем до 20 апреля.
По возникшим вопросам вы можете обратиться к координатору infra.conf Саше Галкиной.
Код с ИИ стал «дешевле», а вот архитектура дороже.
Генеративный ИИ позволяет быстрее проверять идеи и проводить эксперименты, но без умения задавать правильные вопросы и опыта в выстраивании SDLC, это всего лишь позволит вам генерировать больше кода низкого качества.
Вот например пришла идея посчитать косты и спрогнозировать расходы на K8s в облаке и on-prem. Конечно есть много (в основном платных) проектов типа Kubecost, но они не достаточно гибкие для решения такого рода задач.
Если об этом попросить ИИ то он поможет сгенерировать почти работающий скрипт, который нужно будет поправить. Но выберет самое наивное решение, забрать метрики через metrics API:
# Fetch pod metrics for a specific namespace
def get_pod_metrics(namespace):
try:
result = subprocess.run(
["kubectl", "get", "--raw", f"/apis/metrics.k8s.io/v1beta1/namespaces/{namespace}/pods"],
capture_output=True,
text=True,
check=True
)
return json.loads(result.stdout)
except subprocess.CalledProcessError as e:
print(f"Error fetching pod metrics for namespace {namespace}: {e}")
return {}
В данном случае мы используем гипотетический AWS. python3 kost.py --plot Namespace Costs: Namespace: default Hourly Cost: $0.04 Daily Cost: $1.00 Monthly Cost: $30.00 6-Month Cost: $180.01 Namespace: kube-system Hourly Cost: $0.07 Daily Cost: $1.77 Monthly Cost: $53.17 6-Month Cost: $319.04
И получаем график с прогнозом расходов:
Plot
Но это слишком простое решение, для реальной инфры, нужна будет мультитенантность и гарантии доставки. Если ИИ попросить очень настойчего, то он может быть расскажет вам, что нужно забрать метрики из Prometheus, но он никогда не предложит использовать kubernetes API для передачи событий в NATS. Как показано в этом примере.
Не умею работать с руководством: отстаивать границы впихуемости по порученным задачам.
Бизнес всегда будет желать напихать задач полную панамку.
Для такой панамки есть чёткий термин: бэклог. Этот бэклог всегда будет выше любых границ разумного, доброго и вечного. Одна из главных Твоих задач — чтобы он не был бессмысленным навалом хотелок, а стал приоритезированным и управляемым процессом.
Первым рубежом в обороне и систематизации задач будет оценка и группировка, — это Твоя ответственность. Важно понимать границу между оценкой (примерное представление о размере задачи) и декомпозицией (уже полноценная работа над ней). Процесс уточнения и детализации задач называют грумингом (или backlog refinement), а оценка задач проводится в рамках планирования или специальных встреч. Оценивают задачи в крокодилах, бананах, бутылках — или по классическим методам, например, покеру планирования с использованием последовательности Фибоначчи.
Зачем нужна такая грубая оценка? Чтобы бизнес мог сопоставить трудозатраты с потенциальной ценностью задачи. После этого он может применить фреймворки приоритезации, такие как MoSCoW, ICE, RICE и прочие, чтобы определить, что действительно нужно сделать в первую очередь.
Это позволяет избежать ситуации, когда разработчики бросаются на "огненные" задачи, которые в конечном счёте не приносят ценности, а реально важные вещи тонут в хаосе.
Держать бэклог в приоритезированном состоянии — это только полдела. Надо ещё понять, сколько задач команда может физически осилить. Надо понять широту размаха челюсти команды - velocity :) Для этого существует несколько способов оценки, включая оценку в человеко-часах, сторипоинтах, T-shirt sizes и другие.
Velocity — это не просто количество задач за спринт, а сумма их оценок (например, в сторипоинтах) за спринт, а совокупная способность команды выполнять задачи, включая багфиксы, тестирование, митинги и прочую обвязку. В реальности бОльшая часть времени может уходить на поддержку, рефакторинг и другие технические нужды. Поэтому рассчитывать, что 100% ресурсов пойдут на новые задачи, — полный фейл. Не попадись на эту удочку!
Как только команда поймёт своё реальное velocity, станет очевидно, что любая новая задача вытесняет другую. Кому станет очевидно? И команде, и бизнесу. И вот тут начинается меджик — бизнес перестаёт думать, что производительность команды резиновая.
Теперь можно чётко отстаивать границы впихуемости. Если бизнес диктует, что "завтра всё должно быть в 100 раз масштабируемо", CTO не кидается в бой с криками "сейчас запилим!", а чётко объясняет, какие ресурсы потребуются, какие риски возникнут и какие альтернативные варианты возможны. Главное — не просто говорить "нет", а предлагать реалистичные варианты решения проблемы.
Видишь? Мы отстроили процесс груминга, приоритезации, декомпозиции и оценки задач, взятие в работу только реального объёма бэклога спринта, и внезапно — у нас резко наладились отношения с бизнесом. Бизнес больше не ждёт чудес, команда работает без авралов, CTO перестаёт быть мальчиком на побегушках.
Важно с бизнесом говорить на его языке. Если разработчики постоянно в аврале, а менеджеры требуют новых фич, нужно донести, чем это обернётся:
Затраты на поддержку вырастут → Дороже обслуживать.
Продукт становится нестабильным → Клиенты уйдут к конкурентам.
Отток специалистов → Потери на найме и онбординге.
Поэтому CTO — это не просто технический управленец, а человек, который понимает, как встроить технический блок в коммерческую стратегию компании и поддерживать баланс между техническими возможностями и бизнес-целями.
Впихуемость — штука коварная, как чемодан без ручки: тащить тяжело, а бросить страшно. Отстаивай границы, управляй ожиданиями, приоритизируй с умом — и однажды бизнес сам предложит оставить пару задач в бэклоге "на потом".
П.С. объявляю конкурс на иллюстрацию к этому посту!
Совсем недавно мне довелось поучаствовать в роли докладчика в конференции TeamLead Conf 2024. Выступал, как технический директор компании "Спринт-Ф", а темой выбрал "Законы Мерфи в повседневной работе руководителя".
Жаль, конечно, что строгий регламент выступления не позволяет рассказать всё, что хочется поведать аудитории. Но, надеюсь, то, что успел рассказать, было кому-то интересно и полезно.
Атмосфера HighLoad++ 2024 в репортаже Мир Plat.Form
Привет, друзья! С вами Дарья Морозова, специальный корреспондент Мир Plat.Form, и я снова здесь, чтобы поделиться с вами самыми горячими новостями из мира технологий. Сегодня у нас в программе — эксклюзивный видеорепортаж с HighLoad++ 2024!
Это была масштабная конференция, на которую собралось более 3000 ИТ-разработчиков высоконагруженных систем со всей страны. И мы не могли обойти её стороной.
Из репортажа вы узнаете — чем занимались участники конференции, какие стенды компаний привлекли наше внимание, о чем были доклады экспертов Мир Plat.Form и как объяснить блондинке принцип работы интернета. =)
Самый сложный вопрос для организаторов мероприятий — где найти выступающих и интересные доклады.
В далёком 2019-м на конференции Apple WWDC показали сотню видео про новинки iOS-разработки, каждое по 40-50 минут. За 2 недели я посмотрел лишь пару. С такой скоростью на все ушла бы вечность.
Когда я рассказал коллеге суть увиденного, мне пришла идея, что можно распределить темы между всеми айосерами. Я так и сделал. За час мы проходили 3-4 темы, это было весело и легко. Мы ещё полгода проводили такие техтолки.
У нас заговорили разработчики, которые раньше стеснялись. Всё просто: тебе нужно посмотреть демонстрацию фичи и пересказать её. Это была первая ступенька к большим выступлениям многих ребят.
Атмосфера была максимально ламповой. Мы закупались бутылочками Колы и пиццей, приглушали свет, слушали доклады и обсуждали, как можем внедрить новинки в наше приложение. Те, кто не мог прийти, подключались по Зуму. Тогда это не было мейнстримом, мы ставили Mac в первом ряду, чтобы показать выступающего и слайды.
Безусловно, техтолку предшествовали анонсы в чатах, а я в личках узнавал о планах и выбирал удобное всем время. Тогда я понял, что никакие объявления не заменят личного общения.
Отвечаю на вопрос, где найти выступающих: всё просто, они среди нас. Нужен всего лишь наблюдательный организатор, который убедит вас, что вы правда интересны.
Что с нашими техтолками сейчас — читайте в статье. И делитесь, как вы сами начали выступать или как находите спикеров.
