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

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

Вот например:

1. Инженерия — про числа. Анализ без чисел — мнение.

20. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately. / Плохая идея с хорошей презентацией рано или поздно развалится. Хорошую идею презентованную плохо выкинут сразу же.

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

24. It's called a "Work Breakdown Structure" because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it.

33. Хороший план исполненный сегодня лучше, чем идеальный план завтра.

40. (McBryan's Law) You can't make it better until you make it work. / Ты не можешь улучшить что-то, пока не заставишь это что-то выполнять свою функцию.

Как не уронить свой сервис под нагрузкой, на примере Signal.

Люди массово переходят из вацапа в Signal. Серверы Signal не выдержали и совсем лежали почти 14 часов, а испытывали серьезные трудности больше суток. Не лучшее время, чтобы падать :( Официальный твиттер сигнала при этом хранил молчание, будто это не модный стартап, а какая-то древняя корпорация. Жаль. Надеюсь, позже они опубликуют подробный разбор, что случилось.

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

В одном проекте именно так мы и сделали. Всё было хорошо, пока серверу не стало плохо на пару минут. Если обычно на сервер приходили 100 запросов в минуту (полтора запроса в секунду), то за три минуты скопились 300 запросов и теперь, стоило серверу очухаться, как ему насыпали все 300 запросов в одну секунду. То есть для сервера это выглядело как рост нагрузки в 200 раз и он опять ложился под нагрузкой. Очень неприятная ситуация. Мы сами себя задидосили, своими же собственными мобильными приложениями. 🙈

Есть две компоненты решения этой проблемы:

🛑 Первая: сервер должен уметь ответить «довольно!», и клиенты должны перестать повторять запрос, если получили такой ответ. Интересно, что именно этой функции в Android-клиенте Signal не было и они добавили её во время аварии.

⏱ Вторая, более сложная и интересная, но тоже классическая: exponential backoff (экспоненциальная задержка). Идея очень простая: если сервер не ответил в первый раз — ждем 1 секунду и повторяем запрос. Во второй раз — ждем 2 секунды, в третий — 4, в четвертый — 8. То есть с каждой неуспешной попыткой, даем серверу больше времени прийти в себя. У Signal эта функция реализована, но во время аварии они добавили jitter — небольшую случайную задержку, чтобы клиенты не набегали на серверу толпой, через одинаковые интервалы времени после его падения, а нагрузка была более плавной. Обычно, в этом же коде реализуют ещё паттерн circuit breaker, когда после определённого числа ошибок «выбивает пробки» и запросы прекращаются совсем.

Используйте оба приема и будьте здоровы!

💭 Есть твит и телеграм-пост в популярном канале, в которых утверждается, что причина падения сигнала — в само-дидосе (мол, анекдот). Это маловероятно. Во первых, exponential Backoff в сигнал внедрили больше 2 лет назад и он здорово распределяет нагрузку; во вторых, изменения коснулись только Android клиента. Не верьте советским газетам, читайте первоисточники.

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

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

Хороший канал про аналитику, ту, которая с числами и базами данных, от чувака в теме. И название подходящее — @leftjoin. Особенно хорошо, что много репостов — можно полистать вверх и обнаружить все важные каналы про аналитику.

Cloudflare готовится перевернуть рынок хостинга веб-приложений. Длинный пост, но технологии на самом деле поразительные.

Исторически, Cloudflare — крупный и агрессивный игрок на рынке CDN, то есть они умеют с минимальной задержкой и максимальной скоростью отдавать статический контент: картинки или страницы, которые одинаковые для всех пользователей. Они забирают их с ваших серверов, копируют (кешируют) на сотни своих серверов и отдают пользователю. Прикол в том, что у Cloudflare есть свои серверы в 200 главных точках обмена трафиком, 99% пользователей интернета живут ближе, чем в сотне километров от сервера Cloudflare. Это называется edge-network, пограничная сеть, в смысле та, которая граничит с пользователями. Небольшое расстояние и оптимизированные серверы означают, что статический контент будет грузиться мгновенно.

Проблема в том, что большинство страниц — динамические. Например, гугл-документ или мою ленту фейсбука кешировать на edge смысла нет — никому кроме меня она не нужна, да и мне интересна только самая последняя версия документа, и я его только что отредактировал. Исторически это означает, что нам нужно вести все эти вычисления новых страниц где-то на центральном сервере. У крупных компаний вроде гугла или фейсбука обычно есть несколько крупных серверных ферм на каждом континенте, поближе к пользователям, так что пользователи из России кучкуются на европейских серверах, а американцы — на штатовских. Это всё требует довольно сложную инфраструктуру, маленьким компаниям недоступную. Облака Амазона и другие конкуренты пытаются решить эту проблему, но без поллитра во всех их рычажках не разберешься.

Кажется, у Cloudflare получилось придумать элегантное, красивое решение для динамических страниц, которое работает прямо на edge-серверах! Встречайте Cloudflare Workers и Durable Objects.

Cloudflare Workers — облачные функции, в Амазоне они называются лямбды (lambda@edge). То есть вы пишете программу, которая обрабатывает запросы пользователей, загружаете её в облако и она запускается по необходимости на серверах облака, прозрачно, незаметно для вас и для пользователя. Придет один пользователь — запустится одна копия, придет тысяча — запустится тысяча копий. Обычно есть время на так называемый cold start, то есть после некоторого ожидания облачная функция тушится и нужно время, чтобы она проснулась и начала отвечать на запросы. Тут этой задержки нет. Обычно вам нужно выбрать регион работы функции (помните про близость к пользователю?), тут выбирать не нужно, код запустится из самого ближнего к пользователю edge (!) сервера. Обычно эта штука стоит недешево, здесь она примерно в 3-10 раз дешевле, чем у конкурентов. Весь этот банкет за счет того, что наш код работает не контейнерах, а v8-изолятах, то есть частично — на движке гугл-хрома! (тут рассказано, как их выбрали). Но это всё закуска, кайф — дальше.

У облачных функций есть слабое место — координация пользователей. Например, мы хотим сделать копию сервиса Гугл-документов или сервис чатов — то есть несколько людей подключаются к одной программе, могут в неё писать и читать общие данные. Решений два — либо запускаем программу по-старинке, один экземпляр на сервере и храним данные в памяти (быстро!), либо запускаем в функциях, но тогда нужна будет очень быстрая общая база данных и то скорость будет ниже, потому что функциям нужно будет ходить в центральную базу данных.

Cloudflare эту проблему решили с помощью Durable Objects — это такие воркеры, которые а) уникальны, то есть гарантированно запускается только один экземпляр б) имеют доступ к надежному и быстрому хранилищу в) запускаются там, где большинство пользователей и могут самостоятельно мигрировать между серверами. Получается, что большинство операций происходят в памяти, но при этом самостоятельная серверная программа не нужна. Красиво! В статье примеры каунтера и чата, простота кода впечатляет.

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

