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

Вопрос в субботний вечер

Имеется Mikrotik, конфигурация сброшена, в брандмауэр добавлены следующие правила:

/ip firewall filter
add action=accept chain=input connection-state=established,related in-interface=ether5
add action=drop chain=input connection-state=invalid in-interface=ether5
add action=accept chain=input in-interface=ether5 protocol=icmp
add action=drop chain=input in-interface=ether5

Остальная конфигурация не редактировалась.

❓❓❓ Вопрос: можно ли подключиться с помощью Winbox через интерфейс ether5?

​​Про обслуживание и оптимизацию баз 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С. Разумеется, это ни к чему не обязывает.

​​Пятничное, о жизни. Информационный шум.

Мне кажется, если сейчас каким-нибудь образом переместить сюда человека 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, то с ее языком разметки вам придется непосредственно столкнуться.

Антон Дорошкевич. Тонкости эксплуатации PostgreSQL

Тема перехода с MS SQL на PostgreSQL становится все актуальнее. В докладе на конференции Infostart Event 2022 Saint Petersburg руководитель проектов Антон Дорошкевич рассказал, что ждёт после перехода, к чему нужно быть готовым, и какие варианты решения задач существуют на данный момент в мире PostgreSQL для его успешной эксплуатации. https://youtu.be/sx1FCw0zPCY?si=Oo4CbF1JybZ9IJln

Доклад в виде статьи: https://infostart.ru/1c/articles/1883272

У кого нет доступа к YouTube видео приложено отдельно

​​Postgres + 1C = сильно тормозит?

Самое частое нарекание на работу свежеустановленной связки PostgreSQL + 1С:Предприятие – это тормоза. Причем именно тормоза, а не замедление, и часто видимые невооруженным глазом.

Означает ли это, что Postgres плох? Вовсе нет, просто привычный подход Далее – Далее – Готово здесь не работает.

Если MS SQL из коробки имеет вполне оптимальные настройки и без проблем будет работать на небольших инсталляциях 1С, то Postgres настроен на запуск и работу в минимальной конфигурации, что сразу сказывается на производительности.

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

Как это сделать – написано в нашей статье: Оптимизация производительности PostgreSQL для работы с 1С:Предприятие

Перенос баз данных 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 с одной стороны крайне просты и доступны в использовании, с другой требуют постоянного внимания, как в части администрирования, так и поддержки и сопровождения. Но для большинства – это наиболее легкий путь к своему сайту.

​​Сказка о потерянном времени

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

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

1️⃣ На первом месте с огромным отрывом стоят локальные базы знаний, чаще всего выполненные на Wiki-движках, но абсолютно необязательно.

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

Сейчас, на просьбы заказчика сделать им такой сервис мы сразу отвечаем, что сделать его – это только 1% от все работы. Остальное – это наполнение и тут им придется уже как-то самим. Обычно, когда дело доходит до конкретной реализации и назначения ответственных энтузиазм как-то сам утихает.

2️⃣ Второе место – это всякие внутренние порталы. В теории это видится некой точкой консолидации, в которой размещают новости, объявления, внутренние документы, инструкции и т.д. и т.п.

Но, на практике, всем этим снова нужно кому-то заниматься. И если нет специально назначенного за этим человека, то такой портал становится нафиг никому не нужным.

Еще меньше он нужен сотрудникам, что надо – доведет руководство. Да и все остальное легче передать через систему совместной работы, тот же Битрикс 24 или аналоги, им хотя бы ежедневно пользуются.

3️⃣ Третье место по ненужности занимает, как это не странно, мониторинг. Но здесь тоже все достаточно прозаично. Ожидания не совпадают с реальностью. Многие представляют мониторинг как красивые графики и диаграммы, которые можно вывести на отдельный монитор и с гордостью показывать начальству.

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

4️⃣ Четвертое место, хотя можно и поменять местами с мониторингом, это системы учета заявок и инцидентов, тот же GLPI. Но мы все-таки вынесли его на четвертое, потому что внедряют его уже более-менее осознанно и данные системы менее популярны у начинающих, нежели мониторинги.

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

Вы же не покупаете отбойный молоток просто так и только потом начинаете искать куда бы его применить.

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

5️⃣ На следующее место мы бы поставили различные средства наблюдения и управления инфраструктурой, раздел это довольно обширный и отнести к нему можно много чего, скажем тот же IPAM или Ansible.

Пятое место здесь потому, что внедряются такие вещи хотя бы уже с базовым пониманием что и как, но очень часто их внедрение обусловлено не необходимостью, а желанием админа поиграться с новой «крутой» технологией. Но со временем играться надоедает и все это переходит в разряд ненужного.

