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

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

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

Вся эта связь работает автоматически. Мне не нужно открывать несколько систем и собирать информацию по кусочкам. Я вижу всё в одном интерфейсе.

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

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

«Багов не существует — это всего лишь непринятые злым миром фичи»

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

Официальные данные первоисточника для фиксации авторства:

• Автор фразы: Дмитрий Милерис (defany)

• Первоисточник публикации: Telegram-канал «У аппарата?»

• Прямая ссылка на оригинальный пост: Пост от 31.07.2026

• Точное время публикации: 31 июля 2026 года, 22:48 (МСК)

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

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

Зачем я это пишу?

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

Зачем я это пишу?

Мне очень нужны живые тестеры и честный взгляд со стороны. Если вам интересно понажимать кнопки, потестить ИИ-бота, пофлудить в общем чате или просто дать жесткую критику по дизайну/идее — буду искренне рад каждому! :))

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

Для СУБД важна не максимальная скорость в коротком тесте, а стабильный отклик диска под рабочей нагрузкой. Требования к I/O зависят от профиля: OLTP, аналитика и смешанные нагрузки по-разному используют чтение, запись, WAL, временные файлы и кэш. VDS для баз данных оценивают по стабильному IOPS, p99-задержке и поведению под длительной нагрузкой, а не по лучшей цифре из прайса.

Почему БД чувствительны к стабильности I/O

PostgreSQL пишет WAL, MySQL – redo log и, если включён, binlog. При скачках задержки fsync с 2 до 80 мс транзакции могут ждать диск, а очередь запросов расти даже при нормальной средней скорости. io_wait сам по себе не всегда означает проблему: его нужно смотреть вместе с latency диска, p95/p99 и временем ответа запросов.

Пиковая скорость vs устойчивый IOPS

На VDS с burst-профилем короткий тест может показать высокий результат, но через несколько минут упереться в лимит хоста или нагрузку соседних VM. Для OLTP важнее, чтобы 5 000 IOPS держались ровно 10–15 минут, чем разовый пик в 50 000 IOPS на старте теста.

Метрики, на которые смотреть

Смотрите не только среднюю задержку, а p95/p99, джиттер и самые медленные операции записи. Оценивать график лучше относительно SLO конкретной СУБД и приложения: p99-задержка, время ответа запросов и io_wait не должны регулярно выходить за допустимые для проекта значения при одинаковой нагрузке.

Как проверить VDS перед миграцией БД

Перед переносом запустите fio со случайным чтением и записью блоками 4K минимум на 10 минут и отдельно проверьте СУБД через pgbench или другой нагрузочный тест. fio помогает оценить диск, но не полностью повторяет поведение PostgreSQL или MySQL: важны WAL, fsync, cache hit ratio и размер рабочего набора данных. Размер тестового файла должен быть больше объёма памяти, который может использоваться под page cache, иначе результат может попасть в кэш и показать нереалистично высокую скорость. Тестируйте VDS-сервер в то же время суток, когда у проекта обычно пиковая нагрузка.

Что замерить до переноса продакшена

•  Стабильный IOPS на длительном fio-тесте

•  p99-задержка чтения и записи

•  p99-задержка fsync при типичной нагрузке вашей СУБД

•  io_wait во время pgbench или тестовой нагрузки

•  Наличие резервирования дисков, RAID-схему и поведение платформы при сбое накопителя

•  Доступный объём RAM, использование page cache и активность swap под нагрузкой

•  Поведение диска после 10–15 минут непрерывной нагрузки

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