Записки IT специалиста

Регистрируйся на ИТ-Пикник от Т-Банка 8 августа 8 августа — время отложить ноутбуки и встретиться офлайн на ИТ-Пикнике от Т-Банка в музее-заповеднике «Коломенское». Вот сколько всего запланировано: — научпоп-лекции; — мастер-классы; — дискуссии об ИИ и больших языковых моделях; — доклады о кибербезопасности; — примеры, как данные из логов становятся решениями; — много музыки. Бери с собой друзей, супругов и детей — каждый найдет себе что-то по душе. Узнать больше #реклама 16+ it-picnic.ru О рекламодателе

Не было печали, купила баба порося Тестовую эксплуатацию ПИоТ можно охарактеризовать именно этой народной поговоркой, разве что «порося» купить заставили добровольно-принудительно. Какие-то серьезные выводы делать пока рано, но забот у поддержки явно прибавится, причем тех, которых раньше не было, а все старые проблемы Честного знака останутся. Ну и не перестает покидать ощущение, что ПИоТ – это в первую очередь за деньги, потому что маниакально проверяет свою лицензию чуть ли не в реальном времени и чуть что перестает работать, ссылаясь на ее отсутствие. При этом четкой ясности по дате 1 июля нет, но до сих пор остаются кассы, которые не готовы к ПИоТ (РР, которые бывший Штрих) и технически отозвать с 1 июля розничный токен не получится, значит и у остальных появится возможность работать по-старому. Другое дело, что с этим можно будет легко бороться административными методами. В общем, поживем увидим. А пока надо быть готовым к любому раскладу.

📢 Реализация L3 MPLS VPN на оборудовании Eltex Приглашаем вас на практический вебинар, где мы подробно разберем, как развернуть и настроить L3 MPLS VPN на отечественном железе. 📌 22 июня 2026 (понедельник) 🏙 14:00 (по МСК) 📚 Что разберем на встрече:

➖Магистральные маршрутизаторы МЕ ➖Сервисные маршрутизаторы ESR ➖Коммутаторы MES

🎙 Спикер: Алексей Листаров — инженер с многолетним опытом работы в крупном операторе связи. Сертифицированный преподаватель нашего авторизованного учебного центра Академии Eltex. 🔗 Регистрация Готовьте свои вопросы по конфигурации, будем разбираться вместе! #eltex #eltexcm #webinar #вебинар #esr #me #mes #mpls #l3vpn #vpn @eltexcm #реклама О рекламодателе

Можно вечно смотреть на горящий огонь, бегущую воду, как работают люди и как инициализируется ЛМ ЧЗ. И, твою дивизию, ведь все это уже когда-то проходили. Первые версии ЛМ ЧЗ инициализировались долго и не с первого раза. Потом проблему пофиксили и все стало хорошо. Но теперь на смену ветке 1.х пришла ветка 2.х и ее, что, писали новые пионеры? Которые были не в курсе проблем старых? В общем - готовьтесь снова развлекаться с ЛМ ЧЗ, как будто новых развлечений с ПИоТ нам мало.

