#инцидент

19 постов
пост №2062

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

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

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

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

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

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

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

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

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

пост №2055

Очень неприятная история с потерей данных на гитхабе.

Если у вас активная разработка и пул-реквесты конкурируют между собой при мерже в main, то гитхаб предлагает решить это через merge queue, который мержит PR-ы по очереди.

Так вот из-за бага в коде, часть ранее замерженных коммитов пропадала из main в течение четырех с половиной часов начиная с 2026-04-23 16:05 UTC.

Страшно представить, как такое дебагать.

И как вообще вести разработку, если не можешь доверять системе контроля версий, что она не потеряет коммиты? 🤷‍♂️

Уверен, что по всему миру инженеры думали, что сходят с ума.

Ну а дальше github предлагает исправлять это руками... Sic transit gloria mundi

пост №1546

Хероку (один из лучших облачных хостингов) взломали примерно 15 апреля (ну, они узнали о взломе 15 апреля), но насколько все плохо и к чему получили доступ взломщики — неизвестно.

Сегодня вот прислали письмо, что принудительно сбросят пароли для моей безопасности.

Ссылаются на «предыдущие уведомления», но никаких уведомлений в почте, конечно, нет.

Два варианта: либо их вообще целиком взломали и пиарщики хорошо наводят муть, либо, что более вероятно, компания стоимостью в миллиарды долларов, нацеленная на разработчиков, не умеет говорить с этими самыми разработчиками об инцидентах безопасности. Не боги горшки обжигают, а скорее — король голый :(

Пример, как не писать о взломах — тут, стенания hackernews по теме — здесь.

По делу: сбросьте пароли, секреты и токены, которые хранились в хероку или засветились в логах внутри хероку и молитесь.

P. S. Иронично, что Хероку отказался предоставлять сервис пользователям из России, так что Федя перенёс все приложения из Хероку на собственные серверы месяц назад.

пост №959

Поведение при факапе - отдельное искусство.

Сильно упрощая: хостер Digitalocean заблокировал аккаунт клиента и потушил продакшен-серверы стартапа без предупреждения, не дал даже данные выгрузить (автоматический антифрод, да).

Твит про это капитально бомбанул, на ситуацию обратил внимание основатель компании и вот Digitalocean публикует образцовый постмортем.

В нем есть все: и честная фактология произошедшего, и признание ошибок и четкий, полный план что они делают для того, чтобы не допустить эту ошибку в будущем.

5/5

P.S. Ещё одно напоминание об опасности держать все яйца в одной корзине. Как минимум бэкапы должны быть у второго провайдера.

пост №924

Яндекс выкатил пресс-релиз на Роеме. В таймлайне не указано, когда они уведомили пользователей о проишествии, а ведь поддержка — один из параметров, по которому мы выбираем хостинг.

«Мы уже работаем над формированием мер для предотвращения повторения подобного инцидента в будущем и в ближайшее время проинформируем о дальнейших шагах всех пользователей.»

Интересно, будет ли более подробный post mortem в этом информировании?

P.S. А ведь было время, когда Яндекс говорил отличным русским языком; помню, студентом мечтал там работать в том числе из-за языка на сайте (древнегреческое «красивый не может быть плохим»). Эх.

Upd: ну наконец-то приличный текст от руководителя Яндекс.Облака. Был бы я журналистом — продолжил бы долбить про «считаете ли вы нормальным писать пользователям об удалении их сервера через 6 часа, а не сразу же», но думаю, что эта история и так заняла слишком много внимания и нечего так напрыгивать на национальное достояние. ❤️ спокойной ночи

пост №922

Ходят слухи (пикабу, хабр), что Яндекс вчера случайно удалил виртуальные серверы клиентов в своем облаке (человеческий фактор).

Это отличное напоминание настроить бекапы (если вдруг их нет) и проверить, как работают процедуры восстановления.

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

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

Интересно, там было затронуто так мало машин, что они не видят видят причин официально комментировать? Классическое «это затронуло 0.004% клиентов и вот что мы сделали, чтобы такого больше не случилось» — тоже часть работы.

пост №893

Пока мы спали, фейсбук с инстаграмом заболели и до сих пор не до конца здоровы. Последнее обновление статуса от фб - 12 часов назад «разбираемся, до сих пор проблемы».

Жалко, что искусство менеджить кризисные ситуации и искусство постмортема так не развиты. Недавно чуть ломался Gmail (очень редко бывает) и думаю, что мы никогда не узнаем, что же там произошло.

Вот пример идеального поведения в похожей ситуации от Basecamp и DHH.

Лично я люблю разруливать кризисные ситуации. Думаю, что это чувство, которое есть у гонщиков на высокой скорости и у спортсменов. Когда высоки ставки, высокие риски и благодаря профессионализму и удаче получается сделать красиво. Или удача отвернулась в этот раз, но ты сделал все, что мог и это все равно красиво.

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

пост №855

Вообще, герой дня, я думаю, не только МТС, но и https://platformalp.ru (какая-то система для быстрой сборки лендосов), на которой припаркован этот прекрасный поддомен.

Вот про эту ситуацию точно был бы бомбический доклад на конференцию, жаль никто не расскажет :((

Я бы на месте безопасников МТС вырубил домен по-быстрому (но у них такой возможности нет, TTL большой). Это, кстати, одна из причин, почему стандартным TTL доменов нужно устанавливать 5 минут.

пост №845

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

Они сломались почти двое суток назад. 6 часов у них заняло признать ошибку в твиттере. Почитайте обсуждение под этим твитом; они в какой-то момент просто выключили status page (страницу, отображающую статус сервиса и ошибки на нем) — обязательный элемент любой сервисной компании.

После этого они сделали 6 твитов вида «ваш звонок очень важен для нас, оставайтесь на линии». Последний твит — 10 часов назад «часть починили, ещё что-то чиним, сорян».

Это жесть. Худшая антиреклама критичного для бизнеса сервиса.

Интересно, будут ли комментарии материнской компании — Mailchimp и стоит ли ожидать такого же отношения к клиентам в случае проблем от них? Ничего святого.

P.S. Для транзакционных писем рекомендую использовать Amazon SES. Дешево и надежно.