Привет! Я Алиса, DevOps-инженер в KTS.

В этой статье я расскажу о том, как мы настроили автоматическое обновление драйверов NVIDIA для работы с Jupyter и ML-стеком в управляемом кластере.

Проблема: когда контейнеры и ML-библиотеки обновляются чаще, чем системные образы GPU-нод, версия драйвера быстро перестает соответствовать версии CUDA в контейнере. В итоге при вызове  nvidia-smi возвращает ошибку Driver/library version mismatch, а CUDA просто не видит драйвер на хосте.

Нам нужно было обновить Jupyter с ML-стеком, зависящим от CUDA. Как следствие, встал вопрос обновления драйверов NVIDIA на GPU-нодах. Можно было выполнять его руками на каждой ноде, но такой способ нам не подходил, и мы выбрали автоматизацию, которой и посвящена моя статья. Ниже я разберу и ручное обновление, и варианты автоматизации, а также объясню, как мы решали проблему конфликта GPU Operator с предустановленными драйверами.

Всем привет! Я Алексей Босенко, DevOps-инженер в компании KTS. В этой статье я покажу, как комплексно настроить быструю и эффективную сборку проектов в Kubernetes с использованием BuildKit, которая учитывает не только производительность, но и стоимость ресурсов.

Под этой громкой фразой я подразумеваю целый комплекс решений: как создать и настроить экономичный кластер Kubernetes для сборок (ведь цена вопроса всегда важна), как настроить GitLab Runners и как сделать эффективное масштабирование сборок. Особый акцент будет на том, почему мы выбрали BuildKit, какие варианты использования он предлагает, и как непосредственно настроить один из них.

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

Привет! Я Тимур, разработчик мобильных приложений в KTS.

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

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

Да, тема довольно холиварная, и в статье я не заявляю, что KMP лучше Flutter’а во всем. Каждая технология хороша под свои задачи. Вместо этого я расскажу о конкретном проекте, на котором KMP оказался более удачным выбором. Также коснусь вопросов архитектуры и миграции Android-приложения на iOS с помощью CMP, а заодно подсвечу подводные камни, с которыми пришлось разбираться в процессе.

Привет! Я Ева, тестировщик в KTS.

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

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

Привет!

Я Таня, фронтенд-разработчик в KTS и студент магистратуры МГТУ им. Баумана. На одном из недавних проектов я работала над интересной фичей — визуальным представлением аудиоданных, a.k.a. звуковой спектрограммой. Казалось бы, штука нехитрая: кто не видел график, прыгающий в такт с музыкой на разных частотах? Он есть в любом секвенсоре, на любом диджейском пульте и даже в динамическом островке последних айфонов.

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

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

Привет! Меня зовут Александр Егоров, я MLOps-инженер в Альфа-Банке, куда попал через проект компании KTS.

За свою карьеру я построил четыре ML-платформы (одна из которых сейчас в Росреестре) и развиваю с командой пятую. Параллельно учусь в ИТМО по направлению «Безопасность искусственного интеллекта».

В этой статье я немного покритикую Airflow и поделюсь нашей историей миграции на связку Argo Workflows и Argo CD. Spoiler alert: технические подробности и результаты в наличии.

Привет. Я Сергей Истомин, DevOps-инженер в KTS.

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

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

Привет!

Меня зовут Валентин, я — руководитель направления тестирования моделей машинного обучения в Альфа-Банке. Моя команда занимается тестированием ML-моделей и модельных сервисов для наших клиентов уже более четырех лет, и более трех из них я погружен в наши процессы QA.

Я попал в Альфу через проект компании KTS, над которым работал раньше, и первое время занимался ручным тестированием. За несколько лет прошел путь от линейного тестировщика до руководителя команды из 8 человек, и в этой статье рассказываю о своем опыте и делюсь советами, которые дал бы самому себе несколько лет назад.

Эта статья будет полезна:

• тем, кто только начинает выстраивать процессы тестирования моделей;
• начинающим тимлидам QA-команд до 10 человек;
• тем, кто просто хочет познакомиться с примером организации QA-процесса с нуля.

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

Привет! Меня зовут Ваня Тришкин, я тестировщик в KTS.

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

Сегодня я не просто опишу панель DevTools, а приведу примеры сценариев, в которых она может понадобиться менеджеру. Заодно для каждого инструмента я дам небольшие упражнения, которые помогут закрепить материал и увереннее пользоваться тулзами на практике.

Привет! Я Рома, бэкендер-питонист в KTS.

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

Привет. Я Дима Рагозин, фронтенд-разработчик в KTS. Эту статью я хочу начать с предыстории.

Полтора года назад на проекте для одного крупного клиента мы получили задачу — ускорить главную страницу. К тому моменту в кодовой базе уже жили два отдельных фронтенд-приложения под две разные платформы — CSR-версия (Client Side Rendering) и SSR‑версия (Server Side Rendering), — а MobX‑сторы все время жизни проекта разрастались вместе с функциональностью.

