Kurgan-Telecom Ru | Информационные технологии

Все сейчас говорят об ИИ-гонке. Или об ИИ-пузыре и о том, когда он лопнет.

GPU от NVIDIA, дата-центры на миллиарды долларов, гигантские тренировочные прогоны. OpenAI, Google, Claude, Microsoft.

Весь мир технологий наблюдает, как ИИ-гиганты выясняют, кто построит модель покрупнее.

Об Apple говорят редко. А если говорят — в основном негативно. «Apple уже проиграла ИИ-гонку». Siri — посмешище. Никаких реальных ИИ-функций. Никакого реального рывка — только сделка с Google, чтобы Gemini в итоге питал Siri. Которая, конечно, снова отложена.

И всё? Серьёзно?

Apple стала неактуальной, потому что не строит кластеры из H100 и не тренирует базовые модели? Просто компания, выпускающая хорошие ноутбуки, классные планшеты и дорогие телефоны?

Думаю, мы упускаем кое-что важное. Apple не играет в ту же игру, что все остальные. Они не вливают миллиарды в ИИ, как Meta, Google, Microsoft или Amazon. Не в том же смысле.

Пока NVIDIA строила всё больше и больше — Apple строила всё меньше и меньше. И эта разница может на самом деле значить больше, чем кто-либо осознаёт.

Привет, Habr! Меня зовут Костя Козлов, я работаю в команде анализа и валидации экспериментов A/B-платформы Ozon. В предыдущей статье коллеги рассказали, как создать высокопроизводительную платформу сплитования пользователей на группы и стенд метрик. В этой статье расскажу, как построить поверх этого инструмент, который автоматически оптимизирует бизнес-метрики продукта за счёт "умного" перебора возможных вариантов его параметров.

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

Привет, хабровчане!

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

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

Главный толчок был простой и жизненный: уже на стадии рассмотрения сервиса мы понимаем, какая нагрузка на него ляжет, поэтому мы выводили правило: «Сервис должен стабильно держать N запросов в секунду», и мы берем эту планку и начинаем работу.

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

Тикет «404 на оплате» раньше означал для меня 5 вкладок и 15-20 минут ручного расследования: Sentry, Kibana, Grafana, база, Jira. Я собрал AI-оркестратор расследования на SKILL.md, субагентах и обычных API: теперь агент за 3-5 минут приносит первый черновик отчёта. Показываю архитектуру, контракт между агентами, рабочие формулировки и границы, где AI-оркестрация реально помогает, а где начинает буксовать.

Документацию можно готовить где угодно и как угодно. Писать инструкции в многочисленных CCMS, публиковать сайты через генераторы наподобие Sphinx, применять сложные разметки вроде DITA, вести базы знаний в Confluence или вообще собирать файлы в Word. У каждого инструмента и подхода есть свои плюсы и минусы. Выбор зависит от множества факторов: сложности, требований к результату, потребителя контента, бюджета отдела, объема накопившегося легаси — да и просто моды в профессиональной среде.

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

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

С 2021 года я работаю на стыке двух отраслей - цифровой и сельского хозяйства. За это время мышление у меня заметно профдеформировалось: я все чаще смотрю на другие сферы через сельхоз-призму. Мне пришла мысль провести аналоги между ИТ и племенным животноводством. Да простят меня айтишники и племенные бычки...

Когда говорят про RAG, обычно имеют в виду довольно прямую схему: взять документы, нарезать их на фрагменты, посчитать эмбеддинги, сложить всё в векторную базу и поверх этого подключить LLM. На демо это часто работает. Иногда работает и на корпоративных данных. Но на нормативных документах такой подход очень быстро начинает сыпаться.

Мы увидели это на практике, когда строили систему для работы с нормативкой. Сначала задача выглядела стандартно: есть документы, есть вопросы пользователей, есть поиск по смыслу. Значит, нужен обычный RAG. Но довольно быстро стало ясно, что главная проблема здесь не генерация. Главная проблема в том, как представить документ так, чтобы retrieval не разрушал его структуру и смысл.

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

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

Всем привет! Меня зовут Артем Плаксин, я с рождения практически ничего не вижу.

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

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

В этой статья я хочу поделиться с вами своей историей освоения интернета.

