⏰ CRON в GitHub Actions — просто и понятно
Всем привет! 👋

Чуть ранее я сделал пост на тему настройки workflow для запуска по расписанию.
Расписание настраивается в формате * * * * * - это называется POSIX cron-синтаксис
Пять настраиваемых значений.
Для многих кто сталкивается с данным форматом впервые не совсем понятно, что эти звездочки настраивают.

Поэтому решил сделать данный пост.

Когда в workflow ты видишь:

on:
  schedule:
    - cron: '0 3 * * *'

👉 это триггер запуска по расписанию, какие еще есть я расскажу в одном из следующих постов.
В данном случае данное расписание запускает workflow в 03:00 по UTC.

GitHub всегда считает время по UTC — таймзону задать нельзя.

🧩 Формат cron:

┌───────────── минута (0 - 59)
│ ┌───────────── час (0 - 23)
│ │ ┌───────────── день месяца (1 - 31)
│ │ │ ┌───────────── месяц (1 - 12 или JAN-DEC)
│ │ │ │ ┌───────────── день недели (0 - 6 или SUN-SAT)
│ │ │ │ │
* * * * *

💡 Пример:
cron: '15 4,5 * * *' → запустит workflow в 04:15 и 05:15 по UTC каждый день.
В данном примере я добавил ещё оператор во втором параметре - ,

⚙️ Какие есть операторы:

| Символ | Значение       | Пример                                            |
| :----- | :------------- | :------------------------------------------------ |
| `*`    | любое значение | `15 * * * *` — каждые часы в 15 минут             |
| `,`    | список         | `2,10 4,5 * * *` — 04:02, 04:10, 05:02, 05:10     |
| `-`    | диапазон       | `30 4-6 * * *` — 04:30, 05:30, 06:30              |
| `/`    | шаг            | `20/15 * * * *` — каждые 15 минут, начиная с 20-й |

🧠 Важно знать:

🕓 Cron всегда по UTC.
⏱️ Минимальный интервал — раз в 5 минут.
💤 Репозиторий без активности 60 дней — cron отключается.
⚠️ GitHub может задержать запуск при высокой нагрузке (особенно в начале каждого часа).

💡 Совет: не ставь 0 * * * *.
Выбирай, например, 7 * * * * или 3 4 * * *, чтобы избежать очередей.


📅 Примеры расписаний:

| Cron           | Что делает                          |
| -------------- | ----------------------------------- |
| `0 3 * * *`    | каждый день в 03:00 UTC             |
| `30 6 * * 1-5` | по будням в 06:30 UTC               |
| `*/10 * * * *` | каждые 10 минут                     |
| `0 0 1 * *`    | в полночь 1-го числа каждого месяца |

🔗 Быстро настроить и проверить формат можно здесь:
👉 crontab.guru

Он покажет, когда именно сработает твой cron 😎
Ставь реакцию 🔥, если было полезно

🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

🔥 Куда я пропал на 2 недели, и причём тут 70 VU?

Привет! 👋
Если вы заметили, что блог притих, - это не лень, а полное погружение в боевые задачи. Последние две недели я с головой ушёл в новую, захватывающую тему: Нагрузочное тестирование.
Это был невероятный челлендж!
Когда прилетает такая задача, интерес перевешивает всё, и ты не замечаешь, как после рабочего дня продолжаешь разбираться.

Неделя 1️⃣: Постановка задачи. Борьба за информацию и базовый анализ

Цель: в преддверии акции 11.11 необходимо было проверить как складская система(WMS) будет справляться с повышенной нагрузкой. Предполагалась что количество заказов будет выше почти в два раза чем в обычные дни.

Здесь надо было нагрузить наш основной процесс, чтобы понять будет ли деградация и на сколько будут расти задержки. Тут же, конечно, столкнулись с двумя ключевыми проблемами:
1. Не так давно был изменен один из этапов процесса и мы его не успели ещё автоматизировать. Процесс не простой и с "пол пинка" не автоматизируешь.
2. Вторая проблема это генерация "живых" заказов. Так как у нас нет отдельного стенда под нагрузку, грузить надо было на тестовом стенде, где обычно проводим регресс. Максимально близок по своему состоянию к продакшну. Со всеми интеграциями. Поэтому просто лить синтетику было нельзя, так как почти на каждом шаге данные синхронизируются с различными системами. И мы просто на первом же шаге упадем с ошибкой.

