FAANG Master

Основные причины багов в проде Это мой личный рейтинг причин на основе работы в 5 компаниях в 4 странах в течении почти двух десятков лет: 1) Качество разработчиков. В начале карьеры я думал, что основная причина - отсутствие процессов. Но потом на практике убедился, что это не так. Какие бы не были процессы (код ревью, тестирование, мониторинг и т.д.) вы не сможете всего предугадать и сделать защиту от дурака от всех возможных случаев. Процессы помогают, но при низком качестве разработчиков это не спасет от всех возможных случаев. В Мета процессов почти нет, тестирование минимально, при этом количество багов не такое большое. Если вы будете нанимать верхние персентили разработчиков по качеству (что бы это не значило), то они будут сразу писать правильно и без багов. 2) Конфигурации. Это вообще топ причина для фангов. Что в Амазоне, что в Facebook/Meta sev0, Large Scale Event аутеджи чаще всего случаются из-за деплоя конфигураций в прод. Конфигурации практически никак не тестируются, быстро деплоятся в прод (минуты). И никто не знает как они повлияют на систему. В них нет/мало проверок, как автоматических так и ручных. Нет особых процессов. Нет интуиции и опыта, как с кодом. Поэтому качество программистов не всегда спасает. 3) Проблемы версионирования/API. Это актуально, если у вас не монолит. Если вы дергаете какую-то зависимость, но ее поведение изменилось и стало не таким каким вы его ожидаете или изменился протокол взаимодействия, то это приводит очень часто к багам. Это типичная проблема микросервисных архитектур, особенно, когда зависимостей очень много. 4) Miscommunication, неправильное понимание задачи/бизнес логики. Тут часто не спасают ни тесты, ни качество программистов. Тесты не спасают, т.к. если вы не правильно поняли как это должно работать, то и в тесты вы будете проверять, что оно работает как ожидаете вы, а не как правильно. Качество программиста тут только гарантирует, что оно будет работать как вы ожидаете, но не как правильно. 5) Проблемы зависимостей. Это то, что сложно контролировать. Если ваша зависимость перестала работать, то тут только нужно убедиться, что ваша компонента fault tolerant и реализованы все нужные механизмы для сокращения blast radius. Например, retry, rate limiting/throttling, circuit breaker, bulk head и т.д. 6) Отсутствие достаточного тестирования. Это только на 6 месте у меня, т.к. при хорошем качестве программистов, это не обязательное условие. При низком качестве, если вы хотите минимизировать число багов - это must have. Если человек не глубоко понимает как работает, написанный им, код. Не видит все edge-cases. Не имеет опыта, не предвидит потенциальные проблемы. Если человек не внимателен к деталям, если он не умеет делать прогрессивный ролаут, мониторить, находить проблемы и их исправлять, пока они не станут влиять на систему, то все возможные тесты обязательны. 7) Отсутствие прогрессивного ролаута и мониторинга в проде. Тестировать и воспроизводить условия прода в тестах часто очень сложно. Поэтому иногда проще задеплоить это в прод, но добавить feature flag и ограничить, кто может пользоваться этим функционалом. Например, можно начать с одного пользователя или маленького процента пользователей. Посмотреть как это будет работать в условиях прода, собрать и проанализировать все метрики и потом уже разворачивать на больший процент пользователей. 8) Сложное сочетание редких событий/медленная деградация системы. Обычно, это сложно покрыть тестами заранее. Часть проблем можно отловить нагрузочным/перфоманс тестированием, но не всегда. Т.к. длительность теста ограниченна по времени и баг может воспроизводится в каких-то особенных условиях. Например, у вас какая-то проблема в коде с многопоточностью, или у вас есть подтекание памяти, которое не происходит на масштабах времени работы нагрузочного теста. Тогда проблема может возникнуть в проде через большой промежуток времени при определенных условиях, которые сложно предусмотреть во время тестирования. Также частично это покрывается качеством программистов, у кого есть опыт и интуиция возможных проблем, но далеко не всегда. Обычно, такие проблемы находят в проде, долго инвестигируются и потом уже под них добавляют какой-то особенный тест. 9) Отсутствие или плохой code review. Одна из задач code-review это найти баги. Это хоть и не основная, но важная часть. Когда пару других разрабов посмотрят на ваш код, они могут заметить баги, которые не заметили вы. Из всех компаний, где я работал, это реально работало только в Amazon. Во многих других компаниях code review или отсутствовал, или был формальным. Но чаще это просто был тул для создания холиваров и конфликтов между программистами и ничему не помогал.