Атомарность на серверах Linux. Да или нет? Обсуждая с коллегами атомарные дистрибутивы очень часто можно услышать мнение, что мол да, десктопные туда уверенно идут и скоро придут, но вот серверные… Серверные системы представляются как надежный оплот пакетной базы, где каждый админ, как тот суслик, сам себе агроном и сам себе собирает по кирпичикам нужную систему. На самом деле это давно не так, ну разве только вы админ локалхоста. В корпоративных средах давно важна унификация и поддержка. Точнее снижение затрат на последнюю. Любая собранная руками система накладывает дополнительные требования по своей поддержке и увеличивает суммарную стоимость владения. К тому же сервер сегодня – это не сервер вчера, времена, когда одна система выполняла кучу различных ролей, канули в прошлое. Сегодня ведущую роль играет виртуализация и контейнеризация. И неписанным стандартом стало правило: одна роль – одна виртуалка (контейнер). Таким образом типичный современный железный сервер будет с большой вероятностью иметь роль гипервизора. Либо еще что-то нишевое и специфическое: роутер, дисковое хранилище и т.д. со своей нишевой сборкой: OPNsense, TrueNAS и т.д. и т.п. А все остальное – виртуалки или контейнеры, скорее всего последнее. Контейнеры экономичны, производительны, удобны и не несут ничего лишнего, тогда как виртуалка – это полноценная ОС со всем «фаршем». Но так или иначе мы приходим к тому, что базовая система на физическом сервере должна обеспечить нам возможность запуска KVM, LXC, Docker. А остальное нас сильно не волнует. Точнее даже будет лучше, если вообще не будет волновать. И мы снова приходим к атомарной системе. Чем плох атомарный гипервизор? Да ничем, наоборот даже лучше, что никакие шаловливые ручки не наставят в него левых пакетов и он не «скопытится» на очередном обновлении. Тоже самое давно напрашивается в отношении OPNsense, TrueNAS и подобных, там давно никто не лазит под капот. Скажем та же RouterOS давно себе является атомарной. Мы просто загружаем новый образ системы и никого это не напрягает и не ущемляет. Если завтра атомарным станет Proxmox – кому станет от этого хуже? Да никому, кроме полутора землекопов, которые пытаются из пакетов натянуть сову на глобус, типа установки на mdadm или еще чего-нибудь разработчиками нерекомендуемого и неподдерживаемого. А так вышло обновление, прочитали отзывы, если все хорошо – обновляемся, нет – ждем следующего релиза. И нет никаких конфликтов зависимостей, левых репозиториев и установленных через make install непотребств, которые могут взять и сломать все на ровном месте. Вы всегда знаете, что у вас под капотом образ 123.45.6 и он работает именно так, как написано. Еще есть образ 123.45.7, но там есть траблы, поэтому подождем 123.46.0 где их не только исправят, но и новых «ништияков» подкинут. А как же то, что мое приложение требует… Как-как? Берем контейнер с нужным окружением и пусть дальше требует, получите и распишитесь. Работаем, радуемся, никому не мешаем. Надо обновить? Просто заменили контейнер. Проблемы? Убили контейнер, создали новый из шаблона. Это прекрасно представлено в парадигме Docker, где контейнеры отделены как от базовой системы, так и от пользовательских данных. Сломался контейнер? Убей, запусти новый. С одной стороны дико, но с другой – это время, а время деньги. Бизнес не погладит вас по головке из-за того, что вы несколько часов решали проблему и таки решили ее. Бизнес за это время потерял деньги. Поэтому схема решения проблемы запуском заведомо исправной системы имеет место быть. А если она начинает регулярно выходить из строя – то есть тестовый стенд, разбирайся, никуда не спеши. Бизнес при этом будет продолжать работать. Таким образом роль серверной ОС также сводится до фактически ограниченного набора ролей: гипервизор, роутер, хранилище и никто не мешает сделать их атомарными. И большинство админов будут только рады. Нажал – апдейт. Перезагрузился. Все. Не понравилось – откатился назад. Тоже абсолютно ни за что не опасаясь.

Для онлайн-эксперимента по похудению ищем 10 женщин. Это не про диеты. Не про изнурительные тренировки. И точно не про таблетки и жесткие ограничения. Меня зовут Наталья Игнатова. Я практический психофизиолог МГУ. Психолог с 17-летним стажем. Я не буду требовать от вас отчеты о каждом съеденном кусочке. Не заставлю жить с весами под рукой. И не стану объяснять отсутствие результата «слабой силой воли». Моя система работает иначе. По ней уже снизили вес более 20000 человек. Мой подход — это работа с мышлением, состоянием и глубинными причинами набора веса. Мы убираем внутренние блоки — и тело начинает снижать вес уже в первую неделю. Чтобы присоединиться к интенсиву пройдите по ссылке «Попробовать» в конце поста. Если на сайте кнопка «Принять участие» цветная — вы успеваете. Если стала серой — набор закрыт. Попробовать #реклама 16+ ignatova-natalya.com О рекламодателе

