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

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

Современные тенденции в сайтостроении. Классические 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+ О рекламодателе

​​Как сэкономить на регистрации и продлении доменов Не так давно мы размещали подаренные нам при продлении доменов промокоды на бесплатную регистрацию в доменной зоне SITE, но были несколько удивлены реакциями, состоявшими преимущественно из дизлайков. При обсуждении выяснилось, что отдельное недовольство вызывает ценовая политика регистратора и высокая цена продления, от чего многие воспринимают такие предложения как завуалированный лохотрон и подобное мнение имеет под собой основание. Но если подойти к вопросу грамотно, то можно существенно экономить на регистрации и продлении доменов, а также не пропускать привлекательных предложений. Но для начала разберемся кто есть кто на этом рынке и какие функции он выполняет. Прежде всего у каждой доменной зоны есть администратор, для RU и РФ — это Координационный центр доменов .RU/.РФ, сам он не выдает домены, но осуществляет общее управление зонами и осуществляет аккредитацию регистраторов. Количество регистраторов невелико, всего в списке их 131 организация, но крупных, обслуживающих более 10 000 доменных имен ровно 20. Полный их список приведен тут: https://cctld.ru/domains/reg/ Кроме регистраторов есть еще их партнеры, которые не являются регистраторами, но могут регистрировать домены через одного из них. При этом ценовые условия у партнеров обычно существенно приятнее, чем у регистраторов. Чем обусловлена подобная щедрость? Ведь, как известно, бесплатного сыра не бывает. Все просто: обычно партнеры имеют смежный бизнес, для которого продажа доменных имен является сопутствующей. Чаще всего это хостинг-провайдеры, которые таким образом формируют полный пакет услуг, а низкие цены на домены используют как еще одно конкурентное преимущество. В тоже время они будут совсем не против если вы просто купите или перенесете к ним свои домены. Все эти процессы обычно хорошо автоматизированы и кушать не просят, а копеечка капает. Сами же регистраторы поддерживают куда более высокий уровень цен и любят наводить тень на плетень с запутанными тарифами, больше всего они любят скрывать стоимость продления. А это один из основных параметров на который следует обратить внимание при выборе доменной зоны. Потому как регистрируете вы домен один раз, а продлять его придется ежегодно. Сейчас средняя стоимость продления домена RU у регистраторов составляет примерно 600 руб. за домен. Если же брать партнеров, то продлить домен у них в среднем обойдется в 200 руб. Как говорится – почувствуйте разницу. Что касается приобретения, то зарегистрировать домен можно вообще за копейки, а то и бесплатно. Например, самая вкусная цена на домены RU сегодня у Джино, всего 39 руб., правда за продление с вас уже попросят стандартные 589 руб. Но приобретение домена не привязывает вас к регистратору или его партнеру, вы можете свободно передавать домены как между партнерами, так и регистраторами. Поэтому покупаете домены, где вам удобно, а затем в течении года переносите их к партнеру с низкими ценами и продляете их у него. Многие опасаются переносить домены к партнерам, так как это обычно небольшие организации или ИП, не вызывающие особого доверия и уверенности в завтрашнем дне. Но это абсолютно необоснованное опасение. Никаких прав на домены партнеры не имеют и работают сугубо через регистратора. Для переноса доменов от одного партнера к другому в пределах регистратора достаточно простого письма. Если партнер морозится или вообще перестал существовать, то перенос домена к другому партнеру обязан выполнить регистратор. Это несложно и такие ситуации у нас были. Для переноса домена между регистраторами вы просто запрашиваете у текущего AuthInfo-код и передаете его в поддержку нового. Обычно это имеет смысл делать, если партнеры нового регистратора предлагают более выгодные условия, нежели партнеры старого. Причем это может быть одна и таже организация. Если регистратор прекратил свое существование или отказывает вам в переносе, то AuthInfo-код можно запросить у Координационного центра.

В телеграмм любят авторские каналы 📲 Мы думали, что классных редакционных каналов немного, но недавно мне порекомендовали один и я хочу поделиться им с вами 🤖 Авторы оперативно публикуют все новинки в мире IT, например: 🔗Как AI помогает разработчикам  🔗Что происходит с соцсетями? Какие уходят, а какие планируют вернуться в Россию? 🔗Самые свежие новости По-моему, очень крутой формат!  Подпишитесь, чтобы быть в курсе самых свежих технологических трендов 👇🏼 #реклама О рекламодателе

