🧠 Основы

Git — распределённая система контроля версий. Позволяет отслеживать изменения в коде, работать в команде и возвращаться к любому состоянию проекта.
GitHub — онлайн-платформа для хостинга репозиториев Git. Обеспечивает удобный веб-интерфейс, управление пулреквестами, кодревью и автоматизацию.

📁 Репозитории

• Репозиторий (Repository) — проект, отслеживаемый с помощью Git. Содержит весь код, историю изменений, конфигурации, ветки и коммиты.
• Локальный репозиторий — версия проекта на вашем компьютере.
• Удалённый репозиторий (Remote) — версия проекта на сервере, например, на GitHub. Обычно называется origin.
• Fork (Форк) — копия чужого репозитория в вашем GitHub-аккаунте. Используется для самостоятельной работы и последующего внесения изменений обратно через Pull Request.

📌 Ветки и изменения

• Branch (Ветка) — отдельная «линия» разработки. Позволяет параллельно работать над фичами, багфиксом и экспериментами.
• Master / Main — основная ветка проекта. Сейчас чаще используется название main.
• Commit (Коммит) — сохранённое изменение. Содержит снимок состояния проекта с комментарием и автором.
• Push — отправка локальных коммитов в удалённый репозиторий.
• Pull — получение новых изменений из удалённого репозитория.
• Clone — скачивание репозитория с GitHub на локальную машину.
• Checkout — переключение между ветками или коммитами.
• Merge (Мёрдж) — объединение изменений из одной ветки в другую.
• Rebase (Ребейз) — «перепроигрывание» коммитов поверх другой ветки. Помогает сделать историю проекта линейной.
• Merge conflict (Конфликт слияния) — ситуация, когда Git не может автоматически объединить ветки, и разработчику нужно вручную выбрать, какие изменения оставить.
• Stash (Ста́ш) — временное сохранение изменений без коммита. Удобно, когда нужно срочно переключиться на другую задачу.

📦 Работа с форками

• Обновиться из апстрима (upstream) — синхронизировать свою копию проекта (форк) с оригинальным репозиторием.
• Обновиться из ориджина (origin) — получить обновления с удалённой версии своего же репозитория.

🧪 Проверка и публикация

• Pull Request (PR) — предложение внести изменения из одной ветки в другую. Обычно используется для отправки изменений в основной репозиторий.
• Code Review (Кодревью) — проверка кода другим разработчиком перед слиянием в основную ветку. Оценивается стиль, читаемость, безопасность и логика.
• CI/CD (Continuous Integration / Continuous Delivery) — автоматизация запуска тестов, сборок и деплоя после коммита или PR.

🛠 Полезные команды

git clone <url>            # клонирование репозитория
git checkout -b <branch>   # создание и переход в новую ветку
git add .                  # добавление всех изменений в индекс
git commit -m "comment"    # фиксация изменений
git push                   # отправка в удалённый репозиторий
git pull                   # получение новых изменений
git merge <branch>         # слияние ветки
git rebase <branch>        # ребейз на другую ветку
git stash                  # сохранение изменений во временное хранилище
git stash pop              # восстановление изменений из stash

📌 Итог

Git и GitHub — это основа современной командной разработки. Понимание всех этих терминов и их практическое применение помогает не только грамотно управлять кодом, но и выстраивать эффективную командную работу.

SOAP изначально разработан для работы в корпоративной среде, где безопасность критически важна. Он поддерживает WS-Security, стандарт, который добавляет к сообщениям:

• Шифрование 🔐 – данные можно зашифровать так, что их сможет прочитать только получатель.
• Подписи ✍️ – сообщения можно подписывать цифровыми подписями, чтобы убедиться, что они не были изменены в процессе передачи.
• Аутентификацию 🔑 – можно требовать, чтобы отправитель доказывал свою личность с помощью токенов, сертификатов и других методов.

💡 Пример: В банковских системах SOAP используется для передачи платежных данных, потому что он может обеспечить их защиту от взлома и подмены.

🏢 2. Поддержка сложных схем авторизации

SOAP поддерживает такие мощные механизмы аутентификации, как:

• SAML (Security Assertion Markup Language) – используется в корпоративных системах для единого входа (SSO).
• OAuth + WS-Security – можно комбинировать оба метода для усиленной защиты.
• X.509 сертификаты – можно использовать цифровые сертификаты для безопасного обмена данными.

💡 Пример: SOAP идеально подходит для работы с государственными порталами и крупными корпорациями, где требуется высокая степень безопасности.

