Доброго дня друзі - як ви? як ваш день?
Ну шо ше пару годин і можно відпочівати)

Протоколи для QA - gRPC

Чесно? gRPC - це той випадок, коли REST вже не тягне по швидкості і навантаженню.
Це не просто ще один API-формат - це зовсім інший підхід.

Що я маю вам сказать сьогодні
gRPC протокол від Google поверх HTTP/2, який працює на Protobuf (бінарний формат), а не JSON.
Тому він швидший, легший і точніший.

Чому бекенди люблять gRPC?
Бо між мікросервісами треба ганяти величезну кількість даних без зайвого оверхеду.
Тому там де REST “задумується”, gRPC просто пролітає.

Виглядає API принцепі більше складніше ніж ви привикли бачити РЕСТ?

Тут не endpoint-и, а методи сервісу:

service UserService {
  rpc GetUser (UserRequest) returns (UserResponse);
}

Все строго типізовано.
Або підходить - або не проходить. Ніяких “а тут стрінга чи інт?”

Важливий момент для КУА для розуміня
- У gRPC є 4 режими викликів:
- звичайний request/response
- сервер стрімить багато відповідей
- клієнт стрімить запити
- двосторонній стрім (майже як WebSocket)

Для чого його реально юзають:
мікросервіси / high-load / фінтех/ігри/стрімінг / real-time системи, де час відповіді важливий

Тестувати теж в принцепі не складно
BloomRPC /grpcurl / Kreya / Postman (так, тепер теж вміє)

Приклад:

grpcurl -plaintext localhost:50051 list

Що ви маєте перевіряти?
- правильність схем (Proto)
- помилки/коди статусів (вони тут свої)
- performance (gRPC створений для цього)
- роботу стрімів (часто саме там і падає) то що

Ну вроді все - є що добавити то кажіть)

Всім гарно закінчення дня)
Обняв🤗

Доброго ранку, друзі!
Як ви? Як пройшли вихідні?

А у мене вихідні почався з міні-катастрофи(
Мій старий сервер, на якому ми роками ганяли SQL / NoSQL / Linux-лаби / демки - просто злетів.
Не впав, не завис - контора просто перестала його сапортити.

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

Але нічого - піднімемо нове.
І навіть краще. Уже думаю чи не пора зробити собі свій олдскульний домашній дата-центр на 3–4 ТБ, щоб більше ніхто не ламав мою КУА-лабораторію 😄

А тепер шо я хочу вам сказать)
Останнім часом у мене рекомендації просто кишать відео про мікрочіпи, кремнієві фабрики і виробництво. Мабуть я занадто захопився цією темою)

Але ви уявіть, який там рівень тестування.
Ці системи тестують не тільки виробництво, а й:

- пропускну здатність,
- деградацію матеріалів,
- напругу,
- температурні коливання,
- дефекти на рівні нанометрів.
І це ж теж КУА, просто на іншому рівні.
От реально круто же дорости до такого рівня інженерії.

Натрапив на статтю про те, як тестують напівпровідники. Дуже стисло, але технічно і по суті:
https://mptestequipment.com/blog/how-semiconductor-testing-works/

Подумав - може і вам буде цікаво. Бо QA - це не тільки UI/REST/кнопочки. Це цілий світ технологій.

Всім гарного дня і настрою. Обняв!
Сильні 💙

P.S. якщо маєте поради по стабільному сервісу для піднятя Linux-середовища на пару терабайт - буду дуже вдячний. Я вже дивлюсь у бік Hetzner але може є щось прям проверене у робочих умовах?

Друзі привіт - як ваш ранок?

Я все поки в запарі на роботі і налаштуванні свого енв)

Є для вас круте пояснення роботи одного з протоколів, мені подобається формат а вам? Чайники не про васС))

Всім гарного дня і настрою
Обняв 🤗

Доброго ранку друзі - як ви? як ваш ранок?

Це відео якраз про те шо деви іноді роблять бяку в обход куа)
Але миж куа не повині бякі пропускати в прод) Думаю підніму вам настрій

Всім гарного дня, друга кавуся вже допита і погнали працювати)

Сьогодні буде цікава інфа))

Сильні💛💛💛

Друзі, привіт! Як ваш день?
Добрався я до розбору нового пула - і цього разу він прям життєвий для всіх, хто хоч раз ловив «сервер лагає, API відповідає повільно» )

І так

