Начало года — лучшее время, чтобы подготовить свою стратегию тестирования. Если прошлый год был крутым (или наоборот), самое время проанализировать, что сработало, а что пора менять. Мы собрали 7 практических советов на основе опыта 2025 года, которые помогут вам выстроить стратегию тестирования.

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

1. Начните с данных, а не с "хотелок"

Проблема: Много команд тестирования строят планы на интуицию: "надо больше автотестов", "нужны AI-инструменты", "переходим на Playwright".

Решение: Выкопайте метрики из 2025:

• Time to Value — сколько времени проходит от запуска тестов до того, как команда поняла результаты и действует
• Flakiness rate — процент ложноположительных падений (идеально < 3%)
• Bug escape rate — сколько багов прошли в прод
• Coverage — покрытие кода и критичных пользовательских сценариев

Затем определите 2-3 конкретные цели на 2026:

• Ускорить полный регресс с 4 часов до 1.5 часов?
• Внедрить эй-ай-анализ падений и сэкономить 10 часов/неделю на отладку?

Почему это работает: Данные убеждают руководство, а чёткие цели дают направление.

2. Возьмитесь за исследовательское тестирование всерьёз

Миф: исследовательское тестирование — это когда тестировщик кликает что-то где-то, пока не найдёт баг.

Реальность: Это дисциплинированный процесс одновременного обучения, проектирования и исполнения тестов.

Как это работает в 2026:

Для каждой тест-сессии определите чартер - это такой word-документик, где будет описано:

• Что мы тестируем? (например, новая фича платежей)
• Какие риски ищем? (например, дублирование платежей, тайм-ауты при слабой сети)
• Сколько времени? (например, 2 часа с одним тестировщиком или тим-лидом)

Во время тест-сессии:

Документируйте результаты в реальном времени. Не жалейте на это времени — это не лишняя трата времени, это инвестиция. Найденные дефекты и идеи превратите в автотесты позже.

Главная фишка: Делайте исследовательское тестирование как можно раньше, когда код ещё гибкий.

3. Не меняйте инструменты, пока не исправили фундамент

Типичная ситуация:

• Selenium падает постоянно → "Переходим на Cypress!"
• Переходят → те же проблемы → "Может, Playwright?"

В чём подвох: Инструмент здесь не виноват. Виноваты:

• Тесты, которые переписаны криво
• Нестабильная окружение
• Неправильная архитектура тестов
• Отсутствие анализа

Что делать:

Прежде чем инвестировать в новый инструмент:

1. Изучите паттерны падений. Почему именно падают ваши тесты?
2. Исправьте проблемы в корне (фиксы окружения, рефакторинг тестов).
3. Только потом меняйте инструмент, если это действительно нужно.

Внимание: если вы меняете инструмент ради инструмента, вы просто потратите 3 месяца на миграцию и получите те же проблемы, но в новом интерфейсе.

4. Модернизируйте инфраструктуру (ещё не поздно)

Боль: Ваша тестовая среда дряхлеет. Selenium часто падает, CI/CD медленный, параллелизм "как получится".

Чек-лист инфраструктуры:

• Оптимизирована ли ваша CI/CD pipeline на скорость и надёжность?
• Хватает ли параллелизма для вашего растущего набора тестов?
• Выдержит ли инфраструктура рост тестов на 20-30% в течение года?

Что делать:

Рассмотрите облачные решения для тестирования (облако — это не подозрительно, это стандарт). Внедрите контейнеризацию (Docker, Kubernetes):

• Легко масштабировать: нужно 100 браузеров одновременно? Запустилось за 30 секунд
• Снижается случайность результатов из-за нестабильной окружения (это один из главных источников ложных падений)

5. Сделайте "Time to Value" главной метрикой

Забудьте про "количество тестов". Это не метрика, это фикция.

Главное — Time to Value: сколько времени с момента, как тесты запустились, до момента, когда команда поняла результаты и начала действовать.

Типичная ситуация:

• Ночной регресс запустился, отработал за 30 минут ✅
• Но результатов — 500 строк логов и 50 ошибок
• Разработчик 2 часа разбирается, какие ошибки реальные, какие — ложноположительные
• Итог: Time to Value = 2.5 часа

Если это ваша ситуация, пора действовать:

• Внедрите AI-анализ падений (умный анализ ошибок)
• Автоматизируйте обработку результатов (группировка похожих ошибок, ранжирование по severity (серьезность))
• Интегрируйте в Slack/Telegram уведомления: "2 критичных бага, 15 можно проигнорировать"

6. Делайте обновление тестов в середине года

Идея: Не ждите конца года. В июне остановитесь и переделайте тесты.

Что проверить:

• Какие тесты вы вообще запускаете? Есть ли дублирующие?
• Какие из них постоянно падают без причины?
• Какие тесты медленные? (Оптимизируйте или распараллелите)
• Есть ли "дырки" в покрытии? (Новые фичи, которые не покрыты)

Бонус для лета:

Июнь — это лучше время, потому что:

• Вторая половина года впереди (есть время на действия)
• Обычно меньше "горячих" проектов летом
• Можно спланировать крупные рефакторинги

