Записки IT специалиста

🎥 Вебинар по сетям: Основные протоколы сети Интернет 🧠 Что будет на занятии: - От битов до браузера: что такое сетевой протокол и зачем нужна модель osi/tcp-ip. Простое объяснение сложной концепции. - Фундамент Интернета: детальный разбор ip, tcp и udp. Узнаем, кто отвечает за адресацию, а кто — за надежность доставки. - Протоколы прикладного уровня: как работают знакомые всем http, https и dns, когда вы открываете сайт. - Ответы на ваши вопросы: живая сессия с экспертом, где можно спросить о любых нюансах, связанных с сетевыми технологиями. 💪 В результате : Систематизируете знания о ключевых протоколах и сможете увереннее разбираться в сетевых вопросах. 🎁 Проходит в преддверии старта курса «Network engineer. Basic». Все участники вебинара получат специальные условия на полное обучение курса. 👉 Регистрируйтесь для участия https://otus.pw/roCq/?erid=2W5zFG7raqN Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

​​Про обслуживание и оптимизацию баз 1С Тема широкая, тема сложная, поэтому будет дайджест. 🔸 MS SQL Как первоначально настроить и первично оптимизировать: ▫️ Установка и настройка MS SQL Server для 1С:Предприятие Как обслуживать: ▫️ Обслуживание баз 1С в MS SQL Server. Часть 1 ▫️ Обслуживание баз 1С в MS SQL Server. Часть 2 ▫️ Обслуживание баз 1С в MS SQL Server. Часть 3 Статьи не новые, а про обслуживание – старые, причем довольно сильно старые. Но все они основаны на рекомендациях вендора на ИТС, а там с тех пор ничего нового не появилось. Поэтому в основных настройках актуальность сохраняется. 🔹 PostgreSQL Здесь все свежее, ну и тема гораздо более свежая, на ИТС материалов откровенно мало, поэтому мы более ориентировались на рекомендации ведущего эксперта по этой теме Антона Дорошкевича. Представленный ниже материал предоставляет микс его рекомендации и данных с ИТС и в первую очередь оптимизирован нами под небольшие внедрения, но эффект, местами, становится виден невооруженным глазом. ▫️ Оптимизация производительности PostgreSQL для работы с 1С:Предприятие Про обслуживание у нас ничего нет, но всем, кто хочет подковаться в этой теме настоятельно рекомендуем выделить время и просмотреть или прослушать бесплатный курс Антона Дорошкевича: ▫️Настройка и тонкости эксплуатации PostgreSQL для 1С Курс состоит из нескольких частей, каждая на свою тему и по 1,5 – 2,5 часа продолжительностью. Как мы уже сказали, курс бесплатный, но для доступа к нему нужно зарегистрироваться на портале разработчиков 1С. Разумеется, это ни к чему не обязывает.

Хотите одним глазком заглянуть в то, как устроена IT-поддержка у разработчиков ITSM/ESM-системы? Где обрабатывают 1200+ обращений в месяц через веб-портал, телеграмм, почту, форум и даже 1С-Connect. Без хаоса, Excel и потерянных задач. Где каждый релиз связан с обращениями и нарядами в единой системе, а отчеты обновляются каждые 180 секунд и видна реальная нагрузка и эффективность каждого сотрудника. Онлайн-экскурсия от IT-компании «Деснол» — это: ✔️ реальные сервисные процессы тех, кто сам разрабатывает и внедряет в компании по всей стране ITSM/ESM-систему; ✔️ готовые идеи, стратегии и практики, которые вы сможете забрать себе; ✔️ ответы на вопросы от экспертов; ✔️ возможность увидеть реальные IT-процессы в других крупных компаниях. 📍 Приходите, если: — ищете замену западным решениям; — хотите сократить ручную работу в IT-поддержке; — стремитесь к системности, порядку и развитию сервисов в организации. 🎁 Участие бесплатное, регистрация по ссылке Чтобы в числе первых узнавать о новых кейсах, практиках и полезных инструментах в IT, подписывайтесь на Telegram-канал 1C:ITILIUM по ссылке #реклама О рекламодателе

Хоть пятница сегодня "не настоящая" и публикация эта уже была, но вопрос остался актуален и некуда не делся