Еще один вариант, это когда инструменты явно перерастают потребности и квалификацию персонала. Понятно, что это круто, но нафиг никому не нужно. Чаще всего такие проекты тихо саботируются и тут же сворачиваются после ухода инициатора или потери его интереса к проекту.

👆 А по факту все это – потерянное время и ресурсы. И каждый раз, когда возникнет желание внедрить что-нибудь такое следует спросить себя - а оно мне точно нужно? А зачем? А нужно ли оно еще кому-нибудь кроме меня?

И если вы затрудняетесь дать твердые и аргументированные ответы – оно вам не нужно.

Залить железом

В обсуждениях в очередной раз столкнулись с одним из способов решения проблем с нехваткой ресурсов в информационных системах, который среди коллег называется «залить железом». Многие негативно к нему относятся, но совершенно зря.

Начнем с самого способа – он прост, как мычание. Его смысл – если вам не хватает аппаратных ресурсов, то просто пойдите и купите их.

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

Здесь у нас есть два пути – просто пойти и купить недостающий ресурс или стать на путь оптимизации. Но в большинстве случаев первое будет проще, быстрее и, как это ни странно, выгоднее.

Почему? Потому что дает бизнесу четкие суммы и сроки. Если у вас есть мониторинг (а он же есть?), то нет никакого труда выявить тренды и сделать прогнозы, тем более что с такими задачами прекрасно справляется ИИ. После чего вы говорите: нужно купить то и это, сумма такая, на год-полтора вопрос закроем.

Отлично. Если проблема решается деньгами – то это не проблема, а просто статья затрат. Бизнес понимает что именно он сейчас покупает и на какой период эти затраты следует относить.

А вот тропа оптимизации куда более скользкая. Там нет ответа сколько это будет стоить и что мы в итоге получим. Потому что для начала надо оплатить аудит и анализ. Стоит это будет XXXX руб./час, оплатить надо минимум NN часов.

Ну а по факту вы получите просто анализ вашей инфраструктуры и рекомендации. И не факт, что вердикт не будет звучать как: купите новое железо.

Оптимизация, тоже не дешевое удовольствие и хорошо если разовое. Иначе бизнес попадает в зависимость от оптимизаторов и их поддержки. Особенно это касается оптимизации коробочных продуктов с регулярными обновлениями, например, 1С:Предприятие.

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

А теперь снова посмотрим на это все со стороны бизнеса. В первом случае ему предлагают потратить некоторую сумму денег здесь и сейчас и закрыть проблему на год-полтора. Потом повторить.

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

Сценарий с оптимизацией обычно выглядит как – у вас проблема, но вы попали на бабки, ежемесячная такса такая-то. И как соскочить с этой иглы решительно непонятно.

Ладно, оставим аутсорс, возьмем нужного специалиста в штат. А сколько будет стоит этот специалист? Явно не дешево, так что это та же самая ежемесячная «дань», только несколько в ином виде.

И снова никто не гарантирует, что через год-полтора старательных оптимизаций вам снова не скажут, что все, ресурсов больше нет, оптимизировать нечего, покупайте новое железо, а там продолжим.

Но вы не подумайте, мы вовсе не против оптимизаций. Но подходить к этому вопросу нужно трезво и взвешенно.

Если проблему можно залить железом – просто залейте. Особенно если это решает проблему на продолжительный временной отрезок.

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

​​Как сэкономить на регистрации и продлении доменов

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

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

Но если подойти к вопросу грамотно, то можно существенно экономить на регистрации и продлении доменов, а также не пропускать привлекательных предложений.

Но для начала разберемся кто есть кто на этом рынке и какие функции он выполняет.

Прежде всего у каждой доменной зоны есть администратор, для RU и РФ — это Координационный центр доменов .RU/.РФ, сам он не выдает домены, но осуществляет общее управление зонами и осуществляет аккредитацию регистраторов.

Количество регистраторов невелико, всего в списке их 131 организация, но крупных, обслуживающих более 10 000 доменных имен ровно 20. Полный их список приведен тут: https://cctld.ru/domains/reg/

Кроме регистраторов есть еще их партнеры, которые не являются регистраторами, но могут регистрировать домены через одного из них. При этом ценовые условия у партнеров обычно существенно приятнее, чем у регистраторов.

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

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

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

Сейчас средняя стоимость продления домена RU у регистраторов составляет примерно 600 руб. за домен. Если же брать партнеров, то продлить домен у них в среднем обойдется в 200 руб. Как говорится – почувствуйте разницу.

Что касается приобретения, то зарегистрировать домен можно вообще за копейки, а то и бесплатно. Например, самая вкусная цена на домены RU сегодня у Джино, всего 39 руб., правда за продление с вас уже попросят стандартные 589 руб.

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

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

Многие опасаются переносить домены к партнерам, так как это обычно небольшие организации или ИП, не вызывающие особого доверия и уверенности в завтрашнем дне. Но это абсолютно необоснованное опасение.

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

