McKinsey Global Institute опубликовал доклад, в котором озвучено, что уже сегодня ИИ-агенты и роботы могли бы автоматизировать до 57% всех рабочих часов в США, если компании радикально перестроят процессы. По расчетам аналитиков, под ударом в таком сценарии оказывается около 40% рабочих мест. При этом примерно треть нынешних профессий в США McKinsey относит к труднозаменимым: там критичны физическое присутствие, эмпатия, гибкое мышление и работа в непредсказуемой среде, а главным барьером масштабной автоматизации становятся не технологии, а политика, инвестиции и готовность бизнеса полностью переформатировать рабочие процессы.

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

Зато медсестры, сиделки, персонал по уходу, учителя, а также специалисты по обслуживанию и ремонту выглядят гораздо устойчивее. В таких профессиях значительная доля задач требует (не всегда сразу) физического труда, развитой моторики, эмпатии, наблюдательности и контекстного мышления — то, что современные системы имитируют хуже всего.
https://www.mckinsey.com/mgi/our-research/agents-robots-and-us-skill-partnerships-in-the-age-of-ai

Работа балансировщика нагрузки
(описание в следующем посте)

Работа балансировщика нагрузки
(продолжение предыдущего поста)

Балансировщик нагрузки - один из неотъемлимых компонентов высоконагруженного приложения. Он обеспечивает:
* Распределение нагрузки между серверами для предотвращения перегрузки.
* Высокую доступность за счёт исключения неработающих серверов из обработки запросов.
* Гибкость в маршрутизации запросов (разные пути направляются к разным группам серверов).
* Улучшение пользовательского опыта за счёт быстрого и надёжного обслуживания запросов.

Рассмотрим, как работает балансировщик нагрузки

1. Приём запросов от клиентов (Listener)

Процесс начинается с того, что клиенты (устройства, подключённые к интернету) отправляют запросы на балансировщик нагрузки. Запросы поступают на Listener (прослушиватель), который настроен на определённый порт и протокол (например, HTTP:80). Listener служит «точкой входа» для входящих запросов.

2. Маршрутизация запросов (Routing Rules & Policies)

