🛠 Postman для тестировщиков: основы и автоматизация

Postman — это удобный инструмент для работы с API, который позволяет тестировщикам 📌 отправлять запросы, проверять ответы, автоматизировать тестирование и интегрировать проверки в CI/CD. Он поддерживает REST, SOAP, GraphQL, работает на всех ОС и позволяет легко управлять переменными и окружениями.

🔍 Основные возможности
✅ Отправка запросов и анализ ответов
✅ Использование коллекций и переменных
✅ Автоматизация тестирования с Collection Runner
✅ Запуск тестов по расписанию ⏳
✅ Интеграция с CI/CD через Newman

📜 Создание тестов
Вкладка Tests позволяет автоматически проверять ответы сервера. Например, проверка статуса ответа:

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

Или проверка содержимого ответа:

pm.test("Response contains campaign name", function () {
    pm.expect(pm.response.text()).to.include("Campaign TEST");
});

🔄 Использование переменных
Переменные помогают передавать данные между запросами 🔗. Например, сохранить auth-токен для последующего использования:

var jsonData = pm.response.json();
pm.environment.set("authToken", jsonData.token);

Также можно передавать ID созданного объекта:

pm.environment.set("campaignID", jsonData.id);

Переменные бывают глобальные, окружения, локальные и из файлов (CSV, JSON) 📂.

🚀 Автоматизация с Collection Runner
📌 Можно запускать коллекции запросов в нужном порядке, задавать количество итераций и запускать тесты по расписанию.

🤖 ChatGPT vs DeepSeek: Битва AI-титанов для системных аналитиков

Сегодня разберем, какая нейросеть лучше справится с вашими задачами: OpenAI ChatGPT или китайский DeepSeek. Мы устроили им экзамен — от математики до философии.

🔍 Ключевые отличия моделей
1. DeepSeek-R1
- Локальное развертывание Ollama — полный контроль над данными.
- Фишки: Может «мыслить» на китайском (даже в русских ответах), но требует мощного железа (например, NVIDIA A100).
- Пример: Лучше справилась с неочевидными задачами (например, генетикой: дала ответ 12.5%, хотя правильный — 25%).

2. ChatGPT (4o и o1)
- Скорость: Быстрее генерирует ответы.
- Креатив: Сильнее в творческих заданиях (например, стихи про Тирекса).
- Ограничение: Только облачная версия.

🚀 Практические выводы для системных аналитиков
- Для работы с конфиденциальными данными выбирайте DeepSeek-R1 (локальный запуск через Ollama).
- Для быстрых ответов и креатива — ChatGPT 4o.
- Для анализа требований и документов обе модели справляются, но DeepSeek лучше сохраняет контекст.

💡 ТОП-3 примера из интервью
1. Математика:
- Вопрос: 2 + 2 * 2 = ?
- ChatGPT 4o: 6 (с пояснением).
- DeepSeek-R1: 6 (с юмором: «Если бы не правила, было бы 8»).

2. Химия:
- Вопрос: Константа гидролиза NH4NO2.
- ChatGPT o1: 3.9×10⁻² (близко к истине).
- DeepSeek-R1: 1.2×10⁻⁶ (правильный ответ — 1.23×10⁻⁶).

3. Креатив:
- Задание: Рассказ-утопия только на буквы Г, Р, К.
- ChatGPT o1: Мини-роман про экогород.
- DeepSeek-R1: «Город Радость. Граждане растили розы...» 🌹

📌 Итоги
- DeepSeek выигрывает в безопасности и кастомизации.
- ChatGPT — для скорости и творчества.
- Совет: Тестируйте обе модели на своих кейсах (например, парсинг требований или генерация документации).

#AI

📌 Куда развиваться системному аналитику?

💡 Системный аналитик — универсальный специалист, который объединяет бизнес, разработку и тестирование. Со временем возникает вопрос: куда двигаться дальше? Разбираем три возможных пути!

