Разработка и инженерия

Очередной шедевр от Cloudflare — подробный отчет об аварии 2 июля.

Рассказ начинается с личной истории. Девять лет назад автор был клиентом, а не сотрудником, и основатель компании Мэтью Принс написал ему детальное письмо в ответ на жалобу о проблеме. Теперь он пишет аналогичный текст нам после падения 2 июля.

Внутри — как у них устроен процесс разработки и деплоя, 11 причин, сочетание которых привело к аварии; что они сделали, чтобы подобная ситуация не повторилась, какие дальнейшие планы и даже разбор, как именно регулярное выражение съело все ресурсы процессора.

После такого ответа я доверяю Cloudflare гораздо больше, чем до аварии. Ошибки и аварии в сложных IT-системах неизбежны. Важно, что они вызваны не вопиющей некомпетентностью и как компания на них реагирует, учится ли она на ошибках. Побольше бы таких текстов и таких компаний.

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

Форма подачи 🔥 и на десктопе и в мобиле.

http://boringtechnology.club

☙

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

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

Ищите таких программистов, говорите с ними на равных и будет вам счастье.

С днём рождения, Лёша!

Выяснили сегодня, что nginx плохо относится к кукам с дефисами в имени. Если кука не существует — то считает, что значение cookie-name равно всему, что идет после дефиса — -name в этом примере. Могли бы показывать какое-то уведомление, когда используешь такую бяку в конфигурации.

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

Интересно, что ввели мы дополнительную куку из-за изменений в Safari. Для большей приватности Safari начал сбрасывать куку поставленную через javascript, а не с сервера (чтобы рекламщики не могли следить за всеми). Если вы владелец макбука или айфона и вас регулярно выкидывает с сайтов — проблема именно в этом.

Такая вот цепочка событий.

upd: читатели замечают, что это поведение nginx — известная «фича, а не баг». Вот так и выдали мы себя, что не настоящие мы сварщики (админы), а только мимикрируем :)

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

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

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

Один из крупнейших и самый дешевый CDN на свете Cloudflare испытывает проблемы с сетью.

Многие сайты могут быть недоступны. Я лично помогал включить Cloudflare десятку медиа, у RAWG отвалились картинки.

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

Статус тут.

Дима Олляк делится в нашем уютном чате хорошим:

«Тем временем на Хабре руководитель разработки российского Леруа Мерлена увлекательно рассказал, как они вдвухсотером пилят российский Леруа с джавой и микросервисами. За неимением апдейтов техблога Медузы вполне годная статья.

Бонустрек — холодной душ от счастливых покупателей в каментах: „Как уже сказали выше, могут эти 200 человек пожалуйста пофиксить поиск?“»

Гугл опубликовал публичный постмортем про воскресную аварию. Текст длинный, но суть простая: у них ломается сеть, если специальная программа не подвозит правильную конфигурацию сети (BGP) каждые пару минут. Несколько копий этой программы запущены на отдельных серверах в каждом дата-центре (отказоустойчивость!). Эти серверы включает-выключает другая программа управления конфигурацией. Во второй программе была ошибка, из-за которой она выключила все копии первой программы. Через пару минут после этого протухли BGP-анонсы и развалилась сеть.

Из-за сломанной сети были недоступны внутренние инструменты, которыми пользуются сисадмины при исправлении проблем. Гугл говорит, что у них есть специальные бункеры с какими-то особыми доступами, но пока админы туда доехали — прошло дополнительное время. Самое главное, что система конфигурации потеряла своё внутреннее состояние и админам пришлось заново настраивать всё руками — это заняло очень много времени.

Чинят тем, что 1) запретят подсистеме выключения задач тушить сразу несколько серваков 2) система не будут терять состояние при потушенных серверах (не придется настраивать её заново руками) 3) сеть будет дольше работать без внешней поддержки программой управления (самое очевидное решение).

❧

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

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

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

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

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

5/5

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

Перевёл сегодня интерфейс одного проекта с одного языка на другой с помощью Google Cloud Translation API.

Сделать сначала грубый машинный перевод, посмотреть его «в живую» и потом писать нормальный перевод — классный способ. Сразу видно, какие интерфейсные элементы вообще не заведены в систему локализации.

Я попробовал несколько разных систем машинного перевода для этой задачи, самая хорошая - Google Translate. Она даже теги span и переменные в фигурных скобках не корёжит, переводит только тексты. Учитывая бесплатные полмиллиона символов перевода - даже с настройкой биллинга не придётся заморачиваться, скорее всего. Регистрируетесь в Google Cloud Platform, пишете небольшой питоновский скрипт и вперёд. Можете взять мой за основу.

Конечно, локализация (l10n) и интернационализация (i18n) проекта (разница между ними) — гораздо больше, чем просто перевод; а даже организация перевода для большого проекта с несколькими переводчиками — то ещё развлечение. Но это тема для гораздо более длинного поста.

Прошлой ночью по Москве у гугла прилегла сеть в Штатах. 4 с половиной часа, с 12 до 17 PT. Проблемы затронули как собственные сервисы Gmail, YouTube и прочие так и клиентов облака: Snapchat и другие.

Гугл потерял «три девятки» (99.99% доступности сервисов) в этом квартале.

С нетерпением ждём постмортем. Ожидаемо, что надёжность сети - последняя нерешенная проблема облаков. Интересно, как они её в результате решат и решат ли в принципе.

Мои сочувствия ребятам из России, у которых пользователи/клиенты в штатах (обычно я им завидую:). У вас была горячая ночь.

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