В итоге мы решили пока нагрузить хотя бы GET-запросы, чтобы понять, где система может "споткнутся" во время чтения данных, обращения к БД.

Я сделал 4 сценария:
- Базовый - имитирующий стандартный рабочий день. Продолжительность 60 минут.
- Пиковый - установил значения ожидаемой пиковой нагрузки +10% сверху. Продолжительность 60 минут.
- Стресс - короткий на 20 минут тест с резким повышением нагрузки, +30% к пику.
- Продолжительный(Soak) - 6 часовой тест с базовой нагрузкой.


Инсайт 1: Ценность простого теста.
Мы увидели, что WMS в целом хорошо справляется с нагрузкой в ключевых точках. И при тестировании не наблюдалось деградации. Плюс смогли понять средний RPS нашей системы. Так же были единичные всплески задержек ряда запросов, которые достигали местами 6 секунд. Причины не ясны. Зафиксировали - будем наблюдать.

Инсайт 2: Прозрачность критериев
Какие метрики брать и какие значения использовать для критериев приемки? Пожалуй это самая сложная часть нагрузочного тестирования. Далеко не всегда в документации прописаны метрики, например, самый важный в нашем случае RPS(Requests Per Second) - запросов в секунду. Пришлось для первого раза брать значение "на глаз" и с текущих метрик с прода.

Главный вывод: составлять и уточнять метрики и их значения заранее. Уделить этому самое сильное внимание.

Нагрузку провел на выходных 2.11. В понедельник выложил интерпретацию результатов в конфлюенс.
Думал на этом пока всё. И после акции продолжим работы.
Но...

Продолжение будет в другом посте.

🔥 Помните времена, когда от тестировщика ждали только ручное тестирование?
Когда знание языка программирования было «приятным бонусом», который выделял тебя среди десятков резюме?

Сейчас всё поменялось.

Автоматизация стала не «хорошо бы знать», а фактически обязательным навыком.
Стоит открыть вакансии - и в каждой второй, если не чаще, нужно знать какой-то язык программирования, понимать какой-то фреймворк.
А строчка «будет плюсом» внезапно превратилась в полку: нагрузка, безопасность, CI/CD — и так далее по списку.

И вот что интересно.
Раньше вакансии «ручное + авто + нагрузка» встречались раз в год.
Сегодня - это чуть ли не норма.
Компании хотят универсалов, которые способны закрывать сразу несколько задач.
Для бизнеса это экономия. Для тестировщика - вызов.

И парадокс времени в том, что рынок под давлением:
💸 зарплаты почти не растут (что не скажешь о инфляции)
⚙️ требований - всё больше
📉 компании экономят на штате, но не на ожиданиях

Конкурентов на одну вакансию очень много. Выигрывают те, кто умеет больше.
Универсалы находят работу быстрее и увереннее держатся в переговорах.
А такой навык, как нагрузочное тестирование, всё чаще становится тем самым «плюсом», который помогает пройти отбор и удержать хорошие условия.

QA давно перестал быть "простым кликером по кнопочкам". Если его кто-то таким считал.
Сегодня это инженер, который понимает архитектуру, работает с метриками, видит слабые места системы и помогает бизнесу пережить реальные пиковые нагрузки.

К чему я вообще это всё рассказываю?
Сейчас я готовлю серию постов, роликов и небольшое обучение по проведению нагрузочного тестирования с помощью k6.

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

Если эта тема вам интересна - поддержите пожалуйста реакцией 🔥
Любого автора ваша поддержка очень мотивирует.

🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

🚀 Первый нагрузочный сценарий

Если вы успешно установили k6(качаем с гитхаб), давайте сделаем простенький базовый нагрузочный сценарий.

Перед тем как перейти к коду, создайте отдельный каталог, в котором будете хранить свои скрипты.
Откройте консоль — например, PowerShell — и перейдите в этот каталог.

Не переживайте, если вы не знаете JavaScript — мы не будем писать код с нуля. Я воспользуюсь специальной «песочницей» от Grafana - QuickPizza. В её GitHub‑репозитории лежит масса готовых шаблонов.

Для примера я возьму скрипт 01.basic.js и слегка скорректирую BASE_URL , чтобы он указывал на QuickPizza:

import http from "k6/http";
import { check, sleep } from "k6";

const BASE_URL = "https://quickpizza.grafana.com";

export const options = {
  vus: 5,
  duration: '5s',
};

