Меня зовут Андрей Колнооченко. Я отвечаю за ядро файловой системы Яндекс Диска. Когда мы запускали сервис, то сразу ориентировались на рост и приняли решение шардировать базу метаданных о файлах. Но за 11 лет Яндекс Диск настолько вырос, что нам пришлось трижды менять подход к шардированию. В статье расскажу, с какими проблемами мы сталкивались по мере роста сервиса и как от MongoDB пришли в итоге к PostgreSQL.

Эта статья будет полезна, если вы планируете распределить нагрузку на вашу БД или вам просто интересен опыт развития БД для обработки большого числа запросов.

Привет, Хабр! Я Виктор, техлид продукта CI/CD в Samokat.tech. А это, :(){ :|:& };: fork-бомба, которая создаёт свои дочерние процессы бесконечно. Запуск такой штуки в контейнере без ограничений роняет всю ноду. Не используйте в проде! Если запустить в WSL, то винду тоже укладывает. Как же избежать запуска такой штуки на проде? Помогут квоты.

Давайте разберемся как работают квоты в Kubernetes. Там есть немало граблей. В этой статье поделюсь своим опытом по работе с квотами – расскажу, чем квоты хороши, что у них под капотом, в каких задачах используются и почему нужны даже в среде single-tenant.

Привет, Хабр! Мы системные инженеры X5 Tech — Алексей Кузнецов и Борис Мурашин. У нас за плечами больше 15 лет опыта, в том числе поддержка сервисов Rapida, CyberPlat, TeleTrade, сопровождение стека BigData и внедрение кластеров Hadoop. В этой статье мы расскажем, как выбирали систему управления конфигурациями, какими критериями руководствовались, что в итоге выбрали, с какими проблемами столкнулись и как их решали.

Рассматривать вопрос, зачем вообще нужна система управления конфигурацией, не будем. Потому что считаем, что если у вас больше одного сервера, она уже необходима. Перейдём сразу к тому, почему мы выбрали именно Ansible.

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

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

Меня зовут Татьяна Сеземина, я директор по управлению проектами Холдинга Т1.

Я вырастила команду с 40 до более чем 150 человек и не потеряла управляемости.

Сейчас расскажу, как мне удалось этого добиться.

Как хранить сложные сущности в БД? Что нужно сделать, чтобы не перезаписывать весь рекламный баннер для обновления одного лишь заголовка? Рассмотрим как минимум 5 независимых и взаимно совместимых идей для многократного снижения нагрузки на чтение и запись подобных объектов.

Меня зовут Юрий Печатнов, я уже 6 лет работаю в Яндексе и занимаюсь сервисами потоковой обработки. Это большие распределенные системы, читающие сообщения из большой распределенной очереди и создающие полезный выход. Полезным выходом могут быть сообщения в другой распределенной очереди и/или обновление состояний в БД. Поговорим о том, как их эффективно обновлять.

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

Меня зовут Михаил Марюфич. Я руководитель Data Platform в ОК, отвечаю за инфраструктуру для Big Data и машинного обучения. В этой статье я расскажу о нашем опыте переноса Hadoop с Bare Metal в облако: с чего стартовали, какие варианты рассматривали, как выстроили миграцию и с чем сталкивались в процессе.

Меня зовут Виктор Попов, я — технический владелец продукта CI/CD в Samokat.tech. Мы с командой разрабатываем там комплекс CI/CD  инструментов. Это единый продукт, который должен удовлетворить потребности продуктовых команд. Правда, не так просто разобраться, а удовлетворяет ли. Чтобы это понять, нужна коммуникация. А коммуникацию я очень люблю! А ещё всё, что связано с пользователями и построением процессов. Кажется, в этой роли я даже полезнее, чем в инженерной.

Чем раньше команда задумается о проблеме безопасности, тем лучше. В этой статье обсудим, какие проблемы ИБ есть в стандартном контейнерном приложении, поговорим о безопасности использования Docker, Kubernetes и Terraform и разберём, как можно встроить проверки в стандартный пайплайн деплоя.

Материал написан и дополнен по мотивам выступления Любови Гринкевич и Алексея Миртова из Yandex Cloud на DevOpsConf. Он будет интересен DevOps-инженерам, специалистам по безопасности, владельцам продуктов и всем, кто хочет:

Привет, Хабр! Я Федор Щудло, team lead и fullstack-разработчик. Всего я в разработке 15 лет, из них 11 в роли team lead.

Три года назад я сменил работу и занялся проектом, состояние которого можно описать кратко: ему 25 лет.

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

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

Как результат, разработка шла с большими накладными расходами (все делали долго), и с высокими рисками (выкатили и разломали прод). А команда при этом работала на износ.

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

Последние двадцать лет привели к серьезной трансформации технологического ландшафта и работы архитекторов, которые за ним должны следить. Архитекторы работают с технологиями и людьми. Компьютерные технологии за последние десятилетия значительно изменились и продолжают это делать. Люди меняются не так быстро. Однако, для работы с людьми выделяются новые роли: продакт-менеджеры, прожект-менеджеры, тимлиды. Роль и влияние архитекторов не так велико, как раньше, они становятся прерогативой больших компаний.

