Привет, меня зовут Александр Виноградов и я главный ИТ архитектор Ви.Tech. Сегодня расскажу о том, как я однажды подал заявку на TeamLead Conf, а в результате стал членом программного комитета этой конференции. А еще поделюсь своим «взглядом изнутри» и научу, как сделать вашу заявку практически идеальным кандидатом на попадание в программу конференции. А поможет мне в этом мой напарник по ПК TeamLead Conf — Виталий Качановский.

Как я расстроился из-за тимлид конф 24

Началось все с того что мою заявку не взяли на московский тимлид 24. Причем ладно бы отказали —  даже никто не связался. Было неприятно, я ж старался в конце концов. Но фрустрировал я недолго. И решил, что раз в этот раз выступить не удастся, то можно и просто рядом постоять, а заодно и выяснить, как программный комитет тимлида (ПК) принимает решение, кого брать в программу, а кого нет. 

И мы сделали подкаст с Ромой Ивлиевым (главный по тимлидконф) о том, как устроен ПК, как в него попасть и сколько надо заплатить, чтобы тебя взяли (спойлер — даже не пытайтесь, не поможет). После выпуска я списался с Ромой и попросился в ПК на «разбор конюшен» — тех заявок, что старожилы себе не взяли по причинам, о которых я расскажу ниже.

Сейчас, когда отбор уже закончен, я смог наконец создать рецепт идеальной заявки для IT конференции. Поделюсь своими наработками с читателями, и, возможно, уже на следующем тимлиде окажусь куратором кого-то из вас.

Её величество Тема

Если вы никак не можете выбрать из нескольких тем ту самую единственную, то не стесняйтесь, предложите все темы, которые можете осветить. Две-три заявки от одного человека — это нормально. Главное, чтобы каждая заявка была хорошо проработана, а материалы и наработки для доклада имелись не только в формате гипотетических записей на салфетке. 

Меня зовут Дмитрий Солдатенко, я разработчик в Ви.Tech, IT-дочке ВсеИнструменты.ру. И теперь, когда формальное представление завершено, хочу поделиться своим, местами не очень формальным, батхертом по поводу слабых указателей.

Предполагается, что вы пишете на Go и хотя бы на уровне чтения релиз-ноутов знакомы с концепцией слабых указателей (weak pointers).

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

Если вы читаете эту статью, значит, меня держат в плену я всё-таки довёл её до публикации, и она не повторила судьбу многих других. Постараюсь кратко и тезисно, пока мне не стало лень писать. =)

Меня зовут Николай Кокоулин, я бэкенд-разработчик в Ви.Tech — это IT-дочка ВсеИнструменты.ру. В этой статье поделюсь нашим опытом о том, как мы в ходе разделения монолитного приложения на микросервисы столкнулись с вызовом: как сохранить производительность и масштабируемость системы при росте нагрузки.

Меня зовут Дима Синявский, я SRE-инженер в Ви.Tech — это IT-дочка ВсеИнструменты.ру

За полгода до этой статьи я рассказал вам в материале Vector.dev: как упростить подсчет метрик по логам как мы сделали удобный для нас подсчет метрик по логам.

И вот недавно мы поняли — что-то не так. Метрик иногда становилось много и появились те, которых быть не должно. Нас это удивило. Оказалось, мы себе оставили грабли в огороде, но удача нам улыбалась и мы их обходили.

Удивительно, что решение почти 2 года нас устраивало и прекрасно решало наши задачи!

Время рассказать вам о граблях: как и где ОНИ нас нашли, каким образом нам удалось от них избавиться.

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

Я – Кирилл Кузин, go-разработчик платформенной команды Ви.Tech (IT-дочка ВсеИнструменты.ру). Последние три года мы переводим высоконагруженные части нашего кода с монолита на Go-сервисы. За это время успели перенести критически важные компоненты, увеличить производительность в десятки раз и найти свой путь между монолитом и микросервисами. О нем я сегодня и расскажу.

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

В предыдущих статьях я рассказывал как мы перешли на vector.dev с Elastic для обработки логов и как мы теперь считаем метрики по логам с его помощью.

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

TL;DR:

Нам помогли наработки по Vector.dev, договоренность с разработчиками и обнаруженная OpenTelemetry Logs Data Model. В итоге это все скомпоновалось в решение которое существенно упростило нам жизнь.

Меня зовут Кирилл Шагин, я руковожу командами SRE, DevOps и DBA в компании Ви.Tech — это дочка ВИ.ру. В наших IT-решениях мы используем современный стек, у нас 4 кластера K8S и более миллиона пайплайнов в месяц.

В этой статье делюсь опытом, как мы построили свою эффективную команду DevOps и постепенно ушли от большей части услуг на аутсорсинге. Конечно, выстроить процессы получилось не за один день и не с первой попытки. На пути к целевым показателям эффективности работы мы использовали различные подходы. В итоге от каких-то отказались, а какие-то внедрили и используем по сей день. Обо всём об этом читайте под катом.

Меня зовут Дима Синявский, я SRE-инженер в Vi.Tech — это IT-дочка ВсеИнструменты.ру. В этой статье я расскажу вам о нашем опыте работы с vector.dev, как мы сначала превращали логи в метрики и как это автоматизировали до такой степени, что теперь с этим справиться один yaml-developer.

Наш сайт создает более 100 тысяч заказов каждый день, и чтобы все это успешно работало у нас много сервисов, которые пишут много логов по ним часто нужно считать метрики. А SRE часто нужны метрики и порой это надо сделать прямо сейчас, а не ждать доработки приложения. Потому метрики по логам спасают.

Если у вас в эксплуатации уже есть коммерческие функциональностью подсчета логов по метрикам, то, думаю, ваши потребности им уже закрыты. Однако, тем кто строит свои системы с применением открытого ПО - это может быть полезно.

TLDR. Да мы смогли улучшить этот процесс, упростить и автоматизировать при помощи шаблонизации конфигов, да посмотреть код можно, есть в опенсорс есть на github.

Привет, Хабр! Я Кирилл Кузин — старший разработчик компании Ви.Tech, IT-дочки маркетплейса ВсеИнструменты.ру. Мы поддерживаем 4 кластера Kubernetes, каждый из которых включает от 200 до 215 нод. Ежемесячно выполняется более 1 миллиона пайплайнов, а на наш сайт ежедневно заходят до 2 миллионов уникальных пользователей.

И в этой статье расскажу о том, как оптимизировать работу сервиса с помощью PGO (Profile-Guided Optimization) - инструмента, изучаемого нашей компанией. На примере кейса разберем, как использование этого инструмента ускоряет выполнение задач и снижает нагрузку на систему.

Что делает PGO? Как он влияет на производительность? Мы сравним результаты работы с и без него, а в конце подведем итоги, чтобы дать объективную оценку результатам.

Меня зовут Дима Синявский, я SRE-инженер в Vi.Tech — это IT-дочка ВсеИнструменты.ру. В этой статье расскажу я вам о том как мы развивались и с нами развивалась наша система логирования. Почему вам нужен Vector.dev + Clickhouse для хранения и когда это выгодно.

Когда компания была маленькой нам хватало и блокнота, чего сейчас уже не скажешь.
У нас 931 000 пайплайнов в месяц, 4 кластера Kubernetes: от 170 до 190 нод в каждом, и 200 ГБ логов ежедневно.