Обработка персональных данных на сайтах. Началось.

Обратил внимание на свежую новость на Хабре.  1 сентября заработали новые положения закона о персональных данных и Роскомнадзор приступил к поиску нарушителей.
Что это? Это предписание исправить на сайте все, что связано с законом, которое заставило меня задуматься. Автор на Хабре подробно разбирает новые требования Роскомнадзора и приводит реальные примеры, когда предприниматели уже получили «письма счастья». Суммы штрафов за повторные нарушения впечатляют, и я решил не откладывать в долгий ящик и провести аудит нашего корпоративного сайта Софтонит.

А самый главный прикол знаете в чем? Скорее всего, все происходит в автоматическом режиме.

Ключевые моменты из статьи на Хабре

Если кратко, то Роскомнадзор теперь уделяет пристальное внимание следующим вещам:

- Активное согласие: Пользователь должен сам поставить галочку в чекбоксе. Предустановленные галочки или пассивное согласие (когда отправка формы автоматически означает согласие) теперь вне закона.
- Четкая политика: На сайте должна быть опубликована «Политика обработки персональных данных», и ссылка на неё должна быть у каждой формы сбора данных.
- Cookies и аналитика: Если используете Яндекс.Метрику или другие счётчики, вы обязаны уведомлять об этом пользователей и получать их согласие.
- Реестр операторов: Все, кто обрабатывает персональные данные, должны быть зарегистрированы в реестре Роскомнадзора.
- Трансграничная передача данных. Это вообще отдельная песня... Используете Google Analytics? Забудьте. Лучше отказаться.

Аудит нашего сайта: что я нашел и исправил

К моему удивлению, даже у нас нашлись недочеты. Вот что было не так:
- Пассивное согласие на обработку. У нас на сайте есть две формы: «Запрос демо-версии» и «Заказ обратного звонка». В обеих формах текст под кнопкой отправки просто уведомлял пользователя, что, нажимая на кнопку, он соглашается с обработкой данных. Это и есть пассивное согласие, которое теперь запрещено.
- Некорректное название документа. Ссылка вела на документ под названием «Политика обработки персональных данных», хотя по закону должен быть документ «Согласие на обработку персональных данных». И эти два документа должны быть разделены. Мелочь, а может стать причиной для штрафа.
Я оперативно внес исправления. Теперь формы выглядят корректно. Кнопку нельзя нажать, пока чек-бокс не будет установлен.

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

Проверьте свои формы, наличие правильной политики и активных чекбоксов. Убедитесь, что вы не нарушаете закон.

Йети, который подсматривает ваш пароль. Зачем делать интерфейсы живыми?

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

Вводные
Итак, у нас есть обычная форма входа: логин, пароль и кнопка входа. Функционально, скучно, знакомо. Мы видим такое каждый день и не замечаем. А теперь вообразите, что под полями сидит веселый анимированный персонаж. Например, йети.

Вводим логин
Когда вы печатаете логин, он с интересом водит глазами за курсором. Как только вы начинаете вводить пароль, он в страхе закрывает глаза лапами — секрет есть секрет 🙂 Нажали на значок «показать пароль»? Йети с хитростью приоткрывает один глаз и смотрит. Ввели всё правильно — он рад. Сделали ошибку — он хватается за голову.

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

Готовые примеры кода есть на Codepen. Это позволяет довольно легко встроить такую функцию в свой веб-проект.

Что это и как устроено?
Эта идея существует давно. Один из хороших примеров — проект «Teddy», который сделал веб-дизайнер Дарин Сенеф. Технически он состоит из трех частей:

1. SVG-анимация: Персонаж нарисован в формате SVG. Поэтому он легкий, меняет размер без потери качества, и его легко анимировать.
2. CSS: Стили делают переходы между состояниями анимации плавными.
3. JavaScript: Скрипт следит за действиями пользователя — выбор поля, ввод букв, нажатие кнопок — и меняет состояние персонажа.

Почему это полезнее, чем просто украшение?

