В интересном треде преподаватель из Стэнфорда поднимает важную проблему - https://x.com/lxeagle17/status/1899979401460371758 Массовое использование больших языковых моделей (LLMs) приводит к тому, что существующие методики обучения перестают работать. Мы не можем запретить использование LLM, поэтому нужно встраивать их в процесс. Сейчас опишу свой опыт в этом.

Недавно я начал обучение GameDev-разработчика, который хочет переквалифицироваться в DevOps. С самого начала мы решили, что для обучения будем активно использовать ChatGPT. Это решение было основано на двух гипотезах:

1. ChatGPT позволит значительно сократить время обучения
2. Нужно сразу учиться решать задачи с использованием ChatGPT. Ведь в реальной работе это так и будет происходить

В итоге я сформировал следующую методику:

Обучение происходит путём выполнения конкретных приближенных к реальности задач. Есть выдуманный стартап под названием AI Tutor. Он разрабатывает бота-преподавателя. Студент работает в нём в качестве DevOps. По мере роста стартапа появляются всё новые задачи, которые нужно выполнять.

Примеры задач:

1. Нужно запустить лендинг стартапа. Для этого нужно на виртуалке AWS запустить nginx и захостить там простой лендинг. После чего купить и привязать домен. На виртуалке нужно организовать SSH-доступ для разработчика. Разработчик должен иметь права только на модификацию лендинга.

2. Прошли первые питчи, пошли первые посетители, стартапу теперь нужен блог. Нужно развернуть блог с использованием ghost и настроить роутинг в nginx, чтобы он был доступен по пути /blog на сайте лендинга. Кроме того, давайте сразу настроим отказоустойчивость. Ожидается посещение сайта серьезными партнёрами, поэтому он должен быть доступен всегда. Для этого нужно поднять вторую виртуалку AWS и создать балансировщик.

И так далее.

Я не объясняю студенту, как настраивать nginx или SSH. Ему об этом расскажет ChatGPT. Но как понять, что ChatGPT дал корректный ответ? Для этого у студента должен быть хороший теоретический фундамент. Если конкретные задачи это первый столп методики, то изучение теории - второй. Для этого в рамках каждой задачи я даю студенту вопросы, ответы на которые он должен подготовить (тоже с помощью ChatGPT, скорее всего).

Когда студент всё сделал, мы созваниваемся. Он показывает результат и отвечает на вопросы. Я корректирую и даю дополнительную информацию. Так мы формируем системные фундаментальные знания. Они позволят понять, что, к примеру, nginx и traefik это просто разные инструменты, но они могут решать общую задачу - роутинг. И теперь опыт работы с nginx может быть переложен на traefik. Создаётся система знаний.

Вот примеры вопросов после первой задачи:

1. Что такое HTML?
2. Что такое HTTP? Как работает этот протокол?
3. Что такое веб-сервер?
4. Как пользоваться curl для отправки запросов по HTTP?
5. Как работает DNS?
6. Как устроена система пользователей и ролей в Linux?
7. Что такое процесс? Как nginx использует процессы для своей работы?

Вот примеры вопросов после второй задачи:

1. Что такое балансировка нагрузки? Какие варианты балансировки нагрузки существуют?
2. Что такое reversy proxy? Как можно настроить nginx для выполнения роли reverse proxy?
3. Что такое TCP/IP? Чем эти протоколы отличаются от HTTP?
4. Что такое пакетный менеджер? Какие есть пакетные менеджеры в дистрибутивах Linux? Как в деталях работают пакетные менеджеры?

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

В посте выше я писал, что в эпоху LLM мы должны изменить традиционные подходы к обучению. Фокус должен смещаться в сторону изучения фундаментальных принципов создания и поддержки программных систем. А конкретный синтаксис или API всегда можно узнать у условного ChatGPT.