Скот, а не питомцы В комментариях снова задали вопрос использования десктопного железа в IT-инфраструктуре взамен брендового. Админы, особенно старой школы, обычно вздыхают и сетуя на санкции, курс доллара и отсутствие у бизнеса нужного количества денег говорят, что мол приходится из десктопным… Но на самом деле это однобокий и устаревший взгляд на проблему. Сегодня уже практически никто не гоняет продуктивную нагрузку на голом железе – это дурной тон и признак ретроградства. Сегодня на железе стоит исключительно гипервизор/оркестратор и больше ничего. Широко в ходу концепция «чистого хоста». Нагрузка в 2026 вся виртуализированна и это даже не виртуальные машины, а контейнеры, чаще всего легковесные (OCI). Но даже при использовании более тяжелых LXC или даже полноценных виртуалок такая инфраструктура прекрасно масштабируется горизонтально. Дорогое серверное железо горизонтально столь же легко не масштабируется, по вполне понятным финансовым причинам и представляет собой единую точку отказа. Выход из строя такого устройства – ситуация аварийная и крайне болезненная для бизнеса. По сути, перед нами питомец, который имеет свой характер, свои особенности, свои настройки, которого мы холим, лечим, лечим и т.д. Болезнь питомца – горе в семье. Питомцы дороги в содержании, на них не сэкономишь. Но с переходом нагрузки от монолитов к микросервисам или гибридам мы можем заменить два дорогих брендовых сервера на штук пять хороших, мощных настольных ПК и собрать на них HA-кластер. Сегодня это доступно даже самым маленьким, тот же Proxmox VE в последней версии научился динамически распределять нагрузку на ноды. И что мы получаем? А получаем не только удешевление владения, но и смену парадигмы. У нас скот, а не питомцы. Да, скот тоже нужно кормить и поить, но коту не покупают корм в пакетиках, а просто кормят сеном или силосом. И скот безлик. Вам уже тоже все равно на какие-то особенности систем, все они безлики, это типичный хост с Proxmox (условно). Там нет индивидуальных настроек, там все типовое и унифицированное. Вы можете спокойно раскатывать новые конфигурации через Ansible или Terraform. Ваша инфраструктура больше не завязана на железо и его особенности. Она перешла в декларативную форму – инфраструктура как код (IaC). Вы описываете не настройки, а конечное состояние, которое требуется получить. Сервер перестает быть сервером, теперь это просто нода, одна из многих. Нет никакого смысла наделять ее индивидуальностью, заниматься персональными настройками и т.д. и т.п. Сломалась, упала? Да и пес с ней, пусть лежит, утром разберемся, полезная нагрузка все равно уже распределилась по другим узлам и никакой спешки нет. А утром мы просто достанем со склада (или купим в ближайшем ДНС или Ситилинк) простой ПК с нужными характеристиками и заменим им выбывший. И даже настраивать его персонально не придется, нужное состояние у нас уже описано, нужно только применить. Заметьте, мы не пытаемся лечить, восстанавливать или что-то еще делать с «заболевшим», мы просто меняем его на «здоровый», разбираться будем потом. Если будем. А попробуйте провернуть такой фокус с брендовым сервером? Причем мы сейчас не придумали ничего нового, он давно применяется гигантами, в частности Google и Facebook, последние вообще стали основателями Open Compute Project (OCP) – смысл которого – это замена дорогих и закрытых систем на простые, недорогие, унифицированные. Вместе с этим меняется и отношение к проектированию инфраструктуры, с переходом к концепции Design for Failure (проектирование для отказов), мы больше не исходим из того, что наша техника надежна, наоборот, мы точно знаем, что она сломается и делаем так, чтобы мы могли спокойно заменить один кирпичик другим. Мы не собираемся никому ничего навязывать, каждый волен поступать как вздумается, но, возможно, пора оглянуться, мир меняется и вместе с ним меняются подходы. И то, что вчера было мейнстримом, сегодня уже устарело, а вчерашние смелые проекты становятся новыми нормами.

Парфюмерная вода Byredo Bal D'Afrique STYLAR: брендовая одежда, обувь и аксессуары ✅ Премиальные бренды, которые ты знаешь — без лишних наценок и напрямую от поставщиков. Работаем уже более 5 лет! ⚡ Tom Ford, EA7, Burberry, Premiata, Moncler, Chrome Hearts, Loro Piana, Prada, Brunello Cucinelli, Hugo Boss, LV, Tommy Hilfiger, D&G, Polo Ralph Lauren, Hermes и др. 🚗 Доставка с примеркой по Москве, в другие города России и СНГ — быстро, надёжно и без задержек. 💰 Скидки до -80% в нашем дисконт Telegram-канале. ❤️ Тысячи моделей в наличии, новинки каждый день — без переплат и лишней суеты! Посмотреть каталог #реклама О рекламодателе