export default function () {
  let restrictions = {
    maxCaloriesPerSlice: 500,
    mustBeVegetarian: false,
    excludedIngredients: ["pepperoni"],
    excludedTools: ["knife"],
    maxNumberOfToppings: 6,
    minNumberOfToppings: 2
  };

  let res = http.post(`${BASE_URL}/api/pizza`, JSON.stringify(restrictions), {
    headers: {
      "Content-Type": "application/json",
      "Authorization": "token abcdef0123456789",
    },
  });

  check(res, { "status is 200": (r) => r.status === 200 });
  console.log(`${res.json().pizza.name} (${res.json().pizza.ingredients.length} ingredients)`);
  sleep(1);
}

Далее сохраняем в созданном каталоге как basic.js или любое другое имя.
Затем в терминале(например PowerShell) выполняем команду:

k6 run basic.js

Начнется выполнение нагрузки.
По завершении которой прямо в терминале вам будет выведен отчет по метриках*.
*Как читать эти метрики мы поговорим в будущих постах и видео 🥸


📊 Что делает этот сценарий
В options указываются настройки нагрузки: 5 виртуальных пользователей, продолжительность 5 секунд.
Ну и функция в которой заложено выполнение простенького бизнес сценария:
Отправляется POST запрос с параметрами пиццы, которую мы хотим заказать.

- Каждый из 5 пользователей отправляет запрос на API QuickPizza параллельно друг-другу на протяжении 5 секунд.

- Скрипт проверяет, что сервер отвечает со статусом 200 OK.

- Выводит название и количество ингредиентов у сгенерированной пиццы.

И самое важное - собирает метрики: время отклика, процент ошибок, количество запросов в секунду.

🎯 Зачем это нужно
QuickPizza крайне простое приложение, поэтому и скрипт нагрузки тоже крайне простой, но уже полезный!
Что он нам показывает

- что API действительно работает под нагрузкой,

- что бизнес‑логика (ограничения на пиццу) учитывается,

- и как быстро сервис отвечает при одновременных запросах.

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

На этом пока всё! Пишите о ваших успехах в комментариях. Если, что-то не получилось тоже пишите!
И, конечно, если пост понравился и хочется продолжения - кидайте реакцию! 🔥

🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

Всем привет! 👋

В предыдущем посте мы с вами запустили простенький сценарий по нагрузочному тестированию.
У всех всё получилось? Пишите ваши результаты в комментариях!

🔍 Разбираем отчёт k6: что это вообще значит?

Ок, вы запустили базовый сценарий, получили красивый отчёт… и зависли. Я, например, в свое время точно завис.

Что означают все эти avg, p(95), iterations, vus?
Давайте разберёмся - без лишней теории, только практический смысл.

Отчет стартует со слов TOTAL RESULTS

✅ Checks - это как такие мини аналог ассертов, которые есть в Postman, и фреймворках автоматизации.
В нашем скрипте одна проверка - на status code 200.

checks_total: сколько всего проверок было за весь прогон.
checks_succeeded: сколько из них прошли успешно, то есть вернулся на наш запрос status code=200.
checks_failed: соответственно, сколько наших проверок провалилось.

✓ Подобные проверки дают нам понять насколько стабильно наша система работает под нагрузкой. Если с увеличением нагрузки checks_failed начинает тоже увеличиваться - вероятно у нас есть где-то проблемы.

🌐 HTTP - скорость и стабильность отклика

http_req_duration: время отклика сервера на наш запрос. Всем известно чем быстрей тем лучше! Никто не любит, когда после нажатия на кнопку приложение еще 10 секунд думает.
Здесь главное понимать, что тут по сути нет какого-то золотого стандарта.
Всё зависит от системы, от архитектуры, от операции, которые выполняются при вызове энд-поинта.
Пробежимся вкратце по сокращениям
avg - средняя температура по палате.
med - медиана, надежнее чем средняя, точнее устойчивее к "случайным" всплескам, которые могут быть.
p(90) / p(95) - процентили по времени отклика. Например, если указано как на скриншоте p(90)=2.69s, p(95)=2.69s, это означает, что 90% и 95% запросов были быстрее 2.69s.

http_req_failed: процент ошибок. → 0.00% — всё стабильно. это встроенная метрика, которая фиксирует любую неудачу при выполнении HTTP‑запроса. "Неудача" - это может быть таймаут, сетевая какая-нибудь ошибка, либо status code который не соответствует ожидаемому (по умолчанию k6 считает успешными 2хх и 3хх статус коды)

