Все потоки

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

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

Егор, аналитик в Naumen Contact Center, рассказал, как внутри продукта устроено нагрузочное тестирование и почему «запустить тест» — самая простая часть.

• количество одновременно работающих операторов

• нагрузка на входящие и исходящие вызовы

2️⃣ Почему аналитик вообще занимается нагрузочным тестированием?

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

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

3️⃣ Когда нужно проводить нагрузочное тестирование?

Есть несколько типичных ситуаций, когда без него не обойтись:

• Регулярные проверки перед релизом или после обновления серверов.

• Тестирование новых фич — если изменения потенциально могут повлиять на производительность.

• Запросы от клиентов или команды внедрения — когда нужно проверить нагрузку или конфигурацию.

• Внутренние задачи разработки — когда команде нужно проверить свои решения под нагрузкой.

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

4️⃣ Как принимается решение о проведении тестирования?

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

5️⃣ Как устроен процесс нагрузочного тестирования?

Процесс можно разделить на три этапа:

1. Первичная аналитика — собираем требования и определяем цель.

2. Детальная аналитика — описываем сценарии, метрики, инфраструктуру.

3. Проведение тестов — запускаем тестирование и анализируем результаты.

6️⃣ Почему нагрузочное тестирование требует отдельной инфраструктуры?

Для более-менее реалистичного тестирования недостаточно одного сервера. В нашем случае используются несколько гипервизоров, десятки виртуальных машин, серверы генерации и приема нагрузки, а также инструменты вроде Gatling, JMeter, Grafana и Ansible.

Отдельные компоненты эмулируют работу операторов и клиентов. Например, для проверки нескольких тысяч операторов фактически собирается отдельный контур.

7️⃣ Почему даже короткий тест может занимать полтора часа?

Потому что сам прогон — только часть процесса. До запуска нужно подготовить окружение, очистить старые данные, проверить сервисы, настроить мониторинг и применить параметры. После — собрать артефакты, метрики и результаты. Поэтому тест на 20 минут превращается в полтора часа работы.

8️⃣ Что происходит после тестирования?

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

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

После анализа команда либо фиксирует результаты, либо заводит задачи на доработку сервисов, окружения или инструментов.

Среди специалистов по информационной безопасности ходит довольно смешной и жизненный мем:

Я инфобезник, поэтому:
• у меня нет социальных сетей
• у меня нет умных устройств
• я не сохраняю пароли в браузере
• я не использую автозаполнение
• все замки исключительно механические
• я заклеиваю веб-камеры на всех используемых устройствах
• не подключаюсь к публичным Wi-Fi
• не кликаю на ссылки • …

Этот список можно продолжать бесконечно, но в каждой шутке, как известно, есть только доля шутки. И ведь действительно, если посмотреть со стороны на свою цифровую жизнь, то можно увидеть, что:
• у меня дома нет умных колонок (только трофейная Маруся, выжившая после проведенных тестирований)
• никаких умных дверных ручек (спасибо, уже пентестили)
• я не знаю свои пароли (потому что они все разные, длиной в 30-40 символов, сгенерированные случайным образом, содержащие все 4 составляющие и хранящиеся специальным образом)
• по возможности использую 2FA (нет, я не параноик, просто соблюдаю минимальную цифровую гигиену)
• не подключаюсь к сторонним Wi-Fi (у меня безлимитный мобильный интернет, поэтому даже и смысла нет в лишних телодвижениях)
• по ссылкам хожу только через режим инкогнито (да и в принципе, почти все вирусы только на Windows, так что тут не страшно)
• а “набитая рука” на фишингах помогает определить зловредное письмо по первым словам заголовка (да, пранки с РикРоллами научили нас не кликать по подозрительным ссылкам лучше, чем повышение осведомленности со стороны ИБ ;)

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

А какие привычки цифровой гигиены используете вы и почему? Делитесь своими советами - давайте проведем внеплановое повышение осведомленности aka awareness!

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

п.с. прошу прощения, если видео было просмотрено на максимальной громкости, не в наушниках и рядом с колонкой Алисы ;)

Приходите на вебинар — покажем, как построить потоковый конвейер данных с латентностью в минуты

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