Про желания и возможности В обсуждениях снова и снова возникают вопросы про покупку ресурсов. Поэтому уделим немного больше внимания этому вопросу. Сразу оговоримся, что все сказанное ниже будет касаться только бизнеса, т.е. деятельности направленной на извлечение прибыли и не касается личных и некоммерческих вопросов. Любые ресурсы стоят денег. Это могут быть материальные ресурсы: производительность процессора, емкость и скорость памяти, дисков и т.д. Либо нематериальные – стоимость рабочего времени специалистов. Ресурсы входят в расходную часть бизнеса и должны быть адекватны его доходам. Недостаток какого-либо ресурса также является для бизнеса убыточным или становится узким горлышком бизнес-процессов. Поэтому если какого-то ресурса не хватает, то его следует докупить. Если вам не хватает грузчиков на склад, то надо нанять дополнительных. Большие очереди в магазинах – нужно поставить вторую кассу. Если это дорого и не окупит вложенных затрат, то значит оно вам не надо. Скажем, если грузчиков не хватает только в дни прихода товара, то можно не брать сотрудников в штат, а просто нанять грузчиков по ГПХ на определенные дни. Если же ресурса вам не хватает, но вы не можете себе его позволить – то вы что-то делаете не так, а то и вовсе занимаетесь ерундой. Скорее всего вам не нужен ни этот ресурс, ни бизнес-процесс или сервис этого ресурса требующий. Проще говоря, являясь владельцем овощного ларька вы не можете позволить себе офис класса А и автомобиль представительского класса. А если вас все-таки угораздило их приобрести, то их содержание и обслуживание пробьют дыру в балансе вашего бизнеса и быстро утянут его на дно. Все это понятно, но как только мы переходим от реальной жизни в плоскость информационных систем, так вроде бы разумные люди начинают делать странные ошибки и ходить по граблям. Хотя здесь все тоже самое: нужны быстрые диски – идете и покупаете, не хватает памяти – идете и покупаете. Нет денег – значит они вам не нужны. Потому что если бы это реально было узким местом в бизнес-процессах, то деньги сразу бы нашлись. Хотите SSD корпоративного класса и брендовый сервер? Но не можете себе позволить? Значит они вам не нужны и ваши задачи прекрасно закроет обычное настольное железо. Да, всякие корпоративные плюшки – это удобно, но удобно прежде всего администратору, а не бизнесу, которому они не нужны, точнее не нужны за такие деньги. А админ? А админ, как бы это не было ему неприятно слышать – перебьется. Потому что предприятию это не даст ничего, кроме дыры в бюджете. И в целом такое требование равносильно тому, чтобы потребовать в качестве служебной машины Мерседес вместо Гранты. Одним из отличных примеров несоответствия желаний и возможностей является почтовый сервер. Очень часто можно услышать: да что-там своя почта, делов то… А дела начинаются ровно потом. Когда выясняется, что база писем в несколько терабайт на жестких дисках ощутимо тормозит при поиске, ее надо на чем-то хранить, куда-то бекапить. Но позволить купить себе быстрые SSD такого объема и построить хранилище бекапов с адекватной глубиной хранения фирма не в состоянии. Тут есть два варианта. Работать как-то так, на костылях и синей изоленте, в надежде на то, что ничего страшного не случится. Или сесть и трезво признать, что своя почта такому предприятию не нужна. И проще и дешевле будет арендовать ее в облаке. И даже если там будут сопоставимые цифры, если считать, скажем, за год. То аренда – это растянутые по времени затраты с гарантированным результатом. Свое сервер – единовременные и результат тут достаточно непредсказуем. Поэтому каждый раз, когда возникнет такая ситуация вспоминаем. Если ресурс нужен – покупаем, нет на это денег – то он нам не нужен или мы делаем что-то не так. Но можно же оптимизировать и не покупать? Можно. Но для этого придется купить время специалиста, который знает, как это сделать и получить гарантированный результат. Вы именно такой специалист? А что вы до сих пор здесь сидите? Вас ждут великие дела.

