Разработка

Zhipu AI выпустила GLM-4.6 с контекстом 200K токенов и производительностью уровня Claude Sonnet 4

Китайская компания Zhipu AI (Z.ai) представила GLM-4.6 — обновленную версию флагманской модели с расширенным контекстом до 200K токенов и улучшенными способностями в программировании, рассуждениях и агентских задачах. Модель показывает паритет с Claude Sonnet 4 при снижении потребления токенов на 15%.

Технические улучшения

GLM-4.6 построена на архитектуре предшественника GLM-4.5 с существенными оптимизациями обработки длинного контекста и генерации кода. Модель тестировалась на восьми публичных бенчмарках, покрывающих агентов, рассуждения и программирование.

Ключевые характеристики:

• Контекст расширен со 128K до 200K токенов

• Улучшенная генерация фронтенд-кода

• Многошаговые рассуждения с использованием инструментов

• Интеграция в поисковые и инструментальные фреймворки

• Снижение потребления токенов на 15% относительно GLM-4.5

Результаты бенчмарков

На LiveCodeBench v6 модель набрала 82.8 балла против 63.3 у GLM-4.5 — существенный прирост. Claude Sonnet 4 лидирует с 84.5, но разрыв минимальный. На SWE-bench Verified GLM-4.6 показала 68.0 против 64.2 у предшественника.

Производительность в бенчмарках:

• LiveCodeBench v6: 82.8 (GLM-4.5: 63.3, Claude Sonnet 4: 84.5)

• SWE-bench Verified: 68.0 (GLM-4.5: 64.2)

• CC-Bench: 48.6% win rate против Claude Sonnet 4

• Снижение токенов: 15% относительно GLM-4.5

Компания расширила CC-Bench более сложными задачами, где человеческие оценщики работали с моделями в изолированных Docker-контейнерах, выполняя многошаговые реальные задачи от фронтенд-разработки до анализа данных.

Практическое применение

GLM-4.6 интегрирована в популярные агенты кодирования: Claude Code, Kilo Code, Roo Code, Cline. Модель доступна через Z.ai API platform и OpenRouter для разработчиков.

Для программирования:

• Генерация фронтенд-компонентов с логичной структурой

• Создание инструментов и автоматизация

• Анализ данных и тестирование

• Алгоритмические задачи

Ценообразование и доступность

GLM Coding Plan предлагает производительность уровня Claude по цене в 7 раз ниже с троекратной квотой использования. Модель доступна через веб-интерфейс chat.z.ai и API.

Варианты доступа:

• Веб-интерфейс Z.ai с выбором модели GLM-4.6

• API через Z.ai platform и OpenRouter

• Локальное развертывание через vLLM и SGLang

• Веса модели на HuggingFace и ModelScope

Сравнение с конкурентами

GLM-4.6 показывает конкурентоспособность с DeepSeek-V3.2-Exp и Claude Sonnet 4, но отстает от Claude Sonnet 4.5 в программировании. Модель опережает китайские аналоги при использовании на 30% меньше токенов.

Конкурентная позиция:

• Паритет с Claude Sonnet 4 в реальных задачах

• Превосходство над китайскими альтернативами

• Отставание от Claude Sonnet 4.5 в кодинге

• Токен-эффективность выше на 15-30%

Архитектура и развертывание

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

Всесторонние инструкции по развертыванию опубликованы в официальном GitHub-репозитории с примерами интеграции и конфигурации.

Оценка реального использования

Компания подчеркивает, что реальный опыт важнее лидербордов. Траектории выполнения задач из CC-Bench опубликованы на HuggingFace для исследований сообщества, обеспечивая прозрачность оценки.

Если материал был полезен, поставьте, пожалуйста, плюс — мы стараемся выбирать для вас только самые актуальные и интересные новости из мира ИИ.

Центральный Банк России опубликовал список из десяти самых популярных фраз, используемых мошенниками. Ими регулятор поделился в своем Telegram-канале.

«Мы собрали топ-10 распространённых фраз кибермошенников, которые они сейчас используют чаще всего. По ним можно быстро вычислить обман», — отметили в ЦБ.