Когда, я работал в Amazon, наша команда использовала Google Guice. Т.к. он более легковесный, чем Spring. Но некоторые использовали Spring. В Meta я на Java не писал. И в hacklang никакого DI не использовали.

Когда, я работал в Amazon, наша команда использовала Google Guice. Т.к. он более легковесный, чем Spring. Но некоторые использовали Spring. В Meta я на Java не писал. И в hacklang никакого DI не использовали.

Heatwave в Лондоне На этой неделе в Лондоне ожидается сильная жара. До +38°C. Обычно, такую погоду в UK называют heatwave (хитвейв). При этом жара в UK переносится сильно хуже, чем в других странах. Тут даже температура выше +25°C уже не сильно комфортная. Это связано с несколькими факторами: 1) Отсутствие кондиционеров в домах. Тут практически не бывает кондиционеров в жилых домах. Кондиционеры есть, в основном, только в офисах и магазинах. Сверлить фасад здания и повесить кондиционер вам никто не даст. 2) Дома - термосы. Дома строились с расчетом на накопление и удержание тепла внутри. У них хорошая теплоизоляция. А также стены сделаны из материала, который хорошо нагревается и долго держит тепло. Это хорошо в прохладную погоду, но не летом. Тут, в отличие от Германии и других стран Европы не холодно зимой в домах. В Дюссельдорфе и Люксембурге, где я жил до Лондона, было сложно получить температуру выше 19-20 градусов зимой без больших счетов на коммуналку. В Лондоне такой проблемы нет (ну или не так заметна). Но летом это превращается в ад. Дом нагревается в жару и даже после того как жара спадает, стены продолжают еще долго отдавать тепло внутрь и удерживать от потерь наружу. На улице уже может быть 20, а в доме все еще больше 25. 3) Нет внешних ставень. Во многих странах Европы, на окнах есть внешние ставни. Закрывать их можно изнутри дома. При этом они полностью блокируют свет, благодаря чему не нагревается само окно и помещение внутри. В Лондоне такого нет. Более того, во многих кввртирах окна от потолка до пола, т.е. у вас такой аквариум, который сильно прогревается солнцем со всех сторон. В Люксембурге у меня в квартире были ставни, хотя страна не южная, типа Испании. Это было особенно хорошо ночью, можно было создать полную темноту в помещении на ночь. И все это хорошо сочеталось с +19°C внутри. Спать было заметачельно. 4) В жару очень часто полностью чистое небо. Не смотря на репутацию туманного Альбиона и дождливой страны, тут бывает очень солнечно. При этом на небе нет ни одного облачка. При таком палящем солнце, даже +25°C уже кажется жарой. А в сочетании с квартирами аквариумами, это делает жару внутри помещений невыносимой.

Amazon Now пришел в UK. Сейчас заказал продукты питания из Amazon Fresh и мне их доставили за меньше чем 20 минут.

Вышел трейлер сиквела Социальной Сети: The Social Reckoning Трейлер: https://youtu.be/gM4LkaXwGuY?is=XWo_W-2cW70AS4yc Сценарий создан тем же автором, что и Социальная Сеть 2010 года - Аароном Соркиным, который получил за него оскар. Только в этот раз он же и снял этот фильм (Социальную Сеть снимал Дэвид Финчер). Фильм про утечку 2021 года.