Разберем это на вебинаре по Evolution Data Platform. Будет полезно дата-инженерам, которые проектируют конвейеры, аналитикам и BI-специалистам, которым важно работать с актуальными данными, а еще архитекторам и руководителям дата-отделов.

На вебинаре расскажем и покажем:

• как проектировать архитектуру конвейера под near real-time: когда брать микробатчинг в Managed Spark Streaming, а когда хватит классического батча;

• зачем нужен Managed Trino как единый слой запросов поверх «горячих» и «холодных» данных — и как это убирает дублирование логики;

• как партиционировать данные по времени в Object Storage, чтобы запросы не тормозили;

• как управлять схемой через Managed Metastore, когда структура потока меняется;

• как настроить дашборд в Managed BI с автообновлением и алертами на отклонения;

• как измерять латентность конвейера — от генерации события до появления на дашборде.

На практической части соберем реальный сценарий: оконная агрегация транзакций в Managed Spark Streaming, оркестрация через Managed Airflow, витрина в Object Storage, ad-hoc запросы через Managed Trino без копирования данных, дашборд с обновлением раз в две минуты.

📅 Когда? 21 мая в 11:00 мск.

📍 Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикеру в прямом эфире.

P.S. А еще мы тут подготовили чек-лист, как создать качественное хранилище данных за 15 шагов — забирайте, нам не жалко. 

Приглашаем вас на вебинар, рассказывающий, как с помощью AI мигрировать ваши финансовые модели из Microsoft Excel в современную EPM-платформу.

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

В программе вебинара:

• Зачем бизнесу переходить от Excel к EPM

• Обзор типовой финансовой модели в Excel

• Демонстрация миграции с помощью AI-инструмента EPM Migration Tool

• Работа модели уже в EPM-платформе

• Ключевые преимущества EPM для финансовых команд

• Бизнес-эффекты: скорость, прозрачность, снижение ошибок

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

19 мая, 11:00, онлайн, бесплатно, требуется регистрация.

Осторожно, разрозненные HR-системы тормозят ваш бизнес!

Дублирование данных, ручные сверки, отсутствие полной картины по людям и сквозных, современных сервисов. Знакомо? Проблема не в вас, а в том, что «зоопарк систем» рано или поздно становится неэффективным!

26 мая в 11.00 на вебинаре разберем, как Uplab и PERX перешли к единой системе на связке Битрикс24 и K-Team HRM. Расскажем, с какими проблемами столкнулись сами, как упростили бизнес-процессы и что изменилось после внедрения.

Спикеры

👤 Антон Аланов – ведущий эксперт по внедрениям Uplab
👤 Полина Наумова – HR people partner Uplab
👤 Екатерина Савина – руководитель отдела персонала PERX

🎁 Подарок всем участникам – самый подробный гайд по внедрению HRM без нервов и ошибок от команды K-Team HRM!

Приходите, если устали от разрозненных сервисов и хотите навести порядок без лишних затрат.

🔴 Регистрация

Когда требований много, а ясности мало: 10 уроков для аналитиков

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

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

Подборка подойдёт бизнес‑аналитикам, системным аналитикам, продактам, тимлидам и всем, кто работает с требованиями, процессами, интеграциями и постановкой задач для разработки.

1. Сначала понять бизнес‑модель

^{Если не ясно, как продукт создаёт ценность, требования быстро превращаются в список пожеланий.}

• 21 мая, 20:00 — «Формирование бизнес‑модели продукта на примере Business Model Canvas». Записаться

2. Проверить проблему через пользователей

^{Кастдев помогает отличать реальную потребность от мнения самого громкого стейкхолдера.}

• 3 июня, 19:00 — «Про кастдевы с интерактивом / исследование потребителей в теории и на практике». Записаться

3. Описать процессы и требования визуально

^{Чтобы бизнес, аналитик и команда смотрели на одну картину, а не спорили о терминах.}

• 14 мая, 18:00 — «Графическое описание бизнес‑процессов и требований». Записаться

4. Разобрать AS IS и TO BE

^{Полезно, когда нужно не просто «автоматизировать», а понять, где хаос, где контроль и что именно должно измениться.}

• 3 июня, 20:00 — «AS IS хаос или TO BE контроль: как построить единую автоматизированную финансовую модель на основе неидеальных, разрозненных данных». Записаться

5. Найти, где создаётся ценность

^{Value Stream помогает увидеть, какие этапы процесса действительно важны, а какие только тормозят движение задачи.}

• 2 июня, 20:00 — «Цепочки создания ценности: моделирование, анализ, проектирование». Записаться

6. Описать поведение системы

^{Sequence Diagram нужен, когда требований уровня «пользователь нажал кнопку» уже недостаточно.}

• 19 мая, 20:00 — «Диаграмма Последовательности (Sequence Diagram) — швейцарский нож системного аналитика». Записаться

7. Собрать объектную модель

^{Чтобы сущности, статусы, связи и правила не расползались в процессе разработки.}

• 2 июня, 20:00 — «Объектная модель без боли: как превратить хаос требований в стройную архитектуру». Записаться

8. Говорить с разработкой и бизнесом на одном языке

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

• 4 июня, 20:00 — «C4 для системного аналитика: строим единый язык между бизнесом и разработкой». Записаться

9. Вовлекать стейкхолдеров

^{Даже сильное решение может застрять, если заказчик, пользователи и команда по‑разному понимают цель.}

• 17 июня, 20:00 — «Заказчик vs Стейкхолдер: как вовлечь бизнес в проект». Записаться

10. Связать аналитику с эффектом для бизнеса

^{Хорошая аналитика должна влиять на скорость, прозрачность, качество и деньги, а не только на документацию.}

• 4 июня, 20:00 — «Операционная эффективность в IT: как находить скрытую прибыль в процессах разработки». Записаться

Если вы только входите в анализ — начните с бизнес‑модели, процессов и требований. Если уже ставите задачи разработке — выбирайте Sequence Diagram, объектную модель и C4. Если работаете с изменениями и согласованиями — смотрите уроки про стейкхолдеров, AS IS / TO BE, цепочки ценности и операционную эффективность.

_{P. S. А если нужен не разовый урок, а полноценный маршрут развития, загляните в каталог курсов OTUS по аналитике и анализу: там собраны программы по системному и бизнес‑анализу, работе с требованиями, процессами и данными.}

_{[Смотреть каталог]}

В России меньше трети компаний страхуют киберриски

Экспертно-аналитический центр ГК InfoWatch выпустил исследование в «Ущерб от утечек информации и страхование». В нем говорится, что риски киберинцидентов застрахованы менее чем у трети российских компаний (28%), при связанные с подобными происшествиями риски страхуют лишь 15,7% компаний.

Кроме того:

• штрафы за утечки данных и возможные убытки от выплат вымогателям в России законодательно страховать запрещено;

• умышленные действия сотрудников не входят в большинство полисов киберстрахования;

• проблема рынка киберстрахования — сложности с оценкой ущерба от утечек, единой методики не существует.

Подробности на сайте InfoWatch.

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

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

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

Май в разгаре и у нас новые вакансии

Говорят, что ближе к лету активность найма в ИТ-отрасли ослабевает. Но только не в SSP SOFT.

Про нас как работодателя: компания SSP SOFT работает в сфере заказной разработкой ПО и предоставления выделенных команд на ИТ-аутсорсинг для крупных клиентов. По размеру компании — мы «средний бизнес» с числом сотрудников около 500 человек, и с проектами федерального уровня.

Рабочие места у нас в московском офисе, который открылся в 2025 году в ЦАО у самой Красной площади. А еще бывают вакансии в департамент разработки в Томске и почти всегда на «удаленку» из любой точки России.

Работа в SSP SOFT — это сложные и интересные проекты, поддерживающая атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента.

Горячие вакансии мая (больше 10 позиций в Москве):
1️⃣ Бизнес аналитика
2️⃣ Дата Инженера
3️⃣ Системного аналитика
4️⃣ Automation QA Engineer (Java) (инженера по автоматизации тестирования, язык Java)
(на остальные вакансии см. ссылку ниже, перейдя на ХХ-ру)

Что предоставляет кадровая политика SSP SOFT:
✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины.
✅ Центр компетенций и личное наставничество ускорят развитие до максимума.
✅ Офис, гибрид или «удаленка» ? Есть все варианты.
✅ Время — ваш ресурс. Мы его уважаем.