Перечень распространённых фраз, применяемых мошенниками при телефонных звонках:

• «Переключаю вас на сотрудника ЦБ»;

• «Финансирование запрещённой организации»;

• «Звоню по поводу удаленной работы».

Также в попытках обмануть граждан преступники прибегают к подобным словосочетаниям:

• «Это отдел курьерской доставки»;

• «На ваших банковских счетах обнаружены неучтенные средства»;

• «Необходимо задекларировать денежные средства и ценности»;

• «Ваш аккаунт на портале «Госуслуг» взломан».

В сообщениях через мессенджеры мошенники часто используют следующие фразы:

• «Беспокоит директор департамента»;

• «Это ты на фото?»;

• «Оплатите имеющуюся задолженность».

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

ИБ-ДАЙДЖЕСТ INFOWATCH

Криптобиржа Crypto.com атакована подростком из Флориды с использованием украденных данных UPS.

Китай мог похитить данные о мозговой активности спортсменов для военных исследований, возможно, для создания «суперсолдат».

Корейские инвестиционные фонды пострадали от кибератаки русскоязычной группировки Qilin на облачное хранилище.

Автогигант подтвердил утечку данных из CRM Salesforce после взлома хакерами ShinyHunters.

Бразильская военная полиция потеряла более 2 ТБ данных, включая медицинские карты и удостоверения личности.

НКО заплатит $1 млн за утечку персональных и медицинских данных 167 400 доноров.

Подборка бесплатных обучающих материалов о PostgreSQL

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

PostgreSQL для новичков

В подборке 14 статей на два с половиной часа чтения. Здесь база: установка и настройка PostgreSQL, нюансы управления, резервного копирования и репликации. Для ленивых — что делать, если администрировать самим БД не хочется.

Средний уровень

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

PostgreSQL на максималках: практикум по расширениям

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

Бонус. Бесплатный онлайн-курс для новичков «Погружение в PostgreSQL»

В семи уроках вы освоите основы SQL, научитесь создавать и связывать таблицы, выполнять базовые операции с данными. Эти знания станут хорошим стартом для дальнейшего изучения PostgreSQL. Курс подойдет начинающим администраторам баз данных, разработчикам, DevOps-инженерам и аналитикам.

Проверил, откуда руки растут.

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

Поднимать можно руками раз в 4 часа или платить hh за pro-подписку. Второе не то, чтобы дорого, но это не путь самурая. А за длительное время руками поднимать его надоело. В принципе, сервисы для подъема есть, не знаю сколько, но знаю как минимум два, скорее их десятки.

В общем, запилил себе помощника.

Базово Python и Django я понимаю; что есть такое API тоже понимаю. Углы, конечно, срезал - вся документация по API hh после первичного личного ознакомления разом улетела в Gemini 2.5 Pro, как бабулины пирожки на противне в духовку. На выходе - диковатый код, с которого еще немного срезал лишнего. Локально все заработало: tg-бот в качестве интерфейса + бэк, гоняющий запросы-ответы. Дальше облако, домен, код в контейнер, еще немного настроек и вуаля - помощник трудится 24/7. Пока, правда, неотесанный, но работает. Еще немного допилить, и будет user-friendly. А там гляди и в пет-проект превратится)

В общем, всем, кому пет-проекты на Python/Django нужны, рекомендую эту идею запилить. Просто, быстро, полезно.

P.S. Автор как бы не программист, но чуток кодить умеет.

Как мы ушли с Airflow и упростили MLOps

Привет! Меня зовут Александр Егоров, я MLOps-инженер в Альфа-Банке, куда попал через проект компании KTS. За свою карьеру я построил четыре ML-платформы (одна из которых сейчас в Росреестре) и развиваю с командой пятую. Недавно мы полностью пересобрали пайплайны и мигрировали c Airflow на Argo Workflows + Argo CD. Делимся подробностями!

Почему Airflow стал мешать?

Airflow отлично подходит для десятков DAG’ов, но на масштабе сотен моделей появляются проблемы: всё усложняется, теряется Kubernetes-нативность, GitOps работает через костыли, а обновления DAG’ов становятся ручным трудом. Версионирование ломается, пайплайны идут десятками минут, и отлаживать их настоящая боль.