7. Протестируйте сезонные нагрузки и скачки трафика заранее

Большинство компаний испытают трудности в "сезонные" периоды:

• 1 сентября (скачок студентов в образовательные приложения)
• Чёрная пятница и киберпонедельник
• Конец квартала (выплаты по подпискам)
• Крупные анонсы или PR-кампании
• Новый год (скачок в финтех и рассылках)

Что делать:

Сейчас же (в январе):

1. Определите пики трафика в вашем 2026-м
2. Запланируйте нагрузочное тестирование за 4-6 недель до события
3. Убедитесь, что в руководстве нет иллюзий: "Вот запустим все фичи 30 декабря, может, чего-то не сломается" — это гарантирует беду.

Инструменты для нагрузки: Apache JMeter (бесплатный), Locust (простой), k6 (для облака), нативные облачные сервисы (Azure Load Testing, AWS CloudWatch Synthetics).

Сценарий, который хорошо работает:

• Май: планируем, какие нагрузки
• Июнь: первый нагрузочный тест (находим узкие места)
• Июль-август: фиксим инфраструктуру, оптимизируем код
• Сентябрь: финальный нагрузочный тест
• Октябрь: готовы к нагрузкам

Главное правило

Тестирование имеет ценность только тогда, когда результаты понимаются и на них действуют.

Запустили 10 000 тестов, которые никто не смотрит? Это не качество, это театр. Запустили 100 тестов, проанализировали за 5 минут и нашли 2 критичных баги? Это работает.

В 2026 году сфокусируйтесь на:

✅ Данных, а не "хотелках"
✅ Скорости получения результатов (Time to Value)
✅ Стабильности окружения
✅ Раннем обнаружении проблем (исследовательское тестирование + сезонное тестирование)
✅ Снижении техдолга (обновление парка тестов в июне)

И помните: лучший инструмент — это дисциплина. Плохую архитектура не спасёт никакой фреймворк (и даже ЭЙ-АЙ)

Когда журналистка взяла и закодила приложение на чистом вайбе

Если бы я попросила вас угадать, кто в моем офисе мог бы создать приложение, в первых пяти вариантах вы не назвали бы мою профессию. И это логично.

Никогда я не указывала программирование в своем резюме как основное умение. Всё, что я знаю о коде, — это случайные обрывки знаний, собранные на работе. К тому же я живу в Bay Area (крупная агломерация в Северной Калифорнии, сформировавшаяся вокруг залива Сан-Франциско и включающая такие города, как Сан-Франциско,Сан-Хосе и Окленд, а также знаменитую Кремниевую долину), где каждый разговор рано или поздно скатывается на AI и технологии — не можешь избежать просто так.

Но жизнь полна сюрпризов. И вот однажды я создала приложение. С одной оговоркой: я не кодила его сама. Приложение полностью родилось из "вайба" (vibes) — так уже называют создание с помощью AI-инструментов вроде Bolt (конструктор сайтов на базе искусственного интеллекта, позволяющий создавать веб-сайты и мобильные приложения за считанные минуты)

Что такое Vibe Coding?

Концепция "vibe coding" появилась только в начале 2025 года, но уже успела стать одной из самых обсуждаемых применений больших языковых моделей. Она вызывает жаркие дебаты об эффективности и кучу страхов среди junior-разработчиков о том, как это изменит их будущее. Даже опытные программисты испытывают экзистенциальный страх замены.

Обещание, что vibe coding дает любому, даже без технического бэкграунда, возможность создать приложение, звучит как-то слишком хорошо. Из своего опыта скажу: это как нажать на кнопку на микроволновке, и еда сама разогреется. Слишком легко. Как только я отдала результат человеку с реальным техническим опытом, щели в моем творении начали вылезать со всех сторон.

В умелых руках это мощный инструмент. В моих — как фильтр AI в TikTok, который делает тебя похожей на персонаж из какого-нибудь аниме. Забавно выложить, но по сути — ничего стоящего.

Как я создавала приложение про плохие туалеты

Участвовала я в хакатоне Bolt, совместно с Reddit. Задача была простой: создать что-нибудь смешное, иррелевантное и вообще бесполезное. Я от таких идей не отказываюсь.

"Вроде Яндекс.Карт, но только про плохие туалеты в мире," — сказала я маме. "А кем ты работаешь, в конце концов?" — спросила она в ответ.

Процесс обещал быть легким. Для кого-то, кто не знает, где на компьютере лежит терминал, это оказалось не очень. Организаторы обещали, что за минуту я запущу разработку. Они предоставили ресурсы, включая гайд Reddit Developer Quickstart. Я потратила кучу времени на этот гайд, ибо не понимала ни черта.

Официально приношу извинения службе поддержки Stack Overflow за попытку установить Node.js на рабочий ноутбук, хотя мне это было совершенно не нужно.

Когда я поняла, что Bolt сам всё вытянет, стало намного легче. И это действительно так — Bolt может создать простое приложение от А до Я чуть ли не автоматически. Нужно либо знать хотя бы основы кода, либо иметь четкие инструкции. Я попала во вторую категорию.

Интерфейс Bolt красивый и интуитивный, с live-preview приложения сбоку. Ты можешь смотреть на код и редактировать строки вручную. Я же использовала простой текстовый ввод: "Создай приложение для Reddit — как Яндекс.Карты с рейтингами, но только для ужасных общественных туалетов"

AI сразу же принялся работать. Примерно за 10 минут основа была готова. Приложение запустилось в моём тестовом сабреддите, с глупым интерфейсом (там даже была эмодзи унитаза). Была форма для отзывов, рейтинг-скейл, страница с отзывами.

Все работало в браузере. Почти.

На самом деле — вообще не работало.

Сразу же начались ошибки. И в интерфейсе Bolt, и в самом приложении. Не мог загрузиться ни один отзыв. Красные сообщения об ошибках: "location services недоступны", "не получается загрузить". Хотя работы было проведено мало, я испытывала подавленность. Я сказала коллегам: "Приложение не работает."

И начался адский час — 45 минут troubleshooting (процесс систематического поиска и устранения неисправностей, неполадок). AI указывал мне, где искать ошибки. Я просто копировала текст ошибки в чат, и Bolt сам разбирался. Правда, когда AI объяснял, что исправил (что-то про API endpoints на root level), я вообще ничего не понимала. Весь смысл опыта был в том, что я этого не должна понимать.

Мой эпический fail с npm run dev

Я даже не знала, что команда npm run dev обновляет приложение в реальном времени. Я думала, что нужно каждый раз переписывать и переливать приложение, чтобы протестировать новую версию. Я представляла каждую версию как отдельный объект, а не развивающееся приложение. В итоге в моем тестовом сабреддите было 20 постов, прежде чем я получила рабочее приложение.

Но Bolt был невероятно полезным. Я была потеряна, как в лесу, а он вытягивал меня за правильное направление. Он даже помогал менять интерфейс — я переделывала дизайн как графический дизайнер, которым я и являюсь.

В конце концов, что-то получилось работающее. С кавычками вокруг слова "я". Bolt создал приложение, а я просто писала промпты и копировала ошибки. С каждой итерацией что-то новое начинало работать. Я добавила загрузку инфы, просмотр отзывов, красивые бейджи.

Но даже когда приложение работало — оно было хорошим?

Отправляю своё творение на суд

Я выполнила задачу хакатона: создала что-то смешное, иррелевантное и совершенно бесполезное. Коллеги с удовольствием начали заполнять его худшими туалетами.

Потом я встретилась с Ryan Donovan (известный блогер Stack Overflow) для ревью. И тут-то вскрылось, что это творение — полная катастрофа.

Во-первых, он удивился, сколько технологий там работает для такого простого приложения. "Ты знаешь, что такое JSON или Redis?" спросил он. "Нет," ответила я честно.

Райану даже не нужно было смотреть на код. Через инспектор браузера он сразу нашел проблемы. Главная: у приложения нет никаких защит. Любой может получить доступ ко всем данным. Это довольно серьёзно, но к этому вернемся позже.

Райан предложил выложить код на GitHub и получить фидбэк от сообщества. Но когда я поняла, как всё плохо, я испугалась публичного позора. Не то, чтобы я боялась критики (нечего тут критиковать), а просто ощущение дрожащего страха, как перед разбором домашки учителем.

К счастью, в Bay Area почти все мои друзья — разработчики. Я попросила их посмотреть. Трусливый ход, конечно, потому что они знали про vibe-coding и были деликатны.

Фидбэк от друзей-программистов

Главное: код — полная свалка, невозможно разобрать.

Я специально давала мало контекста, надеясь, что файл README.md, который создал Bolt, всё объяснит. Но структура вышла паршивая — я же никогда не работала с GitHub.

"У тебя хороший README, но почему-то все спрятано в папке ./project. Почему бы не выложить на верхний уровень?" — написал один мой знакомый из Palo Alto.

Другой: "Весь стайлинг инлайнирован в tsx-компоненты. Это делает всё запутанным и нечитаемым."

Третья добавила: "There are no unit tests." (Нет юнит-тестов.)

Я поняла, что она не может даже проверить, имеют ли смысл мои компоненты.

Ненарушенное обещание

Вот в чём главный разрыв: между vibe-coding и реальной разработкой. Моё приложение было экспериментом, так что плохой код не страшен. Но это точно не должно рекламироваться, как инструмент для поднятия производительности, мост для нетехнических людей и (со временем) замена junior-разработчикам.

Да, я могу взять фидбэк от друзей и влепить их советы в промпт. Один из них порекомендовал добавить описательные имена классов. Bolt сделал это за секунду — и понимал даже, почему это нужно, хотя я и не знала.

Но что если у меня нет друзей-разработчиков? Что если это не хобби-проект, а реальная работа или идея, которую хочу монетизировать?

Мой код превратился бы в проблему. Да, приложение работает, но действительно ли оно хорошее? На реальном проекте после меня пришлось бы приходить разработчику и переписывать всё, чтобы будущие коллеги не потерялись в хаосе. Это называется "productivity tax" — главная боль программистов от AI-инструментов, которые выдают код, почти (но не совсем) правильный. По опросам Stack Overflow, 66% разработчиков сталкиваются с этой проблемой.