Подробности о вакансиях читайте на нашей странице ХХ.ру, но там откликаться необязательно. Ждем резюме напрямую в ЛС нашей HR Lead (https://t.me/AONikitina).
Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».

Желаем всем хабровцам успешной карьеры в 2026 году 🚀

Инфраструктура для ИИ-ассистента: как собрать рабочую систему

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

В новой статье разобрали, из каких компонентов состоит инфраструктура для AI-ассистента. Показали, где достаточно CPU и внешнего API, а когда нужны GPU и собственный инференс. Отдельно рассказали про хранение документов и истории диалогов, векторный поиск, RAG-пайплайны, контейнеризацию, Kubernetes и различия между MVP и production-архитектурой.

Все подробности — в блоге Рег.облака.

Так ли нужна автоматизация личных задач?

Все наперебой рассказывают, как они автоматизировали свою жизнь при помощи агентов. Звучит обычно красиво!

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

Позвольте, как часто вам нужно записываться к врачу? Откуда агенту знать, чего мне сегодня захочется на ужин? — По мне, так практическая ценность большинства из этих "решений" нулевая. Единственный смысл — разобраться с технологией, чтобы потом применить там, где она реально нужна.

Одноразовая автоматизация

Расскажу историю.

Курсе на третьем было у нас задание рассчитать что-то про p-n переходы — сначала легируем бором, потом мышьяком, диффузия, отжиг и все такое. Звучит для студента страшно, но на самом деле на кафедре была методичка, просто берешь и делаешь.

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

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

Мораль этой истории проста: не надо автоматизировать разовые или редкие задачи.
Большинство персональных задач — из этой категории. У вас получится больше тестов, чем реальных кейсов. Такая овчинка едва ли стоит выделки.

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

Или вы просите агента записать вас на занятия по инглишу. Как ему поставить задачу? Можно придумать кучу параметров, но зачем? При том, что задача решается в один поисковый запрос. Как я в итоге выбрал? — Да очень просто, записался на курсы, которые находятся в доме, в котором я раньше жил. Ностальгия-с! Мог бы это учесть агент? — Если бы вам это заранее пришло в голову, то да. Но вряд ли.

Ничего личного, только бизнес

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

Мое субъективное мнение: здесь мы вступаем на поле офисной автоматизации и все эти задачи рано или поздно будут сделаны тем же Microsoft или кем-то еще. Чисто поупражняться — можно. Сделать продукт — тоже можно, только понимая, что срок его жизни будет короток.

Но это пол-беды. Главное — здесь нет жесткой грани между персональным и коллективным, если мы говорим про бизнес.

Если агент управляет вашим расписанием, он должен координироваться с агентом вашего партнера. Это светлое будущее расписывал Тим Бернерс Ли еще в 1997 году, как наши персональные агенты будут обо всем договариваться.

Но эти агенты должны действовать в корпоративной среде и соблюдать все корпоративные политики, работая под зорким оком ИБ. Можно ли такое запилить на коленке? — Только, если у вас есть соответствующие навыки.

Но это все будет shadow IT и потенциальная угроза безопасности.

Сомневаться — нормально

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

Вполне возможно, что я ошибаюсь. Может сбудется пророчество про Semantic Web 2.0 и вокруг будут одни агенты. (Ага, не будет ни театра, ни кино, одно сплошное телевидение, где-то я это слышал — опять нашептывает мне внутренний скептик.)

Мой телеграм-канал Agentic Enterprise — подписывайтесь!

Rust Roadmap 2026 на русском: от нуля до production-кода

Недавно я стал фанатом Rust, к чему и вас призываю)

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

Что внутри:

• базовый синтаксис и первые программы

• ownership, borrowing и lifetimes

• Option, Result, traits и generics

• обработка ошибок и тестирование

• std, smart pointers и многопоточность

• async/await и Tokio

• macros, unsafe и FFI

• web, CLI, embedded, WASM, gamedev и ML

• мини-проекты на каждом этапе

Главная ценность roadmap в том, что он ведёт по Rust постепенно: сначала база, потом ключевая модель памяти, затем практические направления и реальные проекты.

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

Сохраняйте себе и отправляйте тем, кто всё ещё боится borrow checker.

https://github.com/Develp10/rust-roadmap-ru/tree/main

✔️ GPT 5.5 полностью решила задание из бенчмарка ProgramBench