Для руководителя ИТ в разработке любая функция должна иметь цель. Добавление такого персонажа — это не бесполезная трата времени, а шаг, у которого есть несколько задач.

1. Уменьшение стресса и создание контакта
Форма входа может создавать преграду. Пользователь может неверно ввести пароль или логин. Это вызывает небольшое раздражение. Смешная реакция персонажа на ошибку делает этот опыт веселым и снимает напряжение. Пользователь начинает думать, что система дружелюбна. Это первый шаг к построению лояльности.
2. Узнаваемость и отличие от других
Ваш продукт больше не будет «просто еще одним сервисом». Он станет «тем сервисом со смешным йети». Эта деталь запоминается и хорошо отличает вас от конкурентов со стандартными, одинаковыми интерфейсами.
3. Увеличение интереса

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

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

- Скорость работы. Анимация, если она плохо сделана, может замедлить загрузку страницы входа. Это плохо, потому что скорость важна для хорошего впечатления. Решение: использовать легкий SVG-файл и простой JS-код.
- Уместность. Веселый элемент подходит не для всех продуктов. В программе для банка или управления важной системой он будет выглядеть странно и может снизить доверие. Но для CRM, менеджера задач или сайта компании это хорошее решение.
- Отвлечение. Некоторых пользователей анимация может отвлекать.

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

А вы видели похожие «живые» интерфейсы или какие-то не стандартные приемы шутки на сайтах или в интерфейсах программ? Что вам больше всего запомнилось? Напишите в комментариях!

Как WinRAR пережил эпохи и стал легендой? Продается уже более 30 лет (!)

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

1. Фокус на продукте, а не на бизнесе. Программист Евгений Рошал полностью сосредоточился на коде, в то время как его брат Александр взял на себя все юридические и коммерческие вопросы. Это позволило десятилетиями улучшать продукт, не отвлекаясь на управление.

2. Технология с ключевым преимуществом. Изначально RAR предлагал лучшее сжатие, чем ZIP. Но его «киллер-фича» — записи для восстановления, позволяющие «лечить» поврежденные архивы. Это сделало его незаменимым для надежного хранения данных.

3. Бизнес-модель, победившая пиратство. Легендарный «бесконечный триал» — это не ошибка, а стратегия. Зачем искать взломанную версию с вирусами, если официальная работает бесплатно? Это создало огромную базу из 500+ млн пользователей и сделало формат .rar стандартом. А деньги приносят корпоративные клиенты, которые по закону обязаны покупать лицензии.

Ключевые уроки от WinRAR:

- Решайте «скучные», но вечные задачи. Управление файлами нужно было вчера и будет нужно завтра.
- Сделайте легальный продукт удобнее пиратского. Лучшая защита — превосходный опыт.
- Эволюция важнее революции. Постоянные, продуманные улучшения создают доверие.
- Знайте свою главную силу. Рошал — кодер. Он не лез в продажи, и это спасло продукт.

WinRAR — это мощное напоминание, что долгосрочный успех строится на качестве и доверии, а не на погоне за хайпом.

PS: Пока готовил статью стало интересно и я увлекшись написал целый лонгрид где много интересных фактов и даже есть мерч с winrar 🙂

Неприятный инцидент в ЦОД с сервером. Монолит - это риск

На днях мы столкнулись с неприятным инцидентом в ЦОД. Один из двух наших физических серверов подхватил зловреда, похожего на шифровальщика. Несмотря на наличие средств защиты (Касперский), компрометация произошла. 😕
К счастью, инцидент был замечен быстро, и фатальных последствий для данных удалось избежать. Но ситуация заставила меня полностью переосмыслить текущий подход к инфраструктуре.

Главный вывод: Монолит — это зло.