Безопасность — главный красный флаг

Но есть проблема ещё серьёзнее: безопасность. Помните, что Райан сказал про отсутствие защиты? На моём глупом приложении про туалеты — неважно, никаких ценных данных там нет.

Но вот представьте: инструменты обещают результаты без опыта разработки. Будут люди без опыта, которые создадут свои пет-проекты на Bolt. И многие из них будут безобидными и будут работать хотя бы с фронтендом. Потом — запросят почтовый индекс, email, дату рождения, пароль. Вы, наверное, уже догадываетесь, к чему я клоню?

Конечно, на продакшене обычно приходит разработчик и проверяет перед запуском. Но что с любительскими проектами? Я легко представляю, как кто-то создаст что-то для близких с персональными данными — и это попадет в руки мошенников

Или всё не так плохо?

Был ли мой результат достаточно хорош для моих целей? Да. Могла ли я с помощью друзей-разработчиков исправить безопасность и организацию без единой команды терминала? Да, точно.

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

Другая история: когда vibe-coding работает

Мой лучший друг — доктор физики Стэнфорда. Хотел остаться в науке, но в академии зарплаты нищие, а мест нет. Он решил кардинально переквалифицироваться и учиться кодить с нуля за пять лет.

Он сказал, что LLM'ы дали ему буст в обучении в 10 раз. Стал использовать CoPilot, Gemini, ChatGPT как личного репетитора — когда не мог найти баг, AI объяснял. И потом, когда встречалась похожая проблема, он уже знал решение.

Вот это — реальная ситуация, когда vibe-coding может помочь: учиться кодить без соответствующего образования. Мой друг... не скажешь, что он не умен для программирования. Просто у него не было опыта. И возвращаться в институт на ещё пять лет после Стэнфорда было немыслимо. Vibe-coding дал ему поддержку и знания, чтобы учиться самому.

Итог: всё зависит от того, как ты это используешь

Как и в любом инструменте — всё зависит от использования.

Я хочу, чтобы мой опыт вайб-коддинга стал первым шагом в обучении кодированию. Поэтому я выложила свой проект на GitHub и прошу фидбэк, критику и советы.

Помогите мне перестать быть худшим программистом в мире.

Главные выводы из статьи

Для QA-специалистов и тестировщиков

Vibe-coding создает новый вид приложений, которые нужно ОБЯЗАТЕЛЬНО тестировать:

• Код не следует каким-либо лучшим практикам — нужны более строгие тесты
• Безопасность не встроена — тестирование безопасности становится нужным с самого начала
• НЕТ ДОКУМЕНТАЦИИ — нужно самому разбираться в логике через UI и инспектор

Для начинающих разработчиков

Это не замена классическому обучению, но отличная поддержка:

• Учитесь кодить с AI как с репетитором
• Создавайте свои проекты, а потом просите разработчиков на ревью
• Понимайте, почему код так написан — не просто копируйте

Для стартапов и малых команд

Будьте осторожны:

• Код на "ВАЙБЕ" требует дополнительного QA и ревью безопасности
• Не выпускайте такой код в продакшен без опытного программиста

Что такое сборщик мусора и зачем он нужен тестировщику

Если вы начинаете разбираться с производительностью приложений, особенно в Java или .NET, вы рано или поздно столкнётесь с понятием «сборщик мусора». Эта статья поможет вам понять, что это за механизм, как он работает и почему важно учитывать его поведение при нагрузочном тестировании.

Немного истории: от ручного управления к автоматике

Ранние языки программирования, такие как C и C++, требовали от разработчика вручную управлять памятью: выделять её под нужды программы и освобождать, когда она больше не нужна. Ошибки в этом процессе — забытые освобождённые участки памяти (утечки) или повторное освобождение уже освобождённого блока — приводили к сбоям, нестабильности и уязвимостям.

С появлением более высокоуровневых языков, таких как Java и C#, появилась автоматическая сборка мусора (Garbage Collection, далее по тексту - GC). Задача сборщика — автоматически находить и удалять объекты, которые больше не используются программой, тем самым освобождая память.

Как работает сборщик мусора

Сборщик мусора анализирует память, чтобы понять, какие объекты всё ещё «живы» — то есть на которые есть ссылки в коде — а какие можно удалить. В зависимости от реализации, этот процесс может быть:

• Параллельным — GC работает вместе с приложением
• Стоп-мир (stop-the-world) — приложение приостанавливается, пока работает GC
• Инкрементальным — память очищается частями, небольшими порциями

Также во многих современных реализациях используется сборка мусора по поколениям (generational garbage collection). Этот подход основывается на наблюдении, что:

• большинство объектов «умирает» быстро
• объекты, которые пережили несколько сборок, скорее всего будут использоваться долго

В таком случае память делится на поколения:

• Young Generation — для новых объектов. Здесь сборки происходят часто, но быстро (Minor GC)
• Old Generation (Tenured) — для «долгоживущих» объектов. Здесь сборки редкие, но тяжёлые (Major GC)
• Permanent/Metaspace — область для хранения метаинформации классов (в JVM)