Вышла документалка Андрея Лошака про компанию Plata Plata - это спиноф Тинькоф Банка в Мексике. Ее основал Олег Тиньков и Майкл Калви. В топ-менеджменте много выходцев из Тинькоф банка. Среди программистов много выходцев из пост-советских стран. Фильм: https://www.youtube.com/watch?v=pWwQmikOoqg Фильм посмотрел из-за Андрея Лошака и Олега Тинькова. Сама документалка хоть и интересная, но выглядит как проплаченный фильм от компании. Тинькова смотрел еще 14 лет назад с его канала Бизнес Секреты: https://www.youtube.com/@BiZSekrety/videos Сейчас подобный контент смотрю на канале Это Осетинская (раньше назывался Русские Норм!): https://www.youtube.com/@Osetinskaia Реально хорошие документалки Андрея Лошака: 1) Холивар. История рунета. Документалка от Андрея Лошака про историю рунета. Смотрится на одном дыхании. Есть на youtube: Холивар. Кинопоиск 8.2, Imdb 7.8. 2) Русские хакеры: Начало. Еще один шедевр документалистики от Андрея Лошака. Кинопоиск 8.4, Imdb 7.3. Смотри также другие фильмы, документалки, сериалы про программистов: Рекомендую сериал Devs Подборка фильмов, сериалов и документалок о программистах, BigTech, стартапах и их основателях

Наконец получил Британский паспорт. Мой путь к паспорту описан тут: https://t.me/faangmaster/1201

Starbucks отказался от AI системы для инвентаризации В сентябре 2025 года новый CEO компании Брайан Никкол решил побороть вечную проблему нехватки ингредиентов в кофейнях. В 11 тысячах точек США и Канады внедрили систему Automated Counting (от разработчика NomadGo). Бариста должны были просто навести планшет с камерой на полки с сиропами, молоком и кофе, а нейросеть с помощью компьютерного зрения должна была сама всё посчитать и заказать то, что заканчивается. На практике: Нейросеть регулярно путала разные виды молока (например, обычное с миндальным или соевым). ​Система не видела некоторые позиции или, наоборот, считала один пакет за два. ​Из-за постоянных галлюцинаций ИИ бариста приходилось тратить массу времени на ручную перепроверку данных, что полностью убивало смысл автоматизации. После 9 месяцев мучений, в итоге, они отказались от системы и перешли на ручной учет. При этом, они недавно ввели KPI для сотрудников по использованию AI (токенмаксинг) и привязали это к премиям и т.д.

Какие есть с этим проблемы и как их решили в Facebook/Instagram? 1) Производительность системы контроля версий. Если у вас очень много кода в одном репозитории как в Meta (миллионы файлов, десятки, если не сотни миллионов строк), то система контроля версий может на справится по производительности. Поэтому Мета сделала свою систему контроля версий на основе Mercury. 2) Feature Flags. Из-за trunk-based development у вас деплоится множество функционала в промежуточном состоянии. Для этого вам нужно иметь возможность ее включать и выключать в проде, проводить тестирование в проде и т.д. Для этого вам нужно активно использовать feature flags. 3) Привязка к одному языку программирования. Это неустранимая особенность. Приходится писать на том языке, на котором написан монолит. 4) Влияние проблем в одной фиче на другую/независимое масштабирование. Если одна функциональность стала работать плохо (потреблять много памяти, бросать ошибки, потреблять много процессорного времени и т.д.), то это может повлиять на работоспособность другого функционала, т.к. весь функционал живет на одном и том же сервере (т.к. это монолит). Это решено на уровне виртуальной машины/контейнера приложений. В Python у вас создается несколько отдельных процессов. Которые способны обрабатывать запросы независимо друг от друга. Число процессов зависит от числа ядер процессора. Процессы не шарят между собой память. Их можно независимо друг от друга мониторить, убивать и перезапускать. В hacklang и hhvm процесс один, но имеет множество потоков, которые имеют изолированную память, которую можно независимо друг от друга ограничивать. Потоки более легковесные, чем отдельные процессы. Но при этом они не шарят память между собой. В Java такое реализовать не получится. Там также один процесс и отдельные потоки на каждый запрос. Но потоки используют одну и туже память (Java Heap). 5) Проблемы с ownership кода. Из-за того, что весь код в одной большой куче, сложно разграничивать кто отвечает за тот или иной код. В Meta эта проблема решена плохо. Тут есть и плюсы и минусы. С одной стороны вы не ограничиваетесь кодом своей команды и можете при необходимости изменить любой код. Но важно, чтобы те, кто отвечает за этот код как минимум проревьюили это изменение. В Meta с этой целью к каждому файлу добавляется специальная аннотация/тег - какая команда владеет этим кодом. И при его изменении, автоматически в код ревью добавляются люди из нужной команды. 6) Сложно засетапить CI/CD. Нужно, чтобы компиляция на такой большой базе кода работала быстро, а также тесты прогонялись быстро. Для этого вычисляется дельта, и прогоняется только подмножество тестов, на которые может повлиять ваше изменение.