Раньше в Sass был только @import, который создавал кучу проблем: глобальное загрязнение, конфликты имён, дублирование кода. В новых версиях (Dart Sass) @import объявлен устаревшим — вместо него пришли @use и @forward. Переход на модульную систему — это не просто замена одного слова на другое, а смена парадигмы. Теперь каждый файл — изолированный модуль со своим пространством имён.

В статье на реальных примерах показано:

как подключать переменные, миксины и функции через @use;

почему больше не работает @import 'file' и как исправить старый код;

что такое встроенные модули (math, list, map, string, color) и зачем их подключать вручную;

как гибко настраивать темы через !default и with();

чем @forward отличается от @use и как с его помощью собирать публичное API проекта;

как избежать ошибок с повторными импортами и конфигурацией.

Материал будет полезен всем, кто пишет на Sass и хочет идти в ногу с развитием инструмента.

Меня периодически спрашивают — как стать системным администратором? С чего начать изучать эти ваши линуксы?

Я честно несколько раз делал подходы, искал курсы и книги на русском языке, но всё было как-то не то.

А потом я подумал — это же про линукс. Здесь, когда какая-то утилита тебя не устраивает, ты пишешь yet another tool.

Поэтому я взял и написал книгу.

Это буквально для тех, кто делает (или собирается делать) самые первые шаги.
Начиная от "как пользоваться консолью", заканчивая базовым CI (Что? Да!).

Разумеется, она не сделает читателя системным администратором.
Но я скромно надеюсь, что она даст направление. Знаю по себе, что часто очень важно знать куда копать. Поэтому я расставил указатели как мог.

Книга в markdown, готовый pdf в релизе.
https://github.com/strannick-ru/linux-book/

Предпринимательством я занимаюсь с 2012 года. До этого работал финансовым директором, думал, что знаю, как устроены деньги, и решил попробовать своё. Открыл производство мебели на заказ: гараж двадцать квадратных метров, я один, друзья-помощники, которые подводили, работа до часу ночи, в полседьмого утра обратно.

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

Дальше шло быстро. Взял партнёра-производственника, стали делать театральные кресла для гособъектов по всей России. Выросли до 800 квадратов и 30-40 сотрудников, открыли несколько мебельных салонов в Краснодаре, начали делать серийную мебель для гостиниц. Параллельно открыл с другими партнёрами ещё два бизнеса — производство кухонных стульев и торговлю одеждой из Пакистана на маркетплейсах.

И тут узнал про маркетплейсы. Я не думал, что там вообще продаётся мебель, но решили попробовать: сделали тестовую фуру и она продалась за три дня.

Предыстория

У вас конечно же нет VPN сервера ocserv, но возможно у какого-то абсолютно незнакомого человека он есть — с десятками, а может сотней пользователей. И этот незнакомый человек наверняка знает эту боль: каждый раз при добавлении нового клиента нужно вспоминать команды, лезть в документацию, не забыть обновить CRL, правильно экспортировать .p12. Когда этот гипотетический человек в очередной раз забыл флаг --legacy в openssl и получил нечитаемый файл сертификата — он вероятно захотел бы какое-нибудь автоматизированное решение.

Я написал набор bash скриптов для этого человека, чтобы автоматизировать рутину. Скрипт изначально создавался именно под связку ocserv + easy-rsa, поэтому глубоко интегрирован с её структурой PKI. Потом я решил привести код в порядок и выложить — вдруг найдутся ещё люди, которым он пригодится.

Что такое ocservice

Я смотрел существующие решения — нашёл несколько репозиториев на GitHub, но все они заброшены 2-4 года назад и работают только с логин/пароль авторизацией через ocpasswd. Сертификаты не поддерживает никто. Есть популярный проект с веб-интерфейсом, но это совсем другая история: Docker, отдельный порт, база данных, и всё равно только логин/пароль без easy-rsa. Если вам нужно просто управлять пользователями прямо на сервере без дополнительной инфраструктуры — это избыточно.

ocservice — это набор интерактивных bash скриптов для управления ocserv прямо из командной строки. Никакого Docker, никаких веб-серверов и баз данных — только bash и стандартные инструменты которые уже есть на сервере. Главная особенность — полная интеграция с easy-rsa: создание сертификатов, экспорт в .p12, отзыв и обновление CRL всё это делается в несколько нажатий.

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

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

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

Несколько лет назад я решил купить электросамокат, чтобы ездить на работу. Я уже какое-то время пользовался прокатом самокатов, но устал от необходимости «охоты» на них или отсутствия их рядом с домом, когда мне нужно было ехать в офис.

