FAANG Master

Амазон планирует сократить 30k человек на этой неделе Пару недель назад они уволили 15% эйчаров. Но, похоже, слухи про мегалейоф все же подтвердились и уже сегодня начнутся массовые увольнения.

Дана монетка, нужно симулировать 6-гранный кубик Код решения:

int rand6() {
    while (true) {
        int val = 4* rand2() + 2 * rand2() + rand2();
        if (val < 6) {
            return 1 + val;
        }
    }
}

Или можно заменить на битовые операции:

private static int rand6() {
    while (true) {
        int val = (rand2() << 2) | (rand2() << 1) | rand2(); 
        if (val < 6) { 
            return val + 1;
        }
    }
}

Это классическая задача на Sampling Rejection. Аналогичные задачи: 1) Написать rand7() имея rand5() 2) Написать rand10() имея rand7() Почему вероятность - 1/6? 4* rand2() + 2 * rand2() + rand2() дает равномерно распределенные значения от 0 до 7 (всего 8 значений). Нам надо преобразовать это в диапазон от 1 до 6 (6 значений). P[результат = x] = P[с первой попытки = x] + P[провал] * P[со второй попытки = x] + P[провал] * P[провал] * P[с третьей попытки = x] + ... x от 1 до 6. P[провал] = 2/8 = 1/4. - Вероятность, что выпадет 6 или 7 и нам нужно перейти на следующую итерацию цикла. P[с первой попытки = x] = P[со второй попытки = x] = P[с третьей попытки = x] = ... = 1/8 Тогда: P[результат = x] = 1/8 * (1 + 1/4 + 1/4^2 + ...1/4^n + ...) = 1/8 * 1/(1-1/4) = 1/8 * 4/3 = 1/6. Сколько нужно попыток? E[N] = 1 + P[провал] + P[провал] ^2 + ... = 1/(1-P[провал]) = 1/P[успеха] = 1/(6/8) = 8/6 = 4/3.

Вопросы с собеседования на позицию Quant разработчика в Лондоне на £350k/$465k 1) Как протестировать генератор случайный чисел? 2) Дана монетка, нужно симулировать 6-гранный кубик.

Всю прошлую неделю был в Шотландии Очень понравилось. Замки, горы, природа. Необычная архитектура. Больше всего понравилась природа. Если еще не были, очень рекомендую в качестве не пляжного отдыха. От Лондона несколько часов на поезде или машине (4-5 часов), можно и на самолете. Из того, что успел посмотреть: 1) Эдинбургский замок 2) Холирудский дворец 3) Королевская миля 4) Собор Сент-Джайлс 5) Королевская яхта Британия 6) Национальный музей Шотландии 7) Экскурсия по Гарри Поттеру(где писались книги, прототипы мест и персонажей) 8) Озеро Лох Несс 9) Горы 10) Музей детства 11) Камера обскура 12) Динамическая земля 13) Трон Артура И много чего еще.

Retries Это ответы на вопросы: https://t.me/faangmaster/1012 https://t.me/faangmaster/1013 https://t.me/faangmaster/1014 Написал статью: Retries Осторожно, есть пределы, производные и правило Лопиталя. Смотри также: Некоторые подходы к архитектуре приложений в Amazon Обработка ошибок при вызове другой компоненты

Более детальное описание race-condition: The race condition involves an unlikely interaction between two of the DNS Enactors. The normal way things work a DNS Enactor picks up the latest plan and begins working through the service endpoints to apply this plan. This process typically completes rapidly and does an effective job of keeping DNS state freshly updated. Before it begins to apply a new plan, the DNS Enactor makes a one-time check that its plan is newer than the previously applied plan. As the DNS Enactor makes its way through the list of endpoints, it is possible to encounter delays as it attempts a transaction and is blocked by another DNS Enactor updating the same endpoint. In these cases, the DNS Enactor will retry each endpoint until the plan is successfully applied to all endpoints. Right before this event started, one DNS Enactor experienced unusually high delays needing to retry its update on several of the DNS endpoints. As it was slowly working through the endpoints, several other things were also happening. First, the DNS Planner continued to run and produced many newer generations of plans. Second, one of the other DNS Enactors then began applying one of the newer plans and rapidly progressed through all of the endpoints. The timing of these events triggered the latent race condition. When the second Enactor (applying the newest plan) completed its endpoint updates, it then invoked the plan clean-up process, which identifies plans that are significantly older than the one it just applied and deletes them. At the same time that this clean-up process was invoked, the first Enactor (which had been unusually delayed) applied its much older plan to the regional DDB endpoint, overwriting the newer plan. The check that was made at the start of the plan application process, which ensures that the plan is newer than the previously applied plan, was stale by this time due to the unusually high delays in Enactor processing. Therefore, this did not prevent the older plan from overwriting the newer plan. The second Enactor’s clean-up process then deleted this older plan because it was many generations older than the plan it had just applied. As this plan was deleted, all IP addresses for the regional endpoint were immediately removed. Additionally, because the active plan was deleted, the system was left in an inconsistent state that prevented subsequent plan updates from being applied by any DNS Enactors. This situation ultimately required manual operator intervention to correct.

