Как WinRAR пережил эпохи и стал легендой? Продается уже более 30 лет (!)
WinRAR, утилита из Челябинска, уже более 30 лет остается на плаву, пережив бесчисленные технологические тренды. Это не случайность, а результат гениальных решений. Вот его код долголетия в нескольких пунктах:
1. Фокус на продукте, а не на бизнесе. Программист Евгений Рошал полностью сосредоточился на коде, в то время как его брат Александр взял на себя все юридические и коммерческие вопросы. Это позволило десятилетиями улучшать продукт, не отвлекаясь на управление.
2. Технология с ключевым преимуществом. Изначально RAR предлагал лучшее сжатие, чем ZIP. Но его «киллер-фича» — записи для восстановления, позволяющие «лечить» поврежденные архивы. Это сделало его незаменимым для надежного хранения данных.
3. Бизнес-модель, победившая пиратство. Легендарный «бесконечный триал» — это не ошибка, а стратегия. Зачем искать взломанную версию с вирусами, если официальная работает бесплатно? Это создало огромную базу из 500+ млн пользователей и сделало формат .rar стандартом. А деньги приносят корпоративные клиенты, которые по закону обязаны покупать лицензии.
Ключевые уроки от WinRAR:
- Решайте «скучные», но вечные задачи. Управление файлами нужно было вчера и будет нужно завтра.
- Сделайте легальный продукт удобнее пиратского. Лучшая защита — превосходный опыт.
- Эволюция важнее революции. Постоянные, продуманные улучшения создают доверие.
- Знайте свою главную силу. Рошал — кодер. Он не лез в продажи, и это спасло продукт.
WinRAR — это мощное напоминание, что долгосрочный успех строится на качестве и доверии, а не на погоне за хайпом.
PS: Пока готовил статью стало интересно и я увлекшись написал целый лонгрид где много интересных фактов и даже есть мерч с winrar 🙂
WinRAR, утилита из Челябинска, уже более 30 лет остается на плаву, пережив бесчисленные технологические тренды. Это не случайность, а результат гениальных решений. Вот его код долголетия в нескольких пунктах:
1. Фокус на продукте, а не на бизнесе. Программист Евгений Рошал полностью сосредоточился на коде, в то время как его брат Александр взял на себя все юридические и коммерческие вопросы. Это позволило десятилетиями улучшать продукт, не отвлекаясь на управление.
2. Технология с ключевым преимуществом. Изначально RAR предлагал лучшее сжатие, чем ZIP. Но его «киллер-фича» — записи для восстановления, позволяющие «лечить» поврежденные архивы. Это сделало его незаменимым для надежного хранения данных.
3. Бизнес-модель, победившая пиратство. Легендарный «бесконечный триал» — это не ошибка, а стратегия. Зачем искать взломанную версию с вирусами, если официальная работает бесплатно? Это создало огромную базу из 500+ млн пользователей и сделало формат .rar стандартом. А деньги приносят корпоративные клиенты, которые по закону обязаны покупать лицензии.
Ключевые уроки от WinRAR:
- Решайте «скучные», но вечные задачи. Управление файлами нужно было вчера и будет нужно завтра.
- Сделайте легальный продукт удобнее пиратского. Лучшая защита — превосходный опыт.
- Эволюция важнее революции. Постоянные, продуманные улучшения создают доверие.
- Знайте свою главную силу. Рошал — кодер. Он не лез в продажи, и это спасло продукт.
WinRAR — это мощное напоминание, что долгосрочный успех строится на качестве и доверии, а не на погоне за хайпом.
PS: Пока готовил статью стало интересно и я увлекшись написал целый лонгрид где много интересных фактов и даже есть мерч с winrar 🙂
👍1
Неприятный инцидент в ЦОД с сервером. Монолит - это риск
На днях мы столкнулись с неприятным инцидентом в ЦОД. Один из двух наших физических серверов подхватил зловреда, похожего на шифровальщика. Несмотря на наличие средств защиты (Касперский), компрометация произошла. 😕
К счастью, инцидент был замечен быстро, и фатальных последствий для данных удалось избежать. Но ситуация заставила меня полностью переосмыслить текущий подход к инфраструктуре.
Главный вывод: Монолит — это зло.
До этого момента ключевые сервисы (1С, MS SQL, RDP-сервер для разработчиков) жили на одной физической машине (Сервер 2). ИБ-инцидент наглядно показал: любая проблема на этом хосте — будь то зловред, неудачное обновление ОС или аппаратный сбой — парализует всю работу компании. Это недопустимый бизнес-риск.
Век виртуализации наступил давно, и наша инфраструктура очевидно от него отстала. Пора это исправлять.
Я, хоть и директор, глубоко погружен в технические процессы компании. Я убежден, что, прежде чем нанимать администратора или подрядчика для построения новой архитектуры, я должен сам хорошо понять другие варианты, риски и лучшие практики. Только так можно сформировать грамотное ТЗ и принять правильное решение.
Что мы имеем (Дано):
1. ЦОД
- 4 "белых" IP-адреса.
- Маршрутизатор Mikrotik для управления трафиком.
- Канал 200 Мбит/с.
2. Сервер 1 (Младший хост)
- 1U Supermicro, 2 x Xeon E5-2650 v3.
- 190 ГБ ОЗУ.
- SSD-накопители (2 x 480 ГБ Intel, 1 x 960 ГБ Intel).
- Ранее использовался для демо-сервера 1С, бэкапов с Сервера 2 и тестовых VM.
3. Сервер 2 (Старший хост)
- 2U HPE 10 Gen, 2 x Intel XEON 6248R.
- 512 ГБ ОЗУ.
- Высокопроизводительные накопители (SAS SSD 1.6 ТБ x2, NVMe PCI-E 3.2 ТБ x1).
- Архивные HDD (SAS 16 ТБ x2).
- Ранее нес на себе всю основную нагрузку: 1С, MS SQL, RDP, GitLab, GitLab-раннеры, тестовые Linux-машины.
Для Сервера 2 уже заказан апгрейд, который добавит еще 256 ГБ ОЗУ, пару быстрых SAS SSD PM1643a по 3.84 ТБ и дополнительный HDD Exos на 18 ТБ.
Первый сервер послабее, второй достаточно не плохой. Использовать их как два изолированных "монолита" — преступление.
Постановка задачи: Новая архитектура
Цель — построить отказоустойчивую, безопасную и масштабируемую инфраструктуру, используя имеющееся железо.
Очевидный путь — виртуализация. Но просто разнести сервисы по VM на одном хосте — это полумера, которая не решает проблему отказа самого хоста.
Поэтому я думаю о построении HA-кластера (High Availability) на базе двух этих серверов.
В идеале при падении физического Сервера 2 все его критичные виртуальные машины (1С, SQL, RDP) должны автоматически перезапуститься на Сервере №1 c минимальным простоем.
Это порождает три главных вопроса, по которым я и хочу посоветоваться с сообществом.
Вопросы к профи
1. Платформа виртуализации
Что выбрать для построения отказоустойчивого кластера на двух нодах?
- Hyper-V: Логичный выбор для Windows. Но как лучше организовать общее хранилище? Использовать Storage Spaces Direct (S2D), связывая две ноды?
- Proxmox: Выглядит очень привлекательно. Open-source, HA-кластер и бэкапы "из коробки", отлично работает с Linux VM (KVM). Насколько он стабилен для высоконагруженных Windows-машин (MS SQL, 1C, RDP)? Кто использует в проде, какие подводные камни?
- VMware vSphere: Вариант серьезно не рассматриваю. Думаю это будет слишком дорого.
2. Сетевая изоляция
Просто разнести сервисы по VM недостаточно. Если зловред попадет в одну VM, он не должен иметь доступ к другим. Я планирую использовать Mikrotik для жесткой сетевой сегментации (VLAN). Какие здесь лучшие практики?
3. Отказоустойчивые бэкапы
Инцидент показал, что бэкапы, лежащие на соседнем сервере в той же сети не панацея. Шифровальщик мог бы добраться и до них. Какой софт используете для бэкапа VM в кластере? Куда лучше всего отправлять третью копию (S3-совместимое облако, съемные диски, другой ЦОД)?
Цель — построить прочный фундамент для ИТ-инфраструктуры, который переживет и сбой железа, и атаку, не останавливая бизнес. Буду благодарен за любой конструктивный совет и обмен реальным опытом.
На днях мы столкнулись с неприятным инцидентом в ЦОД. Один из двух наших физических серверов подхватил зловреда, похожего на шифровальщика. Несмотря на наличие средств защиты (Касперский), компрометация произошла. 😕
К счастью, инцидент был замечен быстро, и фатальных последствий для данных удалось избежать. Но ситуация заставила меня полностью переосмыслить текущий подход к инфраструктуре.
Главный вывод: Монолит — это зло.
До этого момента ключевые сервисы (1С, MS SQL, RDP-сервер для разработчиков) жили на одной физической машине (Сервер 2). ИБ-инцидент наглядно показал: любая проблема на этом хосте — будь то зловред, неудачное обновление ОС или аппаратный сбой — парализует всю работу компании. Это недопустимый бизнес-риск.
Век виртуализации наступил давно, и наша инфраструктура очевидно от него отстала. Пора это исправлять.
Я, хоть и директор, глубоко погружен в технические процессы компании. Я убежден, что, прежде чем нанимать администратора или подрядчика для построения новой архитектуры, я должен сам хорошо понять другие варианты, риски и лучшие практики. Только так можно сформировать грамотное ТЗ и принять правильное решение.
Что мы имеем (Дано):
1. ЦОД
- 4 "белых" IP-адреса.
- Маршрутизатор Mikrotik для управления трафиком.
- Канал 200 Мбит/с.
2. Сервер 1 (Младший хост)
- 1U Supermicro, 2 x Xeon E5-2650 v3.
- 190 ГБ ОЗУ.
- SSD-накопители (2 x 480 ГБ Intel, 1 x 960 ГБ Intel).
- Ранее использовался для демо-сервера 1С, бэкапов с Сервера 2 и тестовых VM.
3. Сервер 2 (Старший хост)
- 2U HPE 10 Gen, 2 x Intel XEON 6248R.
- 512 ГБ ОЗУ.
- Высокопроизводительные накопители (SAS SSD 1.6 ТБ x2, NVMe PCI-E 3.2 ТБ x1).
- Архивные HDD (SAS 16 ТБ x2).
- Ранее нес на себе всю основную нагрузку: 1С, MS SQL, RDP, GitLab, GitLab-раннеры, тестовые Linux-машины.
Для Сервера 2 уже заказан апгрейд, который добавит еще 256 ГБ ОЗУ, пару быстрых SAS SSD PM1643a по 3.84 ТБ и дополнительный HDD Exos на 18 ТБ.
Первый сервер послабее, второй достаточно не плохой. Использовать их как два изолированных "монолита" — преступление.
Постановка задачи: Новая архитектура
Цель — построить отказоустойчивую, безопасную и масштабируемую инфраструктуру, используя имеющееся железо.
Очевидный путь — виртуализация. Но просто разнести сервисы по VM на одном хосте — это полумера, которая не решает проблему отказа самого хоста.
Поэтому я думаю о построении HA-кластера (High Availability) на базе двух этих серверов.
В идеале при падении физического Сервера 2 все его критичные виртуальные машины (1С, SQL, RDP) должны автоматически перезапуститься на Сервере №1 c минимальным простоем.
Это порождает три главных вопроса, по которым я и хочу посоветоваться с сообществом.
Вопросы к профи
1. Платформа виртуализации
Что выбрать для построения отказоустойчивого кластера на двух нодах?
- Hyper-V: Логичный выбор для Windows. Но как лучше организовать общее хранилище? Использовать Storage Spaces Direct (S2D), связывая две ноды?
- Proxmox: Выглядит очень привлекательно. Open-source, HA-кластер и бэкапы "из коробки", отлично работает с Linux VM (KVM). Насколько он стабилен для высоконагруженных Windows-машин (MS SQL, 1C, RDP)? Кто использует в проде, какие подводные камни?
- VMware vSphere: Вариант серьезно не рассматриваю. Думаю это будет слишком дорого.
2. Сетевая изоляция
Просто разнести сервисы по VM недостаточно. Если зловред попадет в одну VM, он не должен иметь доступ к другим. Я планирую использовать Mikrotik для жесткой сетевой сегментации (VLAN). Какие здесь лучшие практики?
3. Отказоустойчивые бэкапы
Инцидент показал, что бэкапы, лежащие на соседнем сервере в той же сети не панацея. Шифровальщик мог бы добраться и до них. Какой софт используете для бэкапа VM в кластере? Куда лучше всего отправлять третью копию (S3-совместимое облако, съемные диски, другой ЦОД)?
Цель — построить прочный фундамент для ИТ-инфраструктуры, который переживет и сбой железа, и атаку, не останавливая бизнес. Буду благодарен за любой конструктивный совет и обмен реальным опытом.
Почему тимлиды выгорают? Ловушка личной эффективности
Уволился тимлид и я задумался. Как так вышло, что толковый парень просто не вывез и «сгорел» (по его словам). Много думал по этому поводу. Как мне вовремя в будущем отследить это состояние у коллег? Да и у себя, чего уж… И вот что я думаю по этому вопросу.
Любому тимлиду / руководителю ИТ чтобы не продалбывать сроки и не забывать про обещанное нужна самоорганизация. Много задач, разные созвоны, куча договоренностей и без системы устоять нельзя.
Сначала все просто: список дел, приоритеты, план на день. Но потом этого становится мало.
Мы идем дальше: используем GTD, строим базы в Notion, считаем время, вводим утренние правила и смотрим итоги недели. Хочется стать идеальной машиной. Машиной, где запрос клиента сразу становится готовым продуктом. Без опозданий, без ошибок, без стресса.
Но у этой гонки есть не хилый такой итог: требовательность к себе растет очень сильно. Вчера хватало сделать 90% дел, а сегодня злит, если не 100%. Вчера забытое обещание было простительно, ну а сегодня это провал. Ошибка — уже не опыт, а плохой показатель (KPI).
Такая гонка убирает радость от проделанной работы. Нет времени для новых идей, для «просто подумать» или отдохнуть. Вы становитесь системой, которая хорошо решает задачи, но прекращает чувствовать. Как робот.
Вот тут и появляется выгорание. ИТ-специалисты чаще сталкиваются с этим. Лишь 15% тимлидов не сталкивались с выгоранием в прошедшем году.
Это не обычная усталость. Это долгое напряжение из-за внутреннего давления. Давления от того, что надо быть лучшим, чтобы все и везде успеть.
Что делать?
У меня нет универсального рецепта, но есть набор принципов, которые помогают мне (и, надеюсь, помогут коллегам) не превратиться в робота.
- Эффективность — это инструмент, а не цель. Твоя ценность как руководителя — не в числе закрытых задач, а во влиянии на команду и продукт.
- Определи «нижнюю границу». Вместо погони за 100% KPI каждый день, определи достаточный минимум. Сделать его — уже победа. Все, что сверху, — бонус, а не обязательство.
- Легализовать ошибки (для себя и коллег). Пропущенный срок — не провал, а повод для анализа системы. Что в процессе пошло не так? Понятно, что здесь речь не о факапах мирового уровня, но все мы люди и все ошибаемся.
- Планируй «ничегонеделание». Сон и отдых — это база. Но еще нужно время в календаре на «подумать» или «погулять без подкаста». Это не потеря времени, это восстановление ресурсов.
- Говори об этом. Признать, что ты перегружен — не слабость. Это дает и команде право не быть «всегда в форме», снижая общее напряжение.
А вы как с этим справляетесь? Сталкивались с тем, что система личной эффективности начинает работать против вас?
#РазборПродукта_КИД #Кейсы_КИД #Истории_КИД
Уволился тимлид и я задумался. Как так вышло, что толковый парень просто не вывез и «сгорел» (по его словам). Много думал по этому поводу. Как мне вовремя в будущем отследить это состояние у коллег? Да и у себя, чего уж… И вот что я думаю по этому вопросу.
Любому тимлиду / руководителю ИТ чтобы не продалбывать сроки и не забывать про обещанное нужна самоорганизация. Много задач, разные созвоны, куча договоренностей и без системы устоять нельзя.
Сначала все просто: список дел, приоритеты, план на день. Но потом этого становится мало.
Мы идем дальше: используем GTD, строим базы в Notion, считаем время, вводим утренние правила и смотрим итоги недели. Хочется стать идеальной машиной. Машиной, где запрос клиента сразу становится готовым продуктом. Без опозданий, без ошибок, без стресса.
Но у этой гонки есть не хилый такой итог: требовательность к себе растет очень сильно. Вчера хватало сделать 90% дел, а сегодня злит, если не 100%. Вчера забытое обещание было простительно, ну а сегодня это провал. Ошибка — уже не опыт, а плохой показатель (KPI).
Такая гонка убирает радость от проделанной работы. Нет времени для новых идей, для «просто подумать» или отдохнуть. Вы становитесь системой, которая хорошо решает задачи, но прекращает чувствовать. Как робот.
Вот тут и появляется выгорание. ИТ-специалисты чаще сталкиваются с этим. Лишь 15% тимлидов не сталкивались с выгоранием в прошедшем году.
Это не обычная усталость. Это долгое напряжение из-за внутреннего давления. Давления от того, что надо быть лучшим, чтобы все и везде успеть.
Что делать?
У меня нет универсального рецепта, но есть набор принципов, которые помогают мне (и, надеюсь, помогут коллегам) не превратиться в робота.
- Эффективность — это инструмент, а не цель. Твоя ценность как руководителя — не в числе закрытых задач, а во влиянии на команду и продукт.
- Определи «нижнюю границу». Вместо погони за 100% KPI каждый день, определи достаточный минимум. Сделать его — уже победа. Все, что сверху, — бонус, а не обязательство.
- Легализовать ошибки (для себя и коллег). Пропущенный срок — не провал, а повод для анализа системы. Что в процессе пошло не так? Понятно, что здесь речь не о факапах мирового уровня, но все мы люди и все ошибаемся.
- Планируй «ничегонеделание». Сон и отдых — это база. Но еще нужно время в календаре на «подумать» или «погулять без подкаста». Это не потеря времени, это восстановление ресурсов.
- Говори об этом. Признать, что ты перегружен — не слабость. Это дает и команде право не быть «всегда в форме», снижая общее напряжение.
А вы как с этим справляетесь? Сталкивались с тем, что система личной эффективности начинает работать против вас?
#РазборПродукта_КИД #Кейсы_КИД #Истории_КИД
🔥3
Часть 1. Как я две недели воевал с Proxmox на сервере HPE и в итоге сдался
Фух. Выпал на две недели из-за проблем с оборудованием. Напомню, что-то вредоносное попало на сервер, и я решил подстраховаться, все переустановить и усовершенствовать инфраструктуру перейдя на виртуализацию, заодно и «прокачать» наш и без того мощный сервер. Хотел применить лучшие практики и использовать виртуализацию. Итак, по порядку:
Дано:
2U HPE 10 Gen DL380, 2 x Intel XEON 6248R. 12 LFF front + 2 SFF rear.
- HP P00924-B21 24×32 ГБ = 768 Гб (P00924-B21) — было 512 Гб, добавил еще 256 Гб
- HPE Smart Array P816i-a SR Gen10
- Высокопроизводительные накопители 2 x SAS SSD Samsung PM1643a 1.92 ТБ
- 2 x SAS SSD Samsung PM1643a 3.84 ТБ — докупил
- 1 x NVMe Samsung PCI-E 3.2 ТБ
- 2 x SSD Intel D3-S4520 SATA III 960 GB
- 2 x SSD Intel D3-S4520 SATA III 480 GB (под систему где будут крутиться виртуалки) — докупил и поставил в два задних пустых отсека.
- Архивные HDD (Seagate Exos X18 SAS 7200 RPM 18 ТБ x2) mirror
Всего 10 дисков SAS/SATA/HDD + 1 NVMe PCI
Очень хотел все настроить на Proxmox, но не вышло, а экспериментировать я не захотел.
До этого никогда всерьез не рассматривал виртуализацию серверов на Linux, но изучил вопрос и мне очень понравился Proxmox с его zfs. План был прост: взять эту среду виртуализации и на ее базе сделать RDP-сервер, поднять сервер 1С, телефонию и т.д. Но проблема пришла из не самого очевидного места, а именно с драйверами.
Как я понял, возникли проблемы с конкретно моим HPE Smart Array P816i-a и драйверами. Не нашел я настроек как перевести массив из Mixed-режима в HBA JBod для zfs, и использовал все на Mixed-режиме без железного RAID. Но тут случилось не самое лучшее. Когда сервер был развернут и я тестировал работу 1С, то все работало. Скорость по замерам производительности тестов Гилева прекрасная — порядка 40 попугаев. Но как-то странно себя начали вести жесткие при работе из ОС Windows. Открываешь проводник и… ничего не происходит. Не открывается! Хотя все работает. В другой виртуальной машине начал пробовать — те же проблемы!
Начал погружаться в вопрос и понял, что все это из-за Mixed-мода, который на сервере HPE я просто не могу отключить. Нет такой настройки! Понял, что, наверное, в этом смысле на эксперименты времени нет, тем более в продуктовой среде. И обойдемся мы виртуализацией на Hyper-V. Да, мне не нравится это. Не очень надежно, на мой взгляд.
Схема работы основных виртуальных машин:
- host — Windows Server только с ролью Hyper-V
- dc01 — контроллер домена и DNS-сервер в одном лице
- rdp — виртуальная машина для RDP с 256 Гб ОЗУ для работы всех сотрудников достаточно.
- srv1c — сервер 1С
Ну и куча виртуальных машин на Linux, типа gitlab (self hosted), сервер телефонии, reverse proxy, тестовые среды и т.п.
Фух. Выпал на две недели из-за проблем с оборудованием. Напомню, что-то вредоносное попало на сервер, и я решил подстраховаться, все переустановить и усовершенствовать инфраструктуру перейдя на виртуализацию, заодно и «прокачать» наш и без того мощный сервер. Хотел применить лучшие практики и использовать виртуализацию. Итак, по порядку:
Дано:
2U HPE 10 Gen DL380, 2 x Intel XEON 6248R. 12 LFF front + 2 SFF rear.
- HP P00924-B21 24×32 ГБ = 768 Гб (P00924-B21) — было 512 Гб, добавил еще 256 Гб
- HPE Smart Array P816i-a SR Gen10
- Высокопроизводительные накопители 2 x SAS SSD Samsung PM1643a 1.92 ТБ
- 2 x SAS SSD Samsung PM1643a 3.84 ТБ — докупил
- 1 x NVMe Samsung PCI-E 3.2 ТБ
- 2 x SSD Intel D3-S4520 SATA III 960 GB
- 2 x SSD Intel D3-S4520 SATA III 480 GB (под систему где будут крутиться виртуалки) — докупил и поставил в два задних пустых отсека.
- Архивные HDD (Seagate Exos X18 SAS 7200 RPM 18 ТБ x2) mirror
Всего 10 дисков SAS/SATA/HDD + 1 NVMe PCI
Очень хотел все настроить на Proxmox, но не вышло, а экспериментировать я не захотел.
До этого никогда всерьез не рассматривал виртуализацию серверов на Linux, но изучил вопрос и мне очень понравился Proxmox с его zfs. План был прост: взять эту среду виртуализации и на ее базе сделать RDP-сервер, поднять сервер 1С, телефонию и т.д. Но проблема пришла из не самого очевидного места, а именно с драйверами.
Как я понял, возникли проблемы с конкретно моим HPE Smart Array P816i-a и драйверами. Не нашел я настроек как перевести массив из Mixed-режима в HBA JBod для zfs, и использовал все на Mixed-режиме без железного RAID. Но тут случилось не самое лучшее. Когда сервер был развернут и я тестировал работу 1С, то все работало. Скорость по замерам производительности тестов Гилева прекрасная — порядка 40 попугаев. Но как-то странно себя начали вести жесткие при работе из ОС Windows. Открываешь проводник и… ничего не происходит. Не открывается! Хотя все работает. В другой виртуальной машине начал пробовать — те же проблемы!
Начал погружаться в вопрос и понял, что все это из-за Mixed-мода, который на сервере HPE я просто не могу отключить. Нет такой настройки! Понял, что, наверное, в этом смысле на эксперименты времени нет, тем более в продуктовой среде. И обойдемся мы виртуализацией на Hyper-V. Да, мне не нравится это. Не очень надежно, на мой взгляд.
Схема работы основных виртуальных машин:
- host — Windows Server только с ролью Hyper-V
- dc01 — контроллер домена и DNS-сервер в одном лице
- rdp — виртуальная машина для RDP с 256 Гб ОЗУ для работы всех сотрудников достаточно.
- srv1c — сервер 1С
Ну и куча виртуальных машин на Linux, типа gitlab (self hosted), сервер телефонии, reverse proxy, тестовые среды и т.п.
Часть 2. Как я две недели воевал с Proxmox на сервере HPE и в итоге сдался
Proxmox
Мое главное разочарование, что не удалось его завести. Прям печаль. 😟
Плюсы
- Мне понравился веб-интерфейс. Очень современно и быстро все работает.
- Мне понравилось как можно прокидывать USB-ключи 1С в Proxmox. Один щелчок и в нужной виртуалке нужная железка. На Windows пришлось покупать отдельно USB Network Gate за $179. Свои нюансы и там и там, но все же proxmox выглядит значительно лучше в этом.
- Понравились шаблоны виртуальных машин. В Hyper-V этого нет и очень зря.
- Теги виртуальных машин. Это очень удобно, если их много!
- ZFS — файловая система для серверов. С контролем записываемых данных и очень быстрая. Сжимает то что пишет на диск и за счет этого уменьшенная нагрузка на дисковую подсистему (но тут повышенное процессорное время, за все надо платить).
- Скорость замеров 1С была выше на Proxmox ~40 баллов теста Гилева, вместо 35 на Windows Hyper-V. Непонятно за счет чего, но это факт. Совсем чуть-чуть быстрее. Важное уточнение: виртуальные машины были одинаковой конфигурации что в Proxmox, что на Hyper-V, оборудование одно и тоже.
- Цена. Это все бесплатно. Есть план с $99 с техподдержкой на год, но и без всего этого все прекрасно работает, а информации в интернете по настройке просто море.
Минусы
- Самое главное для меня оказалась плохая работа с драйверами SCSI в ОС Windows. Не знаю, возможно, это у меня так получилось из-за моих кривых рук, но мне не удалось заставить работать Windows стабильно.
Итог: откат на Hyper-V
Я снес Proxmox и поставил Windows Server. Развернул ту же схему на Hyper-V. Все предсказуемо, все работает. Но…
Замеры 1С на том же железе и ВМ той же конфигурации показали ~35 попугаев (против 40 на Proxmox). Непонятно, почему, но факт.
Пришлось покупать софт для проброса USB.
Интерфейс управления, на мой взгляд, менее удобен.
Выводы (уроки, оплаченные моим временем)
Proxmox + ZFS = только HBA. Никаких «Mixed-mode» и аппаратных RAID (даже если вы их не используете).
HPE Smart Array P816i-a — не лучший выбор для ZFS. У них нет режима HBA (или я не нашел). Для ZFS нужны контроллеры LSI в режиме IT Mode (точно ли?).
То, что я потерял 5 «попугаев» производительности 1С, не так страшно, как нестабильность. Но все равно обидно.
Вот так. Жаль, что не взлетело.
А вы сталкивались с подобной несовместимостью «железячных» контроллеров и софтверных хранилищ типа ZFS? Как решали?
Proxmox
Мое главное разочарование, что не удалось его завести. Прям печаль. 😟
Плюсы
- Мне понравился веб-интерфейс. Очень современно и быстро все работает.
- Мне понравилось как можно прокидывать USB-ключи 1С в Proxmox. Один щелчок и в нужной виртуалке нужная железка. На Windows пришлось покупать отдельно USB Network Gate за $179. Свои нюансы и там и там, но все же proxmox выглядит значительно лучше в этом.
- Понравились шаблоны виртуальных машин. В Hyper-V этого нет и очень зря.
- Теги виртуальных машин. Это очень удобно, если их много!
- ZFS — файловая система для серверов. С контролем записываемых данных и очень быстрая. Сжимает то что пишет на диск и за счет этого уменьшенная нагрузка на дисковую подсистему (но тут повышенное процессорное время, за все надо платить).
- Скорость замеров 1С была выше на Proxmox ~40 баллов теста Гилева, вместо 35 на Windows Hyper-V. Непонятно за счет чего, но это факт. Совсем чуть-чуть быстрее. Важное уточнение: виртуальные машины были одинаковой конфигурации что в Proxmox, что на Hyper-V, оборудование одно и тоже.
- Цена. Это все бесплатно. Есть план с $99 с техподдержкой на год, но и без всего этого все прекрасно работает, а информации в интернете по настройке просто море.
Минусы
- Самое главное для меня оказалась плохая работа с драйверами SCSI в ОС Windows. Не знаю, возможно, это у меня так получилось из-за моих кривых рук, но мне не удалось заставить работать Windows стабильно.
Итог: откат на Hyper-V
Я снес Proxmox и поставил Windows Server. Развернул ту же схему на Hyper-V. Все предсказуемо, все работает. Но…
Замеры 1С на том же железе и ВМ той же конфигурации показали ~35 попугаев (против 40 на Proxmox). Непонятно, почему, но факт.
Пришлось покупать софт для проброса USB.
Интерфейс управления, на мой взгляд, менее удобен.
Выводы (уроки, оплаченные моим временем)
Proxmox + ZFS = только HBA. Никаких «Mixed-mode» и аппаратных RAID (даже если вы их не используете).
HPE Smart Array P816i-a — не лучший выбор для ZFS. У них нет режима HBA (или я не нашел). Для ZFS нужны контроллеры LSI в режиме IT Mode (точно ли?).
То, что я потерял 5 «попугаев» производительности 1С, не так страшно, как нестабильность. Но все равно обидно.
Вот так. Жаль, что не взлетело.
А вы сталкивались с подобной несовместимостью «железячных» контроллеров и софтверных хранилищ типа ZFS? Как решали?
Когда сервер «слабоват». Что делать со старым железом, если жалко выбросить?
В прошлом посте писал о том, что мы все же остановились на Hyper-V для сервера 2U HPE 10 Gen DL380, 2 x Intel XEON 6248R. Но беда в том, что остался еще один сервер 1U который исторически мы называем Альба (ALBA) 🙂 Честно, уже не помню причину почему так называли, но оно закрепилось. Итак характеристики:
Сервер ALBA
Назначение: резервный сервер и выполнение мелких задач (демо-сервер для наших продуктов + бэкапы). Железо:
- 1U Supermicro PIO-618U-T4T+-ST031 X10DRU-i+ 4LFF
- 2 x Xeon E5-2650 v3
- Raid ADAPTEC ASR-6805T, Adaptec AFM-600/100 Kit, 2xHDDTray 3.5-2.5, riser RSC-RR1U-E8
- 190 ГБ ОЗУ.
- SSD/HDD-накопители:
- 2 x SSD SATA Intel S4620 480 ГБ (будет RAID-1 физический)
- 1 x SSD SATA Intel S4620 960 ГБ
- 1 x HD SATA WD Black 7200 RPM 2 ТБ (не серверный).
Беда в том, что он откровенно слабоват…
Вообще, с серверами, которые мы покупали, всегда дело обстояло так, что мы брали б/у сервер (так сильно дешевле), но с новыми SSD/HDD. Ломаться в серверной платформе, по сути, нечему, кроме жестких. Да и состояние серверов, которые брали всегда соответствовали хорошей эксплуатации. Но не об этом речь.
Сейчас основная дилемма состоит в том, что с этим сервером делать? Как показал прошлый опыт, для разработки хорошо иметь 2 сервера. Боевой сломался / заразился — есть возможность оперативно переехать на другой. Пусть он будет медленнее, но работа не остановится. И это плюс.
Но меня очень сильно напрягают два момента. Что этот сервер совсем слабый и в нем катастрофически мало жестких дисков. Всего 4. В отличие от боевого.
Я запланировал небольшой апгрейд этого сервера:
- Поменять процессоры с 2 x Xeon E5-2650 v3 на 2 x Xeon E5-2690 v4. Процессоры уже куплены. Мать поддерживает после обновления прошивки v4.
- Поменять не серверный WD Black для бэкапов на Seagate Exos X18 SAS 7200 RPM 18 ТБ x1. Пусть он будет один, но это серверный HDD. И вроде как он в таком сетапе заведется.
А сейчас я сижу, смотрю на этот сервер и не знаю, а надо ли вообще его апгрейдить?
Просто сейчас начнется:
🐌 А вот RAID-контроллер поддерживает только 6G, а чтобы было 12G нужен другой контроллер. Контроллер 6G (SATA III) напрочь убьет всю производительность быстрых SAS SSD, если я захочу их поставить. Апгрейд ради апгрейда.
🐌 А чтобы было больше места, давай достанем старые жесткие так как они маленькие, и купим большие, но новые (!) Но тут же вопрос: а со старыми что делать? Ведь это серверные, пусть и не такие быстрые, как SAS SSD, но очень надежные жесткие.
🐌 Всего 4 диска. Это значит, что я не смогу собрать ни RAID-10 из 4-х дисков под ВМ (если два уже заняты под систему), ни какой-то емкий RAID-5. Я сразу упираюсь в потолок по IOPS и объему.
🐌 Блин, не нравится мне после большого HPE-сервера, платформа Supermicro.
И самый главный вопрос: а не проще ли купить по дешевке платформу HPE 1U, но побольше? Например, DL360 на 8SFF? Не уверен, что это будет дороже, если начать заниматься апгрейдом Supermicro.
В итоге у меня сейчас есть три варианта, и каждый со своими минусами:
1. Эконом-апгрейд: Ставлю купленные Xeon E5-2690 v4 и новый HDD на 18 ТБ. Плюсы: дешево, уже все куплено. Минусы: дилемма с 4 дисками и медленным контроллером никуда не денется.
2. Максимальный апгрейд: Искать новый RAID-контроллер (12G), менять корзину (если возможно?), выкидывать старые SSD. Плюсы: выжмем максимум. Минусы: цена может приблизиться к покупке нового сервера, а платформа Supermicro мне все равно не нравится.
3. Радикальный: Продать «Альбу» как есть (или по частям) и купить пустую платформу HPE DL360 8SFF, переставив туда процессоры (если совместимы) и память. Плюсы: получаю нужную базу. Минусы: самый дорогой и долгий вариант.
Сломал всю голову, не пойму как лучше поступить…
Коллеги, а кто из вас сталкивался с такой дилеммой по тому, что мало дисков и сервер слабоват? Что можете посоветовать?
В прошлом посте писал о том, что мы все же остановились на Hyper-V для сервера 2U HPE 10 Gen DL380, 2 x Intel XEON 6248R. Но беда в том, что остался еще один сервер 1U который исторически мы называем Альба (ALBA) 🙂 Честно, уже не помню причину почему так называли, но оно закрепилось. Итак характеристики:
Сервер ALBA
Назначение: резервный сервер и выполнение мелких задач (демо-сервер для наших продуктов + бэкапы). Железо:
- 1U Supermicro PIO-618U-T4T+-ST031 X10DRU-i+ 4LFF
- 2 x Xeon E5-2650 v3
- Raid ADAPTEC ASR-6805T, Adaptec AFM-600/100 Kit, 2xHDDTray 3.5-2.5, riser RSC-RR1U-E8
- 190 ГБ ОЗУ.
- SSD/HDD-накопители:
- 2 x SSD SATA Intel S4620 480 ГБ (будет RAID-1 физический)
- 1 x SSD SATA Intel S4620 960 ГБ
- 1 x HD SATA WD Black 7200 RPM 2 ТБ (не серверный).
Беда в том, что он откровенно слабоват…
Вообще, с серверами, которые мы покупали, всегда дело обстояло так, что мы брали б/у сервер (так сильно дешевле), но с новыми SSD/HDD. Ломаться в серверной платформе, по сути, нечему, кроме жестких. Да и состояние серверов, которые брали всегда соответствовали хорошей эксплуатации. Но не об этом речь.
Сейчас основная дилемма состоит в том, что с этим сервером делать? Как показал прошлый опыт, для разработки хорошо иметь 2 сервера. Боевой сломался / заразился — есть возможность оперативно переехать на другой. Пусть он будет медленнее, но работа не остановится. И это плюс.
Но меня очень сильно напрягают два момента. Что этот сервер совсем слабый и в нем катастрофически мало жестких дисков. Всего 4. В отличие от боевого.
Я запланировал небольшой апгрейд этого сервера:
- Поменять процессоры с 2 x Xeon E5-2650 v3 на 2 x Xeon E5-2690 v4. Процессоры уже куплены. Мать поддерживает после обновления прошивки v4.
- Поменять не серверный WD Black для бэкапов на Seagate Exos X18 SAS 7200 RPM 18 ТБ x1. Пусть он будет один, но это серверный HDD. И вроде как он в таком сетапе заведется.
А сейчас я сижу, смотрю на этот сервер и не знаю, а надо ли вообще его апгрейдить?
Просто сейчас начнется:
🐌 А вот RAID-контроллер поддерживает только 6G, а чтобы было 12G нужен другой контроллер. Контроллер 6G (SATA III) напрочь убьет всю производительность быстрых SAS SSD, если я захочу их поставить. Апгрейд ради апгрейда.
🐌 А чтобы было больше места, давай достанем старые жесткие так как они маленькие, и купим большие, но новые (!) Но тут же вопрос: а со старыми что делать? Ведь это серверные, пусть и не такие быстрые, как SAS SSD, но очень надежные жесткие.
🐌 Всего 4 диска. Это значит, что я не смогу собрать ни RAID-10 из 4-х дисков под ВМ (если два уже заняты под систему), ни какой-то емкий RAID-5. Я сразу упираюсь в потолок по IOPS и объему.
🐌 Блин, не нравится мне после большого HPE-сервера, платформа Supermicro.
И самый главный вопрос: а не проще ли купить по дешевке платформу HPE 1U, но побольше? Например, DL360 на 8SFF? Не уверен, что это будет дороже, если начать заниматься апгрейдом Supermicro.
В итоге у меня сейчас есть три варианта, и каждый со своими минусами:
1. Эконом-апгрейд: Ставлю купленные Xeon E5-2690 v4 и новый HDD на 18 ТБ. Плюсы: дешево, уже все куплено. Минусы: дилемма с 4 дисками и медленным контроллером никуда не денется.
2. Максимальный апгрейд: Искать новый RAID-контроллер (12G), менять корзину (если возможно?), выкидывать старые SSD. Плюсы: выжмем максимум. Минусы: цена может приблизиться к покупке нового сервера, а платформа Supermicro мне все равно не нравится.
3. Радикальный: Продать «Альбу» как есть (или по частям) и купить пустую платформу HPE DL360 8SFF, переставив туда процессоры (если совместимы) и память. Плюсы: получаю нужную базу. Минусы: самый дорогой и долгий вариант.
Сломал всю голову, не пойму как лучше поступить…
Коллеги, а кто из вас сталкивался с такой дилеммой по тому, что мало дисков и сервер слабоват? Что можете посоветовать?
1С (в лице юристов) стреляет себе в ногу? Ситуация с forum.mista.ru
В сети всплыла «прекрасная» новость. Популярный ресурс для 1С-ников форум миста получил письмо счастья. Форум Миста хотят закрыть!
Суть: АО «КМ» (представитель 1С по защите прав) требует удалить страницы с упоминанием товарных знаков «1С» и прекратить их использование. Ссылка на штрафы до 5 млн рублей прилагается.
Форуму, на минуточку, более 20 лет. На нем выросло не одно поколение специалистов. Я пару раз сам там спрашивал совета или находил решения нетривиальных задач.
Почему это выглядит как стратегическая ошибка?
Как ИТ-директор и владелец бизнеса, я смотрю на это прагматично:
1. Бесплатный DevRel и техподдержка. Вендоры тратят миллионы на создание комьюнити. Миста делает это бесплатно. Там сидят спецы, которые помогают новичкам, разбирают баги платформы и (сюрприз!) популяризируют продукт. Закрыть такой ресурс, значит отрезать огромный кусок базы знаний. Да, пусть это и специфичный ресурс, но все же.
2. Порог входа. Чем сложнее найти ответ на вопрос «как это закодить», тем дороже стоят специалисты. Если зачистить всё информационное поле, оставив только платные курсы и сухую документацию ИТС, мы получим дефицит кадров (который и так есть).
3. Разрыв связи с реальностью. Есть ощущение, что представитель по юридическим вопросам работает по своим KPI («количество заблокированных ссылок»), не советуясь с отделом развития продукта. Это проблема больших корпораций правая рука душит то, что кормит левую.
Мой вывод:
Защита интеллектуальной собственности это важно. Но когда борьба за товарный знак превращается в войну с собственным сообществом, проигрывает в итоге вендор. Вместо угроз судами, таким площадкам нужно давать статус информационных партнеров.
Следим за развитием событий. Если Мисту «потушат», это будет плохой сигнал для всей отрасли.
Ссылка на обсуждение на самой Мисте: https://forum.mista.ru/topic/900928?utm_source=Telegram&utm_medium=social&utm_campaign=27028071
👇 Коллеги, что думаете? Это перегибы на местах или новая жесткая политика 1С?
#РазборПродукта_КИД #Бизнес_КИД
В сети всплыла «прекрасная» новость. Популярный ресурс для 1С-ников форум миста получил письмо счастья. Форум Миста хотят закрыть!
Суть: АО «КМ» (представитель 1С по защите прав) требует удалить страницы с упоминанием товарных знаков «1С» и прекратить их использование. Ссылка на штрафы до 5 млн рублей прилагается.
Форуму, на минуточку, более 20 лет. На нем выросло не одно поколение специалистов. Я пару раз сам там спрашивал совета или находил решения нетривиальных задач.
Почему это выглядит как стратегическая ошибка?
Как ИТ-директор и владелец бизнеса, я смотрю на это прагматично:
1. Бесплатный DevRel и техподдержка. Вендоры тратят миллионы на создание комьюнити. Миста делает это бесплатно. Там сидят спецы, которые помогают новичкам, разбирают баги платформы и (сюрприз!) популяризируют продукт. Закрыть такой ресурс, значит отрезать огромный кусок базы знаний. Да, пусть это и специфичный ресурс, но все же.
2. Порог входа. Чем сложнее найти ответ на вопрос «как это закодить», тем дороже стоят специалисты. Если зачистить всё информационное поле, оставив только платные курсы и сухую документацию ИТС, мы получим дефицит кадров (который и так есть).
3. Разрыв связи с реальностью. Есть ощущение, что представитель по юридическим вопросам работает по своим KPI («количество заблокированных ссылок»), не советуясь с отделом развития продукта. Это проблема больших корпораций правая рука душит то, что кормит левую.
Мой вывод:
Защита интеллектуальной собственности это важно. Но когда борьба за товарный знак превращается в войну с собственным сообществом, проигрывает в итоге вендор. Вместо угроз судами, таким площадкам нужно давать статус информационных партнеров.
Следим за развитием событий. Если Мисту «потушат», это будет плохой сигнал для всей отрасли.
Ссылка на обсуждение на самой Мисте: https://forum.mista.ru/topic/900928?utm_source=Telegram&utm_medium=social&utm_campaign=27028071
👇 Коллеги, что думаете? Это перегибы на местах или новая жесткая политика 1С?
#РазборПродукта_КИД #Бизнес_КИД
🔥2🤯1💯1
Налог на Windows: почему мы платим 25к за воздух?
Не так давно у нас закончился срок действия сертификат Code Signing от GlobalSign. Брал в 2022 году сразу на 3 года, и вот пришло время продлевать.
Для контекста: мы в Софтонит разрабатываем решения для ИТ-специалистов Управление IT-отделом 8, и у нас есть кроссплатформенный сервер лицензирования на C++. Само приложение не имеет значения, важен сам факт.
Технически Code Signing сейчас — это USB-токен, на котором хранится сертификат. Когда нужно подписать exe-файл или библиотеку, специальная утилита считывает ключ с токена и подписывает ваше приложение внутри дистрибутива.
Зачем это нужно? Когда пользователь запускает неподписанный дистрибутив, Windows проверяет подпись. Если её нет, SmartScreen выдает пугающее предупреждение: «Вы запускаете программу из неизвестного источника, вы точно этого хотите?». Если подпись есть, предупреждение тоже может быть, но оно выглядит «благородно»: с указанием компании-автора и синими кнопками вместо красных крестов.
О проблеме
Вчера я оформлял новую подпись взамен старой и поймал себя на мысли: компании делают деньги буквально из воздуха.
Разработчики приложений под Windows платят немалые деньги (сейчас это около 25 000 руб. в год) за сертификат, который, по сути, просто подтверждает, что данные пришли из известного источника. И ВСЁ! Мы платим дань, просто чтобы Microsoft не пугала наших же клиентов.
Причем сам вендор ОС (Microsoft) этим не заморачивается. Нет бесплатного сервиса верификации для добросовестных разработчиков. Все подается под благовидным предлогом борьбы с вирусами. Но давайте посмотрим на альтернативы.
А как у других?
В экосистеме Linux это вообще не нужно. Там безопасность строится на цепочке доверия репозитория:
Если ставишь из apt или yum — ты доверяешь мейнтейнерам Debian/RedHat. Они подписывают пакеты своими ключами.
Если распространяешь софт сам (как .deb или .rpm) — ты подписываешь его своим GPG-ключом (бесплатно), и пользователь просто добавляет твой ключ в систему.
Разница фундаментальна: В Linux доверие децентрализовано. В Windows — монополия нескольких удостоверяющих центров (GlobalSign, DigiCert, Sectigo), которым Microsoft «разрешила» работать и собирать с нас деньги.
Техническая боль и CI/CD
Финансы — это полбеды. С середины 2023 года правила ужесточились: теперь нельзя просто получить файл сертификата .pfx и положить его на build-сервер. Обязателен физический носитель (токен) или дорогущий облачный HSM.
Это ломает автоматизацию сборки (CI/CD). Чтобы собрать релиз, в сервере должен быть физически воткнут этот USB-свисток, либо нужно настраивать сложный проброс USB-портов в виртуальные машины или контейнеры.
Итог
Мы имеем индустрию, которая продает нам «цифровые паспорта» за ежегодную ренту. Гарантирует ли это отсутствие вирусов? Нет, хакеры тоже покупают или крадут сертификаты. Зато это создает высокий порог входа для инди-разработчиков и лишний геморрой для бизнеса при настройке DevOps.
В мире Linux доверие строится на репутации, а в мире Windows — на платном сертификате. Кажется, мы свернули не туда.
Не так давно у нас закончился срок действия сертификат Code Signing от GlobalSign. Брал в 2022 году сразу на 3 года, и вот пришло время продлевать.
Для контекста: мы в Софтонит разрабатываем решения для ИТ-специалистов Управление IT-отделом 8, и у нас есть кроссплатформенный сервер лицензирования на C++. Само приложение не имеет значения, важен сам факт.
Технически Code Signing сейчас — это USB-токен, на котором хранится сертификат. Когда нужно подписать exe-файл или библиотеку, специальная утилита считывает ключ с токена и подписывает ваше приложение внутри дистрибутива.
Зачем это нужно? Когда пользователь запускает неподписанный дистрибутив, Windows проверяет подпись. Если её нет, SmartScreen выдает пугающее предупреждение: «Вы запускаете программу из неизвестного источника, вы точно этого хотите?». Если подпись есть, предупреждение тоже может быть, но оно выглядит «благородно»: с указанием компании-автора и синими кнопками вместо красных крестов.
О проблеме
Вчера я оформлял новую подпись взамен старой и поймал себя на мысли: компании делают деньги буквально из воздуха.
Разработчики приложений под Windows платят немалые деньги (сейчас это около 25 000 руб. в год) за сертификат, который, по сути, просто подтверждает, что данные пришли из известного источника. И ВСЁ! Мы платим дань, просто чтобы Microsoft не пугала наших же клиентов.
Причем сам вендор ОС (Microsoft) этим не заморачивается. Нет бесплатного сервиса верификации для добросовестных разработчиков. Все подается под благовидным предлогом борьбы с вирусами. Но давайте посмотрим на альтернативы.
А как у других?
В экосистеме Linux это вообще не нужно. Там безопасность строится на цепочке доверия репозитория:
Если ставишь из apt или yum — ты доверяешь мейнтейнерам Debian/RedHat. Они подписывают пакеты своими ключами.
Если распространяешь софт сам (как .deb или .rpm) — ты подписываешь его своим GPG-ключом (бесплатно), и пользователь просто добавляет твой ключ в систему.
Разница фундаментальна: В Linux доверие децентрализовано. В Windows — монополия нескольких удостоверяющих центров (GlobalSign, DigiCert, Sectigo), которым Microsoft «разрешила» работать и собирать с нас деньги.
Техническая боль и CI/CD
Финансы — это полбеды. С середины 2023 года правила ужесточились: теперь нельзя просто получить файл сертификата .pfx и положить его на build-сервер. Обязателен физический носитель (токен) или дорогущий облачный HSM.
Это ломает автоматизацию сборки (CI/CD). Чтобы собрать релиз, в сервере должен быть физически воткнут этот USB-свисток, либо нужно настраивать сложный проброс USB-портов в виртуальные машины или контейнеры.
Итог
Мы имеем индустрию, которая продает нам «цифровые паспорта» за ежегодную ренту. Гарантирует ли это отсутствие вирусов? Нет, хакеры тоже покупают или крадут сертификаты. Зато это создает высокий порог входа для инди-разработчиков и лишний геморрой для бизнеса при настройке DevOps.
В мире Linux доверие строится на репутации, а в мире Windows — на платном сертификате. Кажется, мы свернули не туда.
Доступ к заблокированным иностранным сервисам и мысли на этот счет
Прошлая неделя прошла под лозунгом что-то опять заблокировали: FaceTime, WhatsApp, Roblox и т.д. Но если раньше мы говорили о блокировках конкретных приложений, то сейчас ситуация меняется на более глубоком, инфраструктурном уровне.
Мы наблюдаем проблемы с работой самих протоколов передачи данных — SOCKS5, VLESS, L2TP.
https://habr.com/ru/news/973082
Судя по всему, фильтрация трафика выходит на новый уровень. Похоже, что от блокировки по сигнатурам (когда ищут конкретный «след» протокола) переходят к поведенческому анализу при пересечении границы. Если соединение выглядит подозрительным или данные передаются нестандартно — канал просто «режут» или замедляют.
И это только одна сторона медали.
С другой стороны «железный занавес» опускают сами зарубежные вендоры. Столкнулся с тем, что не смог установить нужное расширение в Visual Studio Code. Список недоступных инструментов растет:
🐌 Notion и продукты Microsoft 365;
🐌 AI-сервисы (ChatGPT, Gemini, Anthropic);
🐌 Инструменты разработки (Visual C++, продукты JetBrains).
🐌 И т.д. и т.п.
https://news.rambler.ru/tech/52462962-microsoft-ogranichit-na-territorii-rossii-dostup-k-50-produktam
В итоге мы в ситуации когда проигрывают все:
- Зарубежные компании теряют прибыль. Да, наш рынок для них не самый большой, но деньги они теряют.
- Отечественные разработчики теряют инструменты. Мы лишаемся доступа к передовым решениям, что неизбежно тормозит развитие и заставляет тратить время не на создание продукта, а на поиск других инструментов / альтернатив.
Сейчас совершенно неясно, как эффективно выстраивать ИТ-стратегию в таких условиях. Мы зажаты в тиски: изнутри — усиление контроля периметра, снаружи — санкционные ограничения. Вопрос «Куда мы придем?» остается открытым, но работать становится всё сложнее.
Коллеги, что думаете по этому поводу? Как блокировки повлияли на вашу работу?
Прошлая неделя прошла под лозунгом что-то опять заблокировали: FaceTime, WhatsApp, Roblox и т.д. Но если раньше мы говорили о блокировках конкретных приложений, то сейчас ситуация меняется на более глубоком, инфраструктурном уровне.
Мы наблюдаем проблемы с работой самих протоколов передачи данных — SOCKS5, VLESS, L2TP.
https://habr.com/ru/news/973082
Судя по всему, фильтрация трафика выходит на новый уровень. Похоже, что от блокировки по сигнатурам (когда ищут конкретный «след» протокола) переходят к поведенческому анализу при пересечении границы. Если соединение выглядит подозрительным или данные передаются нестандартно — канал просто «режут» или замедляют.
И это только одна сторона медали.
С другой стороны «железный занавес» опускают сами зарубежные вендоры. Столкнулся с тем, что не смог установить нужное расширение в Visual Studio Code. Список недоступных инструментов растет:
🐌 Notion и продукты Microsoft 365;
🐌 AI-сервисы (ChatGPT, Gemini, Anthropic);
🐌 Инструменты разработки (Visual C++, продукты JetBrains).
🐌 И т.д. и т.п.
https://news.rambler.ru/tech/52462962-microsoft-ogranichit-na-territorii-rossii-dostup-k-50-produktam
В итоге мы в ситуации когда проигрывают все:
- Зарубежные компании теряют прибыль. Да, наш рынок для них не самый большой, но деньги они теряют.
- Отечественные разработчики теряют инструменты. Мы лишаемся доступа к передовым решениям, что неизбежно тормозит развитие и заставляет тратить время не на создание продукта, а на поиск других инструментов / альтернатив.
Сейчас совершенно неясно, как эффективно выстраивать ИТ-стратегию в таких условиях. Мы зажаты в тиски: изнутри — усиление контроля периметра, снаружи — санкционные ограничения. Вопрос «Куда мы придем?» остается открытым, но работать становится всё сложнее.
Коллеги, что думаете по этому поводу? Как блокировки повлияли на вашу работу?
Собираем Docs-as-Code: GitLab CI, Docusaurus и поиск. Как мы сделали базу знаний. Часть 3
В прошлой части я объяснил, почему мы выбрали Docusaurus. Выбор сделан, но «движок» сам по себе — это просто куча JS-файлов. Чтобы всё это реально заработало в компании, нужно было подружить его с нашими репозиториями, настроить автоматическую сборку и заставить поиск работать молниеносно.
Рассказываю, как мы это «приготовили» в СОФТОНИТ.
Архитектура: Одна «витрина» — много источников
Главная идея Docs-as-Code: документация лежит рядом с кодом, мы пишем код, обновляем документацию и клиенты видят обновленную документацию на сайте без танцев с бубном. У нас несколько продуктов (например, Управление IT-отделом 8), и у каждого продукта свой репозиторий в GitLab.
Я не хотел заставлять разработчиков копировать файлы вручную. Все должно быть просто для разработчиков. Поэтому мы создали отдельный репозиторий для документации, который работает как «агрегатор».
Как это работает:
1. В репозитории агрегаторе есть файл конфигурации repos.json, где перечислены все наши проекты и ветки откуда надо брать документацию (как правило это ветка main).
2. GitLab CI при запуске в репозитории агрегаторе идет в эти репозитории доноры и забирает папку docs у каждого продукта, копируя в общую структуру Docusaurus. В каждом репозитории есть папка docs с документацией в markdown.
3. Происходит «магия» со слагами (slugs) и ID для каждой статьи (транслитерация адресов URL статей), чтобы ссылки не бились.
Всё это пакуется и собирается общая база знаний, а затем она копируется на сервер.
4. Затем обновляется поисковый индекс.
Разбор полетов: Наш GitLab CI/CD
Ниже — ключевые этапы нашей сборки. Я не буду уходить в дебри, остановлюсь на важных нюансах.
- Этап синхронизации (Sync): Здесь мы используем node:24-alpine. Главная хитрость — обход прокси для внутреннего GitLab. Мы прописываем IP бэкенда прямо в ~/.ssh/config. Скрипт перебирает repos.json, клонирует репозитории и вытягивает Markdown-файлы.
- Сборка (Build): Стандартный npm run build. На выходе получаем готовую статику в папке build/.
- Деплой (Deploy): Используем старый добрый rsync через SSH. Это быстрее и надежнее для обновления только измененных файлов. Работает, кстати, такое очень быстро.
- Индексация (Index): А вот тут самое интересное.
Поиск: Почему Meilisearch, а не Algolia?
В прошлой статье я хвалил Algolia, но в итоге мы развернули Meilisearch. Почему?
- Полный контроль: Всё крутится на нашем сервере.
- Скорость: Он быстрый.
- Стоимость: Для наших объемов это бесплатно, при этом качество выдачи не уступает облачным гигантам.
Сейчас на docs.softonit.ru уже можно посмотреть результат.
А как вы решаете вопрос с обновлением общей документации из разных репозиториев? Делаете мульти-проектные пайплайны или тоже живете на расписании? 👇
В прошлой части я объяснил, почему мы выбрали Docusaurus. Выбор сделан, но «движок» сам по себе — это просто куча JS-файлов. Чтобы всё это реально заработало в компании, нужно было подружить его с нашими репозиториями, настроить автоматическую сборку и заставить поиск работать молниеносно.
Рассказываю, как мы это «приготовили» в СОФТОНИТ.
Архитектура: Одна «витрина» — много источников
Главная идея Docs-as-Code: документация лежит рядом с кодом, мы пишем код, обновляем документацию и клиенты видят обновленную документацию на сайте без танцев с бубном. У нас несколько продуктов (например, Управление IT-отделом 8), и у каждого продукта свой репозиторий в GitLab.
Я не хотел заставлять разработчиков копировать файлы вручную. Все должно быть просто для разработчиков. Поэтому мы создали отдельный репозиторий для документации, который работает как «агрегатор».
Как это работает:
1. В репозитории агрегаторе есть файл конфигурации repos.json, где перечислены все наши проекты и ветки откуда надо брать документацию (как правило это ветка main).
2. GitLab CI при запуске в репозитории агрегаторе идет в эти репозитории доноры и забирает папку docs у каждого продукта, копируя в общую структуру Docusaurus. В каждом репозитории есть папка docs с документацией в markdown.
3. Происходит «магия» со слагами (slugs) и ID для каждой статьи (транслитерация адресов URL статей), чтобы ссылки не бились.
Всё это пакуется и собирается общая база знаний, а затем она копируется на сервер.
4. Затем обновляется поисковый индекс.
Разбор полетов: Наш GitLab CI/CD
Ниже — ключевые этапы нашей сборки. Я не буду уходить в дебри, остановлюсь на важных нюансах.
- Этап синхронизации (Sync): Здесь мы используем node:24-alpine. Главная хитрость — обход прокси для внутреннего GitLab. Мы прописываем IP бэкенда прямо в ~/.ssh/config. Скрипт перебирает repos.json, клонирует репозитории и вытягивает Markdown-файлы.
- Сборка (Build): Стандартный npm run build. На выходе получаем готовую статику в папке build/.
- Деплой (Deploy): Используем старый добрый rsync через SSH. Это быстрее и надежнее для обновления только измененных файлов. Работает, кстати, такое очень быстро.
- Индексация (Index): А вот тут самое интересное.
Поиск: Почему Meilisearch, а не Algolia?
В прошлой статье я хвалил Algolia, но в итоге мы развернули Meilisearch. Почему?
- Полный контроль: Всё крутится на нашем сервере.
- Скорость: Он быстрый.
- Стоимость: Для наших объемов это бесплатно, при этом качество выдачи не уступает облачным гигантам.
Сейчас на docs.softonit.ru уже можно посмотреть результат.
А как вы решаете вопрос с обновлением общей документации из разных репозиториев? Делаете мульти-проектные пайплайны или тоже живете на расписании? 👇
Зачем мы строим планы, когда всё летит в тартарары?
Посмотрел на выходных выпуск-подкаст, тема была не совсем про ИТ. В подкасте говорили о несправедливости и личном выборе. Мне понравился один момент, который как мне кажется хорошо перекликается с ИТ-проектами.
Там зачитывают вопрос подписчика:
Знакомая ситуация для любого руководителя в последние годы. Лег сервер, уволился ключевой сотрудник, срываются сроки проекта и т.п.
Автор дает ответ, который меня зацепил: Это вопрос не про план, это вопрос про ощущение контроля.
Я почему-то никогда в такой парадигме не думал…
Обычно план воспринимают как карту будущего. Но когда ничего не понятно, а в ИТ так почти всегда, функция у него другая. Психотерапевтическая. Когда есть план и ты начинаешь действовать, то перестаешь быть щепкой, которую несет течением. Возвращается субъектность и то самое ощущение контроля.
Если переложить это на нашу работу, становится понятно, зачем на самом деле нужны все эти роадмапы, спринты и стратегии. Даже если через месяц их придется переписывать.
1. План превращает панику в процедуру. Яркий пример — это план аварийного восстановления. Упал сервер и никто не знает, когда поднимется. Хаос. Но если есть инструкция, команда не бегает с криками «мы все умрем», а спокойно по пунктам делает работу. План не тушит пожар, он тушит панику в головах инженеров.
2. Снижается нагрузка на мозг. Спринты планируют не из слепой веры в неизменность задач на две недели. Это нужно, чтобы разработчик утром просто знал: сегодня я делаю задачу А. Меньше тревожности, больше фокуса.
3. Ловушка «иллюзии контроля». Тут важно быть честным, есть риск. В погоне за ощущением контроля руководители часто начинают управлять тем, до чего могут дотянуться, а не тем, что важно.
Не можешь гарантировать, что внешний провайдер не отключит API? От бессилия начинаешь следить, во сколько сотрудники приходят в офис, или считать строки кода. Вроде успокаивает — я же управляю! — но результат убивает. Такой вот карго-культ.
Резюме
Планирование в турбулентности нужно для сохранения холодной головы. Автор подкаста привел жесткий пример: даже если несешься в автобусе в пропасть, мысль о страховке и плане действий для семьи позволяет не истерить, а сгруппироваться и возможно, это спасет тебя.
В ИТ, да и в любом бизнесе то же самое. Планы строят не чтобы угадать будущее, это невозможно. Они нужны, чтобы здесь и сейчас команда чувствовала почву под ногами. Чтобы делали своё дело, а не рефлексировали над новостями.
Мне кажется, что это важная мысль и в текущее время это актуально как никогда. Планируйте проекты, друзья!
Посмотрел на выходных выпуск-подкаст, тема была не совсем про ИТ. В подкасте говорили о несправедливости и личном выборе. Мне понравился один момент, который как мне кажется хорошо перекликается с ИТ-проектами.
Там зачитывают вопрос подписчика:
Как строить планы на жизнь в горизонте пары лет, если я не знаю, что со мной будет через месяц?
Знакомая ситуация для любого руководителя в последние годы. Лег сервер, уволился ключевой сотрудник, срываются сроки проекта и т.п.
Автор дает ответ, который меня зацепил: Это вопрос не про план, это вопрос про ощущение контроля.
Я почему-то никогда в такой парадигме не думал…
Обычно план воспринимают как карту будущего. Но когда ничего не понятно, а в ИТ так почти всегда, функция у него другая. Психотерапевтическая. Когда есть план и ты начинаешь действовать, то перестаешь быть щепкой, которую несет течением. Возвращается субъектность и то самое ощущение контроля.
Если переложить это на нашу работу, становится понятно, зачем на самом деле нужны все эти роадмапы, спринты и стратегии. Даже если через месяц их придется переписывать.
1. План превращает панику в процедуру. Яркий пример — это план аварийного восстановления. Упал сервер и никто не знает, когда поднимется. Хаос. Но если есть инструкция, команда не бегает с криками «мы все умрем», а спокойно по пунктам делает работу. План не тушит пожар, он тушит панику в головах инженеров.
2. Снижается нагрузка на мозг. Спринты планируют не из слепой веры в неизменность задач на две недели. Это нужно, чтобы разработчик утром просто знал: сегодня я делаю задачу А. Меньше тревожности, больше фокуса.
3. Ловушка «иллюзии контроля». Тут важно быть честным, есть риск. В погоне за ощущением контроля руководители часто начинают управлять тем, до чего могут дотянуться, а не тем, что важно.
Не можешь гарантировать, что внешний провайдер не отключит API? От бессилия начинаешь следить, во сколько сотрудники приходят в офис, или считать строки кода. Вроде успокаивает — я же управляю! — но результат убивает. Такой вот карго-культ.
Резюме
Планирование в турбулентности нужно для сохранения холодной головы. Автор подкаста привел жесткий пример: даже если несешься в автобусе в пропасть, мысль о страховке и плане действий для семьи позволяет не истерить, а сгруппироваться и возможно, это спасет тебя.
В ИТ, да и в любом бизнесе то же самое. Планы строят не чтобы угадать будущее, это невозможно. Они нужны, чтобы здесь и сейчас команда чувствовала почву под ногами. Чтобы делали своё дело, а не рефлексировали над новостями.
Мне кажется, что это важная мысль и в текущее время это актуально как никогда. Планируйте проекты, друзья!
🔥2
Искусственный интеллект нарушает цепочку развития программных продуктов и это 100%
Прочел статью на Хабре о проблемах создателей Tailwind CSS и призадумался. Ситуация выглядит парадоксально. Продукт на пике популярности, но бизнес-модель рушится.
Давайте разберем механику этого процесса, потому что она касается не только CSS-фреймворков, но и всего Open Source.
Как это работало раньше и как Tailwind зарабатывала деньги
Возьмем Tailwind CSS. Это сверхпопулярный инструмент, стандарт де-факто в современной верстке. Его используют около 75% опрошенных разработчиков.
Раньше экономика Open Source продукта выглядела так:
1. Разработчик гуглит решение.
2. Попадает на сайт Tailwind.
3. Читает документацию.
4. Видит платные продукты (Tailwind UI — готовые компоненты) и покупает их, чтобы сэкономить время.
5. Деньги идут авторам фреймворка.
6. Авторы инвестируют в развитие ядра продукта.
Схема была здоровой:
Что изменилось с приходом AI
Теперь в игру вступили «умные» редакторы кода: Cursor, Copilot, Windsurf и т.п. Сценарий изменился кардинально:
1. Разработчик открывает IDE (например, Cursor).
2. Пишет промпт: «Сделай мне красивую кнопку на Tailwind».
3. Нейросеть генерирует код, используя знания о классах Tailwind CSS.
Разработчик не заходит на сайт, не видит рекламу платных китов, не покупает Tailwind UI.
Новая экономическая схема:
В чем проблема?
Разработчик инструмента Tailwind выпал из цепочки. Финансы уходят не создателю технологии, а создателю нейросети.
Это создает парадокс:
- Фреймворк популярен как никогда.
- Денежный поток создателей иссякает.
- Компании вынуждены увольнять сотрудников и сокращать инвестиции в развитие.
Змея, пожирающая сама себя
Это не просто «проблемы бизнеса». Это проблема всей индустрии. Если такие компании, как Tailwind, перестанут развивать свои продукты из-за нехватки средств, на чем будут учиться следующие версии нейросетей?
Нейросети не создают новые фреймворки, они используют существующие. Мы рискуем получить ситуацию, где AI паразитирует на текущих технологиях, убивая их создателей, и тем самым останавливает приток новых идей.
Искусственный интеллект нарушает естественную цепочку «финансирование — инновации». В краткосрочной перспективе нам удобно (код пишется быстро), но в долгосрочной это 100% приведет к стагнации инструментов, которыми мы пользуемся.
#Кейсы_КИД #РазборПродукта_КИД #Бизнес_КИД https://t.me/codeitdir/75?utm_source=Telegram&utm_medium=social&utm_campaign=27859428
Прочел статью на Хабре о проблемах создателей Tailwind CSS и призадумался. Ситуация выглядит парадоксально. Продукт на пике популярности, но бизнес-модель рушится.
Давайте разберем механику этого процесса, потому что она касается не только CSS-фреймворков, но и всего Open Source.
Как это работало раньше и как Tailwind зарабатывала деньги
Возьмем Tailwind CSS. Это сверхпопулярный инструмент, стандарт де-факто в современной верстке. Его используют около 75% опрошенных разработчиков.
Раньше экономика Open Source продукта выглядела так:
1. Разработчик гуглит решение.
2. Попадает на сайт Tailwind.
3. Читает документацию.
4. Видит платные продукты (Tailwind UI — готовые компоненты) и покупает их, чтобы сэкономить время.
5. Деньги идут авторам фреймворка.
6. Авторы инвестируют в развитие ядра продукта.
Схема была здоровой:
Клиент → Потребность → Документация/Сайт → Покупка доп. услуг → Деньги разработчику → Развитие продукта
Что изменилось с приходом AI
Теперь в игру вступили «умные» редакторы кода: Cursor, Copilot, Windsurf и т.п. Сценарий изменился кардинально:
1. Разработчик открывает IDE (например, Cursor).
2. Пишет промпт: «Сделай мне красивую кнопку на Tailwind».
3. Нейросеть генерирует код, используя знания о классах Tailwind CSS.
Разработчик не заходит на сайт, не видит рекламу платных китов, не покупает Tailwind UI.
Новая экономическая схема:
Клиент → Подписка на AI ($20/мес) → Нейросеть → Готовый код
В чем проблема?
Разработчик инструмента Tailwind выпал из цепочки. Финансы уходят не создателю технологии, а создателю нейросети.
Это создает парадокс:
- Фреймворк популярен как никогда.
- Денежный поток создателей иссякает.
- Компании вынуждены увольнять сотрудников и сокращать инвестиции в развитие.
Змея, пожирающая сама себя
Это не просто «проблемы бизнеса». Это проблема всей индустрии. Если такие компании, как Tailwind, перестанут развивать свои продукты из-за нехватки средств, на чем будут учиться следующие версии нейросетей?
Нейросети не создают новые фреймворки, они используют существующие. Мы рискуем получить ситуацию, где AI паразитирует на текущих технологиях, убивая их создателей, и тем самым останавливает приток новых идей.
Искусственный интеллект нарушает естественную цепочку «финансирование — инновации». В краткосрочной перспективе нам удобно (код пишется быстро), но в долгосрочной это 100% приведет к стагнации инструментов, которыми мы пользуемся.
#Кейсы_КИД #РазборПродукта_КИД #Бизнес_КИД https://t.me/codeitdir/75?utm_source=Telegram&utm_medium=social&utm_campaign=27859428
😱1💯1
Я вырастил сеньора из саппорта, а он ушел
Открываю в блоге новую рубрику — «Управленческие задачи». Здесь не будет теории из учебников MBA. Кейсы про команду, клиентов, ответственность и выбор, который приходится делать ежедневно в реальной работе. Почти всегда не содержит правильного ответа, но позволяет задуматься как можно повести себя в той или иной ситуации.
Сегодняшний кейс — о талантах, карьерном росте и страхе потерять сотрудника, сделав его слишком крутым.
Описание ситуации
Вы тимлид в ИТ-подразделении и взяли на работу на 1-ю линию сотрудника — Руслана (имя вымышлено). Его задача — отвечать на вопросы техподдержки, помогать тестированием функционала и писать документацию по продукту.
Спустя время, вы понимаете, что парень талантливый и потихоньку это ведет его вперед. Те вопросы, которые ему поручаются он выполняет достаточно хорошо и качественно. То, что отдано в работу Руслану, всегда выполняется в срок и качественно. Время идет, он растет и набирается опыта. Основной стек разработки — это 1С, и вы занимаетесь разработкой собственного решения на 1С. Получается так, что Руслан иногда сам в 1С отладчиком находит проблемы клиентов и разработчикам передает эту информацию. Т.е. парень прям серьезно вырос.
Тут случается непредвиденная ситуация. Два программиста одновременно решают уйти из компании. Перед вами появляется дилемма: как быстро закрыть эту потребность без потери качества, чтобы человек был сразу в теме и мог хотя бы частично эту потребность закрыть.
Вы вспоминаете про Руслана, т.к. именно в текущий момент это win/win.
- Для вас: вы получаете лояльного, мотивированного сотрудника, который уже знает продукт изнутри и готов развиваться.
- Для Руслана: он получает возможность расти дальше, но уже в роли разработчика и с другой мотивацией.
Вы разговариваете с Русланом и предлагаете ему эту должность. Он соглашается.
Спустя время вы понимаете, что Руслан отлично справляется со сменой должности и уже в роли разработчика 1С прекрасно себя показывает. Через год Руслан уже Middle+ и к нему начали поступать задачи на проектирование и разработку отдельных подсистем. Т.е. потенциально мы имеем Senior.
Развитие и финал
На очередном PR, Руслан сказал, что хотел бы уволиться. Причина не в деньгах (оффер не сработал). Причина в стеке. Компания пишет собственный продукт. Руслан осознал: работая над уникальным отраслевым решением, он теряет квалификацию по рынку. Рынок требует знания типовых конфигураций (Бухгалтерия, ERP, ЗУП и т.п.), а он «варится» в кастомном коде. Он бы хотел заниматься типовыми решениями 1С, а наша компания не может ему этого дать. Он увольняется и уходит в компанию на типовые проекты, чтобы оставаться ликвидным специалистом.
Альтернативное мнение: «Ты сам виноват»
Обсуждая эту ситуацию с коллегой-руководителем, я неожиданно услышал жесткую критику. Его позиция была такой:
Для меня такое решение вопроса спорное. Да и с этической стороной есть проблемы.
Вопросы для обсуждения
1. Насколько верным управленческим решением было предлагать Руслану перейти в разработку из техподдержки?
2. Верите ли вы в стратегию «искусственного сдерживания»? Если бы Руслан остался в поддержке, не ушел бы он еще раньше от скуки и отсутствия перспектив?
3. Если ваша компания разрабатывает собственный уникальный софт, как вы удерживаете разработчиков, которые боятся отстать от рынка и потерять квалификацию в типовых решениях (ERP / Spring / React и т.д.)?
4. Вы понимаете, что перед вами сотрудник-бриллиант пока без знаний, но с огромным потенциалом. Как лучше организовать развитие такого сотрудника, чтобы он не покинул компанию досрочно и принес максимум пользы?
Открываю в блоге новую рубрику — «Управленческие задачи». Здесь не будет теории из учебников MBA. Кейсы про команду, клиентов, ответственность и выбор, который приходится делать ежедневно в реальной работе. Почти всегда не содержит правильного ответа, но позволяет задуматься как можно повести себя в той или иной ситуации.
Сегодняшний кейс — о талантах, карьерном росте и страхе потерять сотрудника, сделав его слишком крутым.
Описание ситуации
Вы тимлид в ИТ-подразделении и взяли на работу на 1-ю линию сотрудника — Руслана (имя вымышлено). Его задача — отвечать на вопросы техподдержки, помогать тестированием функционала и писать документацию по продукту.
Спустя время, вы понимаете, что парень талантливый и потихоньку это ведет его вперед. Те вопросы, которые ему поручаются он выполняет достаточно хорошо и качественно. То, что отдано в работу Руслану, всегда выполняется в срок и качественно. Время идет, он растет и набирается опыта. Основной стек разработки — это 1С, и вы занимаетесь разработкой собственного решения на 1С. Получается так, что Руслан иногда сам в 1С отладчиком находит проблемы клиентов и разработчикам передает эту информацию. Т.е. парень прям серьезно вырос.
Тут случается непредвиденная ситуация. Два программиста одновременно решают уйти из компании. Перед вами появляется дилемма: как быстро закрыть эту потребность без потери качества, чтобы человек был сразу в теме и мог хотя бы частично эту потребность закрыть.
Вы вспоминаете про Руслана, т.к. именно в текущий момент это win/win.
- Для вас: вы получаете лояльного, мотивированного сотрудника, который уже знает продукт изнутри и готов развиваться.
- Для Руслана: он получает возможность расти дальше, но уже в роли разработчика и с другой мотивацией.
Вы разговариваете с Русланом и предлагаете ему эту должность. Он соглашается.
Спустя время вы понимаете, что Руслан отлично справляется со сменой должности и уже в роли разработчика 1С прекрасно себя показывает. Через год Руслан уже Middle+ и к нему начали поступать задачи на проектирование и разработку отдельных подсистем. Т.е. потенциально мы имеем Senior.
Развитие и финал
На очередном PR, Руслан сказал, что хотел бы уволиться. Причина не в деньгах (оффер не сработал). Причина в стеке. Компания пишет собственный продукт. Руслан осознал: работая над уникальным отраслевым решением, он теряет квалификацию по рынку. Рынок требует знания типовых конфигураций (Бухгалтерия, ERP, ЗУП и т.п.), а он «варится» в кастомном коде. Он бы хотел заниматься типовыми решениями 1С, а наша компания не может ему этого дать. Он увольняется и уходит в компанию на типовые проекты, чтобы оставаться ликвидным специалистом.
Альтернативное мнение: «Ты сам виноват»
Обсуждая эту ситуацию с коллегой-руководителем, я неожиданно услышал жесткую критику. Его позиция была такой:
Ты совершил ошибку. Таких людей нельзя переводить в разработку, если у тебя «самописная конфигурация». В поддержке он был бы звездой. Он чувствовал бы себя нужным, у него была бы стабильная зарплата, и ему некуда было бы деваться, потому что навыки саппорта специфичны. А ты дал ему в руки профессию, которая позволяет ему выбирать. Мы у себя намеренно ограничиваем вертикальный рост таких кадров, чтобы они дольше приносили пользу на своем месте.
Для меня такое решение вопроса спорное. Да и с этической стороной есть проблемы.
Вопросы для обсуждения
1. Насколько верным управленческим решением было предлагать Руслану перейти в разработку из техподдержки?
2. Верите ли вы в стратегию «искусственного сдерживания»? Если бы Руслан остался в поддержке, не ушел бы он еще раньше от скуки и отсутствия перспектив?
3. Если ваша компания разрабатывает собственный уникальный софт, как вы удерживаете разработчиков, которые боятся отстать от рынка и потерять квалификацию в типовых решениях (ERP / Spring / React и т.д.)?
4. Вы понимаете, что перед вами сотрудник-бриллиант пока без знаний, но с огромным потенциалом. Как лучше организовать развитие такого сотрудника, чтобы он не покинул компанию досрочно и принес максимум пользы?
Как Яндекс бесплатной почтой убил конкурентов и посадил бизнес на подписку
Оплачивал на днях Яндекс 360 для бизнеса и поймал себя на мысли: а ведь мог бы поднять почту на своём сервере. Домен есть, VPS есть. Но каждый раз как подхожу к этой задаче, вспоминаю про настройку DKIM, SPF, борьбу со спам-листами, мониторинг, бэкапы... И откладываю.
А потом вспомнил, как вообще оказался в этой ситуации.
Что было до 2009 года
Если тебе нужна была корпоративная почта на своём домене, варианты были невеселые. Либо поднимаешь свой почтовый сервер и мучаешься с настройками. Либо покупаешь почту у хостинга, платишь, а оно всё равно криво работает. Либо сидишь на бесплатных ящиках типа mail.ru и выглядишь несерьёзно.
Рынок бесплатной почты для физлиц к тому моменту уже поделили. Расти некуда. И тут Яндекс придумал ход.
Что сделал Яндекс
В 2009 году появился pdd.yandex.ru. Суть простая: подключаешь свой домен, прописываешь MX-записи, и в пару кликов получаешь корпоративную почту ivan@moicompany.ru на мощностях Яндекса. Бесплатно и без лимитов.
Бизнес начал перетекать. Зачем платить хостингу или возиться с сервером, если Яндекс даёт всё то же самое, но бесплатно?
Как это работало
Сначала Яндекс занял рынок за свой счёт. Бесплатный сервис привлёк массу мелкого и среднего бизнеса. Кто будет платить хостингу за почту, если можно бесплатно? Конкуренты посыпались.
Параллельно Яндекс допиливал экосистему: Диск, Календарь, потом Телемост, Трекер. Всё это обрастало вокруг почты, затягивало глубже.
А в 2023 году бесплатный тариф убрали. Теперь это Яндекс 360 за деньги. Все клиенты уже внутри, переезжать дорого и больно. Конкурентов нет.
К чему это я
Модель рабочая: входи бесплатно, расти вместе с клиентом, закрывай монетизацию когда рынок твой. С Яндекс Go было очень похоже. Субсидировали поездки, демпинговали, поглотили Uber Russia. Теперь цены растут, а альтернатив почти нет.
Меня вот что цепляет: мы как бизнес сидим на таких сервисах и вроде понимаем риски. Но каждый раз удивляемся, когда бесплатное становится платным. Я вот сам до сих пор плачу Яндексу, хотя технически мог бы съехать.
А вы как решаете? Платите и не паритесь, или ищете альтернативы?
Оплачивал на днях Яндекс 360 для бизнеса и поймал себя на мысли: а ведь мог бы поднять почту на своём сервере. Домен есть, VPS есть. Но каждый раз как подхожу к этой задаче, вспоминаю про настройку DKIM, SPF, борьбу со спам-листами, мониторинг, бэкапы... И откладываю.
А потом вспомнил, как вообще оказался в этой ситуации.
Что было до 2009 года
Если тебе нужна была корпоративная почта на своём домене, варианты были невеселые. Либо поднимаешь свой почтовый сервер и мучаешься с настройками. Либо покупаешь почту у хостинга, платишь, а оно всё равно криво работает. Либо сидишь на бесплатных ящиках типа mail.ru и выглядишь несерьёзно.
Рынок бесплатной почты для физлиц к тому моменту уже поделили. Расти некуда. И тут Яндекс придумал ход.
Что сделал Яндекс
В 2009 году появился pdd.yandex.ru. Суть простая: подключаешь свой домен, прописываешь MX-записи, и в пару кликов получаешь корпоративную почту ivan@moicompany.ru на мощностях Яндекса. Бесплатно и без лимитов.
Бизнес начал перетекать. Зачем платить хостингу или возиться с сервером, если Яндекс даёт всё то же самое, но бесплатно?
Как это работало
Сначала Яндекс занял рынок за свой счёт. Бесплатный сервис привлёк массу мелкого и среднего бизнеса. Кто будет платить хостингу за почту, если можно бесплатно? Конкуренты посыпались.
Параллельно Яндекс допиливал экосистему: Диск, Календарь, потом Телемост, Трекер. Всё это обрастало вокруг почты, затягивало глубже.
А в 2023 году бесплатный тариф убрали. Теперь это Яндекс 360 за деньги. Все клиенты уже внутри, переезжать дорого и больно. Конкурентов нет.
К чему это я
Модель рабочая: входи бесплатно, расти вместе с клиентом, закрывай монетизацию когда рынок твой. С Яндекс Go было очень похоже. Субсидировали поездки, демпинговали, поглотили Uber Russia. Теперь цены растут, а альтернатив почти нет.
Меня вот что цепляет: мы как бизнес сидим на таких сервисах и вроде понимаем риски. Но каждый раз удивляемся, когда бесплатное становится платным. Я вот сам до сих пор плачу Яндексу, хотя технически мог бы съехать.
А вы как решаете? Платите и не паритесь, или ищете альтернативы?
За 2.5 года страх перед ИИ вырос с 13% до 47%
Иногда почитываю Reddit и случайно наткнулся на график, от которого стало как-то не по себе. Какой-то энтузиаст три года подряд каждые полгода спрашивает коллег из FAANG одно и то же: Насколько вы переживаете, что ИИ заберет вашу работу?
Посмотрите на август 2023. 87% людей отвечали в духе «да ладно, это никогда не произойдет».
А сейчас, в январе 2026 только 17% не переживают. Почти половина (47%!) говорят «меня могут заменить сегодня».
Что вообще произошло
В 2023 ChatGPT был прикольной штукой / игрушкой. Да, он мог написать стишок или письмо, но всерьез его воспринимали разве что хайпожоры. Все эти шутки про «нейросеть как второклассник», помните?
Сегодня все, мягко говоря, чуть-чуть не так. Claude Code генерит код, который я отправляю в прод после минимальной правки (есть такой грешок). Cursor дописывает не просто следующую строку, а целую функцию, причем часто именно ту, что мне нужна. Появляются агенты типа OpenClaw, которые и память свою имеют и где-то даже самостоятельны.
Я думаю вот что: дело не в том, что ИИ вдруг стал супер-умным (хотя и не без этого, LLM умнеют). Просто люди наконец ощутили разницу. Не в теории, а на своей шкуре. Увидели, как задачи на три часа теперь закрываются за двадцать минут.
Вот это «ощутили» и есть переломный момент.
Комментарии оттуда же
Я полез читать обсуждение под постом. Там целая война разгорелась.
Кто-то пишет: «На мой взгляд, это огромная часть перемен. Трудно получить нейтральное мнение, когда на кону твоя работа.»
А кто-то отвечает в духе: «Да успокойтесь вы все. ИИ — просто инструмент. Молоток не заменил плотника? Excel не убил бухгалтеров? И здесь так же будет».
Что я об этом думаю
Последние полгода я довольно активно юзаю ИИ в работе над УИТ. Пришел к одной мысли:
Короче, не сама технология угрожает людям. А те, кто ее освоил, угрожают тем, кто нет.
Раньше нормальный разработчик выдавал условно 200 строк годного кода в день. Сейчас с ИИ тот же разработчик может делать 500-700. Может даже больше, зависит от задачи. Планка сместилась. И если ты не подтянулся, ты уже позади.
Я как руководитель теперь не могу объяснить себе, зачем мне нанимать человека, который принципиально не использует эти штуки. Это же прямой удар по эффективности. Либо он делает меньше за ту же зарплату, либо мне надо платить больше за тот же результат.
Наверное, именно эта логика и добралась до тех 47% обеспокоенных людей из опроса.
Вопрос открытый
У себя используем Cursor, $40 подписка на рабочее место + $50 в месяц каждому сверх лимита. В прошлом месяце купил Claude Code попробовать, наверное будем менять схему работы.
Хотелось бы узнать а как у вас в компании? Команда уже активно работает с ИИ, есть такое же беспокойство как на Reddit?
У нас в Софтоните я не то чтобы требую, но очень настоятельно рекомендую использовать. Сам показываю, как работает, разбираем кейсы. Но вот честно не знаю, правильный ли это подход. Может, кто-то делает иначе и это работает лучше?
Делитесь в комментах, правда интересно.
Пруф: https://www.reddit.com/r/dataisbeautiful/comments/1qp1n0r/oc_for_the_past_3_years_ive_polled_people_on/
Иногда почитываю Reddit и случайно наткнулся на график, от которого стало как-то не по себе. Какой-то энтузиаст три года подряд каждые полгода спрашивает коллег из FAANG одно и то же: Насколько вы переживаете, что ИИ заберет вашу работу?
Посмотрите на август 2023. 87% людей отвечали в духе «да ладно, это никогда не произойдет».
А сейчас, в январе 2026 только 17% не переживают. Почти половина (47%!) говорят «меня могут заменить сегодня».
Что вообще произошло
В 2023 ChatGPT был прикольной штукой / игрушкой. Да, он мог написать стишок или письмо, но всерьез его воспринимали разве что хайпожоры. Все эти шутки про «нейросеть как второклассник», помните?
Сегодня все, мягко говоря, чуть-чуть не так. Claude Code генерит код, который я отправляю в прод после минимальной правки (есть такой грешок). Cursor дописывает не просто следующую строку, а целую функцию, причем часто именно ту, что мне нужна. Появляются агенты типа OpenClaw, которые и память свою имеют и где-то даже самостоятельны.
Я думаю вот что: дело не в том, что ИИ вдруг стал супер-умным (хотя и не без этого, LLM умнеют). Просто люди наконец ощутили разницу. Не в теории, а на своей шкуре. Увидели, как задачи на три часа теперь закрываются за двадцать минут.
Вот это «ощутили» и есть переломный момент.
Комментарии оттуда же
Я полез читать обсуждение под постом. Там целая война разгорелась.
Кто-то пишет: «На мой взгляд, это огромная часть перемен. Трудно получить нейтральное мнение, когда на кону твоя работа.»
А кто-то отвечает в духе: «Да успокойтесь вы все. ИИ — просто инструмент. Молоток не заменил плотника? Excel не убил бухгалтеров? И здесь так же будет».
Что я об этом думаю
Последние полгода я довольно активно юзаю ИИ в работе над УИТ. Пришел к одной мысли:
ИИ не заменит программиста. Но программист с ИИ точно заменит программиста без ИИ.
Короче, не сама технология угрожает людям. А те, кто ее освоил, угрожают тем, кто нет.
Раньше нормальный разработчик выдавал условно 200 строк годного кода в день. Сейчас с ИИ тот же разработчик может делать 500-700. Может даже больше, зависит от задачи. Планка сместилась. И если ты не подтянулся, ты уже позади.
Я как руководитель теперь не могу объяснить себе, зачем мне нанимать человека, который принципиально не использует эти штуки. Это же прямой удар по эффективности. Либо он делает меньше за ту же зарплату, либо мне надо платить больше за тот же результат.
Наверное, именно эта логика и добралась до тех 47% обеспокоенных людей из опроса.
Вопрос открытый
У себя используем Cursor, $40 подписка на рабочее место + $50 в месяц каждому сверх лимита. В прошлом месяце купил Claude Code попробовать, наверное будем менять схему работы.
Хотелось бы узнать а как у вас в компании? Команда уже активно работает с ИИ, есть такое же беспокойство как на Reddit?
У нас в Софтоните я не то чтобы требую, но очень настоятельно рекомендую использовать. Сам показываю, как работает, разбираем кейсы. Но вот честно не знаю, правильный ли это подход. Может, кто-то делает иначе и это работает лучше?
Делитесь в комментах, правда интересно.
Пруф: https://www.reddit.com/r/dataisbeautiful/comments/1qp1n0r/oc_for_the_past_3_years_ive_polled_people_on/
Как я разнес код интегратора и поплатился
В период моей работы в агрохолдинге нам поставили задачу внедрить 1С:УПП. Экспертизы не хватало, пригласили внедренцев. Нашли крупного интегратора, заключили договор.
Довелось поработать с группой во главе с Надеждой — хороший специалист. С ней работал опытный разработчик и Александра — отличный аналитик, которая только начинала пробовать себя в разработке.
Мне поставили задачу контролировать код. Тогда в 1С не было тестов и devops. Всё ручками. Ну а я же максималист / правдоруб 🙂
Открываю конфигуратор и погнали. С первых строчек стало не очень... Открыл Word, начал добавлять замечания. Пункты перевалили за 20. Запросы в цикле, мёртвый код, обилие закомментированных кусков.
В конце написал:
Вы крупный интегратор, вы занимаетесь автоматизацией и обслуживаете крупных клиентов. Непозволительно использовать в продакшн такой код. Это непрофессионально.Сейчас бы я так никогда не сделал. Я бы встретился с руководителем, обсудил, поговорил. Попытался бы оценить насколько там вменяемый человек и после этого принял бы решение как быть дальше. Идти к руководству, или мы бы поговорили и они бы исправили все замечания — и дело с концом.
Но тогда я не видел проблемы. Искренне думал: раз наша компания платит (немалые деньги), то я, как представитель заказчика, имею полное право требовать от исполнителей качества.
Эх, что после моих последних строк началось! Надежда была в ярости:
Виталий! Александра написала заявление на увольнение — это она делала этот код! Зачем ты так написал?! Что теперь делать с внедрением? Человек плачет, хочет уволиться. Она преподавала, но решила пойти в разработку, а ты так унизительно отозвался о её профессиональных качествах.Я тоже не остался в долгу и спросил зачем они поставили писать код человека, который совсем нулевой? Почему опытный разработчик, который был с ними в команде, не провёл своё ревью? Мы разругались тогда с ней очень серьёзно. Вплоть до того, что потом не разговаривали.
А дальше опытный разработчик с их стороны всё поправил и проект поехал дальше. Но шёл с огромным скрипом. А через время я уволился.
Всё было бы просто, если бы это был конец истории. Но нет.
Супруга общалась с коллегой Ириной. Муж и жена — одна сатана, мы познакомились, завязалось общение. Через время Ира родила дочь и решила покрестить. Позвала меня крёстным. Спросил, кто будет крёстной — внятного ответа не получил. Чувствуете куда катится история? )))
День крещения — та-да-ам! Надежда будет крёстной! Стоим и смотрим друг на друга. Немая пауза: «ты что здесь делаешь?» 🙂
Всё обошлось. Время и неловкость сбили негатив.
К чему история? ИТ-мир тесный. Земля круглая. Сегодня разносишь чей-то код, а через пару лет стоишь с этим человеком у купели.
После той ситуации я стал по-другому подходить к ревью. Не то чтобы стал добрее — просто понял, что за каждым куском кода стоит живой человек. Можно написать "запрос в цикле, исправить" — и получить тот же результат. А можно написать "непрофессионально" — и получить заявление на увольнение и испорченные отношения на годы.
Если вижу слабый код от подрядчика, стараюсь сначала поговорить с руководителем. Обсудить, понять контекст. Замечания — к коду, не к человеку. Звучит банально, но мне потребовался скандал и случайная встреча на крестинах, чтобы это до меня дошло.
В период моей работы в агрохолдинге нам поставили задачу внедрить 1С:УПП. Экспертизы не хватало, пригласили внедренцев. Нашли крупного интегратора, заключили договор.
Довелось поработать с группой во главе с Надеждой — хороший специалист. С ней работал опытный разработчик и Александра — отличный аналитик, которая только начинала пробовать себя в разработке.
Мне поставили задачу контролировать код. Тогда в 1С не было тестов и devops. Всё ручками. Ну а я же максималист / правдоруб 🙂
Открываю конфигуратор и погнали. С первых строчек стало не очень... Открыл Word, начал добавлять замечания. Пункты перевалили за 20. Запросы в цикле, мёртвый код, обилие закомментированных кусков.
В конце написал:
Вы крупный интегратор, вы занимаетесь автоматизацией и обслуживаете крупных клиентов. Непозволительно использовать в продакшн такой код. Это непрофессионально.Сейчас бы я так никогда не сделал. Я бы встретился с руководителем, обсудил, поговорил. Попытался бы оценить насколько там вменяемый человек и после этого принял бы решение как быть дальше. Идти к руководству, или мы бы поговорили и они бы исправили все замечания — и дело с концом.
Но тогда я не видел проблемы. Искренне думал: раз наша компания платит (немалые деньги), то я, как представитель заказчика, имею полное право требовать от исполнителей качества.
Эх, что после моих последних строк началось! Надежда была в ярости:
Виталий! Александра написала заявление на увольнение — это она делала этот код! Зачем ты так написал?! Что теперь делать с внедрением? Человек плачет, хочет уволиться. Она преподавала, но решила пойти в разработку, а ты так унизительно отозвался о её профессиональных качествах.Я тоже не остался в долгу и спросил зачем они поставили писать код человека, который совсем нулевой? Почему опытный разработчик, который был с ними в команде, не провёл своё ревью? Мы разругались тогда с ней очень серьёзно. Вплоть до того, что потом не разговаривали.
А дальше опытный разработчик с их стороны всё поправил и проект поехал дальше. Но шёл с огромным скрипом. А через время я уволился.
Всё было бы просто, если бы это был конец истории. Но нет.
Супруга общалась с коллегой Ириной. Муж и жена — одна сатана, мы познакомились, завязалось общение. Через время Ира родила дочь и решила покрестить. Позвала меня крёстным. Спросил, кто будет крёстной — внятного ответа не получил. Чувствуете куда катится история? )))
День крещения — та-да-ам! Надежда будет крёстной! Стоим и смотрим друг на друга. Немая пауза: «ты что здесь делаешь?» 🙂
Всё обошлось. Время и неловкость сбили негатив.
К чему история? ИТ-мир тесный. Земля круглая. Сегодня разносишь чей-то код, а через пару лет стоишь с этим человеком у купели.
После той ситуации я стал по-другому подходить к ревью. Не то чтобы стал добрее — просто понял, что за каждым куском кода стоит живой человек. Можно написать "запрос в цикле, исправить" — и получить тот же результат. А можно написать "непрофессионально" — и получить заявление на увольнение и испорченные отношения на годы.
Если вижу слабый код от подрядчика, стараюсь сначала поговорить с руководителем. Обсудить, понять контекст. Замечания — к коду, не к человеку. Звучит банально, но мне потребовался скандал и случайная встреча на крестинах, чтобы это до меня дошло.
🔥4👍1
Я был не прав про ИИ в 1С
Полгода назад я написал статью Искусственный интеллект в 1С: будущее и перспективы и довольно скептически оценил перспективы ИИ в разработке на 1С. Говорил про контекстное окно, про поздний старт компании 1С в ИИ-гонке, про нехватку обучающих данных на BSL. Выводы были пессимистичные.
Сегодня признаю: я ошибся. Не во всём, но в главном. ИИ уже может продуктивно работать с кодом 1С. Не когда-нибудь потом, а прямо сейчас.
Что изменилось
Я недооценил MCP (Model Context Protocol). Когда писал ту статью, мыслил в парадигме «закинуть весь контекст конфигурации в нейросеть». Это невозможно, конфигурации 1С огромны. Но MCP перевернул подход. Вместо того чтобы загружать весь контекст, мы даём нейросети инструменты для работы с ним. Как обычному программисту: открыл модуль, посмотрел код, нашёл нужное, написал своё.
Проблема контекстного окна решена. Не расширением окна, а сменой подхода.
Claude Code Max
Я взял подписку Claude Code Max и после первого месяца понял, что назад дороги нет. Claude Opus в агентном режиме цепко держит контекст задачи, планирует выполнение, запускает субагентов и параллелит работу. Не теряется на полпути, доводит до конца. Моя скорость ощутимо выросла.
Купил Max-подписку и для команды. Да, дорого. Но я смотрю на это иначе: у каждого разработчика появляется персональный Junior/Middle помощник. Он и код напишет, и тесты подготовит, и документацию оформит. Попробуйте нанять живого джуна за эти деньги))
EDT-MCP: ИИ в 1C:EDT
Расширение EDT-MCP придумал и реализовал Дмитрий Шерстобитов. Я тоже участвую в развитии проекта.
В 1C:EDT уже есть всё, чем пользуется программист: поиск по коду, автодополнение, BSL-проверки, семантический поиск. Идея: отдать всё это нейросети через MCP. Посадить ИИ за EDT как обычного программиста.
И этот подход работает. Открываешь 1C:EDT с проектом, рядом запускаешь VS Code с той же папкой и пишешь задачу в чате. ИИ через MCP получает контекст из EDT, проверяет код, использует подсказки платформы, методы, семантический поиск. На выходе получается довольно качественный код.
Но есть границы. Формы верстать через MCP пока нельзя, и тут начинаются проблемы. Что-то простое нейросеть соберёт сама, но сложная вёрстка форм пока ей не по зубам. Это ограничение конкретного MCP, не подхода в целом.
Почему не RAG
В сообществе 1С я видел другой подход: RAG-системы плюс MCP по справке платформы. Индексируют документацию, встраивают в векторные базы, поднимают Qdrant, Embeddings, пачку Docker-контейнеров.
Считаю этот подход тупиковым. Разработчику не нужны конспекты. Мы открываем код и понимаем, как он работает. Базовые концепции держим в голове, остальное находим по ситуации.
Мне нравится аналогия с Tesla Vision. Tesla отказалась от лидаров и полагается только на камеры. Казалось бы, лидар надёжнее: точные данные о расстояниях, трёхмерная карта пространства. Но логика Tesla проста: если человек справляется с вождением, используя только глаза, значит и машина может.
С RAG нужно постоянно индексировать. Данные устарели, нейросеть найдёт неактуальное. Как индексировать, какие модели для векторизации, как поддерживать базу? Лишний слой сложности.
MCP-подход проще. Дай нейросети инструменты, пусть работает с живым кодом напрямую. Как программист. Да, что-то записывает себе куда-то, но не тотально, а только то, что важно в проекте.
Итого
ИИ в разработке 1С работает. Не идеально, с ограничениями по формам, но работает. Claude Code плюс EDT-MCP уже дают ощутимый прирост скорости.
Не нужно ждать, пока фирма «1С» сделает свой ИИ-инструмент. Сообщество уже создаёт решения, которые можно использовать. Чем раньше начнёте, тем больше выиграете.
Полгода назад я написал статью Искусственный интеллект в 1С: будущее и перспективы и довольно скептически оценил перспективы ИИ в разработке на 1С. Говорил про контекстное окно, про поздний старт компании 1С в ИИ-гонке, про нехватку обучающих данных на BSL. Выводы были пессимистичные.
Сегодня признаю: я ошибся. Не во всём, но в главном. ИИ уже может продуктивно работать с кодом 1С. Не когда-нибудь потом, а прямо сейчас.
Что изменилось
Я недооценил MCP (Model Context Protocol). Когда писал ту статью, мыслил в парадигме «закинуть весь контекст конфигурации в нейросеть». Это невозможно, конфигурации 1С огромны. Но MCP перевернул подход. Вместо того чтобы загружать весь контекст, мы даём нейросети инструменты для работы с ним. Как обычному программисту: открыл модуль, посмотрел код, нашёл нужное, написал своё.
Проблема контекстного окна решена. Не расширением окна, а сменой подхода.
Claude Code Max
Я взял подписку Claude Code Max и после первого месяца понял, что назад дороги нет. Claude Opus в агентном режиме цепко держит контекст задачи, планирует выполнение, запускает субагентов и параллелит работу. Не теряется на полпути, доводит до конца. Моя скорость ощутимо выросла.
Купил Max-подписку и для команды. Да, дорого. Но я смотрю на это иначе: у каждого разработчика появляется персональный Junior/Middle помощник. Он и код напишет, и тесты подготовит, и документацию оформит. Попробуйте нанять живого джуна за эти деньги))
EDT-MCP: ИИ в 1C:EDT
Расширение EDT-MCP придумал и реализовал Дмитрий Шерстобитов. Я тоже участвую в развитии проекта.
В 1C:EDT уже есть всё, чем пользуется программист: поиск по коду, автодополнение, BSL-проверки, семантический поиск. Идея: отдать всё это нейросети через MCP. Посадить ИИ за EDT как обычного программиста.
И этот подход работает. Открываешь 1C:EDT с проектом, рядом запускаешь VS Code с той же папкой и пишешь задачу в чате. ИИ через MCP получает контекст из EDT, проверяет код, использует подсказки платформы, методы, семантический поиск. На выходе получается довольно качественный код.
Но есть границы. Формы верстать через MCP пока нельзя, и тут начинаются проблемы. Что-то простое нейросеть соберёт сама, но сложная вёрстка форм пока ей не по зубам. Это ограничение конкретного MCP, не подхода в целом.
Почему не RAG
В сообществе 1С я видел другой подход: RAG-системы плюс MCP по справке платформы. Индексируют документацию, встраивают в векторные базы, поднимают Qdrant, Embeddings, пачку Docker-контейнеров.
Считаю этот подход тупиковым. Разработчику не нужны конспекты. Мы открываем код и понимаем, как он работает. Базовые концепции держим в голове, остальное находим по ситуации.
Мне нравится аналогия с Tesla Vision. Tesla отказалась от лидаров и полагается только на камеры. Казалось бы, лидар надёжнее: точные данные о расстояниях, трёхмерная карта пространства. Но логика Tesla проста: если человек справляется с вождением, используя только глаза, значит и машина может.
С RAG нужно постоянно индексировать. Данные устарели, нейросеть найдёт неактуальное. Как индексировать, какие модели для векторизации, как поддерживать базу? Лишний слой сложности.
MCP-подход проще. Дай нейросети инструменты, пусть работает с живым кодом напрямую. Как программист. Да, что-то записывает себе куда-то, но не тотально, а только то, что важно в проекте.
Итого
ИИ в разработке 1С работает. Не идеально, с ограничениями по формам, но работает. Claude Code плюс EDT-MCP уже дают ощутимый прирост скорости.
Не нужно ждать, пока фирма «1С» сделает свой ИИ-инструмент. Сообщество уже создаёт решения, которые можно использовать. Чем раньше начнёте, тем больше выиграете.
👍2🔥1
Сеньор не сеньор?
Недавно наткнулся на пост, где автор сравнивает типичного разработчика «сеньора» с водителем, который 8 лет ездил по одному маршруту до магазина и обратно, а теперь называет себя профессиональным гонщиком. Грубовато, но в точку.
Сеньоров на рынке с каждым годом всё больше. Сеньорности правда всё меньше :)
Откуда они берутся
Во многих компаниях грейд-система заканчивается на Senior. Отработал 5-8 лет, прошёл пару повышений, а дальше расти некуда. Только в тимлиды, а это вообще другая профессия. Грейд присваивается по выслуге лет. В стартапах ещё проще: ты единственный разработчик, вот тебе и Senior в резюме.
В 1С-мире все тоже самое. Человек 10 лет сопровождает одну конфигурацию на одном предприятии. Знает её вдоль и поперёк. Но ни разу не проектировал ничего с нуля, не трогал нагруженные системы, не принимал решений, от которых зависит продукт целиком. И при этом на собеседовании говорит: «Я сеньор, у меня десять лет опыта». Он прав? Конечно нет.
А в чём разница?
Вот что я заметил за годы найма. Опыт, штука обманчивая. Можно десять лет расти, а можно один год прожить десять раз подряд.
Человек, которого я про себя называю сеньором, думает не про свой модуль. Он думает про систему в целом. Прикидывает, во сколько обойдётся поддержка через пару лет и куда развивать продукт. Когда команда буксует, не ждёт, пока кто-то разрулит, а сам лезет разбираться. Ну и да, берёт на себя ответственность за результат. Не за тикет, не за свой кусок кода, а за результат.
Почему меня это беспокоит
Для бизнеса это конкретные деньги. Платишь сеньорную зарплату, ждёшь, что человек потянет проект. А получаешь исполнителя, который сидит и ждёт задачу.
Для самих разработчиков тут ловушка еще хуже. Получил грейд, и мотивация расти куда-то испаряется. Зачем напрягаться, если ты уже на верхней ступеньке? Это как чёрный пояс после трёх лет тренировок, звучит красиво, но на ринге бесполезно.
Что я делаю у себя
Резюме я давно не читаю всерьёз, тем более сейчас в эпоху ИИ. Конечно, пробегаю глазами, но решение принимаю по другому: как человек думает, какие вопросы задаёт, что делает, когда задача размытая.
Уважаю, когда разработчик берет задачу, где заведомо не хватает данных и начинает уточнять контекст и предлагать варианты. С таким интересно разговаривать и приходить к решению. Тот, кто спрашивает «а где ТЗ?», ну, тоже нормальный специалист. Просто не сеньор.
А если ты разработчик и читаешь это, то тебе один совет. Оторвись от своего модуля. Разберись, зачем бизнесу то, что ты пишешь. Кто этим пользуется, какие у них боли? Сеньорность начинается не с количества отработанных лет в резюме, а с момента, когда тебе становится не всё равно, что происходит за пределами твоего кода.
Недавно наткнулся на пост, где автор сравнивает типичного разработчика «сеньора» с водителем, который 8 лет ездил по одному маршруту до магазина и обратно, а теперь называет себя профессиональным гонщиком. Грубовато, но в точку.
Сеньоров на рынке с каждым годом всё больше. Сеньорности правда всё меньше :)
Откуда они берутся
Во многих компаниях грейд-система заканчивается на Senior. Отработал 5-8 лет, прошёл пару повышений, а дальше расти некуда. Только в тимлиды, а это вообще другая профессия. Грейд присваивается по выслуге лет. В стартапах ещё проще: ты единственный разработчик, вот тебе и Senior в резюме.
В 1С-мире все тоже самое. Человек 10 лет сопровождает одну конфигурацию на одном предприятии. Знает её вдоль и поперёк. Но ни разу не проектировал ничего с нуля, не трогал нагруженные системы, не принимал решений, от которых зависит продукт целиком. И при этом на собеседовании говорит: «Я сеньор, у меня десять лет опыта». Он прав? Конечно нет.
А в чём разница?
Вот что я заметил за годы найма. Опыт, штука обманчивая. Можно десять лет расти, а можно один год прожить десять раз подряд.
Человек, которого я про себя называю сеньором, думает не про свой модуль. Он думает про систему в целом. Прикидывает, во сколько обойдётся поддержка через пару лет и куда развивать продукт. Когда команда буксует, не ждёт, пока кто-то разрулит, а сам лезет разбираться. Ну и да, берёт на себя ответственность за результат. Не за тикет, не за свой кусок кода, а за результат.
Почему меня это беспокоит
Для бизнеса это конкретные деньги. Платишь сеньорную зарплату, ждёшь, что человек потянет проект. А получаешь исполнителя, который сидит и ждёт задачу.
Для самих разработчиков тут ловушка еще хуже. Получил грейд, и мотивация расти куда-то испаряется. Зачем напрягаться, если ты уже на верхней ступеньке? Это как чёрный пояс после трёх лет тренировок, звучит красиво, но на ринге бесполезно.
Что я делаю у себя
Резюме я давно не читаю всерьёз, тем более сейчас в эпоху ИИ. Конечно, пробегаю глазами, но решение принимаю по другому: как человек думает, какие вопросы задаёт, что делает, когда задача размытая.
Уважаю, когда разработчик берет задачу, где заведомо не хватает данных и начинает уточнять контекст и предлагать варианты. С таким интересно разговаривать и приходить к решению. Тот, кто спрашивает «а где ТЗ?», ну, тоже нормальный специалист. Просто не сеньор.
А если ты разработчик и читаешь это, то тебе один совет. Оторвись от своего модуля. Разберись, зачем бизнесу то, что ты пишешь. Кто этим пользуется, какие у них боли? Сеньорность начинается не с количества отработанных лет в резюме, а с момента, когда тебе становится не всё равно, что происходит за пределами твоего кода.
👍8👀1
X в 2026-м напомнил, что такое хороший продуктовый сдвиг
Не думал, что соцсеть сможет меня удивить в 2026 году. X удивил.
Никогда особо не тяготел к Twitter. Заходил, смотрел, уходил. Много английского текста, чужие алгоритмы, общий шум. Не моё.
8 апреля X раскатал автоперевод на всех пользователей, и что-то поменялось. Лента читается на русском. Без кнопки «перевести», без копирования в переводчик. Работает по умолчанию, под капотом Grok.
Технически фича не новая, X экспериментировал с ней через Grok ещё с середины 2025-го. Но одно дело эксперимент для части пользователей, другое, дефолт для всех. И вот в этом переключателе, на мой взгляд, и есть главный урок.
Звучит как мелочь, но попробуйте. Подписываешься на американского CTO, японского инженера или аргентинского стартапера и просто читаешь их мысли на родном языке. Доступ к первоисточникам без языкового барьера.
Без ложки дёгтя не обошлось. Первые дни часть пользователей злилась, не могла понять, что произошло, и искала, как это отключить. Классическая история: хорошая фича, плохой онбординг. Дефолты надо менять аккуратно, иначе даже правильное решение получает волну негатива.
И главный вопрос, который меня зацепил: почему другие так не сделали раньше? Telegram, VK, LinkedIn, везде либо кнопка на каждый пост, либо никак. Но X показал, что в 2026-м это уже решаемо. И тот, кто первым сделал фичу дефолтной, выиграл больше, чем тот, у кого она есть «по кнопке».
Дефолты решают. Почти всегда.
Пользуетесь X? Заметили изменение? Как вам качество перевода? 🤔
Не думал, что соцсеть сможет меня удивить в 2026 году. X удивил.
Никогда особо не тяготел к Twitter. Заходил, смотрел, уходил. Много английского текста, чужие алгоритмы, общий шум. Не моё.
8 апреля X раскатал автоперевод на всех пользователей, и что-то поменялось. Лента читается на русском. Без кнопки «перевести», без копирования в переводчик. Работает по умолчанию, под капотом Grok.
Технически фича не новая, X экспериментировал с ней через Grok ещё с середины 2025-го. Но одно дело эксперимент для части пользователей, другое, дефолт для всех. И вот в этом переключателе, на мой взгляд, и есть главный урок.
Звучит как мелочь, но попробуйте. Подписываешься на американского CTO, японского инженера или аргентинского стартапера и просто читаешь их мысли на родном языке. Доступ к первоисточникам без языкового барьера.
Без ложки дёгтя не обошлось. Первые дни часть пользователей злилась, не могла понять, что произошло, и искала, как это отключить. Классическая история: хорошая фича, плохой онбординг. Дефолты надо менять аккуратно, иначе даже правильное решение получает волну негатива.
И главный вопрос, который меня зацепил: почему другие так не сделали раньше? Telegram, VK, LinkedIn, везде либо кнопка на каждый пост, либо никак. Но X показал, что в 2026-м это уже решаемо. И тот, кто первым сделал фичу дефолтной, выиграл больше, чем тот, у кого она есть «по кнопке».
Дефолты решают. Почти всегда.
Пользуетесь X? Заметили изменение? Как вам качество перевода? 🤔
👍5
DDoS нашего сайта. Кто-то реально ходит на работу
Где-то недели две назад нас прощупывали. Рабочий сайт тупил. Часик так поработает и пауза. Какое-то время на это не обращал внимание, пока вчера сайт полностью не лег на целый день.
Сижу, смотрю в логи. За вчерашние сутки — 2 447 964 запроса. Средний RPS 28, в пиковые часы с 08:00 до 16:00, по 170 тысяч запросов в час, это ~50 RPS. Сегодня все в том же темпе.
У меня честный вопрос: кому мы мешаем? Мы небольшая IT-компания в нише, где нет большой политики и миллиардных контрактов. Конкуренты? Обиженный клиент? Пытаются сделать больно нашим клиентам в рабочее время? Разбираюсь по фактам.
Провел небольшое расследование и собрал статистику:
Всего запросов: 2 447 964
Средний RPS: 28
Пиковый час (16:00): 177 164 запросов
Минимум (20:00): 10 303 запросов
Вчерашнее распределение по часам:
С 07:00 до 18:00 стабильные 120-170 тысяч запросов в час. В 19:00 обрыв в 10 раз. В 21:00 — снова подъём до 34 тысяч. Ночью — средние 50-90 тысяч.
Бот, запущенный в режиме «поставил и ушёл», так себя не ведёт. Тут либо живой оператор, либо скрипт с расписанием, которому выставлены разные режимы на разные часы. И цель не «уронить сайт намертво», а именно замедлять его в рабочее время. С 19:00 до 20:00 — что-то вроде «ужина», потом снова вечерняя смена.
И самое показательное — поисковые запросы :
Это наши собственные теги из базы знаний продукта Управление IT-отделом 8. Кто-то ходил по сайту руками, собрал теги конкретно по нашему продукту (даже с указанием версий 3.0.37, 3.1.2, 3.1.6, 3.1.12.7) и скормил их боту. Атака «на авось» так не умеет. Это разведка, сделанная человеком, понимающим, что у нас за продукт и где у нас тяжёлые запросы.
Выводы
Атака распределённая (сотни уникальных IP, по 700-1400 запросов с каждого), но не из ботнета — это арендованная VPS-ферма.
Атака имитирует браузер: подтягивает всю статику, шлёт легальные URL.
Атака с предварительной разведкой: атакующий собрал конкретно наши теги с нашими версиями продукта.
Атака с живым оператором: работает по графику рабочего дня, ротирует источники день ко дню.
Бюджет атакующего — сотни долларов в месяц.
Три гипотезы, кому мы помешали
Без IR-расследования точного ответа не будет. Но версии стоит перебрать.
1. Конкуренты. Работа по графику рабочего дня, ручной подбор тегов по нашему продукту с номерами версий, ротация источников — всё указывает сюда. Аналитики РБК и Positive Technologies прямо говорят: DDoS как инструмент конкурентной борьбы чаще всего заказывают в узких нишах, где «немного просесть» конкуренту — заметный плюс себе. Ниша B2B-софта с понятной клиентской базой — идеальная мишень.
2. Отвлечение внимания. DDoS как дымовая завеса под другую активность: попытка эксплойта, брутфорс, вынос данных. В отчётах «Лаборатории Касперского» и «Солара» это второй по популярности сценарий 2025-го. Мы прошлись по логам аутентификаций и подозрительных POST — пока чисто, но внимание держим.
3. Заказ «на сдачу». Бывший клиент, бывший сотрудник. В 2025-м заказать DDoS стало тривиально: по Forbes и «Ростелекому», медианная цена атаки в даркнете — 20 долларов. Но наша атака дороже. Это не разовая покупка на 20 долларов, это длительный заказ с ротацией. Если «на сдачу», то от сильно обиженного с деньгами.
Я склоняюсь к первой версии.
А как вы защищаете свои сайты?
Где-то недели две назад нас прощупывали. Рабочий сайт тупил. Часик так поработает и пауза. Какое-то время на это не обращал внимание, пока вчера сайт полностью не лег на целый день.
Сижу, смотрю в логи. За вчерашние сутки — 2 447 964 запроса. Средний RPS 28, в пиковые часы с 08:00 до 16:00, по 170 тысяч запросов в час, это ~50 RPS. Сегодня все в том же темпе.
У меня честный вопрос: кому мы мешаем? Мы небольшая IT-компания в нише, где нет большой политики и миллиардных контрактов. Конкуренты? Обиженный клиент? Пытаются сделать больно нашим клиентам в рабочее время? Разбираюсь по фактам.
Провел небольшое расследование и собрал статистику:
Всего запросов: 2 447 964
Средний RPS: 28
Пиковый час (16:00): 177 164 запросов
Минимум (20:00): 10 303 запросов
Вчерашнее распределение по часам:
=== Нагрузка по часам (вчера) ===
00:00 — 84 690 запросов
01:00 — 42 586
02:00 — 57 603
03:00 — 75 511
04:00 — 91 871
05:00 — 94 590
06:00 — 98 846
07:00 — 146 990
08:00 — 171 044 ← пик утренний
09:00 — 140 138
10:00 — 161 200
11:00 — 140 094
12:00 — 148 158
13:00 — 112 530
14:00 — 141 870
15:00 — 121 985
16:00 — 177 164 ← пик вечерний, максимум дня
17:00 — 162 475
18:00 — 127 229
19:00 — 12 267 ← обрыв, -90%
20:00 — 10 303 ← минимум
21:00 — 34 834
22:00 — 35 838
23:00 — 58 148
С 07:00 до 18:00 стабильные 120-170 тысяч запросов в час. В 19:00 обрыв в 10 раз. В 21:00 — снова подъём до 34 тысяч. Ночью — средние 50-90 тысяч.
Бот, запущенный в режиме «поставил и ушёл», так себя не ведёт. Тут либо живой оператор, либо скрипт с расписанием, которому выставлены разные режимы на разные часы. И цель не «уронить сайт намертво», а именно замедлять его в рабочее время. С 19:00 до 20:00 — что-то вроде «ужина», потом снова вечерняя смена.
И самое показательное — поисковые запросы :
/search/?tags=Markdown,База знаний,Linux
/search/?tags=ITIL,договор,удаление данных
/search/?tags=3.1.6,вложения,обновления,личный кабинет
/search/?tags=3.1.2,обновление,Управление IT-отделом 8,пароли
/search/?tags=3.1.12.7,канбан,обновления,задание,уведомления
Это наши собственные теги из базы знаний продукта Управление IT-отделом 8. Кто-то ходил по сайту руками, собрал теги конкретно по нашему продукту (даже с указанием версий 3.0.37, 3.1.2, 3.1.6, 3.1.12.7) и скормил их боту. Атака «на авось» так не умеет. Это разведка, сделанная человеком, понимающим, что у нас за продукт и где у нас тяжёлые запросы.
Выводы
Атака распределённая (сотни уникальных IP, по 700-1400 запросов с каждого), но не из ботнета — это арендованная VPS-ферма.
Атака имитирует браузер: подтягивает всю статику, шлёт легальные URL.
Атака с предварительной разведкой: атакующий собрал конкретно наши теги с нашими версиями продукта.
Атака с живым оператором: работает по графику рабочего дня, ротирует источники день ко дню.
Бюджет атакующего — сотни долларов в месяц.
Три гипотезы, кому мы помешали
Без IR-расследования точного ответа не будет. Но версии стоит перебрать.
1. Конкуренты. Работа по графику рабочего дня, ручной подбор тегов по нашему продукту с номерами версий, ротация источников — всё указывает сюда. Аналитики РБК и Positive Technologies прямо говорят: DDoS как инструмент конкурентной борьбы чаще всего заказывают в узких нишах, где «немного просесть» конкуренту — заметный плюс себе. Ниша B2B-софта с понятной клиентской базой — идеальная мишень.
2. Отвлечение внимания. DDoS как дымовая завеса под другую активность: попытка эксплойта, брутфорс, вынос данных. В отчётах «Лаборатории Касперского» и «Солара» это второй по популярности сценарий 2025-го. Мы прошлись по логам аутентификаций и подозрительных POST — пока чисто, но внимание держим.
3. Заказ «на сдачу». Бывший клиент, бывший сотрудник. В 2025-м заказать DDoS стало тривиально: по Forbes и «Ростелекому», медианная цена атаки в даркнете — 20 долларов. Но наша атака дороже. Это не разовая покупка на 20 долларов, это длительный заказ с ротацией. Если «на сдачу», то от сильно обиженного с деньгами.
Я склоняюсь к первой версии.
А как вы защищаете свои сайты?
👍1