Такой подход снижает частоту и длительность полной сборки мусора.

Виды управления памятью: ручное и автоматическое

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

Пример: C, C++ — программист сам вызывает команды управления памятью. Ошибки ведут к утечкам памяти, двойному освобождению и крахам приложений.

При автоматическом управлении памятью (например, в Java, Python, Go) эти задачи берёт на себя среда выполнения. Сборщик мусора решает, какие объекты больше не нужны и может освободить занимаемую ими память. Такие языки сами управляют памятью — программисту не нужно вручную её освобождать. Это упрощает работу и снижает шанс ошибок, хотя может повлиять на производительность.

• Java (JVM) — использует продвинутый сборщик мусора с делением памяти на поколения. Есть гибкие настройки и выбор алгоритма под тип нагрузки (например, G1GC, ZGC).
• Python — работает по принципу подсчёта ссылок и запускает отдельный сборщик, чтобы убирать циклические ссылки. Можно вызывать GC вручную через модуль gc.
• C# (.NET) — тоже делит память на поколения. Работает "из коробки" без сложной настройки и подходит для большинства задач.

Знание особенностей GC в каждом языке поможет избегать утечек памяти и добиться стабильной работы приложения.

Преимущества и недостатки сборщика мусора

Автоматическое управление памятью через сборщик мусора имеет как очевидные плюсы, так и важные ограничения. Особенно важно понимать это при работе с высоконагруженными системами.

Преимущества:

• Упрощение разработки: программисту не нужно вручную освобождать память, снижая риск ошибок.
• Защита от утечек памяти: GC автоматически удаляет объекты, на которые больше нет ссылок.
• Повышение надёжности: меньше сбоев, связанных с неправильной работой с памятью.

Недостатки:

• Паузы исполнения: при некоторых алгоритмах приложение может «замереть» на время сборки.
• Менее предсказуемое использование ресурсов: сложнее контролировать точный момент освобождения памяти.
• Ресурсоёмкость: сама работа GC требует CPU и может конкурировать за ресурсы с основным приложением.

Правильный выбор и настройка GC позволяют минимизировать недостатки и использовать преимущества на полную.

Практические соображения для тестировщика

Инженеры по тестированию часто сталкиваются с ситуациями, когда приложение «тормозит» или внезапно «подвисает». Часто причиной этого становится GC:

• Долгие паузы при сборке мусора могут замедлить отклик системы
• Частые сборки могут сигнализировать о неправильной работе с памятью
• Нарастающее использование памяти может говорить об утечке

Вот что важно учитывать:

• Мониторинг GC: с помощью инструментов вроде JVisualVM, Grafana, Prometheus, вы можете отслеживать количество и продолжительность сборок
• Понимание логов: GC оставляет сообщения в логах приложения. Умение читать их — ценное умение
• Выбор правильного сборщика: в зависимости от типа нагрузки (пиковые запросы, фоновая обработка) может потребоваться настроить другой GC

Сборщик мусора — полезный инструмент, но не волшебная палочка. Чтобы он действительно помог, нужно понимать, как он работает, и правильно его настроить. Один и тот же GC может вести себя по-разному в зависимости от нагрузки. Поэтому важно подбирать стратегию под конкретное приложение, следить за его работой и не забывать, что даже автоматике иногда нужна помощь.

Источники aerospike | techTarget

Типы систем мониторинга

Мониторинг всегда был основным компонентом ИТ-систем. Он отвечает за обнаружение и помощь в локализации проблем. Разработчикам (и тестировщикам) необходимо обращать внимание на систему мониторинга и участвовать в ее построении и оптимизации. Сейчас существует более сотни систем мониторинга, которые состоят из:

• Объект мониторинга:
1. Общий - общий метод мониторинга, подходит для большинства объектов мониторинга;
2. Специализированный - настраивается под конкретную функцию, например, система Java JMX, защита от перегрева процессора, защита от сбоев питания жесткого диска и т.д.
• Метод сбора данных:
1. Push (CollectD, Zabbix и InfluxDB) - агенты сами пишут в базу данных;
2. Pull (Prometheus, SNMP и JMX) - система мониторинга собирает с каждого агента информацию
• Режим развертывания:
1. Coupled (связанный режим) - мониторинговая система развертывается вместе с основным ПО;
2. Standalone (автономный режим) - отдельное развертывание мониторинговой системы, которая работает независимо от других компонентов;
3. Distributed (распределённый режим) - cистема мониторинга построена на распределённой архитектуре, что позволяет масштабировать её горизонтально;
4. SaaS (software as a service — программное обеспечение как услуга) - не требует развертывания, предоставляется сторонними компаниями. Не нужно разворачивать собственные инстанции — они просто используют готовое решение через облако
• Метод получения данных:
1. Тип интерфейса - данные можно получить только через API;
2. DSL (Domain-Specific Language) - использование специализированного языка запросов, разработанного для конкретной задачи, например PromQL и GraphQL;
3. SQL - используется стандартный SQL или его вариации (SQL-like), чтобы запрашивать данные из баз данных
• Инструменты
1. Open-source и бесплатные - системы с открытым исходным кодом, которые можно использовать бесплатно (например, Prometheus и InfluxDB standalone edition);
2. Коммерческие с открытым исходным кодом - эти системы имеют открытый исходный код, но их расширенные функции предоставляются на коммерческой основе (например, InfluxDB cluster edition, Elastic Search X-Pack);
3. Коммерческие с закрытым исходным кодом - это полностью проприетарные (закрытые) системы, которые разрабатываются частными компаниями и доступны только на платной основе(например, DataDog, Splunk и AWS Cloud Watch).

