Все потоки

Сервис тормозит, а мониторинг ничего не показывает: разбираемся с eBPF

Сервис начал отвечать медленнее, пользователи жалуются на ошибки, а привычные дашборды показывают только рост задержек. Где искать причину, если приложение, сеть и инфраструктура выглядят «почти нормально»?

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

На открытом уроке курса «DevOps практики и инструменты» вместе с преподавателем разберём, как eBPF помогает исследовать сетевые взаимодействия, производительность и безопасность современных систем. Посмотрим, какие задачи он решает в реальной эксплуатации и где его применение действительно оправдано. Когда: 23 сентября в 20:00. Присоединяйтесь

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

Как мы систематизировали анализ конкурентов

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

Пока команда занята своими задачами, у других игроков появляются новые функции и меняется фокус. Поэтому в Naumen Erudite решили дополнить разовые исследования регулярным мониторингом.

Как устроен процесс и что он изменил, рассказала Таня, продуктовый аналитик Naumen Erudite.

1️⃣ Зачем продуктовым аналитикам следить за конкурентами?

Для нас здесь три основные цели:

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

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

3. Делиться информацией с командой — данные о конкурентах нужны не только аналитикам, но и руководителю продукта, пресейлам и проектным командам.

2️⃣ Почему решили менять прежний подход?

Информация о конкурентах хранилась в разных источниках — Google-таблицах, Jira, Miro, Confluence. Поэтому не всегда было понятно, где искать нужные данные и насколько они актуальны.

В таблице накопилось больше 50 компаний, которые мы анализировали и за которыми хотим следить. Ориентироваться в таком объеме становилось все сложнее.

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

3️⃣ Как удалось собрать все в систему?

Выбрали Miro как единую базу знаний: там храним краткую информацию о конкурентах, роадмап анализа и ссылки на подробные материалы — кейсы, проекты, скриншоты, презентации и видео с мистери-шоппинга.

В Miro сравниваем конкурентов по выручке, формату работы продукта и наличию функций. За подробностями можно перейти в Confluence, на сайт или в документацию компании.

4️⃣ Как сделали анализ регулярным?

Добавили повторяющиеся задачи: раз в две недели смотрим рассылки, Telegram-каналы и обновления продуктов, а раз в полгода пересматриваем роадмап анализа.

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

Мистери-шоппинг проводим, когда открытых источников недостаточно.

5️⃣ Почему недостаточно пересматривать всех конкурентов раз в год или два?

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

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

6️⃣ Как понять, кого анализировать в первую очередь?

Разделили конкурентов на четыре группы по степени влияния: высокий, средний и низкий уровень, а также косвенные конкуренты.

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

7️⃣ Какие инструменты помогают следить за изменениями?

Для десяти ключевых конкурентов настроили Google Alerts — раз в неделю получаем подборку новостей о них. Еще подписались на Telegram-каналы и рассылки компаний, а раз в две недели выделяем час на просмотр источников.

8️⃣ Что изменилось после перестройки процесса?

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

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

GitHub начал требовать аутентификацию для клонирования публичных репозиториев

Дата: 2–3 сентября 2026
Источник: github.com/orgs/community/discussions/206581

Что произошло

Начиная примерно с 11:00 CET 2 сентября 2026 года CI-пайплайны стали периодически падать при попытке клонирования публичных репозиториев по HTTPS без аутентификации. Ошибка возникала не на этапе получения списка ссылок (advertisement), а на следующем шаге — при выполнении POST git-upload-pack. Вместо ожидаемого ответа сервер возвращал 401 Unauthorized с заголовком www-authenticate: Basic realm="GitHub", и git пытался запросить имя пользователя.

Официальная позиция GitHub

Через сутки после появления сообщений администратор GitHub подтвердил, что это не сбой, а запланированное изменение в ответ на значительный рост автоматизированного трафика (ботов). GitHub стремится сохранить публичный доступ без аутентификации «насколько это возможно», но вынужден вводить дополнительные проверки (вплоть до CAPTCHA) для защиты инфраструктуры и поддержания стабильности для всех пользователей.