​​Пятничное, о жизни. Информационный шум. Мне кажется, если сейчас каким-нибудь образом переместить сюда человека 20-летней давности и выдать ему современные гаджеты, то он очень быстро сойдет с ума. Ну или наложит на себя руки. Практически вся наша повседневная жизнь проходит в условиях сильного информационного шума. С самого утра и до позднего вечера к нам приходят сообщения электронной почты, SMS, мессенджеров. Пуши приложений и т.д. и т.п. Фактически мы уже к этому привыкли и если тот же телефон долго молчит, то начинаем беспокоиться, а все ли в порядке со связью? И, пожалуй, остаться без связи для современного человека, это пострашнее чем остаться без трусов. Срам можно и лопухом прикрыть, а вот что делать без гаджета? Навигация в незнакомом месте, такси, деньги, контакты – все сосредоточено в одном месте. И если мы находимся вне дома, то это место – телефон. Это настолько плотно вошло в нашу жизнь, что наши дети уже с трудом представляют себе, что был когда-то мир без интернета и смартфонов. Что такси заказывали по телефону и предварительно еще надо было узнать точный адрес куда вызываешь. А таксист мог попросить показать дорогу… Сегодня же, не вставая с дивана можно вызвать такси, заказать еду, купить билеты, забронировать отель и т.д. и т.п. Это, уже не говоря о таких банальных вещах, как заплатить за интернет, коммуналку или саму связь. Обратная сторона – постоянные сообщения и уведомления. Нужные, не совсем нужные, совсем не нужные. От приложений, сайтов, сервисов, организаций и наконец самых разных людей. И так каждый день, с утра до вечера. Но современный человек воспринимает это нормально, хотя и жалуется периодически на информационный шум. Но если после оплаты на сайте сразу не пришло подтверждение, то он уже начинает нервничать. Если представитель организации в мессенджере молчит более 5 минут – тоже, ну действительно, что там у них случилось… На мой взгляд, информационный шум – это примерно тоже самое что и шум большого города. Нравится, не нравится, но он есть, и мы среди него живем. Это неотъемлемая часть нашей жизни, а когда он пропадает, то современный человек не вздыхает облегченно, а наоборот начинает нервничать, потому что это все равно что замер за окном крупный город. Первый признак, что что-то идет не так.

Современные тенденции в сайтостроении. Wiki-CMS Продолжаем разговор о современных тенденциях в сайтостроении, начало здесь: https://t.me/interface31/5138 Wiki-CMS – это особая категория систем управления контентом, которую нельзя оставить без подробного рассмотрения и дело тут не в особенностях технологической реализации, а в самом подходе к управлению содержимым. Ключевое отличие Wiki-CMS от иных систем управления контентом – это отсутствие строгой иерархии данных. Если в обычной CMS вы так или иначе должны распределить контент по таксономиям, то в Wiki такого требования нет. Здесь вы можете динамически развивать контент снизу вверх, как дерево. Эта особенность делает Wiki-движки наилучшим выбором для ведения баз знаний, документаций, справочников, энциклопедий. А отсутствие строгих структурных ограничений допускает живое развитие проекта по мере добавления и накопления знаний. Одним из ключевых изобретений Wiki стала концепция Red Links (красных ссылок), когда в процессе написания материала автор понимает, что ему нужно дополнительно объяснить некоторый термин, явления, сослаться на другую страницу – то он просто добавляет ссылку. Если такая страница существует, то ссылка становится обычной, синей, если нет – красной. Но в отличие от обычных CMS она не является битой, а ведет на специальную страницу, где предлагается создать недостающий контент. При этом никаких предварительных ссылок делать не нужно и с точки зрения поисковых систем битой такая ссылка не является. Такой подход помогает устранять пробелы в знаниях, так как красные ссылки служат живым воплощением технологического долга, т.е. показывают вам, какие страницы вам нужно написать, но вы пока этого не сделали. Вообще именно ссылки являются основным способом навигации по Wiki-сайтам. Именно взаимные ссылки связывают страницы в единую сеть данных и позволяют перемещаться по ее структуре. Кроме непосредственно ссылок в тексте Wiki-статьи движок позволяет быстро получить список всех входящих ссылок на текущую страницу, что позволяет отслеживать взаимосвязи и поддерживать актуальность данных. Это же является и отдельной большой проблемой Wiki-CMS, особенно если ее ведут разные люди и команды. Если в обычной системе для проставления ссылки нам нужно пойти, найти и хотя бы краем глаза посмотреть на страницу, то тут ссылки ставятся легко и непринужденно. При этом по той стороне ссылки может находиться откровенно устаревший материал или вообще черновик. Но если мы хоть что-то написали на красной странице, то она станет после этого синей. Это хорошо видно на старых проектах, которые ведутся много лет большими командами. Яркий пример – Альт Вики, проект Альт Линукс, там густо перемешаны актуальные материалы с устаревшими, полные с неполными и вообще никогда нельзя понять, насколько можно доверять тому, что ты сейчас читаешь. Отсюда плавно вытекает еще одна беда – потерянные страницы, на которые больше нет ссылок и найти их пользователь просто так не сможет, разве что будет точно знать, что искать. Напомним, что четкой иерархии у Wiki нет и нельзя просто взять и посмотреть все записи по какой-то выбранной таксономии. Но снова вернемся к плюсам – это версионирование. Движок автоматически сохраняет все правки и позволяет в любой момент изучить их, сравнить и откатиться на требуемую версию. До широкого распространения git это была в общем-то киллер-фича, особенно если контент могла править не только лишь все. А вообще Wiki-CMS – это как качели, и мы снова приходим к минусам – специальная Wiki-разметка, которая чем-то похожа на Markdown, но именно что похожа. Она очень своеобразна, сложна и местами совсем нелогична. Отдельные движки, какие как DokuWiki, пытались упростить это процесс, придумывая собственную «упрощенную» разметку, но по факту сделали только хуже, наплодив местечковых вариантов. В современных версиях движков это нивелируется визуальными редакторами, но если вы намерены серьезно работать с Wiki, то с ее языком разметки вам придется непосредственно столкнуться.

