QFE

Горизонтальное и вертикальное масштабирование Вертикальное масштабирование (Scale Up) — это увеличение мощности одного имеющегося сервера. Вы добавляете на ту же машину больше оперативной памяти, более мощный процессор или объемный диск. Например, обновление домашнего компьютера — вы докупаете и вставляете дополнительную оперативную память, чтобы один ПК справлялся с тяжелыми программами. Горизонтальное масштабирование (Scale Out) — это увеличение количества серверов в системе. Вы не меняете железо на текущей машине, а подключаете новые сервера и распределяете нагрузку между ними. Например, открытие дополнительных касс в супермаркете перед праздниками. Вместо того чтобы заставлять одного кассира работать в пять раз быстрее, магазин открывает еще четыре кассы и делит очередь между ними.

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

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

OIDC Есть отличная статья про OIDC на Хабре — https://habr.com/ru/amp/publications/566910/. А в этом посте я бы хотела написать про разницу между авторизацией и аутентификацией. Если авторизация — это механизм получения нужных прав и доступов, то аутентификация — это этап, на котором приложение убеждается, что это вы. Для OIDC, например, механизмом аутентификации является JWT токен, у которого есть цифровая подпись, которая становится невалидной, когда вы меняете данные пользователя.

Выложил в опенсорс свой агентский пресет для создания документации https://github.com/AlexJameson/agent-user-doc-preset В этом августе исполняется год с момента, когда я впервые показал команде, на что могут быть способны агенты в плане создания документации. Вероятно, это была самая нелепая демонстрация за всю историю — в прямом эфире я в течение нескольких минут набирал промпт, который должен был заменить фрагмент одного регулярного выражения, и ждал окончания работы. В процессе пошло не так абсолютно всё, а результат оказался закоммичен не в ту ветку. С тех пор я многому научился, много сделал сам и помог со множеством запросов, в которых была одна и та же тема — как объяснить агентам, что нужно для создания хорошей доки. Интересно, что этот вопрос беспокоит не только техписов, но и других специалистов — я окончательно решил допилить свой пресет до готового состояния в ходе дискуссии в чате канале Ивана Бегтина. В общем, я сформировал набор из двух скиллов и одного agent definition, которые, на мой взгляд, закрывают минимальные потребности большинства проектов. Я противник подборок типа Superpowers, которые по умолчанию забивают контекст десятками скиллов и целятся во все возможные юзкейсы сразу. Мой пресет работает иначе, создавая фундамент, который можно потом достроить: 1. Самая важная часть пресета — навык scan-user-docs, который анализирует содержимое репозитория и фиксирует контракты в виде Markdown KV. Это обычный маркдаун, в котором есть понятная структура данных, адаптированная для чтения как агентами, так и людьми. При сканировании он определяет размер репозитория и примерный тип, то есть разделяет продуктовую документацию с условными репозиториями с кодом, где дока — один README. Результат записывается в виде трёх контрактов — STRUCTURE.md, TOOLING.md и STYLE.md, которые потом можно расширять и изменять по своему усмотрению. 2. Навык maintain-user-docs призван дать агентам минимальное руководство по тому, как в принципе создавать документацию. Агент с этим навыком пытается сразу определить тип документа, с которым сейчас работает, по топологии Diataxis. В качестве базовых стилистических рекомендаций для русского и английского языков используются отдельные рекомендации в стиле STE100 с примиерами хороших и плохих текстов (можно и нужно добавлять свои примеры). Также переиспользуются контракты, создаваемые scan-user-docs. 3. Последняя часть — primary agent для OpenCode. Он содержит некоторые дополнительные правила и рекомендации, но в целом опционален. Его главная цель — по умолчанию загружать в контекст все контракты. Его рекомендуется адаптировать для своих правил и особенно для других харнесов. Я уверен, что примерно так может выглядеть скелет системы контекста для любого проекта, который в дальнейшем можно развивать и адаптировать. Посмотреть на результат генерации для моего тестового сайта с документацией можно в моем репозитории на SourceCraft. Помимо этого проекта, я запускал генерацию в публичном репозитории Yandex Cloud, в нескольких опенсорсных репозиториях (с той самой докой в README) и даже для своей базы знаний. Модели для агентов тоже использовал разные — точно были GPT-5.6, Kimi K3, Qwen 3.8 27b, и везде получались достаточно полезные результаты. Подробнее обо всех деталях и установке пресета смотрите в репозитории, ну и оставляйте обратную связь!

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

Liveness Probe Пробы — отличный способ следить за работой приложения. Самое интересное — это то, как они работают. В приложении разработчик может предусмотреть API эндпоинт, через который Kubernetes сможет проверять состояние приложения. Это проверка по HTTP. Еще Kubernetes умеет проверять состояние приложения, настраивая TCP соединение или выполняя команду в контейнере. После такой настройки в манифесте Pod Kubernetes может проверять работу приложения и перезапускать под в случае падения приложения.

Forward и reverse proxy Forward Proxy действует в интересах клиента (пользователя): он стоит перед пользователем, скрывает его реальный IP-адрес и отправляет запросы во внешний интернет от своего имени (пример: офисный VPN или корпоративный прокси). Reverse Proxy действует в интересах сервера (бэкенда): он стоит перед группой серверов, принимает все входящие запросы из интернета и сам распределяет их по внутренним узлам, скрывая настоящую архитектуру приложения (пример: Nginx, Cloudflare). Простыми словами: Forward Proxy защищает пользователя от интернета, а Reverse Proxy защищает сервер от пользователей.

TCP и UDP Два протокола, про которые есть миллион мемов в интернете. Протокол TCP проверяет наличие соединения перед отправкой пакетов. Про него еще говорят «трехстороннее рукопожатие». Протокол UDP же не проверяет, поэтому иногда отправка пакетов по UDP выглядит как на картинке.

CI/CD (Continuous Integration / Continuous Delivery) Это подход к разработке ПО, который автоматизирует сборку, тестирование и доставку обновлений приложений. Процесс CI (непрерывная интеграция) автоматически проверяет и тестирует новый код при каждом изменении в Git, чтобы сразу находить баги. Процесс CD (непрерывная доставка) берет проверенный код и автоматически выкатывает его на рабочие сервера. Например, когда разработчик делает новую кнопку на сайте интернет-магазина и отправляет код в репозиторий, система CI/CD за пару минут сама прогоняет автотесты, собирает релиз и обновляет сайт без участия человека и без остановки сервиса. Для настройки таких процессов обычно используют инструменты GitLab CI, GitHub Actions или Jenkins.