Чому не (A) systemctl status
Багато хто натиснув саме це, і я розумію чому, перша думка: «подивлюсь, чи сервіс впав».
Але… якщо на сервері вже лагає все, ця команда не покаже головне - хто конкретно вантажить систему.
Вона просто скаже «running / failed», але не дасть ні CPU, ні пам’яті, ні load average.

Так це корисно, але точно не перше, що треба запускати.

Чому не (C) ping 8.8.8.8
Ping - це перевірити інтернет, а не сервер.
API гальмує → причина всередині машини, а не у зв’язку з Google DNS. і пінг вже вмер( краше юзати неткат типо шось nc -vz host port

Ping не покаже, що у вас один процес з’їв 100% CPU і тримає систему за горло.

Чому не (D) cd /var/log
О, логи - це святе)
Але лізти туди в першу секунду - це як шукати граблі в темній кімнаті.
Спочатку треба зрозуміти, чи взагалі живий залізяка, а вже потім дивитися логи.

Ну і чому правильна відповідь (B) htop

Тут все просто:
htop - це рентген сервера за 1 секунду.

Він вам покаже
- хто жере CPU;
- хто з’їв пам’ять;
- load average;
- процеси, що зависли;
- свопінг;
- загальну температуру системи.

Ви за 2 секунди розумієте:
«ага, ось цей java/python/node процес живе власним життям і душить усе навколо».

Саме тому htop - перше, що запускає інженер, коли на сервері почалося пекло )

І що я всеж маю вам сказать)
Правильна відповідь тут - не про "знати команду", а про мислення:
спочатку діагностика заліза → потім сервіс → потім логи.

Хто вгадав з першого разу - респект, ви мислите як SRE)
Хто ні - нічого страшного, тепер будете знати з чого починати.

Всім гарного дня і настрою!
Обняв 🤗

Доброго ранку банда! Як ваш ранок?
Слухайте, хочу вам розказати як я вчора в 10 веччері попав на фокап , і коли ти думаєшь «Чорт, а я ж думав, що знаю мережі» ))

Ранкові QA-історія: як же іх давно не було ТАК???

Тестував я інтеграцію між двома сервісами.
Умовно Сервер Х шле запити на Сервер Y - і раптом половина викликів тупо падає в таймаут. Без помилок. Без 5xx. Просто тиша.
Ну окей, думаю
«Зараз три каманди в терміналі - і розберемося».
Ага… як же ж

Ну перевірка, як завжди, з очевидного

Це - nc

nc -vz server-y 9090

конект є, все красиво.

як же без telnet

telnet server-y 9090

- всі помьятають шо він робе так?
і теж ок.

ну і сurl

curl -v http://server-y:9090/health

і тут вже починається «вічне завантаження»… і Потім timeout.

Тобто дістатися можна, а відповіді нема.
Так-так, це той самий момент, коли мозок каже: «ооо, походу буде весело».

Короче поліз я далі

Тобто сервері Y сервіс живий:

Спробуємо

sudo ss -tulnp | grep 9090

У логах видно, що запит прийшов і навіть була сформована відповідь, і трафік на вихід теж є - tcpdump підтвердив.

І тут уже зрозумів:
проблема не на стороні Y, відповідь відправляється.

І ось тут почалося цікаве
На сервері X зняв дамп:

Через

sudo tcpdump -i eth0 host server-y -w debug.pcap

Відкриваю у Wireshark.
І реально видно:
SYN → SYN-ACK → ACK → запит полетів → а назад пакетів НУЛЬ.

Не дроп, не RST, не ICMP. Просто… нічого.
Як у чорну діру.

тобто розгадка яка (після години матюків і інфри)
Виявилось, що сервер X після міграції в інший датацентр отримав новий набір правил фаєрвола.

І там було правило типу: - дозволити вихід на порт 9090, але заборонити вхідні пакети з цього діапазону IP

Тобто:
- вийти можна
- повернутись не можна

І curl зависав, бо пакет-відповідь просто рубився фаєрволом ще до додатку.

Шо я маю вам сказать:
Не ведіться на «telnet працює - значить все добре».
Telnet і nc показують тільки те, що можна достукатись,
А не те, що відповідь повернеться назад.

Фаєрволи інколи працюють за принципом:
«Випущу. Але назад не пущу.»
І це найпідліший тип багів.

Всім гарного дня і настрою!
Обняв, друзі 🤗🤗🤗