🎮 Поздравляем, игрок! Вы прошли уровень «проектный беспорядок»: чудом уложились в бюджет и сроки, выплыли из безумия задач и героически наладили коммуникацию между исполнителями. Впереди ожидает битва с Финальным Боссом! Вам предстоит убедить топ-менеджмент внедрить систему управления ИТ-проектами и получить статус суперигрока в проектном управлении! А для легкой «игры» возьмите с собой гайд-помощник. В нем: 🧩 5 железных аргументов и выгод для бизнеса; 🧩 калькулятор ROI; 🧩 рекомендации, как презентовать проект внедрения. Скачайте наш бесплатный гайд, чтобы пройти этот уровень без второго раунда!

Антон Дорошкевич. Тонкости эксплуатации PostgreSQL Тема перехода с MS SQL на PostgreSQL становится все актуальнее. В докладе на конференции Infostart Event 2022 Saint Petersburg руководитель проектов Антон Дорошкевич рассказал, что ждёт после перехода, к чему нужно быть готовым, и какие варианты решения задач существуют на данный момент в мире PostgreSQL для его успешной эксплуатации. Доклад в виде статьи: https://infostart.ru/1c/articles/1883272 У кого нет доступа к YouTube видео приложено отдельно

ИИ в кино — это уже реальность. На примере Wink AI Challenge показываем, как ML-инженер может превратить фильм в набор данных и помочь продюсерам: 🔸 Анализировать сценарий с помощью NER и NLP. 🔸 Генерировать раскадровки на базе text-to-image и text-to-video. 🔸 Прогнозировать  возрастной рейтинг фильма по описанию сцен и готовым кадрам. Эти задачи предстоит решать на Wink AI Challenge — хакатоне на стыке кино и ИИ. Регистрация открыта до 31 октября. Если вас пугает слово «превизуализация», вы не знаете, чем отличаются форматы сценариев и как рассчитывается возрастной рейтинг, статья поможет разобраться. Внутри — реальные примеры из культовых фильмов и рекомендации по использованию моделей CLIP, Wan-AI, Qwen3-Omni и множества других. В статье есть всё, чтобы быстро погрузиться в тему и подобрать рабочие инструменты: https://cnrlink.com/winkinterblogarticle?erid=2W5zFK7UYHn

​​Postgres + 1C = сильно тормозит? Самое частое нарекание на работу свежеустановленной связки PostgreSQL + 1С:Предприятие – это тормоза. Причем именно тормоза, а не замедление, и часто видимые невооруженным глазом. Означает ли это, что Postgres плох? Вовсе нет, просто привычный подход Далее – Далее – Готово здесь не работает. Если MS SQL из коробки имеет вполне оптимальные настройки и без проблем будет работать на небольших инсталляциях 1С, то Postgres настроен на запуск и работу в минимальной конфигурации, что сразу сказывается на производительности. Поэтому, вне зависимости от используемой платформы и версии PostgreSQL сразу после установки следует выполнить несложный тюнинг, после которого работа Postgres перестанет вызывать нарекания. Как это сделать – написано в нашей статье: Оптимизация производительности PostgreSQL для работы с 1С:Предприятие