http_reqs: сколько всего запросов было отправлено во время нашего запуска. метрика показывает интенсивность нагрузки. То есть по этому показателю ты можешь понять корректно ли настроен твой сценарий. Если ты моделируешь работу 5 сотрудников, которые каждые 10 секунд проходят какой-то сценарий, то ты можешь высчитать сколько примерно запросов должно быть за время твоего теста. Если цифра сильно отличается, то значит надо корректировать либо vus, duration, либо саму логику сценария.

🔁 Execution — как отрабатывали VU

iterations: сколько всего итераций было выполнено.
iteration_duration: сколько длилась одна итерация. → Если итерации по 1.3 сек, а тест длился 5 сек — всё нормально, они шли параллельно: у нас 5 виртуальных пользователя, одна итерация в среднем 1,3 → то есть один пользователь за 5 секунд успевает выполнить (5/1.3=3.8) почти 4 итерации, всего у нас 5 VU, 5*4=20 - всё сходится.

vus_max = 5: сколько максимум виртуальных пользователей мы запускаем.
vus = 5: значит на протяжении всего теста всегда было ровно 5 активных VU. Никогда не было меньше, никогда не было больше. Что соответствует нашему сценарию. Если бы у нас был сценарий с нарастающей или переменной нагрузкой, где количество VU могло меняться в процессе теста, то значение было бы другим.

📡 Network - объём данных

data_received / data_sent: сколько данных было получено / передано. → Полезно понимать, если API гоняет большие payload'ы.

🎯 И это всё что нужно?

Это базовые метрики, которые уже идут по умолчанию из коробки k6.
Конечно, на практике используют дополнительные метрики, которые подбираются индивидуально под бизнес-логику и цели нагрузки.

Если было интересно и полезно - поддержи реакцией! 🔥

🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

Всем привет! 👋

Я тут решил запилить свой проект - EasyPost 🛠
Это планировщик постов для Telegram.

Почему? На самом деле как и с LMS системой решение пришло из моей боли.
Я редко пишу посты для телеграма сразу в телеграм. Чаще сначала в notion, или в каком-нибудь редакторе.
Выглядит примерно так:

Делаю красивый текст в Notion → копирую в Telegram → и... форматирование улетает в космос.

Приходиться текст прям тут форматировать заново.
Минус еще в том, что редактор приложения телеграм ограничен.
Через html(то есть через бота) возможностей больше.

Все кто ведет свой канал, как правило, если он небольшой(как у меня), то публикуют руками через телеграм, у кого побольше или несколько каналов, то используют сервис какой-то, либо своего бота.

В общем пошёл искать планировщик(честно сказать не особо запаривался поиском):
💲 платные (там реально круто, но мне не нужны половина фич, а платить $20/мес не хотелось)
🆓 бесплатные, но “1 канал / 1 бот / куча ограничений” 🖕
или просто кривенькие

Короче, подумал: “ладно, сделаю свой”.
Собственно и сделал. Предыдущий пост публиковал уже через свой планировщик.

Конечно, я хотел чтоб был нормальный редактор. Чтобы было так:
Делаю красивый текст в Notion → копирую в Telegram → И сразу публику - не парясь с форматированием.

И я ещё наивно думал, что редактор - это вообще не проблема: типа возьму готовое решение, прикручу и оно там само волшебство творить будет.
Ага, конечно 😂
Редактор оказался самой больной частью, и он до сих пор в стадии “полировки”: хочется много чего поправить.

И вот тут главный вопрос: а сколько багов я ещё просто не увидел? 👀

Поэтому зову вас потестировать stage ✅
Особенно если вы новичок в тестировании и вам нужна реальная практика на живом продукте - это прям оно.

📌 Вся инфа (ссылки, мини-дока, куда заводить баги) — здесь:
https://news.1rj.ru/str/testerschool/375/376

Я ещё запишу короткое демо-видео.
Если народу наберётся нормально - сделаем созвон и разберём самые интересные баги/наблюдения.

Если готовы - приходите, потыкайте, поломайте 🙌
И просто так тоже заходите посмотреть. Буду рад любому фидбэку.
Философия приложения - это максимум User Friendly, поэтому если вдруг что-то встречается непонятное обязательно пишите - мне это очень поможет.

UPD: Сам планировщик пока еще не продакшине, пока у меня он в тестировании на тестовом стенде
Надеюсь в две-три недели привести в божеский вид и уже опубликоваться.

🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman