При чём тут я

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

Я ещё прожжёный линуксоид, пересел на него довольно давно, потому что хотел полностью контролировать систему. С табами на Linux в принципе всё нормально. Есть TuxGuitar, он работает, открывает Guitar Pro, умеет проигрывать и редактировать табы. Но мне всё это категорически не нравилось. Не нравился интерфейс, не нравилось, что нужно открывать с десяток вкладок, чтобы оно наконец заработало как надо.

Мне хотелось простого человеческого «сел и играешь». И интерфейс приятный, а не миллиард иконок.

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

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

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

Зачем ещё один Guitar Pro?

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

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

Кто-то ушёл в DAW просто потому, что там «звук был лучше». Часто ругали подписки – без них во многих приложениях нет базовых вещей, например лупа, базовый операций копипасты и т.п.

И всё это – лишь малая часть жалоб, которые мы услышали от музыкантов.

Я изначально хотел делать продукт в подходе community driven development; интервью позволили реализовать задумку ещё до выхода MVP.
В итоге мы пересмотрели приоритет фич приложения и включили часть новых. Например, преподаватели поголовно просили функцию записи гитары прямо внутри приложения, а у нас с командой даже мысли про это не было. В итоге включили в лист фич.

Музыкантами для музыкантов

Нас пятеро, и мы все – музыканты. Кто-то пришёл потому, что я искал людей, которые понимают музыкальную часть продукта, а кто-то вообще присоединился случайно, потому что понравилась идея. С февраля за полгода мы довели Tabify до MVP.

Что Tabify умеет уже сейчас

Сейчас Tabify – это десктоп-приложение для Windows (да, ирония — сам на Linux, а Tabify пока только под Windows, macOS и Linux доделываем), которое собирает разбор музыки в одном месте: он поддерживает табы, зацикливание, замедление темпа. В нём можно отключать лишние треки, чтобы оставить только свой инструмент. На грифе визуализируется аппликатура, есть смена строя и аппликатура это учитывает.

А ещё есть мультитрек: гитара, бас, ударные, клавиши — импорт из GP-файлов, поддержка VST, микшер, метроном.

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

Без отдельной DAW, плеера, пяти окон, между которыми приходится постоянно переключаться.

В MVP-версии мы ещё сделали встроенный каталог партитур, их там примерно 75 000, планируем пополнять.

В общем, если ты играешь по табам, разбираешь каверы или сидишь в Guitar Pro и задолбался от синтетического звука – Tabify для тебя.

Мы открыли бесплатную бету

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

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

Поэтому приглашаю на нашу бету. Ссылку скину в комментах – пост всё-таки не про рекламу, а про просьбу об обратной связи.

Если ты гитарист – буду рад увидеть среди первых пользователей.

А если ты тоже музыкант, но не гитарист – расскажи, каким софтом пользуешься и чего в нём не хватает.

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

Получилось у нас или нет – решать вам, жду комментов.

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

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

Астра, вы там в адеквате вообще? Какая еще нахер ошибка? что вы там пытались воспроизвести - отправку письма и проверку на моем ящике? ))

Как проверить VPS-сервер, если API по какой-то причине отвечает дольше, а список процессов не объясняет задержку? Нужно поймать сам симптом и одновременно записать top, vmstat, iostat -x и ss. Эти данные покажут вам, где образовалась очередь: у CPU, памяти, диска или сокета. Такой сбор подходит для первичной диагностики Linux-сервера под прикладной нагрузкой, но без истории метрик и данных приложения не даёт точную причину сбоя. Поэтому проверку VPS-сервера нельзя сводить к одной команде.

Какие четыре команды сначала запустить на медленном сервере?

Для начала запустите top, интервальные vmstat и iostat -x, а ss повторяйте циклом. Начните запись до воспроизведения замедления и сохраните время каждого среза. Команды помогут выбрать между CPU, памятью, диском и сетью, но вывод нужно сопоставить с метриками приложения и проверить повторным запуском.

Сначала зафиксировать, когда и как сервер замедляется

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

На образе без systemd стоит отдельно проверить службу синхронизации времени.

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

Проверить процессы, CPU и память в одном срезе

Данные интерактивного top пропадут после закрытия терминала, а набор полей зависит от настроек пользователя. Пакетный режим -b печатает срезы обычным текстом, без перерисовки экрана, поэтому вывод можно перенаправить в файл. Ключи описаны в руководстве procps-ng. Два запуска ниже сортируют процессы по CPU и памяти, а системная сводка остаётся в обоих логах.

