500 ГБ - это объем для знакомства с продуктом, тестовых стендов или микросервисов, которым нужен именно S3 API. Для серьезных хранилищ, конечно, мало. Если для тестирования нашего продукта требуется увеличенный лимит на объем данных, то мы готовы обсуждать изменение этого ограничения с заказчиком.
В SeaweedFS есть AD и Kerberos, но сейчас чаще нужен OAuth2/OIDC. Мы добавили нативную интеграцию UI с Keycloak, чтобы избежать самописных прокси.
При росте данных PostgreSQL не справляется, и нужен TiKV. Мы сделали бесшовную миграцию: в Helm-чарте меняется тип бекенда, данные переезжают на TiKV автоматически без даунтайма.
Исправили критичный для нас баг с рекурсивным удалением в Apache Spark (позже фикс появился в апстриме).
Доработали Helm-чарты: добавили поддержку Istio и исправили чарты CSI Driver для корректной работы persistence-слоя в K8s.
Также локализовали UI на русский язык и выполнили другие доработки.
В части поддержки мы даем SLA и снимаем санкционные риски. Контроль санкционных рисков реализован на архитектурном уровне и в процессах жизненного цикла разработки и сборки продукта.
Два часа на покраску кнопки – это действительно значительный объем времени, если смотреть на него изолированно. Однако ключевой результат не в самой цифре, а в том, что мы наконец получили объективную картину. Сформировав общую базу по нормативам и сопоставив плановые показатели с фактическими затратами, мы выявили системные закономерности.
Если кратко: мы подтвердили, что покраска простой кнопки за 2 часа – адекватный норматив. Но анализ отчетности до внедрения этого ориентира показал разброс от 3 до 10 часов на ту же операцию. После приведения к единому нормативу фактическое время сократилось в среднем вдвое. Реальность, разумеется, сложнее, но суть передана верно.
По поводу спринтов и нормативов. Спринты – не универсальный инструмент. Мы говорим о производственных командах, чья задача – создавать инкремент. Для них спринты работают. Для остальных процессов нормативы выполняют другую функцию: они задают разумные границы, помогают выделить время и объективно оценить сложность. Также задача имеет тенденцию заполнять все отведенное ей время, и норматив здесь выступает в качестве ориентира.
Об инженерах. Инженеры для нас, конечно же, ценны в первую очередь как люди. Они точно не просто «трудовая функция» и не единица в формуле. Имели в виду, что норматив – это инструмент, позволяющий снять субъективные колебания. Не попасть в норматив – абсолютно нормально, и за этим часто стоят объективные, уважаемые нами причины.
О сравнение команд. Норматив – это линейка. Впервые мы можем поставить команды в равные условия и корректно сравнить их эффективность. Да, команда может временно находиться в другом процессе – отчеты это покажут, и такое отставание всегда объяснимо. Есть спринты, в которых команда стабилизирует продукт, по сути исправляя ошибки и не создавая новых функций. Но если ситуация повторяется 7 спринтов подряд – это уже системный маркер. Скорее всего, команде нужна помощь, и теперь мы можем это увидеть раньше, чем накопятся проблемы.
Норматив учитывает ИИ или ИИ учитывает норматив. Умеем и то и то.
ИИ не заменил разработчиков, а стал им помощником. Эта помощь может выражаться как в скорости решения рутинных задач, так и в качестве при решении сложных задач.
Когда агент гарантированно закроет какой-то фронт работ, безусловно, это скажется на трудоемкости типовых работ в сторону уменьшения.
Что касается корректности выбора норматива и сложности на задаче при оценке, то да, ИИ это проверяет и формирует определенный отчет для владельцев этой практики для понимания, что можно еще улучшить, чтобы команды выбирали корректные типовые работы и сложности при оценке трудоемкости задач.
2) На данный момент мы используем языковую модель Qwen3-30B-A3B, развернутую через vLLM. Это трансформерная LLM семейства Qwen (аналог GPT-подобных моделей), распространяемая с открытыми весами под лицензией Apache 2.0, что допускает коммерческое использование, модификацию и развертывание в инфраструктуре заказчика.
3) Тесты генерируются тестировщиком по мере необходимости при добавлении нового функционала. Мы автоматизировали процесс тестирования – если ранее при добавлении функционала пользователь писал тест каждый раз под новый функционал, теперь ему необходимо под этот новый функционал описать сценарий, а тест за него напишет LLM. Насчет анализа нового кода агентом напрямую без описания сценария пользователем, тут вопрос не в логичности, а в ограничении ресурсов. Анализ кодовой базы – процесс непростой, для этого необходимо использовать модели с сильно бОльшим контекстом.
В дальнейшем планируется развитие агента – одним из направлений развития как раз и является генерация пользовательского сценария по измененному коду с помощью LLM. В этом случае дальнейшая цепочка генерации теста не изменится, поменяется лишь способ получения исходного сценария (тест-кейса).
4) QA должен понимать какой функционал тестируется, какие входные и выходные данные для тестирования функционала должны использоваться. Глубокое понимание архитектуры проекта ему не требуется.
Пользователь, который подает на вход сценарий, подает его осознано, т.е. знает и понимает какие эндпоинты и для чего используются.
В качестве примера рассмотрим следующий кейс.
Пользователь задает сценарий в терминологии бизнеса: "Добавь тип суммы, поменяй у него название, удали его, проверь, что его больше нет #apionly"
ИИ как раз отбирает необходимые эндпоинты:
POST /agreement-amount-type
PUT / agreement-amount-type/{agreementAmountTypeld}
Если какие-то параметры не будут учтены в одном из вариантов автотестов, то тест не будет пройден, ИИ получит ошибку, прочитает ее и исправит тест относительно текста ошибки.
5) В промте у нас описаны правила построения автотеста, а также в некоторых инструкциях мы явно указываем, как делать не надо. Также от чуши спасает абстрагирование от деталей вызова API/события за счет использования заготовленных методов (определенных в Groovy-сервисе для запуска тестов). То есть LLM не нужно знать, как подключаться к брокеру или как звать API по REST. LLM использует заготовленные нами "кубики" и понимает, что в случае отбора API POST/api/request надо в тесте использовать метод clientPost(), а в случае отправки события и ожидания ответа – sendEventAndWaitForReply().
Дополнительно после отбора API/событий мы проверяем их наличие в документации. Если это результат фантазий LLM, то тест генерироваться не будет. Если LLM сильно фантазирует при генерации теста, то мы это пресекаем проверкой валидности теста при запуске – откровенная «чушь» успехом при запуске не завершится.
Защита от логических ошибок в тестах происходит на нескольких уровнях:
1) После указания пользовательского сценария (заявленного тест-кейса) сначала происходит отбор API/событий по семантической близости с заявленным тест-кейсом. После этого отобранные API/события явно выводятся пользователю, и он может проваладировать корректность их отбора.
При этом дополнительно после отбора API/событий и ответа от LLM мы сопоставляем отобранные API/события с задокументированными. Если в документации такие API/события мы не находим, то тест далее не генерируется.
2) Наш Groovy-сервис, который запускает сгенерированные моделью тесты, включает в себя обертки для осуществления REST/асинхронных запросов. Мы определяем методы (clientPost(), clientGet(),sendEventAndWaitForReply()), которые скрывают детальную реализацию REST/асинхронного взаимодействия. Логика в методах детерминирована.
При обращении к LLM с просьбой составить тест мы передаем системный промпт, в котором четко регламентируем структуру теста с примерами – явно указываем, какие методы разрешено использовать (наши высокоуровневые – clientPost(), clientGet(), sendEventAndWaitForReply()). То есть мы снимаем с модели нагрузку на продумывание детальной реализации отправки POST запроса или взаимодействия с брокером – это мы берем на себя, а модели нужно лишь позвать нужные "кубики".
3) Помимо этого, результаты работы модели выводятся в чат, и пользователь может наблюдать за процессом генерации теста. Пользователю виден тест на каждой итерации генерации, виден лог после запуска теста – при анализе теста он видит какие "кубики" использовались и входные параметры, которые LLM посчитала нужным проставить. После запуска теста в логах он видит результат вызова API/отправки/получения события – выходные параметры выводятся в лог.
Спасибо за внимательность! Вы правы, конфигурация стенда важна. Мы поправили опечатку в статье, тесты проводились на сети 25GbE.
Однако ваш тезис про "упор в сеть" остается актуальным. Тем не менее, тесты релевантны по двум причинам:
1. Эффективность ресурсов (CPU/RAM). Чтобы просто забить сеть до предела S3 Архипелаг использовал 28% доступной мощности. Это означает, что у нас остается большой запас вычислительной мощности, который можно реализовать, использовав более быструю сеть.
2. Тесты на IOPS (мелкие файлы) и LIST-операции (метаданные) упираются не в пропускную способность сети, а в архитектуру хранения и работу с диском. Там сеть не является "узким горлышком", и именно там S3 Архипелаг демонстрирует кратный отрыв от конкурентов (в 2-3 раза быстрее).
Тест показывает главное: мы получаем максимум из доступного канала с минимальными затратами ресурсов сервера.
При чтении система проверяет контрольные суммы. Если обнаружено повреждение, а данные реплицированы, запрос перенаправляется на здоровую копию - клиент получает корректные данные.
Для борьбы с последствиями появления "битого" участка мы настроили мониторинг алертов и периодическую проверку целостности томов. При обнаружении bit rot поврежденные тома восстанавливаются из здоровых реплик.
В планах полностью автоматизировать этот процесс, чтобы система сама восстанавливала поврежденные блоки в фоновом режиме.
Для полноценной работы базы MS SQL Server в Digital Q.DataBase ее нужно предварительно перенести (смигрировать) в собственный формат Digital Q.DataBase.
В первую очередь, данную функциональность выбирают клиенты, которым нужно решение из РРПО, сертифицированное ФСТЭК, или поддержка вендора - лидера рынка
Данное решение реализовано для работы с временными таблицами, содержащий key-value наполнение.
500 ГБ - это объем для знакомства с продуктом, тестовых стендов или микросервисов, которым нужен именно S3 API.
Для серьезных хранилищ, конечно, мало.
Если для тестирования нашего продукта требуется увеличенный лимит на объем данных, то мы готовы обсуждать изменение этого ограничения с заказчиком.
В SeaweedFS есть AD и Kerberos, но сейчас чаще нужен OAuth2/OIDC. Мы добавили нативную интеграцию UI с Keycloak, чтобы избежать самописных прокси.
При росте данных PostgreSQL не справляется, и нужен TiKV. Мы сделали бесшовную миграцию: в Helm-чарте меняется тип бекенда, данные переезжают на TiKV автоматически без даунтайма.
Исправили критичный для нас баг с рекурсивным удалением в Apache Spark (позже фикс появился в апстриме).
Доработали Helm-чарты: добавили поддержку Istio и исправили чарты CSI Driver для корректной работы persistence-слоя в K8s.
Также локализовали UI на русский язык и выполнили другие доработки.
В части поддержки мы даем SLA и снимаем санкционные риски. Контроль санкционных рисков реализован на архитектурном уровне и в процессах жизненного цикла разработки и сборки продукта.
Два часа на покраску кнопки – это действительно значительный объем времени, если смотреть на него изолированно. Однако ключевой результат не в самой цифре, а в том, что мы наконец получили объективную картину. Сформировав общую базу по нормативам и сопоставив плановые показатели с фактическими затратами, мы выявили системные закономерности.
Если кратко: мы подтвердили, что покраска простой кнопки за 2 часа – адекватный норматив. Но анализ отчетности до внедрения этого ориентира показал разброс от 3 до 10 часов на ту же операцию. После приведения к единому нормативу фактическое время сократилось в среднем вдвое. Реальность, разумеется, сложнее, но суть передана верно.
По поводу спринтов и нормативов. Спринты – не универсальный инструмент. Мы говорим о производственных командах, чья задача – создавать инкремент. Для них спринты работают. Для остальных процессов нормативы выполняют другую функцию: они задают разумные границы, помогают выделить время и объективно оценить сложность. Также задача имеет тенденцию заполнять все отведенное ей время, и норматив здесь выступает в качестве ориентира.
Об инженерах. Инженеры для нас, конечно же, ценны в первую очередь как люди. Они точно не просто «трудовая функция» и не единица в формуле. Имели в виду, что норматив – это инструмент, позволяющий снять субъективные колебания. Не попасть в норматив – абсолютно нормально, и за этим часто стоят объективные, уважаемые нами причины.
О сравнение команд. Норматив – это линейка. Впервые мы можем поставить команды в равные условия и корректно сравнить их эффективность. Да, команда может временно находиться в другом процессе – отчеты это покажут, и такое отставание всегда объяснимо. Есть спринты, в которых команда стабилизирует продукт, по сути исправляя ошибки и не создавая новых функций. Но если ситуация повторяется 7 спринтов подряд – это уже системный маркер. Скорее всего, команде нужна помощь, и теперь мы можем это увидеть раньше, чем накопятся проблемы.
Норматив учитывает ИИ или ИИ учитывает норматив. Умеем и то и то.
ИИ не заменил разработчиков, а стал им помощником. Эта помощь может выражаться как в скорости решения рутинных задач, так и в качестве при решении сложных задач.
Когда агент гарантированно закроет какой-то фронт работ, безусловно, это скажется на трудоемкости типовых работ в сторону уменьшения.
Что касается корректности выбора норматива и сложности на задаче при оценке, то да, ИИ это проверяет и формирует определенный отчет для владельцев этой практики для понимания, что можно еще улучшить, чтобы команды выбирали корректные типовые работы и сложности при оценке трудоемкости задач.
1) Нет, конкретное действие делать нет необходимости. Успешный тест выкладывается автоматически в репо продукта.
2) В тесте может быть вызов API или отправка\получения события, на каждый тест у нас отображаются логи в диалоге с ИИ, пользователь их видит.
1) У нас развернуто внутри контура Диасофт.
2) На данный момент мы используем языковую модель Qwen3-30B-A3B, развернутую через vLLM. Это трансформерная LLM семейства Qwen (аналог GPT-подобных моделей), распространяемая с открытыми весами под лицензией Apache 2.0, что допускает коммерческое использование, модификацию и развертывание в инфраструктуре заказчика.
3) Тесты генерируются тестировщиком по мере необходимости при добавлении нового функционала. Мы автоматизировали процесс тестирования – если ранее при добавлении функционала пользователь писал тест каждый раз под новый функционал, теперь ему необходимо под этот новый функционал описать сценарий, а тест за него напишет LLM. Насчет анализа нового кода агентом напрямую без описания сценария пользователем, тут вопрос не в логичности, а в ограничении ресурсов. Анализ кодовой базы – процесс непростой, для этого необходимо использовать модели с сильно бОльшим контекстом.
В дальнейшем планируется развитие агента – одним из направлений развития как раз и является генерация пользовательского сценария по измененному коду с помощью LLM. В этом случае дальнейшая цепочка генерации теста не изменится, поменяется лишь способ получения исходного сценария (тест-кейса).
4) QA должен понимать какой функционал тестируется, какие входные и выходные данные для тестирования функционала должны использоваться. Глубокое понимание архитектуры проекта ему не требуется.
Пользователь, который подает на вход сценарий, подает его осознано, т.е. знает и понимает какие эндпоинты и для чего используются.
В качестве примера рассмотрим следующий кейс.
Пользователь задает сценарий в терминологии бизнеса: "Добавь тип суммы, поменяй у него название, удали его, проверь, что его больше нет #apionly"
ИИ как раз отбирает необходимые эндпоинты:
POST /agreement-amount-type
PUT / agreement-amount-type/{agreementAmountTypeld}
DELETE / agreement-amount-type/{agreementAmountTypeld}
GET / agreement-amount-types
Затем происходит генерация теста.
Если какие-то параметры не будут учтены в одном из вариантов автотестов, то тест не будет пройден, ИИ получит ошибку, прочитает ее и исправит тест относительно текста ошибки.
5) В промте у нас описаны правила построения автотеста, а также в некоторых инструкциях мы явно указываем, как делать не надо. Также от чуши спасает абстрагирование от деталей вызова API/события за счет использования заготовленных методов (определенных в Groovy-сервисе для запуска тестов). То есть LLM не нужно знать, как подключаться к брокеру или как звать API по REST. LLM использует заготовленные нами "кубики" и понимает, что в случае отбора API POST/api/request надо в тесте использовать метод clientPost(), а в случае отправки события и ожидания ответа – sendEventAndWaitForReply().
Дополнительно после отбора API/событий мы проверяем их наличие в документации. Если это результат фантазий LLM, то тест генерироваться не будет. Если LLM сильно фантазирует при генерации теста, то мы это пресекаем проверкой валидности теста при запуске – откровенная «чушь» успехом при запуске не завершится.
Защита от логических ошибок в тестах происходит на нескольких уровнях:
1) После указания пользовательского сценария (заявленного тест-кейса) сначала происходит отбор API/событий по семантической близости с заявленным тест-кейсом. После этого отобранные API/события явно выводятся пользователю, и он может проваладировать корректность их отбора.
При этом дополнительно после отбора API/событий и ответа от LLM мы сопоставляем отобранные API/события с задокументированными. Если в документации такие API/события мы не находим, то тест далее не генерируется.
2) Наш Groovy-сервис, который запускает сгенерированные моделью тесты, включает в себя обертки для осуществления REST/асинхронных запросов. Мы определяем методы (clientPost(), clientGet(),sendEventAndWaitForReply()), которые скрывают детальную реализацию REST/асинхронного взаимодействия. Логика в методах детерминирована.
При обращении к LLM с просьбой составить тест мы передаем системный промпт, в котором четко регламентируем структуру теста с примерами – явно указываем, какие методы разрешено использовать (наши высокоуровневые – clientPost(), clientGet(), sendEventAndWaitForReply()). То есть мы снимаем с модели нагрузку на продумывание детальной реализации отправки POST запроса или взаимодействия с брокером – это мы берем на себя, а модели нужно лишь позвать нужные "кубики".
3) Помимо этого, результаты работы модели выводятся в чат, и пользователь может наблюдать за процессом генерации теста. Пользователю виден тест на каждой итерации генерации, виден лог после запуска теста – при анализе теста он видит какие "кубики" использовались и входные параметры, которые LLM посчитала нужным проставить. После запуска теста в логах он видит результат вызова API/отправки/получения события – выходные параметры выводятся в лог.
Спасибо за внимательность! Вы правы, конфигурация стенда важна. Мы поправили опечатку в статье, тесты проводились на сети 25GbE.
Однако ваш тезис про "упор в сеть" остается актуальным. Тем не менее, тесты релевантны по двум причинам:
1. Эффективность ресурсов (CPU/RAM). Чтобы просто забить сеть до предела S3 Архипелаг использовал 28% доступной мощности. Это означает, что у нас остается большой запас вычислительной мощности, который можно реализовать, использовав более быструю сеть.
2. Тесты на IOPS (мелкие файлы) и LIST-операции (метаданные) упираются не в пропускную способность сети, а в архитектуру хранения и работу с диском. Там сеть не является "узким горлышком", и именно там S3 Архипелаг демонстрирует кратный отрыв от конкурентов (в 2-3 раза быстрее).
Тест показывает главное: мы получаем максимум из доступного канала с минимальными затратами ресурсов сервера.
При чтении система проверяет контрольные суммы. Если обнаружено повреждение, а данные реплицированы, запрос перенаправляется на здоровую копию - клиент получает корректные данные.
Для борьбы с последствиями появления "битого" участка мы настроили мониторинг алертов и периодическую проверку целостности томов. При обнаружении bit rot поврежденные тома восстанавливаются из здоровых реплик.
В планах полностью автоматизировать этот процесс, чтобы система сама восстанавливала поврежденные блоки в фоновом режиме.
Отправьте, пожалуйста, ваш вопрос в службу поддержки по e-mail: supportqdb@diasoft.ru, и вам помогут разобраться.
Для полноценной работы базы MS SQL Server в Digital Q.DataBase ее нужно предварительно перенести (смигрировать) в собственный формат Digital Q.DataBase.
В первую очередь, данную функциональность выбирают клиенты, которым нужно решение из РРПО, сертифицированное ФСТЭК, или поддержка вендора - лидера рынка
Данное решение реализовано для работы с временными таблицами, содержащий key-value наполнение.