Переносим контент на новый сайт, заодно заново перечитываем некоторые статьи 🔹 WD VelociRaptor - пожалуй, самый быстрый жесткий диск Western Digital VelociRaptor можно без преувеличения назвать легендарной серией HDD и объектом мечтания многих пользователей. Как и у любой топовой "железки" основным сдерживающим фактором была и остается цена. Однако сегодня стоимость младших моделей линейки не сказать, что демократична, но вполне приемлема и поэтому мы решили протестировать один из таких дисков. Статья от октября 2012 года, интересно было вернуться в те времена и посмотреть на одного из лидеров лагеря жестких дисков, тогда еще на равных конкурировавшем с массовыми SSD. А теперь? Самый дешевый SATA SSD положит его на лопатки. Такое вот развитие технологий, да и времена поменялись, сегодня иные требования и иные критерии оценки накопителей.

И снова одно и тоже... Выключился свет, бесперебойник погас, сервера упали... А теперь... В общем - беда, да еще и в пятницу вечером. А надо было всего-лишь подстелить соломки... Настраиваем централизованное управление электропитанием в сети при помощи NUT Всем известно, что для защиты от сбоев электропитания нужно купить бесперебойник. Но сам по себе источник бесперебойного питания не решает проблему, а только отсрочивает негативные последствия. Действительно, если питание пропадет надолго, то после разрядки батарей ИБП ваши системы аварийно завершат работу. Избежать этого позволяют модели, имеющие обратную связь, но, чтобы использовать эти возможности нам потребуется система управления электропитанием и сегодня мы расскажем об открытом и бесплатном продукте - NUT (Network UPS Tools). https://interface31.ru/tech_it/2022/08/nastraivaem-centralizovannoe-upravlenie-elektropitaniem-v-seti-pri-pomoshhi-nut.html

Запустите рекламу в телеграм-каналах с Яндекс Директом Перфоманс-реклама теперь в телеграм-каналах ⚡ Яндекс Директ знает, как привлечь целевую аудиторию 💰👌 Попробовать #реклама yandex.ru О рекламодателе

Всё работает! Что вам ещё надо? — Антон Дорошкевич, PGConf.СПб 2023 За 6 лет моего опыта работы с 1С на PostgreSQL СУБД прошла огромный путь, и хочется осветить этот путь, чтобы понять, какой огромный прогресс уже достигнут. Но, как всегда, пользователям всего мало, так что помимо уже пройденного пути в докладе будут освещены пожелания к СУБД с точки зрения эксплуатации, а так же даны обходные пути решения. https://youtu.be/iM-wVbhf8-E?si=Rbmc8E20E23mIy90 Доклад известного специалиста по PostgreSQL в связке с 1С. Рекомендуется всем к ознакомлению. У кого нет доступа к YouTube выкладываю отдельным файлом.

Начальник про ИИ на работе: 🔸 «ИИ — баловство для школьников, у нас серьезный бизнес» 🔸 «Хотите нейросетям всю информацию о компании „скормить“?» 🔸 «У нас нормальные процессы, негде применять ИИ»  И это ошибка. Пока вы думаете, конкуренты действуют. Уже 70% компаний среднего и малого бизнеса разных отраслей используют ИИ для ускорения внутренних задач. Как они это делают? Расскажут эксперты Directum 31 октября.  На вебинаре за 40 минут: ✅ узнаете, как другие компании используют ИИ и как вам не отставать от них; ✅ увидите в действии все возможности ИИ Directum для компаний среднего и малого бизнеса —  распознавание, генерация, сравнение версий, вопросно-ответный поиск, юридическая экспертиза договора, аннотации; ✅ убедитесь, что для работы с ИИ-сервисами не нужны специальные знания — разберется любой сотрудник; ✅ сможете отделить факты про ИИ в бизнесе от вымысла и принимать обоснованные решения. Хватит верить в мифы, пора выбирать самому. Регистрируйтесь.