Amazon опубликовал официальный отчет об outage us-east-1 Ссылка на отчет: https://aws.amazon.com/message/101925/ Что случилось Ночью 19 октября у AWS в регионе US-East-1 (Northern Virginia) произошёл крупный сбой, который затронул десятки сервисов — от DynamoDB и EC2 до Lambda и Redshift. Как началось Около 23:48 PDT у Amazon DynamoDB внезапно перестали работать DNS-записи. Из-за ошибки гонки («race condition») в автоматизации DNS система удалила актуальные записи для регионального endpoint — и сервис просто перестал резолвиться. DynamoDB лежит в основе множества внутренних систем AWS, поэтому следом начали падать зависимые сервисы: авторизация, метаданные, мониторинг, балансировщики и многое другое. Как развивалось 23:48 PDT — первые ошибки API у DynamoDB. 02:25 AM PDT 20 октября — восстановлены основные DNS-записи. 05:30 – 14:09 PM PDT — Network Load Balancer массово помечает целевые инстансы как «unhealthy», ухудшая восстановление. К 15:00 PDT — регион возвращается в нормальный режим работы. Что пострадало EC2 — запуск новых инстансов часто фейлился. Lambda, ECS, Redshift, Connect — наблюдались ошибки и задержки. NLB — из-за ложных health-check-ошибок балансировщики выводили инстансы из работы. Root cause Два экземпляра системы «DNS Enactor» одновременно обновляли конфигурацию: один медленно применял старый план, другой уже внёс новый. В результате новый был удалён как «устаревший», и endpoint DynamoDB остался без IP-записей. Что AWS пообещала исправить Убрать гонку в DNS-автоматизации DynamoDB. Добавить защиту от массового удаления capacity у NLB. Улучшить тестирование сценариев восстановления у EC2 и связанных сервисов. AWS признала проблему, принесла извинения и обещает укрепить устойчивость DNS и критичных зависимостей.

Текущая стоимость недвижимости в Эдинбурге Проделал оценку стоимости недвижимости в Эдинбурге. Аналогичный пост про Лондон: Текущая стоимость недвижимости в Лондоне Цены медианные, по текущим предложениям на rightmove. Также добавил размер месячного платежа по ипотеке на 25 лет и 20% первоначального взноса. 1) 1 bed(двушка): £190k/$253k/20.5 миллионов рублей. Платеж в месяц: £0.8k 2) 2 beds(трешка): £270k/$359k/29.2 миллиона рублей. Платеж в месяц: £1.2k 3) 3 beds house(4 комнатный дом/таунхаус): £325k/$432k/35.2 миллиона рублей. Платеж в месяц: £1.44k 4) 4 beds house (4 комнатный дома/таунхаус): £550k/$723k/59.6 миллиона рублей. Платеж в месяц: £2.4k Стоимость в 1.5-2 раза дешевле, чем в Лондоне. Но и зп тут меньше и вариантов работодателей сильно меньше, чем в Лондоне.

Вышло новое интервью в Andrej Karpathy Это автор термина Vibe Coding. Был сооснователем Open AI, работал в Tesla над автопилотом. Он также скептичен насчет достижения AGI в ближайшем время. https://youtu.be/lXUZvyajciY?si=PdjNwtSB11ohe3bi

Следующие вопросы: 1) Что будет если не ограничивать число ретраев? 2) Получается, если вызываемае компонента начинает работать хуже, мы повышаем нагрузку. Что будет, если при увеличении нагрузки, компонента начинает работать еще хуже и p падает с 99, до 95, а потом до 50%?, а при нагрузке больше 1500 запросов, p падает до 5%? Как с этим бороться?

Следующий вопрос: Какая вероятность, что хотя бы 1 запрос из n ретраев завершиться успешно?

Простой вопрос с собеседования Есть 2 компоненты. Одна дёргает другую через RPC. Делает она это 1000 раз в секунду. Но часть вызовов стала завершаться ошибкой, при этом вероятность успешного завершения запроса стала не 100%, а p (например, p=99%). Чтобы бороться с такими transient ошибками, добавили retry. Делают до n ретраев (например, n=5). Вопрос: На сколько вырастет нагрузка на вторую компоненту? (Была 1000 qps, какая станет?)

Очередной layoff в Meta. На этот раз 600 человек в новом отделе - Super Intelligence Lab.

Мытищи, Водники, Клязьминское водохранилище