Для Git-команд GitHub теперь применяет более строгие лимиты на неаутентифицированные запросы. Когда порог превышается, сервер отвечает 401 с требованием базовой аутентификации. Это объясняет, почему проблема была непостоянной и зависела от интенсивности запросов с конкретного IP или подсети.

Сбой затронул европейский регион и пайпланы на старых версиях дистрибутивов Ubuntu и Debian.

Наконец мой мессенджер прошёл тест в Google Play . За время тестирования он научился совершать звонки по udp. Это позволило по udp получать не только голос, но и пинок от сервера на проверку сообщений в реальном времени. Осталось придумать как без внешних сервисов, вроде FCM, не засыпать вместе с системой и не давать андроиду прибить процесс приложения, чтоб принять udp пендаль в любое время. Так как мессенджер ориентирован на пользователей роутеров Mikrotik, на роутер и была возложена такая задача. Не давать телефону спать :). В качестве энергетика будет выступать DHCP Lease. В приложении я подписываюсь на изменения параметров сети, и выполняю задачу в обычном executor.

private void registerNetworkCallback() {
        ConnectivityManager connectivityManager = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);
        if (connectivityManager != null) {
            connectivityManager.registerDefaultNetworkCallback(new ConnectivityManager.NetworkCallback() {
                @Override
                public void onAvailable(@NonNull Network network) {
                    isNetworkActive.set(true);
                    if (userId > 0) {
                        tickUdp();
                        startDownloadNewMsg(true);
                    }
                    offlineHandler.removeCallbacks(resetStatusesRunnable);
                    Log.d(LOG_TAG, "Network: WiFi Connected. " + network);
                }

                @Override
                public void onLinkPropertiesChanged(@NonNull Network network, @NonNull LinkProperties linkProperties) {
                    Log.d(LOG_TAG, "LINK CHANGED DNS=" + linkProperties.getDnsServers());
                    if (userId > 0 && isNetworkActive.get()) {
                        tickUdp();
                        startDownloadNewMsg(true);
                    }
                }

                @Override
                public void onLost(@NonNull Network network) {
                    isNetworkActive.set(false);
                    offlineHandler.postDelayed(resetStatusesRunnable, 15000);
                    Log.d(LOG_TAG, "Network lost. Scheduled offline reset in 15s...");
                }
            });
        }
    }

который тригерится в том числе и на изменение списка DNS серверов. В роутере я указываю время аренды DHCP для подключённых устройств 6 минут. Соответственно устройства будут обновлять аренду каждые 3 минуты. С таким же интервалом 3 минуты, скриптом меняем список DNS серверов для локальной сети.

:local netId [/ip dhcp-server network find address="192.168.88.0/24"];
:local currentDns [/ip dhcp-server network get $netId dns-server];
:if ($currentDns = "192.168.88.1,8.8.8.8") do={
    /ip dhcp-server network set $netId dns-server="192.168.88.1,8.8.4.4";
} else={
    /ip dhcp-server network set $netId dns-server="192.168.88.1,8.8.8.8";
}

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

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

Представлен открытый проект Game Optimizer, который оптимизирует работу CPU под игры в Windows (распределяет потоки и кэш, чтобы разделить нагрузку).

На примере Overwatch у тестеров получилось увеличить FPS вдвое с 210 до 450 кадров. Утилита грамотно распределяет ресурсы, как работает:

• Снижает нагрузку на ваш ПК, которую создают фоновые приложения и утилизируют ресурсы CPU, в которых нуждается игра. Особенно актуально, если у процессора есть кэш нескольких уровней (L1, L2, L3).

• CPU Game Optimizer создаёт маски для игр, которые разделяют ресурсы.

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

Проект хорошо сочетается с такими процессорами:

• Intel Core Ultra 9 285K, Ultra 7 265K, Ultra 5 245K, Core i9-14900K, i7-14700K, i5-14600K, i5-14400F, Core i9-13900K, i7-13700K, i5-13600K, Core i9-12900K, i7-12700K, i5-12600K.