Каждый новый экран приносил еще один класс (а то и несколько), еще кучу связей, и в какой‑то момент мы стали замечать снижение воспринимаемой скорости приложения, избыточные HTTP‑запросы, сложности с поддерживаемостью и другие проблемы, которые становились критичнее по мере роста проекта. В статье я расскажу о том, как мы шаг за шагом перевели такие сторы на React Query, сократили код вокруг запросов на ≈50 % и практически избавились от повторных GET‑ов. Попутно поведаю о наших граблях и поделюсь советами по миграции.

Привет, мир! Я Виталий, управляю проектами в KTS. Мы разрабатываем IT‑решения для корпораций и стартапов.

В этой статье я расскажу о том, как прошла первая треть девятимесячного курса для CTO от школы менеджмента Стратоплан. Я написал ее для тех, кто:

— взаимодействует с CTO и хочет лучше его понимать (например, тимлиды или другие миддл‑менеджеры);

— строит свой карьерный путь в сторону CTO и хочет разобраться, что ожидается от этой позиции (спойлер — ожидания разнятся в зависимости от вида бизнеса);

— уже стал CTO и хочет провалидировать свой профиль и набор навыков, восполнить пробелы.

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

До внедрения TMS процесс тестирования был довольно локальным — QA и команды внутри проектов самостоятельно определяли насколько плотно покрывать проверками функционал, где и как эти проверки хранить, какой выбирать формат для отчетов по регрессам. Такой подход имеет право на существование, но он не масштабируется, неудобен в случае усиления команды новыми участниками и совершенно непрозрачен для клиентов. Мы решили перейти от подхода «у каждого свое» к централизованной и прозрачной для всех стейкхолдеров системе.

Привет! Я Максим Мялкин, управляющий партнер и руководитель мобильной разработки в KTS.

Сегодня я хочу поделиться историей моего знакомого и бывшего студента Сергея Ракова. Его карьера сложилась довольно необычным образом: от инженера-конструктора в Богородицке он прошел путь до Android-разработчика в Катаре.

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

Также коснулись темы культурных особенностей. Да, заголовок — не кликбейт, в Катаре по-прежнему существуют телесные наказания. Историю о них мы расскажем в конце; забегая вперед, знакомые Сергея поплатились таким образом за пьяное вождение (осуждаем).

Привет! Я Андрей Сташок, бэкенд-разработчик в KTS. В этой статье я расскажу о запуске параллельных тестов через pytest-xdist.

Почему это важно?

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

Я расскажу, как запускать параллельные тесты для реляционной БД PostgreSQL (с драйверами asyncpg и psycopg2) и key-value БД Redis. Для подключения к реляционной БД мы будем использовать SQLAlchemy, а для Redis — библиотеку redis. Кроме того, я рассмотрю, как автоматизировать выполнение миграций при каждом запуске тестов с использованием alembic.

Привет! Я Рома Авдонин, Head of QA в KTS.

На Хабре уже выходили посты о том, как тяжело найти работу QA в 2024–2025 годах, но мало кто взвешивает сразу две позиции — и кандидата, и нанимателя. Я побывал по обе стороны и решил поделиться наблюдениями.

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

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

Мы разрабатываем приложения на KMP еще с 2021 года, а в прошлом году начали экспериментировать с Compose Multiplatform. Вчера JetBrains официально объявили о выходе CMP 1.8.0, c которой поддержка iOS переходит в статус stable. Это важный этап, поскольку теперь CMP можно всерьез рассматривать как основу для кроссплатформенной мобильной разработки.

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

Привет! На связи снова Саша Хренников, руководитель DevOps-юнита в KTS.

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

Spoiler alert: мы оставляем доступ к этому испытанию (и ко всем предыдущим) открытым, чтобы вы могли потренироваться перед будущими челленджами. Если вы еще не пытались решить его, не торопитесь читать разгадку — лучше попробуйте найти ее самостоятельно. Сделать это вы можете в нашем боте.

Для тех же, кому не терпится узнать ответ, продолжаем.

Привет! Я Саша Хренников, руководитель DevOps-юнита в KTS.

На носу День Космонавтики, и в честь праздника мы подготовили новое испытание для DevOps-инженеров. Казалось бы, к полету все готово: приложение рабочее и даже описано в Helm. Вот только при попытке запуска каждый раз возникает ошибка. Сможете ли вы разобраться в конфигурации ArgoCD и выполнить деплой?

Самых быстрых участников испытания мы по традиции наградим нашими фирменными футболками. Итоги испытания мы подведем 17 апреля в 19:00, до этого момента стенд челленджа будет открыт для участников.

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

Если у вас уже есть MVP и вы даже смогли привлечь первых юзеров, перед вами встает целый ряд интересных задач: нужно разрабатывать новую функциональность, исправлять баги, обрабатывать запросы пользователей и искать способы привлечения новой аудитории. Крупным корпорациям в этом плане неплохо живется — обычно под каждую из таких задач формируется целый отдел. А что делать, если над вашим продуктом работает всего 5-6 человек?

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

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

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