На вопрос, как проверить скорость VPS, один список процессов не ответит. us показывает время пользовательского кода, sy – работу ядра, wa – простой CPU при незавершённом I/O, st – время, которое гипервизор не предоставил vCPU. Высокий load average не доказывает нехватку CPU, так как Linux учитывает готовые к выполнению задачи и состояние непрерываемого ожидания. Поэтому сопоставляйте загрузку ядер с работающими процессами и состоянием D. Тот же срез закрывает и память: судить о ней по free нельзя, кеш освобождается по мере необходимости.

Увидеть очередь CPU, swap и системную динамику

vmstat сводит в одну строку процессы, память, swap, I/O и CPU. Команда пишет 13 строк с шагом 5 секунд. Первая содержит средние значения с момента загрузки, а текущий эпизод отражают следующие строки.

r показывает готовые к выполнению задачи, b – задачи в непрерываемом ожидании. Очередь r выше числа vCPU вместе с высоким us или sy поддерживает мысль о нехватке CPU. si и so показывают обмен со swap, а не его занятый объём. При включённом swap стабильно ненулевые si/so, дисковая активность и задержка указывают на подкачку. Без swap нулевые значения ни о чём не говорят, здесь нужны MemAvailable, OOM-события и /proc/pressure/memory.

Как отличить проблему CPU, памяти, диска или сети?

Снимайте показатели в одном окне: очередь r и загрузку CPU, обмен со swap, r_await, w_await и очередь диска, повторные передачи и очереди сокетов. Один всплеск не определяет узкое место. Нужны замедление приложения и второй сигнал того же ресурса в соседнем логе.

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

Проверить очередь и задержку конкретного диска

Расширенный режим iostat снимает статистику по блочным устройствам. Ключ -y пропускает отчёт со средними с момента загрузки, -z скрывает неактивные устройства, -t добавляет время. В Debian и Ubuntu утилита входит в sysstat. Установить пакет лучше до диагностики, а не во время короткого сбоя.

Когда диагностика медленного сервера приводит к дисковой ветке, сначала найдите устройство проблемного пути. r/s и w/s показывают операции, rkB/s и wkB/s – поток данных, aqu-sz – среднюю очередь. По описанию sysstat, r_await и w_await включают очередь и обслуживание запроса. Сравнивайте r_await и w_await с задержкой приложения и профилем нагрузки.

%util, близкий к 100%, показывает насыщение устройства с последовательным обслуживанием. Для NVMe, RAID и других параллельных устройств показатель не показывает предел производительности. На VPS видимый диск может скрывать хранилище хоста. Не суммируйте строки диска, раздела и device mapper: одна операция учитывается на нескольких уровнях.

Найти переполненные очереди, retransmits и состояние сокетов

ss не имеет интервального режима, поэтому скрипт ниже запускает его циклом. -n отключает разрешение имён, -a включает все сокеты, -p показывает процесс, -i – TCP-данные. Без root сведения о чужих процессах могут отсутствовать.

Чтобы понять, как проверить скорость VPS-сервера со стороны сети, различайте слушающие и установленные сокеты. У установленного соединения Recv-Q показывает непрочитанные байты, Send-Q – неподтверждённые данные. У слушающего сокета поля показывают текущую и предельную очередь подключений. Её рост у одного процесса указывает, что он может не успевать принимать соединения.

В TCP-информации ищите retransmits, RTT и RTO. Повторная передача означает, что отправитель не получил пригодное подтверждение вовремя. Причинами могут быть потеря, задержка, переупорядочивание пакетов или ложный тайм-аут. Точную сторону проблемы счётчик не определяет. Много TIME-WAIT не считается ошибкой без исчерпания локальных портов. Ключи описаны в руководстве iproute2.

Пороги для RTT, retransmits и очередей у каждого сервиса свои: эталоном служит ваш же базовый интервал без замедления. Скрипт ниже собирает такой пакет за одно окно, после того как вы опишете нагрузку в LOAD_DESC.

Свести четыре вывода в дерево решений

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

1. CPU: r устойчиво выше числа vCPU, а top показывает занятые ядра. При высоком wa сначала проверьте диск.

2. Память: при включённом swap растут si/so и задержка. Без swap нужны MemAvailable, OOM-события и PSI.

3. Диск: растут r_await, w_await или aqu-sz, а vmstat показывает задачи b либо top – состояние D.

4. Сеть или сокет: одновременно растут RTT, retransmits либо очереди сокетов и ухудшаются latency или error rate.

Смешанная картина не означает несколько разных причин. Медленная запись увеличивает число задач в состоянии D; рабочие процессы перестают принимать запросы, и растёт очередь соединений. В такой последовательности дисковая задержка выглядит первичным сигналом, а очередь сокета – следствием. До проверки это лишь предположение.

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

5. Версию ОС и утилит, часовой пояс, начало симптома и длительность выборки.

