IT-инфраструктура *

Будучи разработчиком PHP на протяжении почти 20 лет, я поработал в разных компаниях — и больших, и маленьких. И сейчас, подыскивая новое место работы, я попадалю на статьи множества HR-ов, внутрикомщиков, офис-менеджеров и прочих специалистов по корпоративной красоте. Они пишут про корпоративные мегаценности, важность бренда, коммуникаций, чувства принадлежности, атмосферы и всего вот этого.

Извините, но я больше не могу это терпеть.

Кто-то должен им ответить — строго и по фактам.

Наверняка многие сочтут этот текст неполиткорректным, “мускулинным”, старпёрским. Возможно это дорого мне обойдется. Но вещи надо называть своими именами. Это полезно. Как лекарство: горькое, неприятное, но именно оно и лечит болезнь.

А болезнь тут, по-моему, довольно простая:

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

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

Я провел анализ открытых источников 100 учебных заведений (вузы и колледжи) и выяснил, что 87 из них оставляют возможность такой деанонимизации. Причем данные за предыдущие годы остаются в открытом доступе, формируя устойчивый архив персональной информации.

Проблема публичного идентификатора

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

Однако СНИЛС — это не просто номер. Это ключевой идентификатор гражданина в системе межведомственного взаимодействия. В связке с фамилией и инициалами он позволяет:

HBT — production-grade CLI для управления иерархическими задачами с защитой от изменений. Идеальный инструмент для работы с LLM, автономными агентами и сложными проектами.

Всем привет! Следующие 5 минут с вами Моне Даниил, корпоративный архитектор банка Уралсиб.

Ситуация до боли знакомая: вы заполняете заявку, нажимаете «Отправить», а через минуту получаете СМС: «Банк не готов предоставить кредит». Обидно? Еще бы. Непонятно? Абсолютно.

Сегодня я приподниму завесу тайны над тем, какой путь на самом деле проходит ваша заявка. Почему решения принимаются так быстро? Кто или что решает вашу судьбу? И главное — из-за чего чаще всего сыпятся отказы? Будет жестко, но честно. Поехали.

Словарь, чтобы понимать друг друга

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

Коротко для ленивых

В MariaDB 12.3 binlog можно хранить внутри InnoDB через binlog_storage_engine=innodb.

Главный эффект: вместо двух fsync() на commit остаётся один, поэтому на write-heavy нагрузке резко растут TPS и снижается tail latency.

В тестах из статьи прирост на полном durability-профиле составил примерно 2.4x–3.3x.

Backup, restore и ресинк реплик становятся проще, потому что binlog и данные теперь консистентны на уровне одного механизма хранения.

Цена за это: обязателен GTID, Galera пока не поддерживается, а innodb_log_file_size нужно подбирать внимательнее из-за роста объёма redo.

Если у вас обычная схема primary + async replica на InnoDB, эту возможность точно стоит хотя бы протестировать.

17 марта в Российском новом университете прошёл пресс-завтрак на тему «Гражданские беспилотники: от аэрофотосъёмки до сельского хозяйства». Цель мероприятия была связана с донесением до широких масс через приглашенных журналистов мысли о том, что БПЛА, даже в современных и очень непростых условиях, это отнюдь не только военные коптеры и дроны-разведчики, а средства передвижения и перемещения полезной нагрузки с огромным потенциалом для самых разных сфер и отраслей экономики.

Ваша ML-модель работает в ноутбуке, а в продакшене — нет. Бывало такое? Именно здесь начинается настоящая инженерная задача: взять эксперимент из Jupyter-ноутбука и превратить его в воспроизводимый, наблюдаемый и масштабируемый пайплайн — от сырых данных до стабильного инференса под реальной нагрузкой. Kubernetes давно стал де-факто стандартом для этой работы: более 70% компаний используют его в продакшене — это не дань хайпу, это прагматичный выбор тех, кто уже наступал на грабли.

В этой статье разберем, почему K8s выигрывает у альтернатив именно для ML-нагрузок, а также обсудим какие мифы и анти-паттерны тормозят команды на пути к продакшену. Пройдемся по полному стеку: от подготовки кластера и фиксации данных через DVC до canary-деплоя модели и автоскейлинга GPU-подов. В конце вас ждет взгляд на то, куда движется индустрия: serverless-ML, multi-LLM-ops и edge-развертывания.

Если вы DevOps- или MLOps-инженер, которому приходится запускать обучение и инференс в одном кластере, или R&D-инженер, чьи модели «магически ломаются» при переходе в прод — читать обязательно.

Утилита Easy-RSA изначально была создана в рамках проекта OpenVPN для упрощения управления ключами и сертификатами Инфраструктуры открытого ключа, использующимися для защиты передаваемой по сети информации. Данное упрощение, несомненно, позволяет сократить затраты времени на освоение развёртывания и сопровождения службы OpenVPN.

Представленный материал по большей части является переводом краткого руководства Easy-RSA 3 с некоторыми дополнениями. Сухое и формализованное изложение не предполагает украшательства картинками.

