Привет! Меня зовут Александр Петровский, я инженер в DINS. Я работаю в команде, которая участвует в разработке сервисов облачной телефонии и видеоконференций. Каждый из них состоит из большого количества микросервисов.

Когда мы мигрировали один из наших микросервисов с CentOS 7 с ядром 4.19 на Oracle Linux 7 с ядром 5.4, мы заметили рост утилизации процессора на наших stress/performance-тестах. В статье я расскажу, как мы исследовали причины роста утилизации процессора сначала в user-space, а потом и в kernel-space и о том, к какому результату это нас привело.

Привет, Хабр. Меня зовут Макс. Я специализируюсь на реконструкции и развитии процессов. Сегодняшняя история про баги. Не баги вообще, а про вполне конкретную их категорию.

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

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

В сообществе фанатов текстового редактора Neovim произошло знаменательное событие — вышла версия 0.5, в которой появилось большое количество нововведений:

• встроенная поддержка языка Lua;
• экспериментальная поддержка treesitter;
• и, наконец, встроенный LSP клиент, позволяющий сделать из простого текстового редактора достойного соперника IDE!

Neovim — это модальный редактор, форк редактора Vim, который ставит своей целью улучшение пользовательского опыта при работе с Vim: «Neovim is built for users who want the good parts of Vim, and more».

Мне нравится Neovim своей гибкостью, благодаря которой его можно превратить в очень мощный инструмент редактирования не только текста, но и кода. Как scala-разработчику мне интересно испытать новый встроенный LSP клиент в применении к любимому языку программирования. В отличие от VSCode и даже Vim + CoC настройка LSP клиента в Neovim несколько более сложная, но при этом крайне гибкая. Данная статья — краткое руководство по настройке Neovim для работы со Scala и краткий обзор возможностей, которые дает связка Neovim + Metals.

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

• что-то из следующего списка хорошо знакомо: Grafana, InfluxDB, Prometheus, Zabbix или другая система мониторинга с похожими идеями;
• вы не эксперт/профессионал/уверенный миддл в различных типах отображения временных рядов и матстатистике (в противном случае для вас, весьма вероятно, будет скучновато);
• есть желание взглянуть на некоторые аспекты «под микроскопом».

Если вы решили, что условия выше соблюдены, добро пожаловать под кат.

Привет, Хабр! Меня зовут Раиса. Я работаю в компании DINS старшим инженером по нагрузочному тестированию. Сегодня я хочу поговорить об энваройнментах. Ни для кого не секрет, что энвайронмент (environment) — это основная рабочая площадка тестировщика. Если у программиста — это любимая IDE, то у тестировщика — милый и родной энвайронмент.

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

Артём Ерошенко — CPO и сооснователь Qameta Software. Он преподает тестирование, хостит подкаст «Айтишники», делает доклады в IT-сообществе, а 1 декабря во второй раз станет ведущим QA Meeting Point. Артём рассказал, зачем делиться знаниями и почему он не верит в будущее ручного тестирование.

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

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

Привет, хабровчане!

Меня зовут Нурыев Асхат, я ведущий инженер по автоматизации в DINS. За время работы в компании я участвовал в решении множества сложных задач. В этой статье я поделюсь историей улучшения процесса и автоматизации тестирования высокой доступности и восстановления после отказа подсистемы API, состоящей из множества компонент. 

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

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

Началось все как обычно: одним прекрасным утром ко мне подошел менеджер и спросил, не хочу ли я заняться одной интересной задачей. К тому времени у меня уже был опыт организации перфоманс-тестирования и вообще улучшения процессов в команде, так что я, конечно, согласился. А когда он объяснил, чем именно предстоит заняться, глаза у меня загорелись!  Только подумайте: построить HA тестирование целой подсистемы —  есть где развернуться, проявить изобретательность!

Привет, Хабр! В этой статье я расскажу о Git hooks и о том, как они могут помочь с некоторыми насущными кейсами организации создания commit’ов и commit message. Пост основан на реальном опыте из моей практики: как я упрощал то, что всем надоело делать руками. Я уверен, что хуки могут оказаться полезны почти каждому разработчику. Ведь все мы пишем в сообщении коммита чуть больше, чем «fixed what was broken», верно?

Меня зовут Роман Горбатенко, я Java-разработчик в компании DINS, на момент написания текста тружусь в команде Contact Center. Занимаюсь разработкой больше 3-х лет и прошел путь от личинки стажера до middle разработчика. Считаю Git одним из самых полезных инструментов разработчика. Многие не используют его возможности на полную, возможно, мне удастся это немного исправить.

Привет, Хабр! Меня зовут Илья Селицер. В DINS мы участвуем в разработке продукта для UCaaS-провайдера RingCentral, которая объединяет много функций — от звонков и факса до корпоративного мессенджера и видеоконференций. Я, среди прочего, отвечаю за качество этого сервиса. В повседневной практике мне постоянно приходится анализировать взаимодействие различных сетевых элементов, которые участвуют в предоставлении той или иной услуги абонентам.

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

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

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

REST Assured — DSL для тестирования REST-сервисов, который встраивается в тесты на Java. Это решение появилось более девяти лет назад и стало популярным из-за своей простоты и удобного функционала.

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

Эта статья — о таких неявных особенностях REST Assured. Их нужно учитывать, если есть шанс, что количество тестов в проекте будет быстро увеличиваться — чтобы потом не пришлось переписывать.