Устанавливаем ТС ПИоТ для работы с 1С:Предприятие и ККТ АТОЛ
ТС ПИоТ — это техническое средство получения информации о товаре, программный модуль, использование которого станет обязательным с 1 июля 2026 года. ПО достаточно сложное, требующее интеграции со многими компонентами кассы.
В данной статье мы пошагово разберем его установку и интеграцию с кассовым ПО на базе 1С:Предприятие для работы совместно с ККТ АТОЛ.
Перед тем, как приступать к установке и настройке убедитесь, что у вас:
▫️Установлен .NET 4.8
▫️ККТ имеет прошивку не ниже 5.17
▫️1С обновлена до релиза, поддерживающего ТС ПИоТ
▫️Приобретена лицензия ЕСМ на используемую ККТ
Последний момент достаточно важен: лицензия ЕСМ привязывается к заводскому номеру ККТ и без активной лицензии работает 7 дней в демо-режиме, однако вернуть кассу к работе "по-старому" будет достаточно непросто.
✅ Читать далее: https://interface31.ru/post/ts-piot-dlya--1с-predpriyatie-kkt-atol/
ТС ПИоТ — это техническое средство получения информации о товаре, программный модуль, использование которого станет обязательным с 1 июля 2026 года. ПО достаточно сложное, требующее интеграции со многими компонентами кассы.
В данной статье мы пошагово разберем его установку и интеграцию с кассовым ПО на базе 1С:Предприятие для работы совместно с ККТ АТОЛ.
Перед тем, как приступать к установке и настройке убедитесь, что у вас:
▫️Установлен .NET 4.8
▫️ККТ имеет прошивку не ниже 5.17
▫️1С обновлена до релиза, поддерживающего ТС ПИоТ
▫️Приобретена лицензия ЕСМ на используемую ККТ
Последний момент достаточно важен: лицензия ЕСМ привязывается к заводскому номеру ККТ и без активной лицензии работает 7 дней в демо-режиме, однако вернуть кассу к работе "по-старому" будет достаточно непросто.
✅ Читать далее: https://interface31.ru/post/ts-piot-dlya--1с-predpriyatie-kkt-atol/
👍21🤝3❤2🤮1
Файловая информационная база 1С:Предприятие
Обсуждение показало, что многие коллеги имеют превратное представление о файловой информационной базе 1С, считая ее пережитком прошлого и вообще сосредоточением всех возможных недостатков платформы.
Однако это далеко не так, и в данной заметке мы расскажем почему.
Что собой представляет файловая база? Это собственный формат базы данных от 1С, который всю необходимую информацию хранит в одном единственном файле 1Cv8.1CD, кроме него в папке с базой находятся вспомогательные файлы, но никакой ценности они не несут, все нужное сосредоточено в единственном файле.
Файл имеет страничную структуру и может содержать 2^32-1 страницу размером 4 КБ, что ограничивает общий объем файла базы размеров в 16 ТБ. При этом, в силу внутреннего устройства действует дополнительное ограничение в размере 4 ГБ на размер внутренней таблицы файла.
Начиная с версии 8.3.8 можно менять размер страницы с 4 КБ до 64 КБ, что позволяет увеличить лимит размера внутренней таблицы до 6 ГБ.
Что касается скорости работы, то при прочих равных файловая база всегда работает быстрее клиент-серверной, быстрее в несколько раз. В этом может легко убедиться каждый при помощи теста Гилева. В результате нашего экспресс-теста была получена трехкратная разница.
Как это можно использовать? Если у вас есть тяжелые задачи, требующие преимущественно однопоточного, монопольного доступа, то вы можете радикально их ускорить, выгрузив клиент-серверную базу в файловую, выполнив необходимые операции и загрузив обратно.
А еще вы можете перенести такую базу с сервера на пользовательский ПК с более высокой производительностью на ядро и еще более ускорив выполнение нужных операций.
Поэтому, если вы используете базу единолично, то файловый режим – это то, что доктор прописал. И именно в файловый режим мы всегда выгружаем тестовые базы и базы для разработки, несмотря на наличие севера. Потому что быстрее, сильно быстрее.
Но есть и иная сторона медали, общий доступ к файловой базе осуществляется путем разделения доступа к файлу базы и первое с чем вы столкнетесь – это блокировки. При совместной работе производительность файлового варианта резко падает, поэтому общие рекомендации – это не более 3-5 пользователей.
Второе ограничение – это размер базы, по мере роста которой работа в многопользовательском файловом режиме будет все менее комфортной. Это связано с тем, что по сети приходится гонять большой объем данных, что упирается в производительность дисковой и сетевой подсистем.
В эпоху жестких дисков таким порогом был размер примерно в 4 ГБ, в эпоху SSD более-менее комфортно жить в файловой можно до 10-12 ГБ.
Но здесь есть еще один «чит» - публикация на веб-сервере. В таком режиме работы модуль расширения веб-сервера выполняет серверный код, а тонкий клиент или браузер – клиентскую часть кода.
При этом есть одна тонкость, модуль расширения веб-сервера в файловом режиме однопоточен. Т.е. все запросы клиентов ставятся в единую очередь. При этом вопрос блокировок отпадает сам собой.
Но очередь – скажете вы. И что, что очередь? Еще раз смотрим на разницу в производительности и понимаем, что до определенного предела производительность файлового режима через веб-сервер позволяет вообще не задумываться об этом моменте. Если очередь обслуживается быстро, то не все равно сколько вас там в этой очереди?
Поэтому сегодня даже в одной сети есть смысл использовать файловую базу сугубо через веб-сервер. Это позволяет закрыть потребности 5-10 и даже 15 пользователей простым пользовательским железом, в этом плане вне конкуренции процессоры AMD Ryzen 5/7/9.
Стимулами для перехода на клиент-серверные версии становится рост количества пользователей, когда однопоточный модуль не успевает обрабатывать очередь, рост объема базы, а также необходимость выполнения регламентных заданий и обменов в автоматическом режиме, без активных сеансов пользователя.
Но это уже совсем другой уровень бизнеса и инфраструктуры, да и вообще совсем другая история.
Обсуждение показало, что многие коллеги имеют превратное представление о файловой информационной базе 1С, считая ее пережитком прошлого и вообще сосредоточением всех возможных недостатков платформы.
Однако это далеко не так, и в данной заметке мы расскажем почему.
Что собой представляет файловая база? Это собственный формат базы данных от 1С, который всю необходимую информацию хранит в одном единственном файле 1Cv8.1CD, кроме него в папке с базой находятся вспомогательные файлы, но никакой ценности они не несут, все нужное сосредоточено в единственном файле.
Файл имеет страничную структуру и может содержать 2^32-1 страницу размером 4 КБ, что ограничивает общий объем файла базы размеров в 16 ТБ. При этом, в силу внутреннего устройства действует дополнительное ограничение в размере 4 ГБ на размер внутренней таблицы файла.
Начиная с версии 8.3.8 можно менять размер страницы с 4 КБ до 64 КБ, что позволяет увеличить лимит размера внутренней таблицы до 6 ГБ.
Что касается скорости работы, то при прочих равных файловая база всегда работает быстрее клиент-серверной, быстрее в несколько раз. В этом может легко убедиться каждый при помощи теста Гилева. В результате нашего экспресс-теста была получена трехкратная разница.
Как это можно использовать? Если у вас есть тяжелые задачи, требующие преимущественно однопоточного, монопольного доступа, то вы можете радикально их ускорить, выгрузив клиент-серверную базу в файловую, выполнив необходимые операции и загрузив обратно.
А еще вы можете перенести такую базу с сервера на пользовательский ПК с более высокой производительностью на ядро и еще более ускорив выполнение нужных операций.
Поэтому, если вы используете базу единолично, то файловый режим – это то, что доктор прописал. И именно в файловый режим мы всегда выгружаем тестовые базы и базы для разработки, несмотря на наличие севера. Потому что быстрее, сильно быстрее.
Но есть и иная сторона медали, общий доступ к файловой базе осуществляется путем разделения доступа к файлу базы и первое с чем вы столкнетесь – это блокировки. При совместной работе производительность файлового варианта резко падает, поэтому общие рекомендации – это не более 3-5 пользователей.
Второе ограничение – это размер базы, по мере роста которой работа в многопользовательском файловом режиме будет все менее комфортной. Это связано с тем, что по сети приходится гонять большой объем данных, что упирается в производительность дисковой и сетевой подсистем.
В эпоху жестких дисков таким порогом был размер примерно в 4 ГБ, в эпоху SSD более-менее комфортно жить в файловой можно до 10-12 ГБ.
Но здесь есть еще один «чит» - публикация на веб-сервере. В таком режиме работы модуль расширения веб-сервера выполняет серверный код, а тонкий клиент или браузер – клиентскую часть кода.
При этом есть одна тонкость, модуль расширения веб-сервера в файловом режиме однопоточен. Т.е. все запросы клиентов ставятся в единую очередь. При этом вопрос блокировок отпадает сам собой.
Но очередь – скажете вы. И что, что очередь? Еще раз смотрим на разницу в производительности и понимаем, что до определенного предела производительность файлового режима через веб-сервер позволяет вообще не задумываться об этом моменте. Если очередь обслуживается быстро, то не все равно сколько вас там в этой очереди?
Поэтому сегодня даже в одной сети есть смысл использовать файловую базу сугубо через веб-сервер. Это позволяет закрыть потребности 5-10 и даже 15 пользователей простым пользовательским железом, в этом плане вне конкуренции процессоры AMD Ryzen 5/7/9.
Стимулами для перехода на клиент-серверные версии становится рост количества пользователей, когда однопоточный модуль не успевает обрабатывать очередь, рост объема базы, а также необходимость выполнения регламентных заданий и обменов в автоматическом режиме, без активных сеансов пользователя.
Но это уже совсем другой уровень бизнеса и инфраструктуры, да и вообще совсем другая история.
👍26🤮4❤3
Особенности использования HASP-ключей для лицензий 1С
В комментариях часто вспоминают аппаратные ключи HASP, к которым также можно привязывать программные лицензии. Но использование аппаратных ключей имеет свои особенности.
Начнем с плюсов: лицензия на HASP не привязана к оборудованию и может использоваться по сети как однопользовательская (т.е. без ограничений количества сеансов).
👉 На этом плюсы закончились, дальше идут особенности и подводные камни.
Если ПК теряет связь с менеджером лицензий HASP License Manager, а сервер или компонента веб-сервера продолжают видеть ключ, то они начнут раздавать те же лицензии как многопользовательские, т.е. по одной на сеанс.
Нужно ли говорить, что в таком режиме лицензии могут совершенно неожиданно закончиться.
Привязанный к HASP ключ программной лицензии требует наличия на ключе HASP хотя бы одной свободной лицензии для проверки ключа. В противном случае проверка не будет пройдена и ключ будет считаться на обнаруженным.
При наличии нескольких ключей одной серии их нужно разместить на разных ПК.
Но это еще не все, без дополнительной настройки оба менеджера будут работать с одинаковыми именами и если клиент первым найдет менеджер ключа, на котором нет свободной лицензии, то он не будет искать второй ключ, он сообщит что нет свободных лицензий или получит многопользовательскую лицензию с сервера или веб-сервера.
И наконец, аппаратный ключ не виден в терминальной сессии, поэтому если вы используете терминальный сервер, то ключ придется разместить на другом узле сети и использовать как сетевой.
Кроме того, аппаратный ключ можно сломать, потерять, он может выйти из строя. При этом, в отличии от программной лицензии, он не будет восстановлен пока вы не предоставите фирме 1С сам ключ или то, что от него осталось и они смогут убедиться что это именно тот ключ.
В комментариях часто вспоминают аппаратные ключи HASP, к которым также можно привязывать программные лицензии. Но использование аппаратных ключей имеет свои особенности.
Начнем с плюсов: лицензия на HASP не привязана к оборудованию и может использоваться по сети как однопользовательская (т.е. без ограничений количества сеансов).
👉 На этом плюсы закончились, дальше идут особенности и подводные камни.
Если ПК теряет связь с менеджером лицензий HASP License Manager, а сервер или компонента веб-сервера продолжают видеть ключ, то они начнут раздавать те же лицензии как многопользовательские, т.е. по одной на сеанс.
Нужно ли говорить, что в таком режиме лицензии могут совершенно неожиданно закончиться.
Привязанный к HASP ключ программной лицензии требует наличия на ключе HASP хотя бы одной свободной лицензии для проверки ключа. В противном случае проверка не будет пройдена и ключ будет считаться на обнаруженным.
При наличии нескольких ключей одной серии их нужно разместить на разных ПК.
Но это еще не все, без дополнительной настройки оба менеджера будут работать с одинаковыми именами и если клиент первым найдет менеджер ключа, на котором нет свободной лицензии, то он не будет искать второй ключ, он сообщит что нет свободных лицензий или получит многопользовательскую лицензию с сервера или веб-сервера.
И наконец, аппаратный ключ не виден в терминальной сессии, поэтому если вы используете терминальный сервер, то ключ придется разместить на другом узле сети и использовать как сетевой.
Кроме того, аппаратный ключ можно сломать, потерять, он может выйти из строя. При этом, в отличии от программной лицензии, он не будет восстановлен пока вы не предоставите фирме 1С сам ключ или то, что от него осталось и они смогут убедиться что это именно тот ключ.
👍13❤1🤔1
Особенности использования аппаратных ключей HASP для 1С:Предприятие
Несмотря на то, что ключи HASP более недоступны для покупки у пользователей системы 1С:Предприятие осталось на руках еще достаточно ключей, поэтому информация о их применении остается актуальной.
Бытует мнение, что аппаратные ключи проще и удобнее программных лицензий, однако это не так, у них есть свои особенности и ограничения. Далее мы будем говорить о многопользовательских ключах серии ORGL8, которые поставлялись в вариантах на 5, 10, 20, 50 и 100 лицензий.
Также еще есть ключи серий ORG8A и ORG8B на 300 и 500 лицензий.
Начнем с того, что несколько ключей одной серии не могут быть размещены вместе на одном узле и поэтому вам придется разносить их по разным ПК.
Дальнейшее поведение зависит от того, кто и как получает лицензию с этого ключа. Клиентское приложение при запуске в первую очередь ищет в сети службу HASP License Manager и пытается получить лицензию с ее помощью.
В этом случае ему выдается однопользовательская лицензия и он может запустить неограниченное количество сеансов информационных баз.
При использовании в сети нескольких ключей их желательно явно прописать в nethasp.ini примерно следующим образом:
Если службы HASP LM не найдены или обслуживаемый ими ключ не содержит свободных лицензий, то клиент попытается получить лицензии с сервера или веб-сервера, которые выдают их на сеанс.
Эта особенность часто приводит к сильному перерасходу лицензий в случае возникновения каких-либо сетевых проблем, когда клиенты перестают видеть службу HASP LM, а сервер продолжает иметь к ней доступ, либо ключ установлен на нем локально.
И самое интересное, это взаимодействие с сетевыми ключами сервера или веб-сервера 1С:Предприятие.
В первую очередь сервер ищет локальный ключ и начинает выдавать лицензии из него. По их исчерпании он начинает поиск сетевых ключей, работающих через HASP LM.
Но если в сети находятся несколько ключей, то сервер случайным образом выбирает один из них, дальнейший поиск ключей одной серии не производится.
Таким образом если лицензии на выбранном сетевом ключе будут исчерпаны сервер прекратит выдачу лицензий несмотря на то, что в сети есть еще ключи со свободными лицензиями.
Вместо этого сервер будет производить поиск ключей серий ORG8A и ORG8B, также по одному ключу каждого типа.
Все эти особенности делают использование аппаратных ключей не такой уж простой задачей и заставляют ответственно подходить к планированию инфраструктуры с их использованием.
Несмотря на то, что ключи HASP более недоступны для покупки у пользователей системы 1С:Предприятие осталось на руках еще достаточно ключей, поэтому информация о их применении остается актуальной.
Бытует мнение, что аппаратные ключи проще и удобнее программных лицензий, однако это не так, у них есть свои особенности и ограничения. Далее мы будем говорить о многопользовательских ключах серии ORGL8, которые поставлялись в вариантах на 5, 10, 20, 50 и 100 лицензий.
Также еще есть ключи серий ORG8A и ORG8B на 300 и 500 лицензий.
Начнем с того, что несколько ключей одной серии не могут быть размещены вместе на одном узле и поэтому вам придется разносить их по разным ПК.
Дальнейшее поведение зависит от того, кто и как получает лицензию с этого ключа. Клиентское приложение при запуске в первую очередь ищет в сети службу HASP License Manager и пытается получить лицензию с ее помощью.
В этом случае ему выдается однопользовательская лицензия и он может запустить неограниченное количество сеансов информационных баз.
При использовании в сети нескольких ключей их желательно явно прописать в nethasp.ini примерно следующим образом:
[NH_TCPIP]
NH_SERVER_ADDR = 192.168.111.10, 192.168.111.11
NH_SERVER_NAME = HASP_LM1, HASP_LM2
Если службы HASP LM не найдены или обслуживаемый ими ключ не содержит свободных лицензий, то клиент попытается получить лицензии с сервера или веб-сервера, которые выдают их на сеанс.
Эта особенность часто приводит к сильному перерасходу лицензий в случае возникновения каких-либо сетевых проблем, когда клиенты перестают видеть службу HASP LM, а сервер продолжает иметь к ней доступ, либо ключ установлен на нем локально.
И самое интересное, это взаимодействие с сетевыми ключами сервера или веб-сервера 1С:Предприятие.
В первую очередь сервер ищет локальный ключ и начинает выдавать лицензии из него. По их исчерпании он начинает поиск сетевых ключей, работающих через HASP LM.
Но если в сети находятся несколько ключей, то сервер случайным образом выбирает один из них, дальнейший поиск ключей одной серии не производится.
Таким образом если лицензии на выбранном сетевом ключе будут исчерпаны сервер прекратит выдачу лицензий несмотря на то, что в сети есть еще ключи со свободными лицензиями.
Вместо этого сервер будет производить поиск ключей серий ORG8A и ORG8B, также по одному ключу каждого типа.
Все эти особенности делают использование аппаратных ключей не такой уж простой задачей и заставляют ответственно подходить к планированию инфраструктуры с их использованием.
👍14⚡3🤝2❤1🍌1
Порядок получения лицензий 1С:Предприятия клиентским приложением
Все виды клиентов 1С:Предприятия (кроме веб-клиента) осуществляют поиск лицензии в следующей последовательности:
▫️ Если ранее лицензия была успешно получена, то выполняется попытка получения лицензии из того же файла программной лицензии или HASP ключа что и при последнем подключении
▫️ При первом подключении или в том случае если на предыдущем этапе лицензия не была найдена выполняется поиск локальных программных лицензий
▫️ Поиск локального ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Поиск базовой лицензии на локальном компьютере
❗️ Если лицензия не была найдена, то клиент обращается за лицензией на сервер (веб-сервер), поиск выполняет менеджер кластера, на который назначен сервис сеансовых данных в следующем порядке:
▫️ Программная лицензия или ключ защиты HASP откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной лицензии
▫️ Поиск локального клиентского ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Программная лицензия на сервере лицензирования откуда была получена лицензия при последнем удачном запуске
▫️ Поиск программной лицензии на сервере лицензирования
☝️ При этом выдача лицензии сервером имеет свои особенности:
▫️ Лицензия выдается на каждый сеанс, т.е. один клиент может занять несколько лицензий
▫️ Сервер может подключиться только к одному локальному и одному сетевому ключу одной серии
Как видим, алгоритм достаточно сложный и поиск ключей выполняется во многих местах, поэтому для ускорения запуска клиента 1С, если вы не используете аппаратные ключи, следует использовать параметр
Все виды клиентов 1С:Предприятия (кроме веб-клиента) осуществляют поиск лицензии в следующей последовательности:
▫️ Если ранее лицензия была успешно получена, то выполняется попытка получения лицензии из того же файла программной лицензии или HASP ключа что и при последнем подключении
▫️ При первом подключении или в том случае если на предыдущем этапе лицензия не была найдена выполняется поиск локальных программных лицензий
▫️ Поиск локального ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Поиск базовой лицензии на локальном компьютере
❗️ Если лицензия не была найдена, то клиент обращается за лицензией на сервер (веб-сервер), поиск выполняет менеджер кластера, на который назначен сервис сеансовых данных в следующем порядке:
▫️ Программная лицензия или ключ защиты HASP откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной лицензии
▫️ Поиск локального клиентского ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Программная лицензия на сервере лицензирования откуда была получена лицензия при последнем удачном запуске
▫️ Поиск программной лицензии на сервере лицензирования
☝️ При этом выдача лицензии сервером имеет свои особенности:
▫️ Лицензия выдается на каждый сеанс, т.е. один клиент может занять несколько лицензий
▫️ Сервер может подключиться только к одному локальному и одному сетевому ключу одной серии
Как видим, алгоритм достаточно сложный и поиск ключей выполняется во многих местах, поэтому для ускорения запуска клиента 1С, если вы не используете аппаратные ключи, следует использовать параметр
UseHwLicenses=0 в конфигурационном файле 1cestart.cfg, который отключит поиск лицензий на аппаратных ключах.👍17🤝2❤1
Порядок получения лицензий 1С:Предприятия веб-клиентом
Веб-клиент – особый тип клиентского приложения, предназначенный для работы через браузер. Это один из самых специфичных и ограниченных в возможностях клиентов и поэтому работу через него надо избегать.
Однако в ряде случаев особых альтернатив ему нет, например, для техники Apple или планшетов Andriod.
Получение лицензий таким клиентом имеет свои особенности и зависит от режима работы.
Для файловой базы поиск производится на компьютере, где установлен модуль расширения веб-сервера, все лицензии выдаются только в многопользовательском режиме (на сеанс):
▫️ Получение лицензии из файла программной лицензии или HASP ключа откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной файловой лицензии
▫️ Поиск локального ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
Для клиент-серверных баз локальный поиск ключа на компьютере с установленным модулем расширения веб-сервера не производится, лицензия сразу запрашивается с сервера. Поиск лицензии выполняет менеджер кластера, на который назначен сервис сеансовых данных в следующем порядке:
▫️ Программная лицензия или ключ защиты HASP откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной лицензии
▫️ Поиск локального клиентского ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Программная лицензия на сервере лицензирования откуда была получена лицензия при последнем удачном запуске
▫️ Поиск программной лицензии на сервере лицензирования
При этом, если вы используете веб-клиент для подключения к файловым и клиент-серверным базам одновременно вам будет необходимо держать два комплекта лицензий на веб-сервере и сервере 1С Предприятие в количестве достаточном для запуска нужного числа сеансов.
Веб-клиент – особый тип клиентского приложения, предназначенный для работы через браузер. Это один из самых специфичных и ограниченных в возможностях клиентов и поэтому работу через него надо избегать.
Однако в ряде случаев особых альтернатив ему нет, например, для техники Apple или планшетов Andriod.
Получение лицензий таким клиентом имеет свои особенности и зависит от режима работы.
Для файловой базы поиск производится на компьютере, где установлен модуль расширения веб-сервера, все лицензии выдаются только в многопользовательском режиме (на сеанс):
▫️ Получение лицензии из файла программной лицензии или HASP ключа откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной файловой лицензии
▫️ Поиск локального ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
Для клиент-серверных баз локальный поиск ключа на компьютере с установленным модулем расширения веб-сервера не производится, лицензия сразу запрашивается с сервера. Поиск лицензии выполняет менеджер кластера, на который назначен сервис сеансовых данных в следующем порядке:
▫️ Программная лицензия или ключ защиты HASP откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной лицензии
▫️ Поиск локального клиентского ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Программная лицензия на сервере лицензирования откуда была получена лицензия при последнем удачном запуске
▫️ Поиск программной лицензии на сервере лицензирования
При этом, если вы используете веб-клиент для подключения к файловым и клиент-серверным базам одновременно вам будет необходимо держать два комплекта лицензий на веб-сервере и сервере 1С Предприятие в количестве достаточном для запуска нужного числа сеансов.
🤝8❤3👍3🤮1
Установка и настройка сервера лицензирования 1С:Предприятие
Управление лицензиями 1С:Предприятия - задача не простая, особенно если у вас в эксплуатации несколько серверов или используется виртуализация. Основные проблемы - это оптимизация распределения лицензий и привязка лицензий к параметрам оборудования, что создает трудности в виртуальной среде.
Облегчить работу и централизовать управление лицензиями вам поможет выделенный сервер лицензирования, как его установить и настроить мы расскажем в этой статье.
Начнем с того, что в официальной документации 1С:Предприятия вы не найдете термина Сервер лицензирования, есть понятие сервиса лицензирования, который может быть назначен любому рабочему серверу кластера серверов 1С:Предприятие.
Но существуют некоторые особенности его использования, самая важная из которых заключается в том, что рабочий сервер не имеющих других назначенных сервисов, кроме сервиса лицензирования не требует отдельной серверной лицензии.
Это позволяет выделить для сервиса лицензирования отдельный компьютер или виртуальную машину с постоянными характеристиками оборудования и с его помощью централизованно управлять лицензиями. Неофициально такая система получила название сервера лицензирования, что точно отражает выполняемую роль, но является несколько некорректным с точки зрения официальной терминологии.
✅ Читать далее: https://interface31.ru/post/ustanovka-i-nastroyka-servera-licenzirovaniya-1spredpriyatie/
Управление лицензиями 1С:Предприятия - задача не простая, особенно если у вас в эксплуатации несколько серверов или используется виртуализация. Основные проблемы - это оптимизация распределения лицензий и привязка лицензий к параметрам оборудования, что создает трудности в виртуальной среде.
Облегчить работу и централизовать управление лицензиями вам поможет выделенный сервер лицензирования, как его установить и настроить мы расскажем в этой статье.
Начнем с того, что в официальной документации 1С:Предприятия вы не найдете термина Сервер лицензирования, есть понятие сервиса лицензирования, который может быть назначен любому рабочему серверу кластера серверов 1С:Предприятие.
Но существуют некоторые особенности его использования, самая важная из которых заключается в том, что рабочий сервер не имеющих других назначенных сервисов, кроме сервиса лицензирования не требует отдельной серверной лицензии.
Это позволяет выделить для сервиса лицензирования отдельный компьютер или виртуальную машину с постоянными характеристиками оборудования и с его помощью централизованно управлять лицензиями. Неофициально такая система получила название сервера лицензирования, что точно отражает выполняемую роль, но является несколько некорректным с точки зрения официальной терминологии.
✅ Читать далее: https://interface31.ru/post/ustanovka-i-nastroyka-servera-licenzirovaniya-1spredpriyatie/
👍8🤮2🤣1👀1
Как узнать температуру процессора и накопителей
Пришло лето, а вместе с ним и жаркие деньки, но в это время администраторы думают вовсе не о пляже, а о температурном режиме обслуживаемого оборудования. Перегрев может негативно сказываться как на производительности, так и на сроке службы устройств.
Как понять, требуется ли дополнительное охлаждение основным компонентам вашего компьютера или сервера если вы работаете под управлением Linux?
Очень просто и сегодня мы расскажем о простых и надежных утилитах, позволяющих получить информацию о состоянии оборудования даже если вам доступна только командная строка.
✅ Читать далее: https://interface31.ru/post/linux-nachinayushhim-kak-uznat-temperaturu-processora-i-diska/
Пришло лето, а вместе с ним и жаркие деньки, но в это время администраторы думают вовсе не о пляже, а о температурном режиме обслуживаемого оборудования. Перегрев может негативно сказываться как на производительности, так и на сроке службы устройств.
Как понять, требуется ли дополнительное охлаждение основным компонентам вашего компьютера или сервера если вы работаете под управлением Linux?
Очень просто и сегодня мы расскажем о простых и надежных утилитах, позволяющих получить информацию о состоянии оборудования даже если вам доступна только командная строка.
✅ Читать далее: https://interface31.ru/post/linux-nachinayushhim-kak-uznat-temperaturu-processora-i-diska/
👍20❤1
Как получить информацию об оборудовании ПК в Linux
Как получить информацию об оборудовании, установленном в вашем ПК или сервере? Можно просто открыть крышку корпуса и посмотреть. Но это не всегда возможно, да и не нужно, ведь есть столько разных утилит, которые быстро выдадут вам всю необходимую информацию с нужной степенью детализации.
Но все меняется если перед нами Linux и из интерфейсов доступна только командная строка, есть от чего растеряться. Но не стоит впадать в уныние, нужная информация всего лишь в нескольких командах от вас и сегодня мы о них расскажем.
Сразу уточним постановку задачи - нас не интересуют напряжения, температуры и прочие режимы работы оборудования, сегодня нам нужно максимально подробно узнать какое именно оборудование установлено в компьютере, например, модель материнской платы, процессора, планок памяти. Это часто бывает нужно при апгрейдах, покупке запасных частей, инвентаризациях оборудования.
✅ Читать далее: https://interface31.ru/post/linux-nachinayushhim-kak-poluchit-informaciyu-ob-oborudovanii-pk/
Как получить информацию об оборудовании, установленном в вашем ПК или сервере? Можно просто открыть крышку корпуса и посмотреть. Но это не всегда возможно, да и не нужно, ведь есть столько разных утилит, которые быстро выдадут вам всю необходимую информацию с нужной степенью детализации.
Но все меняется если перед нами Linux и из интерфейсов доступна только командная строка, есть от чего растеряться. Но не стоит впадать в уныние, нужная информация всего лишь в нескольких командах от вас и сегодня мы о них расскажем.
Сразу уточним постановку задачи - нас не интересуют напряжения, температуры и прочие режимы работы оборудования, сегодня нам нужно максимально подробно узнать какое именно оборудование установлено в компьютере, например, модель материнской платы, процессора, планок памяти. Это часто бывает нужно при апгрейдах, покупке запасных частей, инвентаризациях оборудования.
✅ Читать далее: https://interface31.ru/post/linux-nachinayushhim-kak-poluchit-informaciyu-ob-oborudovanii-pk/
👍16🤡2❤1
Где мое бесплатное пиво?
В обсуждениях время от времени всплывает тема коммерческих Linux дистрибутивов, мол какие нехорошие люди, взяли за бесплатно, закрыли и продают. Поэтому решили в очередной раз коснуться этого вопроса.
Прежде всего коснемся используемой терминологии. Мы часто употребляем термины открытое и свободное ПО как синонимы, но они ими не являются, это разные понятия.
Свободное ПО – это прежде всего философия, которая предусматривает наличие у пользователя ряда свобод: свободу использования, свободу изучения, свободу изменения и свободу распространения.
Если лицензия ПО обеспечивает указанные свободы, то такое ПО считается свободным, а занимается всем этим Фонд свободного программного обеспечения (Free Software Foundation), именно он принимает решение какие именно лицензии считать свободными. Самая известная свободная лицензия – GPL.
Открытое ПО – это программное обеспечение с открытым исходным кодом, но оно не обязательно должно быть свободным или бесплатным. В качестве примера можно привести конфигурации 1С — это открытое ПО, но оно не является свободным и тем более бесплатным.
При этом свободное ПО должно быть открытым, это проистекает из свобод изучения и изменения. Но нигде ничего не сказано о том, что оно должно быть бесплатным.
Идем дальше, тут у нас возникает еще одно понятие – дистрибутив. Это набор бинарных пакетов, которые скомпилировал сборщик и которые представляют собой некую целостную систему, включая репозитории.
И вот тут возникает первое большое непонимание. Компоненты дистрибутива могут распространяться под разными открытыми и свободными лицензиями. Но сам дистрибутив представляет собой отдельный объект авторского права и его автор может установить собственные правила его использования.
Например, предусмотреть лицензионные отчисления за каждый используемый экземпляр. Или разрешить использование дистрибутива только стоя на голове. Все это будет отражено в лицензионном соглашении и если вы его приняли, то должны следовать указанным там нормам.
Но как же GPL или другие свободные лицензии? А никак, к дистрибутиву они не применимы, они действуют для его компонентов. Вам никто не запрещает свободно их использовать самих по себе, но если вы хотите запускать именно дистрибутив – то будьте добры следовать его лицензии.
Если вам что-то не нравится – исходные коды предоставлены, собирайте сами и используйте по собственному усмотрению. Тут никаких вопросов нет, но бинарные файлы дистрибутива и репозиториев никто не обязывает предоставлять свободно и бесплатно. Здесь автор в праве поставить свои условия.
Поэтому не следует путать отдельные программы со своими лицензиями и их совокупность – дистрибутив. Он является отдельным объектом авторского права и может иметь собственные условия использования. Единственный момент – они не должны нарушать лицензии используемых компонентов.
Именно поэтому Red Hat так и не может победить клоны, она может запретить использование бинарных пакетов без оплаты лицензии, ограничить доступ к репозиториям, ставить иные различные препоны, но она не может запретить легальному пользователю самостоятельно собрать исходный код и использовать то, что получилось по своему усмотрению.
Но это будет уже не RHEL, а совсем другая сборка, со своим автором и своими правилами использования.
И еще один тонкий момент, если дистрибутив содержит ПО под проприетарными лицензиями или лицензиями, не требующими обязательного раскрытия исходного кода, то собрать вы сможете только свободную часть. Да, там есть тонкости, особенно с вирусным действием GPL, но в целом предоставить код вам должны только к свободной части.
Поэтому, если вы законно приобрели коммерческий дистрибутив Linux, то это не значит, что вы можете свободно его распространять и использовать направо и налево. Это отдельный объект авторского права со своими условиями. Или вы их соблюдаете или отказываетесь от использования.
Ну или берете исходные коды и собираете свой.
В обсуждениях время от времени всплывает тема коммерческих Linux дистрибутивов, мол какие нехорошие люди, взяли за бесплатно, закрыли и продают. Поэтому решили в очередной раз коснуться этого вопроса.
Прежде всего коснемся используемой терминологии. Мы часто употребляем термины открытое и свободное ПО как синонимы, но они ими не являются, это разные понятия.
Свободное ПО – это прежде всего философия, которая предусматривает наличие у пользователя ряда свобод: свободу использования, свободу изучения, свободу изменения и свободу распространения.
Если лицензия ПО обеспечивает указанные свободы, то такое ПО считается свободным, а занимается всем этим Фонд свободного программного обеспечения (Free Software Foundation), именно он принимает решение какие именно лицензии считать свободными. Самая известная свободная лицензия – GPL.
Открытое ПО – это программное обеспечение с открытым исходным кодом, но оно не обязательно должно быть свободным или бесплатным. В качестве примера можно привести конфигурации 1С — это открытое ПО, но оно не является свободным и тем более бесплатным.
При этом свободное ПО должно быть открытым, это проистекает из свобод изучения и изменения. Но нигде ничего не сказано о том, что оно должно быть бесплатным.
Идем дальше, тут у нас возникает еще одно понятие – дистрибутив. Это набор бинарных пакетов, которые скомпилировал сборщик и которые представляют собой некую целостную систему, включая репозитории.
И вот тут возникает первое большое непонимание. Компоненты дистрибутива могут распространяться под разными открытыми и свободными лицензиями. Но сам дистрибутив представляет собой отдельный объект авторского права и его автор может установить собственные правила его использования.
Например, предусмотреть лицензионные отчисления за каждый используемый экземпляр. Или разрешить использование дистрибутива только стоя на голове. Все это будет отражено в лицензионном соглашении и если вы его приняли, то должны следовать указанным там нормам.
Но как же GPL или другие свободные лицензии? А никак, к дистрибутиву они не применимы, они действуют для его компонентов. Вам никто не запрещает свободно их использовать самих по себе, но если вы хотите запускать именно дистрибутив – то будьте добры следовать его лицензии.
Если вам что-то не нравится – исходные коды предоставлены, собирайте сами и используйте по собственному усмотрению. Тут никаких вопросов нет, но бинарные файлы дистрибутива и репозиториев никто не обязывает предоставлять свободно и бесплатно. Здесь автор в праве поставить свои условия.
Поэтому не следует путать отдельные программы со своими лицензиями и их совокупность – дистрибутив. Он является отдельным объектом авторского права и может иметь собственные условия использования. Единственный момент – они не должны нарушать лицензии используемых компонентов.
Именно поэтому Red Hat так и не может победить клоны, она может запретить использование бинарных пакетов без оплаты лицензии, ограничить доступ к репозиториям, ставить иные различные препоны, но она не может запретить легальному пользователю самостоятельно собрать исходный код и использовать то, что получилось по своему усмотрению.
Но это будет уже не RHEL, а совсем другая сборка, со своим автором и своими правилами использования.
И еще один тонкий момент, если дистрибутив содержит ПО под проприетарными лицензиями или лицензиями, не требующими обязательного раскрытия исходного кода, то собрать вы сможете только свободную часть. Да, там есть тонкости, особенно с вирусным действием GPL, но в целом предоставить код вам должны только к свободной части.
Поэтому, если вы законно приобрели коммерческий дистрибутив Linux, то это не значит, что вы можете свободно его распространять и использовать направо и налево. Это отдельный объект авторского права со своими условиями. Или вы их соблюдаете или отказываетесь от использования.
Ну или берете исходные коды и собираете свой.
🥱12👍6🤔2🤡2❤1
Сами, но не с усами
В комментариях часто встречаются коллеги старой закалки, которые с гордостью рассказывают о том, что сами собирают себе пакеты. Ну, собирают и собирают, какая нам от этого печаль? Но последние события в мире ПО заставили посмотреть на это под новым углом.
С массовым привлечением ИИ к разработке и анализу кода уязвимости начали находиться гораздо быстрее и также гораздо быстрее закрываться. Сегодня и дня не проходит, чтобы в сводке новостей не промелькнуло, что ИИ нашел очередную уязвимость.
А после того, как вы собрали собственный пакет, у вас тут же возникают обязанности по его поддержке. В былые времена это не было сильно затратным делом, ну собрал новую версию раз в полгода или когда нашли что-то серьезное.
Сейчас же правила игры сильно изменились. Обновления пекутся как горячие пирожки, а сидеть с незакрытой уязвимостью это риск не гипотетический, а практический. ИИ и эксплойт напишет, и пояснит как им пользоваться, так что доступно сие развлечение будет даже школьникам.
А чтобы не быть голословным, я посчитал обновления ПО на рабочих серверах, где вся нагрузка крутится в Docker. И это только за один месяц.
🔹Traefik – 5 обновлений - 05.06, 06.06, 11.06, 23.06, 24.06
🔹Angie – 3 обновления - 26.05, 16.06, 20.06
🔹Caddy – 5 обновлений - 04.06, 05.06, 10.06, 23.06, 25.06
🔹Redis – 4 обновления - 27.05, 29.05, 23.06, 24.06
🔹Postgres 17 – 3 обновления - 12.06, 13.06, 25.06
🔹Wordpress FPM – 3 обновления - 12.06, 16.06, 25.06
И, глядя на даты выхода, складывается понимание, что апгрейды эти были далеко не плановыми и явно не новые фишечки выкатывали, а старательно что-то латали, да перелатывали.
В таком темпе свои пакеты вам придется срочно пересобирать, да не по одному разу, практически только этим и занимаясь, плюс начать серьезно отслеживать новостные бюллетени на предмет выхода новых релизов у используемого софта.
На практике это делает поддержку собственной сборки очень дорогой и заморочной, либо вам придется настраивать автоматический конвейер, который будет сам пересобирать ПО на каждый коммит в репозитории, но это уже совсем другой уровень и другая история.
🧐 А что думаете по этому вопросу вы? Готовы включиться в эту гонку?
В комментариях часто встречаются коллеги старой закалки, которые с гордостью рассказывают о том, что сами собирают себе пакеты. Ну, собирают и собирают, какая нам от этого печаль? Но последние события в мире ПО заставили посмотреть на это под новым углом.
С массовым привлечением ИИ к разработке и анализу кода уязвимости начали находиться гораздо быстрее и также гораздо быстрее закрываться. Сегодня и дня не проходит, чтобы в сводке новостей не промелькнуло, что ИИ нашел очередную уязвимость.
А после того, как вы собрали собственный пакет, у вас тут же возникают обязанности по его поддержке. В былые времена это не было сильно затратным делом, ну собрал новую версию раз в полгода или когда нашли что-то серьезное.
Сейчас же правила игры сильно изменились. Обновления пекутся как горячие пирожки, а сидеть с незакрытой уязвимостью это риск не гипотетический, а практический. ИИ и эксплойт напишет, и пояснит как им пользоваться, так что доступно сие развлечение будет даже школьникам.
А чтобы не быть голословным, я посчитал обновления ПО на рабочих серверах, где вся нагрузка крутится в Docker. И это только за один месяц.
🔹Traefik – 5 обновлений - 05.06, 06.06, 11.06, 23.06, 24.06
🔹Angie – 3 обновления - 26.05, 16.06, 20.06
🔹Caddy – 5 обновлений - 04.06, 05.06, 10.06, 23.06, 25.06
🔹Redis – 4 обновления - 27.05, 29.05, 23.06, 24.06
🔹Postgres 17 – 3 обновления - 12.06, 13.06, 25.06
🔹Wordpress FPM – 3 обновления - 12.06, 16.06, 25.06
И, глядя на даты выхода, складывается понимание, что апгрейды эти были далеко не плановыми и явно не новые фишечки выкатывали, а старательно что-то латали, да перелатывали.
В таком темпе свои пакеты вам придется срочно пересобирать, да не по одному разу, практически только этим и занимаясь, плюс начать серьезно отслеживать новостные бюллетени на предмет выхода новых релизов у используемого софта.
На практике это делает поддержку собственной сборки очень дорогой и заморочной, либо вам придется настраивать автоматический конвейер, который будет сам пересобирать ПО на каждый коммит в репозитории, но это уже совсем другой уровень и другая история.
🧐 А что думаете по этому вопросу вы? Готовы включиться в эту гонку?
👍16👌3😱2
За героизм нам не платят
Сегодня, на фоне обсуждений в комментариях, хочется поговорить о производственном «героизме». А именно, когда мы начинаем выполнять задачу не в обычном рабочем режиме, а в состоянии аврала или близком к нему.
Данный героизм можно разделить на два типа: добровольный и вынужденный. Начнем с последнего. Вынужденный героизм – это всегда результат просчета, вашего или не только вашего.
Да, причиной возникновения подобной ситуации может послужить некий внешний фактор, но это только триггер, маленький камушек запускающий сход целой лавины. А истинные причины, в случае лавины, это накопление критической массы снега на склоне.
В нашей отрасли – это накопление критической массы ошибок, недоработок, халатного отношения и прочего, прочего, прочего.
По-хорошему, причиной авральной ситуации может быть только наступление форс-мажора, т.е. обстоятельств непреодолимой силы. Во всех остальных случаях ситуация может быть сложной, но контролируемой.
Что такое авральная ситуация? Это когда все бегают по потолку и ищут там пятый угол, а заодно мучительно думают кого бы назначить крайним.
Сложная, но контролируемая ситуация выглядит так: у нас утрачена рабочая копия сервера и локальное хранилище копий. Чтобы запустить основные функции надо получить 40 ГБ бекапов из внешнего хранилища, это займет примерно час. За это время переустановим сервер, потом еще час-полтора на запуск. Туда-сюда, через три -четыре часа взлетим.
В чем разница? В том, что в первом случае это чистый «героизм», мы превозмогаем, самозабвенно бьемся с обстоятельствами, пытаемся пропетлять между струями дождя и т.д. и т.п.
Во-втором – планомерная и слаженная работа в сложной ситуации, когда мы понимаем, что со всеми допущениями и закладками на прочие «сюрпризы» за три – четыре часа мы систему гарантированно поднимем.
А теперь подумаем, что могло стать причиной перерастания сложной ситуации в авральную? Не было внешнего хранилища? Было, но процесс копирования в него никто не контролировал? Контролировал, но не проверял сами копии?
Таких причин можно найти множество и именно их накопление провоцирует в критической ситуации уже упомянутую нами лавину.
Второй вид героизма – добровольный. Тут все проще и не так трагично. Просто мы вызываемся поработать во внерабочее время, в плотном графике, без необходимых ресурсов и т.д. и т.п.
Обычно это начинается так: нам нужно…
А вы вместо того, чтобы обоснованно пояснить, что тут у нас не хватает ресурсов: вычислительных, памяти, пропускной способности, технологического окна и т.д. и т.п. просто берете под козырек и говорите, что мол попробуем.
Начинается все это безобидно: давайте задержимся после работы, выйдем в ночь, пока сделаем так, а там докупим…
Заканчивается по-разному. Самый безобидный сценарий, это когда вам первый раз пожали руку, сказали спасибо и выдали премию, второй раз просто пожали руку, третий раз забыли про спасибо, а потом еще и посетовали, что что-то вы как-то плохо работали.
В результате подобный «героизм» входит в рутину и от вас его уже ожидают по умолчанию. Ну если нравится человеку работать по ночам без дополнительной оплаты…
Но это был безобидный сценарий. А ведь может все пойти не так, и ситуация превратится в авральную и неконтролируемую. После чего сразу переходим к пункту про вынужденный героизм.
Но тут есть нюансы, если причиной критического сбоя послужил внешний фактор, то им еще как-то можно прикрыться. А вот если вы размотали систему «на ровном месте», то это конкретное попадалово.
Потому что руководство доходчиво вам объяснит всю степень вашей неправоты: не контролировал, неверно оценивал риски, не приложил должных усилий и т.д. и т.п.
И оправдания, типа ну я же просил новый сервер, диски, память и т.п. не прокатят. Так как вам справедливо заметят, что если вы осознавали, то почему делали?
А если делали, то вам и отвечать. А что не выделили, так это вы не объяснили и не довели.
В общем – не надо так делать. Как говорил один мой первый руководитель, когда я проявлял ненужную инициативу – за героизм нам не платят.
Сегодня, на фоне обсуждений в комментариях, хочется поговорить о производственном «героизме». А именно, когда мы начинаем выполнять задачу не в обычном рабочем режиме, а в состоянии аврала или близком к нему.
Данный героизм можно разделить на два типа: добровольный и вынужденный. Начнем с последнего. Вынужденный героизм – это всегда результат просчета, вашего или не только вашего.
Да, причиной возникновения подобной ситуации может послужить некий внешний фактор, но это только триггер, маленький камушек запускающий сход целой лавины. А истинные причины, в случае лавины, это накопление критической массы снега на склоне.
В нашей отрасли – это накопление критической массы ошибок, недоработок, халатного отношения и прочего, прочего, прочего.
По-хорошему, причиной авральной ситуации может быть только наступление форс-мажора, т.е. обстоятельств непреодолимой силы. Во всех остальных случаях ситуация может быть сложной, но контролируемой.
Что такое авральная ситуация? Это когда все бегают по потолку и ищут там пятый угол, а заодно мучительно думают кого бы назначить крайним.
Сложная, но контролируемая ситуация выглядит так: у нас утрачена рабочая копия сервера и локальное хранилище копий. Чтобы запустить основные функции надо получить 40 ГБ бекапов из внешнего хранилища, это займет примерно час. За это время переустановим сервер, потом еще час-полтора на запуск. Туда-сюда, через три -четыре часа взлетим.
В чем разница? В том, что в первом случае это чистый «героизм», мы превозмогаем, самозабвенно бьемся с обстоятельствами, пытаемся пропетлять между струями дождя и т.д. и т.п.
Во-втором – планомерная и слаженная работа в сложной ситуации, когда мы понимаем, что со всеми допущениями и закладками на прочие «сюрпризы» за три – четыре часа мы систему гарантированно поднимем.
А теперь подумаем, что могло стать причиной перерастания сложной ситуации в авральную? Не было внешнего хранилища? Было, но процесс копирования в него никто не контролировал? Контролировал, но не проверял сами копии?
Таких причин можно найти множество и именно их накопление провоцирует в критической ситуации уже упомянутую нами лавину.
Второй вид героизма – добровольный. Тут все проще и не так трагично. Просто мы вызываемся поработать во внерабочее время, в плотном графике, без необходимых ресурсов и т.д. и т.п.
Обычно это начинается так: нам нужно…
А вы вместо того, чтобы обоснованно пояснить, что тут у нас не хватает ресурсов: вычислительных, памяти, пропускной способности, технологического окна и т.д. и т.п. просто берете под козырек и говорите, что мол попробуем.
Начинается все это безобидно: давайте задержимся после работы, выйдем в ночь, пока сделаем так, а там докупим…
Заканчивается по-разному. Самый безобидный сценарий, это когда вам первый раз пожали руку, сказали спасибо и выдали премию, второй раз просто пожали руку, третий раз забыли про спасибо, а потом еще и посетовали, что что-то вы как-то плохо работали.
В результате подобный «героизм» входит в рутину и от вас его уже ожидают по умолчанию. Ну если нравится человеку работать по ночам без дополнительной оплаты…
Но это был безобидный сценарий. А ведь может все пойти не так, и ситуация превратится в авральную и неконтролируемую. После чего сразу переходим к пункту про вынужденный героизм.
Но тут есть нюансы, если причиной критического сбоя послужил внешний фактор, то им еще как-то можно прикрыться. А вот если вы размотали систему «на ровном месте», то это конкретное попадалово.
Потому что руководство доходчиво вам объяснит всю степень вашей неправоты: не контролировал, неверно оценивал риски, не приложил должных усилий и т.д. и т.п.
И оправдания, типа ну я же просил новый сервер, диски, память и т.п. не прокатят. Так как вам справедливо заметят, что если вы осознавали, то почему делали?
А если делали, то вам и отвечать. А что не выделили, так это вы не объяснили и не довели.
В общем – не надо так делать. Как говорил один мой первый руководитель, когда я проявлял ненужную инициативу – за героизм нам не платят.
👍18🤝5❤2👎1
Почему я не могу найти работу, если работать некому?
Примерно в этом ключе можно сформулировать основную мысль в последних комментариях. Частично о том, как проходит отбор соискателей по резюме, мы писали здесь и здесь. А не так давно касались проблемы возраста.
Теперь коснемся вопроса, как смотрит работодатель на соискателя на собеседовании и дает от ворот поворот даже если с квалификацией и резюме все хорошо.
Во многом собеседование – это ваша попытка продать себя конкретному работодателю и отказ надо воспринимать спокойно, ну не видит он вас своим сотрудником, просто не видит и все, так бывает.
Это как пришли вы на рынок за помидорами, ходите, смотрите, выбираете. Везде помидоры, цена примерно везде одинаковая, но возьмете вы почему-то вот эти, а не вон те. Просто приглянулись они вам чем-то.
Но есть ряд качеств, которые для работодателя как красная тряпка, хотя вы сами можете полагать обратное. И это не профессиональные качества, а личные, так сказать – софт-скиллы.
1️⃣ Вранье. То, что на собеседовании приукрашивают и привирают – знают все, это нормально. Но откровенное вранье – это сразу стоп-сигнал, хороший специалист по сленгу, терминам и вопросам с подтекстом сразу поймет, что вы не в теме. И сделает выводы, хотя вслух может ничего и не скажет.
Поэтому лучше честно скажите, что и как. Мол видеть видел, глубоко не вникал, коллеги делали, но готов учиться. Такая позиция выглядит в глазах работодателя намного лучше.
2️⃣ Любопытство. С одной стороны, интересоваться новым местом работы – это хорошо и правильно. Но начинать с порога углубляться в детали, не важно – технические, организационные, финансовые – это вызвать у потенциального работодателя настороженность. Коротко и емко это можно описать фразой: а казачок, случайно не засланный?
Плюс лишнее любопытство может вызвать настороженность у ваших будущих коллег? Зачем вы интересуетесь тем, что не касается прямо вашей будущей вакансии? Метите потом их подсидеть?
3️⃣ Болтливость. Это когда вы сразу, без каких-либо просьб вываливаете подробности внутренней кухни старого работодателя. Нет, возможно и в иных условиях эта информации оказалась бы для вашего работодателя ценной, и вы могли бы продать ее за некоторые бонусы.
Но когда он видит, что вы буквально без спроса вываливаете ему первому встречному-поперечному, то, что вам помешает точно также разболтать внутреннюю информацию о его компании?
А если это сочетается с предыдущим пунктом, то поздравляем, вы выбили двойное комбо!
4️⃣ Пронырливость. Если вас берут на позицию линейного сисадмина – то, наверное, организации нужен именно линейный сисадмин. А попытки продать себя «подороже», мол я еще и сервера знаю, и скрипты пишу, и на 1С умею, а еще крестиком вышивать могу вызовут только глухое раздражение ваших будущих коллег.
Вы только что, еще даже не устроившись на работу явно высказали претензии на их поляны. Фактически на их кусок хлеба и они видят в вас не будущего коллегу, а вполне реальную угрозу. То же самое может видеть и работодатель, а ему конфликтные ситуации в коллективе меньше всего нужны.
5️⃣ Психотип. По резюме этого не видно, но сразу бросается в глаза на собеседовании. И тут ничего сделать нельзя и это даже к лучшему. Скажем, ваши будущие коллеги – все сплошь крепкие грубоватые мужики, объединенные темой охоты и рыбалки, с грубыми шутками и приколами. А тут вы, интеллигентный любитель классической музыки.
Тут уже не только работодателю, но и ежу понятно, что комфортно вам вместе не будет, причем более некомфортно будет вам, а не им – они уже спевшийся и спаянный коллектив, а вы в нем белая ворона.
👉 Про остальное, которое уже относится к явной неадекватности, вроде неуместного внешнего вида, разговоров на отвлеченные темы и прочего подобного мы даже говорить не будем, сами должны понимать, что таким образом вы сами убиваете свои шансы до нуля.
Примерно в этом ключе можно сформулировать основную мысль в последних комментариях. Частично о том, как проходит отбор соискателей по резюме, мы писали здесь и здесь. А не так давно касались проблемы возраста.
Теперь коснемся вопроса, как смотрит работодатель на соискателя на собеседовании и дает от ворот поворот даже если с квалификацией и резюме все хорошо.
Во многом собеседование – это ваша попытка продать себя конкретному работодателю и отказ надо воспринимать спокойно, ну не видит он вас своим сотрудником, просто не видит и все, так бывает.
Это как пришли вы на рынок за помидорами, ходите, смотрите, выбираете. Везде помидоры, цена примерно везде одинаковая, но возьмете вы почему-то вот эти, а не вон те. Просто приглянулись они вам чем-то.
Но есть ряд качеств, которые для работодателя как красная тряпка, хотя вы сами можете полагать обратное. И это не профессиональные качества, а личные, так сказать – софт-скиллы.
1️⃣ Вранье. То, что на собеседовании приукрашивают и привирают – знают все, это нормально. Но откровенное вранье – это сразу стоп-сигнал, хороший специалист по сленгу, терминам и вопросам с подтекстом сразу поймет, что вы не в теме. И сделает выводы, хотя вслух может ничего и не скажет.
Поэтому лучше честно скажите, что и как. Мол видеть видел, глубоко не вникал, коллеги делали, но готов учиться. Такая позиция выглядит в глазах работодателя намного лучше.
2️⃣ Любопытство. С одной стороны, интересоваться новым местом работы – это хорошо и правильно. Но начинать с порога углубляться в детали, не важно – технические, организационные, финансовые – это вызвать у потенциального работодателя настороженность. Коротко и емко это можно описать фразой: а казачок, случайно не засланный?
Плюс лишнее любопытство может вызвать настороженность у ваших будущих коллег? Зачем вы интересуетесь тем, что не касается прямо вашей будущей вакансии? Метите потом их подсидеть?
3️⃣ Болтливость. Это когда вы сразу, без каких-либо просьб вываливаете подробности внутренней кухни старого работодателя. Нет, возможно и в иных условиях эта информации оказалась бы для вашего работодателя ценной, и вы могли бы продать ее за некоторые бонусы.
Но когда он видит, что вы буквально без спроса вываливаете ему первому встречному-поперечному, то, что вам помешает точно также разболтать внутреннюю информацию о его компании?
А если это сочетается с предыдущим пунктом, то поздравляем, вы выбили двойное комбо!
4️⃣ Пронырливость. Если вас берут на позицию линейного сисадмина – то, наверное, организации нужен именно линейный сисадмин. А попытки продать себя «подороже», мол я еще и сервера знаю, и скрипты пишу, и на 1С умею, а еще крестиком вышивать могу вызовут только глухое раздражение ваших будущих коллег.
Вы только что, еще даже не устроившись на работу явно высказали претензии на их поляны. Фактически на их кусок хлеба и они видят в вас не будущего коллегу, а вполне реальную угрозу. То же самое может видеть и работодатель, а ему конфликтные ситуации в коллективе меньше всего нужны.
5️⃣ Психотип. По резюме этого не видно, но сразу бросается в глаза на собеседовании. И тут ничего сделать нельзя и это даже к лучшему. Скажем, ваши будущие коллеги – все сплошь крепкие грубоватые мужики, объединенные темой охоты и рыбалки, с грубыми шутками и приколами. А тут вы, интеллигентный любитель классической музыки.
Тут уже не только работодателю, но и ежу понятно, что комфортно вам вместе не будет, причем более некомфортно будет вам, а не им – они уже спевшийся и спаянный коллектив, а вы в нем белая ворона.
👉 Про остальное, которое уже относится к явной неадекватности, вроде неуместного внешнего вида, разговоров на отвлеченные темы и прочего подобного мы даже говорить не будем, сами должны понимать, что таким образом вы сами убиваете свои шансы до нуля.
1👍16🤔6🤡3❤2
Как я внедрял систему учета обращений на бумажном носителе
Я уже рассказывал на данном канале истории из далекой молодости, когда я сразу после окончания высшего учебного заведения попал на работу в сельскохозяйственный НИИ на должность инженера.
Первоначально там предполагались задачи администратора, но постепенно на меня скинули все обязанности типового инженера данной конторы вплоть до газовых баллонов, пневматики и всего такого разного.
Сия организация была бюджетной и руководил ей бывший партийный начальник областного уровня, славный в свое время «подвигами», о которых из уст в уста передавались «легенды».
Контингент той конторы был преимущественно предпенсионного возраста, а «молодежь» были те, кому за тридцать. Ну и я со своими 20 с небольшим числился там за «юношу».
Очень скоро я познал… нет, не дзен, а суровую реальность бюджетной конторы – если можно не работать, то работать не нужно, а ответственность всегда можно спихнуть на кого-то другого.
В результате на собраниях по утрам меня часто вызывали на ковер к директору, потому что какой-то отдел чего-то там вовремя не сделал, а причиной назвал неисправность оборудования.
А дальше был примерно следующий диалог:
- Товарищ инженер, ну что это за дела?
- Товарищ директор, первый раз сейчас слышу.
- А мы тебе говорили!!!
- Когда?
- Когда ты баллон менял в понедельник!!!
- Не было такого!
- Было!!!
- Не было!
- Ты гляди, он еще и огрызается! Я тут 100500 лет работаю, а он без году неделя!!!
В результате подобные совещания заканчивались далеко не в мою пользу и получалось что инженер нефига не делает и вообще крайний.
Понятно, что такое положение дел мне не нравилось. Поэтому я взял толстую тетрадку, разлинеил ее и каждое утро, через полчаса после начала рабочего дня начал делать обход.
Я с этой тетрадкой заходил в каждый кабинет и спрашивал – есть ли вопросы по технике или нарекания. Нет? Отмечал в тетрадке: кабинет – прибор – наличие или отсутствие вопросов, дату и время.
Все обращения записывал туда-же. Дату и время обращения, его суть, коротко причину и принятые меры и время завершения. Или объективную невозможность завершить работы, например, нужно купить запасные части.
Со временем одна тетрадка превратилась во две. Одну я назвал «Журнал учета состояния техники», вторую «Журнал учета обращений». С одной делал обход, в другой фиксировал все заявки.
И потом на подобных совещаниях я просто приходил с тетрадками, открывал их и говорил, что обращений не получал, а если получал, то исправил тогда-то и тогда-то, либо не исправил по объективным причинам, так как…
Вся эта система была выстроена мною где-то за полгода, ну да когда получаешь отнюдь не пряники на каждом совещании – думать и шевелиться начнешь.
А потом она прижилась и тихо стала официальной, теперь уже не только я вел эту тетрадку, но и каждый отдел и расписывались в ней обе стороны.
Я проработал в этом НИИ ровно два года, но эта система осталась там надолго и уже лет через 10-15 при общении с бывшими коллегами я узнавал, что система обходов и журналов там до сих про живее всех живых.
Я уже рассказывал на данном канале истории из далекой молодости, когда я сразу после окончания высшего учебного заведения попал на работу в сельскохозяйственный НИИ на должность инженера.
Первоначально там предполагались задачи администратора, но постепенно на меня скинули все обязанности типового инженера данной конторы вплоть до газовых баллонов, пневматики и всего такого разного.
Сия организация была бюджетной и руководил ей бывший партийный начальник областного уровня, славный в свое время «подвигами», о которых из уст в уста передавались «легенды».
Контингент той конторы был преимущественно предпенсионного возраста, а «молодежь» были те, кому за тридцать. Ну и я со своими 20 с небольшим числился там за «юношу».
Очень скоро я познал… нет, не дзен, а суровую реальность бюджетной конторы – если можно не работать, то работать не нужно, а ответственность всегда можно спихнуть на кого-то другого.
В результате на собраниях по утрам меня часто вызывали на ковер к директору, потому что какой-то отдел чего-то там вовремя не сделал, а причиной назвал неисправность оборудования.
А дальше был примерно следующий диалог:
- Товарищ инженер, ну что это за дела?
- Товарищ директор, первый раз сейчас слышу.
- А мы тебе говорили!!!
- Когда?
- Когда ты баллон менял в понедельник!!!
- Не было такого!
- Было!!!
- Не было!
- Ты гляди, он еще и огрызается! Я тут 100500 лет работаю, а он без году неделя!!!
В результате подобные совещания заканчивались далеко не в мою пользу и получалось что инженер нефига не делает и вообще крайний.
Понятно, что такое положение дел мне не нравилось. Поэтому я взял толстую тетрадку, разлинеил ее и каждое утро, через полчаса после начала рабочего дня начал делать обход.
Я с этой тетрадкой заходил в каждый кабинет и спрашивал – есть ли вопросы по технике или нарекания. Нет? Отмечал в тетрадке: кабинет – прибор – наличие или отсутствие вопросов, дату и время.
Все обращения записывал туда-же. Дату и время обращения, его суть, коротко причину и принятые меры и время завершения. Или объективную невозможность завершить работы, например, нужно купить запасные части.
Со временем одна тетрадка превратилась во две. Одну я назвал «Журнал учета состояния техники», вторую «Журнал учета обращений». С одной делал обход, в другой фиксировал все заявки.
И потом на подобных совещаниях я просто приходил с тетрадками, открывал их и говорил, что обращений не получал, а если получал, то исправил тогда-то и тогда-то, либо не исправил по объективным причинам, так как…
Вся эта система была выстроена мною где-то за полгода, ну да когда получаешь отнюдь не пряники на каждом совещании – думать и шевелиться начнешь.
А потом она прижилась и тихо стала официальной, теперь уже не только я вел эту тетрадку, но и каждый отдел и расписывались в ней обе стороны.
Я проработал в этом НИИ ровно два года, но эта система осталась там надолго и уже лет через 10-15 при общении с бывшими коллегами я узнавал, что система обходов и журналов там до сих про живее всех живых.
1👍43🤣10🤡4❤1
Кто сильно переживал за ПИоТ - может выдохнуть и немного расслабиться.
С 1 июля продажи не станут и проверка марок в разрешительном режиме работать будет.
Штрафные санкции откладываются на 1 сентября.
Но расслабляться и откладывать на потом внедрение ПИоТ не нужно. Чтобы он не свалился вам потом как снег на голову, со всеми его приколами и чудесами.
С 1 июля продажи не станут и проверка марок в разрешительном режиме работать будет.
Штрафные санкции откладываются на 1 сентября.
Но расслабляться и откладывать на потом внедрение ПИоТ не нужно. Чтобы он не свалился вам потом как снег на голову, со всеми его приколами и чудесами.
🤝8❤3⚡3👍1👀1
Практическое использование программных лицензий 1С:Предпритие
Данный материал написан на злободневную тему, так как не все умеют правильно использовать желтый листок с набором цифр.
Что представляет собой программная лицензия? Это листок (физический или электронный), на котором нас интересуют два набора цифр.
В самом верху крупно напечатан рег. номер – это десять цифр, являющихся уникальным идентификатором лицензии. Его будут спрашивать при всех обращениях в поддержку и к нему привязываются все перечисленные ниже коды.
Пинкоды, напечатаны мельче в нижней части листка, напечатаны с избытком, например, на лицензии на 5 рабочих мест указано: пинкодов 8, из них 3 резервных.
Каждый пинкод дает вам право на получение или восстановление лицензии.
Получение лицензии подразумевает ее установку на новое рабочее место, здесь мы просто указываем пинкод и заполняем данные о пользователе.
После активации лицензии пинкод будет помечен как активный. Остальные останутся свободными/резервными.
До определенного момента никакой разницы между свободными и резервными пинкодами нет, вы можете использовать любой пинкод с листа как для активации новой лицензии, так и для восстановления уже существующей.
При восстановлении лицензии мы указываем старый пинкод и новый пинкод. После восстановления старый пинкод становится заблокированным.
После того, как количество активных лицензий сравняется с количеством доступных по данной лицензии, то все остальные пинкоды станут резервными, т.е. использовать их можно только для восстановления уже существующих лицензий. Получить новую лицензию по такому номеру не получится.
Вот с этим моментом и связан ряд тонкостей. Разберем несколько случаев. Во всех случаях будем рассматривать набор лицензии на 5 рабочих мест: пинкодов 8, из них 3 резервных.
Изначально мы установили лицензии на три рабочих места, потом на двух поменяли оборудование. А вот дальше возможны варианты.
1️⃣ Администратор решил не заморачиваться и на новые ПК получил новые лицензии. Теперь у нас 5 активных лицензий, 1С не отслеживает статус лицензии онлайн/оффлайн.
И далее новые лицензии мы уже активировать не сможем. Теперь нам доступен только один путь – восстановление. На новом ПК нам нужно будет указать пинкод от старого и те данные пользователя, которые были указаны при первом получении лицензии.
2️⃣ Администратор не поленился и восстановил лицензии на новые ПК, теперь у нас два пинкода заблокировано, три активно, а из оставшихся трех – два свободные и один резервный.
Да, несмотря на то что пинкодов осталось только три, два из них свободные. Кстати, самое время обратиться на линию лицензирования и получить еще резервный пинкод.
👆А вот теперь подводные камни.
На тех ПК, где у нас лицензии с заблокированными пинкодами сами файлы программной лицензии никуда не делись и при запуске 1С они продолжат работать как ни в чем не бывало. Но 1С отслеживает общее количество активных лицензий и у вас может начаться случайный их «слет».
Т.е. сегодня лицензия не обнаружена у Иванова, завтра у Петрова, а Иванов снова нормально работает. И если не изучать лог поиска ключа, то искать причину можно очень долго и безуспешно.
Также может помочь запрос на линию поддержки, они покажут вам какие пинкоды дублируются и на каких ПК это происходит, далее только останется найти ПК по имени.
✅ Поэтому, во избежание разных проблемных ситуаций удаляйте файлы программных лицензий с выводимых из эксплуатации ПК.
А также ведите учет пинкодов и указанной при их активации информации о пользователе, которую, напоминаем, надо восстановить посимвольно.
Все это, конечно, можно восстановить через линию поддержки, но это занимает время.
Также, при активации лицензий, указываете доступную и активную почту, а не почту пользователя или директора/главбуха.
Потому что иначе переписку с поддержкой вам придется вести через их ящик, либо предоставлять кучу дополнительной информации или довольствоваться тем, что информация на сторонний почтовый ящик будет ограничена.
Данный материал написан на злободневную тему, так как не все умеют правильно использовать желтый листок с набором цифр.
Что представляет собой программная лицензия? Это листок (физический или электронный), на котором нас интересуют два набора цифр.
В самом верху крупно напечатан рег. номер – это десять цифр, являющихся уникальным идентификатором лицензии. Его будут спрашивать при всех обращениях в поддержку и к нему привязываются все перечисленные ниже коды.
Пинкоды, напечатаны мельче в нижней части листка, напечатаны с избытком, например, на лицензии на 5 рабочих мест указано: пинкодов 8, из них 3 резервных.
Каждый пинкод дает вам право на получение или восстановление лицензии.
Получение лицензии подразумевает ее установку на новое рабочее место, здесь мы просто указываем пинкод и заполняем данные о пользователе.
После активации лицензии пинкод будет помечен как активный. Остальные останутся свободными/резервными.
До определенного момента никакой разницы между свободными и резервными пинкодами нет, вы можете использовать любой пинкод с листа как для активации новой лицензии, так и для восстановления уже существующей.
При восстановлении лицензии мы указываем старый пинкод и новый пинкод. После восстановления старый пинкод становится заблокированным.
После того, как количество активных лицензий сравняется с количеством доступных по данной лицензии, то все остальные пинкоды станут резервными, т.е. использовать их можно только для восстановления уже существующих лицензий. Получить новую лицензию по такому номеру не получится.
Вот с этим моментом и связан ряд тонкостей. Разберем несколько случаев. Во всех случаях будем рассматривать набор лицензии на 5 рабочих мест: пинкодов 8, из них 3 резервных.
Изначально мы установили лицензии на три рабочих места, потом на двух поменяли оборудование. А вот дальше возможны варианты.
1️⃣ Администратор решил не заморачиваться и на новые ПК получил новые лицензии. Теперь у нас 5 активных лицензий, 1С не отслеживает статус лицензии онлайн/оффлайн.
И далее новые лицензии мы уже активировать не сможем. Теперь нам доступен только один путь – восстановление. На новом ПК нам нужно будет указать пинкод от старого и те данные пользователя, которые были указаны при первом получении лицензии.
2️⃣ Администратор не поленился и восстановил лицензии на новые ПК, теперь у нас два пинкода заблокировано, три активно, а из оставшихся трех – два свободные и один резервный.
Да, несмотря на то что пинкодов осталось только три, два из них свободные. Кстати, самое время обратиться на линию лицензирования и получить еще резервный пинкод.
👆А вот теперь подводные камни.
На тех ПК, где у нас лицензии с заблокированными пинкодами сами файлы программной лицензии никуда не делись и при запуске 1С они продолжат работать как ни в чем не бывало. Но 1С отслеживает общее количество активных лицензий и у вас может начаться случайный их «слет».
Т.е. сегодня лицензия не обнаружена у Иванова, завтра у Петрова, а Иванов снова нормально работает. И если не изучать лог поиска ключа, то искать причину можно очень долго и безуспешно.
Также может помочь запрос на линию поддержки, они покажут вам какие пинкоды дублируются и на каких ПК это происходит, далее только останется найти ПК по имени.
✅ Поэтому, во избежание разных проблемных ситуаций удаляйте файлы программных лицензий с выводимых из эксплуатации ПК.
А также ведите учет пинкодов и указанной при их активации информации о пользователе, которую, напоминаем, надо восстановить посимвольно.
Все это, конечно, можно восстановить через линию поддержки, но это занимает время.
Также, при активации лицензий, указываете доступную и активную почту, а не почту пользователя или директора/главбуха.
Потому что иначе переписку с поддержкой вам придется вести через их ящик, либо предоставлять кучу дополнительной информации или довольствоваться тем, что информация на сторонний почтовый ящик будет ограничена.
👍14❤2🥱1
Очередная сказка о потерянном времени
Где-то примерно год назад внедряли одному заказчику систему для управления ИТ-отделом. Заказчик был рад и счастлив, строил обширные планы и уже готовил разнообразные интеграции.
Недавно встретились, просил как там его управление ИТ-отделом поживает? Выяснилось, что никак, задвинуто на самую дальнюю виртуалку самого дальнего сервера. Потому что оказалось никому не нужно, в том числе самому ИТ-отделу.
Надо сказать, что такому исходу мы совершенно не удивились, а точнее ожидали чего-то подобного с самого начала. Потому что подобных историй мы видели ни одну и не две.
Все это хорошо и красиво смотрится на бумаге, в мечтах и презентациях. Вот как внедрим, вот как заживем! А на самом деле это просто дополнительная нагрузка на персонал, дополнительная работа и дополнительная бюрократия. И если система не решает никаких насущных проблем – то заканчивается всегда примерно одинаково.
У нас уже примерно сформирован собственный рейтинг «ненужности», который выглядит следующим образом:
1️⃣ На первом месте с огромным отрывом стоят локальные базы знаний, чаще всего выполненные на Wiki-движках, но абсолютно необязательно.
Причина проста – такой базой знаний должен кто-то заниматься, причем заниматься постоянно. Если этого нет, то база утрачивает актуальность и ей просто перестают пользоваться, а если перестают пользоваться, то какой смысл ее пополнять.
Сейчас, на просьбы заказчика сделать им такой сервис мы сразу отвечаем, что сделать его – это только 1% от все работы. Остальное – это наполнение и тут им придется уже как-то самим. Обычно, когда дело доходит до конкретной реализации и назначения ответственных энтузиазм как-то сам утихает.
2️⃣ Второе место – это всякие внутренние порталы. В теории это видится некой точкой консолидации, в которой размещают новости, объявления, внутренние документы, инструкции и т.д. и т.п.
Но, на практике, всем этим снова нужно кому-то заниматься. И если нет специально назначенного за этим человека, то такой портал становится нафиг никому не нужным.
Еще меньше он нужен сотрудникам, что надо – доведет руководство. Да и все остальное легче передать через систему совместной работы, тот же Битрикс 24 или аналоги, им хотя бы ежедневно пользуются.
3️⃣ Третье место по ненужности занимает, как это не странно, мониторинг. Но здесь тоже все достаточно прозаично. Ожидания не совпадают с реальностью. Многие представляют мониторинг как красивые графики и диаграммы, которые можно вывести на отдельный монитор и с гордостью показывать начальству.
А по факту получаем кучу метрик, не меньше алертов, которые приходят по делу и без дела и необходимость серьезно вникать и настраивать продукт. После чего тот же условный Zabbix задвигается на самый дальний сервер и благополучно забывается.
4️⃣ Четвертое место, хотя можно и поменять местами с мониторингом, это системы учета заявок и инцидентов, тот же GLPI. Но мы все-таки вынесли его на четвертое, потому что внедряют его уже более-менее осознанно и данные системы менее популярны у начинающих, нежели мониторинги.
Но чтобы у вас работала система учета заявок, у вас уже должна быть работа с заявками или осознанная необходимость и политическая воля в ее создании и внедрении. Потому как инструмент выбирается для решения задачи, а не наоборот.
Вы же не покупаете отбойный молоток просто так и только потом начинаете искать куда бы его применить.
Если нет системы работы с заявками, равно как и самой культуры такой работы, то данный сервис окажется бесполезен и поигравшись месяц другой о нем все забудут.
👆 А по факту все это – потерянное время и ресурсы. И каждый раз, когда возникнет желание внедрить что-нибудь такое следует спросить себя - а оно мне точно нужно? А зачем? А нужно ли оно еще кому-нибудь кроме меня?
И если вы затрудняетесь дать твердые и аргументированные ответы – оно вам не нужно.
Где-то примерно год назад внедряли одному заказчику систему для управления ИТ-отделом. Заказчик был рад и счастлив, строил обширные планы и уже готовил разнообразные интеграции.
Недавно встретились, просил как там его управление ИТ-отделом поживает? Выяснилось, что никак, задвинуто на самую дальнюю виртуалку самого дальнего сервера. Потому что оказалось никому не нужно, в том числе самому ИТ-отделу.
Надо сказать, что такому исходу мы совершенно не удивились, а точнее ожидали чего-то подобного с самого начала. Потому что подобных историй мы видели ни одну и не две.
Все это хорошо и красиво смотрится на бумаге, в мечтах и презентациях. Вот как внедрим, вот как заживем! А на самом деле это просто дополнительная нагрузка на персонал, дополнительная работа и дополнительная бюрократия. И если система не решает никаких насущных проблем – то заканчивается всегда примерно одинаково.
У нас уже примерно сформирован собственный рейтинг «ненужности», который выглядит следующим образом:
1️⃣ На первом месте с огромным отрывом стоят локальные базы знаний, чаще всего выполненные на Wiki-движках, но абсолютно необязательно.
Причина проста – такой базой знаний должен кто-то заниматься, причем заниматься постоянно. Если этого нет, то база утрачивает актуальность и ей просто перестают пользоваться, а если перестают пользоваться, то какой смысл ее пополнять.
Сейчас, на просьбы заказчика сделать им такой сервис мы сразу отвечаем, что сделать его – это только 1% от все работы. Остальное – это наполнение и тут им придется уже как-то самим. Обычно, когда дело доходит до конкретной реализации и назначения ответственных энтузиазм как-то сам утихает.
2️⃣ Второе место – это всякие внутренние порталы. В теории это видится некой точкой консолидации, в которой размещают новости, объявления, внутренние документы, инструкции и т.д. и т.п.
Но, на практике, всем этим снова нужно кому-то заниматься. И если нет специально назначенного за этим человека, то такой портал становится нафиг никому не нужным.
Еще меньше он нужен сотрудникам, что надо – доведет руководство. Да и все остальное легче передать через систему совместной работы, тот же Битрикс 24 или аналоги, им хотя бы ежедневно пользуются.
3️⃣ Третье место по ненужности занимает, как это не странно, мониторинг. Но здесь тоже все достаточно прозаично. Ожидания не совпадают с реальностью. Многие представляют мониторинг как красивые графики и диаграммы, которые можно вывести на отдельный монитор и с гордостью показывать начальству.
А по факту получаем кучу метрик, не меньше алертов, которые приходят по делу и без дела и необходимость серьезно вникать и настраивать продукт. После чего тот же условный Zabbix задвигается на самый дальний сервер и благополучно забывается.
4️⃣ Четвертое место, хотя можно и поменять местами с мониторингом, это системы учета заявок и инцидентов, тот же GLPI. Но мы все-таки вынесли его на четвертое, потому что внедряют его уже более-менее осознанно и данные системы менее популярны у начинающих, нежели мониторинги.
Но чтобы у вас работала система учета заявок, у вас уже должна быть работа с заявками или осознанная необходимость и политическая воля в ее создании и внедрении. Потому как инструмент выбирается для решения задачи, а не наоборот.
Вы же не покупаете отбойный молоток просто так и только потом начинаете искать куда бы его применить.
Если нет системы работы с заявками, равно как и самой культуры такой работы, то данный сервис окажется бесполезен и поигравшись месяц другой о нем все забудут.
👆 А по факту все это – потерянное время и ресурсы. И каждый раз, когда возникнет желание внедрить что-нибудь такое следует спросить себя - а оно мне точно нужно? А зачем? А нужно ли оно еще кому-нибудь кроме меня?
И если вы затрудняетесь дать твердые и аргументированные ответы – оно вам не нужно.
👍27🤔7🔥3❤2🤡2
Про бумажки
Как известно, чем больше бумаги – тем чище одно место. И в обсуждениях этот метод неоднократно всплывал.
Что делать, если руководство или заказчики игнорируют потребности IT и требуют работать на том, что есть? Как обезопасить себя? Каким образом снять ответственность?
Скажем сразу – надежный и проверенный способ только один – не работать с чудаками на букву «м». Поэтому если заказчик или работодатель начинает неоднократно исполнять дичь, что с ним лучше расстаться по-хорошему, чем потом выяснять кто прав, а кто виноват.
Способ обложиться служебками не так прост, как кажется, и таит свои подводные камни. Прежде всего, служебку надо подать по всем принятым правилам документооборота, регистрацией и отметкой на своем экземпляре. Иначе толку от такой служебки не будет, она тут же отправится в мусорку.
В этом плане внешним подрядчикам проще, у них в договоре указаны допустимые форматы обмена документами и в большинстве случаев достаточно обычного письма по электронной почте. Более важные документы можно всегда отправить по ЭДО или заказным письмом с уведомлением.
Но вернемся к нашим баранам. А именно служебкам, в некоторых случаях их наличие может сыграть резко против вас, вплоть до самых печальных последствий.
Почему так? Начнем немного издалека. Для чего пишется служебка? Для того чтобы переложить ответственность с себя на руководителя, который не выделяет нужных ресурсов. Мол я тебя уведомил, моя совесть чиста, теперь это твоя проблема.
А вот и нет. Самая плохая ситуация, когда сложившаяся ситуация однозначно попадет под одну из статей скучной книжки с названием Уголовный кодекс.
Скажем пришла проверка на пиратство, а вы неоднократно служебками уведомляли руководство о наличии нелицензионного ПО. Вы молодец? Нет, вы только что подняли статью с пола. Потому что следователь так и запишет: осознавая противоправность деяния, группой лиц, по предварительному сговору…
Если касаться бюджетки, то там список статей куда более широкий, включая коррупционные и всякие прочие, касающиеся той же КИИ. И там наличие служебки будет являться доказательством того, что вы были в курсе всех творящихся безобразий, но мер по их предотвращению не приняли, в ближайший околоток с заявлением не обратились, а следовательно, пойдете прицепом.
Поэтому перед тем, как руки потянулись писать служебку, надо сесть и крепко подумать, а что скажет прокурор, попади эта бумага ему в руки? Иногда проще пройти за недалекого и недостаточно квалифицированного товарища, чем поднять с пола статью.
Но это только одна сторона монеты. На другой стороне коммерческие структуры и бизнес. А бизнес бывает разный. Вы можете обложиться служебками в два слоя, но если владелец бизнеса решит, что вы крайний – то крайним назначат именно вас.
И подпрыгивать там бесполезно. Свободно улетите по статье, если сами не уйдете по собственному, а там можете пытаться в суде доказать свое честное имя и восстановиться.
Но, это в реальной жизни практически волчий билет. Так как ваш новый потенциальный работодатель видит, что вы не смогли уладить конфликт полюбовно (т.е. уйти по собственному), а значит вы человек конфликтный. А судебная тяжба говорит о том, что вы еще и сутяжник. Ну и нафиг ему такой сотрудник?
Но это мы про бизнес цивилизованный, а кроме бизнеса цивилизованного, у нас осталось немало бизнеса дикого, который так и живет «по понятиям». И по этим самым «понятиям» вы будете им должны.
Полиция? С тем некомплектом, который творится там будет классическое: когда убьют – тогда и приходите. И даже если наш герой имеет стальные тестикулы, то всегда есть слабое звено: жена, дети, родители.
А еще никто не исключает связи вашего бывшего работодателя в силовых структурах, когда прессовать вас будет уже полиция. И тут надо или иметь контрсвязи, или сидеть и не отсвечивать.
Все это наша жизнь и реалии на земле. Поэтому служебки это хорошо, но абсолютно бесполезно во многих случаях.
Поэтому – просто не работайте с чудаками на букву «м».
Как известно, чем больше бумаги – тем чище одно место. И в обсуждениях этот метод неоднократно всплывал.
Что делать, если руководство или заказчики игнорируют потребности IT и требуют работать на том, что есть? Как обезопасить себя? Каким образом снять ответственность?
Скажем сразу – надежный и проверенный способ только один – не работать с чудаками на букву «м». Поэтому если заказчик или работодатель начинает неоднократно исполнять дичь, что с ним лучше расстаться по-хорошему, чем потом выяснять кто прав, а кто виноват.
Способ обложиться служебками не так прост, как кажется, и таит свои подводные камни. Прежде всего, служебку надо подать по всем принятым правилам документооборота, регистрацией и отметкой на своем экземпляре. Иначе толку от такой служебки не будет, она тут же отправится в мусорку.
В этом плане внешним подрядчикам проще, у них в договоре указаны допустимые форматы обмена документами и в большинстве случаев достаточно обычного письма по электронной почте. Более важные документы можно всегда отправить по ЭДО или заказным письмом с уведомлением.
Но вернемся к нашим баранам. А именно служебкам, в некоторых случаях их наличие может сыграть резко против вас, вплоть до самых печальных последствий.
Почему так? Начнем немного издалека. Для чего пишется служебка? Для того чтобы переложить ответственность с себя на руководителя, который не выделяет нужных ресурсов. Мол я тебя уведомил, моя совесть чиста, теперь это твоя проблема.
А вот и нет. Самая плохая ситуация, когда сложившаяся ситуация однозначно попадет под одну из статей скучной книжки с названием Уголовный кодекс.
Скажем пришла проверка на пиратство, а вы неоднократно служебками уведомляли руководство о наличии нелицензионного ПО. Вы молодец? Нет, вы только что подняли статью с пола. Потому что следователь так и запишет: осознавая противоправность деяния, группой лиц, по предварительному сговору…
Если касаться бюджетки, то там список статей куда более широкий, включая коррупционные и всякие прочие, касающиеся той же КИИ. И там наличие служебки будет являться доказательством того, что вы были в курсе всех творящихся безобразий, но мер по их предотвращению не приняли, в ближайший околоток с заявлением не обратились, а следовательно, пойдете прицепом.
Поэтому перед тем, как руки потянулись писать служебку, надо сесть и крепко подумать, а что скажет прокурор, попади эта бумага ему в руки? Иногда проще пройти за недалекого и недостаточно квалифицированного товарища, чем поднять с пола статью.
Но это только одна сторона монеты. На другой стороне коммерческие структуры и бизнес. А бизнес бывает разный. Вы можете обложиться служебками в два слоя, но если владелец бизнеса решит, что вы крайний – то крайним назначат именно вас.
И подпрыгивать там бесполезно. Свободно улетите по статье, если сами не уйдете по собственному, а там можете пытаться в суде доказать свое честное имя и восстановиться.
Но, это в реальной жизни практически волчий билет. Так как ваш новый потенциальный работодатель видит, что вы не смогли уладить конфликт полюбовно (т.е. уйти по собственному), а значит вы человек конфликтный. А судебная тяжба говорит о том, что вы еще и сутяжник. Ну и нафиг ему такой сотрудник?
Но это мы про бизнес цивилизованный, а кроме бизнеса цивилизованного, у нас осталось немало бизнеса дикого, который так и живет «по понятиям». И по этим самым «понятиям» вы будете им должны.
Полиция? С тем некомплектом, который творится там будет классическое: когда убьют – тогда и приходите. И даже если наш герой имеет стальные тестикулы, то всегда есть слабое звено: жена, дети, родители.
А еще никто не исключает связи вашего бывшего работодателя в силовых структурах, когда прессовать вас будет уже полиция. И тут надо или иметь контрсвязи, или сидеть и не отсвечивать.
Все это наша жизнь и реалии на земле. Поэтому служебки это хорошо, но абсолютно бесполезно во многих случаях.
Поэтому – просто не работайте с чудаками на букву «м».
⚡16👎5❤3🥱3🤡2
Раскрыты эксплоиты для 23 неисправленных уязвимостей в FFmpeg, VLC, Firefox, Docker, PHP, OpenVPN, nmap, libssh2, nghttp2 и 7zip
✅ Отсюда: https://www.opennet.ru/opennews/art.shtml?num=65794
В этой новости все прекрасно – это новая реальность, с которой мы столкнулись после прихода в нашу жизнь ИИ. Его можно не замечать, можно игнорировать, можно считать переоцененным, но по факту он есть, и он работает.
А в какую сторону он будет работать – это уже от применяющего его зависит, это как топором: можно дров наколоть, а можно бабку-процентщицу зарубить.
И это не единичный случай, ИИ старательно ищет и находит уязвимости там, где люди не видели их годами и будет продолжать это делать. В долгую это кардинально изменит модель разработки, когда ИИ будет, как минимум, проверять написанный код.
А вот на короткой дистанции легко не будет никому, ни разработчикам, ни пользователям. И, возможно, рынок ПО существенным образом изменится, те продукты, которые не смогут поддерживать подобный темп исправлений вынужденно уйдут на обочину.
Пользователям же придется серьезно пересмотреть модель обновлений в частном и использование софта в общем. Здесь как раз на первый план будет выходить скорость доставки обновлений и их атомарность, чтобы можно было обновить/откатить единственный пакет, а не все состояние системы.
Кроме того, это прекрасная иллюстрация качества кода, написанного руками, который часто пытаются противопоставить коду, написанному ИИ. Хотя ничего удивительного в этом нет – людям свойственно ошибаться, это нормально.
И также нет ничего удивительного, что ИИ пишет код гораздо лучше среднего человека, как минимум соблюдая все правила и соглашения языка и не ленясь делать проверки. Также будущее за безопасными языками, тем же Rust, хотя его и модно ругать.
Но это будет уже совсем другая история и совсем другой рынок ПО, который мы с нынешним темпом развития технологий можем увидеть уже в самом ближайшем будущем.
Анонимный исследователь безопасности опубликовал в открытом доступе прототипы 23 эксплоитов, в которых задействованы ещё не исправленные (0-day) уязвимости в таких проектах, как FFmpeg, VLC, Firefox, Docker, PHP, OpenVPN, nmap, libssh2, nghttp2, 7zip, Ghidra, Gitea, c-ares, Floci, Flowise, ImageMagick, Lunar Client, MyBB, objdump и RustDesk.
Уязвимости были выявлены в результате fuzzing-тестирования проектов с привлечением AI-модели GPT-5.5-3-Codex-Spark. Утверждается, что эксплоиты, за исключением эксплоита к RustDesk, были написаны вручную, но вся сопроводительная документация к ним сгенерирована через AI.
✅ Отсюда: https://www.opennet.ru/opennews/art.shtml?num=65794
В этой новости все прекрасно – это новая реальность, с которой мы столкнулись после прихода в нашу жизнь ИИ. Его можно не замечать, можно игнорировать, можно считать переоцененным, но по факту он есть, и он работает.
А в какую сторону он будет работать – это уже от применяющего его зависит, это как топором: можно дров наколоть, а можно бабку-процентщицу зарубить.
И это не единичный случай, ИИ старательно ищет и находит уязвимости там, где люди не видели их годами и будет продолжать это делать. В долгую это кардинально изменит модель разработки, когда ИИ будет, как минимум, проверять написанный код.
А вот на короткой дистанции легко не будет никому, ни разработчикам, ни пользователям. И, возможно, рынок ПО существенным образом изменится, те продукты, которые не смогут поддерживать подобный темп исправлений вынужденно уйдут на обочину.
Пользователям же придется серьезно пересмотреть модель обновлений в частном и использование софта в общем. Здесь как раз на первый план будет выходить скорость доставки обновлений и их атомарность, чтобы можно было обновить/откатить единственный пакет, а не все состояние системы.
Кроме того, это прекрасная иллюстрация качества кода, написанного руками, который часто пытаются противопоставить коду, написанному ИИ. Хотя ничего удивительного в этом нет – людям свойственно ошибаться, это нормально.
И также нет ничего удивительного, что ИИ пишет код гораздо лучше среднего человека, как минимум соблюдая все правила и соглашения языка и не ленясь делать проверки. Также будущее за безопасными языками, тем же Rust, хотя его и модно ругать.
Но это будет уже совсем другая история и совсем другой рынок ПО, который мы с нынешним темпом развития технологий можем увидеть уже в самом ближайшем будущем.
👍16❤3👏3🔥1