Как я развалил бизнес-план или про то, где сейчас денег нет Погода у нас сегодня наконец-то немного наладилась, поэтому я нисколько не удивился спонтанному предложению молодых коллег приехать к ним на дачу, покушать мяса, да поболтать за рюмкой чая. Тем более что им нужен мой совет как старшего товарища. Ну да чего бы и не съездить, чего бы и не поговорить. А вот дальше началось интересное. Оба коллеги возрастом около 30 лет, админы на производственных предприятиях. Ребята неплохие, знающие и умеющие. При этом повод к беседе оказался очень интересный. Они коротко изложили мне свой бизнес-план – открыть небольшой сервис по ремонту и обслуживанию ПК. А мое мнение их интересовало потому, что у меня такой сервис был. Сказать, что я чуть не упал со стула – это значит ничего не сказать. И сразу пояснил их, что спросили они меня не об этом, точнее спрашивать надо было почему я сервис закрыл. Ну парни оказались упорными и пришлось разложить все по полочкам. Начнем с ремонта. Кого и где они собрались ремонтировать? Сегодня розничный рынок продажи ПК поделен парой-тройкой крупных игроков и все вопросы покупатели будут решать с ними. К ним пойдут владельцы старых ПК с истекшей гарантией и покупатели всякого китайского творчества с маркетплейсов. Далее – ремонтопригодность современного железа упала в разы. Чинить в большинстве своем нечего. Только менять, крупными узлами, что по цене абсолютно невыгодно, проще немного добавить и купить новый. А для китайцев проблемой может стать даже поиск и приобретение запчастей. Что будет долго, дорого и не факт, что подойдет. Это если найдете. Поэтому весь «ремонт» будет сводиться к замене дисков, памяти и блока питания, а на этом кассу не сделаешь. К тому же гораздо чаще приносить туда будут технику не с аппаратными проблемами, а с программными. То игруха с торрента не запускается, то ломаный фотошоп перестал работать, то винду ушатали. Лицензий на все это, конечно, нет. Приобретать их никто не собирается, а попытка предложить альтернативный бесплатный софт будет рассматриваться как открытое вредительство. И это очень и очень тонкий лед. Практически каждый день поднимаешь с пола статью. За очень смешные деньги, потому как на этой стезе массово поджимают студенты, которые прибегут на дом и сделают все и даже больше за условную миску супа. Что дальше? Заправка картриджей? Все струйные принтеры практически поголовно перешли на СНПЧ, а налить чернила пользователь и сам может. Лазерники? Прошли те времена, когда лазерный картридж можно было тупо заправить на коленке с отверткой и пылесосом. Сегодня, если вы хотите качественной печати, то нужно гораздо больше телодвижений и без заправочной станции уже не обойтись. А если у вас сервис в жилом доме, то там заправка требует дополнительных усилий. Ибо шум, пыль от тонера, запахи. В общем тут надо или заниматься серьезно или не заниматься вообще. Тем более что прибыльность там тоже так себе. На маркетплейсах полно совместимых картриджей по цене пары заправок. А если человек печатает дома, то раз в год-полтора ему проще купить новый картридж, чем заправлять старый. Торговля железом, апгрейды, китайские Xeon и все такое прочее? Тоже нет. Минули те времена, когда можно было в Москве купить железа по второй колонке прайса (мелкий опт), накрутить свои 6-10% и что-то с этого получить. Сегодня у каждого есть интернет, там маркетплейсы и цены в них будут ниже вашей закупки. И товар они доставляют быстрее, и вернуть его проще. В общем расстроил я коллег донельзя. Заодно пояснил, что в этой сфере частный клиент – это очень токсичный клиент и никогда он к вам с хорошим настроением не приходит. А сервис я закрыл после того, как после выплаты всех зарплат, аренд и налогов забрал оттуда 11 000 рублей (в ценах 2011 года), хотя жизнь в нем кипела, клиенты были, работы хватало. Точнее хотел закрыть, но пацаны уговорили отдать им. Отдал, сугубо по остаточной цене активов. Они еще полтора года барахтались и все ушли в найм.