Есть несколько способов изучения этих принципов, и один из них это чтение хороших книг. На мой взгляд, эталоном книги с фундаментальными знаниями является "Designing Data-Intensive Applications" Мартина Клеппмана (в русскоязычном сообществе известна под названием "Кабанчик") https://a.co/d/f2DYvKt. После её прочтения в голове формируется целостная картина принципов и технологий работы с данными. А это базы данных, очереди сообщений, кеши - всё то, что мы практически всегда используем в создаваемых нами системах. Каждый разработчик должен прочесть эту книгу.

И скоро выйдет второе издание! 🔥

Об этом автор книги Мартин Клеппман с соавтором второго издания Крисом Риккомини рассказали в сессии вопросов-ответов на Monster Scale Summit 2025 https://youtu.be/T-d1wR7adB8?si=jEVzB4w6eYE8Szz5. Кроме этого, они обсудили ряд современных трендов в работе с данными, таких как облачные хранилища, встроенные базы данных, расширения баз данных. Рекомендую к просмотру.

Что же нового будет во втором издании? Основной источник нового материала - это облачные технологии. С момента выхода первого издания книги прошло 8 лет, и за это время облачные хранилища данных, такие как AWS S3 и облачные БД, существенно повлияли на то, как мы проектируем системы работы с данными. Например, Grafana Loki, Tempo и Mimir используют не файловую систему, а объектные хранилища (AWS S3, Azure Blob Storage, Google Cloud Storage) для хранения данных. Этот тренд набирает популярность и нужно его систематизировать. Что и будет сделано во втором издании.

В общем, если вы ещё не читали "Кабанчика", то стоит подождать до декабря 2025 года, когда выйдет второе издание. А если читали, то тоже подождать и прочитать заново 🙂 И тогда можно не волноваться, что вас заменит ИИ. Наоборот, он станет вашим помощником, вместе с которым вы будете быстро создавать надёжные и производительные системы. 🚀

Менеджмент и маркетинг.

1. Реалистичная оценка ажиотажа: Понятно, что JLo – это мегазвезда для Казахстана. Ожидать стандартной нагрузки было нельзя. Менеджменту следовало не просто предположить высокий спрос, а заложить в планы пиковую, возможно, даже чрезмерную нагрузку, исходя из масштаба события и медийного шума. Это включает коммуникацию с технической командой о порядке ожидаемых цифр (не "будет много", а "ожидаем X десятков тысяч одновременных запросов в первую минуту").

2. Стратегия продаж: Запуск всех билетов одномоментно в полночь – классический рецепт для создания пиковой нагрузки. Менеджмент мог рассмотреть альтернативы:

* Предрегистрация/лотерея: Собрать заявки заранее и распределить возможность покупки.

* Поэтапный старт: Начинать продажи по секторам или ценовым категориям с интервалом в несколько часов.

* Очередь: Внедрить систему виртуальной очереди, которая пропускает на сайт ограниченное количество пользователей одновременно. Да, это тоже вызывает недовольство ожидающих, но предотвращает падение и хаос.

3. Коммуникация: Заранее предупредить пользователей о возможном высоком спросе и потенциальных сложностях, объяснить, как будет работать система (если используется очередь или поэтапный старт). Это управляет ожиданиями.

Техническая команда.

1. Нагрузочное тестирование: Это альфа и омега подготовки к таким событиям. Нужно было не просто проверить, что сайт работает, а симулировать реалистичный сценарий: одновременный заход десятков тысяч пользователей, массовые запросы к базе данных (проверка наличия мест, создание заказов). Тестирование должно выявить "узкие места" – будь то серверные мощности, пропускная способность сети, неоптимизированные запросы к БД или проблемы во внешних сервисах (например, эквайринг).

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

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

4. Самое главное! - предотвращение продажи дубликатов: Вот здесь и произошла катастрофа. Падение сервера – полбеды. Продажа одного места нескольким людям – это фундаментальная ошибка в логике приложения или управлении данными. Как это предотвратить:

* Атомарность операций: Процесс "проверить доступность места -> занять место -> создать заказ" должен быть атомарным. Это означает, что он либо выполняется целиком и успешно, либо полностью откатывается, если на каком-то этапе произошел сбой или место уже занято другим запросом. Это достигается с помощью механизмов транзакций в базах данных.

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