📜 3. Чёткая спецификация и строгая структура

SOAP использует XML, и у него есть строгая схема, которая предотвращает ошибки в данных.
REST же может работать с разными форматами (JSON, XML, YAML), и поэтому у него нет встроенных механизмов проверки, как у SOAP.

💡 Пример: Если REST API отправит некорректный JSON (например, забудет кавычки), сервер может неправильно его обработать. В SOAP такого не будет – все данные проверяются на соответствие схеме.

🔄 4. Сообщения передаются через POST, что сложнее для атак

SOAP всегда использует метод POST, а это означает, что данные передаются в теле запроса, а не в URL.
В REST часто используют GET, и параметры передаются в адресной строке, что делает их уязвимыми для атак (например, их можно подглядеть в логах).

💡 Пример: В SOAP банковский перевод будет отправляться через POST, и никто не сможет увидеть параметры в URL. В REST, если бы использовался GET, данные могли бы попасть в логи сервера и стать уязвимыми.

🛡️ 5. SOAP поддерживает MTOM – безопасную передачу бинарных данных

Если нужно передавать файлы, SOAP делает это через MTOM (Message Transmission Optimization Mechanism), который автоматически шифрует и защищает файлы. В REST приходится либо использовать Base64 (что увеличивает размер файлов), либо настраивать дополнительные уровни безопасности.

💡 Пример: Если нужно передавать скан паспорта, SOAP зашифрует его встроенными средствами, а в REST это нужно делать вручную.

🏆 Итог: Когда использовать SOAP вместо REST?

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

📌 Но! REST проще и быстрее для большинства задач, особенно в веб-разработке. Если безопасность не критична, REST будет удобнее.

🔒 Реальные примеры использования SOAP vs REST в безопасности

1️⃣ Банковские переводы и платежные системы 🏦💰

Почему SOAP?

• Банки используют SOAP для перевода денег, потому что он поддерживает WS-Security и шифрование данных.
• SOAP гарантирует, что данные не изменятся при передаче.
• Работает с SAML, который позволяет безопасно аутентифицировать пользователей.

📌 Пример:
Допустим, ты отправляешь деньги через интернет-банк.
Система отправляет SOAP-запрос с твоими данными:

<soapenv:Envelope>
  <soapenv:Header>
    <wsse:Security>
      <wsse:UsernameToken>
        <wsse:Username>user123</wsse:Username>
        <wsse:Password>securepassword</wsse:Password>
      </wsse:UsernameToken>
    </wsse:Security>
  </soapenv:Header>
  <soapenv:Body>
    <TransferFunds>
      <FromAccount>12345678</FromAccount>
      <ToAccount>87654321</ToAccount>
      <Amount>1000</Amount>
    </TransferFunds>
  </soapenv:Body>
</soapenv:Envelope>

🔹 Тут пароль зашифрован и передаётся в заголовке, что делает атаку сложнее.
🔹 В REST тот же запрос мог бы передаваться через GET (что небезопасно) или POST, но без встроенной защиты данных.

2️⃣ Государственные сервисы и налоги 🏛️📄

Почему SOAP?

• В налоговых системах SOAP используется из-за строгого контроля передачи данных.
• Налоговые декларации шифруются, аутентифицируются с помощью цифровых сертификатов (X.509).

📌 Пример:
Когда компания подаёт налоговую декларацию, данные должны быть подписаны и зашифрованы, чтобы никто их не изменил. SOAP позволяет это сделать автоматически.

🔹 REST API не имеет встроенной поддержки цифровых подписей, и разработчикам пришлось бы добавлять это вручную.

3️⃣ Безопасность в медицине 🏥🔬

Почему SOAP?

• В медицинских сервисах, таких как HL7 (стандарт передачи медицинских данных), SOAP используется для передачи конфиденциальной информации.
• Данные зашифрованы и подписаны, чтобы не было подмены.

📌 Пример:
Больница отправляет SOAP-запрос с медицинскими данными пациента в страховую компанию:

<soapenv:Envelope>
  <soapenv:Header>
    <wsse:Security>
      <wsse:BinarySecurityToken ValueType="X.509">
        MIIBIjANBgkqh...
      </wsse:BinarySecurityToken>
    </wsse:Security>
  </soapenv:Header>
  <soapenv:Body>
    <PatientRecord>
      <ID>98765</ID>
      <Name>John Doe</Name>
      <Diagnosis>COVID-19</Diagnosis>
    </PatientRecord>
  </soapenv:Body>