Почему самые высоконагруженные веб приложения мира это не всегда микросервисы? Многие компании, которые разрабатывают самые высоконагруженные приложения, с миллиардами запросов в секунду, используют монолиты и монорепы. Ярким примером является Facebook и Instagram. В бэкенде это монолиты. Конечно, у них есть большое число других компонент, которые вынесены в отдельные сервисы, но основной backend, который принимает и обрабатывает запросы от фронтенда (веба или мобильного приложения), содержит бизнес логику - это монолит. Backend Facebook изначально был написан на PHP в 2004 году. Далее его плавно мигрировали на собственный язык hacklang и собственную виртуальную машину hhvm. При этом он остался, по большей части, колоссального размера монолитом. Аналогично, Instagram написан на python (django). Основная часть все еще остается монолитом. Оба сервиса имеют миллиарды пользователей и обрабатывают невероятное число запросов в секунду. При этом они обладают колоссальной отказоустойчивостью и скорость разработки сервисов огромная. Время от того, как вы запушили комит до деплоя в prod проходит несколько часов. Более того, весь код этих приложений находится в монорепе и используется trunk-based development. Т.е. все изменения сразу делаются в основной ветке разработки. Почему так? Какие это дает преимущества? Монорепа: 1) Проблема версионирования API решается на уровне компилятора. Если вы меняете какое-то API, то вы не сможете запушить это изменение в trunk до тех пор, пока не измените все call site (все места, где это API вызывается). Вам не позволит компилятор, ваш код просто не скомпилируется. Если у вас множество репозиториев, то изменение API в одном месте не блокирует вас запушить это изменение. Вы создадите новую версию вашего API. Всем клиентам нужно про это узнать, и делать процесс миграции на новую версию. Нужно менять код, зависимости и т.д. Очень часто это приводит к багам в проде. Когда клиент ожидает одного поведения или семантики API, а в проде уже задеплоена другая версия. 2) Полностью решается проблема dependency hell. Проблемы зависимостей на разные версии одной и той же библиотеки со стороны разных зависимостей вашего модуля. Круговые зависимости и т.д. Тут все решается автоматически на уровне компилятора. 3) Легкий поиск по коду. У вас весь код под рукой. Если он проиндексирован можно легко найти любой интересующий вас код. В Амазоне отдельные репы. Там целая наука работы с зависимостями. Есть свои тулы, концепции и т.д. Там есть тул brazil, понятие version set и много всего другого. Это постоянно приводят с затыкам с зависимостям, багам в проде из-за версионирования. Часто пуш сторонней библиотеки может заблокировать ваш CI/CD пайплайн, т.к. у вас поломались зависимости. Монолиты: 1) Высокая производительность. В микросервисах вызов функции происходит по сети, что работает за миллисекунды. В монолитах вызов происходит в рамках одного процесса и работает за наносекунды. 2) Нет проблемы версионирования API в проде. Это решается на уровне компилятора. Это типичная проблема микросервиисов. 3) Легко тестировать. Вы можете протестировать все e2e. В микросервисах часто очень сложно или не возможно протестировать приложение e2e. Вы можете протестировать свою компоненту, но не весь функционал в целом. Особенно, если у вас под 100 тысяч микросервисов, как в условном Amazon. Trunk-based development: 1) Отсутствие Merge-Hell. Если вы разрабатываете крупную фичу в отдельной ветке, ее потом сложно мержить в trunk. Мелкие и частые изменения предотвращают тяжелые конфликты вмерживания. 2) Можно сделать реальный и быстрый CI/CD. В Мета любое изменение вмерживается, компилируется, тестируется и деплоится в прод за несколько часов. Не нужно делать долгие сложные редкие релизы.

Документалка про создание React.js На том же канале есть документалка про создание React.js. Он был создан как внутренний фреймворк в Facebook. Далее он стал open source проектом. Трейлер Фильм

Exit стратегия ранних инвесторов в Open AI, Anthropic и Space X заключается в использовании пенсионных накоплений американцев Такая дискуссия разворачивается в преддверии самых масштабных IPO в истории. В этом году на IPO выходят SpaceX, OpenAI и Anthropic. Ранние инвесторы вкладывали колоссальные деньги в эти компании по астрономическим оценкам. Все три компании глубоко убыточные. Revenue (доход) измеряется десятками миллиардов долларов в год. При этом оценка капитализации в триллионах долларов. Выход на IPO — это один из вариантов вернуть инвестиции и заработать на них. Но что необычного сейчас происходит? Крупные индексы, вроде Nasdaq, Russell 1000, S&P 500, изменили правила включения компаний специально под эти 3 компании. Они сократили время включения до недель и даже дней, вместо месяцев или даже года. Кроме того, S&P 500 исключил правило, что для включения компании в индекс нужно, чтобы компания была прибыльной. То есть, Индексы планируют включить эти компании в портфели почти по стартовой цене, без ожидания установления рыночной цены. Но как это связано с пенсиями в США? В США существенная часть пенсий поступает от так называемых инвестиционных счетов 401(k). Работник может откладывать часть своего дохода на специальный инвестиционный счёт. Например, 5%. Часто работодатель может добавить столько же. То есть вы можете откладывать 10% своего дохода на инвестиционный счёт. Причём вы откладываете процент дохода до уплаты налогов. То есть то, что вы туда откладываете, идёт в обход уплаты налогов. И когда вы перечисляете туда деньги, вы можете выбрать индексы, в которые вы инвестируете. Снять деньги со счёта до достижения пенсионного возраста очень сложно, и придётся платить штраф за это. Теперь получается так, что эти компании насильно и по практически изначальной цене включают в индексы, и следовательно, это частично оплачивается из пенсионных накоплений американцев. Соответственно, ранние инвесторы могут быстро продать свою долю и выйти по астрономической цене за счет пенсионных денег американцев. Это вызвало широкие обсуждения в последнее время. И S&P 500 уже отказался от упрощенных правил для этих трех компаний. Но Nasdaq и Russell 1000 — нет. Более того, под соусом SpaceX нам продают ракеты, но в реальности туда включили X.AI (создатель Grok), который является глубоко убыточным AI-бизнесом. Всё это, совместно с разговорами про токенмаксинг и бесполезными расходами на AI (не видна польза от внедрения AI, видны только астрономические расходы), снова поднимает тему про AI Bubble.

На том же канале много других прикольных документалок 1) IntelliJ IDEA. Про создание, возможно, лучшей среды разработки для Java. Трейлер Фильм 2) Spring. Про создание одного из самых популярных фреймворком для Java. Трейлер Фильм 3) Java. Про создание языка программирования Java. Пока только трейлер. Фильм должен выйти летом этого года. Трейлер.

Еще одно интервью с выпускником МФТИ в Лондоне Это основатель Рокет Банка. Сейчас делает компанию Numica в Лондоне. Его линкедин: Victor Lysenko https://youtu.be/Ec8V9kNdLco?si=Q10bixYviPlea85r

Вышла документалка про создание C++ Трейлер: https://youtu.be/NXwTRzywDSk?si=3aEmsgWoZXUjA2Hk Документалка: https://youtu.be/lI7tMxzSJ7w?si=aSSf8X7ZWxZpH_CY

Тест

Сегодня пришли рекрутеры из Synthesia. Пора начать собеситься, но лень. Они кстати тоже с моем топе были: https://t.me/faangmaster/1226