Как правильно работать с резервным копированием в облаке? 25 июня приглашаем на бесплатный вебинар от MWS Cloud Platform всех, кто работает с облаками. ⚫️Развеем мифы, разберём лучшие современные подходы и инструменты. ⚫️Обсудим интеграцию в процессы, консистентность, точечное восстановление и безопасность. Поговорим о плюсах нативных облачных инструментов. ⚫️Проведём демо в MWS Cloud Platform и ответим на ваши вопросы. Зарегистрируйтесь, чтобы не пропустить! ⏰ 25 июня в 14:00 (мск) ✅ Зарегистрироваться Реклама. ООО "МВС ОБЛАЧНЫЕ РЕШЕНИЯ". ИНН 7841468537. erid: 2W5zFH1pTJh

Не прошло и полгода… Совсем не неожиданно, а очень даже наоборот, второй ведущий почтовый Mail.ru прекратил поддержку сторонних почтовых клиентов на бесплатных тарифах. В веб-интерфейсе с почтой можно по-прежнему работать без ограничений. При этом совсем недавно на аналогичный шаг пошел Яндекс, о чем мы совсем недавно писали: https://t.me/interface31/6266 Какие варианты? Да никаких, достаем кошелек и оплачиваем. Ну или начинаем увлекательный квест под названием «сам себе почтовый хостер», что тоже не самый лучший вариант.

Если при слове «облако» вы думаете не о небе, а об инфраструктуре и сетях — вам понравится канал «Кучевые АйТи». Здесь команда компании «Облакотека» пишет о развитии облачных технологий и о том, как превратить инфраструктурный хаос в удобные виртуальные решения для бизнеса. Читайте в канале: Вы же видели новость о том, как ИИ-агент в Cursor за 9 секунд удалил основную базу и все бэкапы стартапа PocketOS. Как держать ИИ на коротком поводке? Читать в канале Не NVIDIA единой. Разбираемся на практике, что находится за пределами привычного стека и почему иногда стоит туда заглянуть. Читать в канале Если в компании очередь к DWH-команде длиннее, чем в поликлинике, то Data Mesh придумали для вас. Рассказываем, в чем суть подхода и как он применяется на практике. Читать в канале Подписаться: t.me/oblakoteka

Атомарность – будущее Linux Этот вопрос волнует многих, и пользователей и, тем более, администраторов. Давайте попробуем разобраться в чем преимущество атомарности. Атомарность дает большое преимущество – стабильную и предсказуемую среду, не зависящую от действия или бездействия пользователя. Это хорошо разработчику и это хорошо пользователю, каждый из них знает, что это просто работает, без 100500 условий… Сегодня пакетные дистрибутивы неизбежно скатываются в атомизацию (не путать с атомарностью) – страшный сон любого разработчика и администратора. Потому как обновляясь (или не обновляясь) с произвольной частотой мы получаем бесконечно большое множество самых разных сочетаний пакетов. Дополнительно ситуация усугубляется сторонними репозиториями, пакетами, установленными вручную, заморозкой и прикреплением пакетов, это мы уже промолчим про самостоятельную сборку. И что мы получаем? Правильно, неуправляемый хаос. В итоге один и тот же пакет, на одной и той же системе отлично работает у Пети, не совсем хорошо у Васи и совсем не работает у Димы. А ты пойди – разберись. Да и Пете, Васе и Диме, как пользователям, тоже от этого не легче. Они хотят просто скачать пакет и работать, становиться администраторами Linux у них нет ни времени, ни желания. Еще одна известная ложка дегтя – это наличие целого зоопарка дистрибутивов, под каждый из которых нужно собирать свой пакет. И хорошо, если это будет делать мейнтейнер и это не будет противоречить политике дистрибутива. Но попробуйте в том же Debian, где пакетная база замораживается на этапе подготовки к релизу, поддерживать пять лет тот же Telegram? Ну вот то-то же… Разработчик? А оно ему надо? Ну вот возьмем один тот же Debian, как минимум надо поддерживать три версии: stable, oldstable и oldoldstable. Такая же ситуация практически с любым дистрибутивом и даже если взять только дистрибутивы первого эшелона список уже окажется огромным. А ведь это не просто собрать пакет. Его нужно тестировать, сопровождать, устранять баги и т.д. и т.п. Не говоря уже о том, что возможности у дистрибутивов разные и если в последних версиях есть какая-то библиотека, предоставляющая новые функции, то в старых ее может не быть, со всеми вытекающими. Чтобы избежать этих сложностей придумали универсальные пакеты: Flatpak, Snap, AppImage. По сути, это ничто иное, как контейнеризация приложений, позволяющая обеспечить единую среду выполнения вне зависимости от версии и типа ОС. А если мы отвязали пользовательские приложение от системы, то кто нам мешает отвязать систему от пользователя? Тем более что мобильные платформы все это давно реализовали и обкатали. Собираем атомарный, неизменяемый образ и поставляем его пользователю как есть, обновления поставляем в виде нового, неизменяемого образа, у которого есть только одно, строго определенное состояние, которое заранее известно. В результате получаем небольшой набор возможных состояний, что сильно облегчает разработку и сопровождение. Пользователю тоже хорошо, он знает, что если приложение А заработало у Пети, то будет работать и у него. А для возможных багов есть общие универсальные решения. Без оглядки на то, что если у вас Debian, то… а если Fedora – тогда… А как быть с патчами? Вот нашли уязвимость в библиотеке, пересобирать образ? Вовсе нет, уже давно есть утилита systemd-sysext, которая позволяет устанавливать расширения атомарных образов, накладывая их сверху на иерархию файловой системы через OverlayFS. Таким образом будущее настольного Linux видится именно в атомарности, нравится нам это или нет. А что думаете вы?

