diff --git a/readme.md b/readme.md
index 7cc5294..b70c0ea 100644
--- a/readme.md
+++ b/readme.md
@@ -55,3 +55,4 @@
 * [10.6. Инцидент-менеджмент](/src/homework/10-monitoring/10.6)
 * [11.1. Введение в микросервисы](/src/homework/11-microservices/11.1)
 * [11.2. Микросервисы: принципы](/src/homework/11-microservices/11.2)
+* [11.3. Микросервисы: подходы](/src/homework/11-microservices/11.3)
diff --git a/src/homework/11-microservices/11.2/readme.md b/src/homework/11-microservices/11.2/readme.md
index 394b6b2..5b90760 100644
--- a/src/homework/11-microservices/11.2/readme.md
+++ b/src/homework/11-microservices/11.2/readme.md
@@ -5,7 +5,6 @@
 
 ### Задание 1
 
-
 > Предложите решение для обеспечения реализации API Gateway.
 > Составьте сравнительную таблицу возможностей различных программных решений. На основе таблицы сделайте выбор решения.
 > 
diff --git a/src/homework/11-microservices/11.3/readme.md b/src/homework/11-microservices/11.3/readme.md
new file mode 100644
index 0000000..d6ce081
--- /dev/null
+++ b/src/homework/11-microservices/11.3/readme.md
@@ -0,0 +1,92 @@
+Выполнение [домашнего задания](https://github.com/netology-code/devkub-homeworks/blob/main/11-microservices-03-approaches.md)
+по теме "11.3. Микросервисы: подходы"
+
+## Q/A
+
+> Вы работаете в крупной компанию, которая строит систему на основе микросервисной архитектуры.
+> Вам как DevOps специалисту необходимо выдвинуть предложение по организации инфраструктуры, для разработки и эксплуатации.
+
+### Задание 1
+
+> Обеспечить разработку
+>
+> Предложите решение для обеспечения процесса разработки: хранение исходного кода, непрерывная интеграция и непрерывная поставка.
+> Решение может состоять из одного или нескольких программных продуктов и должно описывать способы и принципы их взаимодействия.
+>
+> Решение должно соответствовать следующим требованиям:
+> - Облачная система;
+> - Система контроля версий Git;
+> - Репозиторий на каждый сервис;
+> - Запуск сборки по событию из системы контроля версий;
+> - Запуск сборки по кнопке с указанием параметров;
+> - Возможность привязать настройки к каждой сборке;
+> - Возможность создания шаблонов для различных конфигураций сборок;
+> - Возможность безопасного хранения секретных данных: пароли, ключи доступа;
+> - Несколько конфигураций для сборки из одного репозитория;
+> - Кастомные шаги при сборке;
+> - Собственные докер образы для сборки проектов;
+> - Возможность развернуть агентов сборки на собственных серверах;
+> - Возможность параллельного запуска нескольких сборок;
+> - Возможность параллельного запуска тестов;
+>
+> Обоснуйте свой выбор.
+
+В данном случае облачный gitlab подойдёт как нельзя хорошо. А именно:
+- `git` и гибкое управление репозиториями
+- гибкая система настройки и управления `CI/CD`, большие возможности по кастомизации шагов сборки
+- возможность хранить секреты в переменных репозитория
+- присутствие приватного `docker-registry` для хранения собранных docker-образов
+
+Дополнительно к `gitlab` необходимо будет развернуть несколько `gitlab-runner`, чтобы непосредственно запускать сборку.
+В рамках конфигурации `gitlab-runner` можно указывать параметры параллельного выполнения.
+
+### Задание 2
+
+> Логи
+> 
+> Предложите решение для обеспечения сбора и анализа логов сервисов в микросервисной архитектуре.
+> Решение может состоять из одного или нескольких программных продуктов и должно описывать способы и принципы их взаимодействия.
+> 
+> Решение должно соответствовать следующим требованиям:
+> - Сбор логов в центральное хранилище со всех хостов обслуживающих систему;
+> - Минимальные требования к приложениям, сбор логов из stdout;
+> - Гарантированная доставка логов до центрального хранилища;
+> - Обеспечение поиска и фильтрации по записям логов;
+> - Обеспечение пользовательского интерфейса с возможностью предоставления доступа разработчикам для поиска по записям логов;
+> - Возможность дать ссылку на сохраненный поиск по записям логов;
+> 
+> Обоснуйте свой выбор.
+
+Для боевой среды может подойти решение `fluentd` + `elk`-стек. Таким образом:
+- `fluentd` будет отвечать за сбор логов из stdout всех docker-контейнеров.
+  Для сбора логов можно настроить для каждого контейнера лог-драйвер `fluentd`
+  и избежать различных проблем при работе с файловой системой.
+- `logstash` будет отвечать за приём логов со всех агентов `fluentd` и максимально преобразовывать логи к единому формату.
+- кластер `elasticsearch` будет отвечать за хранение логов.
+- `kibana` будет выступать в качестве пользовательского интерфейса для просмотра логов.
+  Из коробки в данной системе доступны сохранение и шаринг поисковых запросов по логам. 
+
+### Задание 3
+
+> Мониторинг
+>
+> Предложите решение для обеспечения сбора и анализа состояния хостов и сервисов в микросервисной архитектуре.
+> Решение может состоять из одного или нескольких программных продуктов и должно описывать способы и принципы их взаимодействия.
+> 
+> Решение должно соответствовать следующим требованиям:
+> - Сбор метрик со всех хостов, обслуживающих систему;
+> - Сбор метрик состояния ресурсов хостов: CPU, RAM, HDD, Network;
+> - Сбор метрик потребляемых ресурсов для каждого сервиса: CPU, RAM, HDD, Network;
+> - Сбор метрик, специфичных для каждого сервиса;
+> - Пользовательский интерфейс с возможностью делать запросы и агрегировать информацию;
+> - Пользовательский интерфейс с возможностью настраивать различные панели для отслеживания состояния системы;
+> 
+> Обоснуйте свой выбор.
+
+Для сбора метрик лучше всего использовать prometheus и его агенты. Например, для сбора метрик состояния ресурсов можно использовать [node_exporter](https://github.com/prometheus/node_exporter).
+Этого же агента можно использовать для сбора информации о docker-контейнерах,
+что покроет потребность в отслеживании потребляемых ресурсов каждым сервисом.
+
+Специфичные метрики можно отправлять как непосредственно изнутри приложений, так и при помощи [`push gateway`](https://prometheus.io/docs/practices/pushing/).
+
+Для отображения всей информации идеально подойдёт grafana, в которой возможно построить огромное множество различных графиков и показателей на основе данных prometheus.