Transcript
00:00:00GitHub находится в очень тяжелом, крайне плачевном положении.
00:00:04Существует масса проблем, многие из которых связаны с ИИ,
00:00:08но, возможно, совсем не по тем причинам, о которых вы думаете,
00:00:10однако я к этому еще вернусь.
00:00:11И, разумеется, это имеет огромное значение.
00:00:13Это важно, потому что GitHub — это своего рода фундамент
00:00:16всей современной разработки.
00:00:17Неважно, занимаетесь ли вы открытым исходным кодом,
00:00:20поддерживаете ли какие-то open-source проекты,
00:00:22работаете ли вы просто над своими личными задумками,
00:00:24над персональными или сторонними проектами,
00:00:26руководите ли малым бизнесом или небольшой компанией,
00:00:29или, возможно, трудитесь в крупной корпорации —
00:00:32он используется повсеместно: как архив кода,
00:00:35для рабочих процессов CI/CD, для совместной работы,
00:00:38через тикеты (issues) для общего ведения проектов,
00:00:42для пул-реквестов и множества других задач.
00:00:47Так что это серьезно, но, как я уже сказал,
00:00:49проблем сейчас накопилось очень много.
00:00:51Давайте начнем с того, что именно идет не так,
00:00:53прежде чем разбираться в причинах
00:00:54и в том, что все это значит для будущего.
00:00:57И начнем с самого громкого случая.
00:00:59Буквально вчера появилась информация
00:01:02об огромной, просто невероятной уязвимости,
00:01:07на момент записи этого видео.
00:01:09Удаленное выполнение кода (RCE) на github.com.
00:01:12Знаете, читать об этом — просто безумие.
00:01:16Ее обнаружила компания Wiz, специализирующаяся на безопасности,
00:01:19и она не была использована злоумышленниками.
00:01:21То есть ее нашли, сообщили о ней и исправили.
00:01:25Никакого ущерба нанесено не было.
00:01:28По заявлениям самого GitHub,
00:01:31они также опубликовали ответ на этот отчет.
00:01:33Сейчас я не буду вдаваться в детали того,
00:01:36как именно работала эта уязвимость.
00:01:39Но я оставлю ссылку на статью в описании.
00:01:42В конечном итоге все сводилось к команде git push.
00:01:44Никакого фишинга,
00:01:46никакого взлома аккаунтов сотрудников,
00:01:49никаких атак на цепочку поставок.
00:01:51Мы видели много подобного за последние недели,
00:01:54но здесь ничего такого не было.
00:01:56Вместо этого — обычный git push,
00:01:58а конкретно — стандартная функция параметров push,
00:02:03которую можно добавить к команде git push,
00:02:05чтобы передать дополнительные опции.
00:02:10И через эти параметры, используя уязвимость
00:02:13в том, как GitHub обрабатывал пуши,
00:02:17исследователи безопасности смогли внедрить код,
00:02:22который просто брал и исполнялся на серверах GitHub.
00:02:27Опять же, точные детали есть в отчете,
00:02:31но суть в том, что они злоупотребили возможностью
00:02:34добавлять метаданные в заголовок xstat,
00:02:39который заполнялся с помощью этого флага параметров push.
00:02:44И эти метаданные — информация, передаваемая
00:02:49вместе с запросом через данный заголовок —
00:02:52в итоге не очищались GitHub'ом от вредоносного кода.
00:02:54Они просто проверяли подлинность запроса
00:02:58и самой команды push.
00:02:59Проверяли, есть ли у вас права на запись
00:03:01в репозиторий, в который вы пытаетесь отправить код,
00:03:03а затем брали данные из параметров
00:03:07и формировали заголовок xstat без какой-либо фильтрации.
00:03:12И это позволило исследователям безопасности
00:03:15выполнить команду, которая не была ограничена
00:03:18тем репозиторием, в который они пушили,
00:03:21а вместо этого свободно запускалась на серверах GitHub
00:03:24и могла получать доступ к другим репозиториям,
00:03:27включая приватные.
00:03:29Напомню, об этой уязвимости сообщили, ее исправили,
00:03:33и ее больше не существует,
00:03:35но масштаб проблемы очевиден.
00:03:39Я имею в виду, это невероятно серьезно — иметь уязвимость,
00:03:43позволяющую удаленно выполнять код на github.com.
00:03:45Это действительно грандиозный прокол.
00:03:47Да, это большая беда,
00:03:48но, разумеется, это не единственная проблема.
00:03:5123 апреля, то есть всего на несколько дней раньше,
00:03:56произошел крупный инцидент с очередями слияния (merge queues).
00:04:01Очереди слияния GitHub, если вы вдруг не знали,
00:04:04это функция, предназначенная для репозиториев
00:04:07с высокой активностью и интенсивной разработкой,
00:04:11куда поступает очень много пул-реквестов.
00:04:13И чтобы вам не приходилось завершать слияние
00:04:16каждого пул-реквеста перед отправкой нового,
00:04:19ведь вы хотите, чтобы пул-реквест был
00:04:21согласован с актуальным состоянием репозитория,
00:04:24например, основной ветки,
00:04:26и чтобы не нужно было ждать завершения
00:04:28каждого слияния перед открытием следующего,
00:04:30была создана эта функция очередей слияния.
00:04:34Ее простая задача — фактически создавать
00:04:38некое промежуточное слияние,
00:04:42формируя новое состояние репозитория или ветки,
00:04:46с которой вы пытаетесь слиться, для каждого пул-реквеста.
00:04:49И если в цепочку пул-реквестов
00:04:51добавляется новый,
00:04:53он также объединяется с теми пул-реквестами,
00:04:57что стоят перед ним в очереди в основную ветку,
00:04:58чтобы новые пул-реквесты открывались так,
00:05:01будто предыдущие уже были успешно слиты.
00:05:05Это позволяет командам работать быстрее,
00:05:08потому что можно открывать всё новые пул-реквесты,
00:05:10не дожидаясь окончательного слияния предыдущих.
00:05:13Рано или поздно они все будут слиты,
00:05:15но это позволяет не прерывать рабочий процесс,
00:05:17что критически важно для больших команд.
00:05:19Но также крайне важно, чтобы эта функция
00:05:22работала абсолютно корректно.
00:05:24И вот 23 апреля произошло то,
00:05:28что возникла ошибка, внутренняя логическая ошибка
00:05:32в том, как GitHub разрешал эти разные пул-реквесты.
00:05:37В итоге это приводило к созданию слияния,
00:05:41которое теряло часть информации, что вело
00:05:45к невалидному коммиту и уничтожению части
00:05:49истории Git в этом месте.
00:05:50На самом деле данные не были безвозвратно утеряны,
00:05:53но функция сработала со сбоем
00:05:55и создала этот некорректный коммит.
00:05:57Это если вкратце, самая суть произошедшего.
00:06:00И это, конечно, тоже совершенно неприемлемо,
00:06:03если вы крупная компания или любой бизнес, полагающийся
00:06:06на эту фичу, и вдруг ваш проект оказывается
00:06:09в сломанном состоянии без каких-либо внятных
00:06:13объяснений — это, разумеется, недопустимо.
00:06:16И первая ваша мысль, скорее всего, будет не о том,
00:06:19что в механизме очередей слияния есть внутренний баг.
00:06:23Вы, вероятно, подумаете, что сами где-то ошиблись.
00:06:26Так что вы тратите кучу времени на поиск ошибки,
00:06:28пока не выясняется: «О нет, это всё GitHub».
00:06:30И всё это происходит в дополнение
00:06:33к постоянным проблемам с доступностью сервиса.
00:06:38Официальная страница статуса выглядит неважно,
00:06:42может быть, терпимо, но у нас нет даже
00:06:46«трех девяток» аптайма, по крайней мере для большинства систем.
00:06:49Они публикуют данные о доступности отдельно для разных узлов.
00:06:53Но картина меняется, если взглянуть
00:06:55на альтернативную страницу статуса GitHub,
00:06:57которая отслеживает аптайм иначе
00:07:00и считает каждый мелкий инцидент проблемой
00:07:04и, по сути, временем простоя.
00:07:05Там мы видим ужасающие показатели для такой критической системы,
00:07:10как GitHub. Это, конечно, совершенно неприемлемо.
00:07:14Проблемы с аптаймом тянутся последние месяцы
00:07:18и даже начались еще в прошлом году.
00:07:20Тут и там постоянно всплывают мелкие баги,
00:07:23просто они не такие громкие или важные,
00:07:26как эта уязвимость в системе безопасности.
00:07:28Но да, проблем действительно хватает,
00:07:31и GitHub на данный момент определенно стал ненадежной платформой,
00:07:36к сожалению,
00:07:38что является катастрофой, учитывая его роль и значимость,
00:07:43как я и говорил вначале, для современной разработки,
00:07:47каким бы именно направлением вы ни занимались.
00:07:50Другая проблема заключается в том, что коммуникация со стороны GitHub
00:07:54была, скажем так, весьма скудной.
00:07:59Общения было не так уж и много,
00:08:01но 28 апреля в блоге появился пост —
00:08:06еще до этой истории с уязвимостью,
00:08:10где они попытались объяснить, что происходит,
00:08:14откуда берутся все эти проблемы,
00:08:16и признали, что их стратегия коммуникации
00:08:19была не идеальной, и пообещали, что всё наладится.
00:08:23И это подводит нас к следующей части.
00:08:25В чем же корень всех бед?
00:08:28В официальном заявлении причиной назван ИИ,
00:08:32но не в том плане, что инженеры GitHub
00:08:36в Microsoft используют ИИ и выпускают кривой софт,
00:08:40выкатывая глючные обновления для сервиса.
00:08:43Возможно, это и так, но у нас нет доказательств.
00:08:47Вместо этого главная причина, указанная здесь, в том,
00:08:51что благодаря ИИ стало создаваться гораздо больше проектов,
00:08:57генерируется на порядок больше кода,
00:09:00и в конечном счете все эти проекты и весь этот код
00:09:03отправляются на GitHub.
00:09:04И они поделились некоторыми... ну,
00:09:09не то чтобы очень полезными графиками.
00:09:12Они не особо информативны, потому что нет оси Y.
00:09:14Мы не видим абсолютных цифр,
00:09:17но, конечно, можем отследить соотношения.
00:09:20И мы четко видим, что на протяжении 2025 года
00:09:23наблюдался резкий рост числа принятых пул-реквестов,
00:09:28отправленных коммитов и, само собой, открытых репозиториев.
00:09:32Это все те наши побочные проекты, которые мы теперь начинаем
00:09:34и не заканчиваем с помощью ИИ.
00:09:36А затем, в 2026 году, по всем этим показателям
00:09:41график просто взлетает ракетой куда-то в стратосферу.
00:09:46Так что да, тренд вырисовывается вполне очевидный.
00:09:49И такой трафик, подобный взрывной рост нагрузки,
00:09:54безусловно, поставил бы под удар любую систему.
00:09:58Для GitHub это особенно проблематично,
00:10:01потому что они находятся в самом разгаре миграции
00:10:05от монолитной структуры и собственных выделенных
00:10:09дата-центров или систем в облако Azure
00:10:13и перехода на более дробную микросервисную архитектуру,
00:10:17если можно так выразиться, взамен прежнего монолита.
00:10:21Этот процесс начался еще задолго до 2026 года.
00:10:26Но теперь получается, что на этот процесс миграции
00:10:31наложился колоссальный всплеск спроса.
00:10:34что означает, что даже в процессе миграции
00:10:36вам приходится как-то стабилизировать текущую систему,
00:10:39продолжая при этом переезд,
00:10:40что, как мы надеемся, поможет справиться с ростом
00:10:44трафика в будущем.
00:10:46Таковы надежды, конечно, без гарантий.
00:10:50Но, разумеется, это то, с чем GitHub приходится иметь дело.
00:10:52Здесь они заявляют, что начали выполнять план
00:10:56по десятикратному увеличению мощностей GitHub в октябре 2025 года.
00:11:01Так что можно сказать, примерно тогда они увидели,
00:11:04что показатели ползут вверх.
00:11:06То есть они могли это видеть и раньше,
00:11:09но именно в этот момент решили, что нужно увеличить мощности в 10 раз.
00:11:13А затем, в феврале 2026 года, они поняли:
00:11:16«Окей, нам нужно 30-кратное увеличение, а не 10-кратное», потому что...
00:11:20ну, из-за того самого развития событий здесь, верно?
00:11:22И это, конечно, должно делаться в дополнение к миграции.
00:11:28А это, очевидно, колоссальная задача.
00:11:33Сейчас это часть Microsoft, так что это не какой-то маленький стартап,
00:11:37но, тем не менее, задача пугающая.
00:11:39И это один из аспектов всей этой проблемы GitHub,
00:11:44в котором я им сочувствую, потому что, думаю, легко
00:11:47хейтить GitHub и относиться к нему с пренебрежением.
00:11:51И вы определенно имеете на это право.
00:11:52Я еще вернусь к другим проблемам, которые действительно плохи.
00:11:56Но такой рост трафика стал бы огромной проблемой
00:11:59для любой системы, для любой компании на рынке.
00:12:03И трудно поверить, что какой-либо конкурент GitHub
00:12:07справился бы в этой ситуации лучше.
00:12:09Тем не менее, это не оправдание.
00:12:10Это часть Microsoft.
00:12:12И следовательно, у них точно есть ресурсы,
00:12:16чтобы пройти через этот переход и адаптировать свои системы
00:12:20к этому новому миру и к новому объему трафика.
00:12:24Но есть еще одна важная проблема с GitHub.
00:12:28И заключается она в том, что у него больше нет гендиректора.
00:12:32Предыдущий CEO, Томас, Томас Домке,
00:12:37ушел на пенсию, покинул пост или объявил об уходе
00:12:41в августе 2025 года.
00:12:43И Microsoft не назначила нового генерального директора.
00:12:48Вместо этого GitHub стал частью Core AI —
00:12:51внутреннего подразделения Microsoft, которое, как ясно из названия,
00:12:56целиком посвящено ИИ и созданию ИИ-инструментов и платформ.
00:13:01И GitHub теперь часть этого процесса.
00:13:03Так что миссия GitHub с точки зрения Microsoft явно
00:13:07заключается в том, чтобы стать частью этой цепочки инструментов ИИ,
00:13:11частью этой ИИ-революции.
00:13:13И очевидно, что Microsoft внедряет Co-Pilot
00:13:15во все свои продукты.
00:13:16И действительно, на GitHub Universe 2023
00:13:20они уже заявили, что превратят GitHub
00:13:24в платформу для разработчиков на базе ИИ,
00:13:28где GitHub будет повсюду.
00:13:30Это включает в себя такие вещи, как новые функции,
00:13:32помогающие создавать тикеты с помощью GitHub Co-Pilot,
00:13:36что является огромной проблемой для мейнтейнеров опенсорса,
00:13:39а также само присутствие GitHub Co-Pilot
00:13:43буквально везде на GitHub.
00:13:44На GitHub есть этот раздел Agent HQ,
00:13:48[github.com/copilot](https://github.com/copilot),
00:13:49где вы можете взаимодействовать с GitHub Co-Pilot
00:13:52и работать над кодом прямо в GitHub Copilot,
00:13:55даже не открывая локальную среду разработки или ИИ-агента,
00:14:00и многие другие функции.
00:14:02GitHub Copilot теперь повсюду в GitHub,
00:14:05так же как Copilot присутствует везде
00:14:07в продуктах Microsoft, я полагаю.
00:14:10И это, конечно, четкое стратегическое решение,
00:14:14которое идет вразрез с истинной миссией GitHub,
00:14:19по крайней мере той, что была у него раньше.
00:14:23Потому что, как я упоминал в самом начале,
00:14:25GitHub важен для разных разработчиков
00:14:29и для самых разных сценариев использования.
00:14:31Мейнтейнеры открытого кода используют его для хранения
00:14:36исходного кода и совместной работы с коллегами
00:14:39и другими участниками сообщества.
00:14:41Задачи (Issues) жизненно важны для выявления ошибок
00:14:45и работы над ними.
00:14:46Пул-реквесты важны для того, чтобы другие люди
00:14:50могли внести свой вклад в кодовую базу.
00:14:52Обсуждения отлично подходят для проработки новых функций
00:14:55или направлений развития репозитория или библиотеки.
00:15:01Здесь есть много функций,
00:15:03которые помогают мейнтейнерам open source,
00:15:04ну или, по крайней мере, помогали раньше.
00:15:07Другие используют GitHub просто как ресурс
00:15:11для хранения ссылок или документации,
00:15:13как все эти репозитории «awesome Go» или «awesome Rust»,
00:15:17где можно легко найти нужные материалы,
00:15:20если вы хотите работать с Go или Rust.
00:15:22Я также использую GitHub для размещения ресурсов к курсам,
00:15:26например, для моего курса по Codex,
00:15:29и для многих других программ обучения.
00:15:31Так что GitHub можно использовать даже
00:15:33просто как своего рода хранилище документов.
00:15:36И, конечно же, GitHub можно использовать для CI/CD.
00:15:40В компании вы можете использовать GitHub,
00:15:43чтобы хранить там свой исходный код,
00:15:46чтобы члены команды работали над ним сообща
00:15:50через пул-реквесты и прочее.
00:15:52И зачастую GitHub
00:15:54также является частью конвейера CI/CD,
00:15:57где, например, новый пуш в основную ветку
00:15:59запускает процесс сборки и развертывания.
00:16:02Это может быть реализовано через GitHub Actions,
00:16:05хотя у этого продукта есть свои проблемы.
00:16:08Но, разумеется, это может быть и триггером для CI/CD
00:16:12у любого другого провайдера, а не только в GitHub Actions.
00:16:16Так что GitHub играет очень важную роль
00:16:20в классической, традиционной разработке.
00:16:24Но в Microsoft решили: «Нет,»
00:16:27«он должен стать платформой на базе ИИ»,
00:16:31а не просто платформой для разработчиков.
00:16:33И здесь возникает определенное несоответствие.
00:16:37Разработчикам не обязательно нужен Copilot
00:16:41в каждом аспекте GitHub.
00:16:43Думаю, пользователи продуктов Microsoft в целом
00:16:46не хотят видеть его во всех приложениях,
00:16:48но это уже другая история.
00:16:49GitHub стал пренебрегать основными функциями,
00:16:53которые действительно важны для разработчиков.
00:16:56Взять хотя бы разработку открытого ПО.
00:17:00Сопровождающие опенсорс-проектов буквально тонут
00:17:03в сгенерированных ИИ задачах и пул-реквестах.
00:17:07Проблема здесь, конечно, в асимметрии.
00:17:10С помощью ИИ легко создавать код или тикеты,
00:17:14но проверять всё это гораздо сложнее.
00:17:19То есть просматривать этот сгенерированный код и задачи.
00:17:24И это знает любой разработчик,
00:17:26который когда-либо работал с ИИ.
00:17:27Вы можете легко запустить три и более ИИ-агента,
00:17:30чтобы они работали над вашими проектами,
00:17:32совершенно не касаясь GitHub.
00:17:33Это можно делать локально через codecs,
00:17:35Claude Code и так далее.
00:17:36Но если вы не сторонник слепого кодинга,
00:17:39чего делать, по-моему, не стоит,
00:17:41вам в какой-то момент придется проверять этот код.
00:17:44А это требует времени.
00:17:45И это не особо весело, по крайней мере для меня.
00:17:48Так вот, если запустить трех агентов,
00:17:51вам придется проверять результат работы троих.
00:17:54Можно уменьшить число агентов, если это перебор
00:17:57и вы понимаете, что ваша продуктивность
00:17:59от этого не растет.
00:18:00Но когда вы мейнтейнер опенсорса на GitHub,
00:18:03вы тонете в ИИ-задачах и пул-реквестах,
00:18:07и у вас обычно есть два основных пути.
00:18:09Можно их игнорировать, что лишает их смысла,
00:18:13хотя это, очевидно, вполне рабочая стратегия.
00:18:16Либо вы пытаетесь со всем этим разобраться
00:18:18и выгораете, потому что нагрузки слишком много.
00:18:21Ведь в отличие от личной разработки,
00:18:25вы не можете просто взять и ограничить поток
00:18:29входящих тикетов и пул-реквестов.
00:18:30У себя вы можете использовать меньше агентов,
00:18:33если чувствуете, что не справляетесь
00:18:36с тем объемом, который они выдают.
00:18:38С публичными репозиториями так не выйдет.
00:18:41Вы не контролируете, сколько людей пришлют вам
00:18:45созданные нейронкой задачи или пул-реквесты.
00:18:49Это огромная проблема для мейнтейнеров,
00:18:53и именно поэтому всё опенсорс-сообщество
00:18:56и сама его философия сейчас
00:18:59в глубоком кризисе из-за ИИ.
00:19:04И GitHub в этом никак не помогает.
00:19:06Напротив, они делают всё наоборот.
00:19:08Они активно упрощают процесс рассылки
00:19:13этого «мусорного» ИИ-контента.
00:19:15А мейнтейнерам и разработчикам нужны
00:19:18эффективные инструменты для борьбы
00:19:22со всем этим ИИ-спамом.
00:19:25Но GitHub над этим не работает.
00:19:27Похоже, это просто не входит в их стратегию.
00:19:29Возможно, когда-нибудь это изменится.
00:19:30Тот официальный пост GitHub, о котором я говорил,
00:19:35в основном посвящен надежности и аптайму,
00:19:39тому, что они хотят быть прозрачнее и так далее.
00:19:41Но они также упомянули о своем обязательстве
00:19:44поддерживать разработчиков.
00:19:46Посмотрим, но я не слишком оптимистичен,
00:19:49потому что в конечном счете это часть Microsoft,
00:19:52а у них здесь своя собственная стратегия.
00:19:55Но что же это значит для GitHub?
00:19:59Пришло ли время для миграции?
00:20:02В соцсети X кое-кто уже поговаривает,
00:20:05что пора искать альтернативу GitHub.
00:20:08Я знаю, что некоторые проекты уже ушли.
00:20:12Zig, пожалуй, самый заметный пример.
00:20:15В ноябре 2025 года они переехали на Codeberg.
00:20:20Но давайте смотреть на вещи реально.
00:20:22Во-первых, как я уже говорил,
00:20:24тот объем трафика, который идет на GitHub,
00:20:28раздавил бы любого конкурента.
00:20:31Скорее всего, даже быстрее, чем GitHub,
00:20:32ведь за ними не стоит Microsoft.
00:20:35Так что замены GitHub мы точно не увидим.
00:20:40И хотя отдельные проекты,
00:20:42особенно опенсорсные, могут покинуть GitHub
00:20:45по вполне понятным мне причинам,
00:20:48все эти компании и частные разработчики
00:20:52никуда, скорее всего, не денутся.
00:20:54У GitHub, несмотря на все его проблемы,
00:20:57очень богатый функционал, который стал частью
00:21:02рабочих процессов множества программистов.
00:21:06Особенно это касается компаний,
00:21:08им не так-то просто заменить GitHub
00:21:11на какого-то другого провайдера.
00:21:13Хотя проблемы с доступностью сервиса
00:21:15критичны и для бизнеса тоже,
00:21:18они будут готовы терпеть гораздо больше,
00:21:23прежде чем всерьез задумаются о переезде.
00:21:25Я в этом уверен.
00:21:26GitHub — слишком важная платформа.
00:21:30Это главное место для облачного хранения,
00:21:35работы и коллаборации над Git-проектами.
00:21:39Так что он никуда не исчезнет,
00:21:43даже если ситуация ухудшится.
00:21:45Конечно, со временем люди начнут уходить,
00:21:47если GitHub ничего не предпримет,
00:21:49но они явно что-то делают,
00:21:50как минимум в плане аптайма и надежности.
00:21:55Что касается опенсорса и проблем
00:21:58с ИИ-мусором — поживем-увидим.
00:22:01Даже здесь, я верю, что GitHub слишком важен
00:22:07и дает слишком много преимуществ мейнтейнерам,
00:22:10чтобы они просто так взяли и ушли.
00:22:14Но я вполне понимаю, когда отдельные проекты
00:22:17Возможно, они снова назначат генерального директора в GitHub.
00:22:20И, может быть, они поймут его важность.
00:22:23он останется стандартом.
00:22:24Тем не менее, остается только надеяться,
00:22:28что эта ситуация станет звоночком для Microsoft.
00:22:33Может быть, они снова назначат в GitHub CEO.
00:22:38Может, они осознают его значимость.
00:22:41Поймут, что это прежде всего платформа
00:22:45для разработки, а не просто ИИ-площадка.
00:22:49Но да, остается только надеяться.
00:22:52Не знаю, когда это случится и случится ли вообще.
00:22:55Но в общем, такова сейчас ситуация с GitHub.
00:23:00Всё плохо, действительно плохо.
00:23:03И в ближайшем будущем лучше не станет,
00:23:06но хотя бы надежность, будем надеяться,
00:23:11повысится к концу этого года.
00:23:13В общем, посмотрим.