Forwarded from Всеволод Викулин | AI разбор
Надеюсь, я не отбил у вас желание разбираться с LLM System Design. Если нет, то продолжаем.
Второй паттерн. Structured output
Вы выдаете желаемую JSON-схему ответа, LLM не может ее нарушить. Работает благодаря 2-м вещам:
1) Ваш формат конвертируется в грамматику. Генерация каждого следующего токена жестко ограничена этой грамматикой. Считайте, что работает регулярка на выходе модели.
2) Базовая модель дообучалась, чтобы понимать по схеме, что вообще от нее хотят.
Удобно задавать через библиотеку Pydantic. Вы просто программируете классы, Pydantic генерирует нужный json. Пример, когда LLM извлекает поля научной статьи:
Optional объясняет, что keywords может быть не у каждой статьи.
Почему важно
- Убирает боль неверных форматов. При условии, что мы все идем к тулам и агентам (подробнее в 3 паттерне), это супер важно.
- Улучшает прозрачность. Все понятно, что модель нашла , а что найти не смогла (там будет None)
- Самодокументация. Вы сами наложили спецификацию на формат данных, потом всем сильно проще будет разобраться в этом коде.
Structured Output и Reasoning
Никто не мешает вам совмещать Structured Output (SO) с рассуждающими моделями. Пусть они выводят свои рассуждения в отдельное (первое) поле:
Есть статьи, которые говорят, что это ломает рассуждающие способности. Решение: пробуйте 2 раза. Сначала рассуждайте без SO, потом извлейкайте ответ с SO (более простой моделью, конечно)
Литература для изучения
- Документация от OpenAI
- Волшебный доклад про Pydantic
- Подробнее про двойной подход в SO + Reasoning
- Туториал по SO для Langchain
Как обычно, любые вопросы жду в комментариях. Все полезные материалы буду помечать хештегом.
#llm_system_design
Второй паттерн. Structured output
Вы выдаете желаемую JSON-схему ответа, LLM не может ее нарушить. Работает благодаря 2-м вещам:
1) Ваш формат конвертируется в грамматику. Генерация каждого следующего токена жестко ограничена этой грамматикой. Считайте, что работает регулярка на выходе модели.
2) Базовая модель дообучалась, чтобы понимать по схеме, что вообще от нее хотят.
Удобно задавать через библиотеку Pydantic. Вы просто программируете классы, Pydantic генерирует нужный json. Пример, когда LLM извлекает поля научной статьи:
from pydantic import BaseModel
class ResearchPaperExtraction(BaseModel):
title: str
authors: list[str]
keywords: Optional[list[str]]
response = client.responses.parse(
model="gpt-4o-2024-08-06",
input=[...],
text_format=ResearchPaperExtraction,
)
Optional объясняет, что keywords может быть не у каждой статьи.
Почему важно
- Убирает боль неверных форматов. При условии, что мы все идем к тулам и агентам (подробнее в 3 паттерне), это супер важно.
- Улучшает прозрачность. Все понятно, что модель нашла , а что найти не смогла (там будет None)
- Самодокументация. Вы сами наложили спецификацию на формат данных, потом всем сильно проще будет разобраться в этом коде.
Structured Output и Reasoning
Никто не мешает вам совмещать Structured Output (SO) с рассуждающими моделями. Пусть они выводят свои рассуждения в отдельное (первое) поле:
class Step(BaseModel):
explanation: str
output: str
Есть статьи, которые говорят, что это ломает рассуждающие способности. Решение: пробуйте 2 раза. Сначала рассуждайте без SO, потом извлейкайте ответ с SO (более простой моделью, конечно)
Литература для изучения
- Документация от OpenAI
- Волшебный доклад про Pydantic
- Подробнее про двойной подход в SO + Reasoning
- Туториал по SO для Langchain
Как обычно, любые вопросы жду в комментариях. Все полезные материалы буду помечать хештегом.
#llm_system_design
Forwarded from Всеволод Викулин | AI разбор
10 паттернов разработки надежных LLM приложений.
Начинаю серию публикаций по LLM System Design.
Если осилите все 10 паттернов - сможете разрабатывать надежные LLM-приложения, которые не сломаются от наплыва счастливых пользователей.
Поехали.
Паттерн 1. LLM приложение это просто граф
Считайте, что вы разрабатываете обычный софт. Используете микросервисную архитектуру. Сервис 1 ждет ответа от Сервиса 2, если ответ = X, то идет в Сервис 3 и тд.
Только теперь у вас некоторые сервисы это не просто код. Может быть вызов LLM-классификатора, в зависимости от вердикта вызываться какой-то другой код. Или вызов LLM-суммаризатора, ответ которого запишется в NOSQL базу данных.
Получается такой недетерминированный граф, который может решать поразительные задачи. Которые не мог решать обычный софт.
Перечислим часто используемые элементы в этом графе:
- Код бизнес логики. Не пытайтесь отдать это на LLM. Читайте про это статью. Туда же я отношу другие элементы разработки - реляционные базы данных, очереди сообщений и тд.
- Вызов LLM. Они могут соединяться различным образом: идти последовательно, параллельно, при выполнении условия и тд. Строго читать статью
- Внешние инструменты. Например, поисковый движок. Похоже на код, но инструменты не делают бизнес логики. Результат инструментов подается на вход в LLM. Разберем в "Паттерн 3. Все есть инструмент".
- Внешняя база знаний. Так делается RAG. Лучший способ заложить внешние знания в LLM. Подробнее обсудим в "Паттерн 4. Всегда используйте in context learning" и "Паттерн 5. Не переусложняйте RAG".
- Не-LLM модели. Обычно это берты/сверточные сети или бустинги над деревьями. Очень быстры и дешевы. Как правило, обучаются дистилляцией. Поговорим про это в "Паттерн 10. Дистилируйте."
- Guardrails. Модели, которая оценивает качество ответа. Если качество плохое, лучше такое никому не показывать. Обсудим в "Паттерн 8. Human-in-the-loop"
- Человек. У него нужно уточнить, когда непонятно, что делать дальше. У него нужно спросить, когда хотим сделать рискованное действие. Подробнее в "Паттерн 8. Human-in-the-loop"
- Автономные агенты. Редкий зверь, но будет чаще встречаться. Почему редкий. Обсудим в "Паттерн 9. Когда нужны автономные агенты."
Литература для изучения
- Строго mustread пост от Anthropic
- Подробная схема LLM-приложений от Chip Huyen
- Пост, почему надо разделять LLM и бизнес логику
- 500 реальных кейсов LLM-приложений
- Подробный гайд с большим числом деталей
- Принципы проектирования агентов (многое можно почерпнуть и для неагентов)
Как обычно, любые вопросы жду в комментариях. Все разберем.
#llm_system_design
Начинаю серию публикаций по LLM System Design.
Если осилите все 10 паттернов - сможете разрабатывать надежные LLM-приложения, которые не сломаются от наплыва счастливых пользователей.
Поехали.
Паттерн 1. LLM приложение это просто граф
Считайте, что вы разрабатываете обычный софт. Используете микросервисную архитектуру. Сервис 1 ждет ответа от Сервиса 2, если ответ = X, то идет в Сервис 3 и тд.
Только теперь у вас некоторые сервисы это не просто код. Может быть вызов LLM-классификатора, в зависимости от вердикта вызываться какой-то другой код. Или вызов LLM-суммаризатора, ответ которого запишется в NOSQL базу данных.
Получается такой недетерминированный граф, который может решать поразительные задачи. Которые не мог решать обычный софт.
Перечислим часто используемые элементы в этом графе:
- Код бизнес логики. Не пытайтесь отдать это на LLM. Читайте про это статью. Туда же я отношу другие элементы разработки - реляционные базы данных, очереди сообщений и тд.
- Вызов LLM. Они могут соединяться различным образом: идти последовательно, параллельно, при выполнении условия и тд. Строго читать статью
- Внешние инструменты. Например, поисковый движок. Похоже на код, но инструменты не делают бизнес логики. Результат инструментов подается на вход в LLM. Разберем в "Паттерн 3. Все есть инструмент".
- Внешняя база знаний. Так делается RAG. Лучший способ заложить внешние знания в LLM. Подробнее обсудим в "Паттерн 4. Всегда используйте in context learning" и "Паттерн 5. Не переусложняйте RAG".
- Не-LLM модели. Обычно это берты/сверточные сети или бустинги над деревьями. Очень быстры и дешевы. Как правило, обучаются дистилляцией. Поговорим про это в "Паттерн 10. Дистилируйте."
- Guardrails. Модели, которая оценивает качество ответа. Если качество плохое, лучше такое никому не показывать. Обсудим в "Паттерн 8. Human-in-the-loop"
- Человек. У него нужно уточнить, когда непонятно, что делать дальше. У него нужно спросить, когда хотим сделать рискованное действие. Подробнее в "Паттерн 8. Human-in-the-loop"
- Автономные агенты. Редкий зверь, но будет чаще встречаться. Почему редкий. Обсудим в "Паттерн 9. Когда нужны автономные агенты."
Литература для изучения
- Строго mustread пост от Anthropic
- Подробная схема LLM-приложений от Chip Huyen
- Пост, почему надо разделять LLM и бизнес логику
- 500 реальных кейсов LLM-приложений
- Подробный гайд с большим числом деталей
- Принципы проектирования агентов (многое можно почерпнуть и для неагентов)
Как обычно, любые вопросы жду в комментариях. Все разберем.
#llm_system_design
Forwarded from TechSparks
Как-то я это пропустил; или просто недавно появилось: курс для самостоятельного знакомства с ИИ с отличным названием Introduction to AI Fluency; курс хорош тем, что это не очередной бессмысленный справочник по промтам, а пособие по структуре работы с ИИ, актуальное на 2025. Здесь и про делегирование ИИ, и про работу над реальными (хотя и модельными) проектами на каждом занятии.
Помимо содержательной стороны это еще и пример того, как можно сделать современный образовательный продукт, а не просто очередной видеокурс.
https://www.anthropic.com/ai-fluency/overview
Помимо содержательной стороны это еще и пример того, как можно сделать современный образовательный продукт, а не просто очередной видеокурс.
https://www.anthropic.com/ai-fluency/overview
Anthropic Courses
Learn to build with Claude AI
through Anthropic's comprehensive courses and training programs.
through Anthropic's comprehensive courses and training programs.
Forwarded from дAI потестить!
This media is not supported in your browser
VIEW IN TELEGRAM
Forwarded from дAI потестить!
Где сделать себе генеративное личико по одному фото, не устанавливая ComfyUI и не тренируя эти ваши Lora
1. https://app.klingai.com/global/text-to-image
2. https://sora.chatgpt.com/
3. https://www.skyreels.ai/home/tools/text2image
4. https://hailuoai.video/create
5. https://dreamina.capcut.com/ai-tool/image/generate
P.S. Кидайте в комменты о каком сервисе забыл, добавлю.
#faceswap@dAIpotestit
1. https://app.klingai.com/global/text-to-image
2. https://sora.chatgpt.com/
3. https://www.skyreels.ai/home/tools/text2image
4. https://hailuoai.video/create
5. https://dreamina.capcut.com/ai-tool/image/generate
P.S. Кидайте в комменты о каком сервисе забыл, добавлю.
#faceswap@dAIpotestit
Forwarded from дAI потестить!
Памятка видео модель Wan2 (локальненько)
🔗 Основные репозитории
• Wan2.1 GitHub
github.com/Wan-Video/Wan2.1
• ComfyUI Wrapper
github.com/kijai/ComfyUI-WanVideoWrapper
🧩 Модели:
• VAE
huggingface.co/Kijai/WanVideo_comfy/blob/main/Wan2_1_VAE_bf16.safetensors
• CLIP Vision
huggingface.co/Comfy-Org/Wan_2.1_ComfyUI_repackaged/resolve/main/split_files/clip_vision/clip_vision_h.safetensors?download=true
• UMT5 text encoder
huggingface.co/Kijai/WanVideo_comfy/blob/main/umt5-xxl-enc-fp8_e4m3fn.safetensors
huggingface.co/OreX/Models/blob/main/WAN/umt5_xxl_fp8_e4m3fn_scaled.safetensors
• Diffusion models
huggingface.co/Kijai/WanVideo_comfy/blob/main/Wan2_1-I2V-14B-480P_fp8_e4m3fn.safetensors
huggingface.co/Kijai/WanVideo_comfy/blob/main/Wan2_1-I2V-14B-720P_fp8_e4m3fn.safetensors
huggingface.co/city96/Wan2.1-I2V-14B-480P-gguf/blob/main/wan2.1-i2v-14b-480p-Q4_K_M.gguf
huggingface.co/Kijai/WanVideo_comfy/blob/main/Wan2_1-T2V-14B_fp8_e4m3fn.safetensors
huggingface.co/Kijai/WanVideo_comfy/blob/main/Wan2_1-T2V-1_3B_fp8_e4m3fn.safetensors
huggingface.co/city96/Wan2.1-I2V-14B-480P-gguf
civitai.com/models/1299436?modelVersionId=1466629
🛠 Кастомные ноды для ComfyUI:
• NF4/FP4 Loader
github.com/silveroxides/ComfyUI_bnb_nf4_fp4_Loaders
• GGUF Loader
github.com/city96/ComfyUI-GGUF
⚡️ Воркфлоу и примеры:
• wan_t2v_1.3b - текст в видео
github.com/Mozer/comfy_stuff/blob/main/workflows/wan_1.3b_t2v.json
• wan_i2v_14b_nf4_gguf - воркфлоу с квантами
github.com/Mozer/comfy_stuff/blob/main/workflows/wan_14b_i2v.json
• wanvideo_Fun - Fun модель (есть контроль видео)
github.com/kijai/ComfyUI-WanVideoWrapper/blob/main/example_workflows/wanvideo_Fun_control_example_01.json
• wan_1_3B_VACE_v2v_with_depth_and_lora (есть контроль и референс)
github.com/Mozer/comfy_stuff/blob/main/workflows/wan_1_3B_VACE_v2v_with_depth_and_lora.json
• wanvideo_FLF2V_720P - первый и последний кадр
github.com/kijai/ComfyUI-WanVideoWrapper/blob/main/example_workflows/wanvideo_FLF2V_720P_example_01.json
🎨 Лоры:
• Control Loras (spacepxl) - контролим видео
huggingface.co/spacepxl/Wan2.1-control-loras
• Remade-AI - крутой набор лор
huggingface.co/Remade-AI
• Depth LoRA (1.3B) - контролим лорой глубины
huggingface.co/spacepxl/Wan2.1-control-loras/blob/main/1.3b/depth/wan2.1-1.3b-control-lora-depth-v0.1_comfy.safetensors
🔥 Интересное
VACE
Remove/Replace ANYTHING (VACE + Wan2.1):
• Удаление объектов
civitai.com/models/1454934/remove-anything-with-vacewan21
youtube.com/watch?v=vioEox7CKUs
• Замена объектов
civitai.com/models/1470557?modelVersionId=1663316
youtube.com/watch?v=L9OJ-RsDNlY
• VACE GitHub
github.com/ali-vilab/VACE
• Wan+VACE ноды
github.com/kijai/ComfyUI-WanVideoWrapper
• Depth-Anything Nodes
github.com/DepthAnything/Depth-Anything-V2
Wan2.1-Fun-1.3B-InP:
• Модель
huggingface.co/spaces/alibaba-pai/Wan2.1-Fun-1.3B-InP
• Control LoRA
huggingface.co/alibaba-pai/Wan2.1-Fun-1.3B-Control
• FP8 веса Kijai
huggingface.co/Kijai/WanVideo_comfy/tree/main
• Wan2GP (low VRAM)
github.com/deepbeepmeep/Wan2GP
WAN 2.1 Fun ControlNet 1.1 (Alibaba):
• Хаггингфейс
huggingface.co/alibaba-pai/Wan2.1-Fun-V1.1-14B-Control/blob/main/README_en.md
• GitHub
github.com/aigc-apps/VideoX-Fun
• ComfyUI Readme
github.com/aigc-apps/VideoX-Fun/blob/main/comfyui/README.md
До 81 кадра, до 16 fps, до 1024p
Поддержка управления камерой и анимации по референсу
FLF2V (first-last-frame):
• Модель
huggingface.co/Wan-AI/Wan2.1-FLF2V-14B-720P
• Wan2.1 сайт
wan.video/
• Workflow пример
github.com/kijai/ComfyUI-WanVideoWrapper/blob/main/example_workflows/wanvideo_FLF2V_720P_example_01.json
🕹 Специализированные проекты
ReCamMaster:
• Код
github.com/KwaiVGI/ReCamMaster
• Workflow
drive.google.com/file/d/1E8fxHIhM9qI9YeeAxdTf3SmfqktZAN2W/view
• Видеотуториал
youtube.com/watch?v=TzkBJHu2P4s
🔗 Основные репозитории
• Wan2.1 GitHub
github.com/Wan-Video/Wan2.1
• ComfyUI Wrapper
github.com/kijai/ComfyUI-WanVideoWrapper
🧩 Модели:
• VAE
huggingface.co/Kijai/WanVideo_comfy/blob/main/Wan2_1_VAE_bf16.safetensors
• CLIP Vision
huggingface.co/Comfy-Org/Wan_2.1_ComfyUI_repackaged/resolve/main/split_files/clip_vision/clip_vision_h.safetensors?download=true
• UMT5 text encoder
huggingface.co/Kijai/WanVideo_comfy/blob/main/umt5-xxl-enc-fp8_e4m3fn.safetensors
huggingface.co/OreX/Models/blob/main/WAN/umt5_xxl_fp8_e4m3fn_scaled.safetensors
• Diffusion models
huggingface.co/Kijai/WanVideo_comfy/blob/main/Wan2_1-I2V-14B-480P_fp8_e4m3fn.safetensors
huggingface.co/Kijai/WanVideo_comfy/blob/main/Wan2_1-I2V-14B-720P_fp8_e4m3fn.safetensors
huggingface.co/city96/Wan2.1-I2V-14B-480P-gguf/blob/main/wan2.1-i2v-14b-480p-Q4_K_M.gguf
huggingface.co/Kijai/WanVideo_comfy/blob/main/Wan2_1-T2V-14B_fp8_e4m3fn.safetensors
huggingface.co/Kijai/WanVideo_comfy/blob/main/Wan2_1-T2V-1_3B_fp8_e4m3fn.safetensors
huggingface.co/city96/Wan2.1-I2V-14B-480P-gguf
civitai.com/models/1299436?modelVersionId=1466629
🛠 Кастомные ноды для ComfyUI:
• NF4/FP4 Loader
github.com/silveroxides/ComfyUI_bnb_nf4_fp4_Loaders
• GGUF Loader
github.com/city96/ComfyUI-GGUF
⚡️ Воркфлоу и примеры:
• wan_t2v_1.3b - текст в видео
github.com/Mozer/comfy_stuff/blob/main/workflows/wan_1.3b_t2v.json
• wan_i2v_14b_nf4_gguf - воркфлоу с квантами
github.com/Mozer/comfy_stuff/blob/main/workflows/wan_14b_i2v.json
• wanvideo_Fun - Fun модель (есть контроль видео)
github.com/kijai/ComfyUI-WanVideoWrapper/blob/main/example_workflows/wanvideo_Fun_control_example_01.json
• wan_1_3B_VACE_v2v_with_depth_and_lora (есть контроль и референс)
github.com/Mozer/comfy_stuff/blob/main/workflows/wan_1_3B_VACE_v2v_with_depth_and_lora.json
• wanvideo_FLF2V_720P - первый и последний кадр
github.com/kijai/ComfyUI-WanVideoWrapper/blob/main/example_workflows/wanvideo_FLF2V_720P_example_01.json
🎨 Лоры:
• Control Loras (spacepxl) - контролим видео
huggingface.co/spacepxl/Wan2.1-control-loras
• Remade-AI - крутой набор лор
huggingface.co/Remade-AI
• Depth LoRA (1.3B) - контролим лорой глубины
huggingface.co/spacepxl/Wan2.1-control-loras/blob/main/1.3b/depth/wan2.1-1.3b-control-lora-depth-v0.1_comfy.safetensors
🔥 Интересное
VACE
Remove/Replace ANYTHING (VACE + Wan2.1):
• Удаление объектов
civitai.com/models/1454934/remove-anything-with-vacewan21
youtube.com/watch?v=vioEox7CKUs
• Замена объектов
civitai.com/models/1470557?modelVersionId=1663316
youtube.com/watch?v=L9OJ-RsDNlY
• VACE GitHub
github.com/ali-vilab/VACE
• Wan+VACE ноды
github.com/kijai/ComfyUI-WanVideoWrapper
• Depth-Anything Nodes
github.com/DepthAnything/Depth-Anything-V2
Wan2.1-Fun-1.3B-InP:
• Модель
huggingface.co/spaces/alibaba-pai/Wan2.1-Fun-1.3B-InP
• Control LoRA
huggingface.co/alibaba-pai/Wan2.1-Fun-1.3B-Control
• FP8 веса Kijai
huggingface.co/Kijai/WanVideo_comfy/tree/main
• Wan2GP (low VRAM)
github.com/deepbeepmeep/Wan2GP
WAN 2.1 Fun ControlNet 1.1 (Alibaba):
• Хаггингфейс
huggingface.co/alibaba-pai/Wan2.1-Fun-V1.1-14B-Control/blob/main/README_en.md
• GitHub
github.com/aigc-apps/VideoX-Fun
• ComfyUI Readme
github.com/aigc-apps/VideoX-Fun/blob/main/comfyui/README.md
До 81 кадра, до 16 fps, до 1024p
Поддержка управления камерой и анимации по референсу
FLF2V (first-last-frame):
• Модель
huggingface.co/Wan-AI/Wan2.1-FLF2V-14B-720P
• Wan2.1 сайт
wan.video/
• Workflow пример
github.com/kijai/ComfyUI-WanVideoWrapper/blob/main/example_workflows/wanvideo_FLF2V_720P_example_01.json
🕹 Специализированные проекты
ReCamMaster:
• Код
github.com/KwaiVGI/ReCamMaster
• Workflow
drive.google.com/file/d/1E8fxHIhM9qI9YeeAxdTf3SmfqktZAN2W/view
• Видеотуториал
youtube.com/watch?v=TzkBJHu2P4s
Forwarded from запуск завтра
Гугл опубликовал пост-мортем по позавчерашнему падению. Обычные ошибки, только на инфраструктуре планетарного масштаба.
У них есть внутренний сервис, который проверяет доступы (бабки, квоты и т. д.) перед тем, как API запрос доходит до любого продукта.
Эта программа берет из специальной глобальной базы данных правила, по которым проверяет каждый запрос и отвечает, пропускать его или нет.
В эту программу добавили поддержку нового типа квот. Программист допустил небрежность в новом коде и не проверял, насколько корректно записано это правило в базе, перед тем, как пытаться положить его в память. Обращение к несуществующей памяти — смертный грех, за такое программа мгновенно завершается (если программист не предусмотрел, что такое может случиться, а это не наш случай). При этом я бы не назвал это ошибкой, все мы люди, мы не идеальны и поэтому придумываем механизмы защиты от своей природы. В этом суть инженерного подхода.
Экземпляр этой программы работает в каждом регионе Гугла. Так как это серьезный, ключевой сервис, его выкатывают не во все регионы сразу, а по одному, внимательно отслеживая, не внесли ли программисты новые ошибки.
Более того, весь новый функционал специально помечают и сначала запускают только для внутреннего пользования, чтобы, даже при наличии ошибки, она не задела внешних клиентов. Этот механизм называется фича-флагами.
К сожалению, программист забыл настроить фича-флаги для этого кода. Кусочек программы с ошибкой запустился на всех пользователей сразу. Удивительно, что это не заметили на этапе code review!
Итак, проходит время, и вот программа с ошибкой запущена во всех регионах для всех пользователей. Кто-то добавляет в базу данных новое правило с новым типом квот, с пустым полем. Эта запись в течение десятков миллисекунд копируется во все регионы, и в каждом регионе программа проверки считывает новое правило, пытается обратиться к несуществующей памяти, падает, перезапускается и снова падает.
Тут в дело вступает, на мой взгляд, первая ошибка (а не просто человеческая небрежность) инженеров — система контроля доступа настроена так, что при отсутствии ответа от программы проверок она отклоняет запрос. Так называемый fail closed. Хорошо для замков на банковских сейфах, плохо для пожарных выходов.
В нашем случае система не пропускает ни один запрос.
Дежурные инженеры замечают проблему в течение 2 минут, за 10 минут находят причину (дежурная система и дежурные инженеры у Гугла достойны восхищения) и нажимают большую красную кнопку, которая должна выключить эту часть программы (ее программисты сделали). Ее включение занимает еще 30 минут. (Не понятно, почему этот механизм занимает 30 минут, а не 20 миллисекунд, но движемся дальше).
Система заработала, но из-за того, что она лежала 40 минут, накопилось много желающих отправить запрос еще раз, и они создали эффект толпы, которая набежала и перегрузила остальные соседние сервисы через наш сервис проверок. Оказалось, что он не ждет какое-то время, если нужный сервис отказывается ответить на запрос (для этого есть красивая схема exponential back off), а долбит до упаду, тем самым не давая системе возможности восстановиться. Пришлось руками ограничивать число запросов. На постепенную, ручную разгрузку очередей ушло еще 2 часа.
Ко всему прочему, Гугл час не мог опубликовать уведомление о проблеме, потому что сервис публикации статус-страниц зависит от системы, которая упала.
Как вывод, Гугл обещает пройтись по всем сервисам и убедиться, что они, во-первых, fail open, то есть пропускают запросы, когда падают, во-вторых, реализуют exponential back off, если на их запрос не отвечают, а не добивают лежачего, и, наконец, в-третьих, что даже глобальные добавления правил должны прилетать во все регионы не сразу, а с некоторыми задержками. Ещё обещают добавить эти проверки в свои статические анализаторы кода, завидую!
Первые два пункта можно и нужно использовать в каждом проекте, даже если ты не Гугл.
У них есть внутренний сервис, который проверяет доступы (бабки, квоты и т. д.) перед тем, как API запрос доходит до любого продукта.
Эта программа берет из специальной глобальной базы данных правила, по которым проверяет каждый запрос и отвечает, пропускать его или нет.
В эту программу добавили поддержку нового типа квот. Программист допустил небрежность в новом коде и не проверял, насколько корректно записано это правило в базе, перед тем, как пытаться положить его в память. Обращение к несуществующей памяти — смертный грех, за такое программа мгновенно завершается (если программист не предусмотрел, что такое может случиться, а это не наш случай). При этом я бы не назвал это ошибкой, все мы люди, мы не идеальны и поэтому придумываем механизмы защиты от своей природы. В этом суть инженерного подхода.
Экземпляр этой программы работает в каждом регионе Гугла. Так как это серьезный, ключевой сервис, его выкатывают не во все регионы сразу, а по одному, внимательно отслеживая, не внесли ли программисты новые ошибки.
Более того, весь новый функционал специально помечают и сначала запускают только для внутреннего пользования, чтобы, даже при наличии ошибки, она не задела внешних клиентов. Этот механизм называется фича-флагами.
К сожалению, программист забыл настроить фича-флаги для этого кода. Кусочек программы с ошибкой запустился на всех пользователей сразу. Удивительно, что это не заметили на этапе code review!
Итак, проходит время, и вот программа с ошибкой запущена во всех регионах для всех пользователей. Кто-то добавляет в базу данных новое правило с новым типом квот, с пустым полем. Эта запись в течение десятков миллисекунд копируется во все регионы, и в каждом регионе программа проверки считывает новое правило, пытается обратиться к несуществующей памяти, падает, перезапускается и снова падает.
Тут в дело вступает, на мой взгляд, первая ошибка (а не просто человеческая небрежность) инженеров — система контроля доступа настроена так, что при отсутствии ответа от программы проверок она отклоняет запрос. Так называемый fail closed. Хорошо для замков на банковских сейфах, плохо для пожарных выходов.
В нашем случае система не пропускает ни один запрос.
Дежурные инженеры замечают проблему в течение 2 минут, за 10 минут находят причину (дежурная система и дежурные инженеры у Гугла достойны восхищения) и нажимают большую красную кнопку, которая должна выключить эту часть программы (ее программисты сделали). Ее включение занимает еще 30 минут. (Не понятно, почему этот механизм занимает 30 минут, а не 20 миллисекунд, но движемся дальше).
Система заработала, но из-за того, что она лежала 40 минут, накопилось много желающих отправить запрос еще раз, и они создали эффект толпы, которая набежала и перегрузила остальные соседние сервисы через наш сервис проверок. Оказалось, что он не ждет какое-то время, если нужный сервис отказывается ответить на запрос (для этого есть красивая схема exponential back off), а долбит до упаду, тем самым не давая системе возможности восстановиться. Пришлось руками ограничивать число запросов. На постепенную, ручную разгрузку очередей ушло еще 2 часа.
Ко всему прочему, Гугл час не мог опубликовать уведомление о проблеме, потому что сервис публикации статус-страниц зависит от системы, которая упала.
Как вывод, Гугл обещает пройтись по всем сервисам и убедиться, что они, во-первых, fail open, то есть пропускают запросы, когда падают, во-вторых, реализуют exponential back off, если на их запрос не отвечают, а не добивают лежачего, и, наконец, в-третьих, что даже глобальные добавления правил должны прилетать во все регионы не сразу, а с некоторыми задержками. Ещё обещают добавить эти проверки в свои статические анализаторы кода, завидую!
Первые два пункта можно и нужно использовать в каждом проекте, даже если ты не Гугл.
Forwarded from AB тесты и все вот про это вот все
О бедном т-тесте замолвите слово. Подробный разбор метода, в том числе "легендарное" требование нормальности распределения для использования т-теста.
YouTube
Мифы и заблуждения про t-тест (t-критерий Стюдента, t-критерий Уэлча)
Многие уверены, что знают, как проводить t-тест, но на деле допускают однотипные ошибки. Преподаватель karpov.cоurses Александр Сахнов на примерах разбирает типичные заблуждения о t-тесте и показывает, как правильно работать с самым популярным статистическим…