На Хабре уже выходило множество статей о том, что наш мир — это симуляция. Но, несмотря на это, прошу дать мне шанс с этой статьёй, в которой мы рассмотрим фундаментальные вещи, к которым все давно привыкли и не подвергают сомнению, хотя они толсто намекают…
А также мы рассмотрим практический вопрос: что это может значить лично для нас, если симуляционная теория верна.
Всем привет! Меня зовут Андрей, я бэкенд‑разработчик ядра Яндекс Диска. В индустрии я уже около 15 лет и повидал некоторое ПО. Последние три года занимаюсь ядром файловой системы — всем, что связано с метаданными о файлах.
Однажды мы в Диске переносили общие данные из шардированного MongoDB в шардированный же PostgreSQL. После переноса пользовательских данных у нас осталась часть данных про общие папки.Их было сложно изолировать внутри шарда пользователя, и они остались в общей БД на MongoDB, которую мы так и назвали — CommonDB. Спустя время мы заметили, что общая БД не справляется с нагрузкой: все запросы перед выполнением должны были сначала получить информацию об общих папках, и только после этого они начинали работать. Поэтому надо было дублировать информацию ближе к другим данным пользователей — на их шарды.
Однако при дублировании важно было избежать распределённых транзакций, так как они снижают общую производительность. Также проблемой был сам процесс перехода: у нас сотни миллионов пользователей, которые не должны были ощущать процесс перехода и потерять доступ к своим данным. При этом надо было выкатывать изменения не сразу на 100%, а частично, с возможностью в любой момент отключить функциональность. При выкатке также нельзя было допустить даунтайм.
В статье я хочу поделиться опытом этой масштабной миграции. Под катом покажу, как вообще устроены сложные миграции и как к ним подходить. А также перечислю те пункты, на которые нужно обратить внимание, если вам предстоит миграция под нагрузкой.
Привет, Хабр.
Красивый и интуитивно понятный интерфейс — это моя личная страсть. Я тратил дни, чтобы докрутить свои проекты до нужного мне уровня. В итоге я начал систематически собирать приёмы HTML и CSS, которые мгновенно улучшают восприятие пользователя.
Сегодня я решил показать вам несколько проверенных трюков. Выбрал самые лёгкие в освоении, чтобы вы смогли внедрить их уже сегодня, не отвлекаясь на сложности.
Давайте посмотрим, что я вам подготовил.
Всем привет! Меня зовут Никита Звонарёв, я работаю в команде Яндекс 360 и занимаюсь разработкой бэкенда Яндекс Мессенджера. В статье я расскажу о том, как устроен наш ключевой сервис Fanout, через который проходят все запросы чатов, и как наша команда шаг за шагом дорабатывала алгоритмы балансировки, чтобы выдерживать сотни тысяч RPS без сбоев и утренних страданий дежурного инженера.
Fanout можно считать сердцем Мессенджера: он отвечает за такие запросы, как «выдать историю сообщений чата», «обработать отправленные сообщения», «посчитать количество непрочитанных сообщений» и тому подобное. Fanout держит большую нагрузку — несколько десятков машин обрабатывают более 300 тысяч RPS. Сервис написан на C++, а его особенность в наличии собственной системы балансировки нагрузки. Долгое время она работала хорошо, но в какой‑то момент команда столкнулась с трудностями — расскажу о том, как мы их разруливали.
Всем привет! Меня зовут Алексей Кременьков, я старший разработчик в Яндекс Почте. В этой статье расскажу, как мы работаем с большим количеством шардов PostgreSQL: как создавали собственный сервис динамического шардирования Sharpei, как развивали инфраструктуру под него и как проходил переезд на облачное решение. В конце разберёмся, какие плюсы и минусы мы смогли найти в этом решении.
Пришло, пришло время (экспертов по опенсорсу) моей истории опенсорс-проекта. Было столько всего, что до технических деталей (почти) не дойдёт – они есть и в более древних свитках статьях.
Началось всё в 2010 году. Я только закончил аспирантуру и попал в новый для меня проект в Интеле фулл-тайм разработчиком. Мне нужно было внедрить автоматическое тестирование десктопных GUI приложений для внутреннего пользования. Опыт подобный уже был накоплен с середины 2006-го тоже в Интеле, но подходящий инструмент надо было еще найти или даже создать. Получилось что-то среднее: найти и воскресить!
КДПВ
Обычно сервер ассоциируется с чем-то дорогим и недоступным обычному человеку. Даже на вторичном рынке они пока еще стоят весьма существенно (если не рассматривать совсем уж допотопные экземпляры). Однако, есть и такие, которые можно приобрести весьма недорого.
Это так называемые блейд-серверы. Блейд-сервер (от англ. blade — лезвие) – концепция использования нескольких компактных серверов в одной общей корзине (шасси). Некоторые узлы сервера (такие как блоки питания, охлаждение, сетевые адаптеры, управление) вынесены за пределы сервера и сделаны общими для всех. Благодаря этому исключается излишнее дублирование и, соответственно, уменьшаются габариты и общее энергопотребление всей сборки. Увеличивается плотность вычислительной мощности на единицу объема серверной стойки. Из-за того, что единичный блейд-сервер бесполезен без корзины, а в корзине избыточен, они не пользуются спросом на вторичном рынке, а потому стоят весьма недорого.
Фото важных семейных событий и видео из путешествий, копии важных документов, музыка, фильмы, которых не найти на стримингах — многие задумывались, как сохранить все самое важное так, чтобы ситуация с не вовремя сломавшейся флешкой не обернулась потерей ценных данных навсегда. Кому-то для спокойствия достаточно Google Drive или Яндекс.Диска, но я решил пойти чуть дальше и построить собственное домашнее облако с приложениями Immich и Nextcloud.
Кстати, привет, Хабр! Я Денис Петухов, Python-разработчик в Cloud.ru и сегодня я расскажу, как построил облако в шкафу. По ходу дела дам практические рекомендации по архитектуре, выбору оборудования, приложений, настройке сети и даже приведу расчеты того, что выгоднее, и сколько электричества «съедает» домашняя хранилка в месяц.
Недавно я перешёл в новую команду и столкнулся с классической задачей — рефакторингом сложной продуктовой фичи. Путь от диагностики проблемы до «продажи» решения был тернист... и нереально интересен. Всеми знаниями, что из него вынес, делюсь в этой статье.
Текст будет полезен не только разработчикам продуктовых команд. Участникам core-команд расскажу про общие принципы рефакторинга, а менеджерам помогу понять, чем отличается зрелое предложение о рефакторинге от обычного «хочу всё переписать».
На сегодняшний день трансформеры правят балом хайпа в мире машинного обучения, особенно после появления ChatGPT и ему подобных языковых моделей. Это стало возможным благодаря лежащему в основе их архитектуры механизму внимания (attention), однако он же и является слабым местом с точки зрения производительности и потребления памяти. Хотя в связи с этим и была разработана изящная концепция Flash Attention (Tri Dao), её существующие реализации имеют ряд ограничений.
Поэтому представляю вашему вниманию первую и единственную open-source реализацию Flash Attention 2 на Triton с поддержкой Linux и Windows, Turing-Blackwell архитектур (теперь можно работать в Google Colab и Kaggle), гомо и гетерогенных кластеров, опциональным детерминизмом, а также возможностью ручной кастомизации ядер (kernels) для более гибкой настройки под каждую GPU архитектуру отдельно. Более подробно о том как это устроено и не только — далее в статье.
Ну и пара свежих новостей внутри для пущего реализма.
Повестка, конечно, застала всех врасплох: с одной стороны люди видят и чувствуют тенденцию, когда крупные компании второпях пытаются внедрить AI для автоматизации бизнес-процессов. Безоса можно понять — ведь если не он, то кто-то другой.
Как эта контора OpenAI появляется из ниоткуда и Google в попыхах пытается...
С момента публикации предыдущей статистики прошел год и пора опять обновить данные, провести анализ по предложениям работы в сфере системного администрирования для планирования индексаций на 2026 год.
У нас уже есть статистика за 2022, 2023 и 2024 года, будем смотреть динамику изменений с ними, пока позволяет ширина таблиц на Habr.
Цели, условия, методика и формат анализа остались без изменений, их можно прочитать в предыдущих статьях или спойлером ниже. Данные по каждой должности сравним с предыдущими периодами по количеству вакансий и по заработным платам.
Год назад на конференции VideoTech ваш покорный слуга сделал большой доклад, в том числе про прогресс современных метрик качества видео (которыми мы довольно плотно занимаемся: тык, тык, тык, тык, тык, тык, тык, тык). А на открытой дискуссии тем же вечером представитель крупного российского видеосервиса поднялся и высказал всем мнение (своего менеджера):
«Измерение качества видео — это лишняя операция. Бизнес — это вообще-то про деньги. Поэтому в бизнесе главное — это бизнес-метрики: user retention, DAU, MAU и вообще ARPU. А все эти ваши PSNR, SSIM, VMAF — от лукавого. Если пользователи платят деньги и не отписываются, значит всех всё устраивает и это главная метрика качества».
«И вообще в свое время в Toyota был внедрен подход Lean Manufacturing, где одна из «семи потерь» — это потери из-за лишних этапов обработки (waste on over-processing), к которому, очевидно, относится измерение качества. Эти материи проходят на курсах MBA, которые довольно дороги. Поэтому далеко не все российские технари в теме этих важнейших понятий и не в состоянии осознать их критическую важность для бизнеса компаний».
Мне эта позиция (изложенная выше короче и резче) очень понравилась своей прямотой и кристальной ясностью. Из этой дискуссии родились два сравнения — видеохостингов и онлайн кинотеатров, про которые и будет рассказано ниже. В том числе будет ответ на вопрос, который мне не раз задавали мои знакомые:
«Слушай, а почему у меня на даче YouTube через Роскомнадзор работает лучше Rutube без Роскомнадзор?»
(видеоверсия — доклад на VideoTech доступен тут)
Ну-с, господа, «которых всё устраивает!» Поехали!
Однажды к нам обратился клиент с проблемой: имеется 2 HDD с производительностью записи 250 MБ/с. Из них делается хранилище RAID 0. Начинаем записывать трафик, скорость — 350 MБ/с. Он успешно пишется, но через некоторое время утилизация дисков подходит к 100% и начинаются потери при записи. Вывод клиента: проблема в PT NAD, так как диски должны все успевать. Думаю, многие уже догадываются, в чем соль. У нас тоже имелись догадки, но тем не менее мы решили их проверить. Из этой проблемы и родилось небольшое исследование по записи трафика в хранилище. Под катом — наше расследование «заговора» разработчиков HDD.
Некоторое время назад администрация платформы, номинально, ведомая проникновением ИИ во все сферы нашей жизни, предложила пользователям помочь Хабру идеями. Это предложение было оформлено в виде поста со ссылкой на опрос, который выяснял: нравится ли пользователю ИИ‑контент и что делать с ИИ‑контентом на Хабре?
Данное официальное сообщение администрации, однако, находится в некотором концептуальном противоречии с заметкой «Инфляция обратной связи» продукт‑менеджера Хабра в его публичном тг‑канале:
«Когда проект становится значимым, обратная связь теряет в цене: мнение одного человека плохо масштабируется на миллионы; отклики часто противоречат друг другу. Поэтому статьи в духе «5 идей как сделать Хабр лучше» всегда хорошо обсуждают, но пользу из них извлечь сложно»
Обдумывая это противоречие, мне стало интересно, когда именно Хабр превратился из маленькой деревушки, где староста знал каждого в лицо, в Олимп, с вершины которого ропот внизу не особо различим? Так как батарейки в моём Б3‑18М сели, я взял арифмометр «Феликс», бумагу, перьевую ручку и решил выписать некоторые числа, а затем кое‑что посчитать.
Но как это часто бывает, исследование привело туда, где сам вопрос уже не вполне имеет значение :)
В Дринкит был анимированный компонент на MotionLayout — слайдер быстрой оплаты в меню. Его и сейчас можно увидеть, когда вы добавляете продукты в корзину. Проведя по нему, вы оплатите заказ, а тапнув — перейдёте к покупкам.
Так почему «был»? У компонента накопилось немало багов, а самому слайдеру понадобился новый функционал. Реализовать его на MotionLayout было сложно, так что мы решили переписать компонент на Compose.
Привет! Меня зовут Дима Максимов, я — Android-разработчик. В этой статье я расскажу, почему на Compose проще пилить масштабируемые компоненты, разобрав процесс во всех деталях, покажу код и его реализацию в интерфейсе.
Весной 2025 года Google представила Live Updates, аналог Live Activity в iOS. Мы быстро запушили продактов — «нам такое надо!» — и потащили фичу в Android-приложение Додо Пиццы.
Но всё оказалось не так просто — мы столкнулись с неполной документацией, расхождениями представлений дизайнеров Google и разработчиков этого SDK, и не только. В общем, запасайтесь попкорном. Сегодня расскажем обо всех нюансах в реализации и тестировании Live Updates.
Недавно, перебирая хлам скопившийся на пыльных антресолях, я обнаружил старенький MacBook 2,1 (A1181) образца 2008 года выпуска. Этот MacBook мне на день рождения, который состоялся более 15-ти лет назад, подарила супруга. Большим ценителем яблочной продукции я так и не стал, но некоторое время использовал эту машинку в качестве второй — для чтения почты или просмотра ютуба, брал с собой в туристические поездки. Мне нравился дизайн корпуса и клавиатуры этой машинки, местами даже где-то меня привлекала операционная система MacOS X являющаяся родственником FreeBSD. Но сейчас не об этом. В те времена вычислительная техника персонального применения стремительно устаревала — появлялись процессоры с всё большим числом ядер и большей тактовой частотой, состоялся полный переход от 32-битных архитектур к 64-х битным и т. д. Всё это сильно расслабило разработчиков и, как следствие, требования софта к железу выросли просто непомерно. Таким образом, данная машинка очень быстро «морально устарела». Я пару раз проводил апгрейд — сначала добавил немного SDRAM, потом заменил HDD на SSD, несколько раз апгрейдил MacOS X. Но к 2012 году машинка всё равно стала мало пригодной для работы и отправилась на антресоли.
Две недели назад этот MacBook попался мне на глаза. Я включил его и обнаружил, что MacOS X прекрасно загружается и даже подключается к WiFi, только вот в Safari все сертификаты давно протухли и ни один Web сайт не открывается. Но тут меня посетила совершенно здравая мысль - почему бы не оживить эту машинку установкой на неё современной ОС, такой как например FreeBSD ? К тому же появился повод — одна из моих дочерей доросла до своего компьютера, а покупать ей сейчас новый ноут для посещение «учи.ру» меня, откровенно говоря, «жаба душит». Короче, я быстренько заказал новую АКБ на известном китайском маркетплейсе и принялся изучать вопрос «как пропатчить KDE MacBook для FreeBSD».
В данной статье я расскажу о некоторых особенностях яблочных ноутбуков мало знакомых даже опытным маководам, о тонкостях установки FreeBSD, о проблеме под названием UEFI, о баге в ядре ОС FreeBSD с которым я столкнулся и помог зафиксить, о прекращении поддержки DRM-KMOD драйверов в 32-х битной ветке ОС FreeBSD и о том, как мне все же удалось портировать их для FreeBSD 14.3-RELEASE/i386. И еще о некоторых мелочах, знание о которых необходимы для того, чтобы сделать ОС FreeBSD пригодной для эксплуатации на этом стареньком MacBook-е, и чтобы Ваш кислотно-щелочной баланс всегда оставался в полном порядкеTM.
Отладка больших CMake-проектов часто превращается в боль. Уходит не один час на то, чтобы с помощью message() и бубна найти проблему. Но существуют более удобные и эффективные способы. Например, отладчик, который позволяет пошагово пройтись по CMake-скриптам и посмотреть значение переменных. Или профилировщик, показывающий последовательность вызовов и время их выполнения. Как их использовать? Читайте в статье.
Проблема ценообразования на ИТ-услуги и, в частности, вопрос об определении оптимальных ставок на работы по T&M напрямую влияет на бизнес многих ИТ-компаний. Тут есть множество интересных нюансов. Предлагаю рассмотреть их в данной статье. Возможно, это поможет осознанно выбирать лучшие варианты, когда придется принимать очередное решение на эту тему.