Чек-лист для банков и ТЭК: Запуск корпоративного ИИ Данные не покинут периметр, а первые ИИ-агенты заработают за 14 дней. В практическом руководстве разобрали, почему облака не подходят регулируемым отраслям, и сравнили 3 пути: самостоятельная сборка, ПАК или облако. Вы узнаете: как гарантировать суверенность и пройти проверки регуляторов, скрытые затраты облачных сервисов, точный расчёт TCO на 3 года и реальные кейсы банков и ТЭК. Внутри: матрица решений, чек-лист готовности и Excel-калькулятор. Скачайте руководство и запустите ИИ без CAPEX и санкционных рисков. Скачать #реклама 16+ t1-ai.ru О рекламодателе

Пакетный ад сложных проектов с зависимостями Многие администраторы критически относятся к современным нововведениям, наподобие контейнеризации и часто вздыхают: мол старый-добрый APT. Но жизнь всегда расставляет все на свои места. Пакетная система вполне себе стройна, хороша и удобна пока вы не пытаетесь выйти за ее рамки, точнее за рамки базовой системы, которая поддерживается на уровне дистрибутива и является более-менее стабильной и неизменной. Но как только вы втягивались в какой-то проект со сложными зависимостями, то пакетная система быстро превращалась в пакетный ад. Чтобы не быть голословными расскажем реальную историю с нашим старым сайтом, который более 16 лет просуществовал на движке Movable Type. Хотя это будет характерно для любого сложного приложения, которое живет отдельно от пакетной базы дистрибутива. Movable Type – сложный движок, в своей работе он использует Perl и большое количество модулей, часть из которых ставится из пакетной базы дистрибутива, часть из CPAN. Единого рецепта нет, разработчики положили в комплект скрипт, который говорит, чего не хватает, а дальше ты сам. Причем далеко не факт, что библиотека прицепится с первого раза и не придется подбирать версии. В итоге уже сам процесс установки растягивается на полдня и обязательную фиксацию в блокноте чего ты именно там понаставил. Потом приходит черед PHP, на котором построена другая половина движка и начинаются все те же самые танцы с библиотеками, хотя тут уже немного попроще. Но все равно особенности были. Потом еще недельку ловим ошибки сборки сайта, читаем логи и добираем недостающее, потому как скрипт проверял только базовые библиотеки, а установленные темы или плагины могли иметь «свое понимание о прекрасном». Настроили, записали, забыли? Как бы не так. Теперь нам надо это все сопровождать и обновлять. Что представляет собой отдельное развлечение, с цыганами, балалайками и медведями. Обновили движок – он хочет новые версии библиотек, которых или нет в пакетах или там не те версии или начинаются конфликты, и вы снова старательно подбираете «рецептуру» для новой версии. Надо обновить хостовую ОС? Эта песня хороша, начинай сначала. Снова берем скрипт и начинаем собирать «солянку сборную, мясную». А дальше выясняется, что такого пакета в дистрибутиве больше нет и хорошо если мы найдем другой пакет, который предоставит нам эту или совместимую библиотеку и, если она с нашим движком заработает. Не нашли, попробуем притащить из CPAN и попутно сломаем то, что работало. И снова будем искать, выдумывать, пробовать. В итоге хост через некоторое время превращается в помойку, которую трогать страшно. И даже имея на руках все нужные списки пакетов и «заклинания» поднять это все на чистой системе было задачей со звездочкой. Потому что либо чего-то не хватало, либо что-то не работало, либо работало – но не так. И понять, что именно это было и какой пакет, который «исторически» кочевал в старой системе CPAN и отвечал за нужный эффект было крайне сложно. А настоящее развлечение началось, когда движок сменил владельца и те резко поменяли лицензионную политику, оставив версию с открытым исходным кодом без обновлений. А остаться сегодня без обновлений – это гарантированно оказаться взломанным, причем уже не «если», а «когда». При том, что уязвимости бывают разные и взломать через них можно не только сам сайт, но систему целиком. В этом случае только долго и старательно латать, искать, вычищать – и все это руками. В результате сайт последний год-полтора существовал в режиме «только чтение», потому что иначе сразу становился проходным двором для всех желающих. Кроме того, отсутствие обновлений движка сделало невозможным обновление хостовой ОС, так как движок банально не поддерживал новые версии. После чего, в очередной раз вынырнув из этой мешанины начинал с тоской и нежностью смотреть в сторону Docker.