P.S. Адептам рунглиша с острой аллергической реакцией и когнитивным диссонансом к русскоязычным терминам и сокращениям просьба не беспокоиться.

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

Мы поговорили с тремя специалистами по машинному обучению и data science (ML/DS) и попросили их рассказать о своём пути и проектах. А в конце собрали советы для тех, кто хочет начать свой путь в data science: какие навыки качать, где брать опыт и к чему готовиться на собеседованиях.

Большинство команд, которые внедрили канбан, на самом деле просто создали доску с колонками. Перетащили стикеры слева направо — и решили, что на этом все. Но канбан — это не формат доски, а метод управления потоком работы.

Мы тут решили дотошно разобраться и рассказать, из чего он состоит на практике: инструменты, принципы, WIP-лимиты и метрики. 

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

Меня зовут Сергей Емельянов. Я руководитель Core-команды VK Tech. В этой статье я пошагово покажу процесс построения синтетической платформы для обработки потоковых данных на Kubernetes.

В крупных компаниях (да и в небольших, если уже совсем откровенно) остановка работы 1С — это не просто технический сбой. Это замороженные процессы, потерянные операции и упущенная выгода. Риск остановки 1С сильно повышается, если вся инфраструктура размещается исключительно на локальных серверах, которые в любой момент могут выйти из строя или потребовать планового обслуживания. Именно с такой ситуацией столкнулся один из наших клиентов, и в этой статье мы расскажем, как создали для него полноценное резервное облако, обеспечив непрерывность работы и защиту данных.

Привет, Хабр! 

Меня зовут Алексей Кирдяшкин, я занимаюсь инфраструктурной разработкой в Timeweb Cloud.

У нас есть сервис App Platform (раньше он назывался Apps). Если коротко, это управляемая платформа поверх VDS для деплоя приложений напрямую из Git, без ручной настройки серверов и танцев с бубном. 

Я застал App Platform еще в виде MVP, участвовал в его адаптации под инфраструктуру, работал над архитектурой — по сути, провел сервис от первого прототипа до продакшена с реальной нагрузкой. Конечно, все работало — приложения деплоились, пользователи приходили, платформа росла. Но с ростом стали заметны архитектурные решения, которые были оправданы для MVP, но плохо подходили для большого сервиса. 

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

Привет, Хабр! На связи INTEKEY — системный интегратор в складской логистике. Мы разрабатываем и внедряем WMS, но парадокс нашей работы в том, что успешная автоматизация склада почти всегда начинается не с софта, а с разбора физических процессов.

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

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

Чтобы система реально поддерживала процесс, а не пыталась залатать его дыры, мы всегда используем логику: сначала аудит и выравнивание процессов, и только затем — «прошивка» правил в цифровом контуре. И здесь на первый план выходит бережливое производство (Lean).

Сразу оговоримся: внедрение бережливого производства на складе — это не разовая инициатива, не просто наведение порядка по системе 5S и не мотивационная “кайдзен-доска”. Это жесткий, измеримый подход к управлению складским потоком, нацеленный на поиск узких мест и устранение потерь.

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

Привет, Хабр! Мы – Константин Тюрин и Евгений Соколов – группа технической поддержки транспортных сетей РТК-Сервис.

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

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

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

В этой статье разберём, как устроены процессы учёта и маркировки на производстве, какие задачи решает мобильное приложение для терминалов сбора данных (ТСД) «Фабрика 15» и как оно интегрируется с 1С.

Привет! На связи команда Yandex Monium, это вторая часть серии про эффективный мониторинг. Исторически Monium был разработан командой Yandex Infrastructure как внутренняя observability‑платформа и использовался для мониторинга критических сервисов внутри Яндекса. В прошлый раз мы рассказали о том, что важно знать про мониторинг в целом, а также рассмотрели подробнее асинхронные задачи. На примере кейса с таинственным зависанием задач мы увидели, как с помощью метрик можно определить не очевидную проблему, вызванную скрытым багом. 

Но вполне возможно, что у вас всё взаимодействие происходит через очереди, а не через асинхронные задачи. Далее в этой статье:

— В первой части разберём кейсы на примере in‑memory‑очереди. Это также применимо для различных типов очередей, в том числе для Apache Kafka. 

— Во второй части перейдём к клиент‑серверному взаимодействию.

В моменте идея развертывания дома почтового сервера может показаться излишеством, ведь вполне для отправки различного рода уведомлений можно использовать Telegram или любой другой мессенджер, а для переписок со своего домена почту можно завернуть на какой-нибудь почтовый сервис, предлагающий возможность использования своего домена бесплатно, например mail.ru. Однако с учетом последних телодвижений РКН в сторону блокировки Telegram и ограничение в 5 ящиков на mail.ru (а с недавнего времени и использование сторонних почтовых клиентов только на платных тарифах), вариант использования собственного почтового сервера кажется все более интересной альтернативой.

Привет! Меня зовут Дмитрий Ивахненко из команды Автономного транспорта Яндекса. В этой статье я подробно разберу, как устроены сервисы удалённого управления автономными юнитами — роботакси, роботами‑доставщиками и грузовиками. 

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

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