авария

Все мы были в ситуации, когда тест идет совсем не так, как мы планировали.

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

Поделюсь, как я тестировал пуши в Медузе. В какой-то момент я придумал отправлять в тестовом пуше ровно то же содержимое, которое было в предыдущем продакшен пуше. Если такой тест протечет на продакшен — большинство людей подумают, что это глюк телефона (или их самих глючит), но в любом случае — такая проблема мало кого удивит. «тест» или того хуже «111 zaebalo» — гораздо хуже. Признаюсь, что порой я тестировал пуши «путин умер», но повторять такое я не рекомендую.

Интересно, это сообщение пришло всем миллионам клиентов МТС или только какой-то небольшой группе? В любом случае: 8 вечера по Москве - не лучшее время для тестов на продакшене. Привет, МТС!

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

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

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

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

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

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

Basecamp уже несколько часов в read-only. У чуваков переполнились первичные ключи в таблице в базе (были в int, нужно было bigint).

Работы всё ещё идут, но они ведут идеальный status report и уже написали два детальных объяснения (сначала покороче и потом подлиннее), что идет не так, почему так получилось и что они делают для починки. ИДЕАЛЬНО.

Github на прошлой неделе опубликовал postmortem, почему они лежали сутки. Язык тяжелый и перегружен жаргоном, executive summary отсутствует как класс, куча воды про «вы для нас очень важны». Текст — 3/5. Были бы на самом деле важны — сделали бы учения нормальные. Тоже мне engineering excellence.

У гитхаба развалилась база в 2 ночи, не удивляйтесь, что не можете сделать PR. Обещают починить в ближайшие минуты.

Пока московская часовая зона спала, ютуб успел полежать с 4:41 до 6 утра — 1ч и 21м, если верить официальному аккаунту. Никогда такого не видел. Интересно узнать, что у них там случилось; пока подробностей 0. Если бы был такой тотализатор — я бы поставил на то, что опять сеть упала из-за ошибок конфигурации.

Гугл опубликовал post-mortem про то, почему в среду Google Cloud Global Loadbalancer лежал по всему миру полчаса. Это big deal, потому что одно из базовых обещаний крупных облачных вендоров — никаких кросс-региональных проблем. Деплоите свой супер важный сайт на 2 региона и считаете, что по хостингу SLA 100%. Ага.

Баг в коде не словили на стейджинге и на тестовой раскладке, потому что он проявлялся только при определенной конфигурации.

Интересно, что они заметили проблему через 2 минуты после её начала, 25 минут прогали фикс, 5 минут оно раскатывалось по продакшену и ещё 6 минут приходило в норму.

Жаркие же 36 минут это были для инженеров на дежурстве!

У Амазона лежал сайт сразу после начала дня скидок Prime Day. Тонны денег вложены в рекламу, за 40 часов Амазон планирует продать товаров на 4 миллиарда долларов и сайт сломался. Не боги горшки обжигают.

Жаль, что post mortem вряд ли появится в публичном доступе :(

Вспомнил, как именно сломался сервер с первой версией. Мы удалили его в админке хостера, перепутав один сервер с другим.

Такие дела.