Открываете Grafana и видите 50 дашбордов «из коробки», но не понимаете ни один. Копируете PromQL со Stack Overflow, потому что писать с нуля долго и непонятно. 200 алертов в день, критичных — три, и их не видно в общем шуме. Не нужно учить всё это месяцами, пройдём полный путь за час. 23 июня в 12:00 — вебинар Deckhouse Академии. 60 минут, один живой сюжет, ноль воды.

Что покажем в эфире: – как формируется metric и почему «удобный» label вроде user_id может взорвать кардинальность и заполнить всё хранилище; – Prom++ против ванильного Prometheus: экономия памяти от ~10x и причины этой экономии (реестр ПО № 28605); – модуль monitoring-custom в DKP или как начать собирать метрики без правок scrape_config; – базовую агрегацию метрики; – Alert Rule с for и keep_firing_for: как сделать «нешумный» алерт; – как настроить отправку уведомлений и получить алерт.

Регистрация

Почему пакетная система Linux скорее всего доживает последние дни Пакетная система Linux кажется чем-то классическим и незыблемым, тем, на чем держится вся система и отказ от нее видится многим каким-то кощунством. Но если разобраться трезво, то скорее всего мы увидим планомерный уход от этой схемы. Первый звоночек прозвучал со стороны настольных дистрибутивов, где сначала начали массово применять универсальные приложения Flatpak и Snap, а в последнее время вовсю рассматривается концепция атомарного дистрибутива. Атомарный дистрибутив не делится на пакеты и поставляется в виде готового образа, обновляется тоже весь целиком, монтируется только на чтение, чем обеспечивает пользователю, разработчику или администратору стабильную и предсказуемую среду. Все знают: лучший способ сломать систему – наставить в нее левых пакетов. И такой зоопарк – настоящий ад для разработчика и администратора, потому что здесь работает, а здесь не работает. А все потому, что тут стоит библиотека А, а тут конфликтующая с ней библиотека Б, которая тем не менее предоставляет все функции библиотеки А. Сторонние репозитории – это вообще туши свет, никому неизвестно что именно там содержится и насколько оно стабильно и безопасно. Да, есть проверенные авторы и репозитории, но никто не гарантирует, что они не сломают систему и что завтра кто-то вообще будет их сопровождать. Вот тут мы подходим к самому важному и уязвимому месту системы – сопровождающим пакетов (maintainer) - это те люди, которые собирают и поддерживают пакеты для вашего дистрибутива. В любом современном дистрибутиве пакетная база чаще всего делится на две части: поддерживаемая дистрибутивом и поддерживая сообществом. В первом случае вы еще можете с большой вероятностью рассчитывать, что пакет продолжит поддерживаться, во втором все зависит от сопровождающего. Если он устал и забил – вы останетесь без пакета или его обновлений. И такое случалось не раз и не два, из того же Debain пропадал пакет phpMyAdmin, пропадал ряд других популярных утилит, а потом появлялся, так как нашелся новый сопровождающий или текущий вышел из спячки. Отдельная проблема – это конфликты зависимостей. Дистрибутивы с длительной поддержкой работают по принципу заморозки мажорных версий пакетной базы. А разработчик приложения начинает использовать новую версию библиотеки, которой в дистрибутиве не было, нет и быть не может. Для наиболее важных пакетов дистрибутивы используют бекпортирование – пересборку новых пакетов для текущего дистрибутива и размещение их в отдельном репозитории, но никто не гарантирует вам, что они не сломают именно вашу систему. А для менее важных пакетов вы можете просто никогда не дождаться их в официальном репозитории на текущей версии системы. И никаких здоровых альтернатив такая система не предусматривает: вы или качаете нужный пакет со стороны, либо собираете его сами, либо подключаете сторонний репо. В первых случаях вы берете на себя обязанности по сопровождению пакета в вашей системе, в последней – зависите от совершенно неизвестного вам источника. В то же время современный сервер – это скорее всего гипервизор или движок контейнеризации и не предусматривает запуск полезной нагрузки непосредственно на сервере. Из этого вытекает концепция «чистого хоста», на котором только движок виртуализации/контейнеризации плюс пара-тройка служебных утилит, остальное в изолированных средах. При этом данные среды давно стандартизированы – OCI (Open Container Initiative) – это не только про Docker, это про универсальный формат контейнера, который вы можете запустить где угодно- хоть на докере, хоть на кубере, хоть в подмане или вообще на микроте. И очень многие производители ПО переходят от бинарных пакетов именно к OCI (тот же SeaFile или Wiki.js), многие вообще не подразумевают других путей распространения. А дальше просто напрашивается атомарная серверная система, которая у всех одинакова, стабильна и не предполагает вмешательства в базовый образ конечного пользователя.