Команда ProgramBench сообщила (https://programbench.com/blog/gpt-5-5-first-solve/), что модель GPT 5.5 в режимах high и xhigh впервые в истории теста полностью прошла одно из заданий - задачу cmatrix (https://github.com/abishekvashok/cmatrix).

До этого ни одна модель из публичного рейтинга не доводила задания до конца.

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

🟡Лидерборд выглядит так

🟢GPT 5.5 (xhigh) - 1 место: 0,5% полностью решённых задач и 13,5% почти решённых (то есть проходящих свыше 95% поведенческих тестов)

🟠GPT 5.5 (high) - те же 0,5% при 5% почти решённых

🟠Claude Opus 4.7 (xhigh) показала 0% и 4,5%, обычная версия Opus 4.7 - 0% и 3%

🟠Opus 4.6 - 0% и 2,5% соответственно

Совокупно число почти решённых задач у GPT 5.5 достигло 26, это рекорд рейтинга.

Примечательно, что в режиме medium, который OpenAI выставляет по умолчанию, GPT 5.5 лишь незначительно опережает Claude Sonnet 4.6. При включении расширенного рассуждения её результат заметно улучшается.

🟡Разброс по стоимости

Запуск GPT 5.5 (high) стоил $3,17 и потребовал 34 обращения к API, GPT 5.5 (xhigh) - $4,84 и 40 обращений.

Тот же запуск Claude Opus 4.7 (xhigh) обошёлся в $10,74 при 178 обращениях, однако решение содержало 19 ошибок в поведенческих тестах.

По разбору авторов, все провалы объясняются 2-мя багами в коде Claude: чувствительностью парсера цветов к регистру и неверным кодом возврата.

Интересно, что 2 версии GPT 5.5 выбрали разные языки для одной и той же задачи: high решала на C с ANSI escape-последовательностями, xhigh предпочла Python.

Claude Opus 4.7 (xhigh) использовала библиотеку ncurses и команда бенчмарка охарактеризовала этот подход как креативное системное решение, которое, впрочем, не дало преимущества в итоговом результате.

#news #ai #ml

В C код может выполниться ещё до main()

В Linux и GCC есть constructor-функции - они запускаются автоматически до входа в main().

Выглядит почти как магия:

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

Где это используется:

- инициализация глобального состояния

- подготовка shared libraries

- регистрация плагинов

- настройка runtime-окружения

- выполнение служебного кода до основной логики

Именно поэтому в C-программе не всегда всё начинается с main().

Иногда до него уже кто-то успел поработать.

Подсмотрел в тг про С++ : https://t.me/cpluspluc/1449

Так получилось, что мне приходится работать с достаточно древними серверами (причины оставаться на старом железе и софте разные, но достаточно веские). Я и так стараюсь держаться на два шага позади переднего края (чаще всего это Debian oldoldstable), но иногда приходится делать резкий шаг вперёд (обновляться до oldstable, который скоро oldoldstable станет).

Вот и сейчас обновил кое-что с Bullseye на Bookworm. И получил при попытке зайти со старого OpenSSH 5.3 на новый 9.2 “no hostkey alg”. В новой версии OpenSSH по умолчанию отключены алгоритмы ssh-rsa и ssh-dss (первый из-за небезопасного хеша SHA1, второй из-за общей проблемности DSA); а старые версии ещё не умеют rsa-sha2-256, rsa-sha2-512 (не говоря уж об эллиптических кривых).

К счастью, эти алгоритмы ещё не удалены напрочь! Поэтому для обеспепчения возможности подключения старого клиента OpenSSH 5 к новому серверу OpenSSH 9 достаточно записать такие строки в файл /etc/ssh/sshd_config.d/local.conf (и перезапустить sshd):

HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa

В обратную сторону тоже работает, чтобы иметь возможность заходить новым клиентом OpenSSH 8 (и выше) на старый сервер OpenSSH 5 (и ниже) достаточно прописать такие три строки в файл ~/.ssh/config:

Host old-server
        Hostname 1.2.3.4
	. . .
        HostKeyAlgorithms +ssh-rsa
        PubkeyAcceptedKeyTypes +ssh-rsa
        KexAlgorithms +diffie-hellman-group14-sha1

Тысячи сайтов на cPanel скомпрометированы через одну уязвимость — и атакующие работали незаметно шесть лет до этого всплеска.

По данным SecurityLab, за недавней волной взломов стоит не случайный скрипт-кидди, а организованная группа с многолетним опытом. Шесть лет — это не оговорка. Столько времени они оставались в тени, прежде чем атаки стали заметны.

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

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

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

Для владельцев хостинг-инфраструктуры и тех, кто держит сайты на shared-хостинге с cPanel, вопрос сейчас не «взломают ли», а «не взломали ли уже». Следы присутствия профессиональной группы могут быть нечитаемы стандартными средствами мониторинга.

• Проверить версию cPanel и наличие последних обновлений безопасности

• Поднять логи аутентификации за последние недели — аномальные входы без учётных данных

• Проверить целостность файлов на сервере (особенно конфиги и веб-шеллы)

• Если хостинг управляемый — запросить у провайдера подтверждение патча

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

Пока нет публичного CVE и технического разбора, сложно говорить о полной картине. Но шесть лет незаметной работы — это уже достаточный аргумент, чтобы не откладывать проверку на потом.

TG @CIOlogia

Большинство менеджеров думают, что делегируют. На самом деле они просто раздают задачи.

Это разные вещи.

Когда ты говоришь «сделай вот это вот так» — ты не делегируешь. Ты дистанционно управляешь. Человек выполняет инструкцию, но не развивает суждение. И ты по-прежнему держишь в голове всё решение целиком.

Настоящее делегирование — это передача права думать и решать. Не задачи, а ownership.

По данным State of Delegation 2026, почти каждый пятый менеджер — «интервенционист»: делегирует и тут же вмешивается. Ещё почти каждый пятый — «изоляционист»: держит слишком много решений у себя. Вместе они составляют почти половину всех руководителей. И в обоих случаях команда не растёт, а менеджер не разгружается.

Главный предиктор исполнения в гибридных командах — не навык человека, а clarity of ownership: кто именно принимает это решение? Когда ответ размытый — исполнение страдает всегда.

Как делегировать решения, а не задачи?

Шесть шагов: составить список задач → выбрать человека → поставить чётко → дать ресурсы → дать автономию → дать обратную связь и поблагодарить.

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

И ещё одна вещь, которую стоит сказать прямо.

Если ты вмешиваешься после того, как делегировал — ты не помогаешь. Ты сигнализируешь о недоверии. Команда это считывает мгновенно и перестаёт брать на себя реальную ответственность.

Делегирование — это не про контроль над результатом. Это про доверие к суждению человека. Если этого доверия нет — сначала реши эту проблему. Всё остальное — техника.

Напрямую или через бот-платформу: как лучше интегрировать чат-боты

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

1. Прямая интеграция с каналом 

➕  Полный контроль над функциональностью — например, в случае VK можно обрабатывать не только запросы в личных сообщениях, но и комментарии под постами, на стене, под фото.
➖  Разные API, авторизации, ограничения и нюансы. Требуется закладывать время на поддержку каждого канала.

2. Интеграция через Botmother

➕  Визуальный конструктор — менять сценарии могут не-разработчики. Один сценарий обработки обращений достаточно просто раскатать на разные каналы.
➖  Меньше гибкости в тонкой настройке маршрутизации и аналитики по сравнению с другими платформами.

3. Интеграция через Fasttrack

➕  Расширенные шаблоны ответов, точная маршрутизация по командам, продвинутая аналитика.
➖  Сложнее в настройке сценариев в отличие от того же Botmother.

Что же в итоге? Можно остановиться на способе 2-в-1. Для отдельных сценариев — прямая интеграция, в других случаях — через бот-платформу. Так сделано у одного крупного клиента ITSM 365.

Подробнее про кейс, нюансы в поддержке интеграций и практические шаги по внедрению — в полной версии статьи на Хабре.

Документы и доказательства: фиксируем факт выполнения договора

Продолжаем серию постов о договорах.

Сегодня разбираем, чем подтвердить, что вы действительно выполнили работу. Особенно если вы блогер, эксперт, самозанятый или ИП, продаёте свои товары (свечи, одежду, торты) или услуги онлайн.

Проблемы начинаются, когда клиент:
⦁ отказывается платить;
⦁ требует возврат;
⦁ заявляет, что услуга оказана не полностью или товар не передан.

И тогда главный вопрос: а чем вы это докажете?

Что считается доказательством в суде

Суды давно принимают не только бумажные документы. Переписка тоже является доказательством - особенно для небольшого бизнеса.

Подойдёт:
⦁ переписки в Telegram, WhatsApp, по электронной почте;
⦁ голосовые сообщения;
⦁ скриншоты согласования условий;
⦁ файлы, отправленные клиенту;
⦁ ссылки на готовую работу;
⦁ подтверждения получения товара или услуги.

Но есть важный нюанс. Переписка должна позволять понять:
⦁ кто именно общается (номер телефона, ник, e-mail);
⦁ о какой услуге или товаре идёт речь;
⦁ какие условия согласованы;
⦁ что работа действительно выполнена.

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

Это уже может работать как доказательство.

А вот переписка в стиле «ок», «да», «сделаем» - обычно бесполезна.

Важно про скриншоты: суды принимают их, но лучше заверить у нотариуса (протокол осмотра доказательств). Без нотариального заверения ответчик может заявить, что скриншот поддельный, и суд отклонит доказательство (Решение Щёлковского городского суда от 09.08.2024 по делу № 2-5690/2024). Если контрагент «исчез» - нотариус обязателен.

Когда нужен акт, а когда достаточно переписки

Акт - самый сильный документ. Он фиксирует объём работы, отсутствие претензий, дату исполнения. Особенно важен для:
⦁ услуг, разработки, дизайна, консультаций, рекламы;
⦁ любых онлайн-услуг;
⦁ передачи товара собственного производства.

Переписки достаточно, если:
1. Из неё чётко следует, что услуга оказана в полном объёме и заказчик не имеет претензий.
2. Цена услуги небольшая и оформление акта не является обычной практикой.
3. Договор заключён в форме публичной оферты, и акцептом послужила оплата.

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

Как работают односторонние акты

Многие думают: если клиент не подписал акт - доказать ничего нельзя. Это не так.

Пункт 4 статьи 753 ГК РФ (применяется по аналогии к услугам) предусматривает возможность составления одностороннего акта, если заказчик уклоняется от приёмки.

Как это работает:
1. Направляете клиенту подписанный акт (по почте с уведомлением, курьером, в мессенджере с подтверждением отправки).
2. Даёте разумный срок на возражения (например, 5 рабочих дней).
3. Если возражений нет - работа считается принятой.

Лучше, когда это прямо прописано в договоре/оферте:
«Если заказчик в течение 5 рабочих дней с момента получения акта не направил мотивированный отказ, услуги считаются принятыми без замечаний».

В отсутствие мотивированных возражений односторонний акт является допустимым доказательством выполнения работ.

А теперь вопрос к вам: сталкивались ли с ситуацией, когда клиент отказывался платить, а доказательств было недостаточно? Как фиксируете факт выполнения работы? Делитесь опытом в комментариях 👇

«Слово живое и мёртвое» Нора Галь

Легендарная книга советской переводчицы (и не только) Норы Галь о том, как писать живые тексты. Лёгкие, понятные, ритмичные, не отталкивающие. Ну и о том, как не писать тексты мёртвые – этого, пожалуй, даже больше.

Для меня тексты – первый по значимости инструмент. Статьи (300+ на Хабре, недостижимый ТОП-1 на Инфостарте), блоги, электронные письма, переписка в мессенджерах, даже пошлятина вроде коммерческих предложений – всё это тексты. Нора Галь помогла сделать всё это живым.

Я получал много отзывов и комментариев на свои тексты. Самый редкий – «плохо написано». Это всё – влияние «Слова живого и мёртвого».

В 2019 г. я целый доклад на конференции сделал, на тему «Пиши, не пожалеешь» (текстовая версия здесь), там всё по полочкам разложил. В том числе упомянул книгу Норы Галь.

«Слово живое и мёртвое» - самая полезная книга о текстах из тех, что я читал. Она небольшая и очень конкретная. Приёмов, которые рекомендует автор, всего несколько.

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

Аналогично – причастные и деепричастные обороты. Не нужны они без какой-то особой необходимости. И нужно побольше глаголов – это «самая огнестрельная часть речи». Так, всё, дальше сами в книге прочитаете. Повторю – там всё просто и понятно. Немного практики – и сможете применять на автомате.

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

Из Книжного стека.