</soapenv:Envelope>

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

4️⃣ Передача файлов и защищённые документы 📁🔐

Почему SOAP?

• SOAP поддерживает MTOM (Message Transmission Optimization Mechanism), который позволяет передавать зашифрованные файлы.
• REST приходится кодировать файлы в Base64, что увеличивает их размер и снижает безопасность.

📌 Пример:
Компания отправляет скан паспорта в банк для верификации личности.
SOAP передаёт его зашифрованным файлом:

<soapenv:Envelope>
  <soapenv:Body>
    <UploadDocument>
      <File>binary_data</File>
    </UploadDocument>
  </soapenv:Body>
</soapenv:Envelope>

🔹 REST пришлось бы делать это через обычный POST, что не так безопасно.

5️⃣ Корпоративные системы (Microsoft, IBM, Oracle) 🏢💼

Почему SOAP?

• Крупные компании используют SOAP для внутренних API, где важна строгая безопасность и контроль.
• Например, в Microsoft Active Directory аутентификация пользователей происходит через SOAP-запросы.

📌 Пример:
Когда сотрудник входит в корпоративную систему, его логин передаётся с цифровой подписью, а не обычным паролем, как в REST.

🔹 REST чаще используют для открытых API, например, в мобильных приложениях или веб-сервисах.

Вывод: Где использовать SOAP, а где REST?

🚀 Когда REST лучше?

REST лучше, если:
✔ Нужно простое и быстрое API (например, для мобильного приложения 📱).
✔ Безопасность не критична (например, блог, новости 📰).
✔ Нужно работать с браузерами (REST API легко интегрируются в фронтенд).

🔒 Когда использовать SOAP?

SOAP лучше, если:
✔ Требуется высокий уровень безопасности 🔐.
✔ Нужно передавать конфиденциальные данные (банки, медицина, госуслуги).
✔ Важна строгая структура данных и их неизменность.

🔥 Итог: SOAP – это как броневик для данных, а REST – как легковая машина 🚗. Если нужно максимальная защита, выбирай SOAP. Если важна скорость и удобство, лучше REST.

• Описание сервисов
• 🔹 API Gateway 🚪
• 🔹 Auth Service (Сервис авторизации) 🔑
• 🔹 Transaction Service (Сервис транзакций) 💰
• 🔹 RabbitMQ (Очередь сообщений) 📩
• 🔹 Notification Service (Сервис уведомлений) 📢
• 🔹 Kafka (Платформа потоковой обработки) 🔄
• 🔹 Kibana (Мониторинг) 📊
• 🔹 PostgreSQL (Реляционная база данных) 🗄
• 🔹 Redis (Кэш) ⚡
• 💡 Различия между Kafka и RabbitMQ 🤔
• 💡 Различия между Redis и PostgreSQL 🧐
• Как это всё работает
• Примеры позитивных сценариев
• 1. Проверка платежной транзакции
• 2. Проверка получения баланса
• Примеры негативных сценариев
• 1. Ошибка авторизации (Auth Service)
• 2. Недостаточно средств на счёте (Transaction Service)
• 3. Некорректные данные запроса (API Gateway / Transaction Service)
• 🛠 Что важно проверять

Описание сервисов

🔹 API Gateway 🚪

Что это?
API Gateway — это точка входа для всех запросов от пользователей и внешних систем. Он управляет маршрутизацией, авторизацией и безопасностью.

Почему используется?
✅ Централизованный контроль доступа.
✅ Балансировка нагрузки.
✅ Безопасность и управление API.

Пример работы:
👤 Пользователь отправляет запрос → API Gateway проверяет авторизацию → перенаправляет запрос в нужный микросервис.

🔹 Auth Service (Сервис авторизации) 🔑

Что это?
Проверяет права пользователя и определяет, можно ли ему выполнять определённые действия.

Почему используется?
✅ Обеспечивает безопасность.
✅ Поддерживает аутентификацию по JWT или OAuth.

Пример работы:
👤 API Gateway отправляет запрос в Auth Service → Auth Service проверяет токен → возвращает результат (успешно / ошибка 401).

🔹 Transaction Service (Сервис транзакций) 💰

Что это?
Отвечает за выполнение и обработку банковских операций (переводы, платежи, пополнение счета).

Почему используется?
✅ Гарантирует выполнение транзакций (ACID).
✅ Логирует операции для аудита.

Пример работы:
📨 API Gateway отправляет платежный запрос → Transaction Service проверяет баланс → записывает в базу → отправляет события в Kafka и RabbitMQ.