Гайд для CEO по подготовке и проведению вебинаров Как CEO оптимизировать бизнес-процессы с помощью вебинаров и повысить прибыль компании? Гайд от МТС Линк по подготовке и проведению эффективных вебинаров. ✅ В гайде: - Как выбрать день и время для вебинаров, чтобы максимизировать ROI; - Как улучшить коммуникацию с клиентами и партнёрами для роста бизнеса; - Как сократить расходы на event-маркетинг и повысить эффективность команды; - Как измерить вклад вебинаров в прибыль компании и масштабировать успех. ✨ Скачайте гайд бесплатно по ссылке Скачать #реклама 16+ mts-link.ru О рекламодателе

Перенос баз данных PostgreSQL между серверами Такая задача встречается не так уж и редко, но практически везде приведен один и тот же сценарий: выгрузить базы в дамп – загрузить базы из дампа. Все это хорошо, но ровно до тех пор, пока не дойдет до практического применения. Для начала базы надо куда-то выгрузить, с учетом имеющихся прав доступа у всех участников этого процесса. Затем их надо на второй сервер как-то передать и снова куда-то сложить, снова не забыть про права. Потом их надо загрузить. Получается такая не быстрая эпопея, большую часть которой мы бегаем со своими дампами как дурень с крашеной торбой. Но есть способ проще, гораздо проще, достаточно вспомнить, что служебные утилиты Postgres умеют работать с удаленными серверами и поддерживают стандартные потоки ввода вывода. Для того, чтобы подключиться к другому узлу используйте ключ -h:

-h имя_сервера

Если пользователь удаленного сервера отличается от текущего пользователя СУБД, то дополнительно используем ключ -U:

-U имя_пользователя

Теперь несколько практических примеров: На целевом сервере переключаемся на учетную запись суперпользователя СУБД:

su - postgres

Теперь можно посмотреть базы на текущем сервере:

psql -l

И на удаленном:

psql -h SRV-02 -l 

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

createdb -T template0 newbase

Это также можно сделать удаленно, не вставая с любимого дивана:

 createdb -h SRV-02  -T template0 newbase

Ну вот, все готово к переносу. Выгружаем здесь и по конвейеру передаем туда:

pg_dump  oldbase | psql -h SRV-02 newbase

Также можно выполнить всю эту операцию полностью удаленно, это может пригодиться, если сервера СУБД находятся у вас в разных подсетях и не видят друг друга или в контейнерах с минимальным набором инструментов. Все что вам понадобится – это клиент Postgres:

apt install postgresql-client-<VERSION>

Версию ставим ту, что в дистрибутиве, ее номер роли не играет, так же, как и базы можно переносить между серверами различных версий. Теперь переносим базы с одного на другой командой:

pg_dump -h SRV-01  oldbase | psql -h SRV-02 newbase

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

Практический телеграм-канал про информационную безопасность на простом и понятном языке. Каждую неделю публикуем новости про защиту данных, советы ведущих экспертов сферы ИБ, разбираем кейсы без нудной теории и делимся рекомендациями о том, как защитить компанию от инсайдеров.  Узнайте: ➕ с какими инцидентами ИБ сталкиваются в финансах, промышленности и здравоохранении. ➕ как эффективно повысить цифровую грамотность сотрудников. ➕ когда регуляторы ужесточат ответственность за разглашение коммерческой тайны. ➕ какие ИБ-нарушения совершали сотрудники и какие решения выносили суды: результаты исследования. ➕ чем закончились шпионские триллеры про мстительного админа, разгромившего сеть работодателя, и инсайдера, сливающего данные конкуренту.  Подписывайтесь и следите за информационной безопасностью.