Привет! hh team сделали тут на днях бота с простым тестовым заданием, но не успели оттестировать, потому что Олег ушёл в отпуск. Олег, вернись, мы всё простим. Потестируйте, в общем, пжлст, по кнопке под постом ⚡ Задачка на три минуты — если справитесь, велкам в розыгрыш призов. 5 победителей: каждому подарим футболку, шопер и брелок. Итоги 30 июня в 12:00 мск, выберем рандомом. Погнали? 🚗 Начать #реклама 16+ О рекламодателе

Не было печали – апдейтов накачали В самом разгаре история с крупнейшей компрометацией пользовательского репозитория AUR в Arch Linux, на настоящий момент известно о компрометации 1577 пакетов. Принцип атаки прост – злоумышленники взяли на себя сопровождение пакетов, оставшихся без сопровождающих, после чего быстро выпустили обновление, в котором пакетам добавили зависимости на вредоносное ПО. Вредоносное ПО регистрировалось в системе как systemd-сервис с произвольным именем и выглядело как поток ядра, а дальше буквально пылесосило систему и отправляла на сервера злоумышленников все, до чего могла дотянуться: SSH-ключи, учетные данные, секреты из конфигурационных файлов, токенов доступа, историю команд и т.д. Эта ситуация снова подсвечивает критичность проблемы доверия и атак на цепочки поставки. Особенно если вы используете ПО от «сообщества» и до конца не понимаете, кто его сопровождает и на каких условиях.

Компании переходят к новой норме: продукты нужно выпускать быстрее, без роста команд и затрат. Скорость разработки становится ключевым фактором конкуренции. Приглашаем на вебинар, где создадим с нуля и запустим в корпоративной инфраструктуре приложение. А пока машины работают, обсудим: 💡что такое автономные фабрики ПО; 💡какой эффект даёт использовании ИИ в разработке уже сейчас - разберем на живых примерах; 💡коробочные решения, low-code / no-code платформы или внутренний платформы разработки (IDP), интегрированные с ИИ-агентами - какую стратегию автоматизации бизнеса выбрать в 2026 году; 💡какие вызовы стоят на пути внедрения полностью автономных фабрик ПО. 📅 25.06.2026 в 11:00 👉 Зарегистрироваться на вебинар