Если партнер морозится или вообще перестал существовать, то перенос домена к другому партнеру обязан выполнить регистратор. Это несложно и такие ситуации у нас были.

Для переноса домена между регистраторами вы просто запрашиваете у текущего AuthInfo-код и передаете его в поддержку нового. Обычно это имеет смысл делать, если партнеры нового регистратора предлагают более выгодные условия, нежели партнеры старого. Причем это может быть одна и таже организация.

Если регистратор прекратил свое существование или отказывает вам в переносе, то AuthInfo-код можно запросить у Координационного центра.

Переносим контент на новый сайт, заодно заново перечитываем некоторые статьи

🔹 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

Всё работает! Что вам ещё надо? — Антон Дорошкевич, PGConf.СПб 2023

За 6 лет моего опыта работы с 1С на PostgreSQL СУБД прошла огромный путь, и хочется осветить этот путь, чтобы понять, какой огромный прогресс уже достигнут. Но, как всегда, пользователям всего мало, так что помимо уже пройденного пути в докладе будут освещены пожелания к СУБД с точки зрения эксплуатации, а так же даны обходные пути решения.

https://youtu.be/iM-wVbhf8-E?si=Rbmc8E20E23mIy90

Доклад известного специалиста по PostgreSQL в связке с 1С. Рекомендуется всем к ознакомлению. У кого нет доступа к YouTube выкладываю отдельным файлом.

Как я развалил бизнес-план или про то, где сейчас денег нет

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

Ну да чего бы и не съездить, чего бы и не поговорить. А вот дальше началось интересное. Оба коллеги возрастом около 30 лет, админы на производственных предприятиях. Ребята неплохие, знающие и умеющие.

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

Сказать, что я чуть не упал со стула – это значит ничего не сказать. И сразу пояснил их, что спросили они меня не об этом, точнее спрашивать надо было почему я сервис закрыл.

Ну парни оказались упорными и пришлось разложить все по полочкам. Начнем с ремонта. Кого и где они собрались ремонтировать? Сегодня розничный рынок продажи ПК поделен парой-тройкой крупных игроков и все вопросы покупатели будут решать с ними.

К ним пойдут владельцы старых ПК с истекшей гарантией и покупатели всякого китайского творчества с маркетплейсов.

Далее – ремонтопригодность современного железа упала в разы. Чинить в большинстве своем нечего. Только менять, крупными узлами, что по цене абсолютно невыгодно, проще немного добавить и купить новый.

А для китайцев проблемой может стать даже поиск и приобретение запчастей. Что будет долго, дорого и не факт, что подойдет. Это если найдете.

Поэтому весь «ремонт» будет сводиться к замене дисков, памяти и блока питания, а на этом кассу не сделаешь.

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

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

И это очень и очень тонкий лед. Практически каждый день поднимаешь с пола статью. За очень смешные деньги, потому как на этой стезе массово поджимают студенты, которые прибегут на дом и сделают все и даже больше за условную миску супа.

Что дальше? Заправка картриджей? Все струйные принтеры практически поголовно перешли на СНПЧ, а налить чернила пользователь и сам может.

Лазерники? Прошли те времена, когда лазерный картридж можно было тупо заправить на коленке с отверткой и пылесосом. Сегодня, если вы хотите качественной печати, то нужно гораздо больше телодвижений и без заправочной станции уже не обойтись.

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

В общем тут надо или заниматься серьезно или не заниматься вообще. Тем более что прибыльность там тоже так себе. На маркетплейсах полно совместимых картриджей по цене пары заправок. А если человек печатает дома, то раз в год-полтора ему проще купить новый картридж, чем заправлять старый.

Торговля железом, апгрейды, китайские Xeon и все такое прочее? Тоже нет. Минули те времена, когда можно было в Москве купить железа по второй колонке прайса (мелкий опт), накрутить свои 6-10% и что-то с этого получить.

Сегодня у каждого есть интернет, там маркетплейсы и цены в них будут ниже вашей закупки. И товар они доставляют быстрее, и вернуть его проще.

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

А сервис я закрыл после того, как после выплаты всех зарплат, аренд и налогов забрал оттуда 11 000 рублей (в ценах 2011 года), хотя жизнь в нем кипела, клиенты были, работы хватало.

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

​​И снова про белок и колеса…

Этот поучительный случай произошел на неделе, но мы решили оставить его до выходных.

Позвонили нам из одной незнакомой нам организации и пожаловались, что от них ушел администратор и они буквально «осиротели».

Начинаем разбираться что почем. Фирма небольшая, десяток ПК, два принтера, сервер. Админ работал на полставки за 25 тыс. руб. Приходил на полдня, решал насущные проблемы, остальное время был удаленно или на телефоне.