• AMD Ryzen 9 9950×3D• Ryzen 9 9900×3D, Ryzen 9 7950×3D, 7900×3D, Ryzen 9 9950X, 9900X, PRO 9965, PRO 9955, PRO 9945, Ryzen 9 9950×3D2 Dual Edition, Ryzen 9 7950X, 7900X, 7900, PRO 7945, Ryzen 9 5950X, 5900X, 5900XT, 5900, PRO 5945, Ryzen 9 3950X, 3900X, Ryzen 7 3700X, 2700X.

Даёт небольшой прирост с этими процессорами:

• Intel i5-12400, i3-12100, i3-13100, i3-14100, i9-9900K, i7-9700K, i5-9600K, i7-2600K.

• AMD Ryzen 7 9700X, 9700F and Ryzen 5 9600X, 9600, 9500F, Ryzen 7 7700X, 7700, Ryzen 5 7600X, 7600, 7500F, Ryzen 7 5800X, 5800XT, 5700X and Ryzen 5 5600X, 5600, Ryzen 7 8700G, Ryzen 5 8600G, monolithic APU: 9800×3D, 9850×3D, 7800×3D, 5800×3D, 5700×3D, 5600×3D.

Как внедрить ИИ в оптовые продажи: практические сценарии

⏰ Вебинар 15 сентября в 11:00

Приглашаем на вебинар, на котором эксперты департамента e-commerce «КОРУС Консалтинг» разберут практические сценарии внедрения ИИ в оптовые продажи — что стоит оптимизировать в первую очередь, что потребуется для запуска и как измерять результат. 

⚡️Почему это важно сейчас

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

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

• Какие задачи в оптовых продажах уже имеет смысл отдавать ИИ: семь практических сценариев для отдела продаж и личного кабинета клиента

• Как выбрать первый сценарий для своей компании: по каким критериям оценить потенциальный эффект, сложность запуска и необходимость интеграций

• Что потребуется технически: какие решения работают с корпоративными документами и данными, а где нужен доступ к учётным системам

• Ответы на вопросы и разбор ситуации в ваших компаниях в прямом эфире

🎁 Бонус при регистрации

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

➡️ Зарегистрироваться

Исследуем soft skills для инженеров и тимлидов в эпоху AI

Когда-то мы выпускали подкаст про soft skills для SRE — обсуждали, как инженерам прокачивать не только технические, но и человеческие навыки. Тема оказалась настолько живой, что мы решили пойти дальше и разобраться шире: как soft skills инженеров и тимлидов меняются с приходом AI-инструментов в повседневную работу.

Какие навыки становятся важнее, а какие теряют актуальность? Как меняется коммуникация в командах? Где заканчивается зона ответственности человека и начинается зона ответственности модели?

Мы хотим собрать реальную картину от вас, а не строить гипотезы в вакууме.
Если вам близка тема — заполните опрос, это займёт несколько минут.

А если хотите освежить контекст, смотрите выпуск подкаста В SREду на кухне про soft skills для инженера, с которого всё началось:

🔵 VK Видео 
📺 YouTube
📌 RuTube
Ⓜ️ Mave

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

Как частное облако помогло Okko выдержать наплыв зрителей в периоды крупных чемпионатов

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

⚡ Задача
Okko располагал собственной инфраструктурой в Москве и Санкт-Петербурге, необходимо было связать все воедино, обеспечить резервной площадкой и убедиться, что платформа будет работать стабильно даже при взрывном росте аудитории. 

☁️ Что сделали
Используя платформу Cloud.ru Evolution Stack развернули частное облако на 294 хостах, реализовали новую сетевую архитектуру и георезервирование. В качестве резервной площадки выступило публичное облако Cloud.ru. Единство кодовой базы публичного и частного облака обеспечило бесшовное масштабирование и стабильную работу онлайн-кинотеатра при высоких нагрузках. 