Pull или Push?

Существует множество вариантов построения платформы системы мониторинга для внутреннего использования, будь то самостоятельная сборка с использованием решений с открытым исходным кодом или коммерческих SaaS-продуктов. Однако независимо от того, будет ли это решение с открытым исходным кодом или коммерческий SaaS-продукт, при реальном внедрении необходимо продумать, как передать данные платформе мониторинга или как платформа мониторинга может получить эти данные. Для этого нужно сделать выбор метода получения данных: Pull или Push.

Система мониторинга на основе Pull-модели, как следует из названия, активно запрашивает метрики у объектов мониторинга, которые должны обладать возможностью быть доступными удалённо. В отличие от неё, Push-модель мониторинга не запрашивает данные самостоятельно — объекты мониторинга сами отправляют метрики в систему.

Эти два подхода имеют существенные различия в ряде аспектов. При разработке и выборе системы мониторинга важно заранее понимать преимущества и недостатки каждого из методов, чтобы выбрать наиболее подходящий вариант для реализации. В противном случае в будущем могут возникнуть значительные затраты на поддержку стабильности системы, её развертывание и эксплуатацию.

Источник alibabacloud |

Если вы открывали какие-либо файлы в интерфейсе MobaXterm, то могли обратить внимание, что их текстовый редактор, установленный по умолчанию (MobaTextEditor), не может похвастаться большим функционалом и удобством использования

Решение №1 (не самое удачное 🤷‍♂️)

Возможно, в такой ситуации вы пробовали открывать файлы в удобном для вас редакторе с помощью нажатия ПКМ -> "Open with..."

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

Решение №2 (имба 💪)

Создатели MobaXterm осознавали, что пользователи будут испытывать боль при использовании их редактора, поэтому дали возможность изменять его на любой другой:

• Открываете "Settings"

• Далее кликаете на иконку указания пути до выбранного вами редактора

• Выбираете нужный редактор

Теперь файлы будут открываться в выбранном вами текстовом редакторе

Ну красота же?)

Источник статьи: мой опыт работы 😁

Введение

В этой статье я расскажу о том, какие метрики наиболее полезно собирать для приложений и сервисов.

Начало работы

Допустим, вы развернули сервис на своей платформе и решили добавить для него мониторинг.

С чего начать?

Во-первых, необходимо выяснить, какой именно набор метрик вы хотите снимать.

Этот набор не всегда будет одинаковым для всех приложений.

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

Чтобы немного сузить круг поиска, мы можем обратиться к методам RED и USE.

Методы RED / USE

Вы наверняка слышали о методах RED и USE.

USE

USE - это аббревиатура от Utilization, Saturation и Errors. В статье Брендан Грегг пишет, что

"USE - это методология анализа производительности любой системы" и что с помощью этого метода можно решить около 80% проблем сервера, затратив 5% усилий.Вы начинаете с создания чек-листа для анализа сервера, который может быть использован для быстрого выявления узких мест или ошибок. Затем вы начинаете задавать вопросы и искать на них ответы.

Он сравнивает его с аварийным контрольным списком в руководстве по летной эксплуатации: он должен быть простым, понятным, полным и быстрым.

В основе метода USE лежат три типа метрик и стратегия метода к комплексной системе.

Брендан Грегг кратко описал метод USE следующим образом:

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

где:

• Utilization (использование - процент времени, в течение которого ресурс был занят).
• Saturation (насыщенность - количество работы, которую должен выполнить ресурс).
• Errors (количество ошибок во время выполнения работы)

Метод USE предназначен для использования на ранних этапах исследования производительности, чтобы выявить системные узкие места.

О методе USE можно прочитать здесь

RED

В 2015 году Том Уилки из Grafana рассказал о методе RED для мониторинга микросервисов.

В этом выступлении Том Уилки сказал:

«Метод USE не совсем применим к сервисам; он применим к аппаратному обеспечению, сетевым дискам и тому подобным вещам. Нам очень нужна была философия мониторинга, ориентированная на микросервисы, поэтому мы придумали метод RED».

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

Для каждого ресурса отслеживайте:

• Rate (скорость - количество запросов в секунду, которые обслуживают ваши службы).
• Errors (количество неудачных запросов в секунду - ошибок).
• Duration (длительность - время отклика ваших сервисов на каждый запрос).

Используя метод RED, компании будут лучше понимать, насколько довольны клиенты

Если у вас высокая частота ошибок, это означает, что ваши пользователи получают ошибки при загрузке страницы.

Если у вас высокое время отклика, значит, ваш сайт работает медленно.

LTES (или "Четыре золотых сигнала")