* Уникальные ограничения (unique constraints): На уровне базы данных должно быть жесткое ограничение, не позволяющее добавить две записи с одинаковым местом на одно и то же мероприятие. Это последняя линия обороны, которая не даст записать дубликат, даже если логика приложения даст сбой.

* Тестирование конкурентного доступа: Нужно было специально тестировать сценарии, когда несколько "покупателей" одновременно пытаются купить одно и то же место. Эти тесты должны доказать, что система корректно обрабатывает такие "гонки запросов" (race conditions).

5. План действий при сбоях (incident response plan): Что делать, если система все-таки упала? Как быстро ее поднять? Критически важно: перед тем как снова открывать продажи после сбоя, необходимо провести проверку целостности данных. Убедиться, что не возникло аномалий вроде "подвисших" заказов или некорректного статуса мест. Похоже, именно этот шаг был пропущен, что и привело к продаже дублей после восстановления работы.

Катастрофа с Ticketon – это результат целого комплекса проблем: недооценка нагрузки менеджментом, недостаточная подготовка и тестирование со стороны технической команды, и, вероятно, отсутствие должного контроля и стратегического видения со стороны технического руководства (CTO) в части обеспечения фундаментальной надежности критически важной функции – продажи уникального товара (билета на место). Падение сервера – это плохо. Продажа дубликатов – это показатель системного сбоя на уровне архитектуры, процессов разработки и тестирования.

Ticketon обещали опубликовать постмортем, где они опишут все причины, приведшие к этой ситуации. Посмотрим, насколько они будут пересекаться с тем, что я написал выше.

Этот случай – болезненный, но ценный урок для всей IT-индустрии Казахстана о том, насколько важен не только внешний функционал сервиса, но и его внутренняя надежность, особенно когда на кону стоят большие деньги и доверие тысяч людей. Надеюсь, нужные выводы будут сделаны и подобных ситуаций в будущем удастся избежать.

Ситуация с Тикетоном вызвала большой резонанс в среде казахстанских ИТ-специалистов. Её много обсуждали, примеряли на себя, думали, как поступили бы они. А группа ребят из чата тимлидов Казахстана (включая меня) решила провести хакатон, где команды будут проектировать и реализовывать базовый функционал аналога Тикетона. А затем эти решения будут подвергаться нагрузкам, чтобы оценить их производительность и корректность. Следующим постом скину предварительный анонс этого мероприятия.

Привет!
Мы в чате Тимлидов (@teamleads_kz) по итогу обсуждения сложностей проектирования высоконагруженных систем, пришли к выводу что в Казахстане есть потенциальный запрос на проведение образовательного Хакатона на эту тему.

Мы готовы взять на себя полностью организацию и подготовку инфраструктуры, но нужно понять есть ли запрос или интерес к этому мероприятию со стороны сообществ разработки.

Если вы разработчик и готовы принять участие в хакатоне по разработке высоконагруженного сервиса - заполните опросник:
https://forms.gle/W7tTdGAwEXTZKHR4A

О мероприятии:
Предварительные планы на Август 2025 года. Задача - разработать командой сервис, который способен будет выдержать нагрузку по покупке билетов (на подобии Тикетона), при этом не сломав бизнес-сценарии и не допустив потерь бизнесу (двойные продажи билетов, противостояние фроду, выдержать нагрузку и т.д.). Пример задания

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

Мероприятие будет в Алмате, возможно подключиться онлайн. Ожидаем, что это будет бесплатное мероприятие, но зависит от предварительного спроса. Если будет большой спрос на данное мероприятие, то могут быть введены критерии отбора. Но это мы уточним только когда поймет спрос. Для этого, ждем ваши ответы в форму. Спасибо!

Каждые 2 недели мы в сообществе Drim Team проводим семинары по использованию ИИ. Там мы изучаем возможности современных инструментов. В частности, мы концентрируемся на использовании ИИ для помощи в программировании. Изучаем, как устроены LLM. Изучаем, какие есть инструменты. Пробуем использовать эти инструменты. Делимся практическим опытом. Цель - найти такие сценарии использования ИИ, которые позволят каждому из нас в разы повысить свою производительность.

