Разница между «всё встало» и «починили до того, как кто-то заметил» — чаще всего один регламентный осмотр. Ниже — наши истории, где регламент и живой мониторинг не просто спасают технику, а дарят инженерам комфортный запас времени: успеть спаять H-мост вместо умершего контроллера или заранее поставить резервную колонку, пока старая тонет в компаунде.
Привет, меня зовут Айдар, я транспортный дизайнер в Атоме: работаю над обликом электромобиля и его интерьером на стыке искусства, маркетинга и технологий. Хочу рассказать о том, как я к этому пришел.
Я родился и вырос в Уфе и в 18 лет поехал в Италию, чтобы поступить в Европейский Институт Дизайна в Турине.
Почему именно туда? Ответ таков: Турин – буквально колыбель автомобильного дизайна, да и вообще автомобилестроения. В начале 20 века там было около 100 мелких автомобильных брендов.
Привет, Хабр! Меня зовут Егор Карамышев, в YADRO я разрабатываю ПО для коммутаторов семейства KORNFELD. В статье расскажу о реализованной нами С++ обертке для управления сетевой подсистемой Linux на основе протокола Netlink и библиотеки libnl3. В некоторых случаях она позволила на порядок ускорить работу функций конфигурирования. Разберемся, почему мы решили отказаться от подхода с системными вызовами, а также посмотрим на результаты временных тестов.
Всем привет, меня зовут Володя. Я работаю в Yandex Infrastructure и занимаюсь развитием систем балансировки нагрузки. В статье расскажу, как развивалась наша новая система управления конфигураций с момента её создания в 2018 году, а ещё о том, как мы переходили на новый Data Plane балансировки и какие новые интересные вызовы это породило с точки зрения массовости задач и управления ресурсами.
Опишу новые проблемы и особенности, в том числе планирование ресурсов для большого динамичного парка клиентов. Также обсудим, какие бывают долговременные негативные последствия у слишком удобных систем балансировки нагрузки и что мы планируем с этим делать.
Статья представляет техническое сравнение StarRocks и ClickHouse для real‑time аналитики. На идентичных AWS‑кластерах с набором ~1 ТБ (Parquet, >3 млрд строк) смоделированы параллельные нагрузки (k6) и непрерывный поток UPSERT из PostgreSQL через CDC. Оцениваются субсекундная Latency, согласованность обновлений, полнофункциональные JOIN и операционная простота (TCO). ClickHouse с Replacing/CollapsingMergeTree обеспечивает eventual consistency и нередко требует FINAL/внешних потоковых компонентов. StarRocks с Primary Key Model дает нативный UPSERT с мгновенной видимостью изменений и асинхронным Compaction. В бенчмарках StarRocks показал до ~40% преимущество в длинных запросах, лучший p99/QPS и стабильность (без HTTP 5xx). В контексте Lakehouse StarRocks сильнее за счет внешних таблиц и записи в Apache Iceberg. Рекомендации: ClickHouse — для append‑only сценариев; StarRocks — для real‑time аналитики с частыми обновлениями.
Вот уже который год я потихоньку разрабатываю SQL-ный движок на основе Apache Spark, специализированный под задачи ETL. И хотя диалект языка изначально называется «Transform Definition Language», писать трансформации данных непосредственно на нём самом было до сих пор невозможно. Вместо этого на фазе Transform предполагалось использовать подключаемые модули, которые рантайм интерпретатора предоставляет из Java classpath.
Это очень эффективный с точки зрения производительности, но довольно долгий с точки зрения внедрения, и дорогой в разработке способ. Сначала трансформацию надо описать формально в виде статьи-whitepaper'а (это делает data scientist), потом написать прототип на Python (ответственность data analyst), отладиться на сэмпле реальных данных (тоже аналитик), и тогда уже делать и оптимизировать финальную имплементацию на Java с использованием низкоуровневого API Spark (собственно, задача разработчика). Неудобно.
Нельзя ли его как-нибудь сократить? Например, дать аналитикам инструмент для написания трансформаций непосредственно в самом SQL, вынеся некоторую часть функциональности MapReduce как разновидность итерирующих функций? Можно, конечно!
Всем привет!
Меня зовут Александр Борисов, я главный эксперт по технологиям в СберТехе. В статье расскажу про свой алгоритм, который позволил повысить скорость Unicode в PostgreSQL 18. На эту тему уже выпущен патч Optimization for lower(), upper(), casefold() functions, принятый сообществом PostgreSQL.
Статья будет интересна разработчикам, которые работают с большими объёмами текстовых данных, а также всем, кто следит за развитием PostgreSQL и интересуется оптимизацией.
Начнём с краткого обзора: что же удалось ускорить в PostgreSQL?
Рубрика «Кем работать в IT» — интервью с представителями IT-профессий, в которых специалисты рассказывают о тонкостях своей работы: плюсах, минусах, подводных камнях и заработной плате. Мы надеемся, что джунам и стажёрам она поможет больше узнать о том, что их ожидает на карьерном пути, а профессионалам — посмотреть на свою специальность через чужой опыт и, может быть, открыть для себя что-то новое.
Сегодня о своём опыте работы нам рассказала Виктория Пак, Network Engineer in Test в компании YADRO.
Космос, как неизведанное безграничное пространство, полное новых возможностей, тайн и опасностей манит нас с незапамятных времен, когда еще наш дальний предок, отбросив плавники, стал выбираться на сушу. Впоследствии человек мечтал подняться в небо, летать как птица, вернуться в океан и все это осуществилось. И останавливаться мы не планируем. Ведь за куполом небосвода скрывается поистине необъятное пространство - Космос.
Человечество мечтает. Принято считать, что мечтать полезно, таким образом прокладывается тропинка к реальным успехам. От фабрики грез мы получаем потоки образов, как наше космическое будущее будет устроено. Это несомненно развлекает, но остается ли полезным ? И что несомненно вредно, так это галлюцинировать об освоении космоса, выдавая желаемое за действительное. Я решил не предвзято взглянуть на перспективы человека в космосе.
Всем привет!
Работая Senior Java Developer в одном из банков, я успел пройти уйму собеседований, столкнуться с десятками каверзных вопросов и понять, сколько усилий требует подготовка. И каждый раз убеждаюсь в одном: тема JVM, память и GC — одна из самых недооценённых и одновременно самых частых на Java-собесах. Многие знают об этом “что-то где-то слышал”, но как только разговор заходит про Heap, Metaspace, JIT, Safepoint или разные типы GC — начинаются проблемы.
Поэтому эта статья — вторая часть моей шпаргалки по подготовке к Java-собеседованиям. Здесь я собрал всё самое важное о работе JVM и управлении памятью простым, человеческим языком, без боли и академической зауми. Разберём архитектуру JVM, устройство памяти, JIT, GC, типы ссылок и самые частые вопросы, которые любят спрашивать на интервью.
В профиле уже есть первая часть для подготовки — Многопоточность без боли.
Не все корпоративные базы знаний помогают решать вопросы. Некоторые только создают больше проблем. На своем опыте рассказываю о том, как мы справлялись с одной из них.
Недавно меня попросили мои студенты сделать для них какой-нибудь гайд по самым популярным нодам в n8n, чтобы быстро погрузить в их разнообразие.
Чтобы моя подборка была действительно из самых часто используемых n8n нод - я спарсил большую коллекцию из 3000 workflows. Разбил ее на ноды. Удалил ноды, которые редко используются в СНГ. Добавил к каждой ноде короткое описание и примеры использования, в итоге получился cheat sheet гайд на почти 40 n8n нод в виде pdf - забирайте pdf по ссылка с гугл драйва!
Пока традиционные банки экспериментировали, рынок стейблкоинов вырос до $301 миллиарда в октябре 2025 года, обрабатывая $3.1 триллиона в среднесуточных транзакциях. Это не просто цифры — это симптом market failure традиционной системы. Circle (USDC) и Tether (USDT) контролируют 90% рынка, предоставляя то, что банки не могли: мгновенные трансграничные расчеты 24/7 с минимальными издержками .
В этой статье я размышляю о том, как события одной недели изменили мое понимание будущего финансов, разбираю технические детали каждого анонса, анализирую регуляторный контекст на базе исследований IMF, BIS и IOSCO, и делюсь стратегическими выводами для нашего стартапа по токенизации активов
Из первых уст рассказываю как переход на Temporal обеспечил надежную доставку клиентских услуг в контексте обычного хостинга.
Представьте: вы гуляете по ночному парку с прекрасной девушкой после романтического вечера в ресторане. Тут перед вами открывается полянка, а над ней — летнее небо, полное звезд. Вы невзначай говорите: “о, смотри, сейчас Плеяды особенно яркие”! Показываете на небо, девушка прижимается к вам поближе, чтобы разглядеть, куда же вы показываете, и…Ну дальше все в ваших руках. А вот не знали бы, где Плеяды — и все, так и пошли бы грустно по домам. В этом посте расскажу, как научиться различать созвездия, что можно наблюдать невооруженным взглядом, как выбрать первые девайсы и всякое такое.
Для тех, кто хочет подходить к вопросу подготовленным, порекомендую свой текст про небесную сферу: в нем мы рассказываем, как устроены небесные координаты, как пользоваться картами звездного, какие бывают телескопы и всякое прочее полезное. Материал рассчитан на школьников и учителей, так что там все очень доступно :)
В этом же посте пройдемся по самой-самой базе, чтобы гарантированно впечатлять друзей и кайфануть самому.
Предположим, вы пишете многопоточное приложение для Linux, которое рассчитано на длительную работу. Может — это СУБД или какой-нибудь сервер. Представим ещё, что ваша программа не рассчитана на какую-нибудь среду выполнения кода (скажем — на JVM, Go или BEAM), которая берёт на себя управление низкоуровневыми вещами. Вы сами управляете порождением потоков (thread), прибегая к системному вызову clone. Когда пишут на C — потоки создают с помощью pthread_create, а в C++ применяется std::thread. (1)
Еще 3-5 лет назад у многих было полное ощущение, что облака победили. Казалось, что теперь только тарифы, all-in cloud и все такое. Но нет. В какой-то момент некоторые компании вновь начали думать о том, чтобы не выгружать все в облако, а держать у себя под боком и даже возвращать их облака на землю. В результате сложилось два противоположных лагеря, где одни вкладывают миллиарды в строительство ЦОД, а другие продолжают арендовать ресурсы и не парятся. Разница в подходах, понятное дело, не случайна.
Сравнил Пушкина и Ершова с помощью Python и пытался найти автора "КОнька-горбунка" среди цифр и кода.
Какие практики бывают в разработке и эксплуатации, и как их внедрять? И как масштабировать практики и оценивать их с помощью метрик? Какие сложности можно встретить на пути?
Привет, Хабр! Меня зовут Евгений Харченко. Моя роль в Райффайзен Банке — руководитель отдела по развитию практик в разработке и эксплуатации. А еще уже пять лет я — Senior Community Lead DevOps, хотя начинал с роли инженера тех. поддержки ServiceDesk. Еще я — член программного комитета DevOpsConf.
В этой статье по мотивам моего доклада для конференции Highload++ будет много примеров, историй и ретроспективы того, как мы в компании развивали технические практики и инженерную культуру.
Установка и эксплуатация приложений Spark в облаке зачастую становятся препятствием для дата-инженеров (Data Engineer, DE): сложная работа с Helm-конфигурациями отвлекает внимание от анализа данных и замедляет подготовку среды. Но полностью отказываться от Spark зачастую нерационально, поэтому многие команды стремятся найти свое решение для обхода существующих сложностей.
Привет, Хабр. Меня зовут Юрий Орлов. Я руководитель команды разработки ML Platform в VK Tech. В этой статье я расскажу о том, как мы автоматизировали развертывание Spark в облаке и создали клиент на Python, который снижает требования к знаниям в области DevOps и Kubernetes, необходимым для начала работы со Spark.
