#надёжность

Гитхаб в последнее время сильно сбоит.

В дополнение к инциденту с merge queue, за последние дни успели сломаться поиск и показ пул-реквестов.

Техдир сервиса Владимир Федоров в своем покаянном посте пишет, что причина — во взрывном росте активности на платформе из-за нейросетей (см картинку).

Обещает, что теперь они будут работать над стабильностью, масштабируемость и перестанут гнаться за фичами.

Внешние наблюдатели подозревают две причины: 1) плохой вайбкодинг в Microsoft 2) сложный переезд с собственной инфраструктуры на Azure.

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

❧

Создать git репозиторий можно без всяких сервисов — это просто файлы на диске. Гитхаб выигрывает за счет удобного контроля доступа, интеграции с ci/cd инструментами, удобного веб-интерфейса для комментирования и тысячи мелочей.

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

Конечно, у таких сервисов огромная инерция, но очень интересно, куда побегут «модные ребята», которые задают тренды. Будет ли это новый классический конкурент со взрывным ростом или что-то распределенное и децентрализованное, соответствующее базовой философии гита?

Удивительно наблюдать, как гиганты (не)справляются с вайб-кодингом:

Github потерял последнюю девятку в своем SLA. Отдельно замечу, что status page вендоров уже давно нельзя верить и вот люди собрали собственный, народный.

Амазон был вынужден сильно замедлить выкатку фич после падений и теперь требует сениор-ревью перед релизами.

Хотя казалось бы, уж у них-то должны быть и автоматизированные тесты и легион ручных QA-инженеров!

Вот целый список подобных падений, с оценкой, сколько пользователей они задели.

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

С другой стороны, мы сейчас во временном переходном периоде, когда ещё есть программисты, которые не умеют ставить задачи (хотя и умеют писать код самостоятельно) и с этим нужно что-то делать.

В общем, быть техдиром опять становится интересно.

Очередная статья вида «делайте простые, скучные, рабочие штуки», а не «сложные, интересные и умные».

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

Амазон анонсировал сервис для «chaos engineering» в своем облаке AWS. Система выключает случайные части инфраструктуры для того, чтобы проверить, как ваш сервис умеет противостоять реальным авариям.

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

Этот подход сильно популизировал Нетфликс. В 2011 году они переехали в облако и тогда же анонсировали «chaos monkey» — «обезьяну хаоса», которая выключала (убивала) случайные продакшен серверы компании. Идея в том, что на определенном объеме серверов подобные проблемы неизбежны. Это не вопрос «сломается ли», а вопрос «когда сломается» и «сколько сломается». И лучше подготовиться и протестировать свои подходы и инструменты заранее.

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

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