В эту субботу мы провели очередной созвон. На нём мы попробовали использовать Cursor. В отличие от AI-ассистентов типа GitHub Copilot, которые помогают писать код в каком-то конкретном файле, Cursor - это пример AI-агента. Его отличие в том, что он оперирует всем проектом. Для решения задачи он может добавлять новые файлы, редактировать существующие, выполнять команды в консоли.

В качестве проекта мы взяли наш учебный проект Drimstarter (аналог Kickstarter). И попросили Cursor добавить операцию создания проекта. Следует отметить, что в Drimstarter мы используем Vertical Slices Architecture, которая используется реже классической слоёной архитектуры. То есть Cursor должен был понять, что используется именно этот подход и файлы нужно создавать в соответствии с ним. Мы ввели запрос на русском языке "Реализуй функцию CreateProject по аналогии с функцией CreateCategory" и стали смотреть, что получится.

Следующие наши эмоции можно сравнить с теми эмоциями, которые все испытывали, когда первый раз использовали ChatGPT. Это фантастика. Cursor дописал proto-файлы, написал эндпоинт ASP.NET Core, хендлер операции и валидатор. После этого он попытался скомпилировать код и получил несколько ошибок компиляции. На основании ошибок он внёс правки и скомпилировал снова. На этот раз ошибок не было.

Затем мы попросили Cursor написать тесты. Он быстро сделал и это. Правда, в этот раз было несколько моментов, которые он не учёл. Мы быстро их поправили и запустили тесты. Они были зелёные 🤯 Среди участников звонка повисла тишина. То, на что нужно было потратить час, Cursor сделал за 10 минут. Определённо, на более сложных задачах, результат может быть не таким прямолинейным. Но у Cursor есть система правил, которые помогают ему адаптироваться к структуре и соглашениям проекта, повышая качество его работы.

В конце семинара мы все сошлись на том, что теперь нам нужно устанавливать Cursor и начинать его использовать для рабочих задач. На следующих семинарах мы поделимся полученным опытом и расскажем о результатах. Но всем уже очевидно, что такие инструменты как Cursor сильно изменят то, как мы программируем.

Разработка с помощью AI-агентов сильно отличается от обычной разработки. Это имеет как плюсы, так и минусы. Среди плюсов - значительное повышение производительности программиста. Среди минусов - атрофия навыков самостоятельной разработки. Необходимо явно осознавать этот риск и принимать меры, чтобы избежать атрофии. На эту тему у нас недавно было интересное обсуждение.

Дархан Изтлеу:

"Немного мыслей после вчерашней встречи)

Начну с того, что я услышал новость (оригинала, к сожалению, нет) о том, что средняя оценка по экзаменам у студентов-инженеров стала худшей во второй половине 2024 года. Та же история наблюдается и в школах.

Не трудно догадаться что могло повлиять на это)
Давайте поговорим о работе мозга. Он очень ленивый: создавать новые нейронные связи — дорого, и поддерживать их тоже. Поэтому мозг пытается всё автоматизировать. Возьмём, к примеру, тот же поход до работы: большинство даже не замечают, как добираются, сколько ступенек преодолевают по пути. В этом есть плюс — мы можем думать о чём-то другом. Но стоит изменить высоту одной ступеньки, и мы споткнёмся. И вот когда у нас есть такой замечательный инструмент как «большая языковая модель», мне кажется человек даже сам того не осознавая, просто перестает учится. А зачем, если можно спихнуть эту работу на GPT!

К чему я это? Я стал всё чаще использовать ИИ в работе, и это сильно повысило мою продуктивность. Однако не стоит забывать об обратной стороне этой технологии — деградации собственных мыслительных способностей. Ведь к хорошему быстро привыкаешь (попробуйте сейчас что-то найти в тексте без `Ctrl+F`).