Современные тенденции в сайтостроении. Классические CMS Сайт давно перестал быть роскошью, а стал привычным средством размещения информации. Сайты бывают личные, корпоративные, внутренние, внешние и вообще всякие разные. А потребность в сайте может возникнуть у кого угодно. Как реализовать эту потребность? Не столь давно альтернатив особо не наблюдалось, сегодня же вариантов масса, как понять какой из них вам подходит и не ошибиться? Чтобы ответить на этот вопрос мы решили сделать краткий обзор современных тенденций сайтостроения. Классические CMS – это всем известные Wordpress, Joomla, Drupal или Битрикс. Они имеют монолитную архитектуру и представляют из себя связку из набора скриптов, чаще всего на PHP – движка, который занимается генерацией контента и СУБД, в которой этот самый контент хранится, вместе с настройками веб-приложения. Появились классические CMS давно, в самом начале нулевых и обусловили переход от простого статического HTML к динамическим сайтам, где содержимое страницы генерировалось на лету, согласно запросу пользователя. В свое время это была небольшая технологическая революция и ее детищем стал Веб 2.0 – т.е. сеть, контент в которой производился самими пользователями: форумы, блоги, вики-проекты. Но все это имело и обратную сторону медали. Во-первых – сложность, для работы динамического сайта кроме веб-сервера требовались СУБД и сервер-приложений для обработки скриптов движка. Все это нужно грамотно настроить и увязать между собой. Выделить и поделить ресурсы и т.д. и т.п. Во-вторых, остро вставала проблема безопасности. Вам требовалось поддерживать актуальность самого движка, плагинов и тем к нему, скриптового языка (PHP), СУБД, а также правильно настроить права доступа. Все это выливается в сложность администрирования и сопровождения. Плюс резервные копии нужно создавать как для СУБД, так и для статической части контента, что добавляет забот и хлопот. Но при этом классические CMS оказались очень просты в использовании для создателей контента. Развитые админ-панели позволяли делать все просто и интуитивно понятно, с использованием концепции WYSIWYG – что вижу, то и получаю. Также они обросли большим количеством тем и плагинов, которые пользователь мог самостоятельно установить из магазина и расширить возможности сайта, не прибегая к услугам технических специалистов. Но вместе с удобством это принесло целый ворох дополнительных проблем, неконтролируемое и не всегда своевременно поддерживаемое добавление стороннего кода в CMS вызывает огромное количество проблем безопасности, тот же Wordpress не раз и не два массово ломали через плагины. Еще одна проблема таких CMS – это производительность. Так как сайт у нас динамический, то веб-страниц как таковых не существует до обращения к ним пользователя. Получив от пользователя URL нужной страницы движок вытаскивает нужные данные из СУБД и генерирует веб-страницу налету, отдавая ее пользователю через веб-сервер. С ростом количества посетителей и количества контента растут затраты вычислительных ресурсов. Но большинство страниц на самом деле имеет статическое содержимое и их можно эффективно кешировать и отдавать уже готовый результат, вместо генерации налету. Но это еще более усложняет систему, так как требует наладить взаимодействие компонентов сайта с системой кеширования и грамотно ее настроить. Если мы не сможем своевременно инвалидировать кеш – пользователь будет получать устаревшие данные, перестараемся – малейшее изменение на сайте будет вызывать каскадный сброс кеша и резкий рост вычислительной нагрузки. С ростом нагрузки основной проблемой становится база данных и масштабирование требуется преимущественно вертикальное. Горизонтальное масштабирование требует определенных затрат и квалификации, что не всегда оправдано (дешевле залить железом). В общем – классические CMS с одной стороны крайне просты и доступны в использовании, с другой требуют постоянного внимания, как в части администрирования, так и поддержки и сопровождения. Но для большинства – это наиболее легкий путь к своему сайту.

YDB Qdrant‑compatible — Qdrant API поверх YDB - Работает с IDE‑плагинами Roo Code и Kilo Code (как базовый URL Qdrant) - Быстрый top‑k с авто‑индексом; хранение/поиск в YDB; Демо: http://ydb-qdrant.tech:8080 (без API‑ключа) Локально: `http://localhost:8080` Подробнее на сайте #Qdrant #YDB #VectorSearch #RAG #RooCode #KiloCode #NodeJS

