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

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

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

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

Скорее всего, в ближайшие 3–5 лет появятся новые интеллектуальные приложения для работы с данными, и для них понадобится новый тип современной платформы. Мы называем ее «шестая платформа данных».

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

Команда VK Cloud перевела статью об этой самой «шестой платформе данных». Это переработка подкаста Breaking Analysis с гостем Райаном Блю — одним из создателей и председателем комитета по управлению проектами Apache Iceberg. Он соучредитель и генеральный директор компании Tabular Technologies Inc., основанной создателями Iceberg и разработавшей универсальное открытое табличное хранилище, которое подключается к любому уровню вычислительных ресурсов.

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

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

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

На связи техредакция RuStore. В прошлой статье мы рассказали о миграции документации RuStore. Мы продолжаем исследовать возможности Docusaurus и знакомить вас с ними. Сегодня расскажем о способах настройки навигационного меню и о том, почему мы выбрали автоматический режим.

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

В контексте сказанного магистратура «Распределенные веб-сервисы» — совместная программа VK Education и Института прикладных компьютерных наук ИТМО — предоставляет возможность для IT-специалистов овладеть необходимыми навыками для успешной карьеры в одной из самых перспективных областей. Программе недавно исполнился год, и сегодня мы расскажем о её преимуществах и особенностях, а также поделимся опытом студентов программы.

Всем привет! Меня зовут Дмитрий, я Frontend-разработчик в VK. В этой статье расскажу немного о том, как мы знакомились с замечательной архитектурой FSD (Feature-Sliced Design), как мы рефакторили свои проекты под неё. И, самое главное, что  из этого вышло. Постараюсь заинтересовать  вас, чтобы и вы смело её внедряли в свои проекты. FSD — это, пожалуй, то, чего так не хватало в Frontend-мире.

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

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

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

Привет! В команде ВКонтакте мы переписываем рантайм движков баз данных — они становятся быстрее, надёжнее, а ещё с новым рантаймом проще писать код. Однако есть нюанс: в новом рантайме много конкурентных структур данных, в том числе нужных для работы с корутинами из С++20. Появляется интересная задача — проверять корректность этих конкурентных структур данных до выхода кода в продакшен.

Для решения этой задачи команда ВКонтакте вместе со студентами из университетов ИТМО и СПбГУ работала над научно-исследовательским проектом — верификацией конкурентных структур данных на языке C++. В этой статье подробно расскажем, как мы в рамках проекта проверяли корректность наших конкурентных структур данных и заодно исправили найденную в нашем новом рантайме ошибку.

В продуктово-исследовательском мире есть 2 проблемы:

1. Хаотично пополняющийся бэклог исследователя
2. ТТМ (Time to market) продукта, которому необходимо сократить этап discovery (поиска и анализа)

Продукт приходит с просьбой провести исследование "надо вчера, возьмите в работу, ну пожалуйста", а исследователи уже загружены “по полный скворечник” и начинается перебрасывание задач.

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

Командная работа при разработке программного обеспечения (ПО) — это не только объединение компетенций и экспертиз, но и общая ответственность за конечный продукт. К сожалению, об этом часто забывают, оставляя проверку качества и соответствие требованиям только на QA-инженеров. Это ошибочная практика, которая нередко заканчивается выкаткой в прод «сырых» продуктов с недочетами и уязвимостями.

С вами снова Алексей Петров, директор по качеству в Одноклассниках. В этой статье я расскажу, как команда может на каждом этапе разработки ПО заботиться о качестве будущего продукта, а также бороться с багами еще до их появления.

Материал подготовлен по мотивам моего доклада на CodeFest. Вы можете посмотреть его здесь.

Привет Хабр! Меня зовут Петр Уваров, я руководитель направления Bug Bounty в VK. Есть много статей, где багхантеры рассказывают о Bug Bounty и своем опыте в нем. Но в этой статье, я бы хотел проанализировать текущую ситуацию на российском рынке, сравнив ее с тем, что было раньше, и поговорить про ситуацию с багхантерами. Некоторые вещи, которые я буду говорить прозвучат как цитаты Капитана Очевидность. Другие могут быть приписаны Генералу Ясенпеню, но тем не менее, про них стоит рассказать.

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

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

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

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

Привет! Меня зовут Никита, я занимаюсь информационной безопасностью в RuStore. Сегодня расскажу о том, как мы создали свой сервис сканирования уязвимостей на базе OWASP ZAP, с какими трудностями столкнулись и какие подходы применили для их решения.

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

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

Написание автотестов — одна из наиболее эффективных практик, которая позволяет проверять работоспособность всех компонентов сервиса и своевременно обнаруживать любые сбои. Но писать много автотестов — не всегда верный подход: тестов должно быть не много, а достаточно. Иначе время и силы инженеров по тестированию и автоматизации будут тратиться напрасно. Но как понять, что автотестов достаточно, и, главное, быть уверенным, что обновление или добавление новых методов внутри проекта не создаст «неотслеживаемые бреши»? Очевидно, что для этого нужна система анализа покрытия автотестами.

Мы продолжаем серию статей об автотестах в ОК (материалы по этой теме мы можете почитать здесь, здесь и здесь). И сегодня рассказываем на примере анализа покрытия автотестами API, как с этими задачами справляется команда ОК.

Сегодня я хочу рассказать про нашу внутреннюю AppSec-разработку – платформу Security Gate. Начну с предпосылок для ее создания, подробно опишу архитектуру решения и поделюсь открытиями и маленькими неожиданностями, которые ждали нас (и могут ждать любого в рамках построения похожего инструмента).

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

Исследования российского ИТ-рынка показывают, что компании все чаще стали выбирать Managed Kubernetes отечественных провайдеров. При этом рост спроса обусловлен не только построением облачной инфраструктуры с нуля, но и необходимостью «приземления» уже существующих ИТ-ландшафтов на российских платформах. 

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