запуск завтра
о каналепоиск

авария

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

So in other words, out of 5 backup/replication techniques deployed none are working reliably or set up in the first place.

Guys, don't be too hard on yourself. Все мы там были. Несколько месяцев назад аналогичная история произошла в медузе - монга двухлетней давности оказалась без бэкапов. Обнаружили мы это после того, как случайно удалили не тот сервер в админке хостера.

Единственный способ быть уверенным, что все в порядке - попробовать поднять реплику продакшена без продакшена, тестировать не бэкапы, а recovery plan.

Наслаждайтесь: https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

Пользуетесь сервисами Яндекса для бизнеса? Этот пост для вас.

Только что в комметариях в фб у Тани Бибиковой (infotanka) произошло удивительное:

https://www.facebook.com/photo.php?fbid=10154281029159597&set=a.10151249640244597.475532.772799596&type=3

13 октября удалились все корпоративные ящики «Лаборатории данных» в Яндекс.Почте, без возможности восстановления, техподдержка отмораживается. В комментарии сразу же пришли друзья-яндексоиды, подключилось телефонное право.

6 декабря (!) Таня публикует описание, что случилось:
> Мы хотели дать админские права коллеге с адресом username@dl.ru, но оказалось, что Яндекс умеет только username@ya.ru делать админами. В итоге приглашение улетело левому чуваку, он пришёл и, не разобравшись, всё удалил.

Но самый огонь в том, что в комментариях нет никого из Яндекса, кто бы объяснил, что они сделали, чтобы такого не случилось в будущем. 🔥

Бесплатный сыр.

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

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

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

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

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

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

У Амазона серьёзные проблемы с облаком, s3 (один из крупнейших сервисов хранения файлов в мире, им пользуются многие стартапы, которыми пользуетесь вы) возвращает 500 во многих регионах, недавно упал EBS в двух регионах. Это происходит уже больше часа - а значит они потеряли право говорить "доступность 99.999%" - это 53 минуты отказа в год.

Весь интернет посыпался как домино: heroku, Trello, slack, Quora, Netflix, you name it.

Интересно, что в status dashboard у Амазона все зелененькое. Ещё интереснее, что сайт Amazon.com работает отлично - там чуваки умеют программировать без единой точки отказа.

За новостями следите в треде на HN, раз Амазон не готов признавать ошибок: https://news.ycombinator.com/item?id=13755673

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

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

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

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

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

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

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

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

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

Описание вчерашней сетевой аварии опубликовал в своем блоге Cloudflare. Ниже мой перевод первого абзаца на скорую руку, оригинал лучше:

Сегодня в 10:40 UTC у интернета случился сердечный приступ. Небольшая компания в Северной Пенсильвании стала избранным путем (preferred path) многих соединений крупнейшего транзитного провайдера Verizon. Представьте, что Яндекс.Карты завернули весь трафик МКАДа через маленький переулок. Клаудфлер, вместе с многими другими хостингами стал недоступен для больших частей интернета. Всё началось с того, что Verizon анонсировал свои внутренние пути во внешний интернет. Почему так вышло — читайте дальше.

Обожаю, когда объясняют сложные события с самых основ и не упускают важных деталей, раскрывая их суть по мере рассказа. ❤️💪

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

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

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