🦾 Что получили в итоге
Скорость SDN-компонентов достигла 240 Гбит/с, обеспечены необходимые показатели пропускной способности сети и количества одновременно поддерживаемых пользователей. Собственная инфраструктура кинотеатра показала свою устойчивость в период Олимпийских игр. А во время финала Лиги чемпионов нагрузку подхватило публичное облако, что обеспечило доступ к трансляции для 4,5 млн зрителей. Инфраструктура готова к еще большему масштабированию без изменения архитектуры. 

Все подробности кейса читайте на сайте.

🏆 В рейтинг российских платформ виртуализации CNewsMarket мы попали впервые и сразу заняли третье место!

Эксперты оценивали платформы по функциональности, совместимости, безопасности и надежности. VK Private Cloud набрал внушительные 660 баллов.

Для нас это уже второй заметный результат в этом году. Ранее VK Private Cloud занял первое место в исследовании рынка систем виртуализации TAdviser.

Рады такому старту в рейтинге CNews и продолжаем развивать платформу дальше 💙

❤️ — так держать!👍 — если мы для вас всегда на первом месте

📬 Мы в МАХ

Телематика и топливо: как данные о стиле вождения влияют на экономию

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

В перерасходе можно винить поломки или плохую дорогу, но важным фактором остается манера вождения. Резкий разгон, торможение в последний момент, скорость выше оптимальной – каждое действие разово и само по себе не так страшно. Но вместе они дают устойчивый перерасход, который списывают на маршрут, погоду или возраст техники. Сейчас, когда цены на топливо растут, а доступность ГСМ на маршрутах нестабильна, это уже вопрос рентабельности каждого рейса. На парке в 50 машин плюс 10–15% к расходу превращаются в сотни тысяч рублей в год – просто за то, что никто не смотрел на стиль вождения.

А наша любимая телематика это видит. Технология Eco Driving фиксирует резкие ускорения и торможения, превышения скорости, работу двигателя на повышенных оборотах. Каждое событие – метка на треке со временем, местом и именем водителя. По итогам смены или недели можно составить рейтинг и увидеть, кто пережигает топливо. Данные сами по себе, конечно, ничего не меняют. Дальше начинается самое интересное: что с ними делать. Штрафовать и премировать? При нынешнем рынке кадров терять водителей никто не хочет.

И момент, который обычно упускают: стиль вождения влияет не только на расход. Есть кейс с 89 КАМАЗами в нефтегазовом секторе: после внедрения телематики и контроля режима работы двигателя межсервисный интервал вырос в 2,5 раза. Меньше агрессии за рулём = меньше износ = реже и дешевле ТО. Экономия на обслуживании оказалась сопоставима с экономией на топливе.

В первую очередь, говорю для тех, чья работа связана с грузоперевозками, потому что работаю в основном с тяжелой и спецтехникой. Но вот недавно поставили систему телематики с Eco Driving на легковые машины. Захотелось поделиться одним из первых результатов месяца тестирования: одна и та же машина трижды подряд прошла один замкнутый круг 30,3 км: спокойно, резко и снова спокойно. Одна дорога, один час, один водитель – различается только манера:

спокойно: 6,90 л/100 км, 27 минут;

резко: 13,75 л/100 км, 24 минуты;

спокойно: 6,99 л/100 км, 30 минут.

Резкий круг сжег вдвое больше топлива и выиграл три минуты. Для масштаба: у машины, которая ежедневно ездит по одним и тем же маршрутам, расход от проезда к проезду гуляет на 5–8%. Разница вдвое – это куда больше обычного разброса. Погоды, светофоров или времени суток уже недостаточно, чтобы объяснить.

Ближе к обычной жизни другой замер: две городские поездки подряд по одной дороге (совпадение треков 94%) дали +24% топлива – без всякого показательного «резкого» режима.

Честная оговорка: это один маршрут, одна машина, один водитель. Каждый случай – индивидуальный. Переносить «экономия N%» на весь парк нельзя – для этого нужны повторы на других машинах и в городе. Но порядок цифр на контрасте виден уже сейчас.