​​Сказка о потерянном времени В очередной раз помогали коллегам заказчика делать инвентаризацию. И в очередной раз нашли много неиспользуемого, включая то, про что давно забыли и были приятно удивлены количеством освободившихся ресурсов. А пока мы решили составить свой рейтинг ненужности, возможно у вас он будет другой, ждем ваших комментариев. 1️⃣ На первом месте с огромным отрывом стоят локальные базы знаний, чаще всего выполненные на Wiki-движках, но абсолютно необязательно. Причина проста – такой базой знаний должен кто-то заниматься, причем заниматься постоянно. Если этого нет, то база утрачивает актуальность и ей просто перестают пользоваться, а если перестают пользоваться, то какой смысл ее пополнять. Сейчас, на просьбы заказчика сделать им такой сервис мы сразу отвечаем, что сделать его – это только 1% от все работы. Остальное – это наполнение и тут им придется уже как-то самим. Обычно, когда дело доходит до конкретной реализации и назначения ответственных энтузиазм как-то сам утихает. 2️⃣ Второе место – это всякие внутренние порталы. В теории это видится некой точкой консолидации, в которой размещают новости, объявления, внутренние документы, инструкции и т.д. и т.п. Но, на практике, всем этим снова нужно кому-то заниматься. И если нет специально назначенного за этим человека, то такой портал становится нафиг никому не нужным. Еще меньше он нужен сотрудникам, что надо – доведет руководство. Да и все остальное легче передать через систему совместной работы, тот же Битрикс 24 или аналоги, им хотя бы ежедневно пользуются. 3️⃣ Третье место по ненужности занимает, как это не странно, мониторинг. Но здесь тоже все достаточно прозаично. Ожидания не совпадают с реальностью. Многие представляют мониторинг как красивые графики и диаграммы, которые можно вывести на отдельный монитор и с гордостью показывать начальству. А по факту получаем кучу метрик, не меньше алертов, которые приходят по делу и без дела и необходимость серьезно вникать и настраивать продукт. После чего тот же условный Zabbix задвигается на самый дальний сервер и благополучно забывается. 4️⃣ Четвертое место, хотя можно и поменять местами с мониторингом, это системы учета заявок и инцидентов, тот же GLPI. Но мы все-таки вынесли его на четвертое, потому что внедряют его уже более-менее осознанно и данные системы менее популярны у начинающих, нежели мониторинги. Но чтобы у вас работала система учета заявок, у вас уже должна быть работа с заявками или осознанная необходимость и политическая воля в ее создании и внедрении. Потому как инструмент выбирается для решения задачи, а не наоборот. Вы же не покупаете отбойный молоток просто так и только потом начинаете искать куда бы его применить. Если нет системы работы с заявками, равно как и самой культуры такой работы, то данный сервис окажется бесполезен и поигравшись месяц другой о нем все забудут. 5️⃣ На следующее место мы бы поставили различные средства наблюдения и управления инфраструктурой, раздел это довольно обширный и отнести к нему можно много чего, скажем тот же IPAM или Ansible. Пятое место здесь потому, что внедряются такие вещи хотя бы уже с базовым пониманием что и как, но очень часто их внедрение обусловлено не необходимостью, а желанием админа поиграться с новой «крутой» технологией. Но со временем играться надоедает и все это переходит в разряд ненужного. Еще один вариант, это когда инструменты явно перерастают потребности и квалификацию персонала. Понятно, что это круто, но нафиг никому не нужно. Чаще всего такие проекты тихо саботируются и тут же сворачиваются после ухода инициатора или потери его интереса к проекту. 👆 А по факту все это – потерянное время и ресурсы. И каждый раз, когда возникнет желание внедрить что-нибудь такое следует спросить себя - а оно мне точно нужно? А зачем? А нужно ли оно еще кому-нибудь кроме меня? И если вы затрудняетесь дать твердые и аргументированные ответы – оно вам не нужно.

🔥 Готов принять настоящий бизнес-вызов? Участвуй в VTB API hackathon 2025! Когда: 27 октября – 22 ноября Формат: онлайн + офлайн ⚡ В 2025 году еще больше возможностей: реальные и практические кейсы, общение с экспертами, карьерные консультации от HR-специалистов и призовой фонд 2 млн ₽ Выбери свой трек из 3 актуальных направлений для открытого банкинга: 🔹 Мультибанк: единый интерфейс финансового сервиса 🔹 Защита API: автоматический анализ уязвимостей 🔹 «Оркестр» из API: анализ и тестирование бизнес-процессов Участвуй, особенно если ты: - Студент или выпускник технического вуза - Backend/Frontend-разработчик - Аналитик, QA, AQA и SDET - Product/Project-менеджер - Системный архитектор - Специалист по ИБ 📌 Подробнее о треках и условиях участия — на сайте хакатона! ➡️ Регистрируйся до 2 ноября, 23:59 (МСК) по ссылке.