6. Полные команды и сырые интервальные логи top, vmstat, iostat -x и ss.

7. Описание нагрузки, endpoint или задачу, latency, throughput, error rate и базовый интервал.

Эти интервалы должны перекрывать один эпизод: разновременные логи в причинную цепочку не сводятся.

Проверить, отвечает ли ресурсная гипотеза на симптом

Системный сигнал нужно связать с сервисом. Сопоставьте по времени p50, p95 и p99 latency, throughput и error rate. Для очереди заданий подойдут время жизни старейшей задачи и скорость обработки. Рост r_await или w_await без прикладной задержки может относиться к другому диску. Если сервис замедлился без ресурсных сигналов, проверяйте блокировки, внешние зависимости и DNS.

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

Гипотеза должна предсказывать результат. Если CPU занят фоновой задачей, её ограничение должно уменьшить r и задержку сервиса. При дисковой очереди уменьшение интенсивности тестовой записи должно снизить w_await. Если прогноз не сбылся, зафиксируйте результат и проверьте другую ветку.

Оформить короткий пакет для следующего шага

Передавайте каталог с логами и коротким README, а не один скриншот top. Укажите автора, дату, конфигурацию VPS, ОС, ядро, команды, нагрузку и границы симптома.

Разделите диагноз на факты, гипотезу и недостающие данные. Факт содержит время и источник, например одновременный рост w_await и p95 одного адреса API. Гипотеза описывает механизм и ожидаемый результат проверки. Термин network latency без маршрута, RTT и стороны измерения остаётся предположением.

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

Хорошая первичная диагностика заканчивается не определением «виновного» ресурса, а предположением с проверяемым прогнозом. Сохранённые команды, временные метки и описание нагрузки дают другому инженеру возможность повторить ход проверки и оспорить вывод. Если нужно решить, как проверить VPS-сервер, сначала определите границы симптома, затем ищите два согласованных сигнала и меняйте только один фактор. Не совпавший прогноз тоже полезен: он исключает ветку и не даёт принять следствие за причину или случайное совпадение за закономерность.

Что происходит

Российские банки и госсервисы переходят на TLS-сертификаты от российских удостоверяющих центров. Chrome, Firefox и Safari этим центрам не доверяют по умолчанию — они не в их списках. Браузер честно говорит: «я этот сертификат не знаю».

Государство предлагает решение: скачай сертификат с Госуслуг и установи в систему. Звучит просто. На практике — вопросы.

Это вообще безопасно?

Когда добавляешь сертификат в Root CA системы — говоришь браузеру «доверяй всему что подписано этим центром». Теоретически владелец сертификата может подписать поддельный сертификат для любого сайта. Это не паранойя — это то как работает PKI.

Большинство людей просто ставят сертификат и не парятся. Но если хочется аккуратнее — есть варианты.

Вариант 1: Отдельный профиль браузера

Создаёшь в Chrome/Edge/Brave отдельный профиль — называешь его «Банки» — и устанавливаешь сертификат только там через настройки браузера, не через систему. Изоляция лучше чем системная установка.

Иконка профиля → Добавить профиль → Настройки → Конфиденциальность → Управление сертификатами.

Лайфхак: если хочешь чтобы ссылки на банки и Госуслуги открывались именно в этом профиле — а не в том который система назначила по умолчанию — вот инструкция: как открыть сайт не в браузере по умолчанию.

Вариант 2: Ruthenium для Android

Буквально на днях вышел браузер Ruthenium — это Chromium для Android с уже вшитым Russian Trusted Root CA. На .ru и .рф сайтах использует расширенный набор сертификатов, на остальных ведёт себя как обычный Chromium.

Главный плюс — не нужно добавлять сертификат в системное хранилище Android, которое вызывает пугающее предупреждение «Сеть может контролироваться». Исходники открыты.

Вариант 3: Поставил и забыл

Если просто хочешь чтобы банк открывался — ставь через скрипт.

Windows (от администратора):

certutil -addstore Root russian_trusted_root_ca.cer
certutil -addstore CA russian_trusted_sub_ca.cer

Linux:

sudo cp russian_trusted_root_ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

На Linux есть нюанс: Firefox, Chromium, Java используют отдельные хранилища. Системной установки может не хватить — придётся добавлять отдельно в каждый браузер.

Важно про актуальный комплект

В августе 2026 комплект обновился. Теперь там не два файла как раньше, а пять: 2 корневых и 3 выпускающих сертификата. Старые инструкции ставят только пару — и потом удивляются почему часть сайтов не открывается.

Скачивай с gosuslugi.ru/crt — там всегда свежая версия.

Если вообще не хочется думать

Яндекс Браузер поддерживает российские сертификаты без ручной установки. Используй его для банков — и забудь про всё что написано выше.