Почему Argo Workflows?

Argo — это K8s-native решение, декларативный подход, совместимость с GitOps, простейшее развертывание и минимум лишних компонентов. Для нас это был буквально глоток свежего воздуха. Вместо монолитного Kubeflow — один контроллер, никаких лишних слоёв и масштабируемость из коробки

Подробнее читайте в статье «GitOps для Airflow: как мы перешли на лёгкий K8s-native Argo Workflows»

Есть ли смысл спрашивать моб.разработчика про устройство хештаблицы?

Это же как спрашивать моб.разработчика про устройство базы данных или бэкенда.

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

Никак знание или незнание устройства хешмапа не влияет на разработку качественного моб.приложения. А везде спрашивают, и все заучивают.. И всех оценивают по этому ответу в том числе..

И биг О это..

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

Где здесь здравый смысл?

Вместо этого лучше спрашивать напрямую про оптимизацию времени выполнения и использования памяти.

А единственный вопрос который следует задать мобильному разработчику про хештаблицы - это используешь ли ты в качестве ключей что-нибудь кроме примитивов?

Нет - проходишь, да - ну ка расскажи тогда про хештаблицы голубчик.

Хотя я бы сразу такого взял на заметку. Ибо незачем в ключи совать то что не предназначено быть ключём, мы же с базами данных так не делаем? (Или у кого-то это бестпрактис? Тогда делитесь в комментариях для расширения кругозора 😁 )

Как я понял про хешмапы спрашивают 2 вида людей:

1. Каргокультисты, "а зачем ты спрашиваешь?", а все спрашивают и я спрашиваю, говорят что это "бла, бла, бла", и для здоровья полезно. (Так много чего для здоровья полезно 😁)

2. Те кто пару раз пихал таки в качестве ключа какую-нибудь дичь и потом отлаживал это дело пару недель, и теперь транслирует свою боль на весь мир. (Понимаю было больно, но это прошло, можно отпустить)

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

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

Или нет?

Когда WAF - не помощник
Наткнулся на ситуацию, когда митигация эксплуатации API-метода была бы возможна при блокировке POST-запроса по правилу "если тело запроса более n-байт". Но, используемый WAF в такое не умеет (вендор подтвердил, завел задачку на подумать о такой функции). Представьте: на сайте можно выбрать 3 из 5 категорий кэшбека. Но, ограничение проверяется лишь на фронте. Ничего не мешает обратиться к методу напрямую, указав все 5 параметров в теле POST-запроса:

{
 "CODE_1": "1",
 "CODE_2": "1",
 "CODE_3": "1",
 "CODE_4": "1",
 "CODE_5": "1",
 }

Где разный CODE - последовательность символов (одинаковой длины), которая означает один из кэшбеков (красота, аптеки, рестораны и т.д.). Для митигации (пока разработчики исправляют уязвимость) можно было бы прикинуть максимальное количество байт примерно до (чтоб был небольшой люфт по байтам: чуть более 3-х запросов, но, длина из 4 параметров уже точно не попадала):

{
 "CODE_1": "1",
 "CODE_2": "1",
 "CODE_3": "1",
 "CODE_4":
 }

Как оказалось, подобного правила нет в различных WAF (поспрашивал коллег, почитал документацию некоторых популярных WAF). Правда, тут нужно быть внимательным: иногда представители вендора\интегратора ошибочно считают, что у них это есть. Но, в процессе обсуждения выясняется, что речь идёт о другом. О максимальном размере тела POST-запроса, общим для всех методов (защита от DoS). Либо речь идёт о составлении описания правила, где блокируются запросы, не попадающие под описание правила. Но, в данном случае все 5 параметров в запросе корректны (согласно swagger-схеме). Интересно: какие из существующих WAF уже сейчас умеют в подобные правила (максимальный размер тела запроса для конкретного метода)?

Ждем в прямом эфире! Узнайте, как ИИ меняет информационную безопасность

Практические ИБ-конференции RoadShow SearchInform в самом разгаре. Сегодня встречаемся с участниками в Москве. Впереди еще много городов (список здесь).