​​И снова про белок и колеса… Этот поучительный случай произошел на неделе, но мы решили оставить его до выходных. Позвонили нам из одной незнакомой нам организации и пожаловались, что от них ушел администратор и они буквально «осиротели». Начинаем разбираться что почем. Фирма небольшая, десяток ПК, два принтера, сервер. Админ работал на полставки за 25 тыс. руб. Приходил на полдня, решал насущные проблемы, остальное время был удаленно или на телефоне. А чего, спрашиваем, ушел? Отвечают, как нам показалось, с затаенной обидой: нашел работу лучше на полный рабочий день. Ну так договоритесь с ним, - предлагаю, - пусть он вам по удаленке помогает, тут на месте то делать, наверное, особо нечего. И вот тут уже обида включилась по полной. Мол отказался он, сказал, что на нас у него нет времени, а ведь мы его прямо после института взяли, можно сказать подобрали, обогрели в люди вывели… И делать у нас всегда есть чего, у нас иногда компьютеры тормозят, иногда сеть барахлит, принтеры тоже бывает бумагу заедают. И вообще надо чтобы кто-то помогал нам, вот на той неделе у нас табличка пропала из общей папки. Разговаривая дальше, стало понятно, что нужен им не системный администратор, а некий широкого профиля компьютерный нянька, чтобы и застрявшую бумагу вытаскивал и пропавшие файлы искал и сопли пользователям вытирал. Понимая, что это очевидно не наш клиент, пробуем предложить свои услуги. Мол давайте сначала сделаем аудит, посмотрим, что у вас вообще есть, что может быть источником проблем. Приведем в порядок инфраструктуру, поможем наладить рабочие процессы и большинство ваших проблем рассосется само собой. После некоторого молчания с той стороны трубки последовал ответ: вы знаете, но нам ничего этого не надо, у нас и так все нормально работает, нам нужен человек на полставки, чтобы приходил и помогал нам. В общем разошлись мы каждый в свою сторону, прекрасно поняв, что не подходим друг другу. Но мы задумались о другом, что сколько вокруг таких организаций, у которых в принципе все работает и им надо, чтобы просто кто-то приходил им «помогал». Причем их достаточно много как в мелком бизнесе, так и в бюджетной сфере. Попадая в такую организацию, специалист становится на путь деградации, потому что занимается всем чем угодно, но не своей прямой деятельностью. А именно постоянно решает мелкие инфраструктурные проблемы и утирает сопли пользователям. Да и полставки в таких местах весьма условны, потому как кроме полдня в офисе остается требование помогать если что удаленно и быть доступным на телефоне, т.е. фактически полный рабочий день, а местами порой и ненормированный, как это часто обстоит у самых маленьких. Год-два в таком темпе и можно будет не только забыть о развитии, а и начать терять уже имеющиеся навыки. При этом перспектив там и вдалеке не просматривается, потому что время от времени подвисающие компьютеры, глючная сеть и т.д. и т.п. представляются там чем-то нормальным. А чего? Работает ведь? А если что – у нас есть мальчик, сейчас свистнем, прибежит, починит. Попадать в такие места можно только либо от лютой безысходности, либо после института, когда просто нужен какой-то стаж и возможность заработать хоть какую-то копейку и постепенно подыскать себе нормальную работу. А сталкивались ли вы с подобными организациями? Или может начинали с них свой трудовой путь?

REKONFA Live 6 ноября приглашаем рекламодателей, агентства и рекламные площадки обсудить технологии, маркетинговые инструменты и актуальные новинки. Ключевые участники рынка поделятся опытом и расскажут: — О ситуации на рынке рекламы — Как продвигать и продавать в интернете в 2025 году — Как бизнесу адаптироваться к меняющимся условиям Вас ждут доклады на актуальные темы, классный нетворкинг, вдохновляющая атмосфера для творчества и креатива. Встречаемся 6 ноября в Москве. Для тех, кто не сможет приехать, организуем интерактивное digital-шоу. Мероприятие бесплатное, нужно только зарегистрироваться. Зарегистрироваться #реклама 18+ ya.rekonfa.ru О рекламодателе