🛠 1. Технический путь — архитектор (Solution Architect)
Если хочется погрузиться глубже в технологии, можно развиваться в сторону Solution Architect. Это человек, который проектирует систему на высоком уровне: рисует схемы компонентов, отвечает за их взаимодействие и принимает решения по архитектуре.

🔹 Какие навыки нужны?
✅ Понимание архитектурных паттернов
✅ Глубокие знания API, баз данных и интеграций
✅ Умение видеть систему в масштабе
✅ Навыки коммуникации с разработчиками и заказчиками

🔹 Как развиваться?
📌 Больше взаимодействовать с архитекторами
📌 Изучать REST, SOAP, GraphQL, брокеры сообщений
📌 Разбираться в микросервисах и серверless-архитектуре

📌 Подходит, если: хочется больше работать с технической стороной проектов и видеть систему целиком.

👔 2. Управленческий путь — Product Owner или Project Manager
Если нравится управлять процессами, можно перейти в PO/PM и взять на себя стратегическое развитие продукта.

🔹 Какие навыки нужны?
✅ Управление изменениями и рисками
✅ Планирование и бюджетирование
✅ Развитие продукта и продажа идей

🔹 Как развиваться?
📌 Освоить Agile/Scrum/Kanban
📌 Погрузиться в UX/UI
📌 Учиться презентовать идеи и решать бизнес-задачи

📌 Подходит, если: хочется развивать продукт и влиять на бизнес-решения.

👥 3. Лидерство — Head of Analytics / Team Lead
Если нравится работать с людьми, можно стать тимлидом и выстраивать процессы в команде аналитиков.

🔹 Какие навыки нужны?
✅ Наставничество и развитие коллег
✅ Управление документацией и процессами
✅ Делегирование задач и распределение ответственности

🔹 Как развиваться?
📌 Наставничать и обучать новичков
📌 Оптимизировать процессы в команде
📌 Учиться мотивировать и работать с командной динамикой

📌 Подходит, если: хочется выстраивать работу аналитиков и развивать команду.

💡 Что важно прокачивать всегда?
📌 Структурированное мышление — диаграммы, схемы, таблицы
📌 Глубокое понимание предметной области
📌 Навыки коммуникации внутри команды и с заказчиком

🎯 Выбирай свой путь и развивайся! В каком направлении ты видишь себя? Делись в комментариях! 💬

#OTHER

помочь кому-то?😉

🔗 Оптимизация JOIN в PostgreSQL: ускоряем сложные запросы

При работе с большими объемами данных в PostgreSQL важно понимать, как выполняются JOIN и как их оптимизировать. Неправильный выбор метода соединения может значительно замедлить запросы. Разбираем, какие бывают JOIN, как их выбирает PostgreSQL и что можно улучшить.

🛠 Виды JOIN и их особенности

🔹 Nested Loop Join – выполняется построчно, хорошо работает на маленьких таблицах с индексами, но неэффективен на больших.
🔹 Hash Join – строит хеш-таблицу, удобен, когда нет индексов, но потребляет много памяти.
🔹 Merge Join – использует отсортированные данные, эффективен, если сортировка уже есть.

📌 Как PostgreSQL выбирает метод JOIN?

1️⃣ Анализирует статистику таблиц (ANALYZE).
2️⃣ Рассчитывает стоимость выполнения (cost).
3️⃣ Выбирает наименее затратный метод.

Можно отключить ненужные JOIN, но это не всегда ускорит запросы:

SET enable_nestloop TO off;
SET enable_hashjoin TO off;
SET enable_mergejoin TO off;

В некоторых случаях Nested Loop останется единственным доступным вариантом.

⚡️ Оптимизация JOIN в PostgreSQL

✔️ Настройка `work_mem`
- Если запросы используют диск (spilled to disk) → увеличьте work_mem.
- Не задавайте `work_mem` слишком большим – это может привести к нехватке RAM.
- Пример:

  SET work_mem = '256MB';
  