После приёма запроса балансировщик определяет, куда его направить, используя правила маршрутизации (Routing Rules). Эти правила основаны на различных параметрах:
* путь (Path) в URL (например, /api/* или /images/*);
* хост (Host);
* заголовки (Header) HTTP-запроса.

На изображении показаны два основных правила:
* Rule 1: /api/\*** — направляет запросы, начинающиеся с `/api/`, в **Target Group 1 (API Servers).
* Rule 2: /images/\*** — направляет запросы, начинающиеся с `/images/`, в **Target Group 2 (Image Servers).

3. Распределение нагрузки по целевым группам (Target Groups)

Целевые группы (Target Groups) — это наборы серверов или ресурсов, которые обрабатывают запросы. На изображении есть две целевые группы:
* Target Group 1: API Servers — включает EC2 Instance A, EC2 Instance B и Container C. Обрабатывает API-запросы.
* Target Group 2: Image Servers — включает S3 Bucket и EC2 Instance D. Обрабатывает запросы к изображениям.

Когда запрос соответствует определённому правилу маршрутизации, он перенаправляется в соответствующую целевую группу.

4. Выбор конкретного сервера (алгоритмы балансировки)

Внутри целевой группы балансировщик выбирает конкретный сервер для обработки запроса, используя алгоритмы балансировки нагрузки. Пример алгоритма — Round Robin (циклическое распределение запросов между серверами).

Например, если клиент отправил запрос GET /api/users, процесс будет следующим:
1. Listener принимает запрос на порту 80.
2. Routing Rule определяет, что путь /api/users соответствует правилу /api/*.
3. Запрос перенаправляется в Target Group 1 (API Servers).
4. Балансировщик выбирает, например, EC2 Instance A для обработки запроса (на основе алгоритма Round Robin).
5. EC2 Instance A обрабатывает запрос и возвращает ответ клиенту.

5. Политики (Policies) для повышения надёжности и удобства

Для эффективной работы балансировщика используются политики (Policies):
* Health Checks (проверки работоспособности) — балансировщик регулярно проверяет состояние серверов в целевых группах (например, каждые 30 секунд, Threshold: 2). Если сервер не проходит проверку, он временно исключается из обработки запросов.
* Sticky Sessions (прилипающие сессии) — политика, которая привязывает клиента к одному серверу на время сессии. Это полезно для приложений, где важна непрерывность взаимодействия (например, корзины покупок). На изображении эта политика включена для Target Group 2.

6. Обработка различных типов ресурсов

Балансировщик нагрузки может работать не только с EC2-инстансами, но и с другими ресурсами:
* EC2 Instance — виртуальные машины в облаке.
* Container — контейнеры (например, Docker), которые могут быстро масштабироваться.
* S3 Bucket — хранилище объектов (например, для статических файлов, изображений).

Microsoft представляет будущее, в котором ИИ управляет всем на компьютере. Более того, компания сама активно внедряет ИИ в производственные процессы: ранее в этом году генеральный директор Microsoft Сатья Наделла заявил, что до 30% кода "некоторых проектов" написано ИИ. Однако сами сотрудники Microsoft относятся к внедрению ИИ не столь однозначно.

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

Microsoft заявляет, что 91% её команд разработчиков используют GitHub Copilot, но источники поделились данными, которые свидетельствуют о том, что в некоторых подразделениях компании общий уровень внедрения инструментов ИИ гораздо ниже — ближе к 51% разработчиков, которые сообщили Stack Overflow, что теперь профессионально используют инструменты ИИ каждый день.

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

Один источник в Microsoft рассказал, что некоторые инструменты не так хороши, как их представляют. "ES Chat экономит мне время, потому что я им не пользуюсь", — пошутил собеседник.

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

https://www.theverge.com/tech/831379/microsoft-developer-ai-usage-stats-notepad

Сетевые протоколы, которые работают на разных уровнях сетевой модели OSI
(описание в следующем посте)

Вкратце об уровнях сетевой модели OSI
(продолжение предыдущего поста)

🔌 Уровень 1 — Физический (Physical)

Передаёт необработанные биты по физическим каналам связи.
Протоколы: 10BASE‑T, DSL, ISDN, USB, RS‑232, SONET/SDH.
Устройства: кабели, концентраторы (hubs), повторители (repeaters).

🔗 Уровень 2 — Канальный (Data Link)

Обеспечивает передачу данных между узлами, MAC‑адресацию и формирование кадров.
Протоколы: Ethernet, PPP, STP, VLAN, LLDP.
Устройства: коммутаторы (switches), мосты (bridges).

🗺 Уровень 3 — Сетевой (Network)

Отвечает за маршрутизацию и логическую адресацию.
Протоколы: IPv4/IPv6, OSPF, EIGRP, RIP, MPLS, ICMP, NAT.
Устройства: маршрутизаторы (routers), коммутаторы L3 (L3 switches).

⚙️ Уровень 4 — Транспортный (Transport)

Гарантирует надёжную сквозную передачу данных.
Протоколы: TCP, UDP, SCTP, DCCP.
Ключевые элементы: порты, сегментация, управление потоком (flow control).

📊 Уровень 5 — Сеансовый (Session)

Устанавливает, поддерживает и завершает сеансы связи.
Протоколы: SIP, SMB, RPC, PPTP, TLS.
Ключевые элементы: аутентификация, управление сеансами.

🎛 Уровень 6 — Представительный (Presentation)

Форматирует и преобразует данные для приложений.
Функции: шифрование, сжатие, кодирование данных.
Примеры: шифрование SSL/TLS, JPEG, MP3, ASCII, JSON.

🎨 Уровень 7 — Прикладной (Application)

Предоставляет сервисы непосредственно пользовательским приложениям.
Протоколы: HTTP/S, DNS, DHCP, SSH, SMTP, FTP, SNMP.
Примеры использования: просмотр веб‑страниц, электронная почта, передача файлов.

Вопрос дня

Паттерн Model-View-Controller (Модель‑Представление‑Контроллер или MVC)
(описание в следующем посте)

Паттерн Model-View-Controller (Модель‑Представление‑Контроллер или MVC)
(продолжение предыдущего поста)

→ MVC разделяет приложение на три основных компонента для разграничения ответственностей и повышения удобства сопровождения: Модель, Представление и Контроллер.
→ Представление отвечает за отображение, Контроллер — за обработку ввода и управление потоком, Модель — за данные и бизнес‑правила.

Компоненты

→ Представление (UI) → Отображает данные и обрабатывает взаимодействия пользователя (веб‑страницы, экраны мобильных приложений).
→ Контроллер → Получает ввод от Представления, интерпретирует его, вызывает Модель или обновляет Представление.
→ Модель → Содержит данные приложения и бизнес‑логику; уведомляет Представление об изменениях состояния.
→ База данных / Хранилище → Постоянное хранилище, из которого Модель считывает данные и в которое записывает их.

Поток данных (упрощённо)

→ Представление —(ввод пользователя)→ Контроллер —(вызывает)→ Модель —(считывает/записывает)→ База данных
→ Модель —(уведомляет)→ Представление —(отображает обновлённые данные)→ Пользователь

Преимущества

→ Чёткое разделение ответственностей → упрощение тестирования и параллельной разработки.
→ Повторное использование компонентов — несколько Представлений могут использовать одну и ту же Модель.
→ Более чёткая организация логики интерфейса по сравнению с бизнес‑логикой.

Недостатки

→ Может стать избыточным при большом количестве контроллеров/представлений в крупных приложениях.
→ Возможна тесная связность, если ответственности не разделены чётко.
→ Не всегда оптимально подходит для высокоинтерактивных клиентских интерфейсов без адаптации (например, MVVM или Flux могут быть предпочтительнее).

Распространенные рекомендации по использованию

→ Делайте Контроллеры «лёгкими» — делегируйте бизнес‑логику Моделям или сервисам.
→ Представления без бизнес-логики только для отображения данных и передачи событий
→ Применение шаблона Наблюдатель (observer) или привязки данных, чтобы Представления автоматически обновлялись при изменении Модели.
→ Отедбные юнит‑тесты для Моделей и Контроллеров
→ В крупных проектах организуйте код по функциональным возможностям, а не только по уровням MVC.

Глава Alphabet (Google) Сундар Пичаи сравнил вайб-кодинг с ростом популярности блогов и YouTube, но предупредил, что явление не должно затрагивать критически важные системы.

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

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

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

https://www.techspot.com/news/110434-google-ceo-vibe-coding-reshaping-who-gets-write.html

Вкратце структура ядра Linux #linux

Известный исследователь в области искуственного интеллекта Ян Лекун (Yann LeCun) утверждает, что модели LLM сами по себе не являются пузырем ни в плане стоимости, ни в плане инвестиций — они будут способствовать развитию множества реальных приложений и оправдывать текущие расходы на инфраструктуру.

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

Линус Торвальдс и Линус Себастьян из Linus Tech Tips провели сборку идеального ПК для Linux

Для создания мощной рабочей системы Линусы выбрали:

- процессор CPU AMD Ryzen Threadripper 9960X с 24 ядрами и 48 потоками;

- ОЗУ Kingston 16 ГБ DDR5 х4;

- видеокарту Intel Arc B580;

- материнскую плату GIGABYTE TRX50 AERO D;

- SSD-накопитель Samsung 9100 PRO 2TB;

- кулер Noctua NH-U14S TR5-SP6;

- блок питания Seasonic PRIME TX-1600 1600W 80+ Titanium;

- системный блок Fractal Design Torrent E-ATX Case;

- 31.5-дюймовый монитор Asus ProArt PA32QCV (6K HDR).

Всю сборку выполнил Линус Себастьян, а Торвальдс только пояснял, какие элементы ему больше нравятся (воздушное охлаждение, ECC-память).

https://youtu.be/mfv0V1SxbNA
https://linustechtips.com/topic/1627666-building-the-perfect-linux-pc-with-linus-torvalds/

Механизмы авторизации API
(продолжение к предыдущему посту)

Контроль разрешений пользователей в современных API

1. Управление доступом на основе ролей (RBAC, Role‑Based Access Control)

→ Определение
✓ Назначает разрешения на основе роли пользователя (администратор, редактор, зритель).

→ Как это работает
✓ Пользователи → Назначенные роли → Роли → Предоставление разрешений.

→ Оптимально для
✓ Систем с чётко определёнными группами разрешений.
✓ Панелей управления, SaaS‑приложений, CMS‑платформ.

2. Управление доступом на основе атрибутов (ABAC, Attribute‑Based Access Control)

→ Определение
✓ Принимает решения об авторизации на основе атрибутов.

→ Атрибуты включают
✓ Атрибуты пользователя (возраст, отдел, подписка).
✓ Атрибуты ресурса (тип, владелец).
✓ Атрибуты среды (время, местоположение).

→ Оптимально для
✓ Предприятий с сложными и динамическими правилами доступа.

3. Фреймворк авторизации OAuth 2.0

→ Определение
✓ Делегированная авторизация, которая позволяет сторонним приложениям получать доступ к ресурсам без раскрытия паролей пользователей.

→ Как это работает
✓ Аутентификация через провайдера → Выдача токена доступа → API проверяет токен.

→ Распространённые потоки
✓ Код авторизации (Authorization Code).
✓ Учётные данные клиента (Client Credentials).
✓ Потолок для устройств (Device Flow).

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

4. OpenID Connect (OIDC)

→ Определение
✓ Уровень идентификации, построенный на базе OAuth 2.0.
✓ Добавляет проверку личности пользователя с помощью ID‑токенов.

→ Что предоставляет
✓ Проверенную идентификацию.
✓ Единый вход (SSO, Single Sign‑On).
✓ Стандартные утверждения (имя, электронная почта и т. д.).

→ Оптимально для
✓ Систем аутентификации и авторизации.

5. Авторизация с помощью JSON‑веб‑токенов (JWT, JSON Web Token)

→ Определение
✓ Авторизация осуществляется с помощью подписанных JSON‑токенов.

→ Как это работает
✓ Пользователь входит в систему → Сервер выдаёт JWT, содержащий утверждения → Клиент отправляет токен с каждым запросом.

→ Преимущества
✓ Отсутствие состояния (stateless).
✓ Идеально для распределённых микросервисов.

→ Оптимально для
✓ Мобильных приложений, одностраничных приложений (SPA), современных REST API.

6. Управление доступом на основе политик (PBAC, Policy‑Based Access Control)

→ Определение
✓ Решения о доступе принимаются с использованием централизованных политик.

→ Как это работает
✓ Механизм политик проверяет правила → Разрешает или отклоняет запрос.

→ Оптимально для
✓ Государственных систем.
✓ Среды с жёсткими требованиями соответствия.

7. Списки контроля доступа (ACL, Access Control Lists)

→ Определение
✓ Разрешения настраиваются непосредственно для каждого ресурса.

→ Как это работает
✓ Ресурс содержит список разрешённых пользователей и действий.

→ Оптимально для
✓ Файловых систем.
✓ Моделей безопасности на уровне ресурсов.

Краткое резюме

✓ RBAC → На основе ролей.
✓ ABAC → На основе атрибутов.
✓ OAuth 2.0 → Делегированный доступ.
✓ OIDC → Уровень идентификации.
✓ JWT → Без состояния, на основе токенов.
✓ PBAC → На основе политик.
✓ ACL → На уровне ресурсов.

Вкратце про математические деревья

Линус Торвальдс о резервном копировании данных:

«Только слабаки используют резервное копирование на ленту: настоящие мужчины просто загружают свои важные данные на FTP, и пусть остальной мир их копирует" - Линус Торвальдс, 1996 г., LKML
(Оригинал: "Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it")

«Мой подход к хранению данных таков: я загружаю их в интернет, и если они стоят того, чтобы их сохранить, кто-то другой сохранит их для меня». — Линус Торвальдс, 2025 г., Linus Tech Tips
(Оригинал: "My data storage approach is: I upload it to the internet, and if it's worth saving, somebody else will save it for me.")

Стратегии работы с базами данных
(продолжение в следующем посте)

Стратегии работы с базами данных
(продолжение предыдущего поста)

1. Когда нагрузка на чтение и запись высокая (сбалансированная нагрузка):
* Используйте основную базу данных для всех операций записи.
* Передавайте интенсивный трафик чтения на несколько реплик для чтения через асинхронную репликацию.
* Применяйте кэш Redis для обработки «горячих» ключей и снижения нагрузки на базу данных.
* Учитывайте, что иногда могут возникать промахи кэша (cache miss) — в таких случаях обращение будет перенаправлено к основной базе данных.
* Группируйте операции записи и оптимизируйте индексы, чтобы поддерживать стабильную производительность.

2. Когда нагрузка на запись постоянно растёт:
* Разделите базу данных на шарды (сегменты).
* Каждый шард хранит часть набора данных, благодаря чему операции записи распределяются.
* Ваше приложение должно уметь направлять запросы к нужному шарду.
* Подходит для масштабного развёртывания, но может быть сложным при выполнении комплексных запросов или транзакций между шардами.

3. Когда требуется гибридная масштабируемость (NewSQL):
* Системы вроде CockroachDB работают как SQL, но масштабируются как NoSQL.
* Встроенные функции автоматического шардирования и перераспределения нагрузки избавляют от необходимости вручную управлять шардами.
* Обеспечивается глобальная согласованность данных между узлами.
* Подходит для мультирегиональных приложений, где важны строгая согласованность и отказоустойчивость.

4. Когда требуются операции с высокой степенью надёжности (финансовые операции):
* Система разрабатывается специально для эконом. операций, например, бухгалтерского учёта, платежей...
* Очень высокая скорость работы, устойчивость к сбоям и подход, основанный на формальной верификации.
* В первую очередь обеспечивается корректность — предотвращаются двойные списания, условия гонки и частичные записи.
* Идеально подходит для операций с деньгами, когда каждая транзакция должна быть точной, надёжной и безопасной.