🔹 RabbitMQ (Очередь сообщений) 📩

Что это?
Обрабатывает асинхронные события и уведомления пользователей.

Почему используется?
✅ Гарантия доставки сообщений.

Пример работы:
🔁 Transaction Service отправляет уведомление → RabbitMQ передает его Notification Service → пользователь получает SMS/email.

🔹 Notification Service (Сервис уведомлений) 📢

Что это?
Отправляет пользователям сообщения о выполненных операциях.

Почему используется?
✅ Разгружает Transaction Service.
✅ Позволяет легко менять механизмы уведомлений (SMS, email, push).

Пример работы:
🔁 Notification Service получает сообщение от RabbitMQ → отправляет SMS/email пользователю.

🔹 Kafka (Платформа потоковой обработки) 🔄

Что это?
Используется для передачи данных в систему аналитики и логирования.

Почему используется?
✅ Поддерживает обработку большого количества событий.
✅ Устойчив к сбоям, благодаря репликации.

Пример работы:
🔁 Transaction Service отправляет данные о транзакции в Kafka → Kibana использует эти данные для визуализации логов.

🔹 Kibana (Мониторинг) 📊

Что это?
Система визуализации логов и аналитики.

Почему используется?
✅ Показывает графики и дашборды в реальном времени.
✅ Позволяет анализировать ошибки.

Пример работы:
📊 Kibana получает данные из Kafka → отображает их на дашборде.

🔹 PostgreSQL (Реляционная база данных) 🗄

Что это?
Основное хранилище данных о пользователях, счетах и транзакциях.

Почему используется?
✅ Поддерживает сложные SQL-запросы.
✅ Гарантирует целостность данных (ACID).

Пример работы:
💾 Transaction Service сохраняет транзакцию в PostgreSQL → данные доступны для отчетов.

🔹 Redis (Кэш) ⚡

Что это?
Используется для кеширования данных и быстрого доступа.

Почему используется?
✅ Обеспечивает мгновенный доступ к часто запрашиваемым данным.
✅ Снижает нагрузку на PostgreSQL.

Пример работы:
🔄 Запрос баланса сначала ищет данные в Redis → если их нет, идёт в PostgreSQL.

💡 Различия между Kafka и RabbitMQ 🤔

💡 Когда использовать?
🔹 Kafka → если нужно обрабатывать много данных и событий.
🔹 RabbitMQ → если важна гарантированная доставка сообщений.

💡 Различия между Redis и PostgreSQL 🧐

💡 Когда использовать?
🔹 Redis → когда важна быстрая обработка данных.
🔹 PostgreSQL → когда важна целостность и надёжность данных.

Как это всё работает

1️⃣ Ты (пользователь) делаешь запрос (например, «Отправить деньги»).

2️⃣ Этот запрос попадает в API Gateway, который разбирается, куда его перенаправить.

3️⃣ API Gateway передаёт запрос в Auth Service, чтобы тот проверил:
🔹 «У тебя есть право делать переводы?»
✅ Если проверка пройдена, идём дальше.

4️⃣ Запрос на перевод летит в Transaction Service.

5️⃣ Transaction Service:
🔹 Сохраняет транзакцию в PostgreSQL (чтобы ничего не потерялось).
🔹 Отправляет уведомление в RabbitMQ (чтобы ты получил сообщение).
🔹 Шлёт данные в Kafka (для аналитики).
🔹 Обновляет Redis (кеширует данные, чтобы быстрее загружать баланс).

6️⃣ Notification Service читает уведомление из RabbitMQ и отправляет тебе на телефон или email сообщение, что «Деньги ушли туда-то».

7️⃣ Kafka передаёт данные в Kibana и внешние аналитические системы, чтобы можно было смотреть отчёты, графики и логи.

8️⃣ Kibana – это как приборная панель, показывает всё, что происходит в твоём «цифровом банке», где и что логируется, были ли ошибки и т.д. 🚀

Примеры позитивных сценариев

1. Проверка платежной транзакции

Цель: Проверить, что деньги списываются, записываются в базу, отправляется уведомление, а также что логи корректно отображаются в Kibana.

🔹 Шаги тестирования:

1. Отправить запрос на перевод через Postman
2. Проверить, что транзакция записалась в PostgreSQL
• Данные должны быть внесены в таблицу
3. Проверить, что уведомление отправлено в RabbitMQ:
• Открыть RabbitMQ Management UI
• Убедиться, что сообщение попало в очередь уведомлений.
4. Проверить, что Kafka получила событие:
• Подключиться к Kafka UI
• Найти сообщение о переводе.
5. Проверить логи в Kibana:
• Открыть Kibana
• Перейти в Discover и найти запись по transaction_id.
• Убедиться, что ошибок нет, лог содержит нужные поля (user_id, amount, status).
6. Проверить, что пользователь получил SMS/email

✅ Ожидаемый результат:

• Транзакция успешно проведена.
• Уведомление отправлено.
• В Kibana лог с правильными параметрами.

2. Проверка получения баланса

Цель: Убедиться, что данные кешируются в Redis, а при сбое Redis данные берутся из PostgreSQL.

🔹 Шаги тестирования:

1. Запросить баланс пользователя через API Gateway
2. Проверить, что данные загружены из Redis
• Баланс должен быть в Redis.
3. Удалить кеш (как удалить, сможешь узнать по инструкциям на проекте) и проверить повторный запрос
• Данные теперь должны быть загружены из PostgreSQL.
4. Проверить логи в Kibana:
• Найти запись в Kibana → Discover по request_id.
• Убедиться, что первый запрос получил данные из Redis, второй – из PostgreSQL.

✅ Ожидаемый результат:

• Данные сначала приходят из Redis.
• После удаления кеша – загружаются из PostgreSQL.
• В Kibana логируется источник данных.

Примеры негативных сценариев

1. Ошибка авторизации (Auth Service)

Сценарий:

• Пользователь отправляет запрос с неверным токеном или вообще без токена.
• Допустим, пытается сделать перевод без указания или с просроченным токеном в заголовке.

Что должно произойти?

• API Gateway перенаправляет запрос в Auth Service.
• Auth Service не подтверждает права доступа.
• Пользователь получает ошибку (например, 401 Unauthorized или 403 Forbidden).

Как искать и диагностировать ошибку?

1. Postman:
• Отправить запрос без токена или с поддельным токеном.
• Проверить HTTP-ответ (должен быть 401 или 403).
2. Kibana:
• В разделе Discover отфильтровать логи по дате/ID запроса.
• Посмотреть, что сервис Auth Service вернул ошибку авторизации.
• Убедиться, что Gateway получил запрос и действительно отдал его на Auth Service, а не «потерял» где-то.

2. Недостаточно средств на счёте (Transaction Service)

Сценарий:

• Пользователь пытается перевести сумму, которая превышает баланс счёта.

Что должно произойти?

• Transaction Service при обработке обнаружит, что баланс меньше требуемой суммы.
• Операция должна быть отклонена.
• Пользователь получает ошибку (например, 400 Bad Request с сообщением "Insufficient Funds").

Как искать и диагностировать ошибку?

1. Postman:
• Отправить запрос с суммой больше, чем доступный баланс.
• Убедиться, что сервис вернул корректный код ошибки (400 или 422) и понятное сообщение.
2. PostgreSQL (DBeaver):
• Проверить, что транзакция не появилась в таблице transactions или имеет статус FAILED.
3. Kibana:
• Найти лог по transaction_id и убедиться, что там есть запись об ошибке «Insufficient funds».

3. Некорректные данные запроса (API Gateway / Transaction Service)

Сценарий:

• Отправить запрос с неправильным форматом JSON, отсутствием обязательных полей (например, не указать amount или to_account), или с некорректным типом (вместо числа передать строку).

Что должно произойти?

• API Gateway может отклонить запрос из-за невалидного тела (400 Bad Request).
• Если прошёл до Transaction Service – тот должен вернуть ошибку при парсинге / валидации данных.

Как искать и диагностировать ошибку?

1. Postman:
• Отправить специально искажённый JSON.
• Проверить код ошибки (400 Bad Request или 422 Unprocessable Entity).
2. Kibana:
• Поиск по request_id или transaction_id.
• Увидеть лог о «JSON parse error» или «Validation error».
• Может оказаться, что API Gateway не пропустил запрос — смотрим его логи.

🛠 Что важно проверять

✅ RabbitMQ → Сообщения не теряются в очереди.
✅ Kafka → События корректно попадают в аналитику и Kibana.
✅ PostgreSQL → Данные правильно сохраняются и не теряются.
✅ Redis → Кеш работает и обновляется при изменениях.
✅ Kibana → Логи логируются корректно, их можно просматривать и анализировать.