Если вы не нашли в списке свой город, но хотите пообщаться с коллегами по цеху, задать вопросы спикерам и узнать все о самых горячих трендах инфобеза, то подключайтесь сегодня к онлайн-трансляции. Доклады стартуют в 14:00 (мск).

Смотреть тут: [тыц]

А уже сейчас можно поучаствовать в большом исследовании уровня ИБ в компаниях России и СНГ. Спрашиваем про бюджеты, средства защиты, утечки и другие внутренние инциденты - а потом все считаем и делимся статистикой.

Строите микросервисную архитектуру? Уверены, что с аутентификацией и авторизацией всё идеально?

2 октября разберем на бесплатном вебинаре «Аутентификация в микросервисах за 1 час: Keycloak и JWT без головной боли» отраслевой стандарт для безопасности — Keycloak.

План вебинара (только полезное):

✔️ Keycloak как IAM-сервер: быстрый старт и настройка.

✔️ Интеграция с ASP.NET приложением: пишем код, который работает.

✔️ Четкое разграничение прав (Authorization): чтобы пользователи видели только своё.

✔️ OAuth 2.0 / OIDC & JWT: не просто аббревиатуры, а инструменты, которые вы поймёте и примените.

Итог: вы уйдете с чёткими инструкциями и рабочим примером для ваших проектов.

📅 Когда: 2 октября, 17:00-18:00 (МСК)

👨‍🎓 Спикер: Андреев Андрей — эксперт в области разработки и архитектуры ПО.

👉Забронировать место 👈

Этот час сэкономит вам недели на проектировании и отладке безопасности.

xAI анонсировала Grokipedia — ИИ-энциклопедию на основе модели Grok

Компания xAI Илона Маска объявила о разработке Grokipedia — альтернативы Википедии с автоматической коррекцией ошибок через искусственный интеллект. Проект позиционируется как шаг к цели xAI "понять Вселенную" и должен стать open-source платформой с ИИ-модерацией контента.

Технология и архитектура

Grokipedia будет использовать модели Grok от xAI для создания корпуса знаний, аналогичного Википедии. Система применяет синтетические коррекции для переписывания информации из Википедии, книг и других онлайн-источников с автоматической проверкой фактов.

Заявленные возможности:

• Автоматическая коррекция ошибок через ИИ

• Проверка точности и фактологичности контента

• Open-source архитектура

• Интеграция с моделями Grok для генерации статей

Отличия от Википедии

Основное отличие — использование ИИ для автоматической верификации и коррекции информации вместо краудсорсинговой модели редактирования Википедии. Маск критикует Википедию за предвзятость и позиционирует Grokipedia как более нейтральную альтернативу.

Ключевые преимущества по версии xAI:

• ИИ-проверка фактов в реальном времени

• Снижение человеческой предвзятости

• Более быстрое обновление информации

• Автоматическое выявление противоречий

Контекст и мотивация

Анонс Grokipedia следует за длительной критикой Маском Википедии, которую он обвиняет в политической предвзятости. Проект вписывается в общую стратегию xAI по созданию альтернатив существующим информационным платформам.

Маск заявил, что Grokipedia — "необходимый шаг к цели xAI понять Вселенную", связывая проект с более широкой миссией компании по развитию общего искусственного интеллекта.

Технические вызовы

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

Потенциальные проблемы:

• Галлюцинации ИИ и генерация ложных фактов

• Сложность верификации автоматически созданного контента

• Отсутствие прозрачности процесса редактирования

• Зависимость от качества обучающих данных

Модель управления контентом

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

Вопрос прозрачности критичен — Википедия показывает историю правок и обсуждения, что обеспечивает подотчетность. Неясно, как Grokipedia будет решать эту проблему в ИИ-управляемой системе.

Конкуренция и рынок

Grokipedia не первая попытка создать альтернативу Википедии. Существуют Conservapedia, Citizendium и другие проекты, но ни один не достиг сопоставимого охвата и влияния.

Преимущества Википедии:

• 60+ миллионов статей на 300+ языках

• Установленное доверие сообщества

• Прозрачная модель редактирования

• Некоммерческий статус