Для себя я решил: теперь нужно решать задачи на LeetCode, отключая все подсказки IDE (вроде Copilot) или просто используя встроенный редактор на сайте. Можно даже перерешивать уже решённые задачи — делать так называемые «упражнения Като». Ещё лучше — использовать разные языки программирования.

В общем, в интересное время мы живём. Кажется, современные LLM — это одна из тех технологий, которые создают хорошие времена а как мы знаем … *«Хорошие времена рождают слабых людей»* — и сейчас, как никогда, важно развивать себя."

Дмитрий Мельник:

"Ты поднял важную тему. Я согласен с тобой. Теперь, когда мы увидели, как инструменты типа Cursor могут программировать, становится очевидно, что код мы будем писать по-другому. Мы будем просто следить, что пишет ИИ, и подтверждать или поправлять его. И это изменит нейронные связи в нашем мозгу. Произойдёт атрофия.

Можно провести аналогию с физической активностью. До 20 века большинство людей работало физически. Но в 20 веке технологии позволили многим начать работать сидя в офисе. И у людей появились проблемы с физической формой. И поэтому появились фитнес-клубы, в которые люди начали ходить специально, чтобы поддерживать физические кондиции. Я думаю, ИИ приводит нас к тому же сценарию. Только на этот раз начнут проседать не физические способности, а интеллектуальные. Поэтому теперь нужно заниматься внерабочими активностями для поддержания интеллектуальной формы. Очень возможно, что появятся клубы для таких тренировок.

Решение задач на LeetCode - хороший пример такой внерабочей активности. Но я бы добавил ещё другие. К примеру, написание полноценных приложений без помощи ИИ. Чтобы не утратить навыков структурирования и детализации архитектуры и кода. Вообще, перед нами открывается область, где мы увидим много интересного. Но каждый уже сейчас должен понять, что нужно явно заниматься тренировкой своего ума. Иначе мы станем просто придатками машины."

В основе работы ИИ-ассистентов и ИИ-агентов лежат большие языковые модели - Large Language Models. Их существует большое количество и у каждой из них свои характеристики. И постоянно появляются новые модели. Предыдущим постом я скинул новость о выпуске одной из них - Qwen-3. Но что значат все эти описания:

- Выпустили 2 MoE и 6 dense моделей в весах на любой вкус, 0.6В до 235B
- Это MoE всего с 22В активных параметров
- Это полу-ризонеры, как Sonnet 3.7 или Gemini 2.5 Pro
- Претрейнинг был в три этапа
- Пост-трейнинг: файн-тюнинг на CoT + несколько стадий RL

Все эти термины звучат как сложная магия, доступная только учёным в сфере ИИ, и кажется, что простым программистам этого не понять, да и не нужно. На самом деле это не так. Знать это полезно и изучить можно достаточно просто.

Есть отличное видео, где Андрей Карпатый (со-основатель OpenAI и директор по ИИ в Tesla) всего за три с половиной часа объяснит вам, как устроены LLM и как работает пайплайн их обучения. При этом он вообще не касается математики, поэтому материал доступен для понимания любому ИТ-специалисту. После просмотра вы будете понимать большинство из того, что пишут в новостях про LLM. И сможете более осознанно их обсуждать, выбирать и использовать.

Вот ссылка на видео. Есть русские субтитры. Очень рекомендую к просмотру.

https://www.youtube.com/watch?v=7xTGNNLPyMI

В ходе подготовки к Хакатону, мы собрали небольшой набор данных в виде часто используемых имен и фамилий, также городов и улиц Казахстана. К сожалению так оказалось что ГосСтат публикует только наиболее часто встречающиеся казахские имена в маркетинговых материалах и отчетах. Если кто-то знает где можно взять список других имен и фамилий, было бы круто. Вдвойне круто если бы кто-то законтрибьютил этот список прямо в репозиторий. Также из-за того что существенный набор имен и фамилий публиковался кирилицей, а банковские карты выпускаются латиницей, я сделал довольно топорную транслитерацию, если кто знает правила лучше, или может как-то улучшить этот процесс, буду признателен.

