diff --git a/README.md b/README.md
index f3f82b0..8f8837b 100644
--- a/README.md
+++ b/README.md
@@ -10,6 +10,8 @@
 
 [Дизайн документ](./docs/DESIGN.md)
 
+
+[Отчет по INFRA](./docs/INFRA_REPORT.md)
 [Отчет по MVP](./docs/MVP_REPORT.md)
 
 # Визуал
diff --git a/docs/INFRA_REPORT.md b/docs/INFRA_REPORT.md
new file mode 100644
index 0000000..a5ec2c9
--- /dev/null
+++ b/docs/INFRA_REPORT.md
@@ -0,0 +1,14 @@
+# Отчет HW3
+
+На инфраструктурном этапе мы выбрали контейнеризацию через Docker и Docker Compose, а также базовую обвязку вокруг основного приложения, необходимую для стабильного запуска проекта на сервере.
+Стек быстро разворачивается и позволяет без лишней сложности поднять не только само приложение, но и сопутствующие сервисы, необходимые для проекта.
+Основная цель на этом этапе была не в построении избыточно сложной production-платформы, а в том, чтобы получить воспроизводимый и управляемый деплой.
+
+Основные сложности возникли на стороне сети и конфигурации окружения. У хостера на машине использовался `MTU=1450`,
+тогда как Docker по умолчанию работал с `MTU=1500`, и из-за этого часть сетевого взаимодействия работала нестабильно.
+На поиск причины ушло достаточно много времени, потому что проблема проявлялась неочевидно и сначала выглядела как сбой на других уровнях.
+Дополнительно задержки возникли из-за того, что DNS-записи применялись не сразу, поэтому часть проблем с доступностью сервиса по доменному имени сначала
+было сложно отделить от проблем в конфигурации самого деплоя
+
+Отдельной сложностью стала отправка `traces`: они долго не доходили до системы наблюдаемости, и пришлось отдельно разбираться с настройками сети,
+агента и конфигурацией экспорта телеметрии. В итоге проблему решали поэтапной проверкой всей цепочки: от приложения и контейнера до принимающего сервиса