Непростой выбор
Задумался тут поменять часы, сейчас на руке HONOR MagicWatch 2 купленные в феврале 2020. В целом с ними все хорошо, но батарея уже подустала и стекло со временем наловило царапин.
Значит, что нужно. Часы классического дизайна, круглые. Ценой до 20 тыс. руб., всякими приложениями на часах я не балуюсь, нужны часы, уведомления, пульс, сон, да и, пожалуй, все.
Заряжать часы раз в день или несколько дней я также морально не готов, поэтому Samsung и иже с ним проходят мимо.
Из того, что есть в доступном наличии подобралось три варианта.
🔹 HUAWEI WATCH GT 4 – основной рассматриваемый вариант, четвертое поколение часов, что ждать – понятно, но по отзывам не сильно много отличий от второго поколения, которое сейчас на руке. С другой стороны – сюрпризов также быть не должно.
🔹 Xiaomi Watch S1 – именно S1, а не S1 Active. По описаниям лучше экран, как объективно (461 ppi против 326 ppi), так и субъективно. А также сапфировое стекло.
Не сказать, что стекло на HONOR / HUAWEI плохое, но за четыре года царапин насобирало. Но отзывы о модели неоднозначные и местами крайне противоположные. Кто-то в восторге, кто-то пишет, что они не стоят своих денег.
🔹 Amazfit GTR 4 – по отзывам и рейтингам лидер своей ценовой категории, все прямо хвалят. В целом по характеристикам тот же HUAWEI WATCH GT 4 плюс – минус. Но когда я поменял свои первые Amazfit STRATOS на HONOR MagicWatch 2, т.е. часы той же ценовой категории, то впечатления были сильно не в пользу Amazfit.
Причем нельзя сказать, что Amazfit был именно плох, нет, все вроде бы так, но общее ощущение от HONOR были как «цельно сделанная вещь», а STRATOS ощущался после него каким-то «недоделанным».
Поэтому есть вопрос, если у кого есть опыт эксплуатации этих моделей – поделитесь впечатлениями, плюсами и минусами, а также скажите, какие часы выбрали бы вы, желательно с краткой аргументацией.
Задумался тут поменять часы, сейчас на руке HONOR MagicWatch 2 купленные в феврале 2020. В целом с ними все хорошо, но батарея уже подустала и стекло со временем наловило царапин.
Значит, что нужно. Часы классического дизайна, круглые. Ценой до 20 тыс. руб., всякими приложениями на часах я не балуюсь, нужны часы, уведомления, пульс, сон, да и, пожалуй, все.
Заряжать часы раз в день или несколько дней я также морально не готов, поэтому Samsung и иже с ним проходят мимо.
Из того, что есть в доступном наличии подобралось три варианта.
🔹 HUAWEI WATCH GT 4 – основной рассматриваемый вариант, четвертое поколение часов, что ждать – понятно, но по отзывам не сильно много отличий от второго поколения, которое сейчас на руке. С другой стороны – сюрпризов также быть не должно.
🔹 Xiaomi Watch S1 – именно S1, а не S1 Active. По описаниям лучше экран, как объективно (461 ppi против 326 ppi), так и субъективно. А также сапфировое стекло.
Не сказать, что стекло на HONOR / HUAWEI плохое, но за четыре года царапин насобирало. Но отзывы о модели неоднозначные и местами крайне противоположные. Кто-то в восторге, кто-то пишет, что они не стоят своих денег.
🔹 Amazfit GTR 4 – по отзывам и рейтингам лидер своей ценовой категории, все прямо хвалят. В целом по характеристикам тот же HUAWEI WATCH GT 4 плюс – минус. Но когда я поменял свои первые Amazfit STRATOS на HONOR MagicWatch 2, т.е. часы той же ценовой категории, то впечатления были сильно не в пользу Amazfit.
Причем нельзя сказать, что Amazfit был именно плох, нет, все вроде бы так, но общее ощущение от HONOR были как «цельно сделанная вещь», а STRATOS ощущался после него каким-то «недоделанным».
Поэтому есть вопрос, если у кого есть опыт эксплуатации этих моделей – поделитесь впечатлениями, плюсами и минусами, а также скажите, какие часы выбрали бы вы, желательно с краткой аргументацией.
👍10🥱6
Какие бы часы из предложенных вы выбрали?
Anonymous Poll
23%
HUAWEI WATCH GT 4
8%
Xiaomi Watch S1
14%
Amazfit GTR 4
9%
Предложить другой вариант
47%
Посмотреть результаты
👍1
Как получить работу в крупной промышленной компании?
😭 Можно отправлять отклики на hh, проходить этапы отбора и учиться на полученных отказах
😍 А можно сократить путь с помощью карьерного канала СИБУРа
Тут ты найдешь:
— советы по составлению резюме и прохождению отбора;
— подборки свежих вакансий и стажировок;
— кейсы сотрудников и обмен опытом!
Материалы публикуются по нескольким веткам — будет полезно и студентам, и опытным специалистам, и руководителям. А контент собран в формате путешествия: ты сам выбираешь, какой пост будет следующим, с помощью удобных кнопок.
Вот, например, карьерная история Дианы, ведущего инженера с пермского производства СИБУРа, которую она рассказывает сама, но… с небольшим подвохом: что же случилось дальше, тебе придется угадать самому.
Готов проверить интуицию и познакомиться с реальной историей героини? Тогда подписывайся на канал и переходи к посту!
erid: LjN8K462F
😭 Можно отправлять отклики на hh, проходить этапы отбора и учиться на полученных отказах
😍 А можно сократить путь с помощью карьерного канала СИБУРа
Тут ты найдешь:
— советы по составлению резюме и прохождению отбора;
— подборки свежих вакансий и стажировок;
— кейсы сотрудников и обмен опытом!
Материалы публикуются по нескольким веткам — будет полезно и студентам, и опытным специалистам, и руководителям. А контент собран в формате путешествия: ты сам выбираешь, какой пост будет следующим, с помощью удобных кнопок.
Вот, например, карьерная история Дианы, ведущего инженера с пермского производства СИБУРа, которую она рассказывает сама, но… с небольшим подвохом: что же случилось дальше, тебе придется угадать самому.
Готов проверить интуицию и познакомиться с реальной историей героини? Тогда подписывайся на канал и переходи к посту!
erid: LjN8K462F
Почему именно systemd?
Практически после каждой нашей заметки о возможностях systemd в комментариях появляются читатели, которые пишут, что мол, а не проще ли это сделать … и далее идет перечисление простых утилит или скриптов.
С одной стороны, они могут показаться в чем-то правы. Зачем нужны все эти юниты, когда можно просто дернуть утилиту, получить результат и обернуть все это в скрипт.
Но это очень узкий и односторонний взгляд. Современные системы очень сложны и требуют стандартизации и унификации средств администрирования.
Вы можете мастерски владеть скриптами и автоматизировать все с их помощью, но ваши коллеги не сильно обрадуются этому факту, если им придется принять у вас обслуживание этой системы. Да и самому элементарно можно забыть, где лежит и для чего нужен тот или иной скрипт, особенно если подробного документирования не производилось.
Поэтому первый плюс systemd – это унификация и стандартизация. Теперь у нас есть юниты: юниты служб, юниты таймеров, юниты путей, юниты монтирования и т.д. и т.п.
Все юниты стандартизованы и научившись работать с одним типом вы без труда освоите другой. Кроме этого, юниты просты, очень просты и не идут ни в какое сравнение со скриптами.
Списки юнитов и их состояние также можно получить централизованно, одной простой командой. А чтобы проверить все возможные задания того же cron вам придется пробежать несколько каталогов, а также проверить crontab.
Второй плюс – это углубленная интеграция в систему, systemd предоставляет множество удобных инструментов, начиная от управления автозагрузкой и заканчивая средствами логирования.
Чтобы посмотреть результат работы скрипта – вам придется самому позаботиться о ведении лога. В systemd все это можно посмотреть «не отходя от кассы», стандартными инструментами. При этом никаких особых усилий к этому прикладывать не придется.
Из этого вытекает еще одно большое преимущество юнитов – их гораздо проще отлаживать. Во-первых, у вас уже есть лог, который ведется автоматически. Во-вторых, юниты предсказуемы и работают одинаково, вне зависимости от того, запущены они вручную или другим юнитом.
В тоже время отлично работающий при интерактивном запуске скрипт может оказаться неработоспособным при вызове через cron или из другого скрипта просто потому, что оказался запущен в другом контексте, с другими переменными окружения.
До сих пор нами были перечислены простые задачи, на которых преимущества systemd, конечно, видны, но еще не раскрыли всех своих возможностей.
Начнем с зависимостей. Как мы уже говорили – современные системы сложны. Многие их компоненты и службы зависят от других служб или предоставляемых ими ресурсов. Например, нам нужно выполнить какое-то задание, но только после того, как поднимется сеть и будут доступны некоторые сетевые ресурсы.
Для традиционного решения этой задачи придется немало поломать голову, выполнить кучу проверок или, как делается чаще всего, пойти по пути костылей и синей изоленты. Скажем, просто поставить задержку, в надежде что за это время сервис, от которого зависит работа успеет подняться. Ну а нет, так нет…
Systemd предоставляет простой и удобный способ работы с зависимостями. При этом вы можете указывать как отдельные службы, так и цели (таргеты), которые составляют группы служб, объединенные по некоторому признаку. Нужна сеть? Просто указываем в зависимостях network.target.
Еще одна важная задача – обработка отказа. Если служба упала – вы можете ее автоматически перезапустить. Но это можно сделать и без systemd, а вот systemd позволяет сделать это грамотно, указав частоту и количество попыток.
Если проблема приняла системный характер или находится на другой стороне, то systemd попробует несколько раз перезапустить службу и прекратит это делать, не получив результата. И это гораздо лучше, чем тупо долбить скриптом, вызывая повышенную нагрузку на систему и сеть.
Размер заметки не дает углубиться в подробности, но даже перечисленное дает исчерпывающий ответ на вопрос: почему именно systemd?
Практически после каждой нашей заметки о возможностях systemd в комментариях появляются читатели, которые пишут, что мол, а не проще ли это сделать … и далее идет перечисление простых утилит или скриптов.
С одной стороны, они могут показаться в чем-то правы. Зачем нужны все эти юниты, когда можно просто дернуть утилиту, получить результат и обернуть все это в скрипт.
Но это очень узкий и односторонний взгляд. Современные системы очень сложны и требуют стандартизации и унификации средств администрирования.
Вы можете мастерски владеть скриптами и автоматизировать все с их помощью, но ваши коллеги не сильно обрадуются этому факту, если им придется принять у вас обслуживание этой системы. Да и самому элементарно можно забыть, где лежит и для чего нужен тот или иной скрипт, особенно если подробного документирования не производилось.
Поэтому первый плюс systemd – это унификация и стандартизация. Теперь у нас есть юниты: юниты служб, юниты таймеров, юниты путей, юниты монтирования и т.д. и т.п.
Все юниты стандартизованы и научившись работать с одним типом вы без труда освоите другой. Кроме этого, юниты просты, очень просты и не идут ни в какое сравнение со скриптами.
Списки юнитов и их состояние также можно получить централизованно, одной простой командой. А чтобы проверить все возможные задания того же cron вам придется пробежать несколько каталогов, а также проверить crontab.
Второй плюс – это углубленная интеграция в систему, systemd предоставляет множество удобных инструментов, начиная от управления автозагрузкой и заканчивая средствами логирования.
Чтобы посмотреть результат работы скрипта – вам придется самому позаботиться о ведении лога. В systemd все это можно посмотреть «не отходя от кассы», стандартными инструментами. При этом никаких особых усилий к этому прикладывать не придется.
Из этого вытекает еще одно большое преимущество юнитов – их гораздо проще отлаживать. Во-первых, у вас уже есть лог, который ведется автоматически. Во-вторых, юниты предсказуемы и работают одинаково, вне зависимости от того, запущены они вручную или другим юнитом.
В тоже время отлично работающий при интерактивном запуске скрипт может оказаться неработоспособным при вызове через cron или из другого скрипта просто потому, что оказался запущен в другом контексте, с другими переменными окружения.
До сих пор нами были перечислены простые задачи, на которых преимущества systemd, конечно, видны, но еще не раскрыли всех своих возможностей.
Начнем с зависимостей. Как мы уже говорили – современные системы сложны. Многие их компоненты и службы зависят от других служб или предоставляемых ими ресурсов. Например, нам нужно выполнить какое-то задание, но только после того, как поднимется сеть и будут доступны некоторые сетевые ресурсы.
Для традиционного решения этой задачи придется немало поломать голову, выполнить кучу проверок или, как делается чаще всего, пойти по пути костылей и синей изоленты. Скажем, просто поставить задержку, в надежде что за это время сервис, от которого зависит работа успеет подняться. Ну а нет, так нет…
Systemd предоставляет простой и удобный способ работы с зависимостями. При этом вы можете указывать как отдельные службы, так и цели (таргеты), которые составляют группы служб, объединенные по некоторому признаку. Нужна сеть? Просто указываем в зависимостях network.target.
Еще одна важная задача – обработка отказа. Если служба упала – вы можете ее автоматически перезапустить. Но это можно сделать и без systemd, а вот systemd позволяет сделать это грамотно, указав частоту и количество попыток.
Если проблема приняла системный характер или находится на другой стороне, то systemd попробует несколько раз перезапустить службу и прекратит это делать, не получив результата. И это гораздо лучше, чем тупо долбить скриптом, вызывая повышенную нагрузку на систему и сеть.
Размер заметки не дает углубиться в подробности, но даже перечисленное дает исчерпывающий ответ на вопрос: почему именно systemd?
👍60💯8🔥5
Что такое хорошо и что такое плохо
В админской среде всегда любили и любят всякое нестандартное, возводя это в достоинство и формируя мнение, что любой админ должен уметь нечто такое, что недоступно остальным и позволит выкрутиться из любой ситуации.
В итоге очень и очень многие решения идут вопреки стандартным практикам и фактически представляют из себя костыли и изоленту.
Кто-то виртуозно владеет скриптами, кто-то выучил справочник твиков реестра и т.д. и т.п. И считается что это хорошо.
Нет, знания и умения – это однозначно хорошо, но, когда они идут в разрез с общепринятыми практиками – это плохо.
Попытка решить стандартные вопросы нестандартными средствами – это плохо. И никакие оправдания тут не могут быть уместны.
Исключения – это специфические системы, например, высоконагруженные, но там админы прекрасно понимают, что делают и там у них есть свои стандартные практики, которые всем остальным просто не нужны.
Попытки применять нестандартные средства говорят только об одном – администратор не владеет базовыми навыками администрирования системы, подменяя их собственными костылями.
Столь же плохо применение в системах общего назначения каких-то специализированных практик, какими бы они «крутыми» и «навороченными» не казались.
Мы не раз сталкивались с нестандартными настройками и твиками, которые вызывали сложности на ровном месте. А когда начинали выяснять что это и зачем, то могли услышать примерно следующее:
- Ну это крутые пацаны из High Load рекомендуют?
- А у тебя высокая нагрузка?
- Нет, но…
Или:
- Ну это защита от сетевых атак…
- Тебя кто-то атакует?
- Нет, но…
Все это, конечно, может выглядеть круто, но, по сути, это не дает никаких плюсов, а только сплошные минусы.
Подобные настройки могут вызывать потенциальные конфликты, приводить к сложностям в поддержке или администрировании и даже стать причиной отказов, если незнакомый с ними администратор применит настройки, явно приводящие к конфликту.
Поэтому если у вас самая обычная система, которая не испытывает высоких нагрузок и которую никто не атакует, то и настройки в ней должны быть самые стандартные, сделанные стандартными для этой системы механизмами.
И именно это будет хорошо и правильно. Потому что позволит любому знакомому с системой специалисту быстро разобраться в ней и продолжить поддержку в отсутствие ее основного «архитектора».
И все порывы сделать «лучше», «быстрее», «дешевле» и т.п. нестандартными методами должны жестко пресекаться, как контролем, так и самоконтролем.
Потому что все эти костыли и изолента имеют свойство выстреливать в самый неподходящий момент. И делать это достаточно больно.
Здесь я еще раз напомню, что платят нам не за наши пируэты и изыски, тот кто платит – он и слов таких не знает. А платят нам за стабильную и предсказуемую работу.
Если вы вчера сэкономили нестандартным решением десять тысяч рублей, а сегодня, во время вашего отпуска все это упало и разбирались с вашими художествами несколько часов, понеся убытки на сотни тысяч, то ваши мотивы никто из лиц принимающих решения просто не поймет. Со всеми вытекающими оргвыводами.
Поэтому, подводя итоги, можно сказать, что следовать стандартным практикам, даже если они не совсем оптимальны – это хорошо. А городить собственные нестандартные решения – плохо.
При этом мы не хотим сказать, что нестандартные решения не имеют права на существование. Иногда без них никак. Но при этом они должны быть именно нестандартными и становиться личным стандартом де факто.
Но даже применяя нестандартные решения нужно стараться максимально их стандартизовать: использовать стандартные пути размещения файлов, понятные наименования скриптов и переменных в них. Т.е. сделать работу с ними максимально понятной третьему лицу, который увидит это в первый раз.
Ну и конечно не забыть все это документировать. И часть документации будет совсем не лишним разместить прямо здесь, лучше всего в комментариях к скрипту или в виде файла где-то рядом.
В админской среде всегда любили и любят всякое нестандартное, возводя это в достоинство и формируя мнение, что любой админ должен уметь нечто такое, что недоступно остальным и позволит выкрутиться из любой ситуации.
В итоге очень и очень многие решения идут вопреки стандартным практикам и фактически представляют из себя костыли и изоленту.
Кто-то виртуозно владеет скриптами, кто-то выучил справочник твиков реестра и т.д. и т.п. И считается что это хорошо.
Нет, знания и умения – это однозначно хорошо, но, когда они идут в разрез с общепринятыми практиками – это плохо.
Попытка решить стандартные вопросы нестандартными средствами – это плохо. И никакие оправдания тут не могут быть уместны.
Исключения – это специфические системы, например, высоконагруженные, но там админы прекрасно понимают, что делают и там у них есть свои стандартные практики, которые всем остальным просто не нужны.
Попытки применять нестандартные средства говорят только об одном – администратор не владеет базовыми навыками администрирования системы, подменяя их собственными костылями.
Столь же плохо применение в системах общего назначения каких-то специализированных практик, какими бы они «крутыми» и «навороченными» не казались.
Мы не раз сталкивались с нестандартными настройками и твиками, которые вызывали сложности на ровном месте. А когда начинали выяснять что это и зачем, то могли услышать примерно следующее:
- Ну это крутые пацаны из High Load рекомендуют?
- А у тебя высокая нагрузка?
- Нет, но…
Или:
- Ну это защита от сетевых атак…
- Тебя кто-то атакует?
- Нет, но…
Все это, конечно, может выглядеть круто, но, по сути, это не дает никаких плюсов, а только сплошные минусы.
Подобные настройки могут вызывать потенциальные конфликты, приводить к сложностям в поддержке или администрировании и даже стать причиной отказов, если незнакомый с ними администратор применит настройки, явно приводящие к конфликту.
Поэтому если у вас самая обычная система, которая не испытывает высоких нагрузок и которую никто не атакует, то и настройки в ней должны быть самые стандартные, сделанные стандартными для этой системы механизмами.
И именно это будет хорошо и правильно. Потому что позволит любому знакомому с системой специалисту быстро разобраться в ней и продолжить поддержку в отсутствие ее основного «архитектора».
И все порывы сделать «лучше», «быстрее», «дешевле» и т.п. нестандартными методами должны жестко пресекаться, как контролем, так и самоконтролем.
Потому что все эти костыли и изолента имеют свойство выстреливать в самый неподходящий момент. И делать это достаточно больно.
Здесь я еще раз напомню, что платят нам не за наши пируэты и изыски, тот кто платит – он и слов таких не знает. А платят нам за стабильную и предсказуемую работу.
Если вы вчера сэкономили нестандартным решением десять тысяч рублей, а сегодня, во время вашего отпуска все это упало и разбирались с вашими художествами несколько часов, понеся убытки на сотни тысяч, то ваши мотивы никто из лиц принимающих решения просто не поймет. Со всеми вытекающими оргвыводами.
Поэтому, подводя итоги, можно сказать, что следовать стандартным практикам, даже если они не совсем оптимальны – это хорошо. А городить собственные нестандартные решения – плохо.
При этом мы не хотим сказать, что нестандартные решения не имеют права на существование. Иногда без них никак. Но при этом они должны быть именно нестандартными и становиться личным стандартом де факто.
Но даже применяя нестандартные решения нужно стараться максимально их стандартизовать: использовать стандартные пути размещения файлов, понятные наименования скриптов и переменных в них. Т.е. сделать работу с ними максимально понятной третьему лицу, который увидит это в первый раз.
Ну и конечно не забыть все это документировать. И часть документации будет совсем не лишним разместить прямо здесь, лучше всего в комментариях к скрипту или в виде файла где-то рядом.
👍56🤔8👎1😁1🌭1
И снова про отечественные сертификаты
Весна еще не наступила, а очередное весеннее обострение уже началось. С завидной регулярностью отдельные товарищи начинают разгонять очередную дичь про сертификаты Мицифры.
Мол какое может быть доверие этим сертификатам и этому CA если… (тут можете вписать любой набор стандартных пугалок), в отличие от коммерческих западных CA, которые прозрачны, контролируемы, регулируемы и т.д. и т.п.
Сразу начнем с того, что все взаимодействия в инфраструктуре открытых ключей (PKI) строятся на основании отношений доверия и ключевые участники этого рынка такими отношениями сильно дорожат.
Но все ли так светло и радужно? Нет, достаточно вспомнить историю с WoSign и StartCom, которые творили лютую дичь, включая выпуск сертификатов задним числом и крайне слабые проверки действительного владельца домена.
За ним последовал Symantec, тоже не последний игрок на рынке, и хотя его прегрешения были куда попроще, но это ему тоже не помогло.
Поэтому ни покровительство Минцифры, ни какие иные административные факторы не помогут отечественному CA удержать отношения доверия если он вдруг влипнет в какую-нибудь нехорошую историю.
И инициаторами вынесения вотума недоверия будет не общественность и не активисты, а крупные игроки этого рынка, пользующиеся его услугами, тот же Сбербанк.
Так что мы не видим никаких разумных предпосылок не доверять сертификатам Минцифры по различным надуманным причинам.
Но это была теория, а теперь перейдем к практике. Основная пугалка адептов секты свидетелей Товарища Майора гласит, что сразу после установки сертификата вы делаете весь свой трафик доступным тому самому Товарищу Майору.
Так ли это? Конечно же не так. Что делает удостоверяющий центр Минцифры выдавая сертификат тому же Сбербанку? Прежде всего он удостоверяется, что за сертификатом пришел именно Сбербанк и подписывает выданный сертификат своим закрытым ключом.
Теперь каждый у кого есть открытый ключ (сертификат) Минцифры может проверить подлинность этого сертификата и начать доверять ему, так как мы доверяем удостоверяющему центру, выдавшему сертификат.
Может ли теперь Минцифры расшифровать трафик, зашифрованный этим сертификатом? Нет! Сделать этот может только владелец закрытого ключа, т.е. Сбербанк. Для получения сертификата закрытый ключ удостоверяющему центру предоставлять не нужно.
Но в реальности все еще более интересно, открыв свойства защищенного соединения в браузере, например, для того же Сбербанка, мы увидим строку наподобие:
Это означает, что для формирования сеансового ключа, которым зашифрован канал связи используется алгоритм Диффи-Хеллмана, который позволяет формировать динамические ключи шифрования обоими сторонами без передачи их по каналам связи.
Сеансовые ключи являются одноразовыми и нигде не сохраняются. Это называется совершенная прямая секретность и не позволяет расшифровать записанный сеанс связи даже получив доступ к закрытому ключу владельца сертификата.
Говорить про возможный MitM тем более несерьезно, потому что такое решение должно приниматься на самом высоком уровне и для этого нужны крайне серьезные основания. Плюс не забываем о возможных негативных последствиях со стороны других крупных игроков рынка.
При том, что этот самый MitM давно уже существует на ПК многих и многих пользователей совершенно легально и с их ведома, но почему-то это никого не интересует и не создает такого ажиотажа.
Да, мы про антивирусное ПО, которое имеет функцию проверки трафика на лету, для чего устанавливает собственный доверенный сертификат и делает все тоже самое, в чем пытаются безосновательно обвинить Минцифры.
Хотя потенциальному Товарищу Майору гораздо проще пойти договориться с Касперским, чем мутить с нуля свой собственный MitM.
Поэтому – будьте благоразумны, удостоверяющий центр Минцифры ничем не отличается от любого другого удостоверяющего центра и использование его несет одинаковые с ними угрозы. При том, как мы видели выше, коммерческие УЦ тоже далеко не образцы для подражания.
Весна еще не наступила, а очередное весеннее обострение уже началось. С завидной регулярностью отдельные товарищи начинают разгонять очередную дичь про сертификаты Мицифры.
Мол какое может быть доверие этим сертификатам и этому CA если… (тут можете вписать любой набор стандартных пугалок), в отличие от коммерческих западных CA, которые прозрачны, контролируемы, регулируемы и т.д. и т.п.
Сразу начнем с того, что все взаимодействия в инфраструктуре открытых ключей (PKI) строятся на основании отношений доверия и ключевые участники этого рынка такими отношениями сильно дорожат.
Но все ли так светло и радужно? Нет, достаточно вспомнить историю с WoSign и StartCom, которые творили лютую дичь, включая выпуск сертификатов задним числом и крайне слабые проверки действительного владельца домена.
За ним последовал Symantec, тоже не последний игрок на рынке, и хотя его прегрешения были куда попроще, но это ему тоже не помогло.
Поэтому ни покровительство Минцифры, ни какие иные административные факторы не помогут отечественному CA удержать отношения доверия если он вдруг влипнет в какую-нибудь нехорошую историю.
И инициаторами вынесения вотума недоверия будет не общественность и не активисты, а крупные игроки этого рынка, пользующиеся его услугами, тот же Сбербанк.
Так что мы не видим никаких разумных предпосылок не доверять сертификатам Минцифры по различным надуманным причинам.
Но это была теория, а теперь перейдем к практике. Основная пугалка адептов секты свидетелей Товарища Майора гласит, что сразу после установки сертификата вы делаете весь свой трафик доступным тому самому Товарищу Майору.
Так ли это? Конечно же не так. Что делает удостоверяющий центр Минцифры выдавая сертификат тому же Сбербанку? Прежде всего он удостоверяется, что за сертификатом пришел именно Сбербанк и подписывает выданный сертификат своим закрытым ключом.
Теперь каждый у кого есть открытый ключ (сертификат) Минцифры может проверить подлинность этого сертификата и начать доверять ему, так как мы доверяем удостоверяющему центру, выдавшему сертификат.
Может ли теперь Минцифры расшифровать трафик, зашифрованный этим сертификатом? Нет! Сделать этот может только владелец закрытого ключа, т.е. Сбербанк. Для получения сертификата закрытый ключ удостоверяющему центру предоставлять не нужно.
Но в реальности все еще более интересно, открыв свойства защищенного соединения в браузере, например, для того же Сбербанка, мы увидим строку наподобие:
Key exchange ECDHE_RSA with P-256Это означает, что для формирования сеансового ключа, которым зашифрован канал связи используется алгоритм Диффи-Хеллмана, который позволяет формировать динамические ключи шифрования обоими сторонами без передачи их по каналам связи.
Сеансовые ключи являются одноразовыми и нигде не сохраняются. Это называется совершенная прямая секретность и не позволяет расшифровать записанный сеанс связи даже получив доступ к закрытому ключу владельца сертификата.
Говорить про возможный MitM тем более несерьезно, потому что такое решение должно приниматься на самом высоком уровне и для этого нужны крайне серьезные основания. Плюс не забываем о возможных негативных последствиях со стороны других крупных игроков рынка.
При том, что этот самый MitM давно уже существует на ПК многих и многих пользователей совершенно легально и с их ведома, но почему-то это никого не интересует и не создает такого ажиотажа.
Да, мы про антивирусное ПО, которое имеет функцию проверки трафика на лету, для чего устанавливает собственный доверенный сертификат и делает все тоже самое, в чем пытаются безосновательно обвинить Минцифры.
Хотя потенциальному Товарищу Майору гораздо проще пойти договориться с Касперским, чем мутить с нуля свой собственный MitM.
Поэтому – будьте благоразумны, удостоверяющий центр Минцифры ничем не отличается от любого другого удостоверяющего центра и использование его несет одинаковые с ними угрозы. При том, как мы видели выше, коммерческие УЦ тоже далеко не образцы для подражания.
👍71👎7💯6❤4🤮3
Привет!
Это команда Концепт-Разработка. Мы занимаемся развитием и внедрением продуктов в сфере больших данных, корпоративных хранилищ данных, BI и систем управления данными. У себя в канале развиваем сообщество бизнес и системных аналитиков, разработчиков и data-инженеров.
+ Актуальные вакансии;
+ Интересные разработки;
+ Проекты федеральных заказчиков;
+ Новости индустрии и многое другое.
Подписывайся на канал, мы будем рады и экспертам, и начинающим специалистам!
Реклама. ООО "КОНЦЕПТ РАЗРАБОТКА". ИНН 7703471165. erid: LjN8KQu3R
Это команда Концепт-Разработка. Мы занимаемся развитием и внедрением продуктов в сфере больших данных, корпоративных хранилищ данных, BI и систем управления данными. У себя в канале развиваем сообщество бизнес и системных аналитиков, разработчиков и data-инженеров.
+ Актуальные вакансии;
+ Интересные разработки;
+ Проекты федеральных заказчиков;
+ Новости индустрии и многое другое.
Подписывайся на канал, мы будем рады и экспертам, и начинающим специалистам!
Реклама. ООО "КОНЦЕПТ РАЗРАБОТКА". ИНН 7703471165. erid: LjN8KQu3R
⚡1👍1
Чебурнет
Еще одна любимая пугалка в среде IT-братии. Но многие, наверное, удивятся, потому что Чебурнет давно существует и не один.
Что такое сеть интернет? Это всемирное средство коммуникации и т.д. и т.п. Но давайте спустимся с небес на землю и посмотрим на это все с позиции рядового пользователя.
Возьмем условного дядю Васю, инженера на заводе и его жену тетю Клаву, учителя начальных классов. Ну и их детей, Ваню и Машу, класса так 5-го и 10-го.
От IT они крайне далеки и весь их интерес в интернете сводится к получению развлекательного контента и общению к себе подобными.
В языках наше условное семейство не подковано и весь их интерес лежит в зоне RU, которая понятна, ментально близка и позволяет удовлетворить все насущные потребности.
Общий ареал зоны RU – это постсоветское пространство, где русский язык является языком межнационального общения и является неким объединяющим и цементирующим фактором.
Да, есть еще национальные зоны, но они достаточно узки и не могут покрыть все запросы простого пользователя, поэтому так или иначе любой житель постсоветского пространства так или иначе окажется в зоне RU.
Но ведь есть еще и международный интернет… Но что там ловить? В первую очередь мешает языковой барьер, во вторую – там нет ничего интересного простому пользователю. Разве что музыка, кино (обязательно с переводом) и футбол.
Но это все доступно и в зоне RU. Точнее было доступно. Но сей контент сделался недоступным не по политическим мотивам и Товарищ Майор здесь не причем, большинство блокировок возникли по требованиям правообладателей, которые преследовали свои коммерческие интересы.
В ответ народ пошел активно осваивать торренты и VPN, но не потому, что злые чекисты задушили свободу самовыражения, чихать им на это, а потому что правообладатели лишили дядю Васю и тетю Клаву бесплатных зрелищ.
По сути, зона RU – это исторически сложившийся Чебурнет. Он не интересен западному пользователю, так как он вообще здесь ничего прочитать не может (другой алфавит, как никак), а западный сегмент также не интересен пользователю русскоязычному. Потому что языковой барьер.
И тот же Ютуб или Инстаграмм интересен не потому, что кто-то хочет вырваться из Чебурнета на свободу, а потому что в Чебурнете нет им доступных аналогов.
Если брать те же соцсети, то VK/ОК закрыли практически всю нишу, и никто не страдает от отсутствия той же Мордокниги (Facebook).
Стоит только обеспечить качественное импортозамещение этих сервисов и в ту сторону больше никто не посмотрит. А зачем, когда есть тоже самое, но на русском языке.
В итоге за условный «железный занавес» будут бегать только за варезом и контентом 18+, хотя насчет последнего не уверен, так как основной его черно-оранжевый поставщик действует в России вполне легально, надо только подтвердить возраст через VK.
Второй сложившийся Чебурнет – это китайский сегмент сети. Да, он огорожен Великим Китайским Файрволлом, но, по сути, у рядового китайца нет никакой необходимости выходить за периметр.
Если наша культура достаточно близка западной, то китайская крайне далека и непонятна нам, как и наша культура им.
В тоже время в китайском сегменте есть все: свои соцсети, мессенджеры, платежные системы, видеохостинги и т.д. и т.п., в результате чего среднестатистический китаец даже не думает о том, что ему запрещено подключаться куда-то на западные ресурсы.
Собственно, а вы сильно пострадаете, если вам вдруг закроют доступ к китайским ресурсам?
Поэтому китайский Чебурнет — это вполне сложившаяся вещь в себе, пользователи которой вполне довольствуются внутренними ресурсами и не особо стремятся выйти наружу.
Равно как и русский Чебурнет включает в себя постсоветское пространство и не сильно желает выходить куда-то наружу, причем без всяких внешних ограничений.
Поэтому, если вдруг самые страшные прогнозы свидетелей секты Чебурнета сбудутся, то большинство пользователей интернет просто не заметят разницы.
Еще одна любимая пугалка в среде IT-братии. Но многие, наверное, удивятся, потому что Чебурнет давно существует и не один.
Что такое сеть интернет? Это всемирное средство коммуникации и т.д. и т.п. Но давайте спустимся с небес на землю и посмотрим на это все с позиции рядового пользователя.
Возьмем условного дядю Васю, инженера на заводе и его жену тетю Клаву, учителя начальных классов. Ну и их детей, Ваню и Машу, класса так 5-го и 10-го.
От IT они крайне далеки и весь их интерес в интернете сводится к получению развлекательного контента и общению к себе подобными.
В языках наше условное семейство не подковано и весь их интерес лежит в зоне RU, которая понятна, ментально близка и позволяет удовлетворить все насущные потребности.
Общий ареал зоны RU – это постсоветское пространство, где русский язык является языком межнационального общения и является неким объединяющим и цементирующим фактором.
Да, есть еще национальные зоны, но они достаточно узки и не могут покрыть все запросы простого пользователя, поэтому так или иначе любой житель постсоветского пространства так или иначе окажется в зоне RU.
Но ведь есть еще и международный интернет… Но что там ловить? В первую очередь мешает языковой барьер, во вторую – там нет ничего интересного простому пользователю. Разве что музыка, кино (обязательно с переводом) и футбол.
Но это все доступно и в зоне RU. Точнее было доступно. Но сей контент сделался недоступным не по политическим мотивам и Товарищ Майор здесь не причем, большинство блокировок возникли по требованиям правообладателей, которые преследовали свои коммерческие интересы.
В ответ народ пошел активно осваивать торренты и VPN, но не потому, что злые чекисты задушили свободу самовыражения, чихать им на это, а потому что правообладатели лишили дядю Васю и тетю Клаву бесплатных зрелищ.
По сути, зона RU – это исторически сложившийся Чебурнет. Он не интересен западному пользователю, так как он вообще здесь ничего прочитать не может (другой алфавит, как никак), а западный сегмент также не интересен пользователю русскоязычному. Потому что языковой барьер.
И тот же Ютуб или Инстаграмм интересен не потому, что кто-то хочет вырваться из Чебурнета на свободу, а потому что в Чебурнете нет им доступных аналогов.
Если брать те же соцсети, то VK/ОК закрыли практически всю нишу, и никто не страдает от отсутствия той же Мордокниги (Facebook).
Стоит только обеспечить качественное импортозамещение этих сервисов и в ту сторону больше никто не посмотрит. А зачем, когда есть тоже самое, но на русском языке.
В итоге за условный «железный занавес» будут бегать только за варезом и контентом 18+, хотя насчет последнего не уверен, так как основной его черно-оранжевый поставщик действует в России вполне легально, надо только подтвердить возраст через VK.
Второй сложившийся Чебурнет – это китайский сегмент сети. Да, он огорожен Великим Китайским Файрволлом, но, по сути, у рядового китайца нет никакой необходимости выходить за периметр.
Если наша культура достаточно близка западной, то китайская крайне далека и непонятна нам, как и наша культура им.
В тоже время в китайском сегменте есть все: свои соцсети, мессенджеры, платежные системы, видеохостинги и т.д. и т.п., в результате чего среднестатистический китаец даже не думает о том, что ему запрещено подключаться куда-то на западные ресурсы.
Собственно, а вы сильно пострадаете, если вам вдруг закроют доступ к китайским ресурсам?
Поэтому китайский Чебурнет — это вполне сложившаяся вещь в себе, пользователи которой вполне довольствуются внутренними ресурсами и не особо стремятся выйти наружу.
Равно как и русский Чебурнет включает в себя постсоветское пространство и не сильно желает выходить куда-то наружу, причем без всяких внешних ограничений.
Поэтому, если вдруг самые страшные прогнозы свидетелей секты Чебурнета сбудутся, то большинство пользователей интернет просто не заметят разницы.
👍60🤮32🤡9💯7🤔4
1С, Linux и виртуализация
Буквально на днях коллега попросил рассказать нас как мы работаем с на платформе виртуализации Proxmox.
В основе нашей инфраструктуры лежит Linux и контейнерная виртуализация LXC, что позволяет приложениям работать без потерь производительности, как будто они работают непосредственно на железе.
Центром всей этой системы является сервер 1С:Предприятия, который лицензируется отдельно на каждый запущенный экземпляр, стоимость лицензии составляет 95 000 руб., что не располагает к маневрам по разделению серверов и т.п.
Но не стоит сбрасывать со счетом Сервер-Мини за 15 500 руб. разрешающий пять сеансов к расположенным на нем информационным базам. Его можно использовать для вынесения на него ресурсоемких баз с малым количеством пользователей (например, ЗуП) или служебных баз для выполнения разного рода обменов и прочего регламента.
В любом случае сервер 1С – это центр вашей инфраструктуры и ему следует уделить особое внимание. Начнем с лицензирования, при нахождении сервера 1С в контейнере он учитывает ядра и сетевые карты контейнера, но диски и объем оперативной памяти берет от хоста.
При изменении количества ядер сервер посчитает что вы заменили процессор и попросит повторную активацию лицензии. При этом изменять объем памяти и перемещать машину между хранилищами вы можете без проблем, главное, чтобы параметры хоста при этом не изменились.
Сколько места выделить под контейнер? Много не нужно, там будет храниться серверный кеш, индексы и журналы, не считая временных файлов. Все это можно посмотреть на живой базе. Если не знаете – 1,5 – 2 размера ИБ, в случае чего всегда сможете откорректировать.
Следующий важный компонент – СУБД, мы используем бесплатную версию PostgreSQL от компании PostgresPRO. Также можно использовать сборку от 1С, но версия от PostgresPRO имеет репозиторий и получает обновления, что является более предпочтительным.
Ведущие специалисты по Postgres для 1С, такие как Антон Дорошкевич, рекомендуют выделять под одну базу один контейнер. И в этом есть смысл.
Во-первых, вы можете выделить каждой базе собственный набор ресурсов, за которые ей не придется конкурировать. Во-вторых, вы можете настроить сервер СУБД с учетом реальных потребностей конкретной базы, а не искать компромисс между различными базами с различным характером использования.
Как минимум разнесите на разные сервера СУБД различные конфигурации 1С, Бухгалтерию на один, Зарплату на второй, Торговлю на третий.
В этих целях следует создать готовый шаблон контейнера с уже установленной СУДБ и быстро разворачивать экземпляры по необходимости.
Основной тип подключения к базам – тонкий клиент, он отлично работает не только в локальной сети, но и из удаленных расположений через VPN. Забудьте про терминалы как страшный сон, в этом сценарии они не дают никаких преимуществ, только лишнюю головную боль.
Третий компонент – веб-сервер для публикации баз или веб-сервисов. Это дополнительный способ доступа и разворачивается он также по принципу: одна база – один веб-сервер, веб-сервисы публикуются отдельно.
Для него точно также имеет смысл создать готовый шаблон и разворачивать по необходимости. Это позволяет также использовать одноразовые веб-сервера, например, чтобы предоставить доступ внешнему пользователю (скажем, аудитору). После чего такой контейнер просто удаляется.
Что из этой схемы бекапится? В первую очередь сервер СУБД, частота выбирается исходя из допустимой потери информации. Потеря СУБД – потеря всех расположенных на них информационных баз 1С.
Сервер 1С не хранит никакой пользовательской информации и его потеря не так критична, бекапим сугубо в целях быстрого восстановления работы системы при авариях.
Веб-сервера можно не бекапить совсем, развернуть новый сервер из шаблона и заново опубликовать базу скорее всего будет быстрее, чем восстановление резервной копии.
Исключение – сервера работающий наружу, с сертификатами и прочими настройками безопасности. Опять же единственная цель бекапа – быстрое развертывание.
Буквально на днях коллега попросил рассказать нас как мы работаем с на платформе виртуализации Proxmox.
В основе нашей инфраструктуры лежит Linux и контейнерная виртуализация LXC, что позволяет приложениям работать без потерь производительности, как будто они работают непосредственно на железе.
Центром всей этой системы является сервер 1С:Предприятия, который лицензируется отдельно на каждый запущенный экземпляр, стоимость лицензии составляет 95 000 руб., что не располагает к маневрам по разделению серверов и т.п.
Но не стоит сбрасывать со счетом Сервер-Мини за 15 500 руб. разрешающий пять сеансов к расположенным на нем информационным базам. Его можно использовать для вынесения на него ресурсоемких баз с малым количеством пользователей (например, ЗуП) или служебных баз для выполнения разного рода обменов и прочего регламента.
В любом случае сервер 1С – это центр вашей инфраструктуры и ему следует уделить особое внимание. Начнем с лицензирования, при нахождении сервера 1С в контейнере он учитывает ядра и сетевые карты контейнера, но диски и объем оперативной памяти берет от хоста.
При изменении количества ядер сервер посчитает что вы заменили процессор и попросит повторную активацию лицензии. При этом изменять объем памяти и перемещать машину между хранилищами вы можете без проблем, главное, чтобы параметры хоста при этом не изменились.
Сколько места выделить под контейнер? Много не нужно, там будет храниться серверный кеш, индексы и журналы, не считая временных файлов. Все это можно посмотреть на живой базе. Если не знаете – 1,5 – 2 размера ИБ, в случае чего всегда сможете откорректировать.
Следующий важный компонент – СУБД, мы используем бесплатную версию PostgreSQL от компании PostgresPRO. Также можно использовать сборку от 1С, но версия от PostgresPRO имеет репозиторий и получает обновления, что является более предпочтительным.
Ведущие специалисты по Postgres для 1С, такие как Антон Дорошкевич, рекомендуют выделять под одну базу один контейнер. И в этом есть смысл.
Во-первых, вы можете выделить каждой базе собственный набор ресурсов, за которые ей не придется конкурировать. Во-вторых, вы можете настроить сервер СУБД с учетом реальных потребностей конкретной базы, а не искать компромисс между различными базами с различным характером использования.
Как минимум разнесите на разные сервера СУБД различные конфигурации 1С, Бухгалтерию на один, Зарплату на второй, Торговлю на третий.
В этих целях следует создать готовый шаблон контейнера с уже установленной СУДБ и быстро разворачивать экземпляры по необходимости.
Основной тип подключения к базам – тонкий клиент, он отлично работает не только в локальной сети, но и из удаленных расположений через VPN. Забудьте про терминалы как страшный сон, в этом сценарии они не дают никаких преимуществ, только лишнюю головную боль.
Третий компонент – веб-сервер для публикации баз или веб-сервисов. Это дополнительный способ доступа и разворачивается он также по принципу: одна база – один веб-сервер, веб-сервисы публикуются отдельно.
Для него точно также имеет смысл создать готовый шаблон и разворачивать по необходимости. Это позволяет также использовать одноразовые веб-сервера, например, чтобы предоставить доступ внешнему пользователю (скажем, аудитору). После чего такой контейнер просто удаляется.
Что из этой схемы бекапится? В первую очередь сервер СУБД, частота выбирается исходя из допустимой потери информации. Потеря СУБД – потеря всех расположенных на них информационных баз 1С.
Сервер 1С не хранит никакой пользовательской информации и его потеря не так критична, бекапим сугубо в целях быстрого восстановления работы системы при авариях.
Веб-сервера можно не бекапить совсем, развернуть новый сервер из шаблона и заново опубликовать базу скорее всего будет быстрее, чем восстановление резервной копии.
Исключение – сервера работающий наружу, с сертификатами и прочими настройками безопасности. Опять же единственная цель бекапа – быстрое развертывание.
👍88🤝1
Еще раз про нелицензионное ПО и ответственность
Читал сегодня обсуждения на эту тему в соседнем канале и просто удивлялся тому количеству откровенной дичи, которую пишут коллеги. Налицо жуткая юридическая безграмотность. Поэтому сегодня будет воскресный ликбез. Местами скучный, так как будем обращаться и цитировать законы.
Начнем с самой сути, того, к чему вся эта нехорошая деятельность приводит:
УК РФ Статья 146. Нарушение авторских и смежных прав
2. Незаконное использование объектов авторского права или смежных прав, а равно приобретение, хранение, перевозка контрафактных экземпляров произведений или фонограмм в целях сбыта, совершенные в крупном размере,
наказываются штрафом в размере до двухсот тысяч рублей … либо исправительными работами на срок до двух лет, либо лишением свободы на тот же срок.
3. Деяния, предусмотренные частью второй настоящей статьи, если они совершены:
б) группой лиц по предварительному сговору или организованной группой;
в) в особо крупном размере;
г) лицом с использованием своего служебного положения,
наказываются принудительными работами на срок до пяти лет либо лишением свободы на срок до шести лет…
Примечание. Деяния, предусмотренные настоящей статьей, признаются совершенными в крупном размере, если стоимость экземпляров произведений превышают сто тысяч рублей, а в особо крупном размере - один миллион рублей.
С учетом современных цен на ПО крупный размер по данной статье набирается достаточно легко и непринужденно.
А если учесть характер рабочей деятельности администратора, то тут свободно вырисовываются п.3 б и г, т.е. уже до 6 лет, а это уже тяжкое преступление со всеми вытекающими в последствии.
На этом фоне особенно умиляют заявления отдельных коллег, мол я письменно уведомил шефа, что ПО нелицензионное и теперь отдуваться ему. Как бы не так, по сути, товарищ только что поднял с пола более тяжкую часть статьи: группой лиц по предварительному сговору.
А в обвинительном заключении напишут, что обвиняемый, осознавая преступный характер своего замысла… И ключевой фразой тут будет именно «осознавая преступный характер».
Идем дальше, следующий миф: правообладатель ушел из России, претензии предъявлять некому.
Открываем Уголовно-процессуальный кодекс и читаем:
Статья 20. Виды уголовного преследования
Если коротко, то все уголовные дела делятся на: дела частного порядка, частно-публичного и публичного.
Уголовные дела частного и частно-публичного обвинения возбуждаются не иначе как по заявлению потерпевшего. Для возбуждения уголовного дела публичного обвинения достаточно наличия состава преступления.
Если брать нашу 146 УК РФ, то к и частно-публичному обвинению относится только ее первая часть:
Присвоение авторства (плагиат), если это деяние причинило крупный ущерб автору или иному правообладателю,
Остальные части данной статьи являются делами публичного обвинения.
И снова УПК:
Статья 140. Поводы и основание для возбуждения уголовного дела
1. Поводами для возбуждения уголовного дела служат:
3) сообщение о совершенном или готовящемся преступлении, полученное из иных источников;
Т.е. любой опер может на основании имеющихся у него «оперативных данных» в рамках осуществления ОРД инициировать проверку предприятия, на основании которой будет возбуждено уголовное дело.
При этом следует помнить, что ответственность наступает не только за использование, но и за хранение нелицензионных экземпляров, так как согласно
ГК РФ Статья 1270. Исключительное право на произведение
2. Использованием произведения независимо от того, совершаются ли соответствующие действия в целях извлечения прибыли или без такой цели, считается, в частности:
1) воспроизведение произведения… При этом запись произведения на электронном носителе, в том числе запись в память ЭВМ, также считается воспроизведением.
Как видим, все достаточно серьезно и пропетлять в случае чего не получится. Поэтому будьте благоразумны и трезво оценивайте риски, а в случае чего крайне желательно проконсультироваться с адвокатом, если, конечно, нет желания поднять статью с пола.
Читал сегодня обсуждения на эту тему в соседнем канале и просто удивлялся тому количеству откровенной дичи, которую пишут коллеги. Налицо жуткая юридическая безграмотность. Поэтому сегодня будет воскресный ликбез. Местами скучный, так как будем обращаться и цитировать законы.
Начнем с самой сути, того, к чему вся эта нехорошая деятельность приводит:
УК РФ Статья 146. Нарушение авторских и смежных прав
2. Незаконное использование объектов авторского права или смежных прав, а равно приобретение, хранение, перевозка контрафактных экземпляров произведений или фонограмм в целях сбыта, совершенные в крупном размере,
наказываются штрафом в размере до двухсот тысяч рублей … либо исправительными работами на срок до двух лет, либо лишением свободы на тот же срок.
3. Деяния, предусмотренные частью второй настоящей статьи, если они совершены:
б) группой лиц по предварительному сговору или организованной группой;
в) в особо крупном размере;
г) лицом с использованием своего служебного положения,
наказываются принудительными работами на срок до пяти лет либо лишением свободы на срок до шести лет…
Примечание. Деяния, предусмотренные настоящей статьей, признаются совершенными в крупном размере, если стоимость экземпляров произведений превышают сто тысяч рублей, а в особо крупном размере - один миллион рублей.
С учетом современных цен на ПО крупный размер по данной статье набирается достаточно легко и непринужденно.
А если учесть характер рабочей деятельности администратора, то тут свободно вырисовываются п.3 б и г, т.е. уже до 6 лет, а это уже тяжкое преступление со всеми вытекающими в последствии.
На этом фоне особенно умиляют заявления отдельных коллег, мол я письменно уведомил шефа, что ПО нелицензионное и теперь отдуваться ему. Как бы не так, по сути, товарищ только что поднял с пола более тяжкую часть статьи: группой лиц по предварительному сговору.
А в обвинительном заключении напишут, что обвиняемый, осознавая преступный характер своего замысла… И ключевой фразой тут будет именно «осознавая преступный характер».
Идем дальше, следующий миф: правообладатель ушел из России, претензии предъявлять некому.
Открываем Уголовно-процессуальный кодекс и читаем:
Статья 20. Виды уголовного преследования
Если коротко, то все уголовные дела делятся на: дела частного порядка, частно-публичного и публичного.
Уголовные дела частного и частно-публичного обвинения возбуждаются не иначе как по заявлению потерпевшего. Для возбуждения уголовного дела публичного обвинения достаточно наличия состава преступления.
Если брать нашу 146 УК РФ, то к и частно-публичному обвинению относится только ее первая часть:
Присвоение авторства (плагиат), если это деяние причинило крупный ущерб автору или иному правообладателю,
Остальные части данной статьи являются делами публичного обвинения.
И снова УПК:
Статья 140. Поводы и основание для возбуждения уголовного дела
1. Поводами для возбуждения уголовного дела служат:
3) сообщение о совершенном или готовящемся преступлении, полученное из иных источников;
Т.е. любой опер может на основании имеющихся у него «оперативных данных» в рамках осуществления ОРД инициировать проверку предприятия, на основании которой будет возбуждено уголовное дело.
При этом следует помнить, что ответственность наступает не только за использование, но и за хранение нелицензионных экземпляров, так как согласно
ГК РФ Статья 1270. Исключительное право на произведение
2. Использованием произведения независимо от того, совершаются ли соответствующие действия в целях извлечения прибыли или без такой цели, считается, в частности:
1) воспроизведение произведения… При этом запись произведения на электронном носителе, в том числе запись в память ЭВМ, также считается воспроизведением.
Как видим, все достаточно серьезно и пропетлять в случае чего не получится. Поэтому будьте благоразумны и трезво оценивайте риски, а в случае чего крайне желательно проконсультироваться с адвокатом, если, конечно, нет желания поднять статью с пола.
👍44🤡6❤1
Я и нелицензионное ПО (на работе)
Anonymous Poll
19%
Категорически не использую
21%
Может где-то что-то и есть
21%
Местами использую
10%
Преимущественно использую
9%
Я старый пират...
3%
Использовал, больше не хочу...
1%
Небо в клеточку, друзья в полосочку...
15%
Ничего не понятно, но очень интересно
🍌3🫡1
Сервис лицензирования 1С – плюсы и минусы
В обсуждениях многие упоминали и планировали развертывание сервера лицензирования 1С, поэтому мы решили отдельным материалом осветить все достоинства и недостатки такого решения.
Начнем с того, что правильно такое решение называется именно Сервис лицензирования, а не Сервер лицензирования, но второй вариант давно прижился и его также можно использовать, только следует понимать, что речь идет об одном и том же.
Сервис лицензирования представляет отдельную серверную инсталляцию в кластере серверов, которая содержит только одноименную службу (Назначение функциональности в терминах 1С) и не требует для запуска отдельной серверной лицензии.
Сервис лицензирования может выдавать серверные и клиентские многопользовательские лицензии, последние всегда выдаются только на сеанс, вне зависимости от режима подключения клиента.
Минимальные требования к сервису лицензирования – два ядра и 4 ГБ оперативной памяти, хотя последнее требование на наш взгляд несколько завышено.
Также следует помнить, что сервис лицензирования не работает с HASP-ключами и не может привязать лицензию к такому ключу.
Еще один важный момент – сервис лицензирования не работает с клиентскими подключениями, а выдает лицензии только серверу (серверам), который в свою очередь может выдать ее клиенту.
Версия платформы и разрядность сервиса лицензирования должна совпадать с версией платформы или разрядностью рабочих серверов.
При запуске на одном узле нескольких экземпляров сервера 1С:Предприятие при получении лицензии из сервиса лицензирования вам потребуется отдельная лицензия на каждый запущенный экземпляр.
При этом на сервисе лицензирования также потребуется установить и запустить на разных портах несколько экземпляров сервера 1С.
При работе терминального сервера лицензия будет выдаваться не на терминальный сеанс, допускающий неограниченное число сеансов 1С:Предприятие, а на каждый сеанс 1С.
Как видим, особенностей у сервиса лицензирования хватает и подходить к его развертыванию следует взвешенно, проанализировав все плюсы и минусы относительно собственной ситуации.
Так, например, в однозначные плюсы можно записать возможность изменять параметры компьютера или виртуальной машины сервера 1С без необходимости повторной активации лицензии.
А в столь же однозначные минусы то, что теперь два экземпляра сервера на одном узле потребуют две серверных лицензии вместо одной.
Что касается клиентских лицензий, то здесь ситуация не меняется, за исключением терминального сервера.
Но есть и плюс, при наличии нескольких серверов в кластере они могут использовать для выдачи клиентам общий пул лицензий, что исключает ситуации, когда на сервере А лицензии закончились, а на сервере Б их еще с избытком.
Ну и не забываем о том, что наличие сервиса лицензирования совсем не означает необходимости переноса всех лицензий на него. Вы можете перенести только те лицензии, которые считаете нужным, а другие оставить непосредственно на серверах.
Если сильно упростить ситуацию, то поиск лицензии будет происходить следующим образом: сначала на клиенте, потом на сервере, потом на сервисе лицензирования.
В заключение хочется сказать, что сервис лицензирования достаточно удобная штука, но со своими особенностями и перед его использованием следует хорошо все продумать, чтобы не оказалось, что при эксплуатации минусы вдруг перевесят плюсы.
В обсуждениях многие упоминали и планировали развертывание сервера лицензирования 1С, поэтому мы решили отдельным материалом осветить все достоинства и недостатки такого решения.
Начнем с того, что правильно такое решение называется именно Сервис лицензирования, а не Сервер лицензирования, но второй вариант давно прижился и его также можно использовать, только следует понимать, что речь идет об одном и том же.
Сервис лицензирования представляет отдельную серверную инсталляцию в кластере серверов, которая содержит только одноименную службу (Назначение функциональности в терминах 1С) и не требует для запуска отдельной серверной лицензии.
Сервис лицензирования может выдавать серверные и клиентские многопользовательские лицензии, последние всегда выдаются только на сеанс, вне зависимости от режима подключения клиента.
Минимальные требования к сервису лицензирования – два ядра и 4 ГБ оперативной памяти, хотя последнее требование на наш взгляд несколько завышено.
Также следует помнить, что сервис лицензирования не работает с HASP-ключами и не может привязать лицензию к такому ключу.
Еще один важный момент – сервис лицензирования не работает с клиентскими подключениями, а выдает лицензии только серверу (серверам), который в свою очередь может выдать ее клиенту.
Версия платформы и разрядность сервиса лицензирования должна совпадать с версией платформы или разрядностью рабочих серверов.
При запуске на одном узле нескольких экземпляров сервера 1С:Предприятие при получении лицензии из сервиса лицензирования вам потребуется отдельная лицензия на каждый запущенный экземпляр.
При этом на сервисе лицензирования также потребуется установить и запустить на разных портах несколько экземпляров сервера 1С.
При работе терминального сервера лицензия будет выдаваться не на терминальный сеанс, допускающий неограниченное число сеансов 1С:Предприятие, а на каждый сеанс 1С.
Как видим, особенностей у сервиса лицензирования хватает и подходить к его развертыванию следует взвешенно, проанализировав все плюсы и минусы относительно собственной ситуации.
Так, например, в однозначные плюсы можно записать возможность изменять параметры компьютера или виртуальной машины сервера 1С без необходимости повторной активации лицензии.
А в столь же однозначные минусы то, что теперь два экземпляра сервера на одном узле потребуют две серверных лицензии вместо одной.
Что касается клиентских лицензий, то здесь ситуация не меняется, за исключением терминального сервера.
Но есть и плюс, при наличии нескольких серверов в кластере они могут использовать для выдачи клиентам общий пул лицензий, что исключает ситуации, когда на сервере А лицензии закончились, а на сервере Б их еще с избытком.
Ну и не забываем о том, что наличие сервиса лицензирования совсем не означает необходимости переноса всех лицензий на него. Вы можете перенести только те лицензии, которые считаете нужным, а другие оставить непосредственно на серверах.
Если сильно упростить ситуацию, то поиск лицензии будет происходить следующим образом: сначала на клиенте, потом на сервере, потом на сервисе лицензирования.
В заключение хочется сказать, что сервис лицензирования достаточно удобная штука, но со своими особенностями и перед его использованием следует хорошо все продумать, чтобы не оказалось, что при эксплуатации минусы вдруг перевесят плюсы.
👍33🔥1🤯1💯1
Присоединяйтесь к нашему бесплатному курсу и начните увлекательное путешествие в мир Java!
Изучайте основы, создавайте программы, разбирайтесь с методами и анализируйте ошибки в коде. Практика, упражнения и проверочные тесты помогут вам освоить навыки программирования.
🎓 Чему вы научитесь:
— Создавать программы с использованием основных конструкций языка.
— Разделять код на методы для повторного использования.
— Анализировать ошибки в коде с использованием отладочной печати.
💼 Включено в курс:
29 уроков (видео и/или текст), 35 упражнений в тренажере, 95 проверочных тестов + дополнительные материалы.
Вы с нами?😉
Изучайте основы, создавайте программы, разбирайтесь с методами и анализируйте ошибки в коде. Практика, упражнения и проверочные тесты помогут вам освоить навыки программирования.
🎓 Чему вы научитесь:
— Создавать программы с использованием основных конструкций языка.
— Разделять код на методы для повторного использования.
— Анализировать ошибки в коде с использованием отладочной печати.
💼 Включено в курс:
29 уроков (видео и/или текст), 35 упражнений в тренажере, 95 проверочных тестов + дополнительные материалы.
Вы с нами?😉
Media is too big
VIEW IN TELEGRAM
Какой Linux самый игровой?
Вы удивитесь, но вполне возможно, что скоро на этот вопрос будут отвечать: Astra Linux.
А все благодаря Денису Давыдову и его единомышленникам, которые развили поистине бурную деятельность по портированию на Linux различных игр. В первую очередь классических, но уже сейчас можно поиграть в Doom 3 или Quake 4.
Несмотря на то, что многие игры работают через Wine никаких проблем с их установкой и запуском нет. Каждая игра – отдельный DEB пакет. Установил и играй.
Сейчас игры вынесены на отдельный портал https://playonastra.ru и их общее количество составляет 60 шт., но как сказал нам Денис всего упакованных игр уже около ста и они будут продолжать выкладываться.
Очень радует, что кроме Дениса к играм приложили руку и единомышленники, таким образом сформировав отдельное сообщество, что можно только приветствовать, так как в одиночку долго тянуть проект, даже при всем энтузиазме сложно.
Ну а мы пожелаем удачи, а заодно и во что-нибудь поиграем!
Вы удивитесь, но вполне возможно, что скоро на этот вопрос будут отвечать: Astra Linux.
А все благодаря Денису Давыдову и его единомышленникам, которые развили поистине бурную деятельность по портированию на Linux различных игр. В первую очередь классических, но уже сейчас можно поиграть в Doom 3 или Quake 4.
Несмотря на то, что многие игры работают через Wine никаких проблем с их установкой и запуском нет. Каждая игра – отдельный DEB пакет. Установил и играй.
Сейчас игры вынесены на отдельный портал https://playonastra.ru и их общее количество составляет 60 шт., но как сказал нам Денис всего упакованных игр уже около ста и они будут продолжать выкладываться.
Очень радует, что кроме Дениса к играм приложили руку и единомышленники, таким образом сформировав отдельное сообщество, что можно только приветствовать, так как в одиночку долго тянуть проект, даже при всем энтузиазме сложно.
Ну а мы пожелаем удачи, а заодно и во что-нибудь поиграем!
👍46🤡6🔥3🤔3
Материальная ответственность системного администратора
Продолжаем юридическую серию, направленную на повышение правовой грамотности коллег. Посильную помощь в составлении данного материала мне оказал мой хороший друг – практикующий адвокат.
Начнем с материальной ответственности. Несет ли ее системный администратор? Безусловно несет. Обратимся к Трудовому кодексу:
Статья 238. Материальная ответственность работника за ущерб, причиненный работодателю
Работник обязан возместить работодателю причиненный ему прямой действительный ущерб. Неполученные доходы (упущенная выгода) взысканию с работника не подлежат.
Под прямым действительным ущербом понимается реальное уменьшение наличного имущества работодателя или ухудшение состояния указанного, а также необходимость для работодателя произвести затраты либо излишние выплаты на приобретение, восстановление имущества.
Есть ли случаи, когда администратор может быть освобожден от материальной ответственности? Есть.
Статья 239. Обстоятельства, исключающие материальную ответственность работника
Материальная ответственность работника исключается в случаях возникновения ущерба вследствие непреодолимой силы, нормального хозяйственного риска либо неисполнения работодателем обязанности по обеспечению надлежащих условий для хранения имущества.
Самое интересное в этом пункте - нормальный хозяйственный риск. Что это такое? Читаем:
К нормальному хозяйственному риску могут быть отнесены действия работника, соответствующие современным знаниям и опыту, когда поставленная цель не могла быть достигнута иначе, работник надлежащим образом выполнил возложенные на него должностные обязанности, проявил определенную степень заботливости и осмотрительности, принял меры для предотвращения ущерба, и объектом риска являлись материальные ценности, а не жизнь и здоровье людей.
Т.е. если администратор действовал согласно установленной инструкции, руководству по эксплуатации ПО и т.д. и т.п., то даже если такие действия повлекли ущерб материальной ответственности сотрудник не подлежит.
Следующий тонкий момент – полная материальная ответственность.
Статья 242. Полная материальная ответственность работника
Полная материальная ответственность работника состоит в его обязанности возмещать причиненный работодателю прямой действительный ущерб в полном размере.
Так, секунду, а что есть не полная? Да, есть:
Статья 241. Пределы материальной ответственности работника
За причиненный ущерб работник несет материальную ответственность в пределах своего среднего месячного заработка.
А вот здесь становится действительно интересно, но на помощь нам приходит:
Постановление Минтруда РФ от 31.12.2002 N 85 «Об утверждении перечней должностей и работ, замещаемых или выполняемых работниками, с которыми работодатель может заключать письменные договоры о полной индивидуальной или коллективной ответственности»
Должности системного администратора там нет. Поэтому любая попытка внести такие условия в трудовой договор или иные соглашения с сисадмином являются незаконными.
Но не стоит расслабляться раньше времени:
Статья 243. Случаи полной материальной ответственности
Материальная ответственность в полном размере причиненного ущерба возлагается на работника в следующих случаях:
3) умышленного причинения ущерба;
4) причинения ущерба в состоянии алкогольного, наркотического или иного токсического опьянения;
5) причинения ущерба в результате преступных действий работника, установленных приговором суда;
6) причинения ущерба в результате административного правонарушения, если таковое установлено соответствующим государственным органом;
8) причинения ущерба не при исполнении работником трудовых обязанностей.
Как видим, из правила есть исключения, которые отлично покрывают ситуации «работодатель козел, сменю пароли, поставлю тайм-бомбу, сделаю еще какую-нибудь пакость».
Поэтому будьте благоразумны, не давайте нарушать свои права, но в тоже время не допускайте противоправных действий по отношению к работодателю. Надеемся, данный материал будет вам полезен.
Продолжаем юридическую серию, направленную на повышение правовой грамотности коллег. Посильную помощь в составлении данного материала мне оказал мой хороший друг – практикующий адвокат.
Начнем с материальной ответственности. Несет ли ее системный администратор? Безусловно несет. Обратимся к Трудовому кодексу:
Статья 238. Материальная ответственность работника за ущерб, причиненный работодателю
Работник обязан возместить работодателю причиненный ему прямой действительный ущерб. Неполученные доходы (упущенная выгода) взысканию с работника не подлежат.
Под прямым действительным ущербом понимается реальное уменьшение наличного имущества работодателя или ухудшение состояния указанного, а также необходимость для работодателя произвести затраты либо излишние выплаты на приобретение, восстановление имущества.
Есть ли случаи, когда администратор может быть освобожден от материальной ответственности? Есть.
Статья 239. Обстоятельства, исключающие материальную ответственность работника
Материальная ответственность работника исключается в случаях возникновения ущерба вследствие непреодолимой силы, нормального хозяйственного риска либо неисполнения работодателем обязанности по обеспечению надлежащих условий для хранения имущества.
Самое интересное в этом пункте - нормальный хозяйственный риск. Что это такое? Читаем:
К нормальному хозяйственному риску могут быть отнесены действия работника, соответствующие современным знаниям и опыту, когда поставленная цель не могла быть достигнута иначе, работник надлежащим образом выполнил возложенные на него должностные обязанности, проявил определенную степень заботливости и осмотрительности, принял меры для предотвращения ущерба, и объектом риска являлись материальные ценности, а не жизнь и здоровье людей.
Т.е. если администратор действовал согласно установленной инструкции, руководству по эксплуатации ПО и т.д. и т.п., то даже если такие действия повлекли ущерб материальной ответственности сотрудник не подлежит.
Следующий тонкий момент – полная материальная ответственность.
Статья 242. Полная материальная ответственность работника
Полная материальная ответственность работника состоит в его обязанности возмещать причиненный работодателю прямой действительный ущерб в полном размере.
Так, секунду, а что есть не полная? Да, есть:
Статья 241. Пределы материальной ответственности работника
За причиненный ущерб работник несет материальную ответственность в пределах своего среднего месячного заработка.
А вот здесь становится действительно интересно, но на помощь нам приходит:
Постановление Минтруда РФ от 31.12.2002 N 85 «Об утверждении перечней должностей и работ, замещаемых или выполняемых работниками, с которыми работодатель может заключать письменные договоры о полной индивидуальной или коллективной ответственности»
Должности системного администратора там нет. Поэтому любая попытка внести такие условия в трудовой договор или иные соглашения с сисадмином являются незаконными.
Но не стоит расслабляться раньше времени:
Статья 243. Случаи полной материальной ответственности
Материальная ответственность в полном размере причиненного ущерба возлагается на работника в следующих случаях:
3) умышленного причинения ущерба;
4) причинения ущерба в состоянии алкогольного, наркотического или иного токсического опьянения;
5) причинения ущерба в результате преступных действий работника, установленных приговором суда;
6) причинения ущерба в результате административного правонарушения, если таковое установлено соответствующим государственным органом;
8) причинения ущерба не при исполнении работником трудовых обязанностей.
Как видим, из правила есть исключения, которые отлично покрывают ситуации «работодатель козел, сменю пароли, поставлю тайм-бомбу, сделаю еще какую-нибудь пакость».
Поэтому будьте благоразумны, не давайте нарушать свои права, но в тоже время не допускайте противоправных действий по отношению к работодателю. Надеемся, данный материал будет вам полезен.
👍35🤔3🤮3❤1🤝1
Как построить успешный бизнес на отраслевых конфигурациях 1С
1. Позиционировать решение как проверенное и отработанное
2. Не показывать весь функционал при демонстрации
3. Продать
4. Профит
👆Бонусом к этому:
1. Забыть положить документацию по настройке более половины функционала
2. Остальную документацию надо просить в техподдержке
3. Техподдержка не общается с вами пока не оплатите сопровождение
4. Та документация, что положили устарела и настройки теперь в другом месте.
5. Ни#$% не работает! 🤬🤬🤬
🎄При помощи молотка, кувалды и такой-то матери, с подсказками поддержки это наконец взлетает. Но…
1. Куча косяков где только можно и нельзя.
2. Половина того, что работает, работает криво
3. Вместо сделать как надо делаем как-нибудь и просто молимся чтобы оно хоть так работало. 🙏
4. Через 15 минут эксплуатации пользователи ломают систему, просто выполняя самые обычные действия в рамках автоматизированного рабочего места. 👻👻👻
5. Все документируется и отправляется вместе с базами в поддержку.
😢 После этого:
1. Поддержка начинает сутками морозиться
2. По телефону тоже внезапно все заняты
3. Линия контроля качества может только посочувствовать
4. Доктор, меня все игнорируют!!! 😤😤😤
Подключаем все связи и выходим на разработчиков через дистрибьютора.
Поздно вечером получаем письмо следующего содержания:
Информацию передали разработчику.
В связи с выходом новых релизов, анализ ошибок возможен лишь после 01.03.24.
Предварительно по обновлению статусов заказов, что-то с периодичностью изменений, система сообщает, что пользователь изменил заказ во время обмена.
🙀🙀🙀 Кошка бросила котят, пусть скребутся как хотят.
Главный вопрос – как работать не освещен, остальные 9 поднятых вопросов меньшей критичности оставлены без ответа.
👍 Но релизы пекутся, планы по продажам выполняются, бизнес цветет и пахнет…
1. Позиционировать решение как проверенное и отработанное
2. Не показывать весь функционал при демонстрации
3. Продать
4. Профит
👆Бонусом к этому:
1. Забыть положить документацию по настройке более половины функционала
2. Остальную документацию надо просить в техподдержке
3. Техподдержка не общается с вами пока не оплатите сопровождение
4. Та документация, что положили устарела и настройки теперь в другом месте.
5. Ни#$% не работает! 🤬🤬🤬
🎄При помощи молотка, кувалды и такой-то матери, с подсказками поддержки это наконец взлетает. Но…
1. Куча косяков где только можно и нельзя.
2. Половина того, что работает, работает криво
3. Вместо сделать как надо делаем как-нибудь и просто молимся чтобы оно хоть так работало. 🙏
4. Через 15 минут эксплуатации пользователи ломают систему, просто выполняя самые обычные действия в рамках автоматизированного рабочего места. 👻👻👻
5. Все документируется и отправляется вместе с базами в поддержку.
😢 После этого:
1. Поддержка начинает сутками морозиться
2. По телефону тоже внезапно все заняты
3. Линия контроля качества может только посочувствовать
4. Доктор, меня все игнорируют!!! 😤😤😤
Подключаем все связи и выходим на разработчиков через дистрибьютора.
Поздно вечером получаем письмо следующего содержания:
Информацию передали разработчику.
В связи с выходом новых релизов, анализ ошибок возможен лишь после 01.03.24.
Предварительно по обновлению статусов заказов, что-то с периодичностью изменений, система сообщает, что пользователь изменил заказ во время обмена.
🙀🙀🙀 Кошка бросила котят, пусть скребутся как хотят.
Главный вопрос – как работать не освещен, остальные 9 поднятых вопросов меньшей критичности оставлены без ответа.
👍 Но релизы пекутся, планы по продажам выполняются, бизнес цветет и пахнет…
💯37👍14🤣10😢1
Такая непростая диагностика
Любую систему можно починить, или понять, почему ее починить нельзя. Но это достаточно непростой и небыстрый процесс, и чтобы он увенчался успехом к нему нужен системный подход.
Что нужно делать при появлении неисправности? Нет, не бежать в поисковик, а также в каналы и на форумы с паническими криками «Помогите!». Потому что скорее всего вы ничего не найдете, и никто вам не поможет, ну если только ваша ситуация самая типовая.
Прежде всего нужно заняться локализацией проблемы. Современные решения достаточно сложны и вам нужно четко понимать, где именно возникла неисправность.
Начинать нужно конечно же с логов, именно там находятся все зацепки, а возможно и готовые ответы на вопросы.
Если лог малоинформативен, то обратитесь к документации, в большинстве случаев его можно переключить в режим отладки. Обязательно пройдите по логу вверх и вниз, внимательно изучив сообщения, предшествовавшие ошибке и возникшие после ее появления, даже если они ошибками не являются.
Также не забываем, что в большинстве случаев у нас есть две взаимодействующие стороны: клиент и сервер. И если лог на сервере неинформативен или вообще не содержит ошибок, то возможно проблема возникает с другой стороны.
Поэтому обязательно изучите логи с обоих сторон. Вполне может оказаться так, что это не сервер прилег, а клиент не может к нему подключиться. А еще чаще именно кусочки лога с обоих сторон, не несущие особой смысловой нагрузки по отдельности, вместе складываются во вполне цельную и логичную картину.
После того как вы локализовали проблему следует вспомнить, какие действия вы или пользователи предпринимали перед ее возникновением. Проверить изменения параметров оборудования или ПО.
Если проблема плавающая или проявляется не у всех пользователей, то нужно постараться ее воспроизвести. При этом максимально подробно задокументировав все действия или применив видеозапись.
Для плавающих проблем хорошо помогает видеозапись сеанса пользователя, которую потом внимательно изучаем по временным меткам из логов.
И вот здесь мы подходим к еще одному тонкому моменту. Проблема может быть не в программе, а в передаваемых ей некорректных данных. Точнее проблема все равно в программе, но связана она именно с пользовательскими данными.
Скажем, если вы в логе видите деление на ноль, то не поленитесь проверить, а вдруг это именно пользователь предает ей ноль, там, где нуля не ожидается.
Особое внимание следует обратить на незаполненные поля и настройки по умолчанию, мы не раз сталкивались с тем, что подобные вещи могут весьма своевольно трактоваться как клиентом, так и сервером, либо их определенной связкой.
Если вы проделаете весь этот пласт работы, то у вас будет уже более-менее четкое представление о причинах неисправности, что позволит наметить возможные пути решения или поиска необходимой информации.
Также именно на этом этапе можно идти к коллегам или на форумы и каналы. Одно дело, когда вы вываливаете малоинформативное сообщение об ошибке и просите помочь, а совсем другое, когда у вас на руках подробное исследование проблемы со всеми деталями.
И, самое главное, не опускать руки. Даже если вы чего-то не понимаете, все проходили через этот этап, но именно самостоятельное решение задач по диагностике неисправностей позволяет получить опыт и, как сейчас модно говорить, прокачать скилл. Чего никогда за вас не сделают форумы и поисковики.
Любую систему можно починить, или понять, почему ее починить нельзя. Но это достаточно непростой и небыстрый процесс, и чтобы он увенчался успехом к нему нужен системный подход.
Что нужно делать при появлении неисправности? Нет, не бежать в поисковик, а также в каналы и на форумы с паническими криками «Помогите!». Потому что скорее всего вы ничего не найдете, и никто вам не поможет, ну если только ваша ситуация самая типовая.
Прежде всего нужно заняться локализацией проблемы. Современные решения достаточно сложны и вам нужно четко понимать, где именно возникла неисправность.
Начинать нужно конечно же с логов, именно там находятся все зацепки, а возможно и готовые ответы на вопросы.
Если лог малоинформативен, то обратитесь к документации, в большинстве случаев его можно переключить в режим отладки. Обязательно пройдите по логу вверх и вниз, внимательно изучив сообщения, предшествовавшие ошибке и возникшие после ее появления, даже если они ошибками не являются.
Также не забываем, что в большинстве случаев у нас есть две взаимодействующие стороны: клиент и сервер. И если лог на сервере неинформативен или вообще не содержит ошибок, то возможно проблема возникает с другой стороны.
Поэтому обязательно изучите логи с обоих сторон. Вполне может оказаться так, что это не сервер прилег, а клиент не может к нему подключиться. А еще чаще именно кусочки лога с обоих сторон, не несущие особой смысловой нагрузки по отдельности, вместе складываются во вполне цельную и логичную картину.
После того как вы локализовали проблему следует вспомнить, какие действия вы или пользователи предпринимали перед ее возникновением. Проверить изменения параметров оборудования или ПО.
Если проблема плавающая или проявляется не у всех пользователей, то нужно постараться ее воспроизвести. При этом максимально подробно задокументировав все действия или применив видеозапись.
Для плавающих проблем хорошо помогает видеозапись сеанса пользователя, которую потом внимательно изучаем по временным меткам из логов.
И вот здесь мы подходим к еще одному тонкому моменту. Проблема может быть не в программе, а в передаваемых ей некорректных данных. Точнее проблема все равно в программе, но связана она именно с пользовательскими данными.
Скажем, если вы в логе видите деление на ноль, то не поленитесь проверить, а вдруг это именно пользователь предает ей ноль, там, где нуля не ожидается.
Особое внимание следует обратить на незаполненные поля и настройки по умолчанию, мы не раз сталкивались с тем, что подобные вещи могут весьма своевольно трактоваться как клиентом, так и сервером, либо их определенной связкой.
Если вы проделаете весь этот пласт работы, то у вас будет уже более-менее четкое представление о причинах неисправности, что позволит наметить возможные пути решения или поиска необходимой информации.
Также именно на этом этапе можно идти к коллегам или на форумы и каналы. Одно дело, когда вы вываливаете малоинформативное сообщение об ошибке и просите помочь, а совсем другое, когда у вас на руках подробное исследование проблемы со всеми деталями.
И, самое главное, не опускать руки. Даже если вы чего-то не понимаете, все проходили через этот этап, но именно самостоятельное решение задач по диагностике неисправностей позволяет получить опыт и, как сейчас модно говорить, прокачать скилл. Чего никогда за вас не сделают форумы и поисковики.
🔥32👍17🤔2💯2
Как «выжать» прибыль из цифровой трансформации?
Знают на канале «сИTуация 2024». Внутри — разборы последних событий, подкасты на горячие ИТ-темы, кейсы из разных отраслей, анонсы вебинаров, подборки о бизнесе и технологиях.
Вот самые классные материалы:
→ Что ждет российский ИТ-рынок в 2024 году?
→ 6 полезных советов для ИТ-директора, которые помогут повысить эффективность компании.
→ Как сделать ИТ-стратегию помощником в ежедневной работе?
→ Нужно ли срочно мигрировать на отечественные ERP-системы или можно подождать?
→ От чего зависит успех внедряемых ИТ-изменений?
→ Какой должна быть СЭД для крупного бизнеса? Разбираем 4 главные функции.
→ ИТ-эдвайзер — модное слово или реальный помощник для бизнеса?
Подписывайтесь на канал «сИTуация 2024» и держите руку на пульсе событий!
Реклама. ООО "КОРУС КОНСАЛТИНГ ГК". ИНН 7811090505. erid: LjN8KUaey
Знают на канале «сИTуация 2024». Внутри — разборы последних событий, подкасты на горячие ИТ-темы, кейсы из разных отраслей, анонсы вебинаров, подборки о бизнесе и технологиях.
Вот самые классные материалы:
→ Что ждет российский ИТ-рынок в 2024 году?
→ 6 полезных советов для ИТ-директора, которые помогут повысить эффективность компании.
→ Как сделать ИТ-стратегию помощником в ежедневной работе?
→ Нужно ли срочно мигрировать на отечественные ERP-системы или можно подождать?
→ От чего зависит успех внедряемых ИТ-изменений?
→ Какой должна быть СЭД для крупного бизнеса? Разбираем 4 главные функции.
→ ИТ-эдвайзер — модное слово или реальный помощник для бизнеса?
Подписывайтесь на канал «сИTуация 2024» и держите руку на пульсе событий!
Реклама. ООО "КОРУС КОНСАЛТИНГ ГК". ИНН 7811090505. erid: LjN8KUaey
👍2
Выгрузка и загрузка информационных баз 1С при помощи автономного сервера
При работе с информационными базами 1С:Предприятие очень часто возникают задачи выгрузить или загрузить дамп информационной базы или ее конфигурацию.
Обычно для этих целей используют Конфигуратор, но данный способ имеет ряд неудобств. Во-первых, Конфигуратор требует монопольного доступа к базе, т.е. выгнать из нее всех пользователей.
Во-вторых, могут быть сложности с серверами на Linux без графического окружения, а так как Конфигуратор работает в режиме толстого клиента, то все данные в полном объеме гоняются по сети, таким образом удаленная работа на медленном канале становится попросту невозможной.
От всех этих недостатков вас может избавить Автономный сервер, который поставляется вместе с платформой и располагается в папке
В нашем примере будет использована платформа Linux, но все команды будут прекрасно работать и в среде Windows.
Будем считать, что мы находимся в директории с бинарными файлами платформы, а дампы и конфигурации будем располагать в домашнем каталоге текущего пользователя.
Начнем с самого популярного, выгрузки базы в DT-файл:
В целом параметры в комментариях не нуждаются, только уточним что в опции --db-server мы указываем имя или адрес сервера базы данных и указываем учетные данные также от сервера СУБД.
Параметр --dbms указывает тип СУБД, можете использовать
Выгонять пользователей для этого не нужно, но помните, что в возможно нарушение целостности создаваемого файла выгрузки.
Кроме того, следует помнить, что выгрузка информационной базы не является средством резервного копирования!
Загрузить базу можно обратной командой:
Для выгрузки конфигурации используйте:
Для загрузки:
После загрузки конфигурации вам потребуется обновить конфигурацию базы данных:
В данной заметке мы коснулись лишь малой части того, что умеет автономный сервер, показав лишь самые часто используемые операции. Больше информации можно найти в официальной документации.
При работе с информационными базами 1С:Предприятие очень часто возникают задачи выгрузить или загрузить дамп информационной базы или ее конфигурацию.
Обычно для этих целей используют Конфигуратор, но данный способ имеет ряд неудобств. Во-первых, Конфигуратор требует монопольного доступа к базе, т.е. выгнать из нее всех пользователей.
Во-вторых, могут быть сложности с серверами на Linux без графического окружения, а так как Конфигуратор работает в режиме толстого клиента, то все данные в полном объеме гоняются по сети, таким образом удаленная работа на медленном канале становится попросту невозможной.
От всех этих недостатков вас может избавить Автономный сервер, который поставляется вместе с платформой и располагается в папке
bin под именем ibcmd.В нашем примере будет использована платформа Linux, но все команды будут прекрасно работать и в среде Windows.
Будем считать, что мы находимся в директории с бинарными файлами платформы, а дампы и конфигурации будем располагать в домашнем каталоге текущего пользователя.
Начнем с самого популярного, выгрузки базы в DT-файл:
./ibcmd infobase dump --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1 ~/1cv8.dt
В целом параметры в комментариях не нуждаются, только уточним что в опции --db-server мы указываем имя или адрес сервера базы данных и указываем учетные данные также от сервера СУБД.
Параметр --dbms указывает тип СУБД, можете использовать
PostgreSQL или MSSQLServer. Выгонять пользователей для этого не нужно, но помните, что в возможно нарушение целостности создаваемого файла выгрузки.
Кроме того, следует помнить, что выгрузка информационной базы не является средством резервного копирования!
Загрузить базу можно обратной командой:
./ibcmd infobase restore --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1 ~/1cv8.dt
Для выгрузки конфигурации используйте:
./ibcmd infobase config save --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1 ~/1cv8.cf
Для загрузки:
./ibcmd infobase config load --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1 ~/1cv8.cf
После загрузки конфигурации вам потребуется обновить конфигурацию базы данных:
./ibcmd infobase config apply --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1
В данной заметке мы коснулись лишь малой части того, что умеет автономный сервер, показав лишь самые часто используемые операции. Больше информации можно найти в официальной документации.
👍43🔥13
Критерии выбора оборудования для сервера 1С:Предприятие. Процессор. Часть 1
Тема выбора оборудования для сервера 1С актуальная и с завидной регулярностью поднимается в комментариях. Поэтому сегодня уделим внимание этому вопросу.
Критически важным для 1С является частота центрального процессора, это связано с рядом особенностей, которые мы опишем ниже, точнее даже не с частотой как таковой, а с однопоточной производительностью, которая с частотой обычно связана напрямую.
Ниже 3 ГГц можете даже не смотреть, а лучше выбрать процессоры с частотой около 4 ГГц. Что касается буста, то смотрите не на абсолютные цифры частоты, а на то, как именно процессор ее поднимает, будет лучше если он одновременно может поднимать частоту сразу всех ядер.
А теперь перейдем к тому, почему это так. В админской среде гуляет мнение, что это от того, что 1С написана левой задней лапой и не умеет в многопоточность. Однако это не так. Умеет и там, где может – распараллеливается. Но может это сделать не везде.
Начнем с того, что 1С – это учетная система, предназначенная для ведения бухгалтерского и управленческого учета, расчета заработной платы и многих других специфичных вещей.
И именно предметная часть накладывает серьезные ограничения, бухгалтерия – не математика. Мы не можем взять и вычислить параллельно части выражения и потом произвести окончательные вычисления, в учете многие операции можно делать строго последовательно, в один поток.
Чтобы было проще понять, о чем мы говорим приведем очень сильно упрощенный пример: вы не можете продать товар пока не оприходуете его на склад, а оприходовать не сможете раньше, чем внесете оплату поставщику.
Нет, конечно, технически это сделать можно и если считать только товар на складе и деньги в кассе, то вроде бы все и нормально. Но с точки зрения бухучета это будут абсолютно разные хозяйственные операции и абсолютно разный хозяйственный результат.
Поэтому всегда исходим из того, что у нас будут преимущественно однопоточные нагрузки и наш сервер должен уметь быстро и эффективно их обрабатывать.
Индикатором комфортной работы отдельного пользователя служит широко известный тест Гилева. Который проверяет способность оборудования переварить именно однопоточную нагрузку.
С увеличением количества пользователей растет количество однопоточных задач и нам нужно уметь быстро их обработать. Поэтому следующим вопросом становятся ядра и потоки. Их должно быть достаточно.
Точно сказать сколько надо ядер и потоков на N-пользователей обычно не представляется возможным, так как даже на одной и той же конфигурации, с одним и тем же количеством пользователей и даже с примерно одинаковым размером базы характер нагрузки может быть принципиально разный.
Так у производства и торговли будут совершенно разные сценарии. Да и торговля бывает разной, у кого-то есть партионный учет, у кого-то ВЭД и курсовые разницы и т.д. и т.п.
Где-то нагрузка будет равномерной, где-то пиковой. Все зависит от параметров учета конкретного предприятия. И советовать какое-то железо только исходя из конфигурации и количества пользователей – дело неблагодарное, кому-то ее будет с избытком, а кому-то сразу станет тесно.
Учитывая, что редко кто делает крупные внедрения 1С с нуля, всегда имеется возможность оценить характер нагрузки на уже имеющемся оборудовании и прикинуть необходимый вектор развития.
А также выяснить характер нагрузки и установить кто именно ее производит. Например, мы сталкивались с тем, что сильные пиковые нагрузки производила база ЗуП (Зарплата и управление персоналом), в которой работало три человека. В таких сценариях имеет смысл выносить подобные нагрузки на отдельные экземпляры Сервер-МИНИ.
Объем заметки не позволяет охватить все аспекты, поэтому на сегодня закончим. А в следующей заметке поговорим о менее очевидных вещах: рабочих процессах и веб-клиентах.
Тема выбора оборудования для сервера 1С актуальная и с завидной регулярностью поднимается в комментариях. Поэтому сегодня уделим внимание этому вопросу.
Критически важным для 1С является частота центрального процессора, это связано с рядом особенностей, которые мы опишем ниже, точнее даже не с частотой как таковой, а с однопоточной производительностью, которая с частотой обычно связана напрямую.
Ниже 3 ГГц можете даже не смотреть, а лучше выбрать процессоры с частотой около 4 ГГц. Что касается буста, то смотрите не на абсолютные цифры частоты, а на то, как именно процессор ее поднимает, будет лучше если он одновременно может поднимать частоту сразу всех ядер.
А теперь перейдем к тому, почему это так. В админской среде гуляет мнение, что это от того, что 1С написана левой задней лапой и не умеет в многопоточность. Однако это не так. Умеет и там, где может – распараллеливается. Но может это сделать не везде.
Начнем с того, что 1С – это учетная система, предназначенная для ведения бухгалтерского и управленческого учета, расчета заработной платы и многих других специфичных вещей.
И именно предметная часть накладывает серьезные ограничения, бухгалтерия – не математика. Мы не можем взять и вычислить параллельно части выражения и потом произвести окончательные вычисления, в учете многие операции можно делать строго последовательно, в один поток.
Чтобы было проще понять, о чем мы говорим приведем очень сильно упрощенный пример: вы не можете продать товар пока не оприходуете его на склад, а оприходовать не сможете раньше, чем внесете оплату поставщику.
Нет, конечно, технически это сделать можно и если считать только товар на складе и деньги в кассе, то вроде бы все и нормально. Но с точки зрения бухучета это будут абсолютно разные хозяйственные операции и абсолютно разный хозяйственный результат.
Поэтому всегда исходим из того, что у нас будут преимущественно однопоточные нагрузки и наш сервер должен уметь быстро и эффективно их обрабатывать.
Индикатором комфортной работы отдельного пользователя служит широко известный тест Гилева. Который проверяет способность оборудования переварить именно однопоточную нагрузку.
С увеличением количества пользователей растет количество однопоточных задач и нам нужно уметь быстро их обработать. Поэтому следующим вопросом становятся ядра и потоки. Их должно быть достаточно.
Точно сказать сколько надо ядер и потоков на N-пользователей обычно не представляется возможным, так как даже на одной и той же конфигурации, с одним и тем же количеством пользователей и даже с примерно одинаковым размером базы характер нагрузки может быть принципиально разный.
Так у производства и торговли будут совершенно разные сценарии. Да и торговля бывает разной, у кого-то есть партионный учет, у кого-то ВЭД и курсовые разницы и т.д. и т.п.
Где-то нагрузка будет равномерной, где-то пиковой. Все зависит от параметров учета конкретного предприятия. И советовать какое-то железо только исходя из конфигурации и количества пользователей – дело неблагодарное, кому-то ее будет с избытком, а кому-то сразу станет тесно.
Учитывая, что редко кто делает крупные внедрения 1С с нуля, всегда имеется возможность оценить характер нагрузки на уже имеющемся оборудовании и прикинуть необходимый вектор развития.
А также выяснить характер нагрузки и установить кто именно ее производит. Например, мы сталкивались с тем, что сильные пиковые нагрузки производила база ЗуП (Зарплата и управление персоналом), в которой работало три человека. В таких сценариях имеет смысл выносить подобные нагрузки на отдельные экземпляры Сервер-МИНИ.
Объем заметки не позволяет охватить все аспекты, поэтому на сегодня закончим. А в следующей заметке поговорим о менее очевидных вещах: рабочих процессах и веб-клиентах.
👍65❤3
Критерии выбора оборудования для сервера 1С:Предприятие. Процессор. Часть 2
Во вчерашней заметке мы разобрали общие вопросы производительности сервера 1С в разрезе процессора, сегодня продолжим углубляться в специфику.
Рабочие процессы (rphost) – основная рабочая лошадка, которая выполняет серверный код и обслуживает пользовательские соединения. В целом рабочий процесс умеет эффективно использовать ядра процессора, но есть некоторые тонкости.
Официальная документация гласит:
…при работе на многопроцессорных системах, в зависимости от характера нагрузки, может наблюдаться неравномерная загрузка процессоров/ядер. В некоторых случаях может оказаться загружена только какая-то часть доступных ядер CPU, при этом другая часть будет простаивать. В таких случаях рекомендуется использовать лимит числа соединений на рабочий процесс…
Фактические рекомендации сводятся к тому, чтобы равномерно распределить рассчитанный максимум соединений на доступные ядра процессора, а если нагрузка будет продолжать оставаться неравномерной, то уменьшать этот лимит.
Проще говоря – количество рабочих процессов рекомендовано выставлять по количеству ядер.
Но тут беда пришла откуда не ждали, после разделения платформы на ПРОФ и КОРП. Теперь у пользователей ПРОФ нет возможности настраивать рабочие процессы, единственное доступное значение 8 ИБ на процесс и 256 соединений. Также платформа ПРОФ не может использовать более 12 процессорных ядер.
Это говорит о том, что в большинстве случаев вы будете работать в рамках единого рабочего процесса и иметь все прелести неравномерной загрузки, в этом случае также крайне важно иметь CPU с максимально высокой частотой процессора.
Отсюда проистекает также и схема масштабирования. Если ваши масштабы не предполагают переход на КОРП, а на одном сервере всем становится тесно, то лучший вариант – это увеличение количества серверов 1С.
Где-то ряд нагрузки можно вынести на Сервер-МИНИ, а где-то имеет смысл приобрести еще одну лицензию. При этом аппаратно можно продолжать использовать уже имеющееся оборудование.
Скажем тот же AMD Ryzen 9 5900X имеет 12 ядер / 24 потока, что позволит полноценно развернуть на нем две виртуальных машины или контейнера с серверами 1С по 12 ядер в каждом.
Следующий тонкий момент – веб-сервера, которые сейчас очень популярны как средство доступа к 1С.
Здесь мы начнем с вопроса: где исполняется код 1С? А исполняется он в двух местах: на клиенте и на сервере. На клиенте обрабатываются данные форм приложения и данные введенные в них пользователем.
Данные ИБ можно получить только на сервере и обычно там же происходит их обработка. Количество кода, исполняемого клиентом и сервером, различается от характера нагрузки.
При установке на компьютер пользователя платформы в режиме тонкого клиента, работающего через веб-сервер весь код клиентского приложения исполняется прямо на нем. А веб-сервер служит простым ретранслятором запросов к серверу, практически не оказывая нагрузки.
Если же доступ ведется через веб-клиент (браузер), то код, исполняемый на клиентской стороне, выполняет модуль расширения веб-сервера и вся нагрузка ложится на веб-сервер. Этот момент также нужно учитывать при планировании нагрузки.
Следующий момент – это сеансы и соединения. Сеанс определяет активного пользователя информационной базы и поток управления этого пользователя. Среди доступных видов сеансов есть тонкий клиент и веб-клиент.
Соединение является средством доступа сеансов серверу 1С:Предприятия» и не отождествляется с активным пользователем. Среди видов соединений есть также тонкий клиент и модуль расширения веб-сервера.
О чем это говорит? О том что в режиме работы через веб-сервер количество сеансов не равно количеству соединений. И чаще всего множество входящих сеансов к веб-серверу обслуживаются единственным соединением к серверу 1С:Предприятия.
Поэтому здесь разумно будет распараллеливать нагрузку путем увеличения количества веб-серверов, а также обязательно разносить веб-сервера обслуживающие пользователей и используемые для веб-сервисов.
Во вчерашней заметке мы разобрали общие вопросы производительности сервера 1С в разрезе процессора, сегодня продолжим углубляться в специфику.
Рабочие процессы (rphost) – основная рабочая лошадка, которая выполняет серверный код и обслуживает пользовательские соединения. В целом рабочий процесс умеет эффективно использовать ядра процессора, но есть некоторые тонкости.
Официальная документация гласит:
…при работе на многопроцессорных системах, в зависимости от характера нагрузки, может наблюдаться неравномерная загрузка процессоров/ядер. В некоторых случаях может оказаться загружена только какая-то часть доступных ядер CPU, при этом другая часть будет простаивать. В таких случаях рекомендуется использовать лимит числа соединений на рабочий процесс…
Фактические рекомендации сводятся к тому, чтобы равномерно распределить рассчитанный максимум соединений на доступные ядра процессора, а если нагрузка будет продолжать оставаться неравномерной, то уменьшать этот лимит.
Проще говоря – количество рабочих процессов рекомендовано выставлять по количеству ядер.
Но тут беда пришла откуда не ждали, после разделения платформы на ПРОФ и КОРП. Теперь у пользователей ПРОФ нет возможности настраивать рабочие процессы, единственное доступное значение 8 ИБ на процесс и 256 соединений. Также платформа ПРОФ не может использовать более 12 процессорных ядер.
Это говорит о том, что в большинстве случаев вы будете работать в рамках единого рабочего процесса и иметь все прелести неравномерной загрузки, в этом случае также крайне важно иметь CPU с максимально высокой частотой процессора.
Отсюда проистекает также и схема масштабирования. Если ваши масштабы не предполагают переход на КОРП, а на одном сервере всем становится тесно, то лучший вариант – это увеличение количества серверов 1С.
Где-то ряд нагрузки можно вынести на Сервер-МИНИ, а где-то имеет смысл приобрести еще одну лицензию. При этом аппаратно можно продолжать использовать уже имеющееся оборудование.
Скажем тот же AMD Ryzen 9 5900X имеет 12 ядер / 24 потока, что позволит полноценно развернуть на нем две виртуальных машины или контейнера с серверами 1С по 12 ядер в каждом.
Следующий тонкий момент – веб-сервера, которые сейчас очень популярны как средство доступа к 1С.
Здесь мы начнем с вопроса: где исполняется код 1С? А исполняется он в двух местах: на клиенте и на сервере. На клиенте обрабатываются данные форм приложения и данные введенные в них пользователем.
Данные ИБ можно получить только на сервере и обычно там же происходит их обработка. Количество кода, исполняемого клиентом и сервером, различается от характера нагрузки.
При установке на компьютер пользователя платформы в режиме тонкого клиента, работающего через веб-сервер весь код клиентского приложения исполняется прямо на нем. А веб-сервер служит простым ретранслятором запросов к серверу, практически не оказывая нагрузки.
Если же доступ ведется через веб-клиент (браузер), то код, исполняемый на клиентской стороне, выполняет модуль расширения веб-сервера и вся нагрузка ложится на веб-сервер. Этот момент также нужно учитывать при планировании нагрузки.
Следующий момент – это сеансы и соединения. Сеанс определяет активного пользователя информационной базы и поток управления этого пользователя. Среди доступных видов сеансов есть тонкий клиент и веб-клиент.
Соединение является средством доступа сеансов серверу 1С:Предприятия» и не отождествляется с активным пользователем. Среди видов соединений есть также тонкий клиент и модуль расширения веб-сервера.
О чем это говорит? О том что в режиме работы через веб-сервер количество сеансов не равно количеству соединений. И чаще всего множество входящих сеансов к веб-серверу обслуживаются единственным соединением к серверу 1С:Предприятия.
Поэтому здесь разумно будет распараллеливать нагрузку путем увеличения количества веб-серверов, а также обязательно разносить веб-сервера обслуживающие пользователей и используемые для веб-сервисов.
👍47❤1