Мы никогда не читаем код как книгу — мы выбираем только конкретные интересующие места. Такие места обычно запоминаются ассоциативно, например по имени функции, строковому литералу, импорту библиотеки, комментарию и т. д. Перейти от ассоциации к файлу, а тем более к конкретной строчке кода не всегда легко. Особенно если оперируешь большим количеством проектов с активно меняющейся кодовой базой. В таких случаях выручает удобный инструмент текстового поиска.

Эффективность такого инструмента определяется как скоростью работы, так и удобством использования. В частности, кастомизация под себя позволяет разгрузить мышление и включить «мышечную память» — когда руки сами нажимают кнопки, а все внимание сосредоточено на обработке результатов поиска. Не все инструменты позволяют провести такую тонкую настройку. Меня зовут Роман Щекин, я работаю руководителем команды разработчиков в VK Cloud, и в этой статье мы с вами поищем серебряную пулю, попробуем достичь сочетания скорости и удобства в виде собранного из кросс-платформенного опенсорса поисковика.

В процессе разработки микросервисных приложений часто необходимо наладить эффективную и быструю коммуникацию между сервисами. Разработанный Google gRPC предоставляет высокопроизводительный фреймворк для организации такого взаимодействия. Однако стандартные балансировщики нагрузки в gRPC не всегда удовлетворяют специфическим требованиям, особенно когда требуется приоритизация адресов для минимизации сетевых задержек и обеспечения отказоустойчивости.

В этой статье я поделюсь опытом создания кастомного балансировщика нагрузки на Go для gRPC, который использует приоритеты адресов для выбора наилучшего соединения. Это решение позволяет гибко управлять распределением клиентских запросов между серверами с разными уровнями доступности и обеспечивает подключение к оптимальному ЦОД с минимальными задержками.

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

Меня зовут Юрий Орлов, я тимлид команды ML Platform. В этой статье я подробно разберу, что такое каталоги данных и какие они бывают, а также расскажу о нашем выборе инструмента для построения каталога под запросы аналитиков данных.

При работе с облачной инфраструктурой важна не только гибкость использования ресурсов, но и возможность автоматизировать основные рутинные процессы. При разработке своих продуктов мы в команде VK Tech стараемся следовать именно этим принципам. В нашем продукте Dev Platform в рамках одной из возможностей реализовано автоматическое управление инфраструктурными ресурсами, необходимыми для разработки программного обеспечения — например, виртуальными машинами, Kubernetes-кластерами и прочими.

Меня зовут Виктор Горячкин. Я старший разработчик Dev Platform в VK Tech. В этой статье я расскажу о разработанном нашей командой решении для автоматизации развертывания инфраструктуры.

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

Меня зовут Александр Кириллов. Я СТО в компании Evrone. В этой статье я расскажу о наших предпосылках внедрения IDP, поиске вариантов реализации и объясню, почему иногда готовые решения не подходят.

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

Меня зовут Александр Кленов. Я тимлид разработки Tarantool DB в команде Tarantool. В этой статье я расскажу, почему мы решили добавить в свой продуктовый портфель Tarantool DB и что реализовали в инструменте, а также покажу на примере словарей, почему строить свою СУБД сложно. 

«Битрикс24» — продукт, который позволяет клиентам удобно управлять бизнес-процессами и эффективно использовать доступные данные для глубокой аналитики. В последнем особенно помогает «BI Конструктор» — внутреннее решение, с помощью которого можно реализовывать даже самую сложную аналитику и прозрачно контролировать все метрики.

Меня зовут Александр Сербул. Я руководитель больших данных, высоконагруженных систем и машинного обучения «Битрикс24». В этой статье я расскажу, как мы строили «BI Конструктор»: какие требования предъявляли к решению, как решали возникающие задачи и что получили в результате.

Статья подготовлена по мотивам моего доклада на VK Cloud Conf 24. Вы можете посмотреть его здесь.

В прошлом году Tarantool исполнилось 15 лет. Он прошел долгий путь от обычного кэша до платформы управления данными с десятками разных внутренних продуктов и расширений. Такое обилие инструментов создает множество возможностей — и в этой статье мы расскажем о десяти, о которых многие забывают или попросту не знают.

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

Рассказываем об основных сложностях развития высоконагруженных ИТ-систем и способах их преодоления с помощью очередей сообщений на примере Tarantool Queue Enterprise.

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

Kubernetes — самый популярный оркестратор в России. По данным исследования VK Cloud «State of Kubernetes», K8s используют 56% компаний, работающих с оркестраторами (причем из них 53% работают с Kubernetes в облаке). Более того, спрос на работу с технологией увеличивается. Вместе с тем многие компании сталкиваются с недостатком опыта, что приводит не только к техническим сложностям, но и к неоправданным расходам.