В статье попробуем разобраться действительно ли роль архитектора незаменима, для чего она нужна, как возникла и работает в реальном мире?

Привет, меня зовут Олег Свидченко, я — Chief Data Scientist. Работаю в ассоциации «Цифровые технологии в промышленности». Если вы недавно перешли из крупной технологической компании в нефтегазовую или только планируете этот переход, либо слышали про машинное обучение только в теории, но у вас нет практики его применения в конкретных, особенно промышленных проектах, эта статья для вас.

Когда я искал новое место работы, сперва рассматривал крупные IT-компании, но решил, что мне неинтересно допиливать 0,1% к точности поиска. А в промышленности — непаханное поле, можно внедрять интересные технологии крупными мазками и решать задачи, которые еще не исследовались. Хотя меня пугали страшилками, что будет строгий дресс-код, жесткий график, неудобный офис и скучные проекты...

За последние пару десятилетий с ростом объёма данных на рынке СУБД сложился интересный ландшафт. Появились новые СУБД, при этом старые продолжали развиваться — и сориентироваться среди них становилось всё сложнее. 

В этой статье предлагаем рассмотреть эволюцию разных СУБД и сравнить их между собой. Поможет нам в этом Олег Бондарь, директор по продукту в Yandex Cloud, который отвечает за развитие YDB — это транзакционная реляционная база данных с открытым исходным кодом. Статья написана по материалам его доклада на Saint Highload++.

Привет, Хабр! Я — Алексей Диянов, технический директор Nedra Digital. Мы — IT в нефтегазовой отрасли. Компании чуть больше трёх лет. Мы быстро выросли как в численности персонала, так и в количестве проектов, но не избежали классических проблем в виде трудностей внутренней коммуникации, регулярного тушения пожаров и принятия управленческих решений на основе субъективного мнения.

Поговорим о наблюдаемости качества разработки. Нужно ли измерять всё, что поддается измерению? И если нужно, то с чего начать, где брать исходные данные и с какими инженерными метриками работать, чтобы повысить управляемость разработки в будущем? 

Привет, Хабр! Меня зовут Дмитрий Архипов, я руководитель разработки в Сибур Диджитал. В IT 15 лет, занимаюсь цифровизацией почти 6 лет. Расскажу что это такое, какие задачи возникают в ходе цифровизации, какие бывают стратегии и способы реализации этих стратегий, а также какие проблемы из этого вытекают.

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

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

За 20 лет я успел поработать и в стартапах, и в IT-гигантах, с командами из трёх человек и из сорока. Каждая новая конфигурация требовала менять подход к управлению — то, что работало вчера, переставало работать сегодня. В этой статье поделюсь своим взглядом, как подходить к управлению командой в зависимости от её размера и этапа развития проекта.

Андрей Аксёнов нередко начинает свои доклады с такой самопрезентации: «воронежское быдло, интересуюсь информационным поиском». Правда, в Воронеже он уже давно не проживает, но информационный поиск по-прежнему в топе списка его интересов. Работает Андрей тимлидом в компании Avito и руководит юнитом инфраструктуры поиска. А ещё именно он создал поисковый движок Sphinx и не ограничился этим, а участвовал ещё во многих других проектах — работал в веб студиях, геймдеве (приложил руку к 10+ разных игр в начале 2000-х), немного помогал с движком Unigine, много выступал на IT конференциях. За эти заслуги его наградили Премией Highload++ в 2018 году. Мы расспросили его, что значит для него премия и как создать популярный и полезный open-source проект.

Кирилл Мокевнин — сооснователь школы программирования «Хекслет». В 2019 году по результатам голосования его наградили Премией Highload++ — за весомый вклад в IT-образование. Мы узнали у Кирилла, что для него значит премия и как стать узнаваемым человеком в индустрии.

В 2019 году я жил в США, там и узнал, что меня награждают. Олег Бунин пригласил на церемонию, оплатил билеты и я прилетел. Тогда история премии только начиналась, поэтому я ни о чём таком не мечтал. Но мне приятно было получить высокую оценку, ведь по сути, это был приз зрительских симпатий. Я не подавал никаких заявок и награждение стало приятной неожиданностью.

Пётр Зайцев — основатель компании Percona по разработке ПО для работы с базами данных, предприниматель в области open source, инвестор, ментор и adviser. Кроме Percona, участвует в проектах Altinity, которые занимаются технологией ClickHouse; FerretDB — альтернативой MongoDB и ряде других. Мы расспросили Петра, как дойти до такого уровня экспертизы и что мешает современным IT-бизнесменам.

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

Если у вас только один фронтенд, все еще не так плохо. Однако, когда их количество достигает 10, микроошибки в компонентах могут отнимать до 200-300 человеко-часов в год. С учетом современных зарплат, это значительная сумма. А помимо фронтенда у нас также есть бекенд, девопс и тестирование, что также требует значительных затрат. Давайте вместе разберемся, как можно справиться с этой проблемой.