✔️ Настройка `random_page_cost`
- Для HDD (по умолчанию): random_page_cost = 4.0
- Для SSD: random_page_cost = 1.1 – 1.5
- Для NVMe: random_page_cost = 1.0 – 1.1

Пример настройки:

  SET random_page_cost = 1.1;
  

✔️ Использование индексов
- Ускоряют Nested Loop и Merge Join.
- Пример создания индекса:

  CREATE INDEX idx_customer_id ON orders(customer_id);
  

✔️ Обновление статистики и очистка таблиц
- `ANALYZE` – обновляет статистику, помогает планировщику выбрать лучший JOIN.
- `VACUUM` – удаляет ненужные строки, предотвращает разрастание таблицы.

  VACUUM ANALYZE orders;
  

✔️ Разбиение таблиц (`Partitioning`)
- Снижает объем данных для обработки.
- Поддерживается range, list и hash partitioning.

  CREATE TABLE orders_2024 PARTITION OF orders
  FOR VALUES FROM ('2024-01-01') TO ('2024-12-31');
  

✔️ Использование EXPLAIN ANALYZE
- Позволяет выявить Seq Scan и неоптимальные планы выполнения.

  EXPLAIN ANALYZE SELECT * FROM orders JOIN customers USING(customer_id);
  

✅ Чек-лист по оптимизации JOIN

🔲 Проверить индексы на ключах соединения.
🔲 Запустить ANALYZE и VACUUM для актуализации статистики.
🔲 Использовать EXPLAIN ANALYZE для анализа запросов.
🔲 Оптимизировать work_mem для ускорения Hash Join.
🔲 Настроить random_page_cost в зависимости от типа диска.
🔲 Использовать разбиение (Partitioning) на больших таблицах.

#DBMS 🗄

📌 Deployment vs StatefulSet: в чем разница?

В Kubernetes есть два основных способа управления развертыванием приложений — Deployment и StatefulSet. Оба объекта управляют подами, но предназначены для разных типов приложений. Разбираемся, когда использовать каждый из них.

🏗 Deployment — для stateless-приложений
✔️ Не сохраняет состояние — при удалении пода данные теряются.
✔️ Использует стратегию Rolling Update — обновление версии без простоя.
✔️ Динамические поды — новые поды могут получать другие IP-адреса.
✔️ Подходит для веб-серверов, API-сервисов и других stateless-приложений.

💾 StatefulSet — для stateful-приложений
✔️ Сохраняет состояние — поддерживает Persistent Volumes для хранения данных.
✔️ Фиксированные имена и IP — поды получают уникальные и постоянные идентификаторы.
✔️ Последовательный запуск и остановка — один за другим, без хаоса.
✔️ Используется для баз данных, кешей и других приложений, требующих постоянного хранения данных.

🔍 Как выбрать?
✅ Если ваше приложение не требует хранения состояния — используйте Deployment.
✅ Если вашему приложению нужна сохранность данных — выбирайте StatefulSet.

#ARCHITECTURE

Ничего личного...😂

🚀 Ingress в Kubernetes: Маршрутизация трафика для системных аналитиков
_Кратко и понятно о том, как управлять внешними запросами в кластере_

Что такое Ingress?
Ingress — это набор правил, которые говорят Kubernetes, куда и как направлять внешний трафик (HTTP/HTTPS) внутрь кластера. Это как GPS для ваших запросов:
- Роутит по доменам: app.example.com → сервис frontend.
- Управляет SSL: Подключает TLS-сертификаты для безопасного соединения.
- Балансирует нагрузку: Распределяет запросы между подами.

👉 Проще говоря: Ingress — это инструкция: «Запросы на /api отправляй в backend, а на / — в frontend».

Что такое Ingress-контроллер?
Ingress-контроллер — это «исполнитель» правил Ingress. Без него правила — просто текст. Контроллер состоит из:
1. Обратного прокси (Nginx, Traefik и др.) — обрабатывает запросы.
2. Контроллера — следит за изменениями в Ingress через API Kubernetes.