Сроки и доступность

Конкретные сроки запуска Grokipedia не объявлены. Маск заявил о разработке проекта в xAI, но детали технической реализации, модели финансирования и планов по выпуску не раскрыты.

Учитывая сложность задачи и амбициозность целей, реализация может занять значительное время и потребовать решения множества технических и этических вопросов.

Контейнеры не панацея: скрытые затраты на содержание Kubernetes, о которых молчат вендоры

Kubernetes стал де-факто стандартом оркестрации, но за кадром остаются реальные эксплуатационные расходы. Когда стоимость обслуживания кластера превышает стоимость самих сервисов — пора пересматривать архитектурные решения.

Что не учитывают при внедрении:

• Эффективность нод: В среднем 35-40% ресурсов простаивают "на всякий случай"

• Стоимость сетей: Service mesh + CNI добавляют 15-20% к потреблению CPU

• Трудозатраты: 1 инженер на 3-5 кластеров — утопия для средних компаний

Реальные метрики из практики:

bash

# Анализ утилизации за 3 месяца
kubectl top nodes | awk '{sum += $3} END {print "Средняя загрузка:", sum/NR "%"}'
# Результат: 41% по CPU, 28% по памяти

Где теряем деньги:

1. Overprovisioning
   "На всякий случай" развертываем на 200% больше ресурсов

2. Сложность мониторинга
   Требуется отдельный стек: Prometheus + Grafana + Alertmanager

3. Безопасность
   Pod Security Policies, network policies — +20% к времени развертывания

Когда Kubernetes оправдан:

• 50+ микросервисов

• Непредсказуемая нагрузка

• Команда из 3+ DevOps инженеров

Альтернативы для средних проектов:

• Nomad — проще оркестратор без привязки к контейнерам

• Docker Swarm — для простых сценариев

• Managed k8s — если нет своей экспертизы

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

#Kubernetes #DevOps #контейнеризация #TCO #микросервисы

А как у вас с реальной утилизацией ресурсов в k8s? Делитесь наблюдениями в комментариях.

Приложение Sora 2 доступно пока по приглашениям и работает только на устройствах Apple, но видеороликами из него забиты уже все ленты социальных сетей. Хотя это просто очередной генератор видео, OpenAI позиционирует приложение как соперника TikTok в деле разжижения мозгов и уничтожения способности удерживать внимание. Разница лишь в том, что контент создаёт генеративная нейросеть на основе промптов пользователей. Бесполезно проводить время предлагается за просмотром шлака от ИИ.

Заявляется, что относительно первой версии модель Sora 2 значительно более продвинутая. Это очевидно даже по описанию технических характеристик: Sora 2 генерирует 10-секундные клипы с синхронизированной аудиодорожкой, в то время как первая итерация модели умела создавать только видеоряд. Клипы могут быть ремиксом или начинаться со статичного изображения, а особую популярность снискала функция камео.

На практике это означает, что все ленты сейчас заполнены Сэмом Альтманом, ворующим игровые видеокарты из магазинов электроники. Ну а чего вы хотели? Фантазии у первопроходцев мало, да и его лицо в редакторе — это одно из предлагаемых. В лучшем случае он будет ползать по полу офиса OpenAI в кигуруми кота и истошно мяукать.

На самом деле интересные бенчмарки всё же придумывают. К примеру, как показывает Кристофер Фрайант, Sora 2 выдаёт отлично выглядящие 10-секундные клипы геймплея любой популярной видеоигры. Многие хвалят Sora 2 за отличное понимание физики.

Как утверждает дата-саентист из Meta¹ Колин Фрейзер, не всё так однозначно. У себя в микроблоге он показал несколько примеров откровенных косяков Sora 2. Ниже представлена склейка шести из них.

Здесь опробованы разные промпты. Чаще всего они связаны с отделением одного объекта от другого или их совмещением в единое целое. Как показал скептик, с взаимодействием объектов в кадре у Sora 2 откровенно туго:

1. Вылезающий из автомобиля человек. В ответ на промпт Фрейзера модель зажимает ногу человека дверью.

2. Прыгающий через обруч пёс никуда не прыгает.