А чего, спрашиваем, ушел?

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

Ну так договоритесь с ним, - предлагаю, - пусть он вам по удаленке помогает, тут на месте то делать, наверное, особо нечего.

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

И делать у нас всегда есть чего, у нас иногда компьютеры тормозят, иногда сеть барахлит, принтеры тоже бывает бумагу заедают. И вообще надо чтобы кто-то помогал нам, вот на той неделе у нас табличка пропала из общей папки.

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

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

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

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

Но мы задумались о другом, что сколько вокруг таких организаций, у которых в принципе все работает и им надо, чтобы просто кто-то приходил им «помогал».

Причем их достаточно много как в мелком бизнесе, так и в бюджетной сфере.

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

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

Год-два в таком темпе и можно будет не только забыть о развитии, а и начать терять уже имеющиеся навыки. При этом перспектив там и вдалеке не просматривается, потому что время от времени подвисающие компьютеры, глючная сеть и т.д. и т.п. представляются там чем-то нормальным.

А чего? Работает ведь? А если что – у нас есть мальчик, сейчас свистнем, прибежит, починит.

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

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

​​Как и зачем делить базы данных по отдельным установкам СУБД

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

Если брать конкретные цифры, то дать тут общие рекомендации сложно, нужно смотреть на сценарии применения, объемы данных, интенсивность и характер обращения к СУБД, в общем – требуется индивидуальный подход.

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

Описывая модель нами сознательно предельна упрощена и не требует каких-либо специфических знаний, а также применима к любым СУБД, а не только PostgreSQL.

Одной из задач СУБД – является быстрое и эффективное предоставление прикладному ПО доступа к хранящихся в базе данных. А получить мы их можем одним единственным образом – прочитать с диска.

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

Именно этим объясняется известное всем стремление SQL-серверов занять всю доступную память. В простейших случаях, когда база по размеру гораздо меньше, чем размер оперативной памяти, то она будет закеширована практически вся.

Если же суммарный размер данных больше размера доступной памяти, то данные в кеше будут иметь приоритет по количеству обращений к ним. Таким образом более горячие данные будут вытеснять более холодные.

При достаточном количестве памяти через некоторое время будет достигнут некоторый баланс и все горячие данные будут в кеше. Иначе одни будут постоянно вытеснять другие и СУБД будет вынуждена постоянно прибегать к дисковому чтению.

Хотя это не всегда плохо, с появлением быстрых дисков, таких как NVMe, иногда более оптимально будет читать данные с диска, нежели тратить на их хранение достаточно ограниченный ресурс оперативной памяти.
А теперь про то, зачем делить базы по разным экземплярах СУБД. Представим, что у нас есть некоторый единый сервер, где находятся базы торгового подразделения и бухгалтерии.

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

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

Объем потребляемых ею данных резко вырастет, и они просто вытеснят из кеша данные торгового отдела. И чем активнее будет работать бухгалтерия, тем хуже будет торговле.

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

Также возможен обратный сценарий, когда торговля активно подбивает итоги и тормозит уже бухгалтерия.

Какой выход? В лоб – добавить память. Но опять-таки мы не можем гарантировать, что кто-то не перетянет на себя все одеяло, разве что памяти с запасом хватит на всех. Но это не про современные объемы данных.

Поэтому просто делим один экземпляр СУБД на два и каждому выделяем свое количество памяти. Да, в итоге каждый получит меньше, чем мог бы откусить из общей кучи и может начать работать немного медленнее.

Но это будет гарантированная производительность, особенно после того, как вы определите достаточный объем памяти для хранения всего горячего кеша. Соседи могут делать все, что угодно. Равно как и вы.

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

При этом накладные расходы на дублирование экземпляров СУБД минимальные, особенно если мы используем контейнеры.

Подборка про самосбор

Самосбор – тема вечно живая, полемическая, с множеством за и против. Мы тоже немало писали на эту тему, поэтому решили собрать все в одном месте:

🔹 Гарантия по другую сторону баррикад, часть 3, самосбор (https://t.me/interface31/1366)

🔹 Самосбор, почему это не самая лучшая идея (https://t.me/interface31/1441)

🔹 И снова о вреде самосбора (https://t.me/interface31/2062)

🔹 И снова про самосбор серверов (https://t.me/interface31/2137)

🔹 Про сборку (https://t.me/interface31/4774)

🔹 Неочевидные опасности самосбора для опытных (https://t.me/interface31/4776)

👆 А если коротко и по делу, то наше мнение такое: если сборка ПК для вас не является хобби (или работой), и вы не готовы к дополнительным финансовым и/или временным затратам – то оставьте процесс сборки тому, кто получает за это деньги.

Особенно если вам нужен компьютер, который нужно просто включить и работать, а приключения – это то, что нужно вам в последнюю очередь.