🔧 Популярные контроллеры:
- Nginx Ingress — гибкий, с кучей аннотаций.
- Traefik — автоматически обновляет SSL-сертификаты.
- HAProxy — для высоких нагрузок.

Как это работает?
1. Пользователь заходит на shop.example.com.
2. Ingress-контроллер проверяет правила:
- /orders → сервис orders-service.
- /products → сервис catalog-service.
3. Трафик попадает в нужный сервис.

Пример манифеста Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
    - hosts:
        - shop.example.com
      secretName: shop-tls
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /orders
            backend:
              service:
                name: orders-service
                port: 80
          - path: /products
            backend:
              service:
                name: catalog-service
                port: 80

Зачем это нужно?
- Одна точка входа для всего трафика.
- Легко менять маршруты без перезапуска сервисов.
- Безопасность: Централизованное управление SSL.

💡 Лайфхак: Всегда проверяйте, работает ли Ingress-контроллер:

kubectl get pods -n ingress-nginx

#SYSTEMDESIGN

Всем хорошего дня😉

🚀 Метки (Labels) и селекторы (Selectors) в Kubernetes: Как управлять объектами
_Простыми словами о ключевом инструменте организации в кластере_

Что такое метки (Labels)?
Метки — это пары «ключ-значение», которые добавляются к объектам Kubernetes (подам, сервисам и т.д.) для их идентификации и группировки. Например:
- env: prod — окружение (продакшн).
- app: frontend — название приложения.
- tier: cache — уровень приложения (кэш).

👉 Проще говоря: Метки — это «стикеры», которые помогают быстро находить и фильтровать объекты.

---

Что такое селекторы (Selectors)?
Селекторы — это запросы, которые фильтруют объекты по их меткам. Например:
- Найти все поды с меткой env=prod.
- Исключить сервисы с app=legacy.

👉 Проще: Селекторы — это «поисковый запрос» по вашим стикерам-меткам.

### Примеры использования
1. Группировка подов:

   metadata:
     labels:
       app: frontend
       env: staging
   

2. Фильтрация через kubectl:

   # Все поды в продакшне
   kubectl get pods -l env=prod

   # Сервисы, кроме бэкенда
   kubectl get services -l app!=backend
   

3. Связь сервисов с подами:
В манифесте сервиса селектор указывает, к каким подам направлять трафик:

   spec:
     selector:
       app: frontend
       env: prod
   

Операторы в селекторах
- Равенство: env=prod, app=frontend.
- Неравенство: tier!=cache.
- Вхождение в список: env in (prod, staging).
- Исключение: env notin (test).

#SYSTEMDESIGN

🚀 Почему Redis такой быстрый, если он однопоточный? Разбираемся!

Redis — это легенда среди баз данных, способная обрабатывать 100 000+ запросов в секунду даже на одном потоке. Но как это возможно? Давайте разложим всё по полочкам!

🔥 4 главные причины скорости Redis

1. Данные в оперативной памяти (RAM)
Redis хранит всё в памяти, а не на диске. Доступ к RAM в 100 000 раз быстрее, чем к HDD/SSD.
→ *Пример:* Чтение данных за 100 наносекунд (RAM) vs 10 миллисекунд (SSD).

2. Мультиплексирование ввода-вывода
Redis использует механизмы вроде epoll (Linux) или kqueue (macOS), чтобы один поток мог управлять тысячами подключений.
→ *Как?* Поток отслеживает сокеты и обрабатывает только активные запросы.

3. Оптимизированные структуры данных
Строки, хэши, списки, множества — все они работают за O(1) благодаря хеш-таблицам.
→ *Кейс:* Хэш-таблицы позволяют найти ключ за константное время.

4. Преимущества однопоточности
- Нет переключений контекста между потоками.
- Нет блокировок (все команды атомарны).
- Проще отладка (никаких гонок данных).

