{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Yuriy Gavrilov: posts tagged IT",
    "_rss_description": "Welcome to my personal place for love, peace and happiness 🤖 Yuiry Gavrilov",
    "_rss_language": "en",
    "_itunes_email": "yvgavrilov@gmail.com",
    "_itunes_categories_xml": "",
    "_itunes_image": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic-square@2x.jpg?1643451008",
    "_itunes_explicit": "no",
    "home_page_url": "https:\/\/gavrilov.info\/tags\/it\/",
    "feed_url": "https:\/\/gavrilov.info\/tags\/it\/json\/",
    "icon": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic@2x.jpg?1643451008",
    "authors": [
        {
            "name": "Yuriy Gavrilov - B[u]g - for charity.gavrilov.eth",
            "url": "https:\/\/gavrilov.info\/",
            "avatar": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic@2x.jpg?1643451008"
        }
    ],
    "items": [
        {
            "id": "326",
            "url": "https:\/\/gavrilov.info\/all\/49-megabayt-boli-ekonomika-vrazhdebnogo-veb-dizayna\/",
            "title": "49 Мегабайт Боли: Экономика враждебного веб-дизайна",
            "content_html": "<p>Ссылка на оригинальную публикацию есть тут <a href=\"https:\/\/www.reddit.com\/r\/programming\/comments\/1rv5cb9\/the_49mb_web_page\/\">The 49MB Web Page<\/a>.<\/p>\n<p><b>Опубликовано:<\/b> 12 апреля 2026 г. | <b>Оригинал:<\/b> 12 марта 2026 г.<\/p>\n<p>МненИИе  🤖  <\/p>\n<p>Если бы отвлечение внимания пользователей было олимпийским видом спорта, новостные издания забирали бы все золотые медали. Зайдя на сайт крупного новостного портала вроде New York Times, чтобы просто прочитать пару заголовков, вы столкнетесь с лавиной: 422 сетевых запроса и 49MB загруженных данных. После того как страница наконец-то «успокоится» спустя пару минут, отпадает любой вопрос о том, почему каждый уважающий себя IT-специалист устанавливает блокировщики рекламы на все устройства своих близких.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/image-238.png\" width=\"1080\" height=\"610\" alt=\"\" \/>\n<\/div>\n<p>Чтобы осознать масштаб феномена «49-мегабайтной веб-страницы», давайте вернемся в прошлое. Размер этой страницы превышает объем операционной системы Windows 95 (которая помещалась на 28 дискетах!). В эпоху расцвета iPod стандартный MP3-трек высокого качества (битрейт 192 kbps) занимал около 4-5MB. Таким образом, одна современная статья весит как полноценный музыкальный альбом из 10–12 песен.<\/p>\n<p>Время загрузки в 2006 году ≈ 1.5 Mbps 49 MB×8 бит ≈ 261 секунда<\/p>\n<p>Спустя 20 лет аппаратное обеспечение шагнуло далеко вперед, но современные рекламные технологии (ad-tech) полностью нивелировали этот прогресс своей плохой архитектурой и бесконечным раздуванием кода.<\/p>\n<h4>Почему так происходит? Экономика Hostile Architecture<\/h4>\n<p>Издатели не злодеи, они просто в отчаянии. Попав в «смертельную спираль» programmatic-рекламы, они жертвуют долгосрочной лояльностью читателей ради сиюминутных копеек с показов (CPM). Современная рекламная индустрия разделила создателя контента и рекламодателя.<\/p>\n<p>Каждое враждебное UX-решение проистекает из одной формулы: чем дольше вы заперты на странице взаимодействия, тем выше доход. Ваше разочарование — это их продукт. Мы можем описать общую стоимость взаимодействия (Interaction Cost) как математическую сумму:<\/p>\n<p>C total =∑ ( C mental  + C physical)<\/p>\n<p>Вместо комфортного чтения пользователи сталкиваются с системой, которая максимизирует $C_{total}$, чтобы выжать максимум метрик из человеческого когнитивного ресурса.<\/p>\n<p><summary><strong>Технические детали враждебного дизайна (CLS, Z-Index, Трекинг)<\/strong><\/summary><\/p>\n<ul>\n<li><b>Z-Index Warfare (Предварительная засада):<\/b> При загрузке страницы вас встречает баннер файлов cookie (занимает 30% экрана), затем всплывающее окно «Подпишитесь на рассылку», и одновременно браузер спамит запрос на отправку уведомлений. Доступ к 5 KB текста статьи превращается в полосу препятствий.<\/li>\n<li><b>CLS-катастрофа (Cumulative Layout Shift):<\/b> Вы начали читать, как вдруг текст прыгает на 250 пикселей вниз. Почему? Рекламная сеть завершила фоновые торги и встроила `iframe` над видимой областью. Это вызывает дезориентацию и напрямую ведет к высокому проценту отказов (bounce rate).<\/li>\n<li><b>Невидимые аукционы и перегрузка Mobile CPU:<\/b> Пока вы читаете абзац, браузер вынужден обрабатывать десятки параллельных ставок от `fastlane.json` или систем Amazon. Разбор мегабайтов `JS` монополизирует основной поток браузера.<\/li>\n<li><b>Прилипающие видео и закон Фиттса:<\/b> При прокрутке видео открепляется и закрепляется в углу экрана. Кнопка закрытия «X» делается микроскопической, что нарушает <a href=\"https:\/\/ru.wikipedia.org\/wiki\/Закон_Фиттса\">Закон Фиттса<\/a>, согласно которому время достижения цели зависит от расстояния до нее и ее размера:<br \/>\nT = a + blog 2 ( 1 + WD)<\/li>\n<li><b>Налог на «Толстый палец» (Fat-finger tax):<\/b> Расположение кнопок закрытия вплотную к кликабельной зоне рекламы — это математически просчитанный риск рекламных команд для генерации случайных кликов. Это не баг, это фича.<\/li>\n<\/ul>\n<p><summary><strong>Альтернативные решения для разработчиков<\/strong><\/summary><\/p>\n<p>Если маркетинговая команда настаивает на автовоспроизведении видео, разработчики обязаны использовать `IntersectionObserver`. Это позволит уважать ресурсы пользователя (батарею и CPU) при прокрутке страницы:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">\/\/ Пример базовой реализации для паузы видео вне зоны видимости\nconst videoElement = document.querySelector('video.ads-player');\n\nconst observer = new IntersectionObserver((entries) =&gt; {\n  entries.forEach(entry =&gt; {\n    if (entry.isIntersecting) {\n      videoElement.play();\n    } else {\n      videoElement.pause(); \/\/ Уважаем выбор пользователя!\n    }\n  });\n});\n\nobserver.observe(videoElement);<\/code><\/pre><p>Также шапки сайтов следует скрывать при событии `scrollDown` и показывать только при `scrollUp`, освобождая драгоценное вертикальное пространство на мобильных устройствах.<\/p>\n<hr \/>\n<h3>Критические комментарии к проблеме<\/h3>\n<p>Оригинальная статья поднимает важную проблему UI\/UX, однако дискуссию стоит разбавить долей конструктивной критики:<\/p>\n<ol start=\"1\">\n<li><b>Однобокий взгляд на монетизацию:<\/b> Журналистика стоит денег. Расследования, сервера, зарплаты редакторов — всё это требует финансирования. Падение доходов от печатной прессы заставило издания полагаться на рекламные сети. Хотя 49 MB — это абсурд, сама по себе агрессивная реклама является следствием того, что пользователи массово отказываются платить за подписки (Paywalls).<\/li>\n<li><b>Эффект домино от Ad-blockers:<\/b> Существует парадокс: чем больше продвинутых интернет-пользователей устанавливают блокировщики, тем меньше инвентаря остается у издателя. Чтобы компенсировать потери, издания вынуждены внедрять ещё более агрессивные скрипты и “липкие” видео для оставшейся, менее технически грамотной аудитории.<\/li>\n<li><b>Асинхронность и реальный пользовательский опыт:<\/b> Измерять “зло” веб-страницы исключительно её «боевым весом» (49MB) некорректно. Большинство современных трекеров браузеры загружают асинхронно или отложенно (с атрибутом `defer`). Трудность вызывает не сам объем загружаемых байтов, а именно блокировка главного потока браузера и смещение макета (CLS).<\/li>\n<\/ol>\n<hr \/>\n<h3>Итог<\/h3>\n<p>Современный новостной веб-дизайн оказался в заложниках у метрик. Системы, созданные для вовлечения, трансформировались в «цифровую враждебную архитектуру», доводящую пользователя до ментального истощения. Страницы, превышающие по объему старые операционные системы, использование «тёмных паттернов» (модальные окна, микроскопические крестики закрытия) и беспощадная нагрузка на процессор телефона убивают самое главное — доверие между читателем и изданием.<\/p>\n<p>Создателям контента следует помнить: если пользователь тратит свой когнитивный бюджет на то, чтобы закрыть 4 баннера до прочтения первого слова, никакая «оптимизация конверсии» не заставит его оформить платную подписку. Лучший веб-дизайн — это тот, который уважает время и внимание читателя.<\/p>\n",
            "date_published": "2026-04-12T13:22:50+03:00",
            "date_modified": "2026-04-12T13:21:47+03:00",
            "tags": [
                "IT",
                "Life",
                "Web"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/image-238.png",
            "_date_published_rfc2822": "Sun, 12 Apr 2026 13:22:50 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "326",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "highlight\/highlight.js",
                    "highlight\/highlight.css"
                ],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/image-238.png"
                ]
            }
        },
        {
            "id": "325",
            "url": "https:\/\/gavrilov.info\/all\/ventoy-multizagruzochnaya-fleshka-novogo-pokoleniya\/",
            "title": "Ventoy: Мультизагрузочная флешка нового поколения",
            "content_html": "<p><b><a href=\"https:\/\/www.ventoy.net\">Ventoy<\/a><\/b> — это бесплатная утилита с открытым исходным кодом, которая навсегда изменит ваш подход к созданию загрузочных USB-накопителей. Вместо того чтобы каждый раз форматировать флешку для записи нового образа Windows или Linux, Ventoy позволяет просто копировать файлы образов на накопитель, как на обычную флешку.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-04-12-v-13.00.14.png\" width=\"742\" height=\"222\" alt=\"\" \/>\n<\/div>\n<hr \/>\n<h4>Зачем это нужно?<\/h4>\n<p>Традиционные инструменты (например, Rufus или UltraISO) извлекают содержимое ISO-образа и записывают его на флешку, форматируя её. Если вам нужна другая операционная система, весь процесс приходится повторять.<\/p>\n<p><b>Преимущества Ventoy:<\/b><\/p>\n<ul>\n<li><b>Экономия времени:<\/b> Не нужно форматировать флешку снова и снова. Вы делаете это лишь один раз при установке самого Ventoy.<\/li>\n<li><b>Мультизагрузочность:<\/b> Вы можете закинуть на одну флешку десятки образов (Windows, Ubuntu, различные антивирусные LiveCD, инструменты для восстановления). При загрузке Ventoy покажет удобное меню со списком всех найденных образов.<\/li>\n<li><b>Поддержка форматов:<\/b> Работает не только с ISO, но и с WIM, IMG, VHD(x) и EFI файлами.<\/li>\n<li><b>Сохранение обычных данных:<\/b> Оставшееся свободное место на флешке можно использовать для хранения обычных файлов (документов, фотографий, портативных программ).<\/li>\n<\/ul>\n<hr \/>\n<h4>Как использовать<\/h4>\n<p>Процесс использования максимально прост и состоит из нескольких шагов:<\/p>\n<ol start=\"1\">\n<li><b>Скачивание и установка:<\/b> Скачайте программу с официального сайта и запустите. Выберите вашу флешку в списке и нажмите кнопку `Install` (Установить). <b>Внимание: все данные на флешке будут удалены!<\/b><\/li>\n<li><b>Копирование образов:<\/b> После установки флешка разделится на скрытый загрузочный раздел и видимый раздел для данных. Просто скопируйте нужные вам ISO-файлы (или другие поддерживаемые форматы) в видимый раздел через проводник.<\/li>\n<li><b>Загрузка:<\/b> Вставьте флешку в компьютер, в BIOS\/UEFI выберите загрузку с USB. Появится меню Ventoy, где вы с помощью стрелочек на клавиатуре сможете выбрать нужный образ и запустить его.<\/li>\n<\/ol>\n<hr \/>\n<h4>Какие есть ограничения и особенности?<\/h4>\n<p>Несмотря на всю свою гениальность, у Ventoy есть несколько нюансов, о которых стоит знать:<\/p>\n<p><summary><b>список ограничений<\/b><\/summary><\/p>\n<ul>\n<li><b>Secure Boot (Безопасная загрузка):<\/b> Хотя Ventoy поддерживает Secure Boot, на некоторых компьютерах при первой загрузке может потребоваться ручное добавление ключа сертификата (enroll key). Процесс описан на официальном сайте, но для новичков это может стать небольшим препятствием. Для обхода проблемы Secure Boot в BIOS можно временно отключить.<\/li>\n<li><b>Специфичные ОС:<\/b> Хотя Ventoy тестировался на более чем 1000 различных ISO-образов и поддерживает 99% популярных дистрибутивов, некоторые экзотические или очень старые системы могут не загрузиться корректно.<\/li>\n<li><b>Фрагментация файлов:<\/b> Если вы часто записываете и удаляете образы, они могут фрагментироваться. Ventoy не поддерживает загрузку сильно фрагментированных ISO-файлов на файловой системе exFAT. В таких случаях может потребоваться дефрагментация флешки.<\/li>\n<li><b>Зависимость от BIOS\/UEFI:<\/b> Успешная загрузка иногда зависит от конкретной реализации прошивки материнской платы. Некоторые старые устройства с кривым BIOS могут не распознать загрузчик.<\/li>\n<\/ul>\n<hr \/>\n<h4>Итог<\/h4>\n<p>Ventoy — это инструмент категории “must-have” для системных администраторов, энтузиастов и всех, кому приходится периодически переустанавливать операционные системы или пользоваться загрузочными инструментами. Один раз подготовив такую флешку, вы забудете о рутине с форматированием навсегда.<\/p>\n",
            "date_published": "2026-04-12T12:59:51+03:00",
            "date_modified": "2026-04-12T13:00:47+03:00",
            "tags": [
                "IT",
                "Open Source"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-04-12-v-13.00.14.png",
            "_date_published_rfc2822": "Sun, 12 Apr 2026 12:59:51 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "325",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-04-12-v-13.00.14.png"
                ]
            }
        },
        {
            "id": "313",
            "url": "https:\/\/gavrilov.info\/all\/propuschenny-semestr-kursa-po-kompyuternym-naukam\/",
            "title": "Пропущенный семестр курса по компьютерным наукам",
            "content_html": "<p><a href=\"https:\/\/missing-semester-rus.github.io\">https:\/\/missing-semester-rus.github.io<\/a><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-01-29-v-21.12.57.png\" width=\"1416\" height=\"1186\" alt=\"\" \/>\n<\/div>\n<p>Может кому надо?<\/p>\n",
            "date_published": "2026-01-29T21:14:00+03:00",
            "date_modified": "2026-01-29T21:13:57+03:00",
            "tags": [
                "Edu",
                "IT"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-01-29-v-21.12.57.png",
            "_date_published_rfc2822": "Thu, 29 Jan 2026 21:14:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "313",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-01-29-v-21.12.57.png"
                ]
            }
        },
        {
            "id": "310",
            "url": "https:\/\/gavrilov.info\/all\/bazy-dannyh-v-2025-god-postgresql-ai-agentov-i-sliyaniy\/",
            "title": "Базы данных в 2025: Год PostgreSQL, AI-агентов и слияний",
            "content_html": "<p>2025 год стал поворотным моментом для индустрии баз данных. Мы увидели не просто эволюцию существующих технологий, а фундаментальный сдвиг в том, как приложения взаимодействуют с данными. Эпоха “просто хранения” закончилась — началась эра “интеллектуального взаимодействия” через AI-агентов и глубокую интеграцию векторного поиска.<\/p>\n<p>В этом обзоре мы разберем ключевые события, техно-потери и главные приобретения, сформировавшие ландшафт года.<\/p>\n<p>Оригинал тут: <a href=\"https:\/\/www.cs.cmu.edu\/~pavlo\/blog\/2026\/01\/2025-databases-retrospective.html?utm_source=tldrdev\">https:\/\/www.cs.cmu.edu\/~pavlo\/blog\/2026\/01\/2025-databases-retrospective.html?utm_source=tldrdev<\/a> или на интересном канале <a href=\"https:\/\/t.me\/five_minutes_of_data\">https:\/\/t.me\/five_minutes_of_data<\/a><\/p>\n<hr \/>\n<h3>🚀 Главные тренды 2025 года<\/h3>\n<h4>1. Доминирование PostgreSQL и его экосистемы<\/h4>\n<p>PostgreSQL окончательно закрепил за собой статус “стандарта де-факто”. Выход <b>PostgreSQL 18<\/b> в ноябре 2025 года принес долгожданную подсистему <b>асинхронного ввода-вывода (AIO)<\/b>, что позволяет базе данных меньше зависеть от кэша операционной системы. Также была добавлена поддержка *skip scans*, что значительно ускоряет запросы по B-Tree индексам, даже если пропущены ведущие ключи (префиксы).<\/p>\n<p>Но главный “движ” происходил не в ядре, а вокруг него:<\/p>\n<ul>\n<li><b>Распределенный Postgres:<\/b> В этом году развернулась настоящая битва за горизонтальное масштабирование (шардинг). Проекты вроде <b>Multigres<\/b> (от Supabase) и <b>Neki<\/b> (от PlanetScale) нацелились на решение проблемы масштабирования записи, бросая вызов таким ветеранам, как Citus и YugabyteDB.<\/li>\n<li><b>Война поглощений:<\/b> Крупнейшие игроки скупали Postgres-стартапы. <b>Databricks<\/b> заплатил 1 млрд долларов за <b>Neon<\/b>, а <b>Snowflake<\/b> выложил 250 млн долларов за <b>Crunchy Data<\/b>. Это показывает, что облачные гиганты хотят владеть своими собственными “движками” Postgres, а не просто хостить open-source.<\/li>\n<\/ul>\n<p><details><br \/>\n<summary><b>Подробнее о слияниях и поглощениях (M&A) (спойлер) <\/b><\/summary><\/p>\n<p>Рынок M\\&A в 2025 году был невероятно горячим. Помимо упомянутых сделок с Postgres:<\/p>\n<ul>\n<li><b>IBM<\/b> купила <b>DataStax<\/b> (Cassandra) за ~$3 млрд и <b>Confluent<\/b> (Kafka). IBM явно строит массивный стек для работы с данными в реальном времени.<\/li>\n<li><b>Salesforce<\/b> приобрела ветерана ETL <b>Informatica<\/b> за $8 млрд.<\/li>\n<li><b>Databricks<\/b> также купила <b>Mooncake<\/b> (для работы с Iceberg) и <b>Tecton<\/b> (AI-агенты).<\/li>\n<li><b>Fivetran<\/b> и <b>dbt Labs<\/b> объявили о слиянии, создавая единый мощный ETL\/ELT конгломерат перед выходом на IPO.<br \/>\n<\/details><\/li>\n<\/ul>\n<h4>2. Взлет MCP (Model Context Protocol)<\/h4>\n<p>Если 2023-й был годом векторных индексов, то 2025-й стал годом <b>MCP<\/b> от Anthropic. Это стандартизированный протокол (на базе JSON-RPC), позволяющий LLM взаимодействовать с внешними инструментами и базами данных без написания кастомного связующего кода (glue code).<\/p>\n<p>Практически все вендоры (MongoDB, Neo4j, Redis, Snowflake, ClickHouse) выпустили свои MCP-серверы. Теперь AI-агент может самостоятельно “изучить” схему базы данных и выполнить SQL-запрос.<\/p>\n<blockquote>\n<p><b>Важно:<\/b> Это открывает огромные возможности, но и создает риски безопасности. Агент с правами администратора может случайно выполнить `DROP DATABASE`. Внедрение MCP требует жесткого разграничения прав доступа и использования прокси с защитными механизмами.<\/p>\n<\/blockquote>\n<h4>3. Битва форматов файлов и “Смерть Parquet”?<\/h4>\n<p>Неожиданно обострилась конкуренция в области файловых форматов для аналитики. Старый добрый <b>Parquet<\/b> столкнулся с новыми претендентами: <b>Vortex<\/b> (от SpiralDB), <b>Nimble<\/b> (Meta), <b>Lance<\/b> и другие.<br \/>\nПричина — рост использования GPU для аналитики и необходимость в более быстрых декодерах. Parquet, созданный более 10 лет назад для Hadoop, начинает отставать в эпоху современного “железа” и случайного доступа к данным.<\/p>\n<ul>\n<li>Появление <b>DuckLake<\/b> указывает на попытки переосмыслить архитектуру Data Lakehouse.<\/li>\n<\/ul>\n<h4>4. Рост локальных и Edge баз данных<\/h4>\n<p>На фоне развития <b>Local AI<\/b> (запуск нейросетей на устройствах пользователя) вырос спрос на базы данных, работающие “на краю” (on-device). Такие решения, как <b>Turso<\/b> (на базе libSQL\/SQLite) и оптимизированные версии <b>DuckDB<\/b>, позволяют обрабатывать данные прямо на ноутбуке или смартфоне пользователя, снижая задержки и повышая приватность. AI больше не обязан жить только в облаке.<\/p>\n<hr \/>\n<h3>☠️ Кладбище технологий 2025<\/h3>\n<p>Не все пережили этот год. Рынок безжалостен к тем, кто не нашел свою нишу или бизнес-модель.<\/p>\n<ul>\n<li><b>Voltron Data:<\/b> “Супергруппа” разработчиков (создатели Apache Arrow, Ibis и др.), собравшая $110 млн, не смогла выпустить коммерчески успешный продукт <b>Theseus<\/b> (GPU-ускоренная база). Они закрылись.<\/li>\n<li><b>PostgresML:<\/b> Идея запускать ML прямо внутри Postgres была хорошей, но убедить компании мигрировать на их платформу оказалось сложно.<\/li>\n<li><b>Fauna (прекращение поддержки собственного языка?):<\/b> Хоть компания и жива, игнорирование SQL в начале пути стоило им дорого. В 2025 году стало окончательно ясно: если у тебя нет SQL — ты теряешь рынок.<\/li>\n<li><b>Derby:<\/b> Один из старейших Java-движков (экс-IBM Cloudscape) перешел в режим “read-only” (архивации). Эпоха ушла.<\/li>\n<\/ul>\n<hr \/>\n<h3>🏆 Интересные технические новинки<\/h3>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td style=\"text-align: center\">Технология<\/td>\n<td style=\"text-align: center\">Суть<\/td>\n<td style=\"text-align: center\">Почему это важно<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Multigres \/ Neki<\/b><\/td>\n<td style=\"text-align: center\">Middleware для шардинга PG<\/td>\n<td style=\"text-align: center\">Попытка сделать Postgres таким же масштабируемым, как NoSQL, сохраняя SQL.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Vortex<\/b><\/td>\n<td style=\"text-align: center\">Новый колоночный формат<\/td>\n<td style=\"text-align: center\">Оптимизирован для современного “железа” и векторных операций лучше, чем Parquet.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>pg_vector + DiskANN<\/b><\/td>\n<td style=\"text-align: center\">Векторный поиск<\/td>\n<td style=\"text-align: center\">Алгоритмы приблизительного поиска (ANN) теперь работают с данными, превышающими объем RAM, прямо в Postgres.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>AI-native DBs<\/b><\/td>\n<td style=\"text-align: center\">Встроенный ML<\/td>\n<td style=\"text-align: center\">Базы данных сами становятся хостами для LLM (пример: *PostgreSQL + PL\/Python + локальные модели*).<\/td>\n<\/tr>\n<\/table>\n<h3>🔥 Скандал года: MongoDB против FerretDB<\/h3>\n<p>Судебный иск MongoDB против FerretDB стал самым громким юридическим событием. FerretDB предлагает open-source прокси, который конвертирует запросы MongoDB в SQL для PostgreSQL. MongoDB обвинила их в нарушении прав на торговую марку и патенты.<br \/>\nЭто дело ставит под вопрос саму возможность создания совместимых API. Если Oracle проиграла Google в битве за Java API, то исход битвы за API баз данных пока не ясен.<\/p>\n<hr \/>\n<h3>МненИИе: Что нас ждет в 2026<\/h3>\n<p>*Раздел подготовлен на основе анализа трендов и экстраполяции текущих событий.*<\/p>\n<ol start=\"1\">\n<li><b>“Агентификация” баз данных:<\/b>  <br \/>\nВ 2026 году базы данных перестанут быть пассивными хранилищами. Мы увидим первые промышленные внедрения <b>Autonomous DBA Agents<\/b> — AI-агентов, которые живут внутри базы, сами строят индексы, оптимизируют запросы в реальном времени и даже исправляют простые ошибки в данных без участия человека. MCP станет стандартом для всех Enterprise-решений.<\/li>\n<\/ol>\n<ol start=\"2\">\n<li><b>GPU становится стандартом для OLAP:<\/b>  <br \/>\nНеудача Voltron Data не остановит тренд. Просто GPU-ускорение станет не отдельным продуктом (“GPU Database”), а опцией внутри существующих гигантов (Snowflake, Databricks, PostgreSQL). Запросы будут прозрачно делегироваться на видеокарты там, где это эффективно. Традиционные CPU-only аналитические системы начнут проигрывать в соотношении цена\/производительность.<\/li>\n<\/ol>\n<ol start=\"3\">\n<li><b>Кризис “Open Source” лицензий:<\/b>  <br \/>\nНа фоне исков (как у MongoDB) и желания облачных провайдеров (AWS, Azure) забирать себе всю прибыль от open-source проектов, мы увидим появление новых, более жестких лицензий (наподобие BSL), которые фактически запрещают конкуренцию со стороны облаков, но остаются открытыми для пользователей. Понятие “Open Source” будет размываться в сторону “Source Available”.<\/li>\n<\/ol>\n<ol start=\"4\">\n<li><b>Смерть специализированных векторных баз:<\/b>  <br \/>\nВекторные базы данных как отдельный класс продуктов (Pinecone, Weaviate и т.д.) столкнутся с экзистенциальным кризисом. PostgreSQL, Oracle, MongoDB и Elasticsearch уже интегрировали векторный поиск достаточно хорошо для 95% задач. Большие специализированные игроки будут куплены (как Pinecone готовился к продаже в 2025), а мелкие — исчезнут.<\/li>\n<\/ol>\n<p>2026 год обещает быть годом, когда искусственный интеллект окончательно “поселится” внутри СУБД, а граница между кодом приложения и базой данных станет еще более прозрачной.<\/p>\n",
            "date_published": "2026-01-06T21:07:37+03:00",
            "date_modified": "2026-01-06T21:07:01+03:00",
            "tags": [
                "IT",
                "trends"
            ],
            "_date_published_rfc2822": "Tue, 06 Jan 2026 21:07:37 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "310",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "307",
            "url": "https:\/\/gavrilov.info\/all\/svoy-heroku-doma-zapustil-dokku-doma-i-nakatil-novogodnego\/",
            "title": "Свой Heroku: запустил Dokku дома и накатил новогоднего :)",
            "content_html": "<p>Мы привыкли, что для развертывания веб-приложений нужно платить за VPS или разбираться в дебрях Kubernetes. Но если у вас есть домашний сервер (в моем случае — Asustor), вы можете создать свою собственную PaaS-платформу (Platform as a Service), которая работает по принципу *“git push — и готово”*.<\/p>\n<p>Сегодня я расскажу, как настроить <b>Dokku<\/b> через Portainer, запустить веселое Python-приложение к Новому 2026 году и поделюсь лайфхаками по оптимизации сборки и масштабированию.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-01-01-v-22.53.49.png\" width=\"2546\" height=\"936\" alt=\"\" \/>\n<\/div>\n<hr \/>\n<h3>Часть 1. Фундамент: Запуск Dokku в Portainer<\/h3>\n<p>Dokku — это Docker-контейнер, который управляет другими Docker-контейнерами. Чтобы он заработал на NAS, его нужно правильно запустить. Я использовал Portainer Stack.<\/p>\n<h4>Docker Compose конфигурация<\/h4>\n<p>Вот рабочий `docker-compose.yml`, который решает главную проблему — доступность приложений из локальной сети.<\/p>\n<pre class=\"e2-text-code\"><code class=\"\"># version: '3.2'\nservices:\n  agent:\n    image: dokku\/dokku:${VERSION}\n    pid: host.  # ⚠️ важно для работы на NAS\n    network_mode: bridge # ⚠️ важно для работы на NAS\n    environment:\n      DOKKU_HOSTNAME: ${DOKKU_HOSTNAME}\n      DOKKU_HOST_ROOT: ${DOKKU_HOST_ROOT}\n    volumes:\n      - \/var\/run\/docker.sock:\/var\/run\/docker.sock\n      - ${VOLUME_PATH:-\/var\/lib\/dokku}:\/mnt\/dokku\n    ports:\n      - &quot;3022:22&quot; # ⚠️ важно для работы через ssh и что бы не конфликтовал с 22 \n      - &quot;80:80&quot;    # Внешний порт 80 -&gt; порт 80 внутри контейнера Dokku\n      - &quot;443:443&quot;<\/code><\/pre><p><b>Нюансы сети:<\/b><br \/>\nЧтобы обращаться к приложениям по красивым домегам типа `my-app.dokku.datahub.mother`, я настроил <b>AdGuard Home<\/b> в качестве локального DNS-сервера (фильтры получил бонусом – где-то 20% это всякие счетчики, ужас:). Добавил правило Rewrite: `*.dokku.datahub.mother` → `192.168.0.20` (IP моего NAS). Теперь все поддомены (приложения) автоматически ведут на Dokku.<\/p>\n<p>Также для удобства я настроил `~\/.ssh\/config` на ноутбуке, чтобы не вводить порты вручную:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">Host dokku.datahub.mother\n  HostName 192.168.0.20\n  Port 3022\n  User dokku<\/code><\/pre><p>ну и ключ сам так можно добавить<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">echo &quot;ВАШ_ПУБЛИЧНЫЙ_КЛЮЧ&quot; | dokku ssh-keys:add dokku<\/code><\/pre><hr \/>\n<h3>Часть 2. Приложение “my-first-app”: Новогоднее гадание<\/h3>\n<p>Для теста я написал простое Flask-приложение, которое рассчитывает ваш возраст в наступающем 2026 году.<\/p>\n<h4>Код приложения (`app.py`)<\/h4>\n<pre class=\"e2-text-code\"><code class=\"\">from flask import Flask, request\n\napp = Flask(__name__)\n\n@app.route('\/')\ndef home():\n    return &quot;&quot;&quot;\n    &lt;h1&gt;Приветствую в игре Нового 2026 года! 🎉&lt;\/h1&gt;\n    &lt;p&gt;Это веселая интерактивная игра в честь Нового года. Угадай свой возраст на 1 января 2026!&lt;\/p&gt;\n    &lt;p&gt;Введи свой год рождения:&lt;\/p&gt;\n    &lt;form action=&quot;\/result&quot; method=&quot;get&quot;&gt;\n        &lt;input type=&quot;number&quot; name=&quot;birth_year&quot; min=&quot;1900&quot; max=&quot;2025&quot; required&gt;\n        &lt;button type=&quot;submit&quot;&gt;Угадать возраст на Новогодний 2026!&lt;\/button&gt;\n    &lt;\/form&gt;\n    &quot;&quot;&quot;\n\n@app.route('\/result')\ndef result():\n    birth_year = request.args.get('birth_year')\n    if not birth_year or not birth_year.isdigit():\n        return &quot;Ошибка: введи корректный год рождения!&quot;\n    \n    birth_year = int(birth_year)\n    age_in_2026 = 2026 - birth_year\n    return f&quot;&quot;&quot;\n    &lt;h2&gt;Результат: 🎇&lt;\/h2&gt;\n    &lt;p&gt;В 2026 году тебе будет {age_in_2026} лет!&lt;\/p&gt;\n    &lt;p&gt;Счастливого Нового 2026 года! Пусть все твои желания сбудутся!&lt;\/p&gt;\n    &lt;a href=&quot;\/&quot;&gt;Играть снова&lt;\/a&gt;\n    &quot;&quot;&quot;\n\nif __name__ == '__main__':\n    app.run(host='0.0.0.0', port=5000)<\/code><\/pre><h4>Подготовка к деплою<\/h4>\n<p>Чтобы Dokku понял, как запускать это чудо, нужны два файла в корне проекта:<\/p>\n<ol start=\"1\">\n<li><b>`requirements.txt`<\/b> (зависимости):<\/li>\n<\/ol>\n<pre class=\"e2-text-code\"><code class=\"\">Flask==2.3.2\ngunicorn==20.1.0\nWerkzeug==2.3.3<\/code><\/pre><ol start=\"2\">\n<li><b>`Procfile`<\/b> (команда запуска):<\/li>\n<\/ol>\n<pre class=\"e2-text-code\"><code class=\"\">web: gunicorn app:app --bind 0.0.0.0:5000<\/code><\/pre><ol start=\"3\">\n<li><b>`.python-version`<\/b> (опционально, явная версия Python):<\/li>\n<\/ol>\n<pre class=\"e2-text-code\"><code class=\"\">3.11.14<\/code><\/pre><h4>Процесс деплоя<\/h4>\n<p>Все делается через Git, как на “взрослых” платформах:<\/p>\n<ol start=\"1\">\n<li><b>Создаем приложение на сервере:<\/b><\/li>\n<\/ol>\n<pre class=\"e2-text-code\"><code class=\"\">ssh dokku@dokku.datahub.mother apps:create my-first-app<\/code><\/pre><ol start=\"2\">\n<li><b>Отправляем код:<\/b><\/li>\n<\/ol>\n<pre class=\"e2-text-code\"><code class=\"\">git init\n    git add .\n    git commit -m &quot;Happy New Year 2026 version&quot;\n    git remote add dokku dokku@dokku.datahub.mother:my-first-app\n    git push dokku master<\/code><\/pre><p>Если вы до этого еще что-то деплоили, то лучше проверить куда гит смотрит<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">git remote -v<\/code><\/pre><p>ну и поменяем еще не верное<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">git remote remove dokku<\/code><\/pre><pre class=\"e2-text-code\"><code class=\"\">git init\n    git add .\n    git commit -m &quot;Happy New Year 2026 version&quot;\n    git remote add dokku dokku@dokku.datahub.mother:my-first-app\n    git push dokku master<\/code><\/pre><p>После пуша Dokku сам скачает Python, установит Flask и запустит Gunicorn. Через минуту-две приложение доступно по адресу `<a href=\"http:\/\/my-first-app.dokku.datahub.mother\">http:\/\/my-first-app.dokku.datahub.mother<\/a>`.<\/p>\n<p>Еще нужно домен установить<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">ssh dokku@dokku.datahub.mother domains:set my-first-app my-first-app.dokku.datahub.mother<\/code><\/pre><p>или можно сразу глобально его установить:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">ssh dokku@dokku.datahub.mother domains:set-global dokku.datahub.mother\n# но тогда придется удалить ручную привязку \nssh dokku@dokku.datahub.mother domains:clear my-first-app\n\n# не забыть перебрать nginx ( на всякий случай ) \nssh dokku@dokku.datahub.mother proxy:build-config my-first-app<\/code><\/pre><p>Сертификат сгенерировать<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">ssh dokku@dokku.datahub.mother certs:generate my-first-app my-first-app.dokku.datahub.mother<\/code><\/pre><p>и проверить порты<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">ssh dokku@dokku.datahub.mother ports:report my-first-app<\/code><\/pre><p>если порты не корректные, то можно их установить так:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">ssh dokku@dokku.datahub.mother ports:set my-first-app http:80:5000 https:443:5000<\/code><\/pre><hr \/>\n<h3>Часть 3. Уровень PRO: Скорость (uv) и Marimo<\/h3>\n<p>Аппетит приходит во время еды. После простого Flask-приложения я решил развернуть что-то посерьезнее — Data Science ноутбук на <b>Marimo<\/b>, и столкнулся с реальными сложностями и особенностями. Для примера брал их дело ноутбук <a href=\"https:\/\/marimo.app\">https:\/\/marimo.app<\/a><\/p>\n<h4>1. Ускорение сборки с `uv`<\/h4>\n<p>Стандартный `pip` устанавливает пакеты медленно. Если проект большой, деплой может висеть минутами.<br \/>\nЯ перешел на <b>uv<\/b> — новый менеджер пакетов на Rust.<\/p>\n<p>Вместо `requirements.txt` я использовал `pyproject.toml` и `uv.lock`. Dokku (благодаря современным buildpacks) увидел `uv.lock` и переключился на быстрый режим. Время сборки сократилось <b>в разы<\/b>.<\/p>\n<h4>2. Ловушка масштабирования (Scaling)<\/h4>\n<p>Marimo — это <b>stateful<\/b> приложение (хранит состояние в памяти). Flask, который мы делали выше — <b>stateless<\/b>.<\/p>\n<p>Когда я задеплоил Marimo, Dokku по умолчанию все было хорошо, но потом я решил масштабировать его и сделал так<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">ssh dokku@dokku.datahub.mother ps:scale my-marimo-app web=3<\/code><\/pre><p>далее Dokku запустил <b>3 копии<\/b> контейнера (`web=3`).<br \/>\nНачался хаос:<\/p>\n<ul>\n<li>Интерфейс открывался.<\/li>\n<li>При нажатии кнопок вылетала ошибка `Invalid server token`.<\/li>\n<\/ul>\n<p><b>Почему?<\/b> Браузер загружал страницу с *Контейнера 1*, а WebSocket-запрос улетал в *Контейнер 2*, который ничего не знал про мою сессию.<\/p>\n<p><b>Решение:<\/b><br \/>\nДля интерактивных приложений (Streamlit, Marimo, Jupyter) всегда принудительно ставьте одну реплику:<br \/>\nНу ли придется делать липкие сессии на nginx или еще что-то.<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">ssh dokku.datahub.mother ps:scale my-marimo-app web=1 # все вернуло в рабочее состояние.<\/code><\/pre><p>А если не хватает мощности — лучше дайте этому единственному контейнеру больше ресурсов, чем пытаться плодить клонов или дайте каждому запускать свой:<\/p>\n<p>Вот так можно установить лимиты или повысить их:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">ssh dokku.datahub.mother resource:limit my-marimo-app --memory 2G --cpu 2<\/code><\/pre><h4>3. SSL в локальной сети<\/h4>\n<p>Браузеры блокируют микрофон и иногда WebSockets на HTTP-сайтах. Для локальной сети Let’s Encrypt не сработает (нет публичного IP), ну и его чуть сложнее запускать.<br \/>\nЯ решил вопрос генерацией самоподписанного сертификата одной командой Dokku:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">ssh dokku.datahub.mother certs:generate my-first-app my-first-app.dokku.datahub.mother<\/code><\/pre><p>Браузер ругается, но приложение работает полноценно.<\/p>\n<hr \/>\n<p>Еще я прогнал стресс тесты<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">ab -n 10000 -k -c 2000 ...<\/code><\/pre><p>Много они не показали, решением было подкрутить nginx, настроить кеш ssl, горизонтальное масштабирование не приносило больших результатов. я упирался в ограничения клиента при тестах нагрузки.<\/p>\n<h3>Итог<\/h3>\n<p>Dokku на домашнем сервере — это отличный инструмент.<\/p>\n<ul>\n<li><b>Для простых API (Flask\/FastAPI):<\/b> Работает “из коробки” идеально.<\/li>\n<li><b>Для сложных задач:<\/b> Использование `uv` делает работу комфортной, а понимание разницы между *Stateless* и *Stateful* приложениями спасает от занудных ошибок и отладки.<\/li>\n<\/ul>\n<p>Теперь my-first-app готово предсказывать возраст всем гостям на Новый год, а сервер готов к новым экспериментам! 🎄 Пожалуй оставлю его для будущих экспериментов. Прижился как-то быстро. Кстати у Dokku есть коммерческая PRO версия, а точнее не версия, а полноценный UI с кнопочками и стоит он 900$. <a href=\"https:\/\/dokku.com\/docs\/enterprise\/pro\/\">https:\/\/dokku.com\/docs\/enterprise\/pro\/<\/a><\/p>\n<p>Пора чего-нибудь накатить новогоднего еще :)<\/p>\n",
            "date_published": "2026-01-01T22:59:46+03:00",
            "date_modified": "2026-01-05T13:51:37+03:00",
            "tags": [
                "Dev",
                "DevOps",
                "IT",
                "Management"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-01-01-v-22.56.17.png",
            "_date_published_rfc2822": "Thu, 01 Jan 2026 22:59:46 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "307",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "highlight\/highlight.js",
                    "highlight\/highlight.css"
                ],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-01-01-v-22.56.17.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-01-01-v-22.53.49.png"
                ]
            }
        },
        {
            "id": "288",
            "url": "https:\/\/gavrilov.info\/all\/bar-is-sooooooooo-high-platform-takes-the-pain\/",
            "title": "Bar is sooooooooo high – Platform Takes The Pain",
            "content_html": "<h2>Часть 1: “Bar is sooooooooo high” – <a href=\"https:\/\/nekrolm.github.io\/blog.html\">https:\/\/nekrolm.github.io\/blog.html<\/a><\/h2>\n<p>Это исповедь инженера, уволившегося из Amazon Web Services (AWS) после трех лет работы. Основная причина — чудовищный стресс и выгорание, вызванные спецификой корпоративной культуры и рабочих процессов, несмотря на престижность компании (FAANG) и высокую компенсацию.<\/p>\n<h3>Учим английские выражения и их значение в контексте статьи, любопытно<\/h3>\n<ul>\n<li><b>`Bar is sooooooooo high`<\/b>: “Планка неимоверно высока”. Означает, что требования для повышения (промоушена) настолько завышены, что достичь их практически невозможно, даже если ты уже выполняешь работу на следующем уровне. Это создает ощущение бега на месте.<\/li>\n<li><b>`RSU (Restricted Stock Units)`<\/b>: Акции компании, которые выдаются сотруднику, но он получает их не сразу, а по частям в течение нескольких лет. Это способ удержания ценных кадров. Автор отказался от ~£100k, не дождавшись очередного получения акций.<\/li>\n<li><b>`FAANG`<\/b>: Акроним для гигантов технологической индустрии: Facebook (теперь Meta), Amazon, Apple, Netflix, Google. Символ престижной и высокооплачиваемой работы в IT.<\/li>\n<li><b>`Return-to-office`<\/b>: “Возвращение в офис”. Политика компании, обязывающая сотрудников работать из офиса определенное количество дней в неделю.<\/li>\n<li><b>`Oncall`<\/b>: “Дежурство”. Период, когда инженер должен быть доступен 24\/7 для решения экстренных проблем с продакшн-системами. В статье это источник огромного стресса из-за сложности системы и широкого круга обязанностей.<\/li>\n<li><b>`Leadership Principles`<\/b>: “Принципы лидерства”. 16 “заповедей” Amazon, которые должны направлять поведение сотрудников. Автор иронично использует их, чтобы показать, как в реальности они превращаются в инструменты бюрократии и давления.<\/li>\n<li><b>`Receive shouldertaps`<\/b>: “Получать ‘похлопывания по плечу’”. Метафора, означающая постоянные отвлечения, прерывания и запросы от коллег и менеджеров, которые мешают сосредоточиться на основной задаче.<\/li>\n<li><b>`Let’s keep rollout aside`<\/b>: “Давайте пока не будем думать о раскатке”. Фраза менеджера, которая говорит о том, что процесс релиза настолько сложный, долгий (от месяца до года) и рискованный, что его даже не пытаются планировать и оценивать.<\/li>\n<li><b>`Customer Obsession`<\/b>: “Одержимость клиентом”. Один из принципов лидерства. В статье показана его гипертрофированная форма, когда нужно реагировать даже на падение одного запроса из миллиона.<\/li>\n<li><b>`Correction-of-errors document (COE)`<\/b>: Документ с разбором ошибок. Его написание и защита перед высшим руководством — крайне неприятная процедура после любого сбоя.<\/li>\n<li><b>`Bar Rising`<\/b>: “Поднятие планки”. Процесс ревью и “прожарки” на митингах, где любая идея подвергается шквалу критики и сомнений, что ведет к выработке синдрома самозванца. пс: у кого-то “паяльники” рабочий инструмент, а у матерых компаний “градусники для мяса”. 🤣 Что поделать, идут дальше, контролируют степень “прожарки” в виде ежедневных опросов, что бы не подгорало.<\/li>\n<li><b>`Ownership`, `Operational Excellence`<\/b>: Другие принципы лидерства, которые на практике означают, что дежурный инженер несет полную ответственность за гигантскую и запутанную систему.<\/li>\n<li><b>`In pain`<\/b>: “Страдает”. Эмоционально окрашенный термин для описания клиента с проблемой, используемый для создания срочности.<\/li>\n<li><b>`Disagree and Commute`<\/b>: “Не согласен, но езди в офис”. Ироничная переделка принципа `Disagree and Commit` (“Не согласен, но поддерживай решение”). Отражает отношение к принудительному возвращению в офис.<\/li>\n<li><b>`GenAI`<\/b>: Генеративный Искусственный Интеллект. Автор описывает неадекватную истерию вокруг этой темы в компании.<\/li>\n<li><b>`Bellow benchmarks`<\/b>: “Ниже эталонных показателей”. Результат анонимных опросов удовлетворенности, который показывает, что команда недовольна, и приводит к игре в “мафию” — поиску виноватых.<\/li>\n<\/ul>\n<p>Любопытна эта эмоциональная окраска, сейчас все продают эмоции, а тут уже их в процесс включают. Как думаете она помогает или истощает?<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/IMG_6D8AFAB994AA-1.jpeg\" width=\"1170\" height=\"724\" alt=\"\" \/>\n<\/div>\n<p>Футбол кстати вовлекает 40% населения, а количество зрителей финала чемпионата может достигать 1,5 млрд. человек.<\/p>\n<p>Стоимость бренда UFC – 4 млрд$, но цифра уже устарела, 11 дек. 2024 г. — $10 миллиардов, — Глава UFC оценил, а в августе этого года Paramount приобрела права на трансляцию UFC за $7,7 млрд. Сейчас оценка где-то 11млрд. За один просмотр выручка c трансляции одного боя может достигать 180$ млн.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/IMG_C3074AF26DC8-1.jpeg\" width=\"1170\" height=\"766\" alt=\"\" \/>\n<\/div>\n<p>А вот Люк как запомнился, “Он говорил на языке страсти, а не KPI”<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-10-24-v-00.05.49.png\" width=\"330\" height=\"330\" alt=\"\" \/>\n<\/div>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-10-24-v-00.06.56.png\" width=\"1370\" height=\"288\" alt=\"\" \/>\n<\/div>\n<p>Ну вы все уже знаете. 81 сервис пострадал, +800 компаний где-то, даже медиум лежал.<\/p>\n<p>Облака, белогривые лошадки,<br \/>\nОблака, что вы мчитесь без оглядки<br \/>\nНе смотрите вы пожалуйста свысока,<br \/>\nА по небу прокатите нас облака... Трям! Здравствуйте!»))<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-10-24-v-00.10.54.png\" width=\"672\" height=\"382\" alt=\"\" \/>\n<\/div>\n<hr \/>\n<h3>Рецепт выгорания от Amazon или почему “планка так высока”<\/h3>\n<p>Крик души Дмитрия — это не просто рассказ об увольнении, а детальный разбор полетов корпоративной машины, где престиж и высокая зарплата становятся недостаточной компенсацией за системный стресс. Автор, проработав три года в AWS, уходит, отказавшись от солидной суммы. Что же пошло не так?<\/p>\n<p>Причина кроется в самой культуре, парадоксальным образом описанной через знаменитые `Leadership Principles` Amazon. Принцип `Insist on Highest Standards` (“Настаивайте на высочайших стандартах”) на практике превращается в бюрократическую “прожарку” (`Bar Rising`), где любая инициатива тонет в бесконечных согласованиях и документах. Чтобы выпустить даже небольшое изменение, нужно “просмотреть все варианты будущего”, как Доктор Стрэндж, и защитить свое решение перед армией сомневающихся.<\/p>\n<p>Вершиной этой культуры становится процесс релиза. Фраза менеджера `Let’s keep rollout aside` говорит сама за себя: раскатка изменений в продукте, через который проходит 30% интернет-трафика, — это настолько болезненный и непредсказуемый процесс, что его предпочитают даже не обсуждать. Проект, сделанный за 2 недели, может добираться до пользователей полтора года. Как пишет автор, это лучший рецепт для выгорания: “Заставьте программистов писать код, не дайте им увидеть результат и при этом дергайте их в разные стороны”.<\/p>\n<p>Эти “подергивания” (`shouldertaps`) — еще один гвоздь в крышку гроба мотивации. Дежурства (`oncall`) превращают инженера в универсального солдата, который должен ориентироваться в сотнях дашбордов, десятках видов логов и нести `Ownership` за все, что происходит. При этом `Customer Obsession` доходит до абсурда: приходится разбираться с падением одного запроса из миллиона, потому что клиент `in pain`.<\/p>\n<p>На фоне этого — постоянные увольнения, принудительное “возвращение в офис” (`Disagree and Commute`) и неадекватная `GenAI`-истерия. В итоге “планка” (`bar is so high`) для карьерного роста оказывается не стимулом, а стеной, о которую разбиваются амбиции. Это история о том, как система, созданная для минимизации рисков в огромном масштабе, начинает пожирать человеческий ресурс, превращая талантливых инженеров в выгоревших статистов.<\/p>\n<hr \/>\n<h3>Стихотворение в стиле АЙ да Пушкина :)  🤖<\/h3>\n<p>Три года в царстве AWS,<br \/>\nГде каждый день — суровый стресс.<br \/>\nПрощай, гигант, твой дом высок,<br \/>\nНо дух мой страждет и продрог.<\/p>\n<p>Чтоб строчку кода в мир пустить,<br \/>\nТрактат надобно сочинить.<br \/>\nНа том совете господа<br \/>\nТебя осудят без труда.<\/p>\n<p>“А точно ль цель сия верна?<br \/>\nВся ль сложность вами учтена?”<br \/>\nИдёт полгода, год второй,<br \/>\nА код твой спит, еще не в строй.<\/p>\n<p>Дежурства мрак, клиент “in pain”,<br \/>\nИ кашель рвёт грудину мне.<br \/>\nИ планка та, что так горда,<br \/>\nЛишь множит горе и года.<\/p>\n<p>Оставлю акций бренный звон,<br \/>\nПокину сей хрустальный трон.<br \/>\nСвободным быть — вот мой удел,<br \/>\nПрощай, Amazon, я улетел.<\/p>\n<hr \/>\n<h2>Часть 2: О статье про Spotify (“Platform Takes The Pain”)<\/h2>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-10-23-v-23.52.48.png\" width=\"1410\" height=\"440\" alt=\"\" \/>\n<\/div>\n<p>Эта статья, основанная на подкасте <a href=\"https:\/\/corecursive.com\/platform-takes-the-pain\">corecursive.com<\/a>, рассказывает о внутренней трансформации Spotify на пути от хаотичного стартапа в стадии гиперроста до зрелой технологической компании. Это история о том, как им удалось навести порядок, не убив свою знаменитую культуру автономии.<\/p>\n<h3>Суть и смысл статьи<\/h3>\n<p>Основная идея — Spotify столкнулся с проблемой масштабирования. Их культура полной автономии команд, где каждая сама отвечала за свой конвейер сборки и доставки (CI\/CD), привела к хаосу: более 300 команд использовали 200+ разных, небезопасных версий CI-системы Jenkins. Перед выходом на IPO аудиторы указали на это как на серьезный риск.<\/p>\n<p>Компании нужно было за 6 месяцев стандартизировать CI, но как это сделать, не нарушив главный принцип — автономию инженеров, которые не хотели, чтобы им что-то навязывали “сверху”?<\/p>\n<p>Решением стала смена парадигмы в работе платформенных команд под лозунгом <b>`Platform Takes The Pain`<\/b> (“Платформа забирает боль на себя”).<\/p>\n<h3>Устройство, культура и особенности Spotify<\/h3>\n<ol start=\"1\">\n<li><b>Культура “старого” Spotify (до трансформации):<\/b>\n<ul>\n  <li><b>Хорошо:<\/b>\n<ul>\n    <li><b>Полная автономия:<\/b> Команды (`squads`) были абсолютно независимы, что давало им чувство сопричастности и ускоряло принятие решений в малом масштабе.<\/li>\n    <li><b>Сильная идентичность:<\/b> У каждой команды была своя “комната” (`squad room`), оформленная в уникальном стиле, что создавало сильную командную связь.<\/li>\n    <li><b>Скорость и гениальные инженеры:<\/b> В компании были “звёзды” (“employee number 10”), которые могли писать код день и ночь и знали всё об инфраструктуре.<\/li>\n  <\/ul>\n<\/li>\n  <li><b>Не очень:<\/b>\n<ul>\n    <li><b>Хаос и фрагментация:<\/b> Более 200 CI-систем — яркий пример. Это приводило к дублированию работы и уязвимостям.<\/li>\n    <li><b>“Rumor Driven Development” (“Разработка, основанная на слухах”):<\/b> Чтобы что-то узнать, нужно было “похлопать по плечу” нужного человека. Не было единого источника информации, что замедляло новичков и приводило к созданию костылей.<\/li>\n    <li><b>Проблемы с онбордингом:<\/b> Новичку требовалось более 60 дней, чтобы сделать свои первые 10 Pull Request.<\/li>\n    <li><b>Хрупкость:<\/b> Если ключевой инженер уходил в отпуск, система могла остаться без поддержки.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<ol start=\"2\">\n<li><b>Трансформация и новая культура:<\/b>\n<ul>\n  <li><b>Мантра `Platform Takes the Pain`:<\/b> Платформенные команды перестали быть просто создателями инструментов “в стол”. Они стали сервис-провайдером для внутренних клиентов — других команд разработчиков. Их новой задачей стало не просто создать инструмент, а <b>взять на себя ответственность за его внедрение (`adoption`)<\/b>. Они приходили в команды и помогали им мигрировать, забирая на себя самую нудную и сложную работу.<\/li>\n  <li><b>`Backstage` — решение проблемы “слухов”:<\/b> Чтобы победить `Rumor Driven Development`, Spotify создали единый портал для разработчиков — `Backstage` <a href=\"https:\/\/engineering.atspotify.com\/2021\/05\/a-product-story-the-lessons-of-backstage-and-spotifys-autonomous-culture\">engineering.atspotify.com<\/a>.\n<ul>\n    <li><b>Устройство:<\/b> Это центральный каталог, где можно найти информацию о любом сервисе, его владельце, документации, API и дежурном инженере.<\/li>\n    <li><b>Главная особенность:<\/b> `Backstage` построен на <b>плагинах<\/b>. Это значит, что центральная команда не стала “бутылочным горлышком”. Любая команда может написать свой плагин для `Backstage`, чтобы добавить нужную ей функциональность. Это гениальное решение, которое <b>централизует информацию, но децентрализует владение и развитие платформы<\/b>.<\/li>\n  <\/ul>\n<\/li>\n  <li><b>Переосмысление автономии:<\/b> В Spotify поняли, что автономия ради автономии бессмысленна. Настоящая цель автономии — <b>влияние (`impact`)<\/b>. Если команда автономна, но изолирована и ее работа не приносит пользы, это плохая автономия. Новые стандарты и инструменты вроде `Backstage` не убили автономию, а, наоборот, дали командам больше влияния, убрав рутину и упростив взаимодействие.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p>*На Backstage кстати можно строить порталы IDP <a href=\"https:\/\/internaldeveloperplatform.org\/what-is-an-internal-developer-platform\/\">https:\/\/internaldeveloperplatform.org\/what-is-an-internal-developer-platform\/<\/a><\/p>\n<h3>Чем Spotify отличается от других (например, от Amazon из первой статьи)?<\/h3>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td style=\"text-align: center\">Аспект<\/td>\n<td style=\"text-align: center\">Amazon (согласно статье)<\/td>\n<td style=\"text-align: center\">Spotify (согласно статье)<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Процесс<\/b><\/td>\n<td style=\"text-align: center\"><b>Процесс — это цель.<\/b> Бюрократия и избегание рисков приводят к параличу. Релизы длятся годами.<\/td>\n<td style=\"text-align: center\"><b>Процесс — это средство.<\/b> Цель — скорость итераций. Узкие места (bottlenecks) активно устраняются.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Автономия<\/b><\/td>\n<td style=\"text-align: center\"><b>Индивидуальная ответственность (`Ownership`)<\/b>, которая часто превращается в поиск виноватого.<\/td>\n<td style=\"text-align: center\"><b>Командная автономия, нацеленная на результат (`impact`)<\/b>. Баланс между свободой и общими стандартами.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Платформа<\/b><\/td>\n<td style=\"text-align: center\">Не описано, но похоже на набор сложных инструментов, за которые ты сам несешь ответственность.<\/td>\n<td style=\"text-align: center\"><b>Платформа как сервис (`Platform takes the pain`).<\/b> Платформенные команды — помощники, а не надзиратели.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Культура<\/b><\/td>\n<td style=\"text-align: center\"><b>Top-down (сверху-вниз).<\/b> Жесткие принципы, которые могут использоваться для давления. Страх ошибки.<\/td>\n<td style=\"text-align: center\"><b>Bottom-up (снизу-вверх).<\/b> Культура эволюционировала в ответ на реальные проблемы. Поощрение экспериментов и “быстрых провалов”.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: right\"><b>Информация<\/b><\/td>\n<td style=\"text-align: center\">Скрыта в тысячах репозиториев и устаревших вики. Огромный контекст, который невозможно удержать.<\/td>\n<td style=\"text-align: center\"><b>Централизована и доступна<\/b> через `Backstage`. Прозрачность — один из ключевых принципов.<\/td>\n<\/tr>\n<\/table>\n<h3>Итоги<\/h3>\n<p>История Spotify — это блестящий пример того, как крупная технологическая компания может преодолеть болезни роста, не превратившись в бездушную корпорацию в духе Amazon из первой статьи. Они нашли золотую середину между хаосом полной свободы и параличом тотального контроля.<\/p>\n<p><b>Основные выводы:<\/b><\/p>\n<ol start=\"1\">\n<li><b>Платформа должна служить разработчикам, а не диктовать им условия.<\/b> Модель `Platform Takes The Pain` — это то, чему стоит поучиться многим компаниям.<\/li>\n<li><b>Централизуйте информацию, а не контроль.<\/b> Инструмент вроде `Backstage` с плагинной архитектурой — мощное решение для сохранения скорости и автономии в большом масштабе.<\/li>\n<li><b>Культура не высечена в камне.<\/b> Она должна адаптироваться к размеру и задачам компании. Spotify смогли переосмыслить “автономию”, привязав её к реальному влиянию на продукт.<\/li>\n<\/ol>\n<p>Для компаний, стремящихся к росту, опыт Spotify<\/p>\n<p><a href=\"https:\/\/www.sciencedirect.com\/science\/article\/pii\/S0164121223000444\">sciencedirect.com<\/a> — это дорожная карта по построению эффективной и при этом человечной инженерной организации. А для инженеров, выбирающих место работы, это маркер здоровой культуры: ищите компании, которые борются с трением, а не создают его. Как говорится, если в компании есть свой `Backstage` — это хороший знак. Если же там “let’s keep rollout aside” — возможно, стоит бежать.<\/p>\n<h3>Если коротко – оригинал по ссылке выше<\/h3>\n<p>В статье анализируется организационная модель Spotify, которая позволяет предоставлять высокую степень автономии сотням команд разработчиков (называемых «сквадами», или `squads`) и при этом эффективно координировать их работу в масштабах всей компании.<\/p>\n<p>Авторы утверждают, что масштабируемая автономия в Spotify — это не анархия. Это тщательно продуманная система, в которой свобода команд уравновешивается механизмами, обеспечивающими согласованность действий и общую ответственность. Сквады, задуманные как «мини-стартапы», имеют право самостоятельно принимать большинство решений, касающихся их работы: как разрабатывать, какие процессы использовать, как отслеживать свой прогресс.<\/p>\n<p>Однако эта свобода существует в рамках так называемых «благоприятствующих ограничений» (`enabling constraints`). Эти ограничения — не приказы сверху, а скорее общие правила и инструменты, которые помогают командам работать слаженно, не создавая хаоса. Исследование основано на ретроспективах с командами, интервью с менеджерами и анализе внутренних данных Spotify.<\/p>\n<h3>Основные рекомендации и стратегии, применяемые в Spotify<\/h3>\n<p>Для достижения баланса между автономией и согласованностью Spotify использует несколько ключевых стратегий:<\/p>\n<ol start=\"1\">\n<li><b>Выравнивание (Alignment) вместо контроля:<\/b> Вместо того чтобы указывать командам, *что* и *как* делать, компания создает условия для естественной синхронизации.\n<ul>\n  <li><b>`TechRadar` (Технологический радар):<\/b> Это централизованный, но коллективно управляемый список одобренных технологий, языков программирования и фреймворков. Команды не могут использовать абсолютно любую технологию, что упрощает поддержку, обмен инженерами и совместную работу над кодом.<\/li>\n  <li><b>Запросы на комментарии (`RFCs – Requests for Comments`):<\/b> Для крупных изменений, затрагивающих несколько команд, используется формальный процесс RFC. Это позволяет собрать обратную связь и достичь консенсуса до начала реализации.<\/li>\n  <li><b>«Золотые пути» (`Golden Paths`):<\/b> Это готовые шаблоны и руководства для выполнения стандартных задач (например, создание нового микросервиса). Это снижает когнитивную нагрузку на инженеров и обеспечивает единообразие.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<ol start=\"2\">\n<li><b>Управление общей кодовой базой:<\/b>\n<ul>\n  <li><b>«Слабое владение кодом» (`Weak Code Ownership`):<\/b> У каждого компонента кода есть команда-владелец, но любая другая команда может предлагать изменения через пул-реквесты (`Pull Requests`). Команда-владелец обязана рассмотреть эти изменения. Это предотвращает возникновение «узких мест» и поощряет коллективную ответственность за продукт.<\/li>\n  <li><b>Самостоятельное управление зависимостями:<\/b> Команды могут договариваться между собой и передавать владение кодовыми репозиториями, чтобы уменьшить зависимости и ускорить свою работу.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<ol start=\"3\">\n<li><b>Сетевые структуры и обмен знаниями:<\/b> Компания активно развивает горизонтальные связи, минуя формальную иерархию.\n<ul>\n  <li><b>Гильдии (`Guilds`):<\/b> Это добровольные сообщества по интересам (например, гильдия веб-разработчиков или гильдия по качеству). Они служат для обмена знаниями, выработки лучших практик и решения общих проблем.<\/li>\n  <li><b>Культура взаимопомощи и внутренние инструменты:<\/b> Использование корпоративного Slack и внутреннего аналога Stack Overflow поощряет открытый обмен информацией. Репутация инженера или команды отчасти зависит от их готовности помогать другим.<\/li>\n  <li><b>«Встраивание» (`Embedding`):<\/b> Практика временного (до трех месяцев) «одалживания» инженеров между командами. Это помогает быстро передавать экспертизу, решать проблемы с зависимостями и укреплять социальные связи.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<h4>Что выходит?<\/h4>\n<ul>\n<li><b>Масштабируемая автономия возможна и эффективна.<\/b> Модель Spotify доказывает, что можно предоставить командам значительную свободу даже в очень крупной организации. Ключ к успеху — в способности команд к самоорганизации, сотрудничеству и коллективному принятию решений.<\/li>\n<li><b>Автономия требует ответственности и согласованности.<\/b> Свобода не работает без «благоприятствующих ограничений». Именно эти рамки позволяют всей системе оставаться управляемой и двигаться в одном направлении.<\/li>\n<li><b>Основные барьеры для автономии не всегда связаны с менеджментом.<\/b> Главными препятствиями являются технические и организационные зависимости между командами, недостаточная зрелость самих команд (неумение управлять своими процессами) и нехватка нужных компетенций.<\/li>\n<li><b>Существует «цепь автономии».<\/b> Производительность всей системы ограничена ее самым медленным и наименее автономным звеном. Проблемы одной команды быстро становятся проблемами для многих других, которые от нее зависят.<\/li>\n<li><b>Главный вызов — поддержание модели при росте.<\/b> По мере роста компании поддерживать культуру автономии и эффективные горизонтальные связи становится все сложнее. Это требует постоянных усилий и адаптации существующих практик.<\/li>\n<\/ul>\n",
            "date_published": "2025-10-24T00:49:24+03:00",
            "date_modified": "2025-10-24T00:49:17+03:00",
            "tags": [
                "IT",
                "Management",
                "Programming"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/IMG_6D8AFAB994AA-1.jpeg",
            "_date_published_rfc2822": "Fri, 24 Oct 2025 00:49:24 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "288",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/IMG_6D8AFAB994AA-1.jpeg",
                    "https:\/\/gavrilov.info\/pictures\/IMG_C3074AF26DC8-1.jpeg",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-10-24-v-00.05.49.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-10-24-v-00.06.56.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-10-24-v-00.10.54.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-10-23-v-23.52.48.png"
                ]
            }
        },
        {
            "id": "274",
            "url": "https:\/\/gavrilov.info\/all\/i-esche-nemnogo-pro-bezopasnost-v-masshtabe\/",
            "title": "И еще немного про безопасность в масштабе",
            "content_html": "<h4>Ranger vs. OPA: Битва архитектур... и почему OPAL меняет правила игры<\/h4>\n<pre class=\"e2-text-code\"><code class=\"\">● Ranger has a fixed development model\n● To add new systems you need to write new modules,\ncompile and roll out Ranger\n● OPA is all REST\n● Basically everything is configuration\n● We can build the 80% abstraction layer easily\n● Anybody else -&gt; they can build whatever extra they need -&gt; in config!<\/code><\/pre><p>В мире современных распределённых систем управление доступом (авторизация) — одна из самых сложных и критически важных задач. Компании постоянно ищут баланс между безопасностью, гибкостью и скоростью разработки. Начальные тезисы были абсолютно точны:<\/p>\n<blockquote>\n<p>У Ranger фиксированная модель разработки. Чтобы добавить поддержку новых систем, нужно писать новые модули. [...] OPA полностью построен на REST. По сути, всё является конфигурацией. [...] Мы можем создать 80% абстракции, а остальные сами допишут всё, что нужно, через конфиг!<\/p>\n<\/blockquote>\n<p>Это сравнение описывает переход от традиционной, монолитной архитектуры к современной, микросервисной. Однако история неполная без третьего ключевого элемента — OPAL, который решает фундаментальную проблему OPA при масштабировании.<\/p>\n<p>Давайте рассмотрим все три компонента по порядку.<\/p>\n<h5>1. “Классический” подход: Apache Ranger<\/h5>\n<p>Apache Ranger — это зрелая и мощная система для централизованного управления политиками безопасности в экосистеме больших данных (Hadoop, Hive, Kafka и т.д.).<\/p>\n<ul>\n<li><b>Как это работает:<\/b> Ranger работает по принципу “сервер + плагины”. Центральный сервер хранит все политики доступа. В каждую защищаемую систему (например, в Hive) устанавливается специальный плагин, который периодически опрашивает сервер Ranger, скачивает актуальные политики и кэширует их для быстрой проверки доступа.<\/li>\n<\/ul>\n<ul>\n<li><b>Сильные стороны:<\/b>\n<ul>\n  <li><b>Централизация:<\/b> Единый центр для аудита и управления доступом.<\/li>\n  <li><b>Мощность:<\/b> Глубокая интеграция с поддерживаемыми системами (например, безопасность на уровне колонок в Hive).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n<li><b>Слабые стороны (те самые “фиксированные модели разработки”):<\/b>\n<ul>\n  <li><b>Негибкость:<\/b> Поддержка новой системы, не входящей в стандартный набор, требует написания плагина на Java, компиляции и развертывания новой версии Ranger. Это медленно и требует узкой экспертизы.<\/li>\n  <li><b>“Бутылочное горлышко”:<\/b> Все изменения проходят через центральную команду, что замедляет продуктовые команды.<\/li>\n  <li><b>Не для микросервисов:<\/b> Этот подход плохо подходит для динамичного мира микросервисов, где новые сервисы появляются каждый день.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><b>Аналогия:<\/b> Ranger — это как служба безопасности крупного завода, которая работает только со стандартными станками этого завода. Если вы покупаете новый станок из-за границы, вам нужно написать для службы безопасности целую новую инструкцию и переобучить персонал.<\/p>\n<h5>2. “Гибкий” подход: Open Policy Agent (OPA)<\/h5>\n<p>OPA — это универсальный движок политик с открытым исходным кодом. Его философия прямо противоположна Ranger. OPA ничего не знает о тех, кого он защищает.<\/p>\n<ul>\n<li><b>Как это работает:<\/b>\n<ol start=\"1\">\n  <li>Ваш сервис, получив запрос, формирует JSON-документ с контекстом (`{“user”: “alice”, “action”: “read”, “resource”: “document”}`).<\/li>\n  <li>Он отправляет этот JSON в OPA через простой REST API-вызов.<\/li>\n  <li>OPA применяет к этому JSON’у правила, написанные на языке <b>Rego<\/b>, и мгновенно возвращает решение: `allow` или `deny`.<\/li>\n<\/ol>\n<\/li>\n<\/ul>\n<ul>\n<li><b>Сильные стороны:<\/b>\n<ul>\n  <li><b>Универсальность:<\/b> OPA может управлять доступом к чему угодно — микросервисам, Kubernetes, конвейерам CI\/CD, базам данных.<\/li>\n  <li><b>Policy-as-Code:<\/b> Политики на Rego — это код. Их можно хранить в Git, версионировать, тестировать и автоматически развертывать.<\/li>\n  <li><b>Децентрализация:<\/b> OPA обычно развертывается как “сайдкар”-контейнер рядом с каждым экземпляром сервиса, что обеспечивает низкую задержку и высокую отказоустойчивость.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n<li><b>Проблема, которую OPA создает:<\/b>  <br \/>\nПредставьте, у вас 500 микросервисов, и рядом с каждым работает свой экземпляр OPA. Возникают вопросы:<\/li>\n\n<ul>\n  <li>Как доставить обновление политики во все 500 экземпляров OPA одновременно?<\/li>\n  <li>Откуда OPA возьмет данные для принятия решений (например, список ролей пользователя или владельцев документа)? Если каждый из 500 экземпляров OPA будет сам ходить в базу данных, это создаст колоссальную нагрузку.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Здесь на сцену выходит OPAL.<\/p>\n<h5>3. “Связующее звено”: OPAL (Open Policy Administration Layer)<\/h5>\n<p>OPAL — это не еще один движок политик. Это <b>административный слой реального времени для OPA<\/b>. Его единственная задача — поддерживать политики и данные в ваших OPA-агентах в актуальном состоянии.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/image-210.png\" width=\"1997\" height=\"945\" alt=\"\" \/>\n<\/div>\n<ul>\n<li>Как это работает (OPA + OPAL):**\n<ol start=\"1\">\n  <li>Политики (Rego-файлы) хранятся в Git-репозитории. Данные (роли, атрибуты) — в базах данных или API.<\/li>\n  <li><b>OPAL Server<\/b> подписывается на изменения в этих источниках (например, через веб-хуки из Git или топики Kafka).<\/li>\n  <li>Когда происходит изменение (например, разработчик пушит новую политику в Git), OPAL Server получает уведомление.<\/li>\n  <li>Сервер немедленно публикует сообщение об обновлении в легковесный канал (pub\/sub, обычно через WebSockets).<\/li>\n  <li><b>OPAL Clients<\/b>, работающие рядом с каждым OPA, получают это сообщение.<\/li>\n  <li>Клиенты сами скачивают нужные обновления (новую политику из Git, свежие данные из БД) и загружают их в свой локальный OPA.<\/li>\n<\/ol>\n<\/li>\n<\/ul>\n<ul>\n<li><b>Что это дает:<\/b>\n<ul>\n  <li><b>Обновления в реальном времени:<\/b> Изменение политики в Git моментально распространяется по всей системе.<\/li>\n  <li><b>Событийная архитектура:<\/b> Нет необходимости постоянно опрашивать источники. Это очень эффективно.<\/li>\n  <li><b>Полное разделение:<\/b> OPA отвечает только за принятие решений. OPAL — за доставку “знаний” для этих решений.<\/li>\n  <li><b>Масштабируемость:<\/b> Эта архитектура легко управляет тысячами OPA-агентов, решая проблему синхронизации.<\/li>\n  <li><b>Завершение истории GitOps:<\/b> Вы управляете доступом ко всей вашей инфраструктуре через `git push`, что полностью соответствует исходному тезису: <b>“всё является конфигурацией”<\/b>. <a href=\"https:\/\/medium.com\/@piyushraw12\/building-enterprise-grade-authorization-with-opal-and-opa-decentralized-policy-management-7bddb315433a\">medium.com<\/a><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/telegram-cloud-photo-size-4-5995580363474319391-y.jpg\" width=\"1200\" height=\"1167\" alt=\"\" \/>\n<\/div>\n<hr \/>\n<h4>Итоговое сравнение<\/h4>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td style=\"text-align: center\">Критерий<\/td>\n<td style=\"text-align: center\">Apache Ranger<\/td>\n<td style=\"text-align: center\">OPA (самостоятельно)<\/td>\n<td style=\"text-align: center\">OPA + OPAL (Современный стек)<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Архитектура<\/b><\/td>\n<td style=\"text-align: center\">Монолитный сервер + плагины<\/td>\n<td style=\"text-align: center\">Децентрализованный движок политик<\/td>\n<td style=\"text-align: center\">Децентрализованный движок + слой управления реального времени<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Процесс обновления<\/b><\/td>\n<td style=\"text-align: center\">Код -> Компиляция -> Развертывание<\/td>\n<td style=\"text-align: center\">Ручная загрузка политик через API<\/td>\n<td style=\"text-align: center\">`git push` -> Автоматическое распространение<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Гибкость<\/b><\/td>\n<td style=\"text-align: center\">Низкая (только для поддерживаемых систем)<\/td>\n<td style=\"text-align: center\">Очень высокая (универсальный)<\/td>\n<td style=\"text-align: center\">Очень высокая + управляемость в масштабе<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Управление данными<\/b><\/td>\n<td style=\"text-align: center\">Встроено<\/td>\n<td style=\"text-align: center\">Требует самостоятельного решения<\/td>\n<td style=\"text-align: center\">Встроено в архитектуру (OPAL следит за данными)<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Масштабируемость<\/b><\/td>\n<td style=\"text-align: center\">Масштабируется, но обновления медленные<\/td>\n<td style=\"text-align: center\">Плохо масштабируется с точки зрения управления<\/td>\n<td style=\"text-align: center\">Отлично масштабируется<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Подход<\/b><\/td>\n<td style=\"text-align: center\">Классический, централизованный<\/td>\n<td style=\"text-align: center\">`Policy-as-Code`, но неполный<\/td>\n<td style=\"text-align: center\">`Policy-as-Code` + `GitOps`, событийно-ориентированный<\/td>\n<\/tr>\n<\/table>\n<h4>Вывод<\/h4>\n<p>Возвращаясь к исходным тезисам, становится ясно, что их автор описывал <b>потенциал OPA<\/b>. Однако чтобы этот потенциал раскрылся в крупной организации, необходима система, которая возьмет на себя рутинную, но критически важную работу по синхронизации.<\/p>\n<ul>\n<li><b>Ranger<\/b> — это мощный, но неповоротливый инструмент из прошлого, идеальный для статичных, гомогенных сред.<\/li>\n<li><b>OPA<\/b> — это гениально простой и гибкий движок, сердце современной авторизации.<\/li>\n<li><b>OPAL<\/b> — это нервная система, которая соединяет это сердце с “мозгом” (Git, базы данных) и позволяет всему организму (вашим микросервисам) реагировать на изменения мгновенно.<\/li>\n<\/ul>\n<p>Современный, масштабируемый и по-настоящему гибкий “слой абстракции”, о котором говорилось в начале, строится именно на связке <b>OPA + OPAL<\/b>. Это позволяет создавать платформу, ценность которой, как и было сказано, “заключается в способности объединять внешние инструменты, команды, данные и процессы”.<\/p>\n<p>Еще было это: <a href=\"https:\/\/gavrilov.info\/all\/evolyuciya-upravleniya-dostupom-opa-opal-vs-fga-rbac-rebac\/\">https:\/\/gavrilov.info\/all\/evolyuciya-upravleniya-dostupom-opa-opal-vs-fga-rbac-rebac\/<\/a><\/p>\n",
            "date_published": "2025-08-29T00:02:28+03:00",
            "date_modified": "2025-09-18T09:12:45+03:00",
            "tags": [
                "IT",
                "Programming",
                "Security"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/image-210.png",
            "_date_published_rfc2822": "Fri, 29 Aug 2025 00:02:28 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "274",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "highlight\/highlight.js",
                    "highlight\/highlight.css"
                ],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/image-210.png",
                    "https:\/\/gavrilov.info\/pictures\/telegram-cloud-photo-size-4-5995580363474319391-y.jpg"
                ]
            }
        },
        {
            "id": "273",
            "url": "https:\/\/gavrilov.info\/all\/platforma\/",
            "title": "Платформа",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-08-28-v-23.36.14.png\" width=\"1382\" height=\"426\" alt=\"\" \/>\n<\/div>\n<p><b>Оригинал:<\/b><\/p>\n<blockquote>\n<p>A platform is a set of software and a surrounding ecosystem of resources that helps you to grow your business. A platform enables growth through connection: its value comes not only from its own features, but from its ability to connect external tools, teams, data, and processes.<\/p>\n<\/blockquote>\n<p><b>Перевод:<\/b><\/p>\n<blockquote>\n<p>Платформа — это комплекс программных решений и окружающая их экосистема ресурсов, которые способствуют росту вашего бизнеса. Платформа стимулирует рост за счёт связности: её ценность заключается не только в собственных функциях, но и в способности объединять внешние инструменты, команды, данные и процессы.<\/p>\n<\/blockquote>\n<h4>Дополнение с учетом современных трендов и опыта<\/h4>\n<p>Приведённая цитата — отличное базовое определение. Однако современное понимание платформ стало значительно шире и глубже. Сегодня платформа — это не просто технологический фундамент, а ключевой стратегический актив для трансформации всего бизнеса.<\/p>\n<p>Вот несколько ключевых аспектов, дополняющих это определение:<\/p>\n<ol start=\"1\">\n<li><b>Платформа как основа бизнес-стратегии.<\/b>  <br \/>\nСовременные лидеры рынка рассматривают платформы не как набор инструментов, а как основу для полного переосмысления своего бизнеса. Платформенный подход позволяет заново выстроить всю цепочку поставок, клиентский путь и процессы принятия решений. Это критический компонент «цифрового ядра» компании, стремящейся к постоянному обновлению и росту accenture.com <a href=\"https:\/\/www.accenture.com\/us-en\/insights\/strategy\/platform-strategy.\">https:\/\/www.accenture.com\/us-en\/insights\/strategy\/platform-strategy.<\/a><\/li>\n<\/ol>\n<ol start=\"2\">\n<li><b>Ценность требует инвестиций и настройки.<\/b>  <br \/>\nПлатформа сама по себе не является готовым решением. Она требует значительных инвестиций в настройку и интеграцию для того, чтобы начать генерировать ценность. Как отмечает Forrester, пустой аккаунт в `Amazon Web Services` (AWS) бесполезен до тех пор, пока вы не установите и не настроите на нём программное обеспечение и не окружите его дополнительными возможностями forrester.com <a href=\"https:\/\/www.forrester.com\/blogs\/a-simple-definition-of-platform.\">https:\/\/www.forrester.com\/blogs\/a-simple-definition-of-platform.<\/a><\/li>\n<\/ol>\n<ol start=\"3\">\n<li><b>Переход от монолита к экосистеме.<\/b>  <br \/>\nЭпоха единых монолитных IT-приложений, которые должны были решать все задачи бизнеса, подходит к концу. Современная парадигма — это создание гибкой архитектуры, в которой решения от разных поставщиков могут быть бесшовно развёрнуты и интегрированы. Такие «инновационные платформы» позволяют компаниям быстро адаптироваться к изменениям и использовать лучшие в своём классе инструменты для каждой функции cimdata.com <a href=\"https:\/\/www.cimdata.com\/en\/platformization-some-common-definitions.\">https:\/\/www.cimdata.com\/en\/platformization-some-common-definitions.<\/a><\/li>\n<\/ol>\n<ol start=\"4\">\n<li><b>Драйвер новых бизнес-моделей и конкурентного преимущества.<\/b>  <br \/>\nПлатформенные бизнес-модели — это проверенный способ достижения успеха. Они позволяют технологическим компаниям монетизировать свои продукты через модели `as-a-service` (по подписке или на основе потребления), повышать лояльность клиентов за счёт связанных сервисов и масштабироваться гораздо быстрее. Для 80% компаний, ещё не перешедших на платформенную модель, главным вызовом становится растущая конкуренция со стороны тех, кто уже сделал этот шаг ey.com <a href=\"https:\/\/www.ey.com\/en_nz\/insights\/technology\/how-can-your-platform-business-model-fuel-competitiveness-and-growth.\">https:\/\/www.ey.com\/en_nz\/insights\/technology\/how-can-your-platform-business-model-fuel-competitiveness-and-growth.<\/a><\/li>\n<\/ol>\n<ol start=\"5\">\n<li><b>Создание сетевого эффекта.<\/b>  <br \/>\nКлючевая особенность успешной платформы — способность создавать <b>сетевой эффект<\/b>. Чем больше пользователей, разработчиков, партнёров и сервисов подключается к платформе, тем выше становится её ценность для каждого участника. Примерами могут служить операционные системы (`Windows`, `macOS`), платформы для разработки (`Java`), браузеры (`Chrome`) или социальные сети, где ценность напрямую зависит от количества и активности пользователей и создателей контента appmarketplace.com <a href=\"https:\/\/appmarketplace.com\/blog\/what-is-a-platform.\">https:\/\/appmarketplace.com\/blog\/what-is-a-platform.<\/a><\/li>\n<\/ol>\n<hr \/>\n<p><b>Итоговое современное определение<\/b> можно сформулировать так:<\/p>\n<blockquote>\n<p><b>Платформа<\/b> — это стратегический бизнес-актив, представляющий собой гибкую и масштабируемую технологическую основу, которая объединяет внутренние и внешние ресурсы (инструменты, данные, команды, партнёров) в единую экосистему. Её главная цель — не просто предоставлять функции, а стимулировать рост, инновации и создание сетевых эффектов, позволяя компании переосмысливать бизнес-модели и получать устойчивое конкурентное преимущество.<\/p>\n<\/blockquote>\n",
            "date_published": "2025-08-28T23:44:51+03:00",
            "date_modified": "2025-09-08T21:30:20+03:00",
            "tags": [
                "IT",
                "Platform",
                "Programming"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-08-28-v-23.36.14.png",
            "_date_published_rfc2822": "Thu, 28 Aug 2025 23:44:51 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "273",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-08-28-v-23.36.14.png"
                ]
            }
        },
        {
            "id": "242",
            "url": "https:\/\/gavrilov.info\/all\/my-zadeystvovali-slishkom-mnogo-urovney-abstrakcii-i-teper-budus\/",
            "title": "Мы задействовали слишком много уровней абстракции, и теперь будущее выглядит мрачно.",
            "content_html": "<p>Опубликовано 21.10.2023. Изменено 06.11.2023.<\/p>\n<p>Оригинал: <a href=\"https:\/\/unixdigest.com\/articles\/we-have-used-too-many-levels-of-abstractions-and-now-the-future-looks-bleak.html\">https:\/\/unixdigest.com\/articles\/we-have-used-too-many-levels-of-abstractions-and-now-the-future-looks-bleak.html<\/a><\/p>\n<p>Большой процент так называемых экспертов сегодня умеет только настраивать инструменты, но ничего не понимает о том, как вещи работают на более глубоком уровне. Это настоящий вызов и большая проблема для будущего.<\/p>\n<p>Рулевое колесо — это абстракция, которая облегчает мне вождение автомобиля. Усилитель руля — это еще один уровень абстракции, который еще больше улучшает опыт вождения. Абстракции хороши, они, как правило, улучшают качество жизни. Однако в Дании есть поговорка:<\/p>\n<p>Слишком мало и слишком много всё портит.<\/p>\n<p>Какая польза от абстракции, когда она ломается и никто больше не понимает, как работает технология “под капотом”?<\/p>\n<p>Вся технологическая индустрия движима очень жестким стремлением к прибыли и очень малым интересом к чему-либо еще. Поэтому вам нужно иметь возможность выпускать новые продукты или новые услуги как можно быстрее. Это означает больше абстракций и больше автоматизации, всё меньше и меньше людей и всё меньше глубокого понимания.<\/p>\n<p>Сегодня программистов и системных администраторов больше не существует, вместо них у нас есть DevOps и даже DevSecOps, в которых индустрия очень старательно пытается втиснуть каждую отдельную задачу в должностную инструкцию одного человека. Специалисты по технологиям должны выполнять разработку (Dev), безопасность (Sec) и операции (Ops), то есть системное администрирование, но поскольку ни один человек не может по-настоящему освоить все это, нам нужно автоматизировать как можно больше, чтобы сэкономить деньги и избежать сложностей человеческого социального взаимодействия между различными техническими отделами. В результате современному специалисту по технологиям enseñan только тому, как использовать конкретные инструменты, и он или она очень мало знает о технологии “под капотом”.<\/p>\n<p>Не помогает и то, что технологии стало всё труднее понимать, но всё больше и больше современной жизни сильно зависит от используемых нами технологий. Так что же произойдет, когда уровень понимания в технологической индустрии достигнет такой низкой точки, при которой большинство людей даже не будут знать, как починить инструменты, которыми они пользуются?<\/p>\n<p><video controls style=\"width: 100%; max-width: 740px; height: auto;\"><br \/>\n<source src=\"http:\/\/a.gavrilov.info\/data\/posts\/wall-e-manual-scene.mp4\" type=\"video\/mp4\"><br \/>\nВаш браузер не поддерживает видео.<br \/>\n<\/video><\/p>\n<p>Люди привыкли к состоянию абстракции и считают, что это правильный подход, и с радостью способствуют беспорядку, добавляя еще больше абстракции.<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">Да, давайте все вернемся к кодированию на ассемблере!\n\n— Саркастический комментарий высокомерного разработчика<\/code><\/pre><p>Нам нужны абстракции, в этом нет сомнений, но каждый уровень абстракции обходится дорогой ценой, которая, как ни иронично, в конечном итоге может привести к огромным потерям прибыли.<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">Современное программирование пугает меня во многих отношениях, когда они просто строят слой за слоем, который ничего не делает, кроме перевода.\n\n— Кен Томпсон<\/code><\/pre><p>Уже сейчас большинство “специалистов по безопасности” очень мало знают о безопасности и только о том, как использовать какой-то готовый инструмент для тестирования на проникновение. Инструмент для тестирования на проникновение показывает кучу зеленых лампочек на своей веб-панели, и все считается в порядке. Тем не менее, настоящий эксперт по безопасности со злыми намерениями давно взломал систему и продолжает продавать ценные данные в даркнете. Ничего не утекло и ничего не обнаружено. Это может продолжаться годами, никто ничего не узнает, потому что, ну, на панели GUI написано, что все в порядке.<\/p>\n<p>Некоторые студенты сегодня, по-видимому, даже не знают, что такое файлы и папки.<\/p>\n<p>Советы изучающим технологии:<\/p>\n<ol start=\"1\">\n<li>Никогда не следуйте за хайпом или трендами.<\/li>\n<li>Будьте любопытны. Не просто изучайте инструменты, старайтесь понять, как работает базовая технология.<\/li>\n<li>Если возможно, попробуйте хотя бы один раз вручную сделать то, что, например, делает для вас инструмент конфигурации.<\/li>\n<li>Если возможно, попробуйте посмотреть код инструмента. Даже базовое понимание кода может быть очень ценным.<\/li>\n<li>Сохраняйте любопытство. Продолжайте учиться. Экспериментируйте. Погружайтесь глубже в интересующие вас технологии. Если возможно, создайте домашнюю лабораторию и используйте ее как игровую площадку для обучения и слома вещей.<\/li>\n<li>Ставьте под сомнение все. Особенно то, что вам кажется бессмысленным. Не думайте, что кто-то знает лучше — так вы быстро превратитесь в слепого последователя. Иногда кто-то действительно знает лучше, но не делайте такого вывода по умолчанию. И будьте смелыми! Стойте на стороне правды и своих убеждений, даже если это заставляет вас чувствовать себя одиноким.<\/li>\n<\/ol>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/image-191.png\" width=\"650\" height=\"293\" alt=\"\" \/>\n<\/div>\n<p>Люди слепо следуют друг за другом.<br \/>\nСмысл, который я закладываю в этот пост, не в том, что все должно быть понято всеми с первых принципов, или что вы не должны использовать никакие инструменты. Как я уже сказал, нам нужны абстракции. Кроме того, у нас есть люди, которые специализируются в разных областях, так что, например, механик чинит грузовик, а водитель водит грузовик.<\/p>\n<p>Скорее, я затрагиваю важную ценность инженерного отношения к технологиям у людей, работающих с технологиями.<\/p>\n<p>В, например, разработке программного обеспечения слишком многие специалисты были абстрагированы и заменены инструментами и автоматизацией, и все меньше и меньше людей понимают что-либо даже на один уровень ниже того слоя, на котором они работают.<\/p>\n<p>Это большая проблема, потому что в конечном итоге мы достигнем точки, когда очень немногие смогут что-либо исправить на нижних уровнях. И дело в том, что мы уже частично достигли этой точки!<\/p>\n<p>Примерно полгода назад я наткнулся на несколько фронтенд-веб-разработчиков, которые не знали, что веб-сайт можно создать без инструмента развертывания и что JavaScript вообще не нужен, даже если веб-сайт принимает платежи. Я спросил об этом своего друга, который в то время преподавал программирование на Python, и он сказал:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">Не удивляйтесь этому. Это нынешний уровень. Индустрия хочет, чтобы мы массово производили людей, которые умеют &quot;нажимать кнопки&quot;, а не людей, которые понимают что-то на более глубоком уровне.<\/code><\/pre><p>Я знаю, что всегда найдутся люди, которые будут интересоваться более глубокими уровнями, дело не в этом. Дело в том, что именно в разработке программного обеспечения мы давно достигли точки, когда добавили слишком много слоев абстракции, и слишком мало людей понимают, что они делают. Индустрия стреляет себе в ногу.<\/p>\n<p>Если, например, я веб-разработчик, будь то фронтенд или бэкенд, или занимаюсь так называемой “интеграционной работой” и создаю веб-сайты без особого кодирования или каких-либо знаний о TCP\/IP, DNS, HTTP, TLS, безопасности и т. д., используя только готовые инструменты или фреймворки, то это сделает меня примерно таким же полезным, как обезьяна с динамометрическим ключом, когда что-то пойдет не так.<\/p>\n",
            "date_published": "2025-05-31T23:41:47+03:00",
            "date_modified": "2025-05-31T23:41:40+03:00",
            "tags": [
                "IT",
                "Programming"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/image-191.png",
            "_date_published_rfc2822": "Sat, 31 May 2025 23:41:47 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "242",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "highlight\/highlight.js",
                    "highlight\/highlight.css"
                ],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/image-191.png"
                ]
            }
        },
        {
            "id": "234",
            "url": "https:\/\/gavrilov.info\/all\/analiz-knigi-postroenie-evolyucionnyh-arhitektur\/",
            "title": "Анализ книги – построение эволюционных архитектур",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-04-20-v-14.32.46.png\" width=\"780\" height=\"988\" alt=\"\" \/>\n<\/div>\n<p><a href=\"http:\/\/a.gavrilov.info\/data\/posts\/building_evolutionary_architectures_support_constant_change_1nbsped.pdf\">Полная версия тут <\/a><\/p>\n<p><b>Краткое содержание<\/b><\/p>\n<p>Книга “Построение эволюционных архитектур” Нила Форда, Ребекки Парсонс и Патрика Куа рассматривает подход к разработке программных систем, которые легко адаптируются к изменениям и новым требованиям. Книга подчеркивает важность постепенных изменений, объективных критериев оценки архитектуры (fitness-функций) и разумной связанности между компонентами. Авторы подробно описывают принципы, практики и антипаттерны эволюционного подхода, чтобы помочь читателям создавать гибкие и устойчивые системы.<\/p>\n<p><b>Основные тезисы и выводы<\/b><\/p>\n<ul>\n<li>Эволюционная архитектура – это не просто методология, это философия:** Подход к построению систем, которые “учатся” и адаптируются к изменениям, в отличие от жёстких, заранее спланированных архитектур.<\/li>\n<li>Изменения неизбежны и к ним надо готовиться:** Современный мир разработки требует гибкости. Эволюционные архитектуры призваны облегчить внесение изменений, а не предотвращать их.<\/li>\n<li>Fitness-функции – это компас для эволюции:**  Объективные критерии оценки архитектуры, которые помогают защитить важные её характеристики в процессе изменений (производительность, безопасность, масштабируемость и т.д.).<\/li>\n<li>Постепенность и малые изменения – основа успеха:**  Небольшие инкрементальные изменения легче контролировать, тестировать и развертывать, чем крупные реструктуризации. Большие изменения происходят из маленьких шагов.<\/li>\n<li>Связанность должна быть разумной и осознанной:**  Чрезмерная связанность (coupling) затрудняет изменения. Необходимо стремиться к минимальной связанности, необходимой для решения бизнес-задач и функциональной целостности. Разумная связанность должна обеспечивать масштабируемость и надежность.<\/li>\n<li>Команда и культура важны не меньше, чем технологии:** Успешное внедрение эволюционной архитектуры требует кросс-функциональной команды с культурой экспериментов и автоматизации (DevOps).<\/li>\n<li>Инструменты и автоматизация – основа практики:** Автоматизированные процессы и конвейеры развертывания (deployment pipelines) позволяют быстро и надежно вносить изменения и оценивать их влияние на архитектуру. Автоматизация позволяет снизить цену изменений.<\/li>\n<\/ul>\n<p><b>Заключение<\/b><\/p>\n<p>Книга “Построение эволюционных архитектур” предоставляет ценную методологию для разработки программных систем, способных адаптироваться к постоянным изменениям. Книга будет полезной для архитекторов, разработчиков и руководителей, стремящихся создавать гибкие, устойчивые и конкурентоспособные решения. Эта книга – практическое руководство по эволюции программного обеспечения, а не попытка навязать еще один “серебряный шар”.<\/p>\n<p><b>Рекомендации<\/b><\/p>\n<ol start=\"1\">\n<li><b>Начните с анализа текущей архитектуры:<\/b>  Определите узкие места, критические зависимости и области, требующие большей гибкости.<\/li>\n<li><b>Определите ключевые fitness-функции:<\/b> Какие характеристики архитектуры наиболее важны для бизнеса? Установите объективные критерии их оценки.<\/li>\n<li><b>Постепенно внедряйте конвейеры развертывания (deployment pipelines):<\/b> Автоматизируйте процессы сборки, тестирования и развертывания небольших изменений.<\/li>\n<li><b>Поддерживайте культуру экспериментов:<\/b> Поощряйте небольшие, контролируемые эксперименты с новыми технологиями и подходами.<\/li>\n<li><b>Используйте потребительски ориентированные контакты:<\/b> Отслеживайте требования потребителей и используйте feedback для постоянного совершенствования архитектуры.<\/li>\n<li><b>Создавайте небольшую, но эффективную команду:<\/b> Кросс-функциональная команда с необходимыми навыками будет залогом успешной эволюции архитектуры.<\/li>\n<li><b>Учитывайте организационные факторы:<\/b> Адаптируйте структуру команды, процессы бюджетирования и управления изменениями, чтобы поддерживать эволюционный подход.<\/li>\n<li><b>Применяйте на практике теорию Эрика Эванса в книге “Домен управляемый дизайн”:<\/b> Эффективные архитектурные решения будут приниматься с учетом предметной области.<\/li>\n<\/ol>\n<p><b>План действий согласно книге<\/b><\/p>\n<ol start=\"1\">\n<li><b>Оценка текущей ситуации:<\/b>\n<ul>\n  <li>Анализ архитектуры: Определение проблемных мест, связей, которые необходимо уменьшить.<\/li>\n  <li>Оценка зрелости команды: Анализ навыков, процессов и культуры разработки.<\/li>\n<\/ul>\n<\/li>\n<li><b>Определение целей и стратегии:<\/b>\n<ul>\n  <li>Определение ключевых бизнес-целей: Что должна обеспечивать архитектура? Чего ожидает бизнес? Какова ключевая ценность?<\/li>\n  <li>Выбор стиля архитектуры:  Учитывая ограничения и требования, выбрать подходящий стиль архитектуры (микросервисы, SOA, монолит с модульной структурой и т.д.).<\/li>\n<\/ul>\n<\/li>\n<li><b>Внедрение изменений:<\/b>\n<ul>\n  <li>Разработка fitness-функций:  Для защиты архитектуры с новыми возможностями.<\/li>\n  <li>Постепенные изменения с использованием deployment pipelines: Автоматизация процессов сборки, тестирование, изменение<\/li>\n  <li>Создание Cross-функциональной команды: Поместите все необходимые ресурсы в команду, чтобы уменьшить препятствия.<\/li>\n<\/ul>\n<\/li>\n<li><b>Непрерывное совершенствование:<\/b>\n<ul>\n  <li>Анализ метрик и feedback:  Постоянный сбор информации о работе системы и ее воздействии на бизнес.<\/li>\n  <li>Регулярный пересмотр архитектуры и fitness-функций:  Адаптация к изменяющимся требованиям и технологиям.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n",
            "date_published": "2025-04-20T14:33:38+03:00",
            "date_modified": "2025-04-20T14:34:33+03:00",
            "tags": [
                "Architecture",
                "big data",
                "IT"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-04-20-v-14.32.46.png",
            "_date_published_rfc2822": "Sun, 20 Apr 2025 14:33:38 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "234",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-04-20-v-14.32.46.png"
                ]
            }
        },
        {
            "id": "224",
            "url": "https:\/\/gavrilov.info\/all\/growth-engineering-iskusstvo-vzryvnogo-rosta-kompanii-cherez-kod\/",
            "title": "Growth Engineering: Искусство взрывного роста компании через код",
            "content_html": "<p>На основе:  <a href=\"https:\/\/newsletter.pragmaticengineer.com\/p\/what-is-growth-engineering\">https:\/\/newsletter.pragmaticengineer.com\/p\/what-is-growth-engineering<\/a><\/p>\n<p><b>Что такое Growth Engineering?<\/b><\/p>\n<p>В современном мире технологического бизнеса, где конкуренция ощущается на каждом шагу, компании постоянно ищут способы взрывного роста. На стыке разработки продукта и маркетинга возникла область, получившая название Growth Engineering. Это не просто написание кода – это стратегическое применение инженерных навыков для максимизации прибыли компании, оптимизируя каждый этап взаимодействия с пользователем. Алексей Комиссарук, бывший руководитель Growth Engineering в MasterClass, говорит об этом просто: “Growth Engineering – это написание кода, который помогает компании зарабатывать больше денег”.<\/p>\n<p><b>Зачем компаниям Growth-инженеры?<\/b><\/p>\n<p>Десять лет назад о Growth Engineering мало кто знал. Сегодня, когда стартапы стремятся масштабироваться, а публичные технологические компании – защищать свои позиции, команды с Growth-инженерами стали необходимостью. Они, словно хирурги, препарируют существующие продукты или услуги, выявляя точки роста и реализуют их, зачастую минимальными, но точными изменениями.<\/p>\n<p>Growth-инженеры особенно востребованы в компаниях, осуществляющих продажи потребителям или работающих по модели SaaS, на этапе Series B и далее. Именно тогда компания имеет достаточно трафика и ресурсов, чтобы проводить A\/B-тесты и инвестировать в команду, которая будет заниматься исключительно вопросами роста.<\/p>\n<p><b>Чем занимаются Growth-инженеры? Три ключевых направления<\/b><\/p>\n<p>Работа Growth-инженера лежит в трёх основных плоскостях:<\/p>\n<ul>\n<li>Работа, непосредственно влияющая на бизнес:** Это сердце Growth Engineering. Здесь Growth-инженеры, вооружившись A\/B-тестами и аналитическими инструментами, оптимизируют ключевые бизнес-метрики. Примеры задач:\n<ul>\n  <li>Оптимизация воронки регистрации:** Снижение барьеров для новых пользователей, упрощение форм, добавление социальных логинов, улучшение онбординга.<\/li>\n  <li>Персонализация рекомендаций:** Разработка алгоритмов, которые предлагают пользователям наиболее релевантный контент или продукты, повышая вовлеченность и вероятность покупки.<\/li>\n  <li>A\/B-тестирование цен и пакетов услуг:** Проверка различных ценовых стратегий для максимизации дохода, включая тестирование скидок, пробных периодов и различных комбинаций функций в платных планах.<\/li>\n  <li>Оптимизация рекламных посадочных страниц:** Создание и A\/B-тестирование целевых страниц, адаптированных к конкретным рекламным кампаниям, чтобы повысить конверсию посетителей в лиды или клиентов.<\/li>\n<\/ul>\n<\/li>\n<li>Предоставление возможностей для роста:** Задача Growth-инженера – расширить возможности команды маркетинга и других специалистов, предоставив им инструменты, которые позволяют самостоятельно реализовывать идеи и экспериментировать без постоянного участия разработчиков. Это включает в себя:\n<ul>\n  <li>Интеграцию с платформами автоматизации маркетинга (например, HubSpot, Marketo), автоматизируя e-mail маркетинг и работу с пользователями.<\/li>\n  <li>Создание инструментов для работы с CDP (Customer Data Platform) для сегментации пользователей, таргетинга и персонализированных предложений.<\/li>\n  <li>Настройку систем атрибуции для отслеживания источников трафика и оценки эффективности маркетинговых каналов, позволяя максимально точно определять ROI (Return on Investment) маркетинговых активностей.<\/li>\n<\/ul>\n<\/li>\n<li>Работа с платформой:** Чтобы команда Growth могла двигаться максимально быстро, необходима надежная платформа, включающая в себя:\n<ul>\n  <li>Микросервисную архитектуру, позволяющую командам независимо развертывать эксперименты и избегать конфликтов.<\/li>\n  <li>Создание инструментов для автоматической интеграции с маркетинговыми платформами, упрощающими процесс подключения новых сервисов.<\/li>\n  <li>Централизованные системы ведения логов и аналитики, обеспечивающие доступ ко всем необходимым данным для мониторинга и анализа результатов экспериментов.<\/li>\n  <li>Централизованную A\/B платформу, которая позволяет удобно проводить и анализировать результаты экспериментов.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><b>Почему Growth-инженеры работают быстрее, чем Product-инженеры?<\/b><\/p>\n<p>Ключевое различие между Growth и Product Engineering кроется в философии и подходе к работе. Product-инженеры *разрабатывают*, чтобы создать продукт. Growth-инженеры *разрабатывают*, чтобы учиться. Growth Engineer быстрее принимает решения, потому что их цель – проверять гипотезы, а не создавать идеальный продукт сразу. Они быстрее оптимизируют свою работу, чтобы можно было проводить как можно больше экспериментов.<\/p>\n<p>Представьте себе строительство. Product Engineering – это возведение небоскреба: основательно, долговечно, но требует огромного количества времени и ресурсов. Growth Engineering – это скорее установка палатки: быстро, дешево и легко. Палатка не предназначена для жизни на века, но она позволяет быстро проверить, подходит ли это место для более основательного строительства.<\/p>\n<p><b>Пример из практики: Masterclass и ценовые планы<\/b><\/p>\n<p>В Masterclass команда Growth Engineering столкнулась с необходимостью протестировать новую модель ценообразования. Разработка полноценного многоуровневого решения заняла бы месяцы и потребовала привлечения множества команд. Вместо этого, Growth-инженеры реализовали “фейковую дверь” – показали пользователям страницу с различными тарифными планами, которые на тот момент еще не были реализованы. Анализ данных показал, что переход на новую модель ценообразования может значительно увеличить доход компании. Это позволило убедить руководство инвестировать в полноценную разработку.<\/p>\n<p><b>Инструменты Growth-инженера: Технологический стек<\/b><\/p>\n<p>Для эффективной работы Growth-инженеру необходим обширный набор инструментов, охватывающих разработку, аналитику и автоматизацию маркетинга:<\/p>\n<ul>\n<li>Языки программирования:** Python, JavaScript, TypeScript и другие, в зависимости от специфики проекта.<\/li>\n<li>Feature Flags:** LaunchDarkly, Optimizely – для быстрого включения и выключения функциональности и проведения A\/B-тестов.<\/li>\n<li>Продуктовая аналитика:** Amplitude, Mixpanel – для отслеживания поведения пользователей и оценки эффективности изменений.<\/li>\n<li>Экспериментальные платформы:** AB Tasty, VWO – для автоматизации A\/B-тестирования и анализа результатов.<\/li>\n<li>Системы мониторинга и алертинга:** Datadog, Grafana, Prometheus – для оперативного выявления проблем и оповещения о критических ситуациях.<\/li>\n<li>Платформы автоматизации маркетинга:** HubSpot, Marketo, Iterable – для автоматизации коммуникаций с пользователями и персонализации маркетинговых кампаний.<\/li>\n<li>CDP (Customer Data Platform):** Segment, mParticle – для управления данными о клиентах и создания персонализированных предложений.<\/li>\n<\/ul>\n<p><b>Кто такой Growth-инженер: Необходимые навыки и качества<\/b><\/p>\n<p>Чтобы преуспеть в Growth Engineering, необходимо обладать не только техническими навыками, но и определенным складом ума:<\/p>\n<ul>\n<li>Любознательность:** Желание постоянно учиться новому, исследовать и экспериментировать. Умение смотреть на все глазами пользователя и анализировать причины тех или иных действий.<\/li>\n<li>“Строительство ради обучения”:** Готовность быстро прототипировать, проводить эксперименты и учиться на ошибках.<\/li>\n<li>“Мастер на все руки”:** Обширный набор навыков, позволяющий решать задачи, лежащие на стыке разработки, аналитики и маркетинга.<\/li>\n<li>Аналитическое мышление:** Умение анализировать данные, выявлять тренды и делать обоснованные выводы.<\/li>\n<\/ul>\n<p><b>Организация команды Growth: Где размещаются Growth-инженеры?<\/b><\/p>\n<p>Обычно Growth-инженеры входят в состав отдела разработки, но их работа тесно связана с маркетингом и аналитикой. Существуют разные модели организации команды:<\/p>\n<ul>\n<li>Модель “владельца”:** Команда Growth полностью отвечает за определенный участок работы, например, за оптимизацию воронки регистрации.<\/li>\n<li>Модель “автостопщика”:** Команда Growth оказывает помощь другим командам, предоставляя экспертизу и реализуя их идеи, действуя как внутренний консультант.<\/li>\n<\/ul>\n<p><b>Стать Growth-инженером: Путь к карьерному росту<\/b><\/p>\n<p>Growth Engineering – отличный старт для тех, кто мечтает о карьере основателя компании или руководителя продукта. Работа в Growth предоставляет уникальную возможность увидеть бизнес изнутри, понять взаимосвязи между различными отделами и приобрести навыки, необходимые для принятия стратегических решений. Если вы хотите ускорить свой карьерный рост и получить ценный опыт, который пригодится в любой сфере деятельности, Growth Engineering – это ваш выбор.<\/p>\n<p><b>В заключение<\/b><\/p>\n<p>Growth Engineering – это быстро развивающаяся область, требующая сочетания технических навыков, аналитического мышления и креативности. Это искусство взрывного роста компании через код, путем непрерывных экспериментов и пристального внимания к данным. Если вы готовы к вызовам и стремитесь к постоянному развитию, Growth Engineering может стать вашей дорогой к успеху.<\/p>\n",
            "date_published": "2025-04-06T10:58:04+03:00",
            "date_modified": "2025-04-06T10:58:23+03:00",
            "tags": [
                "IT",
                "Management",
                "Marketing"
            ],
            "_date_published_rfc2822": "Sun, 06 Apr 2025 10:58:04 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "224",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "153",
            "url": "https:\/\/gavrilov.info\/all\/shablon-arhitektury-sistemy\/",
            "title": "Шаблон архитектуры системы",
            "content_html": "<p>Отличный шаблончик на vc нашел<\/p>\n<p>Читаем тут:<br \/>\n<a href=\"https:\/\/a.gavrilov.info\/data\/posts\/Architecture-Description-Template.ru.pdf\">https:\/\/a.gavrilov.info\/data\/posts\/Architecture-Description-Template.ru.pdf<\/a><\/p>\n<p>Пишем свой тут:<br \/>\n<a href=\"https:\/\/a.gavrilov.info\/data\/posts\/Architecture-Description-Template.ru.docx\">https:\/\/a.gavrilov.info\/data\/posts\/Architecture-Description-Template.ru.docx<\/a><\/p>\n<p>Оригинальный пост: <a href=\"https:\/\/vc.ru\/u\/1915268-anna-y\/1087763-dlya-arhitektorov-i-analitikov-ischerpyvayushii-shablon-opisaniya-arhitektury-prilozheniya-34-stranicy-polzy\">https:\/\/vc.ru\/u\/1915268-anna-y\/1087763-dlya-arhitektorov-i-analitikov-ischerpyvayushii-shablon-opisaniya-arhitektury-prilozheniya-34-stranicy-polzy<\/a><\/p>\n<p>Канальчик автора:<br \/>\nAnna Y<br \/>\nITSM-эксперт. 25 лет развиваю процессы в ИТ. Пишу про сложные ИТ-решения. Пишу по большой любви <a href=\"https:\/\/t.me\/itsm4u\">https:\/\/t.me\/itsm4u<\/a> и на заказ <a href=\"https:\/\/t.me\/tyzhavtor\">https:\/\/t.me\/tyzhavtor<\/a><\/p>\n<p>Еще любопытный док получилось бы на тему концепций, что то в эту сторону<\/p>\n<p><a href=\"https:\/\/a.gavrilov.info\/data\/posts\/Framing%20product%20concepts%20for%20your%20team:%20mission,%20vision,%20strategy,%20roadmap%20\">https:\/\/a.gavrilov.info\/data\/posts\/Framing%20product%20concepts%20for%20your%20team:%20mission,%20vision,%20strategy,%20roadmap%20<\/a>|%20by%20Carlin%20Yuen%20|%20Medium.pdf<\/p>\n",
            "date_published": "2024-07-30T22:50:27+03:00",
            "date_modified": "2024-07-30T23:00:10+03:00",
            "tags": [
                "IT",
                "system design"
            ],
            "_date_published_rfc2822": "Tue, 30 Jul 2024 22:50:27 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "153",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "127",
            "url": "https:\/\/gavrilov.info\/all\/kompyuternoe-myshlenie\/",
            "title": "Компьютерное мышление",
            "content_html": "<p>Vienna Gödel Lecture 2016 with Jeannette Wing, Corporate Vice President, Microsoft Research (talk starts at 11:55)<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/YVEUOHw3Qb8?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n",
            "date_published": "2024-06-09T22:33:04+03:00",
            "date_modified": "2024-06-09T22:32:54+03:00",
            "tags": [
                "IT"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/remote\/youtube-YVEUOHw3Qb8-cover.jpg",
            "_date_published_rfc2822": "Sun, 09 Jun 2024 22:33:04 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "127",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/remote\/youtube-YVEUOHw3Qb8-cover.jpg"
                ]
            }
        }
    ],
    "_e2_version": 4171,
    "_e2_ua_string": "Aegea 11.4 (v4171e)"
}