Рассказываем, почему работа с Kubernetes может оказаться «тяжелой ношей» для бюджета компании и как этого избежать.

Распределённая блокировка — очень удобный инструмент в кластере, который помогает обеспечивать эксклюзивный доступ к некоторому общему ресурсу. Цель такой блокировки — обеспечить доступ к ресурсу лишь одному сервису или запросу в данный момент времени. Так предотвращается гонка за данными и их неконсистентность. Распределённая (или кластерная) блокировка называется так потому, что она обеспечивается несколькими узлами, и выход из строя одного из них не повлияет на приложение. В этой статье я расскажу, как реализовать этот инструмент с помощью Tarantool 3.

Apache Airflow — это один из самых популярных ETL-шедулеров. ETL-процессы — это когда мы выбираем интересующие нас данные, приводим их к агрегированному виду и сохраняем для дальнейшего использования. И это присутствует везде, где есть необходимость анализа данных. Соответственно, Airflow предназначен для того, чтобы запускать пайплайны обработки данных.

С ростом сложности ИТ-систем и задач аналитики изменяются требования и к возможностям инструментов. Для многих сценариев приоритетными становятся решения, которые могут работать как с историческими данными, так и с теми, которые обновляются в реальном времени. То есть аналитикам все чаще нужен инструмент, работающий на стыке возможностей транзакционных и аналитических (OLAP и OLTP) систем.

Меня зовут Николай Карлов. Я директор инновационных проектов в VK Tech. В этой статье я расскажу, что такое HTAP-системы, какие преимущества они предоставляют, и познакомлю с нашей колоночной СУБД Tarantool Column Store, которая реализует HTAP-обработку.

Статья подготовлена по мотивам вебинара «Анализируем данные в Real-time». Его вы можете посмотреть здесь.

Внутренние платформы разработки (Internal Development Platform, IDP), как один из артефактовпримеров реализации платформенного подхода (Platform Engineering) становятся важной точкой роста для многих компаний, занимающихся разработкой: помогают унифицировать стек, снизить не целевую нагрузку на команды, увеличить ускорить time-to-market. Поэтому многие компании начинают двигаться в сторону создания развертывания своих IDP. 

Мы продолжаем серию статей о Platform Engineering и Internal Development Platform (IDP). В первом и втором материалах цикла мы уже рассмотрели базовую теорию, познакомились с типовой архитектурой IDP и вариантами реализации. А в этой статье остановимся на обзоре Dev Platform, разрабатываемой командой VK Cloud.

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

Для многих специальностей, будь то бизнес-аналитика, Data Science или геология и геофизика, эффективная визуализация данных вошла в число принципиально важных навыков. Наглядное представление информации, понятное и эстетически привлекательное, может подтолкнуть целевую аудиторию к определенным мыслям или действиям. Хотя на Python создано несколько библиотек визуализации данных, студенты, изучающие этот язык и аналитику данных, часто начинают с Matplotlib.

Команда VK Cloud перевела руководство, как улучшить диаграммы, созданные в Matplotlib. Все показано на реальных примерах.

Меня зовут Павел Зимин. Я системный инженер в VK Cloud. Этой статьей мы начинаем серию публикаций о правильной и безопасной миграции компонентов виртуальной инфраструктуры между облаками, в которой дадим пошаговые алгоритмы и подсветим возможные нюансы.

Недавно CEO Starburst опубликовал манифест о будущем открытого озера данных. В манифесте он говорит об Icehouse, архитектуре озера данных нового поколения на базе Trino и Iceberg. Глядя на нее, многие разработчики недоумевали: «А чем она отличается от любой другой архитектуры Data Lakehouse?». Команда VK Cloud перевела статью о концепции Icehouse. Вы поймете, почему в ней нет необходимости и почему она подходит далеко не всем, кто работает с открытыми архитектурами озера данных.

Прекрасный момент: система написана, часть тестов автоматизирована, отчеты сгенерированы и даже выявлено несколько дефектов. Выдыхаем и будем думать о дальнейших планах: увеличить тестовое покрытие, добавить стабильности и что-то делать с логированием. Стоп, подождите, вы про логи? Заряжаем ELK, агенты сбора, выделяем ресурсы. Как нет ресурсов? Так, может быть, rsyslog в конце концов? И его нельзя? Звучит как тестовая задача на собеседовании, однако можно ли в такой ситуации обойтись без дополнительных инструментов, да еще и интегрировать работу с логами в систему автоматизации тестирования?

Привет Хабр! Меня зовут Татьяна Хуртина, и я программист в группе внутренней автоматизации ИБ VK. Недавно я выступала на киберфестивале PHDays c докладом про наш подход для мониторинга безопасности контейнеров. На примере опыта в inhouse-облаке Дзена я рассказала, как можно использовать open source решения, чтобы искать уязвимости в Runtime. 

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