3. Пиво ведёт себя как желе, у бармена с пальцами случилась каляка-маляка.

4. Кстати, попытки упростить промпт про вылезание из машины ничего хорошего не приносят.

5. Даже когда Колин явно задал в промпте состояние стакана, сосуд с апельсиновым соком опустошён до дна не был — уровень жидкости даже не изменился.

6. Ну и задувание свечей всё так же на реальность не походит.

Твиты Фрейзера вызвали резко негативную реакцию. У себя в микроблоге он пожаловался, что люди в ответ на поиск изъянов начинают злиться. Колин не понимает, почему многие настолько эмоционально инвестированы в какое-то приложение для генерации и листания видеороликов.

(1) Холдинговая компания Meta — экстремистская организация, её деятельность запрещена.

Разбираю статью про обучение с подкрплением для самых маленьких и генерацию ответов

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

Вот для этого придумали Compute as Teacher (CaT). Работает оно так:

1. Пользователь кидает запрос. Ну там: «объясни квантовую физику бабушке».

2. Модель честно пишет сразу несколько версий ответа. Каждая по-своему кривая, но иногда попадаются удачные куски.

3. Другая копия этой же модели собирает из них «лучший хит» — вроде плейлиста «самое ок» из твоих старых песен.

4. Потом мы сравниваем все черновики с этим «финальным шедевром» и решаем: «ага, вот это было ближе, а это лучше забыть как страшный сон».

5. Модель сама делает выводы и в следующий раз уже тупит чуть меньше.

В итоге получается странная штука: модель учится без учителя, проверяя сама себя. Как если бы школьник писал 5 вариантов решения задачи, потом сам делал «сборку Франкенштейна» из них, и именно её принимал за эталон. А дальше наказывает себя за плохие черновики и хвалит за удачные.

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

Если коротко: CaT — это как спорить с самим собой в душе, только полезно

Ссылка на статью у меня в блоге, потому что у меня карма маленькая и тут я не могу всё опубликовать

—————

Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура

Записки параноика: почему Zero Trust — это не мода, а новая реальность для ИТ-инфраструктуры

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

Почему Zero Trust — это не просто buzzword:

• 68% компаний сталкивались с инцидентами внутренних угроз

• Среднее время обнаружения нарушителя в сети — 207 дней

• Традиционные VPN стали главным вектором атак в 2024

Как мы внедряли Zero Trust без переписывания всей инфраструктуры:

Сегментация на микроуровне:

yaml

# Instead of: Allow 10.0.0.0/8
# We use: 
- name: db-access
  source: app-server-01
  destination: postgres-01
  port: 5432
  auth: mTLS + service-account

Service Mesh вместо VPN:

• Istio для взаимной аутентификации сервисов

• Автоматическое шифрование всего трафика

• Детальный контроль доступа на уровне L7
  
  Непрерывная верификация:

bash

# Проверка целостности хостов каждые 30 сек
sudo attestation-agent verify --policy strict

Технические вызовы, с которыми столкнулись:

• Производительность: Overhead Istio ~3ms на hop

• Сложность отладки: Трассировка запросов через 5+ сервисов

• Миграция: Постепенный перенос legacy-систем

Метрики после 6 месяцев работы:

• Время сдерживания атаки сократилось с часов до минут

• Количество инцидентов снизилось на 73%

• Audit trail для compliance стал детализированным

Ключевые инсайты:

1. Начинайте с идентификации — без точной инвентаризации сервисов ничего не выйдет

2. Поэтапное внедрение — от критичных workload к периферии

3. Автоматизация политик — ручное управление не масштабируется

Zero Trust — это не продукт, а архитектурный принцип. И да, он требует изменений в менталитете команды больше, чем в технологиях.

Post-Quantum Cryptography: тихая революция в инфраструктуре, которую нельзя игнорировать

Пока большинство обсуждает ИИ, в мире криптографии происходит настоящая революция. NIST утвердил первые стандарты постквантовой криптографии, и это потребует фундаментальных изменений в ИТ-инфраструктуре уже в ближайшие 2–3 года.

Проблема:

Современные алгоритмы (RSA, ECC) могут быть взломаны квантовыми компьютерами в обозримом будущем. Миграция на PQC — не вопрос «если», а вопрос «когда».

Что меняется:

• Размер ключей увеличивается в 5-10 раз

• Процессоры испытывают нагрузку на 30-50% выше

• TLS-хендшейки становятся значительно объемнее

Наши тесты с OpenSSH 9.8:

bash

# Стандартный ключ Ed25519: 68 байт
# PQC-ключ Dilithium3: 1842 байта
# Рост трафика при подключении: ~2700%

Практические рекомендации:

1. Аудит инфраструктуры:

python

# Скрипт для поиска уязвимых сервисов
import ssl
for protocol in ['TLSv1.2', 'TLSv1.3']:
    ctx = ssl.create_default_context()
    ctx.set_ciphers(protocol)

2. План миграции:

• 2025: Тестирование гибридных схем (PQC + традиционные алгоритмы)

• 2026: Перевод внутренних сервисов

• 2027: Полный переход для внешних endpoint

3. Аппаратные требования:

• CPU с поддержкой AVX2/AVX-512

• Увеличение буферов сетевых карт

• +30% к оперативной памяти для сертификатов

Метрики производительности после перехода:

• 📉 Throughput VPN: снижение на 15%

• 📈 Потребление CPU: рост на 40%

• ⏱️ Время TLS-хендшейка: +80 мс

Вывод:

Откладывание перехода на PQC аналогично игнорированию проблемы Y2K в 90-х. Уже сегодня нужно начинать тестирование и планирование, чтобы избежать хаотичной миграции под давлением регуляторов.

Уже проводили тесты с постквантовыми алгоритмами? Делитесь результатами в комментариях — соберем статистику по разным конфигурациям.

Я размышлял над созданием инструмента для вайбкодинга и вот что я понял:

Вайбкодинг — это менеджмент.

Со всеми его плюсами и минусами.

У менеджмента фокус на управление.

У разработки фокус на конструирование.

Для менеджмента нужны прокачанные скилы общения (говорить, слушать, писать, читать на человеческом)

Для разработки нужны прокачанные скилы разработки (говорить, слушать, писать, читать на программном)

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

Посиделки с инди #5: The King is Watching и путь к 300к копиям. Много говорили про геймджемы. Профакапился с тем, что про управление командой мало расспросил, но даже без этого 2 часа вышло 😅

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

Где можно послушать/посмотреть:

• Ютубчик

• Spotify

• Apple Podcasts

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

Конференция для всех участников рынка электроники от лидера поставки печатных плат в России: 24 ноября в Москве

Приглашаем вас на корпоративную конференцию "ГРАН Груп", которая будет интересна всем участникам рынка электроники от инженеров до топ-менеджеров! Здесь мы говорим о печатных платах с точки зрения развития электроники в России. 

🗓 Когда: 24 ноября 2025 года. Начало мероприятия в 9.30.

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

📍  Место проведения: г. Москва, Отель «Hotel Continental», ул. Тверская, 22, Конференц-зал «Родченко».

Темы конференции:

• Космические горизонты промышленной электроники:

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

• Инженерный космос:

Печатная плата – какая она? Прямоугольная, 1.6 мм, 18/18, зеленая маска и белая шелкография? Мы подготовили обзор нестандартных плат, с которыми уже работали. Расскажем о требованиях, параметрах, процессе подготовки к производству. Только самые интересные кейсы и дискуссия о возможностях инженерного пространства.

• Новейшие технологии:                                                  

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

• Потенциал российского рынка печатных плат:

Серийное производство печатных плат в России? Отличная мысль! Насколько это актуально и возможно? Вас ждет откровенный и полный обзор потенциала этой идеи: технологии, материалы, кадры и т.д. Присоединяйтесь к обсуждению!

Ждем вас!  🤝

Конференции ГРАН всегда бесплатные.

Привет, потенциал kui еще немного увеличился! Случилось то что случилось, в продской cronjoпеb'е что-то застряло. Добавил в kui ручной запуск кронжоб и kui'ем протолкнул застрявшее в кронжобе ...

Творите, выдумывайте, пробуйте!)