Андрей Курдюмов создаёт набор данных для хакатона HackLoad 2025, который мы готовим. Они будут использованы для базы пользователей билетного сервиса. Если знаете, какие есть источники имён, напишите ему.

Ticketon опубликовал постмортем по следам сбоя 11 апреля. Я провёл его анализ и постарался извлечь больше технических деталей вместе с рекомендациями по предотвращению таких проблем в будущем.

https://teletype.in/@drimdev/ticketon-postmortem-2025-analysis

На мою статью с анализом постмортема Ticketon написали комментарий:

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

То есть изначально я предположил, что запросы доходили до бекенда Ticketon, но там блокировались из-за неизвестного IP отправителя. Но, судя по комментарию (написал, скорее всего, человек из команды), запросы до бекенда вообще не доходили и вставали в очередь Waiting Room наравне с запросами от пользователей.

Чтобы избежать этой ситуации, в Cloudflare Waiting Room нужно было настроить Bypass Rules, чтобы запросы с IP адресов платёжных провайдеров не попадали в очередь. Либо настроить правило, чтобы туда не попадали запросы на конкретный URL эндпоинта Ticketon. Система правил Cloudflare очень мощная и позволяет настроить много сценариев. Но команда в экстренной ситуации забыла это сделать. Сказалось отсутствие заранее подготовленных инструкций на случай разных сбоев.

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

Cloudflare

Во время анализа сбоя Ticketon мы много говорили о Cloudflare Waiting Room. Я думаю, что сейчас, пока эта ситуация ещё свежа в памяти, было бы хорошо углубиться и поговорить о том, что такое Cloudflare в целом. Как он работает, какие сервисы предоставляет, какие технологии использует. Эта информация будет полезна тем, кто создаёт веб-приложения и хочет, чтобы они работали быстро и надёжно. Также это будет интересно тем, кто хочет работать в Cloudflare или подобных компаниях и хочет понимать, какие технологии для этого нужно знать.

На тему Cloudflare будет несколько постов. В этом и следующем посте мы сконцентрируемся на основной технологии, которая делает возможными все сервисы Cloudflare. Она называется Anycast Network.

Давайте представим, что мы хотим запустить свой сайт по адресу shokan.blog. Первым делом мы его разрабатываем и получаем набор HTML, CSS и JS файлов. Кроме этого может потребоваться разработать API, но для простоты пока это опустим. После того, как сайт разработан, нам нужно его где-то захостить. Для этого мы пользуемся услугами хостингов. К примеру, мы можем использовать Hetzner и арендовать у них виртуальную машину. Предположим, что она находится в Германии. Затем на этой машине мы запускаем веб-сервер (например, NGINX), который будет обрабатывать HTTP запросы от клиентов (обычно это браузеры) и отдавать наши HTML, CSS и JS файлы.

Виртуальная машина с нашим сайтом имеет публичный IP адрес. Предположим что это 150.10.27.114. Но нам нужно доменное имя, чтобы его можно было забить в браузере. Для этого мы идём в сервис регистрации доменных имён типа GoDaddy и покупаем там нужное имя. Затем мы в админке GoDaddy настраиваем DNS - прописываем, какому IP соответствует купленное имя. Мы создаём DNS-запись "shokan.blog -> 150.10.27.114". После этого наш сайт начинает работать.

Давайте посмотрим, что происходит, когда пользователь вводит в браузере shokan.blog. Сначала с компьютера отправляется DNS запрос на получение IP адреса. Опустим детали работы DNS, но в итоге запрос приходит в GoDaddy и тот отвечает, что домену shokan.blog соответствует адрес 150.10.27.114. После этого браузер отправляет HTTP-запрос на этот адрес, запрос доходит до виртуальной машины Hetzner и та отправляет браузеру файлы сайта. В итоге пользователь видит наш сайт у себя на экране.

