Встречайте AIOps в INFRAX — виртуального инженера, который работает прямо внутри карточки инцидента:
- анализирует логи,
- предлагает команды,
- помогает устранять неполадки быстрее и надёжнее.
🔐 Все действия прозрачны и безопасны: журналируются в инциденте и выполняются строго в рамках ваших политик доступа.
Что такое INFRAX? Это:
🖥 Мультиметричный мониторинг — CPU, память, диски, трафик, доступность узлов, интерактивные графики и гибкие алерты.
🎫 Helpdesk — управление тикетами, статусы, приоритеты, исполнители и комментарии, портал самообслуживания для пользователей.
🤖 Автоматизация — агенты для Windows/Linux, запуск скриптов по расписанию, планировщик задач, автодетект узлов.
🔐 Удалённые подключения — RDP, SSH, VNC прямо из веба или нативных клиентов, видеозапись сессий для аудита.
📚 База знаний — статьи, категории, контроль публикаций, статистика по популярности.
👥 Управление пользователями — детальная система прав, интеграция с IAM, аудит действий, изоляция данных.
📊 Дашборды — мониторинг, техподдержка, удалённые подключения с realtime-обновлением.
🔥 Infrax — это ситуационный центр вашей ИТ-инфраструктуры. Всё, что нужно для стабильной и безопасной работы сервисов, в одном решении.
#реклама
О рекламодателе
- анализирует логи,
- предлагает команды,
- помогает устранять неполадки быстрее и надёжнее.
🔐 Все действия прозрачны и безопасны: журналируются в инциденте и выполняются строго в рамках ваших политик доступа.
Что такое INFRAX? Это:
🖥 Мультиметричный мониторинг — CPU, память, диски, трафик, доступность узлов, интерактивные графики и гибкие алерты.
🎫 Helpdesk — управление тикетами, статусы, приоритеты, исполнители и комментарии, портал самообслуживания для пользователей.
🤖 Автоматизация — агенты для Windows/Linux, запуск скриптов по расписанию, планировщик задач, автодетект узлов.
🔐 Удалённые подключения — RDP, SSH, VNC прямо из веба или нативных клиентов, видеозапись сессий для аудита.
📚 База знаний — статьи, категории, контроль публикаций, статистика по популярности.
👥 Управление пользователями — детальная система прав, интеграция с IAM, аудит действий, изоляция данных.
📊 Дашборды — мониторинг, техподдержка, удалённые подключения с realtime-обновлением.
🔥 Infrax — это ситуационный центр вашей ИТ-инфраструктуры. Всё, что нужно для стабильной и безопасной работы сервисов, в одном решении.
#реклама
О рекламодателе
👍8👎3🤡1
До свиданья наш ласковый миша
Мир IT постоянно находится в движении, меняются технологии, подходы, условия. И вчерашние технологии оказываются не соответствующими текущим вызовам. Поэтому нужно находить в себе силы пересматривать старые привычки и менять используемый стек решений.
Сегодня мы поговорим об mdadm, старом-добром mdadm, который мы все любим, знаем и используем.
Но увы, время mdadm прошло и сегодня он уже не выполняет возлагаемых на него функций и не оправдывает ожиданий.
В чем проблема? А проблема в таком явлении, как bitrot, битовое гниение (https://t.me/interface31/2600) – деградация данных, не связанная с физическим выходом из строя накопителя и часто даже не препятствующая чтению данных, так как встроенные во многие форматы методы коррекции позволяют такие ошибки исправлять.
Но на системах холодного хранения данных такие ошибки могут накапливаться и незаметно повреждать данные вплоть до невосстановимого уровня.
Об этом давно предупреждали разработчики Proxmox и поэтому в доступных вариантах организации хранилища mdadm нет, что вызывало и вызывает недоумения у многих пользователей.
Но они правы и буквально вчера мы столкнулись с неприятной ситуацией с битовым гниением на mdadm.
Медицинская организация, некие наборы данных хранятся в файловом хранилище в виде архивов подписанных ЭП, срок хранения требуется большой, десятки лет. Это требования регламента и единственной альтернативой ему может служить бумажный архив, который, при выполнении всех требований по защите персональных данных становится вовсе неподъемным.
Вчера, при обращении к одному из таких архивов выяснилось, что архив читается, распаковывается, но проверку подписи не проходит. Т.е. фактически мы утратили часть архива, так как данные документы перестали считаться подлинными.
Учитывая важность архива конечно-же делались его копии, в т.ч. и во внешнее хранилище. Извлеченная из бекапа копия проверку подписи прошла.
Следовательно? Следовательно мы имеем дело с классическим bitrot, которое тихо и незаметно портит данные, и никто об этом ни сном, ни духом.
Мы запустили проверку архива и результат был неутешительный, повреждены оказались еще около десятка файлов, один из них имел ошибки распаковки, но все-таки распаковался.
Да, десяток файлов из тысяч – это мало, но в данном случае вполне достаточно для создания серьезных проблем.
А причем тут mdadm? А при том, что все это хранилище как раз было организовано средствами mdadm: LVM поверх двух зеркал по 4 ТБ.
Да, mdadm защищает нас от физического выхода диска из строя, но от битового гниения спасти не может.
Кто может? Современные файловые системы с контролем целостности данных: ZFS или btrfs, но для этого избыточность также должна создаваться средствами этих ФС, в этом случае они смогут эффективно выявлять повреждения и восстанавливать их за счет избыточных данных.
Если же вы просто натянете btrfs поверх mdadm – то ничего работать не будет, избыточность брать неоткуда.
Поэтому, как бы прост, понятен и удобен не был mdadm – его время вышло, говорим старичку спасибо и отправляем на заслуженную пенсию.
Мир IT постоянно находится в движении, меняются технологии, подходы, условия. И вчерашние технологии оказываются не соответствующими текущим вызовам. Поэтому нужно находить в себе силы пересматривать старые привычки и менять используемый стек решений.
Сегодня мы поговорим об mdadm, старом-добром mdadm, который мы все любим, знаем и используем.
Но увы, время mdadm прошло и сегодня он уже не выполняет возлагаемых на него функций и не оправдывает ожиданий.
В чем проблема? А проблема в таком явлении, как bitrot, битовое гниение (https://t.me/interface31/2600) – деградация данных, не связанная с физическим выходом из строя накопителя и часто даже не препятствующая чтению данных, так как встроенные во многие форматы методы коррекции позволяют такие ошибки исправлять.
Но на системах холодного хранения данных такие ошибки могут накапливаться и незаметно повреждать данные вплоть до невосстановимого уровня.
Об этом давно предупреждали разработчики Proxmox и поэтому в доступных вариантах организации хранилища mdadm нет, что вызывало и вызывает недоумения у многих пользователей.
Но они правы и буквально вчера мы столкнулись с неприятной ситуацией с битовым гниением на mdadm.
Медицинская организация, некие наборы данных хранятся в файловом хранилище в виде архивов подписанных ЭП, срок хранения требуется большой, десятки лет. Это требования регламента и единственной альтернативой ему может служить бумажный архив, который, при выполнении всех требований по защите персональных данных становится вовсе неподъемным.
Вчера, при обращении к одному из таких архивов выяснилось, что архив читается, распаковывается, но проверку подписи не проходит. Т.е. фактически мы утратили часть архива, так как данные документы перестали считаться подлинными.
Учитывая важность архива конечно-же делались его копии, в т.ч. и во внешнее хранилище. Извлеченная из бекапа копия проверку подписи прошла.
Следовательно? Следовательно мы имеем дело с классическим bitrot, которое тихо и незаметно портит данные, и никто об этом ни сном, ни духом.
Мы запустили проверку архива и результат был неутешительный, повреждены оказались еще около десятка файлов, один из них имел ошибки распаковки, но все-таки распаковался.
Да, десяток файлов из тысяч – это мало, но в данном случае вполне достаточно для создания серьезных проблем.
А причем тут mdadm? А при том, что все это хранилище как раз было организовано средствами mdadm: LVM поверх двух зеркал по 4 ТБ.
Да, mdadm защищает нас от физического выхода диска из строя, но от битового гниения спасти не может.
Кто может? Современные файловые системы с контролем целостности данных: ZFS или btrfs, но для этого избыточность также должна создаваться средствами этих ФС, в этом случае они смогут эффективно выявлять повреждения и восстанавливать их за счет избыточных данных.
Если же вы просто натянете btrfs поверх mdadm – то ничего работать не будет, избыточность брать неоткуда.
Поэтому, как бы прост, понятен и удобен не был mdadm – его время вышло, говорим старичку спасибо и отправляем на заслуженную пенсию.
👍50❤8😱4👎1
Сегодня в обсуждении возник вопрос о влиянии виртуализации на производительность. Поэтому решили провести небольшой экспресс-тест.
Для начала хост, компьютер не очень мощный, даже наоборот, но в данном случае это не имеет никакого значения.
Теперь KVM виртуальная машина, значения по умолчанию.
Так как у нас эмулируется
А вот третий полностью зависит от поддержки аппаратных инструкций процессора и здесь разница довольно серьезная. Но зато
Дисковая система по умолчанию без кеширования и результат тоже хуже, чем на хосте.
Но и виртуальные машины применяются там. где нужна более серьезная изоляция на уровне железа, либо его специальная эмуляция, так как не все сценарии поддерживаются в контейнерах.
Если же нужна производительность, то смело берем LXC.
Для начала хост, компьютер не очень мощный, даже наоборот, но в данном случае это не имеет никакого значения.
Processor: Intel(R) Celeron(R) CPU J3355 @ 2.00GHz
CPU cores: 2
Frequency: 2428.759 MHz
RAM: 15Gi
Swap: 8.0Gi
Kernel: Linux 5.15.108-1-pve x86_64
Disks:
sda 223.6G SSD
CPU: SHA256-hashing 500 MB
5.458 seconds
CPU: bzip2-compressing 500 MB
10.662 seconds
CPU: AES-encrypting 500 MB
2.635 seconds
ioping: seek rate
min/avg/max/mdev = 103.4 us / 146.3 us / 6.43 ms / 67.6 us
ioping: sequential read speed
generated 8.81 k requests in 5.00 s, 2.15 GiB, 1.76 k iops, 440.4 MiB/s
Теперь LXC контейнер:Processor: Intel(R) Celeron(R) CPU J3355 @ 2.00GHz
CPU cores: 2
Frequency: 2500.000 MHz
RAM: 2,0Gi
Swap: 512Mi
Kernel: Linux 5.15.108-1-pve x86_64
Disks:
sda 223,6G SSD
CPU: SHA256-hashing 500 MB
5,858 seconds
CPU: bzip2-compressing 500 MB
11,333 seconds
CPU: AES-encrypting 500 MB
2,666 seconds
ioping: seek rate
min/avg/max/mdev = 110.8 us / 163.9 us / 4.42 ms / 62.5 us
ioping: sequential read speed
generated 8.16 k requests in 5.00 s, 1.99 GiB, 1.63 k iops, 408.1 MiB/s
Как видим - разница на уровне погрешности измерений. Поэтому можно смело говорить, что производительность контейнеров примерно равна производительности хоста.Теперь KVM виртуальная машина, значения по умолчанию.
Processor: Common KVM processor
CPU cores: 2
Frequency: 1996.800 MHz
RAM: 3,9Gi
Swap: 974Mi
Kernel: Linux 4.19.0-20-amd64 x86_64
Disks:
sda 8G HDD
CPU: SHA256-hashing 500 MB
8,569 seconds
CPU: bzip2-compressing 500 MB
15,707 seconds
CPU: AES-encrypting 500 MB
15,507 seconds
ioping: seek rate
min/avg/max/mdev = 257.1 us / 698.5 us / 29.7 ms / 742.4 us
ioping: sequential read speed
generated 2.75 k requests in 5.00 s, 686.5 MiB, 549 iops, 137.3 MiB/s
В отличии от контейнера виртуалка добавляет отдельный слой виртуального железа и это вносит свои издержки.Так как у нас эмулируется
Common KVM processor, то сразу видим провал по частоте до номинальной и первые два процессорных теста примерно соответствуют разнице в частоте. А вот третий полностью зависит от поддержки аппаратных инструкций процессора и здесь разница довольно серьезная. Но зато
Common KVM processor является универсальным и переносимым. Дисковая система по умолчанию без кеширования и результат тоже хуже, чем на хосте.
Но и виртуальные машины применяются там. где нужна более серьезная изоляция на уровне железа, либо его специальная эмуляция, так как не все сценарии поддерживаются в контейнерах.
Если же нужна производительность, то смело берем LXC.
👍23❤9😁4💯1
Скорость виртуальной сети в Proxmox
После вчерашней публикации возник ряд вопросов по скорости виртуальной сети в пределах одного хоста.
Т.е. мы рассматриваем скорость сетевого взаимодействия между виртуальными машинами и/или контейнерами, находящимися на одном физическом гипервизоре и подключенных к одному сетевому мосту. При этом неважно, подключен данный мост к сетевому интерфейсу или нет.
Начнем с контейнеров. Контейнер с принципа не имеет сетевого интерфейса в его классическом понимании, нам нет необходимости что-то эмулировать на этом уровне, он просто пользуется ресурсами хоста.
В этом случае скорость лимитируется только вычислительными способностями CPU и пропускной способностью памяти и как правило измеряется в десятках Гбит/с.
Для виртуальных машин ситуация немного посложнее, там появляется эмулируемое оборудование и определенные сопутствующие потери на виртуализацию, также многое зависит от того, какой тип эмулируемого оборудования мы используем.
При использовании эмуляции реальных сетевых адаптеров, скажем E1000 мы можем упереться в ограничения драйвера. Если же используем полностью виртуальный VirtIO, то скорость также ограничивается только возможностями процессора и памяти.
Если сравнивать контейнер и виртуальную машину, то контейнер будет всегда немного быстрее, за счет меньших накладных расходов.
Что касается конкретных физических чисел, то на современном этапе развития вычислительной техники вы скорее всего упретесь в пропускную способность памяти.
Для примера мы выполнили тест на процессоре Core i5-4670 3,4 ГГц с 32 ГБ DDR3 2400 и получили значения около 35 Гбит/с, что близко к потолку пропускной способности этого типа памяти в двухканальном режиме (около 38 Гбит/с).
Поэтому бояться виртуальных сетей не нужно, скорость в пределах одного сетевого моста всегда будет выше физических возможностей относительно недорого Ethernet оборудования.
После вчерашней публикации возник ряд вопросов по скорости виртуальной сети в пределах одного хоста.
Т.е. мы рассматриваем скорость сетевого взаимодействия между виртуальными машинами и/или контейнерами, находящимися на одном физическом гипервизоре и подключенных к одному сетевому мосту. При этом неважно, подключен данный мост к сетевому интерфейсу или нет.
Начнем с контейнеров. Контейнер с принципа не имеет сетевого интерфейса в его классическом понимании, нам нет необходимости что-то эмулировать на этом уровне, он просто пользуется ресурсами хоста.
В этом случае скорость лимитируется только вычислительными способностями CPU и пропускной способностью памяти и как правило измеряется в десятках Гбит/с.
Для виртуальных машин ситуация немного посложнее, там появляется эмулируемое оборудование и определенные сопутствующие потери на виртуализацию, также многое зависит от того, какой тип эмулируемого оборудования мы используем.
При использовании эмуляции реальных сетевых адаптеров, скажем E1000 мы можем упереться в ограничения драйвера. Если же используем полностью виртуальный VirtIO, то скорость также ограничивается только возможностями процессора и памяти.
Если сравнивать контейнер и виртуальную машину, то контейнер будет всегда немного быстрее, за счет меньших накладных расходов.
Что касается конкретных физических чисел, то на современном этапе развития вычислительной техники вы скорее всего упретесь в пропускную способность памяти.
Для примера мы выполнили тест на процессоре Core i5-4670 3,4 ГГц с 32 ГБ DDR3 2400 и получили значения около 35 Гбит/с, что близко к потолку пропускной способности этого типа памяти в двухканальном режиме (около 38 Гбит/с).
Поэтому бояться виртуальных сетей не нужно, скорость в пределах одного сетевого моста всегда будет выше физических возможностей относительно недорого Ethernet оборудования.
👍46🤝4❤2
Расходы на виртуализацию. Краткие итоги
Расходы на виртуализацию – это любимая тема для обсуждения, как только вопрос заходит об этой самой виртуализации. Но следует понимать следующее – мы живем в третьем десятилетии 21 века и основная рабочая нагрузка сейчас виртуализирована.
Нравится, не нравится – но это де-факто новый стандарт. Причем мир все дальше уходит от виртуальных машин и отдает предпочтение контейнерам – LXC, Docker и т.д.
Это нормальный и закономерный процесс, глупо его игнорировать или вставлять палки в колеса. Ничего хорошего здесь не выйдет, прогресс продолжит двигаться дальше, а вот вы вполне можете вылететь на его обочину со всеми неприятными вытекающими.
Как мы уже показали в прошлых публикациях, которые мы повторили вчера и сегодня, накладные расходы на контейнеры практически равны нулю, накладные расходы на виртуальные машины сильно зависят от типа эмулируемого оборудования и тут уже надо смотреть для чего вам собственно эта виртуалка и какие задачи она решает.
Скажем если это сервер лицензирования, то производительность там стоит на последнем месте, а главное неизменность набора железа. Поэтому мы выбираем эмулируемые устройства в ущерб производительности.
Хотим переносимость между хостами с разными поколениями процессора – миримся с тем, что некоторые современные инструкции виртуалка не поддерживает.
Желаем максимальную производительность – выбираем самые современные синтетические устройства.
Но в любом случае расходы на виртуализацию не должны превышать 10-15%, если более, то вы что-то сделали не так, или сознательно пожертвовали производительностью ради иных преимуществ.
А теперь вернемся к нашим процентам. Ребята, если для вас эти 10-15% являются критичными, то у меня плохая новость – ваша система не тянет рабочую нагрузку и справляется из последних сил.
Откройте любую систему мониторинга и посмотрите пороги срабатывания триггеров по основным показателям. Примерно будет так: 80% - начинаем беспокоиться и принимать меры, 90% - бьем во все колокола, включаем сирену и вообще сигнализируем, что ситуация полный швах!
А это как раз ваши 10-15% «потерянные» на виртуализации. Если так, то ваша система и без виртуализации не имела никакого запаса производительности и любой резкий скачок спокойно выбьет ее из седла, а виртуализация только подсветила проблему.
Что касается производительности, то мы будем исходить из того, что высокие значения «попугаев» никому не нужны. Пользователи производственных систем не экстремальные геймеры и выжимать максимум из железа им без нужды.
Есть определенный уровень комфортной эксплуатации и все что выше нее просто останется незамеченным.
Если брать ту же 1С, то это 35-40 «попугаев» по Гилеву. Вы можете станцевать ужом на сковородке и обеспечить 60-70-100!!! Но кто это заметит?
Поэтому, если мы удовлетворили базовую потребность пользователей в комфортной работе, то лишние вычислительные ресурсы можем смело потратить на инфраструктуру, ту же виртуализацию.
Ну было у нас 75 «попугаев» Гилева, стало 65 – кто это заметит? Никто. Но за эти 10 «попугаев» мы приобретаем переносимость, высокую доступность, снижение затрат на сопровождение и многие другие плюшки.
А мораль сей басни проста: нет ничего бесплатного, за все мы чем-то вынуждены платить. Но «попугаи» сами по себе не являются высшей ценностью, реальная эксплуатация всегда компромисс и не всегда в пользу высокой производительности.
Расходы на виртуализацию – это любимая тема для обсуждения, как только вопрос заходит об этой самой виртуализации. Но следует понимать следующее – мы живем в третьем десятилетии 21 века и основная рабочая нагрузка сейчас виртуализирована.
Нравится, не нравится – но это де-факто новый стандарт. Причем мир все дальше уходит от виртуальных машин и отдает предпочтение контейнерам – LXC, Docker и т.д.
Это нормальный и закономерный процесс, глупо его игнорировать или вставлять палки в колеса. Ничего хорошего здесь не выйдет, прогресс продолжит двигаться дальше, а вот вы вполне можете вылететь на его обочину со всеми неприятными вытекающими.
Как мы уже показали в прошлых публикациях, которые мы повторили вчера и сегодня, накладные расходы на контейнеры практически равны нулю, накладные расходы на виртуальные машины сильно зависят от типа эмулируемого оборудования и тут уже надо смотреть для чего вам собственно эта виртуалка и какие задачи она решает.
Скажем если это сервер лицензирования, то производительность там стоит на последнем месте, а главное неизменность набора железа. Поэтому мы выбираем эмулируемые устройства в ущерб производительности.
Хотим переносимость между хостами с разными поколениями процессора – миримся с тем, что некоторые современные инструкции виртуалка не поддерживает.
Желаем максимальную производительность – выбираем самые современные синтетические устройства.
Но в любом случае расходы на виртуализацию не должны превышать 10-15%, если более, то вы что-то сделали не так, или сознательно пожертвовали производительностью ради иных преимуществ.
А теперь вернемся к нашим процентам. Ребята, если для вас эти 10-15% являются критичными, то у меня плохая новость – ваша система не тянет рабочую нагрузку и справляется из последних сил.
Откройте любую систему мониторинга и посмотрите пороги срабатывания триггеров по основным показателям. Примерно будет так: 80% - начинаем беспокоиться и принимать меры, 90% - бьем во все колокола, включаем сирену и вообще сигнализируем, что ситуация полный швах!
А это как раз ваши 10-15% «потерянные» на виртуализации. Если так, то ваша система и без виртуализации не имела никакого запаса производительности и любой резкий скачок спокойно выбьет ее из седла, а виртуализация только подсветила проблему.
Что касается производительности, то мы будем исходить из того, что высокие значения «попугаев» никому не нужны. Пользователи производственных систем не экстремальные геймеры и выжимать максимум из железа им без нужды.
Есть определенный уровень комфортной эксплуатации и все что выше нее просто останется незамеченным.
Если брать ту же 1С, то это 35-40 «попугаев» по Гилеву. Вы можете станцевать ужом на сковородке и обеспечить 60-70-100!!! Но кто это заметит?
Поэтому, если мы удовлетворили базовую потребность пользователей в комфортной работе, то лишние вычислительные ресурсы можем смело потратить на инфраструктуру, ту же виртуализацию.
Ну было у нас 75 «попугаев» Гилева, стало 65 – кто это заметит? Никто. Но за эти 10 «попугаев» мы приобретаем переносимость, высокую доступность, снижение затрат на сопровождение и многие другие плюшки.
А мораль сей басни проста: нет ничего бесплатного, за все мы чем-то вынуждены платить. Но «попугаи» сами по себе не являются высшей ценностью, реальная эксплуатация всегда компромисс и не всегда в пользу высокой производительности.
1👍37🔥6❤5🥱3😢1
858 терабайт государственных данных Южной Кореи сгорели к чёртовой матери. Бэкапа просто не было
26 сентября 2025 года в государственном дата-центре National Information Resources Service (NIRS) в городе Тэджон вспыхнул пожар. За несколько часов огонь уничтожил серверы облачного хранилища G-Drive (от слова government), где чиновникам выделялось по 30 ГБ для хранения различных документов, которые запрещено было хранить на офисных компьютерах. Им пользовалось 17% всех федеральных чиновников в Корее, или около 125 тысяч человек. Но не только — там хранились данные ещё 163 онлайн-сервисов южнокорейского правительства.
Масштаб потерь оценивается в 858 терабайт данных, которые могут быть утеряны навсегда. Среди пострадавших сервисов — регистрация бизнесов, проверка безопасности продуктов, сертификация импорта и экспорта, обработка визовых заявок. Представьте: вы подали документы на визу месяц назад, и вся эта информация просто испарилась. Или зарегистрировали компанию — и теперь никто не может подтвердить, что она вообще существует.
✅ Подробнее: https://habr.com/ru/articles/954512
В этой новости все прекрасно. И в очередной раз показывает, что госы - такие госы и не только у нас в стране.
26 сентября 2025 года в государственном дата-центре National Information Resources Service (NIRS) в городе Тэджон вспыхнул пожар. За несколько часов огонь уничтожил серверы облачного хранилища G-Drive (от слова government), где чиновникам выделялось по 30 ГБ для хранения различных документов, которые запрещено было хранить на офисных компьютерах. Им пользовалось 17% всех федеральных чиновников в Корее, или около 125 тысяч человек. Но не только — там хранились данные ещё 163 онлайн-сервисов южнокорейского правительства.
Масштаб потерь оценивается в 858 терабайт данных, которые могут быть утеряны навсегда. Среди пострадавших сервисов — регистрация бизнесов, проверка безопасности продуктов, сертификация импорта и экспорта, обработка визовых заявок. Представьте: вы подали документы на визу месяц назад, и вся эта информация просто испарилась. Или зарегистрировали компанию — и теперь никто не может подтвердить, что она вообще существует.
✅ Подробнее: https://habr.com/ru/articles/954512
В этой новости все прекрасно. И в очередной раз показывает, что госы - такие госы и не только у нас в стране.
🔥35😱10👏6🤮2🤡1
Про «реальную производительность» и APDEX
В комментариях нас уже несколько раз спросили, как мы оцениваем «реальную производительность» наших систем. Вопрос хороший, непростой вопрос.
Мы специально взяли фразу «реальная производительность» в кавычки, потому что за ней кроется нечто непонятное, которое каждый понимает по-своему. Вот прямо сейчас попробуйте отвлечься от прочтения заметки и попытайтесь сформулировать определение этому термину.
Скорее всего это будет синтетическая оценка в попугаях какого-либо популярного теста. Но если вас тут же спросят – а насколько хорошо будет работать на такой конфигурации некоторое бизнес-приложение вы вряд ли сможете дать точный ответ.
А теперь сделаем некоторое лирическое отступление. IT-отдел подразделение сугубо затратное, прибыли оно не приносит. Его задача обеспечивать бизнес-процессы. Прибыль при этом генерируют совсем другие подразделения.
Задача бизнеса – зарабатывать деньги. Бизнесу все равно насколько оно там технически правильно или какая «реальная производительность» в попугаях. Ему это не интересно, ему нужно чтобы работали производящие прибыль подразделения и поэтому мнение пользователей этих подразделений всегда будет иметь больший вес, чем мнение обслуживающих их айтишников.
Если пользователи такого подразделения говорят, что система работает плохо, то вы можете до посинения показывать результаты бенчмарков и уверять, что с вашей стороны все хорошо, вон целых 100 попугаев по Гилеву, должно все летать… Ответ будет прост – не летает, пользователи недовольны.
А в соседней конторе может стоять точно такой же сервер, с точной такой же конфигурацией 1С и там все довольны. Это как так? Почему?
Потому что нельзя оценивать производительность только по техническим характеристиками и синтетическим бенчмаркам. К счастью, все уже придумано до нас – открытый международный стандарт оценки производительности корпоративных приложений – APDEX.
Основным фактором влияния для APDEX является целевое время выполнения операции, если операция укладывается в период T – все довольны, если выходит за пределы 4T – полностью разочарованы.
Собранные результаты обрабатываются и нормируются по шкале от 0 до 1, где 0 – полностью разочарованы, 1 – полностью довольны.
👉 Результаты интерпретируются по шкале:
▫️0.00 - 0.50 неприемлемо
▫️0.50 - 0.70 очень плохо
▫️0.70 - 0.85 плохо
▫️0.85 - 0.94 хорошо
▫️0.94 - 1.00 отлично
APDEX вычисляется для каждой ключевой операции, что позволяет учесть конкретные потребности бизнеса и особенности его бизнес-процессов.
И именно APDEX даст понимание степени комфортности работы с системой и позволит не просто так крутить показатели, а добиваться именно нужных результатов. А также сразу видеть, какие именно участки требуют внимания.
Для операций можно выставить приоритет и тогда дополнительно будет видно, чем именно заняться в первую очередь.
Но позвольте, скажет иной читатель, но как мне определить время T, чтобы пользователь был доволен, это ведь некоторая умозрительная величина.
Согласны, степень довольства – величина субъективная, но APDEX как раз позволяет сопоставить субъективные ощущения с объективными данными.
Если большинство пользователей говорит, что система работает так себе, то принимаем индекс APDEX за 0,65 – плохо, выясняем реальное время выполнения операции и на его основании рассчитываем желаемое T.
А это уже меняет все. Теперь вы не пытаетесь угадать, как сделать чтобы все было хорошо или чем еще они недовольны, а получаете определенный показатель, к которому надо стремиться.
Каким путем вы этого добьетесь – это уже совершенно иной вопрос, но ведь именно вы технический специалист и именно вам за это платят деньги.
Также APDEX всегда позволяет дать ответ в каком текущем состоянии находится наша система и вовремя обосновать тот же апгрейд показав руководству вполне объективные данные, которые подтвердят, что жалобы пользователей имеют под собой реальные основания.
В комментариях нас уже несколько раз спросили, как мы оцениваем «реальную производительность» наших систем. Вопрос хороший, непростой вопрос.
Мы специально взяли фразу «реальная производительность» в кавычки, потому что за ней кроется нечто непонятное, которое каждый понимает по-своему. Вот прямо сейчас попробуйте отвлечься от прочтения заметки и попытайтесь сформулировать определение этому термину.
Скорее всего это будет синтетическая оценка в попугаях какого-либо популярного теста. Но если вас тут же спросят – а насколько хорошо будет работать на такой конфигурации некоторое бизнес-приложение вы вряд ли сможете дать точный ответ.
А теперь сделаем некоторое лирическое отступление. IT-отдел подразделение сугубо затратное, прибыли оно не приносит. Его задача обеспечивать бизнес-процессы. Прибыль при этом генерируют совсем другие подразделения.
Задача бизнеса – зарабатывать деньги. Бизнесу все равно насколько оно там технически правильно или какая «реальная производительность» в попугаях. Ему это не интересно, ему нужно чтобы работали производящие прибыль подразделения и поэтому мнение пользователей этих подразделений всегда будет иметь больший вес, чем мнение обслуживающих их айтишников.
Если пользователи такого подразделения говорят, что система работает плохо, то вы можете до посинения показывать результаты бенчмарков и уверять, что с вашей стороны все хорошо, вон целых 100 попугаев по Гилеву, должно все летать… Ответ будет прост – не летает, пользователи недовольны.
А в соседней конторе может стоять точно такой же сервер, с точной такой же конфигурацией 1С и там все довольны. Это как так? Почему?
Потому что нельзя оценивать производительность только по техническим характеристиками и синтетическим бенчмаркам. К счастью, все уже придумано до нас – открытый международный стандарт оценки производительности корпоративных приложений – APDEX.
Основным фактором влияния для APDEX является целевое время выполнения операции, если операция укладывается в период T – все довольны, если выходит за пределы 4T – полностью разочарованы.
Собранные результаты обрабатываются и нормируются по шкале от 0 до 1, где 0 – полностью разочарованы, 1 – полностью довольны.
👉 Результаты интерпретируются по шкале:
▫️0.00 - 0.50 неприемлемо
▫️0.50 - 0.70 очень плохо
▫️0.70 - 0.85 плохо
▫️0.85 - 0.94 хорошо
▫️0.94 - 1.00 отлично
APDEX вычисляется для каждой ключевой операции, что позволяет учесть конкретные потребности бизнеса и особенности его бизнес-процессов.
И именно APDEX даст понимание степени комфортности работы с системой и позволит не просто так крутить показатели, а добиваться именно нужных результатов. А также сразу видеть, какие именно участки требуют внимания.
Для операций можно выставить приоритет и тогда дополнительно будет видно, чем именно заняться в первую очередь.
Но позвольте, скажет иной читатель, но как мне определить время T, чтобы пользователь был доволен, это ведь некоторая умозрительная величина.
Согласны, степень довольства – величина субъективная, но APDEX как раз позволяет сопоставить субъективные ощущения с объективными данными.
Если большинство пользователей говорит, что система работает так себе, то принимаем индекс APDEX за 0,65 – плохо, выясняем реальное время выполнения операции и на его основании рассчитываем желаемое T.
А это уже меняет все. Теперь вы не пытаетесь угадать, как сделать чтобы все было хорошо или чем еще они недовольны, а получаете определенный показатель, к которому надо стремиться.
Каким путем вы этого добьетесь – это уже совершенно иной вопрос, но ведь именно вы технический специалист и именно вам за это платят деньги.
Также APDEX всегда позволяет дать ответ в каком текущем состоянии находится наша система и вовремя обосновать тот же апгрейд показав руководству вполне объективные данные, которые подтвердят, что жалобы пользователей имеют под собой реальные основания.
🤔21👍9❤4🤮2
Как оценить многопоточную производительность сервера 1С:Предприятие?
Все знают тест Гилева, который стал стандартом де-факто для оценки производительности серверов 1С. Но далеко не все умеют правильно применять и интерпретировать его результаты.
Если коротко – то тест Гилева однопоточный и показывает производительность одного сеанса 1С:Предприятие на текущем железе с текущими настройками. Он может помочь правильно настроить железо или понять, что на этой конфигурации лучше не продолжать, но как она поведет себя под многопоточной нагрузкой этот тест сказать не может.
Мы можем взять два разных ПК и получить на них одинаково высокие результаты в Гилеве, но абсолютно разное поведение под нагрузкой.
👉 Как быть? Взять другой инструмент - Многопоточный тест производительности 1с (Fragster). Он не настолько популярен и раскручен как тест Гилева, но позволяет оценить именно многопоточную производительность.
Данный тест запускает многочисленные сеансы и производит одни и те же вычисления, фиксируя общую производительность и производительность отдельного сеанса. После чего мы можем сравнить значения и проверить как наше оборудование держит нагрузку.
Сам автор предлагает интерпретировать результаты следующими образом:
🔹Нижняя граница - 400-500 попугаев на поток (это когда еще «терпимо»)
🔹 Нормально:
▫️ >2000 для РС на 4 потоках
▫️ >1500 для РН на 4 потоках
▫️ >1000 для РБ на 4 потоках
Чтобы не быть голословными рассмотрим реальные тесты, которые предоставили пользователи. Сам пользователь пишет, что на сервере 50 активных сеансов и оценка пользователей комфортности работы – 4 балла.
Что мы видим? На 4 потока результаты немного ниже требуемой отметки для регистров сведения и хорошо для регистров накопления и бухгалтерии. Т.е. работа с небольшой нагрузкой будет преимущественно комфортной.
Если рассматривать многопоточность, то сервер хорошо масштабируется до 32 сеансов и начинает сдавать при большем количестве. После 60 сеансов производительность не растет, но и критического ухудшения еще не происходит.
Критическая отметка – 80 сеансов, сервер серьезно перегружен и уже не вывозит. Если снова вернуться к однопоточному графику, то как раз на этом промежутке 60-80 сеансов производительность достигает нижней планки терпимости.
В целом результаты соответствуют субъективным ощущениям, с учетом того, что 50 активных сеансов не генерируют одномоментно высокую нагрузку работу с таким сервером, можно оценить на 4 балла, но запаса по количеству пользователей у него практически нет. Добавление сеансов повлечет ощутимое падение производительности.
Все знают тест Гилева, который стал стандартом де-факто для оценки производительности серверов 1С. Но далеко не все умеют правильно применять и интерпретировать его результаты.
Если коротко – то тест Гилева однопоточный и показывает производительность одного сеанса 1С:Предприятие на текущем железе с текущими настройками. Он может помочь правильно настроить железо или понять, что на этой конфигурации лучше не продолжать, но как она поведет себя под многопоточной нагрузкой этот тест сказать не может.
Мы можем взять два разных ПК и получить на них одинаково высокие результаты в Гилеве, но абсолютно разное поведение под нагрузкой.
👉 Как быть? Взять другой инструмент - Многопоточный тест производительности 1с (Fragster). Он не настолько популярен и раскручен как тест Гилева, но позволяет оценить именно многопоточную производительность.
Данный тест запускает многочисленные сеансы и производит одни и те же вычисления, фиксируя общую производительность и производительность отдельного сеанса. После чего мы можем сравнить значения и проверить как наше оборудование держит нагрузку.
Сам автор предлагает интерпретировать результаты следующими образом:
🔹Нижняя граница - 400-500 попугаев на поток (это когда еще «терпимо»)
🔹 Нормально:
▫️ >2000 для РС на 4 потоках
▫️ >1500 для РН на 4 потоках
▫️ >1000 для РБ на 4 потоках
Чтобы не быть голословными рассмотрим реальные тесты, которые предоставили пользователи. Сам пользователь пишет, что на сервере 50 активных сеансов и оценка пользователей комфортности работы – 4 балла.
Что мы видим? На 4 потока результаты немного ниже требуемой отметки для регистров сведения и хорошо для регистров накопления и бухгалтерии. Т.е. работа с небольшой нагрузкой будет преимущественно комфортной.
Если рассматривать многопоточность, то сервер хорошо масштабируется до 32 сеансов и начинает сдавать при большем количестве. После 60 сеансов производительность не растет, но и критического ухудшения еще не происходит.
Критическая отметка – 80 сеансов, сервер серьезно перегружен и уже не вывозит. Если снова вернуться к однопоточному графику, то как раз на этом промежутке 60-80 сеансов производительность достигает нижней планки терпимости.
В целом результаты соответствуют субъективным ощущениям, с учетом того, что 50 активных сеансов не генерируют одномоментно высокую нагрузку работу с таким сервером, можно оценить на 4 балла, но запаса по количеству пользователей у него практически нет. Добавление сеансов повлечет ощутимое падение производительности.
👍19👀5⚡1❤1
🚘 После 1 ноября любые авто свыше 160 л.с. смогут купить только на московские зарплаты!
С 1 ноября планируется повышение утилизационного сбора на машины мощнее 160 л.с. Даже авто до 160 л.с. подорожают косвенно – из-за роста спроса и дефицита.
Все импортеры уже готовятся к изменениям, а многие жители страны понимают: скоро придётся пересаживаться на авто мощностью до 160 л.с., чтобы не переплачивать.
Чтобы помочь вам сэкономить, мы собрали подборку авто до 160 л.с., на которые утилизационный сбор не повысится. Это проверенные варианты, которые можно оформить по старым ценам – никаких переплат!
👋 Я – Влад, помогаю покупать автомобили из Кореи, Японии и Китая:
– Собственные парковки в Корее и Китае – никакого риска и "левых рук"
– Фото/видео каждого этапа – вы видите всё
– Полная ответственность – от царапин до коробки передач
– Оплата проходит напрямую – деньги всегда под контролем
– Стоимость фиксирована и прозрачна, без навязанных услуг
В нашем Telegram-канале каждый день выкладываем новые варианты авто до 160 л.с., которые ещё можно успеть оформить по старым ценам и не переплачивать:
https://tglink.io/57110882d10f?erid=2W5zFJRBkUg.
С 1 ноября планируется повышение утилизационного сбора на машины мощнее 160 л.с. Даже авто до 160 л.с. подорожают косвенно – из-за роста спроса и дефицита.
Все импортеры уже готовятся к изменениям, а многие жители страны понимают: скоро придётся пересаживаться на авто мощностью до 160 л.с., чтобы не переплачивать.
Чтобы помочь вам сэкономить, мы собрали подборку авто до 160 л.с., на которые утилизационный сбор не повысится. Это проверенные варианты, которые можно оформить по старым ценам – никаких переплат!
👋 Я – Влад, помогаю покупать автомобили из Кореи, Японии и Китая:
– Собственные парковки в Корее и Китае – никакого риска и "левых рук"
– Фото/видео каждого этапа – вы видите всё
– Полная ответственность – от царапин до коробки передач
– Оплата проходит напрямую – деньги всегда под контролем
– Стоимость фиксирована и прозрачна, без навязанных услуг
В нашем Telegram-канале каждый день выкладываем новые варианты авто до 160 л.с., которые ещё можно успеть оформить по старым ценам и не переплачивать:
https://tglink.io/57110882d10f?erid=2W5zFJRBkUg.
🤡6❤1
Стоит ли отрицать современные тренды?
Каждый раз при обсуждении виртуализации, контейнеризации и т.п. слышим мнения: мол зачем это нужно у меня и так все хорошо работает…
Начнем с того, что сфера IT во всех ее проявлениях весьма динамична и здесь, как в Алисе: «Нужно бежать со всех ног, чтобы только оставаться на месте»
Если вы выпадаете на несколько лет из актуальной повестки, то можете уже не узнать окружающую вас реальность, все будут говорить о чем-то непонятном и смотреть на вас как на динозавра.
Хорошо, если вы сможете быстро адаптироваться и устранить пробелы, а если такой возможности нет? В таком случае вы выпадаете не только из технологий, но и с рынка труда, где уже не можете претендовать на серьезные вакансии, а на начальный уровень скорее возьмут молодого мальчика, чем взрослого дядьку.
На первое место среди кладбищ кадров я бы поставил бюджетные организации. Там не только прекращается развитие специалиста, но и вообще прививаются крайне вредные привычки, вроде имитации работы и написания красивых отчетов.
В бюджетке важно, чтобы все было прикрыто бумагами и худо-бедно работало. А если не работает, то обязательно по уважительной причине, отраженной в куче отчетов, докладных записок и т.д.
Я сам на заре трудовой деятельности отработал два года в сельскохозяйственном НИИ и прекрасно освоил процесс имитации бурной деятельности. А реальная работа могла сутками стоять, потому что есть «гораздо более важные» дела.
Второй бич бюджетки – это отношения «ты начальник – я дурак, я начальник – ты дурак» и связанные с ними бесконечные согласования, обсуждения и т.п. После того, как я ушел оттуда в частную фирму мой новый начальник еще с полгода закрывал лицо рукой и устало произносил: «ну, когда ты начнешь работать самостоятельно???»
В коммерции все немного бодрее, но до поры до времени. После того как найдена некая оптимальная конфигурация IT-инфраструктуры наступает пора стабилизации и это нормально. Но очень часто она выливается в застой.
Появляется определенная зона комфорта. Действительно, а зачем учить что-то новое, если и так все работает? Зачем что-то внедрять, рисковать, тратить время и нервы, когда можно ничего не делать и получать те же деньги?
Вот так, незаметно, стабильность сменяется застоем, а некогда актуальная инфраструктура начинает стремительно устаревать. Причем чем дольше заметать пыль под ковер, делая вид что все хорошо, то тем хуже становится в последствии.
Обычно то, что с IT что-то не так до руководства доходит слишком поздно, когда начинают ломаться бизнес-процессы или возникает серьезная проблема с внедрением нововведений, как законодательных, так и сервисных, призванных улучшить обслуживание клиентов или внутренних подразделений.
В этом случае выясняется, что проще все сломать и построить заново, нежели приводить то, что есть в порядок и вряд ли ваша карьера в этом месте продолжит дальше катиться по накатанной.
Ну и третья категория, это «узкие» специалисты. Тут вообще разговор отдельный, более проходящий по теме религиозного фанатизма, нежели информационных технологий.
Это любители ставить в продакшен Gentoo, FreeBSD, Solaris и тому подобную экзотику, прекрасно понимая, что в обозримом пространстве специалистов по этой системе не найти и они вроде как на коне.
Проблемы начинаются, когда список задач выходит за пределы знаний и умений такого специалиста, а приглашенные со стороны либо умывают руки, либо выставляют космический прайс.
Я понимаю, что редкий стек – это греет душу и поднимает самооценку, но, будем смотреть правде в глаза – на рынке труда стоимость этих знаний близка к нулю.
Вот сейчас поиск на HH по слову Linux показывает в Москве 44 166 вакансии, по слову FreeBSD – всего 1 776. И это при том, что коммерческая разработка у нас нацелена на DEB/RPM и нестандартная ОС автоматически означает отсутствие официальной поддержки.
Поэтому, коллеги, трезво оцените свое положение и если вы все такие попали в описанное выше болото, то найдите силы это признать и начинайте из него выбираться.
Каждый раз при обсуждении виртуализации, контейнеризации и т.п. слышим мнения: мол зачем это нужно у меня и так все хорошо работает…
Начнем с того, что сфера IT во всех ее проявлениях весьма динамична и здесь, как в Алисе: «Нужно бежать со всех ног, чтобы только оставаться на месте»
Если вы выпадаете на несколько лет из актуальной повестки, то можете уже не узнать окружающую вас реальность, все будут говорить о чем-то непонятном и смотреть на вас как на динозавра.
Хорошо, если вы сможете быстро адаптироваться и устранить пробелы, а если такой возможности нет? В таком случае вы выпадаете не только из технологий, но и с рынка труда, где уже не можете претендовать на серьезные вакансии, а на начальный уровень скорее возьмут молодого мальчика, чем взрослого дядьку.
На первое место среди кладбищ кадров я бы поставил бюджетные организации. Там не только прекращается развитие специалиста, но и вообще прививаются крайне вредные привычки, вроде имитации работы и написания красивых отчетов.
В бюджетке важно, чтобы все было прикрыто бумагами и худо-бедно работало. А если не работает, то обязательно по уважительной причине, отраженной в куче отчетов, докладных записок и т.д.
Я сам на заре трудовой деятельности отработал два года в сельскохозяйственном НИИ и прекрасно освоил процесс имитации бурной деятельности. А реальная работа могла сутками стоять, потому что есть «гораздо более важные» дела.
Второй бич бюджетки – это отношения «ты начальник – я дурак, я начальник – ты дурак» и связанные с ними бесконечные согласования, обсуждения и т.п. После того, как я ушел оттуда в частную фирму мой новый начальник еще с полгода закрывал лицо рукой и устало произносил: «ну, когда ты начнешь работать самостоятельно???»
В коммерции все немного бодрее, но до поры до времени. После того как найдена некая оптимальная конфигурация IT-инфраструктуры наступает пора стабилизации и это нормально. Но очень часто она выливается в застой.
Появляется определенная зона комфорта. Действительно, а зачем учить что-то новое, если и так все работает? Зачем что-то внедрять, рисковать, тратить время и нервы, когда можно ничего не делать и получать те же деньги?
Вот так, незаметно, стабильность сменяется застоем, а некогда актуальная инфраструктура начинает стремительно устаревать. Причем чем дольше заметать пыль под ковер, делая вид что все хорошо, то тем хуже становится в последствии.
Обычно то, что с IT что-то не так до руководства доходит слишком поздно, когда начинают ломаться бизнес-процессы или возникает серьезная проблема с внедрением нововведений, как законодательных, так и сервисных, призванных улучшить обслуживание клиентов или внутренних подразделений.
В этом случае выясняется, что проще все сломать и построить заново, нежели приводить то, что есть в порядок и вряд ли ваша карьера в этом месте продолжит дальше катиться по накатанной.
Ну и третья категория, это «узкие» специалисты. Тут вообще разговор отдельный, более проходящий по теме религиозного фанатизма, нежели информационных технологий.
Это любители ставить в продакшен Gentoo, FreeBSD, Solaris и тому подобную экзотику, прекрасно понимая, что в обозримом пространстве специалистов по этой системе не найти и они вроде как на коне.
Проблемы начинаются, когда список задач выходит за пределы знаний и умений такого специалиста, а приглашенные со стороны либо умывают руки, либо выставляют космический прайс.
Я понимаю, что редкий стек – это греет душу и поднимает самооценку, но, будем смотреть правде в глаза – на рынке труда стоимость этих знаний близка к нулю.
Вот сейчас поиск на HH по слову Linux показывает в Москве 44 166 вакансии, по слову FreeBSD – всего 1 776. И это при том, что коммерческая разработка у нас нацелена на DEB/RPM и нестандартная ОС автоматически означает отсутствие официальной поддержки.
Поэтому, коллеги, трезво оцените свое положение и если вы все такие попали в описанное выше болото, то найдите силы это признать и начинайте из него выбираться.
👍38🤮8❤3😢3🤝1
Их нравы
Эрик Рэймонд (Eric S. Raymond), один из основателей организации OSI (Open Source Initiative), стоявший у истоков движения открытого ПО, высказался по поводу кодексов поведения:
✅ Источник: https://www.opennet.ru/opennews/art.shtml?num=63968
Мне казалось, что этого уже никогда не случится там. Но, оказывается, голос разума пробивается свозь «повесточку».
Потому что ты или приносишь пользу сообществу, невзирая на то, что ты какой-то такой или не такой, или пользы не приносишь, а только суету.
В первом случае ты его уважаемый участник, во втором нафиг сообществу нужен. Вот и всё.
А все эти спекуляции « я не такая, я жду трамвая» оставьте где-нибудь в другом месте.
Что я, что многие мои коллеги исходим из принципа: ты или выполняешь свою работу, либо нет. Соответствуешь квалификации – либо нет. А то, что ты там ешь, с кем спишь, какие у тебя политические и религиозные предпочтения – дело сугубо личное.
Ровно, как и попытки ущемиться по этому поводу. Потому что выгоняют тебя не потому, что ты спишь на потолке, а потому что ты дурак и токсичен. Ничего личного.
Эрик Рэймонд (Eric S. Raymond), один из основателей организации OSI (Open Source Initiative), стоявший у истоков движения открытого ПО, высказался по поводу кодексов поведения:
Я собираюсь сделать то, чего, по-моему, никогда раньше не делал, а именно: использовать весь свой авторитет как человека, который открыл и записал правила открытого исходного кода.
После десяти лет драмы и идиотизма многие люди, помимо меня, теперь готовы публично заявить, что «кодексы поведения» оказались катастрофой — своего рода заразным социальным безумием, порождающим драму, политические интриги, сплетни и отрицательную полезную работу.
Вот мой совет по поводу кодексов поведения:
▫️ 1. Откажитесь от него. Если у вашего проекта есть такой кодекс, удалите его. Единственная реальная функция, которую он выполняет, — это инструмент в руках тех, кто любит подливать масла в огонь.
▫️ 2. Если вы вынуждены иметь такой кодекс по бюрократическим причинам, замените его следующим предложением или чем-то подобным: «Если вы доставляете больше хлопот, чем оправдывают ваши вклады, вы будете отстранены».
▫️ 3.Попытки делать кодексы более конкретными и подробными не работают. Они только дают провокаторам возможность манипулировать.
Да, мы должны стараться быть добрыми друг к другу. Но мы должны быть безжалостными и беспощадными по отношению к людям, которые пытаются превратить «Давайте быть добрее!» в оружие. Потакание им никогда не заканчивается хорошо.
✅ Источник: https://www.opennet.ru/opennews/art.shtml?num=63968
Мне казалось, что этого уже никогда не случится там. Но, оказывается, голос разума пробивается свозь «повесточку».
Потому что ты или приносишь пользу сообществу, невзирая на то, что ты какой-то такой или не такой, или пользы не приносишь, а только суету.
В первом случае ты его уважаемый участник, во втором нафиг сообществу нужен. Вот и всё.
А все эти спекуляции « я не такая, я жду трамвая» оставьте где-нибудь в другом месте.
Что я, что многие мои коллеги исходим из принципа: ты или выполняешь свою работу, либо нет. Соответствуешь квалификации – либо нет. А то, что ты там ешь, с кем спишь, какие у тебя политические и религиозные предпочтения – дело сугубо личное.
Ровно, как и попытки ущемиться по этому поводу. Потому что выгоняют тебя не потому, что ты спишь на потолке, а потому что ты дурак и токсичен. Ничего личного.
1👍37❤3👏1
Forwarded from FBM API Insights
С 17 сентября в мессенджере Max можно создавать каналы
Общее количество постов на платформе за три недели увеличилось втрое, а многие новые каналы уже успели набрать солидную аудиторию!
Таким образом, Max активно растет, привлекая новых пользователей, а значит и перспективы мессенджера набирают обороты. Именно поэтому сейчас — самое время заявить о себе, пока платформа на этапе раскачки и аудиторию будет набрать легче
Реклама. Трусова В.С. ИНН 575311118281. erid: 2W5zFJ2vFqr
Please open Telegram to view this post
VIEW IN TELEGRAM
🤣25👎12🤮11👌4🤡1