*Как считалось: расход – интеграл мгновенного расхода из CAN-шины машины (SPN 183): прибор его измеряет, а не моделирует. Совпадение маршрутов – сравнение треков по клеткам 200×200 м (на кругах 92–95%), старты расходятся не более чем на 30 м, диапазон высот один. Источник – посекундная телеметрия Galileosky из системы мониторинга, времена UTC+5.

Готовлю подробный разбор о работе Eco Driving. Интересно узнать, кто-нибудь сталкивался в работе с контролем стиля вождения?

Почему мои оценки сроков всегда ошибались в одну сторону

Долго не мог понять один паттерн. Задачу оцениваю в три дня - выходит пять. Оцениваю в неделю - выходит две. Причём не случайно, а стабильно в одну сторону. Всегда дольше, никогда быстрее.

Потом разобрался. Дело не в том что я плохо оцениваю конкретную задачу. Дело в том что я оцениваю задачу в вакууме - без учёта всего остального что происходит параллельно.

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

Это называется ошибка планирования. Мозг фокусируется на сценарии где всё идёт по плану. Реальность всегда добавляет помехи которые в оценку не попали.

Два способа которые реально помогли.

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

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

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

Как вы решаете проблему с оценкой сроков - нашли что-то что работает лучше?

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

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

В общем, писать софт для кибербеза с другими дедами мне пока рано. Слишком молодой специалист.

15 бесплатных уроков для тех, кто работает с искусственным интеллектом

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

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

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

LLM и генеративный ИИ

• 3 сентября, 20:00. «Локальные LLM модели для разработки». Записаться

• 8 сентября, 20:00. «Что надо знать про работу LLM моделей». Записаться

• 23 сентября, 18:00. «Structured Outputs: как заставить LLM всегда возвращать то, что вам нужно». Записаться

ИИ‑агенты и искусственный интеллект в разработке

• 14 сентября, 20:00. «ИИ‑агенты против Junior‑разработчиков: кто кого заменит к концу 2026 года». Записаться

• 17 сентября, 20:00. «Обзор ИИ‑технологий для разработчиков. От идей до рабочих решений». Записаться

• 1 октября, 20:00. «Продуктивность разработчика и Agent Skills». Записаться

ML и работа с данными

• 7 сентября, 18:00. «Учимся готовить данные для ML‑моделей». Записаться

• 9 сентября, 18:00. «Оптимизируем построение модели через Pipeline». Записаться

• 10 сентября, 18:00. «Подготовка данных в Pandas». Записаться

• 16 сентября, 18:00. «Задача классификации от 0 до 9». Записаться

• 23 сентября, 18:00. «Дерево решений — простой и интерпретируемый ML‑алгоритм». Записаться

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

• 7 сентября, 20:00. «Почему 90% ML‑проектов не доходят до продакшена? Разбираем архитектуру настоящей ML‑системы». Записаться

• 8 сентября, 20:00. «ИИ против бага: как разобрать инцидент в Python‑проекте от логов до исправления». Записаться

• 21 сентября, 20:00. «Как руководителю внедрить ИИ в работу команды: от выбора процесса до рабочего сценария». Записаться

• 22 сентября, 20:00. «Можно ли доверять ИИ‑коду: как находить галлюцинации, уязвимости и устаревшие решения». Записаться

📚 Что почитать по теме

1. «Промпт, RAG или дообучение: что реально выучит вашу LLM»

2. «Автоматизация процессов на open source — n8n и Ollama»

3. «Как запустить LLM на 2,8 трлн параметров на ноутбуке»

4. «Три месяца с Claude: хороший ассистент, плохой программист»

5. «Как создать своего первого ИИ‑агента за 30 минут»

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

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

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

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

Очень серьезные чечки бегают с большими молотками. Стартаперы — с креативным нечто «похожим на».

Есть ощущение — что нужная вещь! Кто‑то хвастается удачными попаданиями.

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

Вот только… гвоздей пока нет…

Такое ощущение :)

22 «Хагакурэ» Ямамото Цунэтомо

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

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

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

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