Подождите, есть еще один метод. Четыре «золотых сигнала» взяты из книги Google's SRE Book

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

Где:

• Latency (Задержка - время, необходимое для обслуживания запроса)
• Traffic (Трафик - количество запросов к вашей системе)
• Errors (Ошибки - количество запросов, которые не выполняются)
• Saturation (Насыщение - насколько «переполнен» ваш сервис).

Единственное отличие этого метода от метода RED заключается в том, что он включает в себя насыщение (Saturation ).

Какой метод вам следует использовать?

Том Уилки рекомендует использовать комбинацию методов USE и RED.

«Метод RED - это забота о пользователях и их счастье, - говорит Том, - а метод USE - это забота о машинах и их счастье. На самом деле это просто два разных взгляда на одну и ту же систему. Они дополняют друг друга».

Источник Medium |

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

Но прежде чем мы перейдем к техническим обсуждениям, связанным с прокси или обратными прокси, я хотел бы вспомнить одну ситуацию из детства, которая наверняка была у каждого из вас.

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

Надеюсь, вы получили представление об этом простом сценарии, теперь давайте посмотрим, как это связано с прокси-сервером.

Прокси-сервер

На рисунке 2 представлено простое клиент-серверное приложение. Все клиенты отправляют свои запросы на прокси-сервер, а затем прокси-сервер отправляет запросы клиентов на сервер. Таким образом, прокси-сервер выполняет роль брандмауэра или щита на стороне клиента, обрабатывает все клиентские запросы и отправляет их на сервер соответствующим образом. Основная цель такого рода прокси - защитить клиентские приложения от внешних серверов и других уязвимостей безопасности. Как это работает? Это работает так, что клиенты и их IP-адреса не раскрываются внешнему миру, а вот прокси-сервер будет раскрывать себя от имени клиентских приложений. Надеюсь, вы помните приведенный выше сценарий «ребенок-родитель». 😃

Надеюсь, теперь у вас есть четкое представление о прокси-сервере и его роли. Теперь перейдем к обратным прокси-серверам.

Обратный прокси-сервер

Концепция обратного прокси-сервера очень похожа на концепцию прямого прокси-сервера. Предположим, что у нас есть несколько экземпляров сервера, работающих на бэкенде. Но помните, что не обязательно иметь несколько экземпляров, в некоторых случаях будет достаточно одного сервера. 😉 На рисунке 3 показано, что обратный прокси расположен на стороне серверов. Вместо того чтобы защищать клиентские приложения, обратный прокси защищает экземпляры сервера на бэкенде от внешних сторон или клиентов. Таким образом, клиенты никогда не узнают, какой экземпляр сервера будет отвечать на их запросы. Каждый запрос клиента будет отфильтрован на обратном прокси, а затем обратный прокси-сервер перенаправит эти запросы на соответствующие сервера для дальнейшей обработки.

У обратных прокси-серверов есть и другие преимущества. Такие прокси могут кэшировать статический и динамический контент. Если клиенты снова и снова запрашивают один и тот же ресурс, мы можем кэшировать это содержимое на уровне прокси. Таким образом, нам не придется снова и снова отправлять один и тот же запрос на сервера. Следующее преимущество этих прокси-серверов заключается в том, что они могут сжимать данные, которые будут проходить через сеть, используя различные алгоритмы. Еще одно важное преимущество обратных прокси-серверов заключается в том, что они могут выступать в качестве балансировщика нагрузки. Итак, давайте разберемся и с этим.

Балансировщик нагрузки

Как я уже говорил, обратный прокси-сервер может выступать в качестве балансировщика нагрузки. Помните, что не каждый обратный прокси-сервер будет выступать в роли балансировщика нагрузки, но каждый балансировщик нагрузки должен быть обратным прокси-сервером. Итак, роль балансировщика нагрузки заключается в распределении нагрузки клиентских запросов между экземплярами сервера. Например, у нас есть приложение, которое получает более 5 миллионов запросов в день. Таким образом, если на стороне сервера будет только один экземпляр, он не сможет справиться с таким огромным трафиком. Поэтому нам нужно иметь несколько экземпляров сервера. Вы можете задаться вопросом: если у нас есть несколько экземпляров, как мы можем распределить трафик между этими серверами? Как раз в этом случае на помощь приходит балансировщик нагрузки 😉.

Балансировщик нагрузки принимает все запросы клиентов и распределяет их между экземплярами сервера в соответствии с различными алгоритмами. В данном конкретном случае (рисунок 4) он использует алгоритм балансировки нагрузок циклическим перебором (Round-Robin) для распределения нагрузки между экземплярами сервера. В алгоритме Round-Robin каждый новый клиентский запрос будет переадресован следующему соседнему серверному экземпляру в последовательном порядке. Таким образом, вместо того чтобы один сервер разрешал все запросы, все серверы будут участвовать в разрешении клиентских запросов по правильному и эффективному алгоритму. Существует не только Round Robin, но и ряд других алгоритмов, таких как Hash, IP Hash, Least Connections и так далее.

Отлично! Вот и все для этой статьи. Спасибо, что дочитали до конца. Надеюсь, вы узнали что-то ценное. Продолжайте учиться, продолжайте расти.