⚡️ А как же многопоточность?
Redis не полностью однопоточный! Некоторые задачи выполняются в фоне:
- Асинхронное освобождение памяти (с Redis 4.0+).
- Многопоточный анализ протокола (с Redis 6.0+).

Но основная обработка запросов — всё ещё один поток. Это сохраняет простоту и эффективность.

⚠️ Ограничения однопоточности
- Долгие команды блокируют сервер (например, KEYS * на миллионах ключей).
- Узкие места: пропускная способность сети и объем памяти.
- Блокирующие команды (например, BLPOP) могут затормозить весь трафик.

Решение: избегайте «тяжелых» операций и используйте кластер Redis для масштабирования.

🚀 Как масштабировать Redis?
- Кластеризация: запустите несколько экземпляров Redis.
- Режим Sentinel: для отказоустойчивости.
- Шардирование данных между узлами.

#SYSTEMDESIGN

Как пустой S3-бакет может привести к неожиданным расходам: важные уроки по безопасности AWS S3

Ключевая проблема
Пользователь AWS создал приватный S3-бакет для тестирования. Через два дня был обнаружен счет на $1300, вызванный 100 миллионами PUT-запросов за 24 часа. Анализ показал, что запросы поступали от сторонних систем, использовавших имя бакета по умолчанию из популярного опенсорсного инструмента.

Причины расходов
1. Тарификация AWS S3:
- Плата взимается за все запросы, включая неавторизованные (ошибки 4xx).
- Стоимость: $0.005 за 1000 PUT-запросов.
- Запросы без указания региона автоматически направляются в us-east-1, что увеличивает расходы.

2. Риск утечки данных:
- При открытии бакета для публичной записи в него было загружено 10 ГБ данных от сторонних систем, включая конфиденциальную информацию.

Рекомендации по обеспечению безопасности
1. Именование бакетов:
- Используйте уникальные имена с добавлением случайных суффиксов.
- Избегайте распространенных названий (например, backup, data).

2. Настройка доступа:
- Запретите публичную запись через Bucket Policy.
- Регулярно проверяйте IAM-политики и права доступа.

3. Мониторинг:
- Включите логирование через AWS CloudTrail и S3 Server Access Logging.
- Настройте оповещения о нестандартной активности.

4. Региональные настройки:
- Всегда указывайте регион явно в запросах (CLI/SDK).

Ключевой вывод
Любое лицо, знающее имя вашего S3-бакета, может инициировать запросы, приводящие к незапланированным расходам. Единственный способ полностью исключить риск — удалить неиспользуемые бакеты.

Примечание: В описанном случае AWS аннулировал счет как исключение, однако такая практика не гарантирована. Рекомендуется регулярно аудитить настройки S3 и соблюдать лучшие практики безопасности.

#SECURITY

🔥 Список вопросов с реального собеседования на системного аналитика

Недавно удалось ознакомиться с вопросами, которые задавали на собеседовании кандидату на позицию системного аналитика уровня Middle (зарплата ~250 тыс. руб.). Компания крупная и известная на рынке. Делимся списком, который поможет понять, насколько вы готовы к таким техническим интервью:

📌 Раздел «Требования»:
- Какие виды нефункциональных требований вы знаете?
- Как именно вы обычно собираете требования с заказчиками?
- Был ли у вас опыт, когда приходилось менять требования непосредственно во время их презентации команде? Как вы поступали?
- Какие обязательные разделы должны входить в документ «Архитектура решения»?
- Какие виды диаграмм или схем вы обычно используете при описании архитектуры решения?
- В каких инструментах и нотациях предпочитаете работать при создании схем?
- Чем принципиально отличаются User Story и Use Case?

Отдельно рекомендуем быть готовым рассказать о стандартной структуре технического задания (ТЗ), которое вы привыкли готовить.

✅ Эти вопросы помогут заранее подготовиться и успешно пройти собеседование!

#REQUIREMENTS