До этого момента ключевые сервисы (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 каждый день, определи достаточный минимум. Сделать его — уже победа. Все, что сверху, — бонус, а не обязательство.
- Легализовать ошибки (для себя и коллег). Пропущенный срок — не провал, а повод для анализа системы. Что в процессе пошло не так? Понятно, что здесь речь не о факапах мирового уровня, но все мы люди и все ошибаемся.
- Планируй «ничегонеделание». Сон и отдых — это база. Но еще нужно время в календаре на «подумать» или «погулять без подкаста». Это не потеря времени, это восстановление ресурсов.
- Говори об этом. Признать, что ты перегружен — не слабость. Это дает и команде право не быть «всегда в форме», снижая общее напряжение.

А вы как с этим справляетесь? Сталкивались с тем, что система личной эффективности начинает работать против вас?
#РазборПродукта_КИД #Кейсы_КИД #Истории_КИД

Часть 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, тестовые среды и т.п.

Часть 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? Как решали?

Когда сервер «слабоват». Что делать со старым железом, если жалко выбросить?

В прошлом посте писал о том, что мы все же остановились на 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С?
#РазборПродукта_КИД #Бизнес_КИД

Налог на 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 — на платном сертификате. Кажется, мы свернули не туда.

Доступ к заблокированным иностранным сервисам и мысли на этот счет

Прошлая неделя прошла под лозунгом что-то опять заблокировали: 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 уже можно посмотреть результат.

А как вы решаете вопрос с обновлением общей документации из разных репозиториев? Делаете мульти-проектные пайплайны или тоже живете на расписании? 👇

Зачем мы строим планы, когда всё летит в тартарары?

Посмотрел на выходных выпуск-подкаст, тема была не совсем про ИТ. В подкасте говорили о несправедливости и личном выборе. Мне понравился один момент, который как мне кажется хорошо перекликается с ИТ-проектами.

Там зачитывают вопрос подписчика:

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

Знакомая ситуация для любого руководителя в последние годы. Лег сервер, уволился ключевой сотрудник, срываются сроки проекта и т.п.

Автор дает ответ, который меня зацепил: Это вопрос не про план, это вопрос про ощущение контроля.

Я почему-то никогда в такой парадигме не думал…

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

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

1. План превращает панику в процедуру. Яркий пример — это план аварийного восстановления. Упал сервер и никто не знает, когда поднимется. Хаос. Но если есть инструкция, команда не бегает с криками «мы все умрем», а спокойно по пунктам делает работу. План не тушит пожар, он тушит панику в головах инженеров.

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

3. Ловушка «иллюзии контроля». Тут важно быть честным, есть риск. В погоне за ощущением контроля руководители часто начинают управлять тем, до чего могут дотянуться, а не тем, что важно.

Не можешь гарантировать, что внешний провайдер не отключит API? От бессилия начинаешь следить, во сколько сотрудники приходят в офис, или считать строки кода. Вроде успокаивает — я же управляю! — но результат убивает. Такой вот карго-культ.

Резюме

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

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

Мне кажется, что это важная мысль и в текущее время это актуально как никогда. Планируйте проекты, друзья!

Искусственный интеллект нарушает цепочку развития программных продуктов и это 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.

Новая экономическая схема:

Клиент → Подписка на AI ($20/мес) → Нейросеть → Готовый код

В чем проблема?

Разработчик инструмента Tailwind выпал из цепочки. Финансы уходят не создателю технологии, а создателю нейросети.

Это создает парадокс:

- Фреймворк популярен как никогда.
- Денежный поток создателей иссякает.
- Компании вынуждены увольнять сотрудников и сокращать инвестиции в развитие.

Змея, пожирающая сама себя

Это не просто «проблемы бизнеса». Это проблема всей индустрии. Если такие компании, как Tailwind, перестанут развивать свои продукты из-за нехватки средств, на чем будут учиться следующие версии нейросетей?

Нейросети не создают новые фреймворки, они используют существующие. Мы рискуем получить ситуацию, где AI паразитирует на текущих технологиях, убивая их создателей, и тем самым останавливает приток новых идей.

Искусственный интеллект нарушает естественную цепочку «финансирование — инновации». В краткосрочной перспективе нам удобно (код пишется быстро), но в долгосрочной это 100% приведет к стагнации инструментов, которыми мы пользуемся.
#Кейсы_КИД #РазборПродукта_КИД #Бизнес_КИД https://t.me/codeitdir/75?utm_source=Telegram&utm_medium=social&utm_campaign=27859428

Я вырастил сеньора из саппорта, а он ушел

Открываю в блоге новую рубрику — «Управленческие задачи». Здесь не будет теории из учебников 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. Теперь цены растут, а альтернатив почти нет.

Меня вот что цепляет: мы как бизнес сидим на таких сервисах и вроде понимаем риски. Но каждый раз удивляемся, когда бесплатное становится платным. Я вот сам до сих пор плачу Яндексу, хотя технически мог бы съехать.

А вы как решаете? Платите и не паритесь, или ищете альтернативы?

За 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/

Как я разнес код интегратора и поплатился

В период моей работы в агрохолдинге нам поставили задачу внедрить 1С:УПП. Экспертизы не хватало, пригласили внедренцев. Нашли крупного интегратора, заключили договор.
Довелось поработать с группой во главе с Надеждой — хороший специалист. С ней работал опытный разработчик и Александра — отличный аналитик, которая только начинала пробовать себя в разработке.

Мне поставили задачу контролировать код. Тогда в 1С не было тестов и devops. Всё ручками. Ну а я же максималист / правдоруб 🙂
Открываю конфигуратор и погнали. С первых строчек стало не очень... Открыл Word, начал добавлять замечания. Пункты перевалили за 20. Запросы в цикле, мёртвый код, обилие закомментированных кусков.
В конце написал:
Вы крупный интегратор, вы занимаетесь автоматизацией и обслуживаете крупных клиентов. Непозволительно использовать в продакшн такой код. Это непрофессионально.Сейчас бы я так никогда не сделал. Я бы встретился с руководителем, обсудил, поговорил. Попытался бы оценить насколько там вменяемый человек и после этого принял бы решение как быть дальше. Идти к руководству, или мы бы поговорили и они бы исправили все замечания — и дело с концом.
Но тогда я не видел проблемы. Искренне думал: раз наша компания платит (немалые деньги), то я, как представитель заказчика, имею полное право требовать от исполнителей качества.

Эх, что после моих последних строк началось! Надежда была в ярости:
Виталий! Александра написала заявление на увольнение — это она делала этот код! Зачем ты так написал?! Что теперь делать с внедрением? Человек плачет, хочет уволиться. Она преподавала, но решила пойти в разработку, а ты так унизительно отозвался о её профессиональных качествах.Я тоже не остался в долгу и спросил зачем они поставили писать код человека, который совсем нулевой? Почему опытный разработчик, который был с ними в команде, не провёл своё ревью? Мы разругались тогда с ней очень серьёзно. Вплоть до того, что потом не разговаривали.

А дальше опытный разработчик с их стороны всё поправил и проект поехал дальше. Но шёл с огромным скрипом. А через время я уволился.

Всё было бы просто, если бы это был конец истории. Но нет.

Супруга общалась с коллегой Ириной. Муж и жена — одна сатана, мы познакомились, завязалось общение. Через время Ира родила дочь и решила покрестить. Позвала меня крёстным. Спросил, кто будет крёстной — внятного ответа не получил. Чувствуете куда катится история? )))

День крещения — та-да-ам! Надежда будет крёстной! Стоим и смотрим друг на друга. Немая пауза: «ты что здесь делаешь?» 🙂
Всё обошлось. Время и неловкость сбили негатив.

К чему история? ИТ-мир тесный. Земля круглая. Сегодня разносишь чей-то код, а через пару лет стоишь с этим человеком у купели.
После той ситуации я стал по-другому подходить к ревью. Не то чтобы стал добрее — просто понял, что за каждым куском кода стоит живой человек. Можно написать "запрос в цикле, исправить" — и получить тот же результат. А можно написать "непрофессионально" — и получить заявление на увольнение и испорченные отношения на годы.

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