УДАЧИ!!!

Источник Medium |

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

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

Зачем использовать тестирование производительности?

Существует ряд причин, по которым организация может захотеть использовать тестирование производительности, в том числе следующие:

• В качестве диагностического способа выявления узких мест в системе.
• Чтобы помочь определить природу проблемы производительности, связанной с программным обеспечением, путем определения мест, где приложение может не работать или отставать. Организации также могут использовать этот вид тестирования для обеспечения готовности к предсказуемому крупному событию.
• Для проверки требований, чтобы убедиться, что система соответствует спецификациям, заявленным в её требованиях.
• Предоставление информации заинтересованным сторонам для информирования участников проекта об обновлениях производительности приложения, касающихся скорости, стабильности и масштабируемости.
• Во избежание получения плохой оценки от пользователей, так как приложение, выпущенное без тестирования производительности, может работать плохо, что может привести к негативной репутации.
• Для сравнения двух или более систем, чтобы организация могла сравнить скорость работы, отзывчивость и стабильность программного обеспечения.

Источник Techtarget |

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

Профиль рабочей нагрузки является ключевым компонентом такой модели. В зависимости от типа и целей нагрузочного теста может быть уместен один или несколько профилей. Выбор профилей нагрузки, отражающих предполагаемую реальную нагрузку в течение определенного времени (будь то сценарий повседневного использования или высокий пик), позволяет получить более точные ответы на «основные вопросы нагрузочного тестирования», такие как:

• Поддержит ли мой сайт одновременный поиск N пользователей?
• Какое наибольшее количество пользователей может поддерживать мой сайт, оставаясь при этом в рамках заданных требований к качеству и производительности?

В этой статье мы рассмотрим вопросы, на которые стоит ответить, чтобы определить рабочий профиль нагрузки для вашего приложения

Каков набор возможных действий, которые может выполнить пользователь?

Такие действия зависят от специфики вашего веб-приложения. Для продуктового приложения это могут быть:

1. Открыть главную страницу.
2. Авторизоваться.
3. Просмотреть каталог товаров.
4. Найти нужный товар через поиск.
5. Добавить товары в корзину.
6. Проверить корзину и оформить заказ.
7. Выйти из приложения

Какие могут быть пользовательские профили для приложения? Достаточно ли одного пользовательского профиля?

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

Например, для вашего нагрузочного теста список пользовательских профилей может быть таким:

1. Профиль просмотра
2. Профиль поиска
3. Профиль размещения заказа

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

Какие действия выполняет пользователь, представляющий каждый пользовательский профиль?

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

Например, предположим, что в среднем каждый пользователь, покупающий товары на в вашем приложении, приобретает три товара за одну сессию. Статистика различных действий в профиле пользователя будет выглядеть вот так:

*Этот анализ необходимо выполнить для всех профилей пользователей

Каково среднее "время обдумывания" пользователя между действиями?

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

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

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

Каково ожидаемое соотношение сценариев профилей пользователей?

Комбинирование различных профилей позволяет создать более реалистичную имитацию веб-трафика для тестов. Соотношение бизнес-действий, выполняемых различными профилями пользователей, можно оценить или измерить. Например, типичная модель использования приложения для покупки товаров может состоять из 77 % пользователей, просматривающих приложение, 20%, ищущих конкретные товары, и 3 %, оформляющих заказ. Соотношение зависит от вашего приложения, вашего бизнеса и ваших пользователей.

Как меняется количество пользователей, заходящих на ваш сайт, с течением времени?

В реальной ситуации количество пользователей будет зависеть от времени суток, недели года, новостей и т. д. Понимание и учет этих изменений позволит вам разработать лучший профиль рабочей нагрузки.

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

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

Каково максимальное ожидаемое количество пользователей, посещающих ваше приложение?

Это число представляет собой предельную пропускную способность вашего приложения.

Если вы разрабатываете новое приложение, источником этих данных может быть документ с требованиями к приложению (который основан на прогнозируемом использовании вашего приложения по наилучшим предположениям вашего отдела аналитики). Для существующих приложений вы можете определить количество одновременных пользователей, проанализировав журналы сервера и/или информацию, предоставляемую службой аналитики.

В течение какого времени должен выполняться тест?

Продолжительность тестирования зависит от специфики вашего приложения и может составлять от 20 минут до недели. Рассмотрим следующие сценарии:

• Вам необходимо протестировать механизм входа в систему, чтобы убедиться, что необходимое количество пользователей может войти на сайт в течение определенного периода времени. Этот сценарий можно протестировать за короткий промежуток времени (15-20 минут), а результаты экстраполировать на более длительные периоды. Если 100 пользователей могут войти на сайт в течение 15 минут, можно экстраполировать результаты на 400 пользователей в течение часа.
• Вы можете проводить тесты непрерывно в течение длительного периода времени (дней, а возможно, и недель) с постоянной нагрузкой, чтобы проследить, как работает ваше приложение в течение длительного времени. Это позволит выявить медленные утечки памяти, которые становятся очевидными только через длительный период времени.

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

Источник SmartBear