Мой выбор остановился на Äike T. Не потому, что он оказался лучше других самокатов: на самом деле, его цена была даже выше других, и в этом ценовом сегменте рынка явно имелись скутеры с более высокими параметрами.

Однако я выбрал Äike, потому что его производили в моей стране, а мне нравится по возможности поддерживать местные компании. Äike («молния» на эстонском) был спроектирован и изготавливался в Эстонии, прямо в Таллине. Насколько я могу судить, разработчики использовали не так много стандартных компонентов. Конструкция была разработана с нуля, модуль IoT и аккумуляторные блоки тоже производили локально, и так далее. Нельзя сказать, что это однозначно лучше, ведь при этом усложняется обслуживание самоката, но сам продукт мне показался амбициозным.

Ещё одной причиной покупки стало то, что у производителя была сестринская компания Tuul («ветер» на эстонском), занимавшаяся прокатом электросамокатов. Это тоже были скутеры Äike, и из всех конкурентов мне больше всего нравились Tuul/Äike, поэтому я по возможности пользовался их прокатом.

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

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

Новую ОС, известную по утечкам как Hudson Valley Next и неофициально называемую Windows 12, разрабатывают с расчетом глубоко интегрировать искусственный интеллект. Подход меняет требования к оборудованию: многие компьютеры запустят систему, но не получат ключевых функций. Что грозит пользователям, то есть нам с вами? Давайте разбираться.

Привет! Хочу поделиться историей о том, как я пытался трудоустроиться в Яндекс в начале 2026 года. Только факты, без эмоций. От каких‑либо выводов также воздержусь.

Немного контекста. Меня зовут Дмитрий, 44 года, C++/Go разработчик, стаж почти 20 лет, в том числе в крупных международных компаниях. Разрабатывал софт для mobile, desktop, backend, инфраструктурные сервисы. Осенью 2023, имея полупассивный доход, я решил взять перерыв в карьере, с целью сосредоточиться на личных приоритетах и «перезагрузиться». В течение этого времени продолжал поддерживать свои навыки разработчика, держал руку на пульсе индустрии. В итоге, личное разгрёб, перезагрузился, полностью готов к продолжению карьеры в ИТ, ищу работу. Обо всём этом прямо написал в резюме, чтоб предвосхитить вопросы. Да, насчёт резюме, тут ссылку на него давать не буду, пост не для этого; cкажу лишь, что резюме я уделил довольно много внимания, и оно… ну, нормальное.

Итак, в декабре 2025 со мной связался HR из Яндекса с предложением пообщаться насчёт вакансий в инфраструктурные команды. В прошлом я уже несколько раз собеседовался в Яндекс, но обычно отваливался на второй технической секции. Но последнее время активно готовился к собеседованиям и практиковался на LeetCode, и решил попробовать ещё раз. С HR пообщались хорошо. Он сказал что процесс найма в Яндекс в backend сейчас полностью унифицирован, такие‑то секции. Ок, назначили первую секцию — лайвкодинг, скорее всего многопоточка.

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

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

Меня зовут Станислав Решетнев, я руковожу отделом разработки в компании Sape по направлению Link Building (инструменты для продвижения в поисковых системах). В этой статье хочу рассказать об оригинальном архитектурном решении, которое мы внедрили, чтобы пользовательский интерфейс всегда оставался актуальным.

Меня зовут Дмитрий, я руковожу отделом ИТ-инфраструктуры и сервисов в Ви.Tech, IT-дочке ВсеИнструменты.ру. Когда у компании одновременно есть свои датацентры, частное облако и несколько публичных облаков, вопрос стоимости вычислительных ресурсов быстро перестает быть бухгалтерской формальностью. Без понятной модели невозможно нормально распределять затраты, сравнивать варианты размещения и объяснять, почему одна и та же виртуальная машина в разных контурах обходится по-разному.

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

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

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

Поэтому дальше я сосредоточусь именно на частных системах виртуализации и на простом примере покажу, как посчитать стоимость 1 ядра CPU и 1 GB RAM.

Для простоты будем считать, что кластер виртуализации состоит из однотипных серверов. Допустим, в каждом сервере установлены 2 CPU по 64 ядра и 1024 GB RAM. Тогда стоимость сервера складывается из стоимости памяти, стоимости процессоров и стоимости платформы, куда входит все остальное: сетевые карты, материнская плата, корпус, блоки питания и прочие компоненты.