Авторское право – не пустой звук. Часть 3
В прошлой части мы разобрали, какие объекты авторского права можно использовать и на каких основаниях, но остались некоторые тонкости, которые мы сегодня рассмотрим.
Статья 1274 ГК РФ прямо говорит, что допустимо использование:
А где и как искать этот объем? Начнем с цели. Какая цель вашего произведения? Именно от этого будет исходить объем. Допустим, вы описываете некоторую материнскую плату – тогда для достижения поставленной цели вы правомерно можете использовать общий вид, фото со стороны разъёмов и т.д.
Но если вы пишете общую статью, скажем об оперативной памяти и поставили на КДПВ (картинка для привлечения внимания) какую-нибудь художественную фотографию с планкой ОЗУ, где не только сама планка, но еще и сюжет, фон, модель – это однозначно нарушение.
А вообще общий принцип прост – если данный объект авторского права можно исключить из вашего произведения, и оно не пострадает – то его нужно исключить, так как его применение не оправдано поставленной целью.
Потому что когда у вас в тексте «посмотрим на скриншот и увидим» или «вот фото устройства в разобранном виде, обратите внимание», то изображения становятся неотъемлемой частью произведения, если их убрать, то станет непонятно, о чем идет речь.
С целью поняли, а что с объемами? Тут тоже следует исходить из того, то заимствованный материал не должен составлять основную часть вашего произведения. В журналистской и редакторской среде действует эмпирическое правило 30%.
Т.е. вы не должны заимствовать более 30% исходного произведения и общий процент заимствований в вашем произведении не должен превышать 30%.
Но это общее эмпирическое правило, в реальности объем всегда зависит от поставленной цели. Скажем, вы пишете статью про историю вычислительной техники. Тематика не позволяет вам самостоятельно создать иллюстрации и поэтому заимствование чужих изображений в полном объеме оправданно заявленной целью.
Следующий момент, демонстрация чужих объектов авторского права на скриншотах, например, обоев рабочего стола. Тема тоже очень скользкая, которая в итоге сводится к правомерности воспроизведения объекта в определенном окружении.
Скажем, в дистрибутиве Simply Linux от Альт есть отличные авторские обои. Показывать их на скриншотах дистрибутива полностью допустимо, правообладатель сам разрешил их использование в составе ОС, а вы показываете внешний вид ОС.
Но стоит вам выложить этот файл изображения отдельно – вы нарушили чужое право, автор не разрешал использовать это изображение отдельно от дистрибутива.
Или, скажем, вы использовали известное изображение Bliss (Безмятежность) из Windows XP как фон рабочего стола Linux и наделали там скриншотов. Поздравляем, вы только что грубо нарушили авторское право.
Статья 1273 ГК РФ разрешает свободное воспроизведение произведения в личных целях, т.е. вы имеете полное право поставить такое изображение на рабочий стол вашей Linux-системы. Но вот публично демонстрировать вы его права не имеете.
Это же касается любых изображений, защищенных авторским правом, поставить на рабочий стол можно, публично демонстрировать нельзя. Поэтому если вы снимаете скриншоты какой-либо системы, то поставьте туда стандартные обои.
Ну и не забывайте, что даже свободно распространяемые изображения имеют своего автора и лицензию, с которыми бывает полезно ознакомиться.
Потому что свободно не означает бесплатно и на такое использование могут быть наложены некоторые ограничения.
В прошлой части мы разобрали, какие объекты авторского права можно использовать и на каких основаниях, но остались некоторые тонкости, которые мы сегодня рассмотрим.
Статья 1274 ГК РФ прямо говорит, что допустимо использование:
правомерно обнародованных произведений и отрывков из них в качестве иллюстраций … в объеме, оправданном поставленной целью
А где и как искать этот объем? Начнем с цели. Какая цель вашего произведения? Именно от этого будет исходить объем. Допустим, вы описываете некоторую материнскую плату – тогда для достижения поставленной цели вы правомерно можете использовать общий вид, фото со стороны разъёмов и т.д.
Но если вы пишете общую статью, скажем об оперативной памяти и поставили на КДПВ (картинка для привлечения внимания) какую-нибудь художественную фотографию с планкой ОЗУ, где не только сама планка, но еще и сюжет, фон, модель – это однозначно нарушение.
А вообще общий принцип прост – если данный объект авторского права можно исключить из вашего произведения, и оно не пострадает – то его нужно исключить, так как его применение не оправдано поставленной целью.
Потому что когда у вас в тексте «посмотрим на скриншот и увидим» или «вот фото устройства в разобранном виде, обратите внимание», то изображения становятся неотъемлемой частью произведения, если их убрать, то станет непонятно, о чем идет речь.
С целью поняли, а что с объемами? Тут тоже следует исходить из того, то заимствованный материал не должен составлять основную часть вашего произведения. В журналистской и редакторской среде действует эмпирическое правило 30%.
Т.е. вы не должны заимствовать более 30% исходного произведения и общий процент заимствований в вашем произведении не должен превышать 30%.
Но это общее эмпирическое правило, в реальности объем всегда зависит от поставленной цели. Скажем, вы пишете статью про историю вычислительной техники. Тематика не позволяет вам самостоятельно создать иллюстрации и поэтому заимствование чужих изображений в полном объеме оправданно заявленной целью.
Следующий момент, демонстрация чужих объектов авторского права на скриншотах, например, обоев рабочего стола. Тема тоже очень скользкая, которая в итоге сводится к правомерности воспроизведения объекта в определенном окружении.
Скажем, в дистрибутиве Simply Linux от Альт есть отличные авторские обои. Показывать их на скриншотах дистрибутива полностью допустимо, правообладатель сам разрешил их использование в составе ОС, а вы показываете внешний вид ОС.
Но стоит вам выложить этот файл изображения отдельно – вы нарушили чужое право, автор не разрешал использовать это изображение отдельно от дистрибутива.
Или, скажем, вы использовали известное изображение Bliss (Безмятежность) из Windows XP как фон рабочего стола Linux и наделали там скриншотов. Поздравляем, вы только что грубо нарушили авторское право.
Статья 1273 ГК РФ разрешает свободное воспроизведение произведения в личных целях, т.е. вы имеете полное право поставить такое изображение на рабочий стол вашей Linux-системы. Но вот публично демонстрировать вы его права не имеете.
Это же касается любых изображений, защищенных авторским правом, поставить на рабочий стол можно, публично демонстрировать нельзя. Поэтому если вы снимаете скриншоты какой-либо системы, то поставьте туда стандартные обои.
Ну и не забывайте, что даже свободно распространяемые изображения имеют своего автора и лицензию, с которыми бывает полезно ознакомиться.
Потому что свободно не означает бесплатно и на такое использование могут быть наложены некоторые ограничения.
👍6👌1🥱1
Тонкая настройка systemd-journald
Классическая ситуация – все место на диске занято логами, либо логи создают излишнюю нагрузку на систему ввода вывода.
Чтобы этого не случилось – логирование нужно настроить в соответствии с реальными потребностями и сегодня мы посмотрим, как это сделать для systemd-journald.
Прежде всего посмотрим текущие настройки, это можно сделать командой:
По умолчанию все значение в нем закомментированы и представляют настройки службы по умолчанию. Для изменения вы можете использовать данный файл, но официально рекомендуется использовать технологию "drop-ins" и хранить настройки в отдельных файлах.
Создадим для этого директорию:
А в нем один или несколько файлов с изменениями конфигурации, в нашем случае это будет
Начнем с места хранения логов. Для сохранения на диск используйте:
Это более надежно, чем auto, которое может иногда приводить к сюрпризам. Если же вам не нужна запись логов на диск, но вы хотите иметь их для диагностики и отладки используйте хранение в оперативной памяти. Такой метод рекомендуется для виртуальных машин и контейнеров, а также встраиваемых устройств и мини-ПК.
Затем проверьте опции:
Первая из них включает сжатие логов, вторая – криптографическую защиту, обычно обе включены по умолчанию.
Хранить логи – это хорошо, но не ограничивать размер – очень плохо, поэтому сразу озаботимся этим:
Первая опция задает максимальный размер хранилища логов, а второй нижний предел свободного места. Таким образом мы будем хранить не более одного гигабайта логов, но при условии, что в системе остается не менее 2 ГБ свободного места.
Если вы храните данные в ОЗУ, то используйте следующие опции аналогичного назначения:
Опции
Задают максимальный размер одного файла журнала и их общее количество, по умолчанию systemd-journald создает файлы размером 8 МБ.
Для хранения в оперативной памяти аналогичные опции:
Следующие важные настройки – это уровни логирования, в продуктивных средах нет необходимости хранить логи уровня debug, будет вполне достаточно info или notice. Поэтому замените debug на более низкий уровень логирования в этих трех опциях:
Данный набор опций отвечает за пересылку логов в syslog, kernel buffer, консоль и отправку сообщения пользователям.
Настройки по умолчанию (указаны выше) оптимальны и без необходимости пересылку включать не следует. Единственная включенная пересылка – это отправка пользователям сообщений уровня emerg (катастрофический сбой).
Еще одна важная опция – это лимиты, позволяющие избегать засорения логов однотипными сообщениями. По умолчанию имеет следующие значения:
Это означает, что в течении 30 секунд можно отправить в лог не более 10 000 сообщений. Обратите внимание, что данный лимит действует для каждого источника событий, а не для всей системы.
В высоконагруженных системах лимит можно повысить, например, для гипервизоров, где виртуалки при старте могут быть достаточно «разговорчивы». В виртуальных средах, наоборот, имеет смысл понизить этот лимит, чтобы избежать массового спама логов сбойным сервисом.
Классическая ситуация – все место на диске занято логами, либо логи создают излишнюю нагрузку на систему ввода вывода.
Чтобы этого не случилось – логирование нужно настроить в соответствии с реальными потребностями и сегодня мы посмотрим, как это сделать для systemd-journald.
Прежде всего посмотрим текущие настройки, это можно сделать командой:
cat /etc/systemd/journald.conf
По умолчанию все значение в нем закомментированы и представляют настройки службы по умолчанию. Для изменения вы можете использовать данный файл, но официально рекомендуется использовать технологию "drop-ins" и хранить настройки в отдельных файлах.
Создадим для этого директорию:
mkdir -p /etc/systemd/journald.conf.d
А в нем один или несколько файлов с изменениями конфигурации, в нашем случае это будет
00-journal.conf куда мы будем вносить изменившиеся опции.Начнем с места хранения логов. Для сохранения на диск используйте:
Storage=persistent
Это более надежно, чем auto, которое может иногда приводить к сюрпризам. Если же вам не нужна запись логов на диск, но вы хотите иметь их для диагностики и отладки используйте хранение в оперативной памяти. Такой метод рекомендуется для виртуальных машин и контейнеров, а также встраиваемых устройств и мини-ПК.
Storage=volatile
Затем проверьте опции:
Compress=yes
Seal=yes
Первая из них включает сжатие логов, вторая – криптографическую защиту, обычно обе включены по умолчанию.
Хранить логи – это хорошо, но не ограничивать размер – очень плохо, поэтому сразу озаботимся этим:
SystemMaxUse=1G
SystemKeepFree=2G
Первая опция задает максимальный размер хранилища логов, а второй нижний предел свободного места. Таким образом мы будем хранить не более одного гигабайта логов, но при условии, что в системе остается не менее 2 ГБ свободного места.
Если вы храните данные в ОЗУ, то используйте следующие опции аналогичного назначения:
RuntimeMaxUse=64M
RuntimeKeepFree=256M
Опции
SystemMaxFileSize=
SystemMaxFiles=100
Задают максимальный размер одного файла журнала и их общее количество, по умолчанию systemd-journald создает файлы размером 8 МБ.
Для хранения в оперативной памяти аналогичные опции:
RuntimeMaxFileSize=
RuntimeMaxFiles=100
Следующие важные настройки – это уровни логирования, в продуктивных средах нет необходимости хранить логи уровня debug, будет вполне достаточно info или notice. Поэтому замените debug на более низкий уровень логирования в этих трех опциях:
MaxLevelStore=debug
MaxLevelSyslog=debug
MaxLevelSocket=debug
Данный набор опций отвечает за пересылку логов в syslog, kernel buffer, консоль и отправку сообщения пользователям.
ForwardToSyslog=no
ForwardToKMsg=no
ForwardToConsole=no
ForwardToWall=yes
Настройки по умолчанию (указаны выше) оптимальны и без необходимости пересылку включать не следует. Единственная включенная пересылка – это отправка пользователям сообщений уровня emerg (катастрофический сбой).
Еще одна важная опция – это лимиты, позволяющие избегать засорения логов однотипными сообщениями. По умолчанию имеет следующие значения:
RateLimitIntervalSec=30s
RateLimitBurst=10000
Это означает, что в течении 30 секунд можно отправить в лог не более 10 000 сообщений. Обратите внимание, что данный лимит действует для каждого источника событий, а не для всей системы.
В высоконагруженных системах лимит можно повысить, например, для гипервизоров, где виртуалки при старте могут быть достаточно «разговорчивы». В виртуальных средах, наоборот, имеет смысл понизить этот лимит, чтобы избежать массового спама логов сбойным сервисом.
👍9🔥5❤1
AppArmor-шум или тонкие настройки логов в LXC-контейнерах Proxmox
Изучая системный журнал Proxmox, вы можете обнаружить целые блоки записей вида:
Они не свидетельствуют о каких-либо проблемах и могут быть проигнорированы, однако таких записей может быть много, что серьезно засоряет лог и затрудняет его чтение.
Но что это вообще за записи? Давайте разберемся. Как мы можем видеть источником записи является служба rsyslogd контейнера, которая хочет получить доступ к dev-log хоста, чтобы что-то записать в системный лог, но AppArmor ей в этом препятствует.
В общем и целом, в rsyslogd для контейнеров нет особой нужны, она только дублирует работу systemd-journald, поэтому его можно отключить, это полностью решит проблему AppArmor-шума.
Но мы пойдем немного дальше и подумаем, а нужны ли нам вообще системные логи в контейнерах? Чтобы посмотреть, что systemd-journald туда пишет запустите:
Ситуация дополнительно усугубляется тем, что такие логи пишет каждый контейнер, создавая дополнительную нагрузку на диск, хотя данные логи фактически бесполезны.
Радикальное решение – отключить логирование вообще, но это может затруднить отладку и диагностику в контейнере. Поэтому мы пойдем другим путем и настроим логирование.
Так как нам нет необходимости хранить системные логи, то мы разместим их в оперативной памяти, тем самым снизив нагрузку на дисковую подсистему хоста.
Такое решение позволит нам иметь логи для диагностики и отладки, но не засорять ими память и не создавать лишнюю нагрузку. Также отключим службу rsyslogd за ненадобностью.
Начнем:
Затем создадим директорию
А в ней создадим и откроем на редактирование файл:
В который внесем следующее содержимое:
Первые две строки предписывают использовать для логов оперативную память и задают доступный размер (в нашем случае 64 МБ).
Последняя строка запрещает перенаправлять события в syslog, несмотря на то что мы отключили rsyslog данная опция не будет лишней, потому что по умолчанию systemd-journald перенаправляет туда каждое событие.
Да, они будут перенаправляться в никуда, но зачем вообще тратить на это ресурсы? А в некоторых конфигурациях это может стать дополнительным источником сообщений в логах.
Сохраняем содержимое файла и перезапускаем службу:
Проверяем, AppArmor-шум должен полностью прекратиться, а логи теперь собираются в оперативную память и не расходуют ресурсы хоста.
Изучая системный журнал Proxmox, вы можете обнаружить целые блоки записей вида:
apparmor="DENIED" operation="sendmsg" class="file" namespace="root//lxc-803_<-var-lib-lxc>" profile="rsyslogd" name="/run/systemd/journal/dev-log"
Они не свидетельствуют о каких-либо проблемах и могут быть проигнорированы, однако таких записей может быть много, что серьезно засоряет лог и затрудняет его чтение.
Но что это вообще за записи? Давайте разберемся. Как мы можем видеть источником записи является служба rsyslogd контейнера, которая хочет получить доступ к dev-log хоста, чтобы что-то записать в системный лог, но AppArmor ей в этом препятствует.
В общем и целом, в rsyslogd для контейнеров нет особой нужны, она только дублирует работу systemd-journald, поэтому его можно отключить, это полностью решит проблему AppArmor-шума.
Но мы пойдем немного дальше и подумаем, а нужны ли нам вообще системные логи в контейнерах? Чтобы посмотреть, что systemd-journald туда пишет запустите:
journalctl -f
Ситуация дополнительно усугубляется тем, что такие логи пишет каждый контейнер, создавая дополнительную нагрузку на диск, хотя данные логи фактически бесполезны.
Радикальное решение – отключить логирование вообще, но это может затруднить отладку и диагностику в контейнере. Поэтому мы пойдем другим путем и настроим логирование.
Так как нам нет необходимости хранить системные логи, то мы разместим их в оперативной памяти, тем самым снизив нагрузку на дисковую подсистему хоста.
Такое решение позволит нам иметь логи для диагностики и отладки, но не засорять ими память и не создавать лишнюю нагрузку. Также отключим службу rsyslogd за ненадобностью.
Начнем:
systemctl stop rsyslog
systemctl mask rsyslog
Затем создадим директорию
mkdir -p /etc/systemd/journald.conf.d
А в ней создадим и откроем на редактирование файл:
nano /etc/systemd/journald.conf.d/00-journal.conf
В который внесем следующее содержимое:
[Journal]
Storage=volatile
RuntimeMaxUse=64M
ForwardToSyslog=no
Первые две строки предписывают использовать для логов оперативную память и задают доступный размер (в нашем случае 64 МБ).
Последняя строка запрещает перенаправлять события в syslog, несмотря на то что мы отключили rsyslog данная опция не будет лишней, потому что по умолчанию systemd-journald перенаправляет туда каждое событие.
Да, они будут перенаправляться в никуда, но зачем вообще тратить на это ресурсы? А в некоторых конфигурациях это может стать дополнительным источником сообщений в логах.
Сохраняем содержимое файла и перезапускаем службу:
systemctl restart systemd-journald
Проверяем, AppArmor-шум должен полностью прекратиться, а логи теперь собираются в оперативную память и не расходуют ресурсы хоста.
👍10❤1🔥1🤮1
Принцип Питера
Принцип Питера сформулирован в 1969 году канадским педагогом и психологом Лоуренсом Дж. Питером, у нас он известен как часть Законов Мерфи.
Принцип Питера гласит:
Следствия принципа Питера:
Многие считают это всего лишь шуткой, но на самом деле подобные тенденции имеют место быть и гораздо шире, нежели этого бы хотелось.
Причина в современной корпоративной культуре, не важно – нашей или западной – вся она завязана на некоторую «эффективность» сотрудника, которая является одним из проявлений «успешного успеха».
«Эффективный» сотрудник просто не может сказать – я не готов к повышению, я что-то не знаю и не умею, мне нужно подучиться. Потому что в этом случае он остановился, когда другие продолжают бежать вперед, он теперь просто неудачник.
При этом реальной компетентности на новой должности уже не хватает. Но если можно заменить работу красивыми отчетами и плавно делегировать ее вниз – то проблемы нет.
А показав «успехи» и на этой должности можно и дальше пробиваться вверх по карьерной лестнице, до тех пор, пока выше вы не сможете вообще ничего, даже писать красивые отчеты.
В этой точке сотрудник поднялся до своего уровня некомпетентности и занял соответствующую ей должность.
Тут может быть смешно, но часто именно так оно и происходит. Потому что руководителю не обязательно знать современные технологии, языки программирования и вообще разбираться в предмете. Ведь у него есть опыт, он лоялен фирме и т.д. и т.п.
В результате должность занимает абсолютно некомпетентный человек, который хорошо, если просто не мешает остальным работать, а не тормозит развитие на своем уровне представления о прекрасном.
И хорошо, если на этом все заканчивается, практика показывает, что нет, особенно явно это проявляется в госах. Осознавая собственный уровень некомпетентности, такой руководитель никогда не будет повышать компетентных сотрудников.
Почему? Потому что они будут представлять непосредственную угрозу его должности, потому что их потолок некомпетентности выше и могут еще расти, а он уже нет. А место теплое и хлебное, рынок труда для него – это какой-то восточный базар в арабской стране: прикольно, интересно, но абсолютно ничего не понятно, что они там лопочут.
И на нижестоящие должности также ставятся некомпетентные сотрудники, зато лояльные и безопасные, обладающие ценными навыками рисовать красивые отчеты и не менее красиво наводить тень на плетень.
Вы думаете им нужны толковые заместители? Вовсе нет. Ну вы поняли. Система самоцементируется сверху вниз, заполняя все уровни некомпетентными сотрудниками.
Погодите, а кто же будет работать? Если это гос, то возможно даже никто, гос не обанкротится, его финансирует бюджет, а все остальное они нарисуют. И такое, к сожалению, имеет место быть, когда элементарные вопросы решаются с огромным скрипом и очень долго.
Если же работать все-таки надо, то работают линейные сотрудники, тоже невысокой компетенции, чтобы даже не думали прыгать выше головы, потому что прыгать в такой системе некуда.
Получаем типичную «потогонку» или «галеру» и пока такой бизнес приносит средства для кормления всей этой руководящей пирамиды – никто ничего менять не будет.
А сегодня для принципа Питера открылось второе дыхание – нейросети, которые помогают поддерживать и даже повышать свой уровень некомпетентности, причем на всех уровнях.
Что с этим делать? Ничего, принимать как данное, ибо нейросеть просто инструмент, а поведение человека складывалось веками. Но умение распознавать подобные организации и стараться обходить их стороной – навык полезный.
Принцип Питера сформулирован в 1969 году канадским педагогом и психологом Лоуренсом Дж. Питером, у нас он известен как часть Законов Мерфи.
Принцип Питера гласит:
В иерархии каждый сотрудник имеет тенденцию подниматься до своего уровня некомпетентности.
Следствия принципа Питера:
🔸С течением времени каждая должность будет занята сотрудником, который некомпетентен в выполнении своих обязанностей.
🔸Работа выполняется теми работниками, которые ещё не достигли своего уровня некомпетентности.
Многие считают это всего лишь шуткой, но на самом деле подобные тенденции имеют место быть и гораздо шире, нежели этого бы хотелось.
Причина в современной корпоративной культуре, не важно – нашей или западной – вся она завязана на некоторую «эффективность» сотрудника, которая является одним из проявлений «успешного успеха».
«Эффективный» сотрудник просто не может сказать – я не готов к повышению, я что-то не знаю и не умею, мне нужно подучиться. Потому что в этом случае он остановился, когда другие продолжают бежать вперед, он теперь просто неудачник.
При этом реальной компетентности на новой должности уже не хватает. Но если можно заменить работу красивыми отчетами и плавно делегировать ее вниз – то проблемы нет.
А показав «успехи» и на этой должности можно и дальше пробиваться вверх по карьерной лестнице, до тех пор, пока выше вы не сможете вообще ничего, даже писать красивые отчеты.
В этой точке сотрудник поднялся до своего уровня некомпетентности и занял соответствующую ей должность.
Тут может быть смешно, но часто именно так оно и происходит. Потому что руководителю не обязательно знать современные технологии, языки программирования и вообще разбираться в предмете. Ведь у него есть опыт, он лоялен фирме и т.д. и т.п.
В результате должность занимает абсолютно некомпетентный человек, который хорошо, если просто не мешает остальным работать, а не тормозит развитие на своем уровне представления о прекрасном.
И хорошо, если на этом все заканчивается, практика показывает, что нет, особенно явно это проявляется в госах. Осознавая собственный уровень некомпетентности, такой руководитель никогда не будет повышать компетентных сотрудников.
Почему? Потому что они будут представлять непосредственную угрозу его должности, потому что их потолок некомпетентности выше и могут еще расти, а он уже нет. А место теплое и хлебное, рынок труда для него – это какой-то восточный базар в арабской стране: прикольно, интересно, но абсолютно ничего не понятно, что они там лопочут.
И на нижестоящие должности также ставятся некомпетентные сотрудники, зато лояльные и безопасные, обладающие ценными навыками рисовать красивые отчеты и не менее красиво наводить тень на плетень.
Вы думаете им нужны толковые заместители? Вовсе нет. Ну вы поняли. Система самоцементируется сверху вниз, заполняя все уровни некомпетентными сотрудниками.
Погодите, а кто же будет работать? Если это гос, то возможно даже никто, гос не обанкротится, его финансирует бюджет, а все остальное они нарисуют. И такое, к сожалению, имеет место быть, когда элементарные вопросы решаются с огромным скрипом и очень долго.
Если же работать все-таки надо, то работают линейные сотрудники, тоже невысокой компетенции, чтобы даже не думали прыгать выше головы, потому что прыгать в такой системе некуда.
Получаем типичную «потогонку» или «галеру» и пока такой бизнес приносит средства для кормления всей этой руководящей пирамиды – никто ничего менять не будет.
А сегодня для принципа Питера открылось второе дыхание – нейросети, которые помогают поддерживать и даже повышать свой уровень некомпетентности, причем на всех уровнях.
Что с этим делать? Ничего, принимать как данное, ибо нейросеть просто инструмент, а поведение человека складывалось веками. Но умение распознавать подобные организации и стараться обходить их стороной – навык полезный.
🔥16👍11🤷♂5😁2
PHP2Shell
Второй день все сообщество гудит как растревоженный улей по поводу уязвимости PHP2Shell. Кто-то в панике обновляется, кто-то патчится, кто-то прикручивает костыли и судорожно прикидывает как жить дальше.
Под именем PHP2Shell скрываются две связанные уязвимости - CVE-2026-109618 и CVE-2026-109619, затрагивающие непосредственно сам интерпретатор PHP. Эксплуатация этих брешей позволяет неаутентифицированному удалённому злоумышленнику с сетевым доступом выполнить произвольный код (RCE) в контексте любого уязвимого PHP-приложения.
Не важно, насколько хорошо написан код вашего приложения, если оно работает на уязвимой версии интерпретатора, то под угрозой даже элементарный «Hello World».
Основная проблема в том, что уязвимыми оказались все версии начиная с PHP 5.4 и этот скриптовый язык используется примерно на 70% сайтов в интернете, т.е. касается буквально каждого.
Хотя, если посмотреть на ситуацию со стороны, то в наш век развитого ИИ ничего удивительного в этом нет, подобные уязвимости находят практически каждый день везде, начиная от ядра Linux и заканчивая какими-нибудь библиотеками.
Но в данном случае попадание пришлось в крайне уязвимое место и теперь главное трезво оценить ситуацию и сделать правильные выводы.
А именно проанализировать реакцию на это событие. Разработчики PHP оперативно выпустили патчи для версии 8.2 – 8.5, для версий 7.4 – 8.1 патч доступен только в виде исходного кода.
Фактически разработчики оставили поддержку только актуальных версий, которые будут поддерживать и собирать. Для не сильно устаревших патч в сорцах, собирайте сами. Ну а старые версии полностью списаны в расход.
В Ubuntu сами пропатчили все пакеты до 5.х включительно и обновления получат все дистрибутивы на официальной поддержке, включая промежуточный 26.10. Пользователи 14.04 LTS, 16.04 LTS, 18.04 LTS и 20.04 LTS получат патчи при наличии подписки Ubuntu Pro (ESM).
В Debian патчи получат пользователи Debian 12 и Debian 13. Для Debian 11, чей пятилетний цикл завершился в августе 2026 года, обновлений нет, закрытие бреши ложится исключительно на плечи команды Extended LTS (ELTS) от Freexian, если на пакет PHP найдутся спонсоры.
В экосистеме RHEL-совместимых дистрибутивов (AlmaLinux и Rocky Linux) ситуация решается через AppStream-модули и оперативную пересборку апстрим-исправлений. Пропатчены стримы в релизах EL8, а также ветки PHP в EL9 и EL10. Для EL7 обновлений нет и не будет.
Что касается популярных репозиториев отдельных энтузиастов, то тут все зависит от них самих, так Ондрей Сури (Debian/Ubuntu) пакеты оперативно пропатчил, а вот Реми Колле (RHEL) уехал в отпуск как раз перед обнаружением уязвимости и все, кто использовал его репозитории в продакшене будут под ударом пока автор не вернется с отдыха.
А так как таких ситуаций с каждым днем будет все больше и больше, то ставить в продуктовые среды продукты одиночек-энтузиастов становится неоправданным риском и, по сути, ставит крест на небольших проектах, авторы которых просто перестанут успевать патчить свои сборки.
Также надо гораздо более тщательно подходить к выбору ОС, хороший пример – это Debian и Ubuntu, хотя и там, и там, казалось бы, по «5 лет» поддержки.
Второй день все сообщество гудит как растревоженный улей по поводу уязвимости PHP2Shell. Кто-то в панике обновляется, кто-то патчится, кто-то прикручивает костыли и судорожно прикидывает как жить дальше.
Под именем PHP2Shell скрываются две связанные уязвимости - CVE-2026-109618 и CVE-2026-109619, затрагивающие непосредственно сам интерпретатор PHP. Эксплуатация этих брешей позволяет неаутентифицированному удалённому злоумышленнику с сетевым доступом выполнить произвольный код (RCE) в контексте любого уязвимого PHP-приложения.
Не важно, насколько хорошо написан код вашего приложения, если оно работает на уязвимой версии интерпретатора, то под угрозой даже элементарный «Hello World».
Основная проблема в том, что уязвимыми оказались все версии начиная с PHP 5.4 и этот скриптовый язык используется примерно на 70% сайтов в интернете, т.е. касается буквально каждого.
Хотя, если посмотреть на ситуацию со стороны, то в наш век развитого ИИ ничего удивительного в этом нет, подобные уязвимости находят практически каждый день везде, начиная от ядра Linux и заканчивая какими-нибудь библиотеками.
Но в данном случае попадание пришлось в крайне уязвимое место и теперь главное трезво оценить ситуацию и сделать правильные выводы.
А именно проанализировать реакцию на это событие. Разработчики PHP оперативно выпустили патчи для версии 8.2 – 8.5, для версий 7.4 – 8.1 патч доступен только в виде исходного кода.
Фактически разработчики оставили поддержку только актуальных версий, которые будут поддерживать и собирать. Для не сильно устаревших патч в сорцах, собирайте сами. Ну а старые версии полностью списаны в расход.
В Ubuntu сами пропатчили все пакеты до 5.х включительно и обновления получат все дистрибутивы на официальной поддержке, включая промежуточный 26.10. Пользователи 14.04 LTS, 16.04 LTS, 18.04 LTS и 20.04 LTS получат патчи при наличии подписки Ubuntu Pro (ESM).
В Debian патчи получат пользователи Debian 12 и Debian 13. Для Debian 11, чей пятилетний цикл завершился в августе 2026 года, обновлений нет, закрытие бреши ложится исключительно на плечи команды Extended LTS (ELTS) от Freexian, если на пакет PHP найдутся спонсоры.
В экосистеме RHEL-совместимых дистрибутивов (AlmaLinux и Rocky Linux) ситуация решается через AppStream-модули и оперативную пересборку апстрим-исправлений. Пропатчены стримы в релизах EL8, а также ветки PHP в EL9 и EL10. Для EL7 обновлений нет и не будет.
Что касается популярных репозиториев отдельных энтузиастов, то тут все зависит от них самих, так Ондрей Сури (Debian/Ubuntu) пакеты оперативно пропатчил, а вот Реми Колле (RHEL) уехал в отпуск как раз перед обнаружением уязвимости и все, кто использовал его репозитории в продакшене будут под ударом пока автор не вернется с отдыха.
А так как таких ситуаций с каждым днем будет все больше и больше, то ставить в продуктовые среды продукты одиночек-энтузиастов становится неоправданным риском и, по сути, ставит крест на небольших проектах, авторы которых просто перестанут успевать патчить свои сборки.
Также надо гораздо более тщательно подходить к выбору ОС, хороший пример – это Debian и Ubuntu, хотя и там, и там, казалось бы, по «5 лет» поддержки.
👍10❤3🥱2👀1
Про помогаторов
На фоне последних событий рассмотрим еще один феномен – помогаторство.
Суть его сводится к тому, что коллеги начинают ошибочно путать процесс зарабатывания денег с помощью клиенту, даже если он об этом не просил и денег за это не предлагал.
В чем это проявляется? Обычно берут подряд на один вид работ, но в процессе всплывают некоторые сложности и вместо того, чтобы озадачить этим клиента, они начинают решать вопрос самостоятельно, либо пытаются решить задачу наличными средствами.
Например, аппаратные средства заказчика явно не соответствуют решаемой задаче. Правильно – это сделать стоп и довести до заказчика реальные требования. А не соглашаться «ну сделать пока как-то так, а там решим».
Потому что ничего «там» не решат, а будут тянуть полудохлую систему до последнего, постоянно прося вас «что-то» сделать. И если вначале просить будут вежливо и даже давать денег, то потом начнут просто требовать и возмущаться, потому как мы тебе столько денег заплатили, а ты нормально ничего сделать не можешь.
А попытка таки вернуть ситуацию на стартовую позицию с покупкой адекватного железа обернется тем «а почему ты мне сразу не сказал» и вряд ли вы снова что-то нормально заработаете. Плюс вам заказчик будет постоянно внушать чувство вины за ваш прошлый «прокол».
Следует понимать, что у вас свой бизнес, у него свой и каждый из вас преследует цель заработать денег, а не взять на себя проблемы и головняки контрагента.
Ему нужно работать? Ну так пусть покупает адекватное железо или ищет неадекватного исполнителя, которому потом будет выносить мозги тем, как у него всё плохо, и это все потому, что исполнитель не может ничего нормально наладить.
Еще раз – это его бизнес и его проблемы. А не ваши. Ваша проблема – заработать указанную сумму денег без лишних проблем и заморочек. Пытаясь решить проблему заказчика подобным образом, вы только перекладываете чужие проблемы на себя.
При этом проблема никуда не денется, ее придется решать, только уже не заказчику, а вам. Так как голова начнет болеть не у него, а у вас. Потому что это вы ему пообещали сделать хоть как-нибудь, и он с вас будет требовать обещанное.
А то, что обещанное не решается наличными средствами, так заказчику это неведомо, он и знать ничего такого не обязан, но как рачительный собственник он, конечно же, попытался у вас узнать, можно ли как-то пока поработать так, вы сказали можно.
Вторая крайность - это создание для заказчика дополнительных сервисов и услуг, которые он не заказывал. Тот же мониторинг, резервные копии и т.д. и т.п.
Возможно, это связано с профдеформацией при работе в крупных организациях, где специалист знает, что при сбоях с него в первую очередь спросят про то, где был мониторинг и откуда взять резервные копии.
Здесь все гораздо проще. Доступно объясняете заказчику, на понятном ему языке, что может произойти и какие варианты вы предлагаете на этот случай. Отказывается – объясняем еще раз. Предельно понятно. Вот это сервер, он сгорел, нафиг, совсем, ничего нет. Что делать будешь?
Снова отказывается? Ну это его проблемы. Спокойно уходим, а если он таки прибегает с такой проблемой, то разводим руками и говорим, что мы его предупреждали. И никаких угрызений совести тут быть не должно. Это его бизнес, его риски. Вы сделали ровно то, что вас просили, остальное не ваши проблемы.
И здесь мы плавно подходим к тому, что нужно уметь твердо, но корректно говорить заказчику нет, когда он пытается попутно нагрузить вас другой проблемой. Следует пояснить, что выполнили вы один объем работ, то, что он хочет – это другое, это другой объем услуг и другая оплата.
Хороший пример был в комментариях, мол вы настроили нам обмен, а теперь у нас не идут остатки. Тут все просто, обмен – это обмен. Работает? Ну прекрасно, вот акт, вот счет.
Надо что-то решать с остатками? Это другая услуга, стоить будет примерно столько. Устраивает? Работаем.
Иначе вы так и останетесь помогатором, который будет тратить собственное время и решать при этом чужие проблемы за собственный счет.
На фоне последних событий рассмотрим еще один феномен – помогаторство.
Суть его сводится к тому, что коллеги начинают ошибочно путать процесс зарабатывания денег с помощью клиенту, даже если он об этом не просил и денег за это не предлагал.
В чем это проявляется? Обычно берут подряд на один вид работ, но в процессе всплывают некоторые сложности и вместо того, чтобы озадачить этим клиента, они начинают решать вопрос самостоятельно, либо пытаются решить задачу наличными средствами.
Например, аппаратные средства заказчика явно не соответствуют решаемой задаче. Правильно – это сделать стоп и довести до заказчика реальные требования. А не соглашаться «ну сделать пока как-то так, а там решим».
Потому что ничего «там» не решат, а будут тянуть полудохлую систему до последнего, постоянно прося вас «что-то» сделать. И если вначале просить будут вежливо и даже давать денег, то потом начнут просто требовать и возмущаться, потому как мы тебе столько денег заплатили, а ты нормально ничего сделать не можешь.
А попытка таки вернуть ситуацию на стартовую позицию с покупкой адекватного железа обернется тем «а почему ты мне сразу не сказал» и вряд ли вы снова что-то нормально заработаете. Плюс вам заказчик будет постоянно внушать чувство вины за ваш прошлый «прокол».
Следует понимать, что у вас свой бизнес, у него свой и каждый из вас преследует цель заработать денег, а не взять на себя проблемы и головняки контрагента.
Ему нужно работать? Ну так пусть покупает адекватное железо или ищет неадекватного исполнителя, которому потом будет выносить мозги тем, как у него всё плохо, и это все потому, что исполнитель не может ничего нормально наладить.
Еще раз – это его бизнес и его проблемы. А не ваши. Ваша проблема – заработать указанную сумму денег без лишних проблем и заморочек. Пытаясь решить проблему заказчика подобным образом, вы только перекладываете чужие проблемы на себя.
При этом проблема никуда не денется, ее придется решать, только уже не заказчику, а вам. Так как голова начнет болеть не у него, а у вас. Потому что это вы ему пообещали сделать хоть как-нибудь, и он с вас будет требовать обещанное.
А то, что обещанное не решается наличными средствами, так заказчику это неведомо, он и знать ничего такого не обязан, но как рачительный собственник он, конечно же, попытался у вас узнать, можно ли как-то пока поработать так, вы сказали можно.
Вторая крайность - это создание для заказчика дополнительных сервисов и услуг, которые он не заказывал. Тот же мониторинг, резервные копии и т.д. и т.п.
Возможно, это связано с профдеформацией при работе в крупных организациях, где специалист знает, что при сбоях с него в первую очередь спросят про то, где был мониторинг и откуда взять резервные копии.
Здесь все гораздо проще. Доступно объясняете заказчику, на понятном ему языке, что может произойти и какие варианты вы предлагаете на этот случай. Отказывается – объясняем еще раз. Предельно понятно. Вот это сервер, он сгорел, нафиг, совсем, ничего нет. Что делать будешь?
Снова отказывается? Ну это его проблемы. Спокойно уходим, а если он таки прибегает с такой проблемой, то разводим руками и говорим, что мы его предупреждали. И никаких угрызений совести тут быть не должно. Это его бизнес, его риски. Вы сделали ровно то, что вас просили, остальное не ваши проблемы.
И здесь мы плавно подходим к тому, что нужно уметь твердо, но корректно говорить заказчику нет, когда он пытается попутно нагрузить вас другой проблемой. Следует пояснить, что выполнили вы один объем работ, то, что он хочет – это другое, это другой объем услуг и другая оплата.
Хороший пример был в комментариях, мол вы настроили нам обмен, а теперь у нас не идут остатки. Тут все просто, обмен – это обмен. Работает? Ну прекрасно, вот акт, вот счет.
Надо что-то решать с остатками? Это другая услуга, стоить будет примерно столько. Устраивает? Работаем.
Иначе вы так и останетесь помогатором, который будет тратить собственное время и решать при этом чужие проблемы за собственный счет.
👍37💯16🥱3
AI меняет IT. Но какие технологии действительно заслуживают внимания?
Новые модели, AI-агенты и инструменты автоматизации появляются ежедневно. Важно не просто следить за новостями, а понимать их реальную ценность.
⚡ AI News Engine — технологическое медиа, где мы отбираем значимые события и объясняем, что изменится, почему это важно и где можно применить новые технологии.
Без информационного шума. Только факты, контекст и практическая польза.
AI News Engine — меньше шума, больше смысла.
Новые модели, AI-агенты и инструменты автоматизации появляются ежедневно. Важно не просто следить за новостями, а понимать их реальную ценность.
⚡ AI News Engine — технологическое медиа, где мы отбираем значимые события и объясняем, что изменится, почему это важно и где можно применить новые технологии.
Без информационного шума. Только факты, контекст и практическая польза.
AI News Engine — меньше шума, больше смысла.
👍3🔥2🤮1
Наташ, ты спишь? Мы там все уронили и мониторинг твой не сработал…
Мониторинг – тема сложная, гораздо сложнее чем кажется на первый взгляд и главное в ней правильно настроить объект мониторинга, чтобы получать нужное и не получать ненужное.
А еще хуже, когда мы мониторим вообще не то, что надо. В результате о случившемся нас оповестит не мониторинг, а разгневанные пользователи.
На днях обновляли 1С:Предприятие в одной подопечной организации и местный админ попросил что-нибудь простое и современное для мониторинга доступности основных сервисов, чтобы просто видеть, что живо, а что упало.
Показали ему Uptime Kuma, понравилось, запустили. Он пошел добавлять узлы, а мы принялись за свою работу, а потом все-таки заглянули посмотреть, что он там сделал и сильно удивились.
В общем это классика жанра. В нашем случае это был веб-сервер с опубликованными на нем базами 1С:Предприятие, скажем 1с.example.com, ну вот наш коллега ничтоже сумняшеся взял и добавил в монитор именно этот узел.
После чего мы предложили ему сесть и подумать, что именно будет контролировать такой монитор? Чтобы активировать мыслительный процесс мы предложили перейти по этой ссылке и полюбоваться на стандартную заглушку IIS/Apache.
Да, такой монитор покажет нам жив ли веб-сервер в принципе, но никакого контроля над опубликованными на нем сервисах у нас не будет. В данном случае хуже будет только Ping, хотя и так многие делают, а потом сильно удивляются, когда их будят рано утром.
А вот здесь самое время подумать, что именно нам нужно мониторить. Веб-сервер? Его статус в вакууме нам не даст никакой полезной информации. Веб-приложения? Именно, вот именно их состояние нам и интересно.
Мы вполне можем получить ситуацию, когда веб-сервер работает нормально, а веб-приложение или сайт вдруг начали выдавать коды 4хх или 5хх и наша задача узнать об этом своевременно, а не тогда, когда найдут и разбудят.
Поэтому добавляем в мониторинг не один узел, а три, по количеству опубликованных веб-сервисов (понятно, что у вас может быть любое количество) и теперь мы будем видеть состояние каждого из них в отдельности.
Теперь вы можете своевременно реагировать на происходящее и четко понимать, что и с кем случилось.
Этот подход следует применять для любых систем мониторинга и сервисов. Помните, что нас интересует не состояние узла, а работоспособность развернутых на нем сервисов, поэтому мониторить нам нужно именно их, а потом уже все остальное.
Кстати, состоянием узла тоже пренебрегать не стоит. Особенно если есть возможность настраивать зависимости. Скажем в Zabbix вы можете настроить зависимости триггеров сервисов от состояния узла и если он полностью выключен, то Zabbix не будет спамить вас десятком сообщений о недоступности каждого сервиса в отдельности, а просто скажет, что узел такой-то не в сети.
Но первичны у нас именно сервисы, помните об этом!
Мониторинг – тема сложная, гораздо сложнее чем кажется на первый взгляд и главное в ней правильно настроить объект мониторинга, чтобы получать нужное и не получать ненужное.
А еще хуже, когда мы мониторим вообще не то, что надо. В результате о случившемся нас оповестит не мониторинг, а разгневанные пользователи.
На днях обновляли 1С:Предприятие в одной подопечной организации и местный админ попросил что-нибудь простое и современное для мониторинга доступности основных сервисов, чтобы просто видеть, что живо, а что упало.
Показали ему Uptime Kuma, понравилось, запустили. Он пошел добавлять узлы, а мы принялись за свою работу, а потом все-таки заглянули посмотреть, что он там сделал и сильно удивились.
В общем это классика жанра. В нашем случае это был веб-сервер с опубликованными на нем базами 1С:Предприятие, скажем 1с.example.com, ну вот наш коллега ничтоже сумняшеся взял и добавил в монитор именно этот узел.
После чего мы предложили ему сесть и подумать, что именно будет контролировать такой монитор? Чтобы активировать мыслительный процесс мы предложили перейти по этой ссылке и полюбоваться на стандартную заглушку IIS/Apache.
Да, такой монитор покажет нам жив ли веб-сервер в принципе, но никакого контроля над опубликованными на нем сервисах у нас не будет. В данном случае хуже будет только Ping, хотя и так многие делают, а потом сильно удивляются, когда их будят рано утром.
А вот здесь самое время подумать, что именно нам нужно мониторить. Веб-сервер? Его статус в вакууме нам не даст никакой полезной информации. Веб-приложения? Именно, вот именно их состояние нам и интересно.
Мы вполне можем получить ситуацию, когда веб-сервер работает нормально, а веб-приложение или сайт вдруг начали выдавать коды 4хх или 5хх и наша задача узнать об этом своевременно, а не тогда, когда найдут и разбудят.
Поэтому добавляем в мониторинг не один узел, а три, по количеству опубликованных веб-сервисов (понятно, что у вас может быть любое количество) и теперь мы будем видеть состояние каждого из них в отдельности.
Теперь вы можете своевременно реагировать на происходящее и четко понимать, что и с кем случилось.
Этот подход следует применять для любых систем мониторинга и сервисов. Помните, что нас интересует не состояние узла, а работоспособность развернутых на нем сервисов, поэтому мониторить нам нужно именно их, а потом уже все остальное.
Кстати, состоянием узла тоже пренебрегать не стоит. Особенно если есть возможность настраивать зависимости. Скажем в Zabbix вы можете настроить зависимости триггеров сервисов от состояния узла и если он полностью выключен, то Zabbix не будет спамить вас десятком сообщений о недоступности каждого сервиса в отдельности, а просто скажет, что узел такой-то не в сети.
Но первичны у нас именно сервисы, помните об этом!
👍7❤2
ZFS на скромном сервере
ZFS привыкли воспринимать как тяжеловесный enterprise-комбайн. Но если спуститься на землю — в реалии небольшого продакшна (один сервер, Proxmox/LXC, связка из 1С с PostgreSQL и потребительские NVMe), возможности ZFS раскрываются с сугубо прикладной стороны.
Главное — сразу отбросить старые догмы.
1️⃣ Почему ZFS идеальна для LXC и баз данных
В отличие от классического LVM или жестких разделов, ZFS дает единый пул (zpool), поверх которого нарезаются датасеты — легкие логические файловые системы. Никаких фиксированных гигабайт: каждый датасет видит весь свободный пул, но управляется индивидуально.
🔸 recordsize под задачу. По умолчанию в ZFS блок равен 128 КБ. Для СУБД со случайной записью страницами по 8 КБ это верная смерть накопителя из-за дикого Write Amplification (WAF). Датасет базы с
🔸 Встроенное сжатие (LZ4/ZSTD). Это не про экономию диска, это про ресурс потребительского флеша. Сжатие уменьшает физический объем, который контроллер SSD пишет в ячейки. Меньше физической записи - ниже WAF и дольше живет TBW.
🔸 ARC вместо page cache. Умный двухфакторный кэш в оперативной памяти (ARC) отслеживает не просто недавние обращения (MRU), но и их частоту (MFU). Случайный тяжелый отчет в 1С не вымоет из памяти горячие индексы живой базы.
2️⃣ L2ARC: почему вторичный кэш здесь вреден
L2ARC создавался 15 лет назад для гибридных хранилищ, чтобы прикрыть медленные «холодные» HDD быстрыми SSD. Ставить его в NVMe-сервер - грубейшая ошибка.
🔸 Кража оперативной памяти. Чтобы адресовать блоки в L2ARC, ZFS держит таблицу указателей прямо в RAM. Выделяя SSD под L2ARC, вы отбираете мегабайты и гигабайты памяти у ARC.
🔸 Бессмысленность шины. Чтение блока с соседнего бытового NVMe идет с теми же задержками PCIe, что и с основного пула. Профита по задержкам - ноль.
🔸 Сжигание ячеек мусором. В L2ARC вытесняется в основном MRU-хвост. Туда потоком летят одноразовые блоки от бэкапов и квартальных проводок. Вы просто тупо стираете ресурс записью «мусора», который больше никогда не будет прочитан
3️⃣ SLOG на копеечном Optane 16 ГБ: громоотвод для СУБД
Базы данных требуют строгой фиксации транзакций (fsync). У потребительских NVMe нет аппаратной защиты от потери питания (PLP). При каждом вызове fsync бытовой контроллер сбрасывает буферы прямо во флеш-память, вызывая провалы по задержкам и раздувая WAF двойной записью в ZIL.
Спасение — отдельный лог записи (SLOG) на стареньком Intel Optane на 16 ГБ (серия M10), купленном за копейки:
🔸 Нам не нужны терабайты: SLOG держит данные только до сброса транзакционной группы (раз в 5 секунд).
🔸 Линейная скорость не важна (у 16 ГБ Optane она всего ~150 МБ/с). Главное — физика памяти 3D XPoint: у нее нет блоков стирания, нет падения скорости после SLC-кэша и микросекундные задержки.
🔸 Optane спокойно живет даже на переходнике в одной линии PCIe x1. Его задача — быстро подтвердить транзакцию СУБД за микросекунды и избавить основной NVMe-пул от мелкоблочной случайной записи.
4️⃣ Special VDEV: когда он нужен, а когда создает риски
Special Allocation Class выносит метаданные (а опционально и мелкие блоки) на выделенные накопители.
🔸В чем риск? Special VDEV — это не кэш, а часть структуры данных пула. Смерть special хоронит zpool целиком. Поэтому сюда допустимо ставить строго зеркало (Mirror). На чисто твердотельном NVMe-сервере под 1С от него мало толку - задержки метаданных на основном пуле и так микросекундные.
🔸 Где он идеален? В сценариях сегрегации нагрузки. Например, у вас есть холодный архив на HDD (почта, файлопомойка): пара небольших NVMe под special заставит поиск и листинг миллионов файлов летать без дерганья шпинделей.
👉 Резюме: ZFS на потребительском железе требует не слепого следования мануалам, а понимания физики накопителей. Выравнивайте recordsize, включайте сжатие, забывайте про L2ARC как про страшный сон, а на сдачу поставьте копеечный Optane под журнал ZIL.
ZFS привыкли воспринимать как тяжеловесный enterprise-комбайн. Но если спуститься на землю — в реалии небольшого продакшна (один сервер, Proxmox/LXC, связка из 1С с PostgreSQL и потребительские NVMe), возможности ZFS раскрываются с сугубо прикладной стороны.
Главное — сразу отбросить старые догмы.
1️⃣ Почему ZFS идеальна для LXC и баз данных
В отличие от классического LVM или жестких разделов, ZFS дает единый пул (zpool), поверх которого нарезаются датасеты — легкие логические файловые системы. Никаких фиксированных гигабайт: каждый датасет видит весь свободный пул, но управляется индивидуально.
🔸 recordsize под задачу. По умолчанию в ZFS блок равен 128 КБ. Для СУБД со случайной записью страницами по 8 КБ это верная смерть накопителя из-за дикого Write Amplification (WAF). Датасет базы с
recordsize=8k сразу убирает оверхед. Датасет под бэкапы или логи при этом спокойно живет со стандартными 128 КБ.🔸 Встроенное сжатие (LZ4/ZSTD). Это не про экономию диска, это про ресурс потребительского флеша. Сжатие уменьшает физический объем, который контроллер SSD пишет в ячейки. Меньше физической записи - ниже WAF и дольше живет TBW.
🔸 ARC вместо page cache. Умный двухфакторный кэш в оперативной памяти (ARC) отслеживает не просто недавние обращения (MRU), но и их частоту (MFU). Случайный тяжелый отчет в 1С не вымоет из памяти горячие индексы живой базы.
2️⃣ L2ARC: почему вторичный кэш здесь вреден
L2ARC создавался 15 лет назад для гибридных хранилищ, чтобы прикрыть медленные «холодные» HDD быстрыми SSD. Ставить его в NVMe-сервер - грубейшая ошибка.
🔸 Кража оперативной памяти. Чтобы адресовать блоки в L2ARC, ZFS держит таблицу указателей прямо в RAM. Выделяя SSD под L2ARC, вы отбираете мегабайты и гигабайты памяти у ARC.
🔸 Бессмысленность шины. Чтение блока с соседнего бытового NVMe идет с теми же задержками PCIe, что и с основного пула. Профита по задержкам - ноль.
🔸 Сжигание ячеек мусором. В L2ARC вытесняется в основном MRU-хвост. Туда потоком летят одноразовые блоки от бэкапов и квартальных проводок. Вы просто тупо стираете ресурс записью «мусора», который больше никогда не будет прочитан
3️⃣ SLOG на копеечном Optane 16 ГБ: громоотвод для СУБД
Базы данных требуют строгой фиксации транзакций (fsync). У потребительских NVMe нет аппаратной защиты от потери питания (PLP). При каждом вызове fsync бытовой контроллер сбрасывает буферы прямо во флеш-память, вызывая провалы по задержкам и раздувая WAF двойной записью в ZIL.
Спасение — отдельный лог записи (SLOG) на стареньком Intel Optane на 16 ГБ (серия M10), купленном за копейки:
🔸 Нам не нужны терабайты: SLOG держит данные только до сброса транзакционной группы (раз в 5 секунд).
🔸 Линейная скорость не важна (у 16 ГБ Optane она всего ~150 МБ/с). Главное — физика памяти 3D XPoint: у нее нет блоков стирания, нет падения скорости после SLC-кэша и микросекундные задержки.
🔸 Optane спокойно живет даже на переходнике в одной линии PCIe x1. Его задача — быстро подтвердить транзакцию СУБД за микросекунды и избавить основной NVMe-пул от мелкоблочной случайной записи.
4️⃣ Special VDEV: когда он нужен, а когда создает риски
Special Allocation Class выносит метаданные (а опционально и мелкие блоки) на выделенные накопители.
🔸В чем риск? Special VDEV — это не кэш, а часть структуры данных пула. Смерть special хоронит zpool целиком. Поэтому сюда допустимо ставить строго зеркало (Mirror). На чисто твердотельном NVMe-сервере под 1С от него мало толку - задержки метаданных на основном пуле и так микросекундные.
🔸 Где он идеален? В сценариях сегрегации нагрузки. Например, у вас есть холодный архив на HDD (почта, файлопомойка): пара небольших NVMe под special заставит поиск и листинг миллионов файлов летать без дерганья шпинделей.
👉 Резюме: ZFS на потребительском железе требует не слепого следования мануалам, а понимания физики накопителей. Выравнивайте recordsize, включайте сжатие, забывайте про L2ARC как про страшный сон, а на сдачу поставьте копеечный Optane под журнал ZIL.
👍5🔥4❤2🤯1