1С и искусственный интеллект. Почему «1C:Напарник» — это только начало большого отставания?
Недавно поймал себя на мысли, что AI-ассистент в 1C:EDT, 1C:Напарник, заметно уступает тому же Cursor. Да, он помогает и автодополнение кода — это лучше, чем ничего. Но разница в качестве подсказок колоссальная.
И это не просто вопрос удобства. Этот маленький пример обнажил большую проблему: похоже, 1С, главный поставщик софта для российского бизнеса, серьёзно буксует в гонке искусственного интеллекта. Пока Сбер и Яндекс давно развивают свои модели, 1С только делает первые шаги.
Возможно я не прав и работа ведется давно, но 1С в этом плане не публичная компания. Что она развивает мы узнаем только по факту, когда выйдет первый релиз того, над чем работают.
Я вижу три фундаментальные проблемы, которые мешают 1С быстро сократить разрыв в ИИ:
Проблема №1: Архитектура и контекстное окно. Любая серьёзная конфигурация 1С — это гигантский объём метаданных и тысячи модулей. Даже топовые нейросети сегодня упираются в лимит контекстного окна. Как «объяснить» модели всю логику огромной ERP-системы, чтобы она писала качественный код, а не галлюцинировала? Архитектурно это очень сложная задача.
Проблема №2: Поздний старт. Компания, на мой взгляд, слишком долго не инвестировала в ИИ. Сейчас, когда на рынке уже есть модели, способные заменить джунов в популярных языках, 1С находится в позиции догоняющего. А в технологиях такой отрыв преодолеть крайне тяжело и дорого.
Проблема №3: Локальный язык. Модели вроде GPT обучаются на триллионах токенов кода с GitHub и всего интернета. А сколько в открытом доступе качественного кода на 1С? Язык — локальный, для рынка СНГ. Этого объёма данных катастрофически мало для обучения действительно мощной модели, которая будет понимать всю специфику платформы.
Что у 1С есть сейчас в арсенале ИИ? Если честно, немного:
- 1С:Напарник: Помощник с автодополнением кода.
- Распознавание документов: Полезно, но это уже стандарт индустрии, а не прорыв.
- Таймлист 1С: Расшифровка встреч. Тоже полезная утилита.
И, кажется, всё.
Я очень люблю платформу 1С и хочу видеть её на острие технологий. Но пока картина выглядит тревожно. Время покажет, сможет ли компания совершить технологический рывок.
Коллеги, а что вы думаете? Есть у 1С шансы догнать тренды? Или её нишевость в итоге станет её же ловушкой в мире повсеместного AI? Делитесь мыслями в комментариях.
Недавно поймал себя на мысли, что AI-ассистент в 1C:EDT, 1C:Напарник, заметно уступает тому же Cursor. Да, он помогает и автодополнение кода — это лучше, чем ничего. Но разница в качестве подсказок колоссальная.
И это не просто вопрос удобства. Этот маленький пример обнажил большую проблему: похоже, 1С, главный поставщик софта для российского бизнеса, серьёзно буксует в гонке искусственного интеллекта. Пока Сбер и Яндекс давно развивают свои модели, 1С только делает первые шаги.
Возможно я не прав и работа ведется давно, но 1С в этом плане не публичная компания. Что она развивает мы узнаем только по факту, когда выйдет первый релиз того, над чем работают.
Я вижу три фундаментальные проблемы, которые мешают 1С быстро сократить разрыв в ИИ:
Проблема №1: Архитектура и контекстное окно. Любая серьёзная конфигурация 1С — это гигантский объём метаданных и тысячи модулей. Даже топовые нейросети сегодня упираются в лимит контекстного окна. Как «объяснить» модели всю логику огромной ERP-системы, чтобы она писала качественный код, а не галлюцинировала? Архитектурно это очень сложная задача.
Проблема №2: Поздний старт. Компания, на мой взгляд, слишком долго не инвестировала в ИИ. Сейчас, когда на рынке уже есть модели, способные заменить джунов в популярных языках, 1С находится в позиции догоняющего. А в технологиях такой отрыв преодолеть крайне тяжело и дорого.
Проблема №3: Локальный язык. Модели вроде GPT обучаются на триллионах токенов кода с GitHub и всего интернета. А сколько в открытом доступе качественного кода на 1С? Язык — локальный, для рынка СНГ. Этого объёма данных катастрофически мало для обучения действительно мощной модели, которая будет понимать всю специфику платформы.
Что у 1С есть сейчас в арсенале ИИ? Если честно, немного:
- 1С:Напарник: Помощник с автодополнением кода.
- Распознавание документов: Полезно, но это уже стандарт индустрии, а не прорыв.
- Таймлист 1С: Расшифровка встреч. Тоже полезная утилита.
И, кажется, всё.
Я очень люблю платформу 1С и хочу видеть её на острие технологий. Но пока картина выглядит тревожно. Время покажет, сможет ли компания совершить технологический рывок.
Коллеги, а что вы думаете? Есть у 1С шансы догнать тренды? Или её нишевость в итоге станет её же ловушкой в мире повсеместного AI? Делитесь мыслями в комментариях.
👍3💯1
Как мой начальник «победил» юристов без единого скандала. Урок корпоративного Win-Win
Мне повезло. В самом начале своей карьеры я был под руководством толкового руководителя. Он был на несколько лет старше, но гораздо более опытнее в плане руководства в ИТ. Много фишек по управлению я подсмотрел именно у него.
Особенно в память врезалась одна история.
Ситуация: Пат
Представьте крупную компанию. IT-отдел постоянно что-то закупает. Юридический отдел — «любимчики» руководства, чувствуют свою власть и могут завернуть любой договор, прикрываясь «интересами компании». Даже там, где можно было легко договориться.
Нам срочно нужно оборудование. Оно есть только у одного поставщика в РФ. Поставщик дает свой типовой договор. Наши юристы — свое решительное «нет», требуют переделать всё под наш шаблон. Поставщик, устав от правок, вежливо посылает нас.
Тупик. Оборудование нужно как воздух. Юристы договор не пропускают. Без их визы никто ничего не оплатит.
Развязка: Картридж как рычаг давления
Иван не стал ругаться и писать докладные. Он взял паузу на пару дней.
Через некоторое время в наш кабинет заходит та самая сотрудница юротдела, которая курировала наш договор, и просит: «Вань, у нас картридж в МФУ закончился, а мне нужно срочно печатать кучу документов для суда. Заправьте, пожалуйста».
И тут Иван спокойно, без наезда, раскладывает пасьянс: «У меня тут ваш договор от единственного поставщика лежит. Оборудование купить не можем, всё стоит. Поставщик нашу редакцию не принимает».
Юрист всё поняла и улыбнулась.
Иван продолжил, уже улыбаясь в ответ: «Я, конечно, могу, как и вы, долго и скрупулезно искать поставщика картриджей и тонера, соблюдая все процедуры. У нас их как раз нехватка. И тогда, боюсь, по шапке прилетит нам обоим. А могу решить ваш вопрос прямо сейчас».
Они помолчали, глядя друг на друга. Затем она встала, дошла до двери, обернулась и сказала: «Приносите ваш договор…»
Когда она ушла, Ваня рассмеялся. Ни грамма грубости, никакого хамства. Просто два человека поняли интересы друг друга и договорились. Классический Win-Win.
Уроки, которые я извлек тогда и использую до сих пор
1. Ищите неформальные рычаги. Когда формальные процедуры заходят в тупик, ищите точки пересечения интересов в операционной плоскости. IT-отдел, как сервисная служба, имеет массу таких рычагов: от скорости реакции на заявку до приоритета в закупках.
2. Пауза — это стратегический ресурс. Мгновенная эскалация конфликта — признак слабости. Иногда нужно просто подождать, пока у оппонента не появится проблема, которую вы можете решить.
3. Авторитет зарабатывается решением проблем, а не криком. Иван не просто «прогнул» юристов. Он показал, что с ним можно и нужно договариваться. В следующий раз они дважды подумают, прежде чем бездумно блокировать его инициативу.
Некоторые скажут, что из таких компаний надо бежать. Возможно. Но корпоративные войны — неотъемлемая часть любой крупной организации. И если вы руководитель, вам придется научиться в них побеждать. Не криком и скандалами, а умом и пониманием чужих интересов.
Вспоминаю Ивана с огромной благодарностью. Он многому меня научил.
А как у вас выстроены отношения с юристами и бухгалтерией? Часто приходится «воевать» или находить нестандартные решения? Делитесь в комментариях!
Мне повезло. В самом начале своей карьеры я был под руководством толкового руководителя. Он был на несколько лет старше, но гораздо более опытнее в плане руководства в ИТ. Много фишек по управлению я подсмотрел именно у него.
Особенно в память врезалась одна история.
Ситуация: Пат
Представьте крупную компанию. IT-отдел постоянно что-то закупает. Юридический отдел — «любимчики» руководства, чувствуют свою власть и могут завернуть любой договор, прикрываясь «интересами компании». Даже там, где можно было легко договориться.
Нам срочно нужно оборудование. Оно есть только у одного поставщика в РФ. Поставщик дает свой типовой договор. Наши юристы — свое решительное «нет», требуют переделать всё под наш шаблон. Поставщик, устав от правок, вежливо посылает нас.
Тупик. Оборудование нужно как воздух. Юристы договор не пропускают. Без их визы никто ничего не оплатит.
Развязка: Картридж как рычаг давления
Иван не стал ругаться и писать докладные. Он взял паузу на пару дней.
Через некоторое время в наш кабинет заходит та самая сотрудница юротдела, которая курировала наш договор, и просит: «Вань, у нас картридж в МФУ закончился, а мне нужно срочно печатать кучу документов для суда. Заправьте, пожалуйста».
И тут Иван спокойно, без наезда, раскладывает пасьянс: «У меня тут ваш договор от единственного поставщика лежит. Оборудование купить не можем, всё стоит. Поставщик нашу редакцию не принимает».
Юрист всё поняла и улыбнулась.
Иван продолжил, уже улыбаясь в ответ: «Я, конечно, могу, как и вы, долго и скрупулезно искать поставщика картриджей и тонера, соблюдая все процедуры. У нас их как раз нехватка. И тогда, боюсь, по шапке прилетит нам обоим. А могу решить ваш вопрос прямо сейчас».
Они помолчали, глядя друг на друга. Затем она встала, дошла до двери, обернулась и сказала: «Приносите ваш договор…»
Когда она ушла, Ваня рассмеялся. Ни грамма грубости, никакого хамства. Просто два человека поняли интересы друг друга и договорились. Классический Win-Win.
Уроки, которые я извлек тогда и использую до сих пор
1. Ищите неформальные рычаги. Когда формальные процедуры заходят в тупик, ищите точки пересечения интересов в операционной плоскости. IT-отдел, как сервисная служба, имеет массу таких рычагов: от скорости реакции на заявку до приоритета в закупках.
2. Пауза — это стратегический ресурс. Мгновенная эскалация конфликта — признак слабости. Иногда нужно просто подождать, пока у оппонента не появится проблема, которую вы можете решить.
3. Авторитет зарабатывается решением проблем, а не криком. Иван не просто «прогнул» юристов. Он показал, что с ним можно и нужно договариваться. В следующий раз они дважды подумают, прежде чем бездумно блокировать его инициативу.
Некоторые скажут, что из таких компаний надо бежать. Возможно. Но корпоративные войны — неотъемлемая часть любой крупной организации. И если вы руководитель, вам придется научиться в них побеждать. Не криком и скандалами, а умом и пониманием чужих интересов.
Вспоминаю Ивана с огромной благодарностью. Он многому меня научил.
А как у вас выстроены отношения с юристами и бухгалтерией? Часто приходится «воевать» или находить нестандартные решения? Делитесь в комментариях!
Политика нулевой терпимости к багам в разработке ПО. Ловушка для перфекциониста или отличная штука?
Столкнулся недавно с идеей «Zero Bug Policy» (ZBP). Речь про политику нулевой терпимости к багам. Концепция простая: увидел баг — бросай всё и чини. Звучит как мечта: ошибки все исправлены, клиенты счастливы, а техподдержка пьет смузи.
Но мой опыт показывает, что такие лозунги часто ведут в ад переработок и демотивации. Давайте разберемся, почему ZBP — это чаще всего утопия, которая может навредить бизнесу больше, чем помочь.
На бумаге все выглядит классно:
- Нашли баг? Все бросаем и чиним. Никаких новых фич, пока в бэклоге есть хоть одна ошибка.
- Результат? Код всегда в идеальном состоянии. Качество продукта стремится к 100%.
Звучит как мечта любого IT-директора. Но дьявол, как всегда, в деталях.
Почему это почти никогда не работает
1. Экономика против. Представьте, что вы делаете уборку в квартире. Убрать 95% грязи можно быстро и легко. А вот вычистить оставшиеся 5% проблемно. Пыль за шкафом, налет на кране займет столько же времени, сколько вся предыдущая уборка. В разработке тот же принцип Парето, только в кубе. Исправление 80% багов занимает 20% времени. А вот охота за последними, редкими и трудновоспроизводимыми ошибками — это колоссальные затраты. Стоит ли неделя работы разработчика исправления бага, который возникает у одного пользователя из тысячи при специфическом стечении обстоятельств? С точки зрения бизнеса, думаю почти никогда.
2. Что вообще считать «багом»? Вот тут и начинается самое интересное.
- Опечатка на кнопке это баг?
- Неидеальное выравнивание элемента на странице при разрешении экрана 1366×768 тоже баг?
- Отсутствие валидации на редко используемом поле точно баг?
Если команда обязана исправлять всё, она утонет в мелочах. Разработчики будут тратить время на косметику, вместо того чтобы пилить фичи, которые приносят деньги. Бизнес за это спасибо точно не скажет.
3. Цена промедления. Пока ваша команда гоняется за съехавшей кнопкой, конкуренты выкатывают новые функции и захватывают рынок. Бизнес теряет не только деньги на зарплатах разработчиков-перфекционистов, но и упущенную выгоду.
Здравый смысл вместо утопии. Сортируем баги
Вместо лозунга «ноль багов» зрелые компании используют прагматичный подход — систему приоритетов и оценку критичности. Можно использовать что-то типа матрицы Эйзенхауэра но для багов:
Матрица багов:
- Критический: Ошибка, блокирующая основную функциональность. Пользователь не может выполнить ключевой сценарий (например, оплатить заказ). Реакция: Бросаем всё, чиним немедленно. Релиз без исправления невозможен.
- Серьезный: Серьезная ошибка, которая нарушает некритичную функциональность или не имеющая простого обходного пути. Реакция: Должна быть исправлена в ближайшем релизе.
- Незначительный: незначительная проблема, которая не мешает работе, но создает неудобство. Есть обходной путь. Реакция: Исправляется, когда есть свободные ресурсы.
- Косметический: Косметическая ошибка: опечатка, съехавший элемент интерфейса. Реакция: Попадают в бэклог и исправляются «пачкой» раз в квартал или когда совсем нечем заняться.
Такой подход позволяет принимать экономически взвешенные решения. Мы не игнорируем баги, мы управляем ими.
Когда ZBP имеет смысл?
Но не все так однозначно. Есть области, где цена ошибки — это человеческая жизнь или миллионные финансовые потери. Софт для больниц, автопилоты, системы управления АЭС и т.п. Там ZBP жизненная необходимость, подкрепленная бюджетами и сроками (например, многоуровневым тестированием).
Но давайте будем честны, большинство из нас не пишет софт для NASA. Наша задача создавать ценность для бизнеса, а не стремиться к недостижимому идеалу.
Вывод: Zero Bug Policy красивая, но опасная идея для большинства компаний. Она подменяет цель (создание работающего и прибыльного продукта) средством (достижение стерильного кода). Гораздо эффективнее внедрить четкую систему классификации багов и принимать решения, основанные на здравом смысле и экономике.
А как у вас в компаниях работают с багами? Делитесь опытом в комментариях.
Столкнулся недавно с идеей «Zero Bug Policy» (ZBP). Речь про политику нулевой терпимости к багам. Концепция простая: увидел баг — бросай всё и чини. Звучит как мечта: ошибки все исправлены, клиенты счастливы, а техподдержка пьет смузи.
Но мой опыт показывает, что такие лозунги часто ведут в ад переработок и демотивации. Давайте разберемся, почему ZBP — это чаще всего утопия, которая может навредить бизнесу больше, чем помочь.
На бумаге все выглядит классно:
- Нашли баг? Все бросаем и чиним. Никаких новых фич, пока в бэклоге есть хоть одна ошибка.
- Результат? Код всегда в идеальном состоянии. Качество продукта стремится к 100%.
Звучит как мечта любого IT-директора. Но дьявол, как всегда, в деталях.
Почему это почти никогда не работает
1. Экономика против. Представьте, что вы делаете уборку в квартире. Убрать 95% грязи можно быстро и легко. А вот вычистить оставшиеся 5% проблемно. Пыль за шкафом, налет на кране займет столько же времени, сколько вся предыдущая уборка. В разработке тот же принцип Парето, только в кубе. Исправление 80% багов занимает 20% времени. А вот охота за последними, редкими и трудновоспроизводимыми ошибками — это колоссальные затраты. Стоит ли неделя работы разработчика исправления бага, который возникает у одного пользователя из тысячи при специфическом стечении обстоятельств? С точки зрения бизнеса, думаю почти никогда.
2. Что вообще считать «багом»? Вот тут и начинается самое интересное.
- Опечатка на кнопке это баг?
- Неидеальное выравнивание элемента на странице при разрешении экрана 1366×768 тоже баг?
- Отсутствие валидации на редко используемом поле точно баг?
Если команда обязана исправлять всё, она утонет в мелочах. Разработчики будут тратить время на косметику, вместо того чтобы пилить фичи, которые приносят деньги. Бизнес за это спасибо точно не скажет.
3. Цена промедления. Пока ваша команда гоняется за съехавшей кнопкой, конкуренты выкатывают новые функции и захватывают рынок. Бизнес теряет не только деньги на зарплатах разработчиков-перфекционистов, но и упущенную выгоду.
Здравый смысл вместо утопии. Сортируем баги
Вместо лозунга «ноль багов» зрелые компании используют прагматичный подход — систему приоритетов и оценку критичности. Можно использовать что-то типа матрицы Эйзенхауэра но для багов:
Матрица багов:
- Критический: Ошибка, блокирующая основную функциональность. Пользователь не может выполнить ключевой сценарий (например, оплатить заказ). Реакция: Бросаем всё, чиним немедленно. Релиз без исправления невозможен.
- Серьезный: Серьезная ошибка, которая нарушает некритичную функциональность или не имеющая простого обходного пути. Реакция: Должна быть исправлена в ближайшем релизе.
- Незначительный: незначительная проблема, которая не мешает работе, но создает неудобство. Есть обходной путь. Реакция: Исправляется, когда есть свободные ресурсы.
- Косметический: Косметическая ошибка: опечатка, съехавший элемент интерфейса. Реакция: Попадают в бэклог и исправляются «пачкой» раз в квартал или когда совсем нечем заняться.
Такой подход позволяет принимать экономически взвешенные решения. Мы не игнорируем баги, мы управляем ими.
Когда ZBP имеет смысл?
Но не все так однозначно. Есть области, где цена ошибки — это человеческая жизнь или миллионные финансовые потери. Софт для больниц, автопилоты, системы управления АЭС и т.п. Там ZBP жизненная необходимость, подкрепленная бюджетами и сроками (например, многоуровневым тестированием).
Но давайте будем честны, большинство из нас не пишет софт для NASA. Наша задача создавать ценность для бизнеса, а не стремиться к недостижимому идеалу.
Вывод: Zero Bug Policy красивая, но опасная идея для большинства компаний. Она подменяет цель (создание работающего и прибыльного продукта) средством (достижение стерильного кода). Гораздо эффективнее внедрить четкую систему классификации багов и принимать решения, основанные на здравом смысле и экономике.
А как у вас в компаниях работают с багами? Делитесь опытом в комментариях.
Неожиданная встреча с клиентом и мой фейл
В пятницу на прошлой неделе к нам в гости заехал Сергей Владимирович, представитель нашего клиента, они в своей работе используют Управление IT-отделом 8. Для меня это необычный кейс. Наш офис находится в маленьком городе в Краснодарском крае, и сюда ехать не ближний свет. Основные клиенты — это крупные компании, которые находятся совсем не близко. Клиент хотел поближе познакомиться, так как был проездом рядом и у него недалеко живут родственники.
После новости, что к нам едет клиент, сразу подумал: «Что? Зачем? Почему?» 😁
А потом понял. Это уникальный шанс «помучать клиента» и задать острые вопросы, узнать кейс нестандартного использования и т. д. Но и клиент может сделать ровно то же самое по нашему ПО: задать неудобные вопросы и узнать планы на будущее.
На мой взгляд, я плохо подготовился. Самый главный фейл — это то, что оказалось у нас два клиента с одинаковой фамилией, и когда я готовился к встрече, я посмотрел на данные другого клиента, на имя и отчество не обратил внимание. 🤦 Из-за этого и вопросы подготовил чутка не те… В общем, вы поняли.
Потом постарался исправиться и импровизировал уже в процессе беседы. Не уверен, что хорошо подготовился. А для себя понял, что в будущем так делать нельзя. К таким интервью надо готовиться хорошо и долго. Надо стараться использовать такие встречи по максимуму.
Конечно, это приятно. Все же не каждый день вживую общаешься с клиентами.
Чуть позже отдельно выложу, что из этого получилось в виде кейса клиента.
В связи с этим у меня к вам пара вопросов:
- Про фейлы: было такое, что при важной встрече всё шло, мягко говоря, не по плану?
- Про продукты: сталкивались с тем, что ваш или чужой софт использовали совсем не так, как задумывали разработчики? Расскажите в комментариях, это же самое интересное!
В пятницу на прошлой неделе к нам в гости заехал Сергей Владимирович, представитель нашего клиента, они в своей работе используют Управление IT-отделом 8. Для меня это необычный кейс. Наш офис находится в маленьком городе в Краснодарском крае, и сюда ехать не ближний свет. Основные клиенты — это крупные компании, которые находятся совсем не близко. Клиент хотел поближе познакомиться, так как был проездом рядом и у него недалеко живут родственники.
После новости, что к нам едет клиент, сразу подумал: «Что? Зачем? Почему?» 😁
А потом понял. Это уникальный шанс «помучать клиента» и задать острые вопросы, узнать кейс нестандартного использования и т. д. Но и клиент может сделать ровно то же самое по нашему ПО: задать неудобные вопросы и узнать планы на будущее.
На мой взгляд, я плохо подготовился. Самый главный фейл — это то, что оказалось у нас два клиента с одинаковой фамилией, и когда я готовился к встрече, я посмотрел на данные другого клиента, на имя и отчество не обратил внимание. 🤦 Из-за этого и вопросы подготовил чутка не те… В общем, вы поняли.
Потом постарался исправиться и импровизировал уже в процессе беседы. Не уверен, что хорошо подготовился. А для себя понял, что в будущем так делать нельзя. К таким интервью надо готовиться хорошо и долго. Надо стараться использовать такие встречи по максимуму.
Конечно, это приятно. Все же не каждый день вживую общаешься с клиентами.
Чуть позже отдельно выложу, что из этого получилось в виде кейса клиента.
В связи с этим у меня к вам пара вопросов:
- Про фейлы: было такое, что при важной встрече всё шло, мягко говоря, не по плану?
- Про продукты: сталкивались с тем, что ваш или чужой софт использовали совсем не так, как задумывали разработчики? Расскажите в комментариях, это же самое интересное!
👍2
Налоги для IT с 2026 года: закручивают гайки?
Не дает мне покоя тема с налогами. Повышение ставки НДС с 20% до 22% — это ещё полбеды. Куда больше беспокоит снижение порога для УСН, после которого придётся платить НДС. Его хотят урезать с 60 млн до 10 млн рублей. Если это примут, а всё к тому идёт, то наша компания тоже попадёт на НДС.
Есть в экономике такая штука, кривая Лаффера. Она просто и наглядно показывает: если налоги 0%, то в бюджет ничего не поступает. А если 100%, то бизнесом заниматься нет смысла — весь доход уйдет на налоги. Где-то посередине есть точка, в которой государство собирает максимум. Если ставку задрать выше этой точки, сборы начнут падать, потому что предприниматели просто не вывозят нагрузку. Бизнес перестаёт развиваться, теряет позиции, а потом и вовсе работает в убыток. В итоге он либо закрывается, либо уходит в тень.
Мне всё это, мягко говоря, не нравится.
А с IT-компаниями вообще история весёлая.
Как менялись льготы для IT-компаний
Давайте посмотрим на динамику налоговых условий для аккредитованных IT-компаний, в том числе тех, кто на УСН. Собрал тут для себя и вас изменения (если что-то забыл, напишите поправлю):
- Налог на прибыль:
2022-2024: 0%
2025-2026: 5% (планируется до 2030 года)
- Страховые взносы:
2022-2024: 7,6%
2025: 7,6%
2026: 15% (на доходы до предельной базы) и 7,6% (сверх базы)
- НДС для разработчиков ПО:
2022-2026: 0% при продаже софта из реестра Минцифры. Но есть нюанс: условия для попадания в реестр могут ужесточить.
- Льготы на УСН:
2022-2025: Регионы сами устанавливали пониженные ставки (от 1% до 6%).
2026: Ставки сохраняются, но порог для освобождения от НДС падает с 60 до 10 млн рублей годового дохода.
- Проверки:
2022-2025: Действовал мораторий на большинство проверок.
2026: Условия, скорее всего, пересмотрят.
Что нас ждёт в 2026 году?
Прогнозы — дело неблагодарное, но вот основные изменения, которые маячат на горизонте.
1. Страховые взносы вырастут почти вдвое. Льготный тариф поднимут с 7,6% до 15%. Это, конечно, не стандартные 30%, но рост ощутимый.
2. Главный удар для малого бизнеса на УСН. Порог для освобождения от НДС рухнет с 60 до 10 млн рублей. Это значит, что даже небольшие IT-компании с оборотом чуть выше 10 млн в год заставят платить НДС, который тоже может вырасти до 22%.
3. Льгота по НДС на софт пока остаётся. Ставка 0% на продажу программ из реестра Минцифры сохранится. Правда, есть подозрение, что на фоне общего повышения налогов попасть в этот самый реестр станет намного сложнее.
Получается, что золотые времена для IT с почти нулевыми налогами заканчиваются. С 2025 года гайки начали закручивать, а в 2026, похоже, закрутят ещё сильнее. Льготы всё ещё есть, и они заметны по сравнению с другими отраслями, но уже не такие щедрые.
Интересно, что вы думаете об этом? Как готовитесь к изменениям? Делитесь мыслями в комментариях.
Не дает мне покоя тема с налогами. Повышение ставки НДС с 20% до 22% — это ещё полбеды. Куда больше беспокоит снижение порога для УСН, после которого придётся платить НДС. Его хотят урезать с 60 млн до 10 млн рублей. Если это примут, а всё к тому идёт, то наша компания тоже попадёт на НДС.
Есть в экономике такая штука, кривая Лаффера. Она просто и наглядно показывает: если налоги 0%, то в бюджет ничего не поступает. А если 100%, то бизнесом заниматься нет смысла — весь доход уйдет на налоги. Где-то посередине есть точка, в которой государство собирает максимум. Если ставку задрать выше этой точки, сборы начнут падать, потому что предприниматели просто не вывозят нагрузку. Бизнес перестаёт развиваться, теряет позиции, а потом и вовсе работает в убыток. В итоге он либо закрывается, либо уходит в тень.
Мне всё это, мягко говоря, не нравится.
А с IT-компаниями вообще история весёлая.
Как менялись льготы для IT-компаний
Давайте посмотрим на динамику налоговых условий для аккредитованных IT-компаний, в том числе тех, кто на УСН. Собрал тут для себя и вас изменения (если что-то забыл, напишите поправлю):
- Налог на прибыль:
2022-2024: 0%
2025-2026: 5% (планируется до 2030 года)
- Страховые взносы:
2022-2024: 7,6%
2025: 7,6%
2026: 15% (на доходы до предельной базы) и 7,6% (сверх базы)
- НДС для разработчиков ПО:
2022-2026: 0% при продаже софта из реестра Минцифры. Но есть нюанс: условия для попадания в реестр могут ужесточить.
- Льготы на УСН:
2022-2025: Регионы сами устанавливали пониженные ставки (от 1% до 6%).
2026: Ставки сохраняются, но порог для освобождения от НДС падает с 60 до 10 млн рублей годового дохода.
- Проверки:
2022-2025: Действовал мораторий на большинство проверок.
2026: Условия, скорее всего, пересмотрят.
Что нас ждёт в 2026 году?
Прогнозы — дело неблагодарное, но вот основные изменения, которые маячат на горизонте.
1. Страховые взносы вырастут почти вдвое. Льготный тариф поднимут с 7,6% до 15%. Это, конечно, не стандартные 30%, но рост ощутимый.
2. Главный удар для малого бизнеса на УСН. Порог для освобождения от НДС рухнет с 60 до 10 млн рублей. Это значит, что даже небольшие IT-компании с оборотом чуть выше 10 млн в год заставят платить НДС, который тоже может вырасти до 22%.
3. Льгота по НДС на софт пока остаётся. Ставка 0% на продажу программ из реестра Минцифры сохранится. Правда, есть подозрение, что на фоне общего повышения налогов попасть в этот самый реестр станет намного сложнее.
Получается, что золотые времена для IT с почти нулевыми налогами заканчиваются. С 2025 года гайки начали закручивать, а в 2026, похоже, закрутят ещё сильнее. Льготы всё ещё есть, и они заметны по сравнению с другими отраслями, но уже не такие щедрые.
Интересно, что вы думаете об этом? Как готовитесь к изменениям? Делитесь мыслями в комментариях.
IT и бухгалтерия: как прекратить споры за каждую мышку. Пример из жизни.
Недавно я писал про встречу с клиентом и свою ошибку в подготовке. Эта встреча принесла пользу. Мы записали наш разговор и сделали из него подробный отчет. Сегодня я расскажу о самом важном из этого отчета — как IT-отдел и бухгалтерия могут прекратить споры.
Полный отчет вы можете найти на сайте SoftOnIT: ccылка на полный кейс
В чем проблема: два разных взгляда
Споры между IT и бухгалтерией почти всегда касаются учета оборудования.
Как видит бухгалтерия: Любая вещь, будь то ноутбук или мышь, — это актив компании. Его надо записать, дать ему номер и назначить ответственного. Обычно это тот, кто вещью пользуется. Каждое движение техники требует бумажного документа. Чтобы что-то выбросить, нужна своя процедура.
Как видит IT-отдел: Оборудование постоянно двигается. Сегодня ноутбук у одного человека, завтра — у другого. Мышь меняется за минуту. Диск в сервере сломался — его выкинули. Если для каждого такого шага готовить документы для бухгалтерии, IT-специалисты будут заниматься только бумагами.
Результат: все недовольны, а в учете беспорядок.
Как клиент решил задачу: разделить ответственность
Наш клиент — компания, у которой есть заводы и офисы в разных местах. Они придумали простой способ. Главная идея: ясно поделить, кто за что отвечает, и закрепить это официальным документом.
Как это у них устроено:
1. Вся ответственность на IT-отделе. По внутреннему приказу, вся компьютерная техника находится в ведении IT-отдела. Руководитель IT отвечает за все оборудование в компании.
2. Бухгалтерия общается только с IT. Когда поступает новая техника, бухгалтеры ставят ее на учет и сразу передают IT-отделу по акту. На этом их работа с конкретной вещью закончена до момента списания. Они работают с общими цифрами и документами от IT.
3. IT-отдел ведет свой учет. В нашей программе (Управление IT-отделом 8) специалисты следят, где находится каждая единица техники. Они отмечают, что ноутбук выдан такому-то человеку, но это их внутренняя запись. Для бухгалтерии этот ноутбук все еще числится за IT-отделом.
4. Ответственность сотрудника. Получая технику, работник подписывает документ о передаче с IT-отделом. Если он что-то потеряет, отвечать будет перед IT. Руководство компании знает и поддерживает этот порядок.
5. Простое списание. IT-отдел готовит документ о техническом состоянии и отправляет бухгалтерам записку: «Просим списать 5 единиц оргтехники на такую-то сумму». Этого бухгалтерии хватает, чтобы провести операцию.
6. Минусы тоже есть. Куда ж без них. За удобство приходится платить тем, что за все отвечает ИТ-подразделение. Но если контакт с бухгалтерией найден, то это, наверное, не такая уж и проблема.
Что это дает?
- Бухгалтеры довольны. Им больше не нужно отслеживать сотни мелких вещей. Они общаются с IT при помощи понятных им документов и цифр.
- IT-отдел получает больше времени на работу. Специалисты могут быстро управлять оборудованием и не тратят время на лишние бумаги.
- В учете все ясно. Деньги считает бухгалтерия. Фактическим наличием техники управляет IT. Путаницы нет.
Это показывает, как один официальный документ и подходящая программа для учета убирают почти все споры.
А как у вас построена работа с бухгалтерией? Удалось договориться или вы спорите из-за каждого старого жесткого диска? Напишите в комментариях!
Недавно я писал про встречу с клиентом и свою ошибку в подготовке. Эта встреча принесла пользу. Мы записали наш разговор и сделали из него подробный отчет. Сегодня я расскажу о самом важном из этого отчета — как IT-отдел и бухгалтерия могут прекратить споры.
Полный отчет вы можете найти на сайте SoftOnIT: ccылка на полный кейс
В чем проблема: два разных взгляда
Споры между IT и бухгалтерией почти всегда касаются учета оборудования.
Как видит бухгалтерия: Любая вещь, будь то ноутбук или мышь, — это актив компании. Его надо записать, дать ему номер и назначить ответственного. Обычно это тот, кто вещью пользуется. Каждое движение техники требует бумажного документа. Чтобы что-то выбросить, нужна своя процедура.
Как видит IT-отдел: Оборудование постоянно двигается. Сегодня ноутбук у одного человека, завтра — у другого. Мышь меняется за минуту. Диск в сервере сломался — его выкинули. Если для каждого такого шага готовить документы для бухгалтерии, IT-специалисты будут заниматься только бумагами.
Результат: все недовольны, а в учете беспорядок.
Как клиент решил задачу: разделить ответственность
Наш клиент — компания, у которой есть заводы и офисы в разных местах. Они придумали простой способ. Главная идея: ясно поделить, кто за что отвечает, и закрепить это официальным документом.
Как это у них устроено:
1. Вся ответственность на IT-отделе. По внутреннему приказу, вся компьютерная техника находится в ведении IT-отдела. Руководитель IT отвечает за все оборудование в компании.
2. Бухгалтерия общается только с IT. Когда поступает новая техника, бухгалтеры ставят ее на учет и сразу передают IT-отделу по акту. На этом их работа с конкретной вещью закончена до момента списания. Они работают с общими цифрами и документами от IT.
3. IT-отдел ведет свой учет. В нашей программе (Управление IT-отделом 8) специалисты следят, где находится каждая единица техники. Они отмечают, что ноутбук выдан такому-то человеку, но это их внутренняя запись. Для бухгалтерии этот ноутбук все еще числится за IT-отделом.
4. Ответственность сотрудника. Получая технику, работник подписывает документ о передаче с IT-отделом. Если он что-то потеряет, отвечать будет перед IT. Руководство компании знает и поддерживает этот порядок.
5. Простое списание. IT-отдел готовит документ о техническом состоянии и отправляет бухгалтерам записку: «Просим списать 5 единиц оргтехники на такую-то сумму». Этого бухгалтерии хватает, чтобы провести операцию.
6. Минусы тоже есть. Куда ж без них. За удобство приходится платить тем, что за все отвечает ИТ-подразделение. Но если контакт с бухгалтерией найден, то это, наверное, не такая уж и проблема.
Что это дает?
- Бухгалтеры довольны. Им больше не нужно отслеживать сотни мелких вещей. Они общаются с IT при помощи понятных им документов и цифр.
- IT-отдел получает больше времени на работу. Специалисты могут быстро управлять оборудованием и не тратят время на лишние бумаги.
- В учете все ясно. Деньги считает бухгалтерия. Фактическим наличием техники управляет IT. Путаницы нет.
Это показывает, как один официальный документ и подходящая программа для учета убирают почти все споры.
А как у вас построена работа с бухгалтерией? Удалось договориться или вы спорите из-за каждого старого жесткого диска? Напишите в комментариях!
🔥1
Perplexity AI: Заменит ли он Google? Мой опыт и опасность покупки за 500 рублей
В последние три недели я почти не использую обычный поиск Google или Яндекс. Всё из-за Perplexity AI. Это поисковик с нейросетью, который понимает смысл вопроса, а не ищет по словам. Он выдает не просто список сайтов, а готовый ответ по делу, со ссылками на источники.
Звучит хорошо, но официальная подписка стоит $20 в месяц. А в интернете её можно купить всего за 500 рублей на год (можно купить на Яндекс маркете, ggsel, plati и прочих площадках). В чём тут хитрость? Посмотрим, что это за программа, откуда такая низкая цена и есть ли смысл её покупать.
Что такое Perplexity и как он работает?
Проще говоря, Perplexity — это смесь поисковика и чат-бота типа ChatGPT. Работает он не так, как обычный поиск:
1. Вы пишете вопрос обычными словами. Программа понимает, что вы хотите узнать.
2. Perplexity быстро ищет в интернете, выбирая подходящие сайты.
3. Искусственный интеллект собирает найденные сведения и делает из них один ясный ответ.
4. Вы видите готовый текст со ссылками на сайты, откуда взята информация. Это главное удобство — можно легко всё проверить.
5. Можно спрашивать дальше, чтобы уточнить детали. Программа помнит ваш разговор и продолжает его.
Практический пример:
Например, я спросил «как работает perplexity простыми словами»:
Вместо списка сайтов я получил готовый ответ. Это сберегло мне очень много времени. Мне не нужно открывать сайты (хотя при необходимости я могу это сделать). Так же это не нейро-ответ Яндекса, перплексити гораздо умнее (на мой взгляд).
Официальная цена vs «Серый рынок»: в чем подвох?
Официальная подписка Perplexity Pro стоит $20 в месяц (или $200 за год). С ней вы получаете доступ к лучшим нейросетям (GPT-5, Claude 4.5, Grok и т.п.), можете загружать сколько угодно файлов и делать больше запросов.
Но на сайтах типа ggsel.net то же самое предлагают купить за 500 рублей в год. Как так? Не понятно… Я так и не понял, но в личном кабинете указана цена подписки как $0 и все регистрируется на мою почту официально и на год. Возможно, какие-то акции самого перплексити, но это — большой вопрос конечно. В чем подвох я так и не понял.
Мой опыт и минусы Perplexity
Я рискнул и три недели назад купил такой доступ для простых личных дел. Пока всё работает хорошо. К удобству быстро привыкаешь: искать сведения для блога или узнавать о новых технологиях стало намного быстрее.
Но кроме опасностей при покупке, у самой программы есть большой минус: скрытые команды. Неизвестно, как Perplexity меняет наш вопрос перед тем, как отправить его нейросети. Он может что-то убрать или добавить от себя, и это может изменить точность ответа. Чтобы это выяснить, нужно делать детальное сравнение с работой нейросетей напрямую. Я этого пока не делал, но было бы интересно провести такой анализ.
С другой стороны, стоит ли это считать минусом?
Выводы
Одно могу сказать точно: Perplexity — это очень мощная и полезная программа, которая может поменять сам подход поиска информации в интернете: то, как мы ищем сведения / факты. А потом это, возможно, может эволюционировать дальше, в персонального помощника.
Что думаете? Кто пробовал Perplexity?
В последние три недели я почти не использую обычный поиск Google или Яндекс. Всё из-за Perplexity AI. Это поисковик с нейросетью, который понимает смысл вопроса, а не ищет по словам. Он выдает не просто список сайтов, а готовый ответ по делу, со ссылками на источники.
Звучит хорошо, но официальная подписка стоит $20 в месяц. А в интернете её можно купить всего за 500 рублей на год (можно купить на Яндекс маркете, ggsel, plati и прочих площадках). В чём тут хитрость? Посмотрим, что это за программа, откуда такая низкая цена и есть ли смысл её покупать.
Что такое Perplexity и как он работает?
Проще говоря, Perplexity — это смесь поисковика и чат-бота типа ChatGPT. Работает он не так, как обычный поиск:
1. Вы пишете вопрос обычными словами. Программа понимает, что вы хотите узнать.
2. Perplexity быстро ищет в интернете, выбирая подходящие сайты.
3. Искусственный интеллект собирает найденные сведения и делает из них один ясный ответ.
4. Вы видите готовый текст со ссылками на сайты, откуда взята информация. Это главное удобство — можно легко всё проверить.
5. Можно спрашивать дальше, чтобы уточнить детали. Программа помнит ваш разговор и продолжает его.
Практический пример:
Например, я спросил «как работает perplexity простыми словами»:
Вместо списка сайтов я получил готовый ответ. Это сберегло мне очень много времени. Мне не нужно открывать сайты (хотя при необходимости я могу это сделать). Так же это не нейро-ответ Яндекса, перплексити гораздо умнее (на мой взгляд).
Официальная цена vs «Серый рынок»: в чем подвох?
Официальная подписка Perplexity Pro стоит $20 в месяц (или $200 за год). С ней вы получаете доступ к лучшим нейросетям (GPT-5, Claude 4.5, Grok и т.п.), можете загружать сколько угодно файлов и делать больше запросов.
Но на сайтах типа ggsel.net то же самое предлагают купить за 500 рублей в год. Как так? Не понятно… Я так и не понял, но в личном кабинете указана цена подписки как $0 и все регистрируется на мою почту официально и на год. Возможно, какие-то акции самого перплексити, но это — большой вопрос конечно. В чем подвох я так и не понял.
Мой опыт и минусы Perplexity
Я рискнул и три недели назад купил такой доступ для простых личных дел. Пока всё работает хорошо. К удобству быстро привыкаешь: искать сведения для блога или узнавать о новых технологиях стало намного быстрее.
Но кроме опасностей при покупке, у самой программы есть большой минус: скрытые команды. Неизвестно, как Perplexity меняет наш вопрос перед тем, как отправить его нейросети. Он может что-то убрать или добавить от себя, и это может изменить точность ответа. Чтобы это выяснить, нужно делать детальное сравнение с работой нейросетей напрямую. Я этого пока не делал, но было бы интересно провести такой анализ.
С другой стороны, стоит ли это считать минусом?
Выводы
Одно могу сказать точно: Perplexity — это очень мощная и полезная программа, которая может поменять сам подход поиска информации в интернете: то, как мы ищем сведения / факты. А потом это, возможно, может эволюционировать дальше, в персонального помощника.
Что думаете? Кто пробовал Perplexity?
👍1
Новое видео: Разработка API для «Управления IT-отделом 8» — полный разбор
Мы в SoftOnIT активно работаем над новой, четвертой редакцией нашего флагманского продукта Управление IT-отделом 8. Одним из ключевых нововведений станет полностью переработанный API. Чтобы поделиться процессом и техническими деталями, мы записали подробное видео, где ведущий разработчик Павел демонстрирует все этапы создания и внутреннее устройство нашего нового API.
Видео получилось объемным, но крайне содержательным. Это настоящий глубокий разбор для тех, кто интересуется разработкой на 1С, интеграциями и правильным построением архитектуры.
Что внутри видео?
Мы постарались охватить все аспекты работы: от внешних интерфейсов до внутренней логики в 1С. Вот основные темы, которые мы разбираем:
- Архитектура и HTTP-доступ: Как устроен наш API, как к нему подключаться и взаимодействовать по HTTP.
- Документация и тестирование: Демонстрация работы со Swagger для интерактивной документации и Postman для отладки запросов.
- Внутреннее устройство: Показываем, как запросы обрабатываются внутри 1С, как они доходят до модулей менеджеров объектов и как формируется ответ.
- Практический пример: В прямом эфире добавляем поддержку нового документа в наше API.
- Отладка и безопасность: Обсуждаем, как находить ошибки и какие меры предпринимаем для защиты от SQL-инъекций.
- Оптимизация: Говорим о производительности, кешировании сеансов, пагинации и сжатии данных.
Это видео будет особенно полезно разработчикам 1С, системным архитекторам и всем, кто сталкивается с задачами интеграции.
📹 Смотреть на RuTube
🎞 Смотреть на VK
📺 Смотреть на YouTube
🌍 Смотреть на Dzen
Тайм-коды для удобной навигации
Буду рад, если посмотрите и поделитесь своим мнением в комментариях под видео. Какие подходы вы используете в своих проектах? С какими сложностями сталкивались при разработке API на 1С?
Приятного просмотра!
Мы в SoftOnIT активно работаем над новой, четвертой редакцией нашего флагманского продукта Управление IT-отделом 8. Одним из ключевых нововведений станет полностью переработанный API. Чтобы поделиться процессом и техническими деталями, мы записали подробное видео, где ведущий разработчик Павел демонстрирует все этапы создания и внутреннее устройство нашего нового API.
Видео получилось объемным, но крайне содержательным. Это настоящий глубокий разбор для тех, кто интересуется разработкой на 1С, интеграциями и правильным построением архитектуры.
Что внутри видео?
Мы постарались охватить все аспекты работы: от внешних интерфейсов до внутренней логики в 1С. Вот основные темы, которые мы разбираем:
- Архитектура и HTTP-доступ: Как устроен наш API, как к нему подключаться и взаимодействовать по HTTP.
- Документация и тестирование: Демонстрация работы со Swagger для интерактивной документации и Postman для отладки запросов.
- Внутреннее устройство: Показываем, как запросы обрабатываются внутри 1С, как они доходят до модулей менеджеров объектов и как формируется ответ.
- Практический пример: В прямом эфире добавляем поддержку нового документа в наше API.
- Отладка и безопасность: Обсуждаем, как находить ошибки и какие меры предпринимаем для защиты от SQL-инъекций.
- Оптимизация: Говорим о производительности, кешировании сеансов, пагинации и сжатии данных.
Это видео будет особенно полезно разработчикам 1С, системным архитекторам и всем, кто сталкивается с задачами интеграции.
Тайм-коды для удобной навигации
00:00:00 — Вступление и анонс темы00:01:45 — Обзор HTTP-доступа и структуры API00:07:07 — Работа с документацией Swagger00:15:23 — Использование Postman для тестирования запросов00:16:28 — Внутренняя архитектура API в 1С00:26:35 — Полный путь обработки HTTP-запроса00:39:32 — Пример добавления нового объекта (документа «Заказ клиента») в API00:52:24 — Процесс отладки ошибок01:03:28 — Обсуждение производительности: сортировка, пагинация и offset01:09:09 — Вопросы безопасности и защита от SQL-инъекций01:24:30 — Обзор ядра API и его структуры01:25:47 — Вопросы производительности: переиспользование сеансов и сжатие01:38:46 — Обработка ошибок и возвращаемые статусы01:43:26 — Идея создания общего теста для проверки всех методов APIБуду рад, если посмотрите и поделитесь своим мнением в комментариях под видео. Какие подходы вы используете в своих проектах? С какими сложностями сталкивались при разработке API на 1С?
Приятного просмотра!
Please open Telegram to view this post
VIEW IN TELEGRAM
RUTUBE
Кружок 1С #10 Следующая версия API v2 для Управление IT-отделом 8, редакция 4
🔥 Готовим новый API V2 для Управление IT-отделом 8, редакция 4🔥
Запись с приемки работ. Погнали! 🚀
https://softonit.ru
Запись с приемки работ. Погнали! 🚀
https://softonit.ru
🔥4
Обработка персональных данных на сайтах. Началось.
Обратил внимание на свежую новость на Хабре. 1 сентября заработали новые положения закона о персональных данных и Роскомнадзор приступил к поиску нарушителей.
Что это? Это предписание исправить на сайте все, что связано с законом, которое заставило меня задуматься. Автор на Хабре подробно разбирает новые требования Роскомнадзора и приводит реальные примеры, когда предприниматели уже получили «письма счастья». Суммы штрафов за повторные нарушения впечатляют, и я решил не откладывать в долгий ящик и провести аудит нашего корпоративного сайта Софтонит.
А самый главный прикол знаете в чем? Скорее всего, все происходит в автоматическом режиме.
Ключевые моменты из статьи на Хабре
Если кратко, то Роскомнадзор теперь уделяет пристальное внимание следующим вещам:
- Активное согласие: Пользователь должен сам поставить галочку в чекбоксе. Предустановленные галочки или пассивное согласие (когда отправка формы автоматически означает согласие) теперь вне закона.
- Четкая политика: На сайте должна быть опубликована «Политика обработки персональных данных», и ссылка на неё должна быть у каждой формы сбора данных.
- Cookies и аналитика: Если используете Яндекс.Метрику или другие счётчики, вы обязаны уведомлять об этом пользователей и получать их согласие.
- Реестр операторов: Все, кто обрабатывает персональные данные, должны быть зарегистрированы в реестре Роскомнадзора.
- Трансграничная передача данных. Это вообще отдельная песня... Используете Google Analytics? Забудьте. Лучше отказаться.
Аудит нашего сайта: что я нашел и исправил
К моему удивлению, даже у нас нашлись недочеты. Вот что было не так:
- Пассивное согласие на обработку. У нас на сайте есть две формы: «Запрос демо-версии» и «Заказ обратного звонка». В обеих формах текст под кнопкой отправки просто уведомлял пользователя, что, нажимая на кнопку, он соглашается с обработкой данных. Это и есть пассивное согласие, которое теперь запрещено.
- Некорректное название документа. Ссылка вела на документ под названием «Политика обработки персональных данных», хотя по закону должен быть документ «Согласие на обработку персональных данных». И эти два документа должны быть разделены. Мелочь, а может стать причиной для штрафа.
Я оперативно внес исправления. Теперь формы выглядят корректно. Кнопку нельзя нажать, пока чек-бокс не будет установлен.
Коллеги, настоятельно рекомендую вам провести аналогичную проверку своих сайтов. Требования ужесточились, и штрафы стали действительно серьёзными. Потратьте 15 минут сейчас, чтобы сэкономить до полутора миллионов рублей в будущем.
Проверьте свои формы, наличие правильной политики и активных чекбоксов. Убедитесь, что вы не нарушаете закон.
Обратил внимание на свежую новость на Хабре. 1 сентября заработали новые положения закона о персональных данных и Роскомнадзор приступил к поиску нарушителей.
Что это? Это предписание исправить на сайте все, что связано с законом, которое заставило меня задуматься. Автор на Хабре подробно разбирает новые требования Роскомнадзора и приводит реальные примеры, когда предприниматели уже получили «письма счастья». Суммы штрафов за повторные нарушения впечатляют, и я решил не откладывать в долгий ящик и провести аудит нашего корпоративного сайта Софтонит.
А самый главный прикол знаете в чем? Скорее всего, все происходит в автоматическом режиме.
Ключевые моменты из статьи на Хабре
Если кратко, то Роскомнадзор теперь уделяет пристальное внимание следующим вещам:
- Активное согласие: Пользователь должен сам поставить галочку в чекбоксе. Предустановленные галочки или пассивное согласие (когда отправка формы автоматически означает согласие) теперь вне закона.
- Четкая политика: На сайте должна быть опубликована «Политика обработки персональных данных», и ссылка на неё должна быть у каждой формы сбора данных.
- Cookies и аналитика: Если используете Яндекс.Метрику или другие счётчики, вы обязаны уведомлять об этом пользователей и получать их согласие.
- Реестр операторов: Все, кто обрабатывает персональные данные, должны быть зарегистрированы в реестре Роскомнадзора.
- Трансграничная передача данных. Это вообще отдельная песня... Используете Google Analytics? Забудьте. Лучше отказаться.
Аудит нашего сайта: что я нашел и исправил
К моему удивлению, даже у нас нашлись недочеты. Вот что было не так:
- Пассивное согласие на обработку. У нас на сайте есть две формы: «Запрос демо-версии» и «Заказ обратного звонка». В обеих формах текст под кнопкой отправки просто уведомлял пользователя, что, нажимая на кнопку, он соглашается с обработкой данных. Это и есть пассивное согласие, которое теперь запрещено.
- Некорректное название документа. Ссылка вела на документ под названием «Политика обработки персональных данных», хотя по закону должен быть документ «Согласие на обработку персональных данных». И эти два документа должны быть разделены. Мелочь, а может стать причиной для штрафа.
Я оперативно внес исправления. Теперь формы выглядят корректно. Кнопку нельзя нажать, пока чек-бокс не будет установлен.
Коллеги, настоятельно рекомендую вам провести аналогичную проверку своих сайтов. Требования ужесточились, и штрафы стали действительно серьёзными. Потратьте 15 минут сейчас, чтобы сэкономить до полутора миллионов рублей в будущем.
Проверьте свои формы, наличие правильной политики и активных чекбоксов. Убедитесь, что вы не нарушаете закон.
❤3👍1
Перевод компании на удалёнку, когда ты руководитель и совсем этого не хочешь
Столкнулся с ситуацией: в нашем городе кадры исчерпаны, а для развития нужны люди. Единственный выход — нанимать удалённо.
В новой статье честно разобрал дилемму:
🚫 С одной стороны, страх потери контроля, разрыва команды и падения вовлеченности.
🟢 С другой — необходимость роста, доступ к талантам и повышение устойчивости бизнеса.
Похоже, удалёнка — это жёсткий, но справедливый тест для менеджмента. Выживают те, кто управляет по результатам, а не по «присутствию в кресле».
Поделился всеми сомнениями и планами в блоге. Заходите почитать и обсудить.
Полный текст статьи здесь: Перевод компании на удалёнку. Когда не хочется, но надо
👇 А что для вас было самым сложным при переходе на удалёнку?
Столкнулся с ситуацией: в нашем городе кадры исчерпаны, а для развития нужны люди. Единственный выход — нанимать удалённо.
В новой статье честно разобрал дилемму:
Похоже, удалёнка — это жёсткий, но справедливый тест для менеджмента. Выживают те, кто управляет по результатам, а не по «присутствию в кресле».
Поделился всеми сомнениями и планами в блоге. Заходите почитать и обсудить.
Полный текст статьи здесь: Перевод компании на удалёнку. Когда не хочется, но надо
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegraph
Перевод компании на удалёнку. Когда не хочется, но надо
Как-то так все закрутилось, наша компания находится в небольшом городе в Краснодарском крае, и после увольнения сотрудника, встал вопрос о поиске новых сотрудников. И так выходит, что мы выбрали потенциал города по кадрам. Также на прошлой неделе у меня был…
🔥1
Йети, который подсматривает ваш пароль. Зачем делать интерфейсы живыми?
Мне всегда импонирует, когда на сайтах или в ПО разработчики добавляют что-то такое, что по-доброму заставляет улыбнуться. В продажах — это отличный маркетинговый прием, а в разработке — хорошая возможность выделиться и сделать так, чтобы вас запомнили.
Вводные
Итак, у нас есть обычная форма входа: логин, пароль и кнопка входа. Функционально, скучно, знакомо. Мы видим такое каждый день и не замечаем. А теперь вообразите, что под полями сидит веселый анимированный персонаж. Например, йети.
Вводим логин
Когда вы печатаете логин, он с интересом водит глазами за курсором. Как только вы начинаете вводить пароль, он в страхе закрывает глаза лапами — секрет есть секрет 🙂 Нажали на значок «показать пароль»? Йети с хитростью приоткрывает один глаз и смотрит. Ввели всё правильно — он рад. Сделали ошибку — он хватается за голову.
Вводим пароль
Это больше, чем веселая игрушка. Это пример дизайна, вызывающего эмоции. Такой подход делает работу с программой и функциональной, и приятной.
Готовые примеры кода есть на Codepen. Это позволяет довольно легко встроить такую функцию в свой веб-проект.
Что это и как устроено?
Эта идея существует давно. Один из хороших примеров — проект «Teddy», который сделал веб-дизайнер Дарин Сенеф. Технически он состоит из трех частей:
1. SVG-анимация: Персонаж нарисован в формате SVG. Поэтому он легкий, меняет размер без потери качества, и его легко анимировать.
2. CSS: Стили делают переходы между состояниями анимации плавными.
3. JavaScript: Скрипт следит за действиями пользователя — выбор поля, ввод букв, нажатие кнопок — и меняет состояние персонажа.
Почему это полезнее, чем просто украшение?
Для руководителя ИТ в разработке любая функция должна иметь цель. Добавление такого персонажа — это не бесполезная трата времени, а шаг, у которого есть несколько задач.
1. Уменьшение стресса и создание контакта
Форма входа может создавать преграду. Пользователь может неверно ввести пароль или логин. Это вызывает небольшое раздражение. Смешная реакция персонажа на ошибку делает этот опыт веселым и снимает напряжение. Пользователь начинает думать, что система дружелюбна. Это первый шаг к построению лояльности.
2. Узнаваемость и отличие от других
Ваш продукт больше не будет «просто еще одним сервисом». Он станет «тем сервисом со смешным йети». Эта деталь запоминается и хорошо отличает вас от конкурентов со стандартными, одинаковыми интерфейсами.
3. Увеличение интереса
Это называется микровзаимодействие. Маленькая, но продуманная реакция программы на действия человека. Такие детали оживляют продукт. Они побуждают пользователя дольше оставаться в программе и изучать её.
Практический взгляд: какие есть риски и минусы
Даже с учетом плюсов, внедрять такую функцию нужно обдуманно.
- Скорость работы. Анимация, если она плохо сделана, может замедлить загрузку страницы входа. Это плохо, потому что скорость важна для хорошего впечатления. Решение: использовать легкий SVG-файл и простой JS-код.
- Уместность. Веселый элемент подходит не для всех продуктов. В программе для банка или управления важной системой он будет выглядеть странно и может снизить доверие. Но для CRM, менеджера задач или сайта компании это хорошее решение.
- Отвлечение. Некоторых пользователей анимация может отвлекать.
Вывод
Это отличный и полезный пример дизайна. Он с первого шага помогает наладить контакт с пользователем, делает продукт запоминающимся и смягчает неприятные ощущения от ошибок.
А вы видели похожие «живые» интерфейсы или какие-то не стандартные приемы шутки на сайтах или в интерфейсах программ? Что вам больше всего запомнилось? Напишите в комментариях!
Мне всегда импонирует, когда на сайтах или в ПО разработчики добавляют что-то такое, что по-доброму заставляет улыбнуться. В продажах — это отличный маркетинговый прием, а в разработке — хорошая возможность выделиться и сделать так, чтобы вас запомнили.
Вводные
Итак, у нас есть обычная форма входа: логин, пароль и кнопка входа. Функционально, скучно, знакомо. Мы видим такое каждый день и не замечаем. А теперь вообразите, что под полями сидит веселый анимированный персонаж. Например, йети.
Вводим логин
Когда вы печатаете логин, он с интересом водит глазами за курсором. Как только вы начинаете вводить пароль, он в страхе закрывает глаза лапами — секрет есть секрет 🙂 Нажали на значок «показать пароль»? Йети с хитростью приоткрывает один глаз и смотрит. Ввели всё правильно — он рад. Сделали ошибку — он хватается за голову.
Вводим пароль
Это больше, чем веселая игрушка. Это пример дизайна, вызывающего эмоции. Такой подход делает работу с программой и функциональной, и приятной.
Готовые примеры кода есть на 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 🙂
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 уже можно посмотреть результат.
А как вы решаете вопрос с обновлением общей документации из разных репозиториев? Делаете мульти-проектные пайплайны или тоже живете на расписании? 👇