Залить железом В обсуждениях в очередной раз столкнулись с одним из способов решения проблем с нехваткой ресурсов в информационных системах, который среди коллег называется «залить железом». Многие негативно к нему относятся, но совершенно зря. Начнем с самого способа – он прост, как мычание. Его смысл – если вам не хватает аппаратных ресурсов, то просто пойдите и купите их. Нет, мы не будет рассматривать явно пограничные случаи, вроде того, когда администратор вовсе не удосужился выполнить оптимизацию и грамотное выделение ресурсов, а будем исходить из того, что у нас есть нормальная, среднестатистическая система, которой вдруг стало тесно. Здесь у нас есть два пути – просто пойти и купить недостающий ресурс или стать на путь оптимизации. Но в большинстве случаев первое будет проще, быстрее и, как это ни странно, выгоднее. Почему? Потому что дает бизнесу четкие суммы и сроки. Если у вас есть мониторинг (а он же есть?), то нет никакого труда выявить тренды и сделать прогнозы, тем более что с такими задачами прекрасно справляется ИИ. После чего вы говорите: нужно купить то и это, сумма такая, на год-полтора вопрос закроем. Отлично. Если проблема решается деньгами – то это не проблема, а просто статья затрат. Бизнес понимает что именно он сейчас покупает и на какой период эти затраты следует относить. А вот тропа оптимизации куда более скользкая. Там нет ответа сколько это будет стоить и что мы в итоге получим. Потому что для начала надо оплатить аудит и анализ. Стоит это будет XXXX руб./час, оплатить надо минимум NN часов. Ну а по факту вы получите просто анализ вашей инфраструктуры и рекомендации. И не факт, что вердикт не будет звучать как: купите новое железо. Оптимизация, тоже не дешевое удовольствие и хорошо если разовое. Иначе бизнес попадает в зависимость от оптимизаторов и их поддержки. Особенно это касается оптимизации коробочных продуктов с регулярными обновлениями, например, 1С:Предприятие. Да, вам переписали запросы, оптимизировали цепочки. Но теперь вы при каждом обновлении должны повторять весь этот процесс заново, что резко увеличивает стоимость поддержки такого решения. А теперь снова посмотрим на это все со стороны бизнеса. В первом случае ему предлагают потратить некоторую сумму денег здесь и сейчас и закрыть проблему на год-полтора. Потом повторить. Это понятно, это хорошо ложится в бизнес-планирование и дает понимание, когда нужно подкопить резервы и запланировать очередные траты. Сценарий с оптимизацией обычно выглядит как – у вас проблема, но вы попали на бабки, ежемесячная такса такая-то. И как соскочить с этой иглы решительно непонятно. Ладно, оставим аутсорс, возьмем нужного специалиста в штат. А сколько будет стоит этот специалист? Явно не дешево, так что это та же самая ежемесячная «дань», только несколько в ином виде. И снова никто не гарантирует, что через год-полтора старательных оптимизаций вам снова не скажут, что все, ресурсов больше нет, оптимизировать нечего, покупайте новое железо, а там продолжим. Но вы не подумайте, мы вовсе не против оптимизаций. Но подходить к этому вопросу нужно трезво и взвешенно. Если проблему можно залить железом – просто залейте. Особенно если это решает проблему на продолжительный временной отрезок. А оптимизация – это уже когда низы не хотят, а верхи не могут жить по-старому. Т.е. когда проблема уже явно железом не заливается и требует серьезного перестроения всей инфраструктуры. В этом случае да, даже небольшая оптимизация помогает здесь и сейчас, а также дает время и ресурсы для качественных изменений.

Приглашаем в телеграм-канал AI Inside Канал для тех, кто смотрит на искусственный интеллект не как на хайп, а как на рабочий инструмент. Здесь нет абстрактных теорий — только прикладные решения. Что вас ждет: - Технологии: расскажем, как ИИ решает реальные бизнес-задачи — от автоматизации до аналитики. - Кейсы: покажем успешные примеры внедрения и использования ИИ-инструментов. - Экспертиза: объясним сложные технологии простым языком с фокусом на практическую пользу. Наша цель - дать конкретные идеи и инсайты, которые можно применить уже сегодня. Присоединяйтесь к сообществу практиков! Подробнее #реклама 16+ О рекламодателе