Проходит время и наш сайт набирает популярность. Вместе с этим начинаются проблемы. Во-первых, пользователи нашего сайта могут находиться по всему миру. И к примеру, запросу из Австралии потребуется 300 мс только для того, чтобы дойти до Германии. И столько же потребуется ответу, чтобы вернуться обратно. В итоге наш сайт для таких пользователей будет долго загружаться. Во-вторых, наша виртуальная машина может перестать справляться с большим потоком запросов и пользователи будут ждать ещё дольше. Кроме того, часть пользователей может начать получать ошибки.

Обе эти проблемы может решить Cloudflare.

Cloudflare имеет по всему миру более 300 дата-центров. Они, к примеру, есть в Сиднее, Алматы, Красноярске, Амстердаме и в множестве других городов. И мы можем сделать так, что запросы на получение нашего сайта будут отправляться не на нашу виртуальную машину в Германии, а в ближайший дата-центр Cloudflare. И Cloudflare отдаст HTML, CSS и JS файлы нашего сайта из своего кеша. То есть запроса на нашу виртуальную машину не будет вообще. Это решает обе проблемы. Все пользователи смогут быстро открывать наш сайт, сколько бы их не было и где бы они не находились.

В следующем посте разберёмся, как это работает технически.

#cloudflare #anycast

Первым делом мы должны создать аккаунт в Cloudflare и перенести домен shokan.blog с GoDaddy на Cloudflare. Опустим детали, как это делается, но в итоге на DNS запросы будет отвечать Cloudflare. И вместо того, чтобы для домена shokan.blog отдавать IP адрес нашей виртуальной машины, он будет отдавать свой IP адрес. То есть браузер пользователя для получения сайта будет слать запросы не на нашу машину, а в дата-центр Cloudflare.

Но в какой конкретно дата-центр будут отправляться запросы? Мы привыкли, что конкретный IP адрес соответствует конкретному серверу в конкретной точке мира (есть ряд исключений, но пока их опустим). Эта схема называется Unicast.

Cloudflare для маршрутизации запросов использует другую схему. Она называется Anycast. Суть заключается в том, что IP адрес указывает сразу на все дата-центры и запрос маршрутизируется в тот дата-центр, который ближе всего к отправителю запроса. Предположим, что Cloudflare для домена shokan.blog вернул адрес 104.17.175.85. Если пользователь находится в Австралии, то запрос по этому адресу 104.17.175.85 будет отправлен в дата-центр в Сиднее. А если пользователь находится в Казахстане, то запрос по этому же адресу 104.17.175.85 будет отправлен в дата-центр в Алматы. Технически Anycast настраивается с помощью протоколов маршрутизации, таких как BGP. Кому интересно, тут можно почитать детальнее.

В результате переноса домена в Cloudflare и использования Anycast весь трафик на сайт shokan.blog начинает проксироваться, то есть идти через дата-центры Cloudflare. И это позволяет использовать много сервисов для ускорения и повышения надёжности работы сайта. Один из них это Cloudflare Waiting Room, который использовал Ticketon. Надеюсь, теперь стало более понятно, как он работает - все запросы сначала идут в Cloudflare, а он уже решает пропустить их дальше или начать делать редиректы на страницу виртуальной очереди, если запросов слишком много.

Благодаря проксированию также работает кеширование файлов сайта. Когда Cloudflare первый раз получает запрос на shokan.blog, то он пересылает запрос на нашу виртуальную машину в Германии, получает файлы, сохраняет их в кеш, и только потом отправляет их пользователю. И на все последующие запросы он уже не шлёт запросы на нашу виртуальную машину, а просто отдаёт их из кеша.

Надеюсь, читатели смогли понять основные принципы работы Cloudflare. (Если нет, задавайте вопросы в комментариях.) Дальше я периодически буду писать посты, где будем углубляться и изучать конкретные сервисы. А также посмотрим, какие технологии использует Cloudflare для своей работы. Возможно, кто-то из вас захочет их изучить и устроиться в эту компанию. Оставайтесь на связи, будет интересно и полезно 🚀

#cloudflare #anycast

https://vas3k.club/post/28485

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

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

Саму статью очень рекомендую почитать, поскольку она описывает самую суть моего подхода к использованию LLM в работе как над кодом, так и над текстом.