​​Как и зачем делить базы данных по отдельным установкам СУБД В комментариях также спрашивали, как и по каким принципам делить базы по установкам экземпляров сервера БД и сколько памяти кому выделять. Если брать конкретные цифры, то дать тут общие рекомендации сложно, нужно смотреть на сценарии применения, объемы данных, интенсивность и характер обращения к СУБД, в общем – требуется индивидуальный подход. Поэтому вместо этого мы рассмотрим общие принципы, и вы могли понять для чего и зачем мы плодим установки и какие плюсы от этого получаем. Описывая модель нами сознательно предельна упрощена и не требует каких-либо специфических знаний, а также применима к любым СУБД, а не только PostgreSQL. Одной из задач СУБД – является быстрое и эффективное предоставление прикладному ПО доступа к хранящихся в базе данных. А получить мы их можем одним единственным образом – прочитать с диска. Но чтение с диска – процесс дорогой и достаточно медленный. Поэтому, чтобы избежать повторного чтения СУБД помещает поднятые с диска данные в оперативную память. И делать так она будет до тех пор, пока будет иметь доступную память. Именно этим объясняется известное всем стремление SQL-серверов занять всю доступную память. В простейших случаях, когда база по размеру гораздо меньше, чем размер оперативной памяти, то она будет закеширована практически вся. Если же суммарный размер данных больше размера доступной памяти, то данные в кеше будут иметь приоритет по количеству обращений к ним. Таким образом более горячие данные будут вытеснять более холодные. При достаточном количестве памяти через некоторое время будет достигнут некоторый баланс и все горячие данные будут в кеше. Иначе одни будут постоянно вытеснять другие и СУБД будет вынуждена постоянно прибегать к дисковому чтению. Хотя это не всегда плохо, с появлением быстрых дисков, таких как NVMe, иногда более оптимально будет читать данные с диска, нежели тратить на их хранение достаточно ограниченный ресурс оперативной памяти. А теперь про то, зачем делить базы по разным экземплярах СУБД. Представим, что у нас есть некоторый единый сервер, где находятся базы торгового подразделения и бухгалтерии. Весь месяц бухгалтерия тихо вбивает первичку, проводит оплаты, а торговля торгует, получает остатки, взаиморасчеты, резервы и задолженности. Кеш прогрет, его хватает обоим базам и вроде бы все хорошо. Но вот наступает конец месяца, и бухгалтерия начинает закрывать месяц, готовить отчетность, начислять зарплату, считать налоги, формировать регламентированные отчеты. Объем потребляемых ею данных резко вырастет, и они просто вытеснят из кеша данные торгового отдела. И чем активнее будет работать бухгалтерия, тем хуже будет торговле. При этом у бухгалтерии все хорошо, у них все летает, а у торговли раньше резервы или задолженность считались за пару секунд, а теперь программа тупит десятками секунд или минутами. Что вызывает сплошной негатив пользователей. Также возможен обратный сценарий, когда торговля активно подбивает итоги и тормозит уже бухгалтерия. Какой выход? В лоб – добавить память. Но опять-таки мы не можем гарантировать, что кто-то не перетянет на себя все одеяло, разве что памяти с запасом хватит на всех. Но это не про современные объемы данных. Поэтому просто делим один экземпляр СУБД на два и каждому выделяем свое количество памяти. Да, в итоге каждый получит меньше, чем мог бы откусить из общей кучи и может начать работать немного медленнее. Но это будет гарантированная производительность, особенно после того, как вы определите достаточный объем памяти для хранения всего горячего кеша. Соседи могут делать все, что угодно. Равно как и вы. Но теперь мы можем анализировать и оптимизировать выделение ресурсов под единственный характер нагрузки. Можем делать быстрее, можем медленнее, но самого плохого сценария – качелей, когда сегодня все летает, а завтра все тормозит – мы избежим. При этом накладные расходы на дублирование экземпляров СУБД минимальные, особенно если мы используем контейнеры.

erid: 2W5zFHwJTBE 🎥 Хочешь фото как у Zara? 🎬 Видео как у Apple? 📸 Упаковку как у Dior? Теперь всё можно сделать прямо в Telegram 💎 Идейкин собрал все лучшие нейросети в одном месте: ⚡ SORA 2 ⚡ VEO 3 ⚡ GPT-5 Vision ... и многое другое 👉 💥 +100 токенов каждому новичку! 👉 @ideikinAiBot — Контент-студия у тебя в телефоне. #идейкинБот #генерацияКонтента #AiДоступноКаждому #Создаю Контент