Перечисленное выше — базовые технологии, на которых можно строить впечатляющие бизнес-решения.

Супер история о том, как Амазон чуть не умер и переехал с серверов Sun на Linux. Это — история зарождения Amazon Web Services — облака, на котором сегодня работает добрая половина интернета.

Рассказывает один из непосредственных участников.

Самые впечатляющие моменты:

❧ в 2000 лопнул пузырь доткомов — технические компании обесценились в сотни раз, на фондовом рынке кончились деньги и Amazon начал жечь собственные средства — 1 миллиард долларов в год; самой крупной статьей расходов были серверы — их делал Sun, они стоили дорого;

❧ можно было перекупить серверы Sun у компаний, обанкротившихся на пузыре доткомов, но техдир Амазона пошел ва-банк — решил переехать с Sun на обычное железо Hewlett Packard на Линуксе; ядру лунукса тогда было всего 6 лет;

❧ на время переезда они остановили ВСЮ продуктовую разработку! ВСЕ занимались только переездом. В бэклоге лежали сотни функций для увеличения продаж, но все ждали, пока закончится переезд;

❧ заморозка развития сервиса привела к падению продаж → пришлось повышать цены на товары → продажи упали ещё сильнее, запустилась «спираль смерти»;

❧ у Амазона оставалось буквально несколько кварталов до смерти, когда деньги на счету кончатся, но они успели и запустили всё нормально, стоимость масштабирования инфраструктуры упала на 80%;

❧ продажи — сезонный бизнес и Безос придумал, почему бы не сдавать простаивающие серверы в низкий сезон другим компаниям? На презентации он привел аналогию с электрической сетью — в 1900 годы каждый завод строил свою собственную электростанцию, почему бы не сделать «электрическую сеть» для IT? Плюс это круто сочеталось с его идеей разделить команды внутри компании, чтобы команды могли развиваться самостоятельно — каждая команда стала независимым API.

Ну а дальше вы знаете. Сегодня Амазон — это не только интернет-магазин, но и одна из крупнейших IT компаний планеты.

https://twitter.com/DanRose999/status/1347677573900242944

Подкаст про криптовалюты! Говорим с крутым гостем — сооснователем блокчейн-стартапа NEAR Александром Скидановым.

Криптовалюты — сложная тема, потому что в основе всех криптовалют — непростая математика. Обычно в ней разбираются в университете с мелом и доской, а мы попытались объяснить как устроен блокчейн и хэш-функции за полторы минуты голосом 🤯 (но в итоге взорвалась бомба).

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

В эпизоде: биткоин, хэш-функции, эфир, смарт-контракты, proof of stake, шардинг и новые блокчейн-протоколы. Все это в итоге может привести нас к интернету будущего, свободному от государственного или корпоративного контроля. Но не буду спойлерить, слушайте сами. Apple, Google, Castbox, Яндекс, Spotify, Overcast, ютуб и веб-версия

Карагодина Степана Ивановича расстреляли 21 января 1938. Почти у всех нас в России есть истории, связанные с большим террором — у кого-то предков сослали или расстреляли, кто-то — потомок палачей, бывает и оба вместе. Денис Карагодин уже много лет делает удивительный проект — расследует, кто и как убил его прадеда.

Позавчера Денис опубликовал на своем сайте востановленные нейросетями цветные фотографии убийц и предсмертную записку руководителя Томского НКВД. Смотреть жутко, потому что это обычные фотографии обычных людей, ничего особенного на лицах нет.

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

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

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

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

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

Cloudflare выкатил бесплатную систему аналитики сайтов. Она не использует никакие cookies, а в случае, если сайт защищен Cloudflare — не требует установки дополнительных скриптов.

Плюсы этого подхода:
1. Работает даже с включенными блокировщиками рекламы, которые часто зарезают аналитику. Вы увидите всех посетителей сайта.
2. Не добавляет никаких тормозов на сайт, что особенно важно для слабых андроидов и медленного интернета.
3. Можно обойтись без порядком надоевшего «cookie notice».

Если вы используете Google Analytics или Яндекс.Метрику для чего-то хитрого, вроде учета числа успешных заказов, нажатий на определенные кнопки сайта или дочитывания статей до определенного процента — то тут Cloudflare analytics пока не подойдет.

Базовые вещи — самые популярные страницы на сайте и число посетителей из разных стран — она уже показывает хорошо. Попробовать можно вот тут.