Если найдутся авторы, вроде упомянутого уже Райана Холидея, переупаковавшие старые книги в новые, технологичные форматы, то пальцем у виска уже никто крутить не будет, и автора ждёт успех. Потому что мысли и знания на вечные темы, написанные в прошлых веках, не устарели. Более того: ничего особо нового в 20-21 веках и придумано не было. Почему?

Возвращаюсь к упомянутой уже глубине проработки. В те времена жизнь не менялась веками. И были люди, которые могли потратить на размышления и наблюдения половину жизни. Сейчас никто так не может – работать надо. А тот же Цунэтомо мог аккумулировать опыт лет за 500, и этот опыт был воспроизводим – контекст не менялся. Автор мог наблюдать, что в этом мире работает, а что нет, на протяжении жизни нескольких поколений. Поразмышлять об этом часа по 4 в день на протяжении 10-20 лет. Писать книгу лет 10, не переживая о гонорарах и роялти (их всё равно не будет 😊).

Как вам глубина проработки темы? Сейчас хоть один автор так может?

Это 22-я книга из Книжного стека

Самая опасная кнопка в КИИ — у человека за соседним столом

1. Сравнить текущее состояние каталога с резервной копией.

2. Найти точечные расхождения.

3. Восстановить только изменённые объекты, не трогая остальное.

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

Информацию взял отсюда и отсюда.

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

Incident Management: почему компании живут от аварии до аварии

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

В новом выпуске «В SREду на кухне» вместе с Максимом Бурцевым, руководителем отдела мониторинга в e-commerce, разобрали, что отличает команду, которая учится на авариях, от той, что просто их переживает.

Что на повестке

Почему большинство инцидентов случаются сразу после релиза — и при чём тут овертаймы и дежурства. Как работать с Root Cause вместо того, чтобы латать одни и те же дыры по кругу. Кто должен управлять инцидентом в моменте и какие три вопроса нужно задать сразу после аварии. Сколько на самом деле стоит инцидент — и стоит ли рассказывать об этом пользователям. Отдельно — про AI: добавит ли вайб-кодинг новых аварий и может ли AI помочь ими управлять. В Авито уже попробовали — рассказали, что получилось.

🔵 VK Видео 
📺 YouTube
📌 RuTube
Ⓜ️ Mave

Посмотрите этот выпуск, если ваша команда разбирает инциденты по принципу «нашли виноватого, закрыли тикет».

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

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

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

Хорошего дня! заходите на тг канал https://t.me/TradPhronesis

Как фильтровать результат оконных функций в ClickHouse

Когда пишешь SQL-запрос с оконками, часто необходимо сделать фильтрацию по данным, которые они возвращают, например, получить первую строку в каждой группе через ROW_NUMBER(). Для этого приходится оборачивать запрос в подзапрос и уже на уровне внешнего запроса фильтровать данные. Ну, либо использовать CTE.

В ClickHouse можно проще.

Недавно наткнулся на фичу, которая позволяет сделать такую фильтрацию вообще без использования подзапросов или CTE. Это предложение QUALIFY.

Оно работает по аналогии с WHERE, но с одним важным отличием. WHERE отрабатывает до вычисления оконных функций, поэтому оно просто их «не видит», а QUALIFY — после.

Поэтому раньше приходилось писать так:

SELECT * 
FROM (
    SELECT 
        id, 
        category, 
        ROW_NUMBER() OVER(PARTITION BY category ORDER BY created_at DESC) as rn
    FROM my_table
) 
WHERE rn = 1;

А с использованием QUALIFY запрос становится короче:

SELECT 
    id, 
    category, 
    ROW_NUMBER() OVER(PARTITION BY category ORDER BY created_at DESC) as rn
FROM my_table
QUALIFY rn = 1;

Несколько нюансов:

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

• Оконную функцию можно написать прямо внутри QUALIFY. Выводить её в итоговый SELECT не обязательно. Фильтрация всё равно сработает «под капотом».

• Если в запросе нет ни одной оконки, QUALIFY выдаст ошибку. Для обычной фильтрации всё так же используем WHERE.

Ссылка на доку.

Мои статьи по ClickHouse на Хабре.