📌 Правильность запросов и ответов: отправил запрос на перевод → получил корректный результат.
📌 Безопасность: никто не может украсть данные или перевести деньги без разрешения (Auth Service).
📌 Целостность данных: все транзакции верно записываются в PostgreSQL.
📌 Уведомления: проверяешь, как работает RabbitMQ и Notification Service → приходит ли пользователю сообщение?
📌 Аналитика и логи: Kafka всё ли записывает? Kibana всё ли отображает?
📌 Кеш: Redis действительно ускоряет ответ? А если кеш упадёт, система продолжит работать через PostgreSQL?

🔥 Главная задача тестировщика — убедиться, что система работает стабильно, данные не теряются, а ошибки легко отслеживаются! 🚀

1. Restful-Booker – приложение

Что это?

Это ваше приложение, которое отвечает на HTTP-запросы. Например:

• Если кто-то отправляет запрос GET /booking, приложение отвечает 200 OK и возвращает “Booking details”.

Что происходит?

• Приложение пишет свои логи в консоль (stdout) – это сообщения о запросах, их статусах и ответах.

Пример лога:

GET /booking 200 4.017 ms - 162

2. Filebeat – сборщик логов

Что это?

Filebeat – это инструмент, который читает логи из приложения (Restful-Booker) и отправляет их в Elasticsearch.

Что происходит?

• Filebeat “смотрит” в файлы Docker-логов (например, /var/lib/docker/containers/*/*.log).

• Он находит логи приложения Restful-Booker и отправляет их в Elasticsearch.

Пример того, что отправляет Filebeat:

{
"message": "GET /booking 200 4.017 ms - 162",
"container.name": "restful-booker",
"log.level": "info",
"timestamp": "2024-12-17T13:56:57.361Z"
}

3. Elasticsearch – хранилище данных

Что это?

Elasticsearch – это база данных, которая умеет быстро искать и обрабатывать текстовые данные (логи).

Что происходит?

• Filebeat отправляет логи в Elasticsearch.

• Elasticsearch сохраняет логи в виде индексов (например, filebeat-2024.12.17).

• Теперь можно искать по этим логам: по запросам, статусам, времени и т.д.

4. Kibana – визуализация данных

Что это?

Kibana – это инструмент для визуализации данных из Elasticsearch.

Что происходит?

• Kibana подключается к Elasticsearch и “видит” все сохранённые логи.

• Вы создаёте Data View (например, для индексов filebeat-*).

• В разделе Discover вы можете искать и фильтровать логи.

Пример поиска в Kibana:

• Найти все запросы с /booking.

• Найти ошибки (status: 500).

Как всё работает вместе?

1. Restful-Booker:

Приложение принимает HTTP-запросы и пишет логи.

2. Filebeat:

Читает логи из контейнера Restful-Booker и отправляет их в Elasticsearch.

3. Elasticsearch:

Сохраняет логи и позволяет быстро искать их.

4. Kibana:

Подключается к Elasticsearch и показывает логи в удобном виде. Вы можете искать, фильтровать и анализировать данные.

Пример потока данных

1. Кто-то отправляет запрос:

GET /booking

2. Restful-Booker пишет лог:

GET /booking 200 4.017 ms - 162

3. Filebeat собирает этот лог и отправляет в Elasticsearch.

4. Elasticsearch сохраняет лог в индекс filebeat-2024.12.17.

5. В Kibana → Discover вы видите:

message: "GET /booking 200 4.017 ms - 162"

Привет!

Меня зовут Даниил, мне 34 года, работаю на позиции Senior Automation QA Engineer.

Обучаю и устраиваю тестировщиков как с полного нуля, так и с опытом. К каждому ученику — индивидуальный подход.

Полный цикл обучения выглядит так*:

1. Знакомство. Обсуждаем на бесплатной консультации твои скиллы и цели. Около 30 минут.
2. Подготовка и приглашение в личное рабочее пространство. Подготолвю для тебя рабочее пространство, которое используется на рекльных проектах в компаниях. Расскажу как им пользоваться.
3. Процесс обучения и проверка знаний. Будем созваниваться каждую неделю, примерно по 1 часу, для корректировки процесса обучения при необходимости и для проверки знаний.
4. Резюме и собеседования. Создадим с тобой легенду и резюме. Опишем подробно твои достижения, скилы и легенду о твоей прошлой работе. Так же проведем торги по повышению оклада, после получения оффера.
5. Сопровождение. Далее в течении 2-3 месяцев буду помогать внедряться в компанию и правильно работать.

*на всех этапах буду помогать по всем возникающим вопросам.