С ростом сложности ИТ-систем и задач аналитики изменяются требования и к возможностям инструментов. Для многих сценариев приоритетными становятся решения, которые могут работать как с историческими данными, так и с теми, которые обновляются в реальном времени. То есть аналитикам все чаще нужен инструмент, работающий на стыке возможностей транзакционных и аналитических (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.
Миграция баз данных - это процесс переноса данных из одного хранилища в другое с минимальным или отсутствующим воздействием на работу организации. Она может быть необходима при изменении поставщика услуг, обновлении аппаратного или программного обеспечения, объединении баз данных или просто для улучшения производительности и безопасности данных. Миграция баз данных требует тщательного планирования, тестирования и выполнения, чтобы избежать потери данных, ошибок в структуре данных или проблем совместимости. Важно учитывать особенности каждой базы данных и выбрать подходящий метод миграции для сохранения целостности и безопасности информации.
Безопасность — ключевой аспект разработки веб-приложений. Но это понятие очень широкое, поэтому для его понимания нужно четко определить роль безопасности в современных веб-приложениях и то, какие аспекты она охватывает.
Для многих специальностей, будь то бизнес-аналитика, Data Science или геология и геофизика, эффективная визуализация данных вошла в число принципиально важных навыков. Наглядное представление информации, понятное и эстетически привлекательное, может подтолкнуть целевую аудиторию к определенным мыслям или действиям. Хотя на Python создано несколько библиотек визуализации данных, студенты, изучающие этот язык и аналитику данных, часто начинают с Matplotlib.
Команда VK Cloud перевела руководство, как улучшить диаграммы, созданные в Matplotlib. Все показано на реальных примерах.
Меня зовут Павел Зимин. Я системный инженер в VK Cloud. Этой статьей мы начинаем серию публикаций о правильной и безопасной миграции компонентов виртуальной инфраструктуры между облаками, в которой дадим пошаговые алгоритмы и подсветим возможные нюансы.
Работа с кросс-продуктовыми фичами — квест для стойких: отдельные команды, независимые регламенты, разные подходы и практики. Часто в таких ситуациях синхронизацию команд блокирует много факторов, что неизбежно влияет на скорость и качество разработки и на поддержку кросс-продуктовых фич.
Меня зовут Таисия Толстунова, и на примере команды обеспечения качества продуктов в VK WorkSpace я расскажу, какие трудности могут возникнуть при работе с кросс-продуктовыми фичами и как минимизировать потенциальные проблемы.
Материал подготовлен по мотивам совместного моего совместного доклада с Еленой Кореневой «Преодоление трудностей кросс-продуктового тестирования».
Разработчики, которые используют Go, сталкиваются с задачей выжать максимальную производительность из каждой строки кода. Но что делать, если оптимизировать уже нечего, а увеличивать скорость всё равно надо?
Меня зовут Никита Галушко. Я старший программист-разработчик в отделе высоконагруженных систем и оптимизации ВКонтакте. В статье поделюсь, какие хитрости помогут использовать Go на полную мощность.
Приветствую всех! На связи Михаил Емельянов, руководитель Android-направления в RuStore.
За последние два года наш проект достиг впечатляющих результатов: более 50 миллионов установок, около 40 тысяч приложений и более 10 тысяч разработчиков.
Однако быстрый рост не проходит без вызовов, включая такие проблемы, как технический долг. В этой статье я расскажу, как управлять техдолгом, не останавливая разработку новых фич.
Недавно CEO Starburst опубликовал манифест о будущем открытого озера данных. В манифесте он говорит об Icehouse, архитектуре озера данных нового поколения на базе Trino и Iceberg. Глядя на нее, многие разработчики недоумевали: «А чем она отличается от любой другой архитектуры Data Lakehouse?». Команда VK Cloud перевела статью о концепции Icehouse. Вы поймете, почему в ней нет необходимости и почему она подходит далеко не всем, кто работает с открытыми архитектурами озера данных.
