Принцип Питера
Принцип Питера сформулирован в 1969 году канадским педагогом и психологом Лоуренсом Дж. Питером, у нас он известен как часть Законов Мерфи.
Принцип Питера гласит:
Следствия принципа Питера:
Многие считают это всего лишь шуткой, но на самом деле подобные тенденции имеют место быть и гораздо шире, нежели этого бы хотелось.
Причина в современной корпоративной культуре, не важно – нашей или западной – вся она завязана на некоторую «эффективность» сотрудника, которая является одним из проявлений «успешного успеха».
«Эффективный» сотрудник просто не может сказать – я не готов к повышению, я что-то не знаю и не умею, мне нужно подучиться. Потому что в этом случае он остановился, когда другие продолжают бежать вперед, он теперь просто неудачник.
При этом реальной компетентности на новой должности уже не хватает. Но если можно заменить работу красивыми отчетами и плавно делегировать ее вниз – то проблемы нет.
А показав «успехи» и на этой должности можно и дальше пробиваться вверх по карьерной лестнице, до тех пор, пока выше вы не сможете вообще ничего, даже писать красивые отчеты.
В этой точке сотрудник поднялся до своего уровня некомпетентности и занял соответствующую ей должность.
Тут может быть смешно, но часто именно так оно и происходит. Потому что руководителю не обязательно знать современные технологии, языки программирования и вообще разбираться в предмете. Ведь у него есть опыт, он лоялен фирме и т.д. и т.п.
В результате должность занимает абсолютно некомпетентный человек, который хорошо, если просто не мешает остальным работать, а не тормозит развитие на своем уровне представления о прекрасном.
И хорошо, если на этом все заканчивается, практика показывает, что нет, особенно явно это проявляется в госах. Осознавая собственный уровень некомпетентности, такой руководитель никогда не будет повышать компетентных сотрудников.
Почему? Потому что они будут представлять непосредственную угрозу его должности, потому что их потолок некомпетентности выше и могут еще расти, а он уже нет. А место теплое и хлебное, рынок труда для него – это какой-то восточный базар в арабской стране: прикольно, интересно, но абсолютно ничего не понятно, что они там лопочут.
И на нижестоящие должности также ставятся некомпетентные сотрудники, зато лояльные и безопасные, обладающие ценными навыками рисовать красивые отчеты и не менее красиво наводить тень на плетень.
Вы думаете им нужны толковые заместители? Вовсе нет. Ну вы поняли. Система самоцементируется сверху вниз, заполняя все уровни некомпетентными сотрудниками.
Погодите, а кто же будет работать? Если это гос, то возможно даже никто, гос не обанкротится, его финансирует бюджет, а все остальное они нарисуют. И такое, к сожалению, имеет место быть, когда элементарные вопросы решаются с огромным скрипом и очень долго.
Если же работать все-таки надо, то работают линейные сотрудники, тоже невысокой компетенции, чтобы даже не думали прыгать выше головы, потому что прыгать в такой системе некуда.
Получаем типичную «потогонку» или «галеру» и пока такой бизнес приносит средства для кормления всей этой руководящей пирамиды – никто ничего менять не будет.
А сегодня для принципа Питера открылось второе дыхание – нейросети, которые помогают поддерживать и даже повышать свой уровень некомпетентности, причем на всех уровнях.
Что с этим делать? Ничего, принимать как данное, ибо нейросеть просто инструмент, а поведение человека складывалось веками. Но умение распознавать подобные организации и стараться обходить их стороной – навык полезный.
Принцип Питера сформулирован в 1969 году канадским педагогом и психологом Лоуренсом Дж. Питером, у нас он известен как часть Законов Мерфи.
Принцип Питера гласит:
В иерархии каждый сотрудник имеет тенденцию подниматься до своего уровня некомпетентности.
Следствия принципа Питера:
🔸С течением времени каждая должность будет занята сотрудником, который некомпетентен в выполнении своих обязанностей.
🔸Работа выполняется теми работниками, которые ещё не достигли своего уровня некомпетентности.
Многие считают это всего лишь шуткой, но на самом деле подобные тенденции имеют место быть и гораздо шире, нежели этого бы хотелось.
Причина в современной корпоративной культуре, не важно – нашей или западной – вся она завязана на некоторую «эффективность» сотрудника, которая является одним из проявлений «успешного успеха».
«Эффективный» сотрудник просто не может сказать – я не готов к повышению, я что-то не знаю и не умею, мне нужно подучиться. Потому что в этом случае он остановился, когда другие продолжают бежать вперед, он теперь просто неудачник.
При этом реальной компетентности на новой должности уже не хватает. Но если можно заменить работу красивыми отчетами и плавно делегировать ее вниз – то проблемы нет.
А показав «успехи» и на этой должности можно и дальше пробиваться вверх по карьерной лестнице, до тех пор, пока выше вы не сможете вообще ничего, даже писать красивые отчеты.
В этой точке сотрудник поднялся до своего уровня некомпетентности и занял соответствующую ей должность.
Тут может быть смешно, но часто именно так оно и происходит. Потому что руководителю не обязательно знать современные технологии, языки программирования и вообще разбираться в предмете. Ведь у него есть опыт, он лоялен фирме и т.д. и т.п.
В результате должность занимает абсолютно некомпетентный человек, который хорошо, если просто не мешает остальным работать, а не тормозит развитие на своем уровне представления о прекрасном.
И хорошо, если на этом все заканчивается, практика показывает, что нет, особенно явно это проявляется в госах. Осознавая собственный уровень некомпетентности, такой руководитель никогда не будет повышать компетентных сотрудников.
Почему? Потому что они будут представлять непосредственную угрозу его должности, потому что их потолок некомпетентности выше и могут еще расти, а он уже нет. А место теплое и хлебное, рынок труда для него – это какой-то восточный базар в арабской стране: прикольно, интересно, но абсолютно ничего не понятно, что они там лопочут.
И на нижестоящие должности также ставятся некомпетентные сотрудники, зато лояльные и безопасные, обладающие ценными навыками рисовать красивые отчеты и не менее красиво наводить тень на плетень.
Вы думаете им нужны толковые заместители? Вовсе нет. Ну вы поняли. Система самоцементируется сверху вниз, заполняя все уровни некомпетентными сотрудниками.
Погодите, а кто же будет работать? Если это гос, то возможно даже никто, гос не обанкротится, его финансирует бюджет, а все остальное они нарисуют. И такое, к сожалению, имеет место быть, когда элементарные вопросы решаются с огромным скрипом и очень долго.
Если же работать все-таки надо, то работают линейные сотрудники, тоже невысокой компетенции, чтобы даже не думали прыгать выше головы, потому что прыгать в такой системе некуда.
Получаем типичную «потогонку» или «галеру» и пока такой бизнес приносит средства для кормления всей этой руководящей пирамиды – никто ничего менять не будет.
А сегодня для принципа Питера открылось второе дыхание – нейросети, которые помогают поддерживать и даже повышать свой уровень некомпетентности, причем на всех уровнях.
Что с этим делать? Ничего, принимать как данное, ибо нейросеть просто инструмент, а поведение человека складывалось веками. Но умение распознавать подобные организации и стараться обходить их стороной – навык полезный.
🔥17👍13🤷♂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 лет» поддержки.
👍12❤4🥱2👀1
Про помогаторов
На фоне последних событий рассмотрим еще один феномен – помогаторство.
Суть его сводится к тому, что коллеги начинают ошибочно путать процесс зарабатывания денег с помощью клиенту, даже если он об этом не просил и денег за это не предлагал.
В чем это проявляется? Обычно берут подряд на один вид работ, но в процессе всплывают некоторые сложности и вместо того, чтобы озадачить этим клиента, они начинают решать вопрос самостоятельно, либо пытаются решить задачу наличными средствами.
Например, аппаратные средства заказчика явно не соответствуют решаемой задаче. Правильно – это сделать стоп и довести до заказчика реальные требования. А не соглашаться «ну сделать пока как-то так, а там решим».
Потому что ничего «там» не решат, а будут тянуть полудохлую систему до последнего, постоянно прося вас «что-то» сделать. И если вначале просить будут вежливо и даже давать денег, то потом начнут просто требовать и возмущаться, потому как мы тебе столько денег заплатили, а ты нормально ничего сделать не можешь.
А попытка таки вернуть ситуацию на стартовую позицию с покупкой адекватного железа обернется тем «а почему ты мне сразу не сказал» и вряд ли вы снова что-то нормально заработаете. Плюс вам заказчик будет постоянно внушать чувство вины за ваш прошлый «прокол».
Следует понимать, что у вас свой бизнес, у него свой и каждый из вас преследует цель заработать денег, а не взять на себя проблемы и головняки контрагента.
Ему нужно работать? Ну так пусть покупает адекватное железо или ищет неадекватного исполнителя, которому потом будет выносить мозги тем, как у него всё плохо, и это все потому, что исполнитель не может ничего нормально наладить.
Еще раз – это его бизнес и его проблемы. А не ваши. Ваша проблема – заработать указанную сумму денег без лишних проблем и заморочек. Пытаясь решить проблему заказчика подобным образом, вы только перекладываете чужие проблемы на себя.
При этом проблема никуда не денется, ее придется решать, только уже не заказчику, а вам. Так как голова начнет болеть не у него, а у вас. Потому что это вы ему пообещали сделать хоть как-нибудь, и он с вас будет требовать обещанное.
А то, что обещанное не решается наличными средствами, так заказчику это неведомо, он и знать ничего такого не обязан, но как рачительный собственник он, конечно же, попытался у вас узнать, можно ли как-то пока поработать так, вы сказали можно.
Вторая крайность - это создание для заказчика дополнительных сервисов и услуг, которые он не заказывал. Тот же мониторинг, резервные копии и т.д. и т.п.
Возможно, это связано с профдеформацией при работе в крупных организациях, где специалист знает, что при сбоях с него в первую очередь спросят про то, где был мониторинг и откуда взять резервные копии.
Здесь все гораздо проще. Доступно объясняете заказчику, на понятном ему языке, что может произойти и какие варианты вы предлагаете на этот случай. Отказывается – объясняем еще раз. Предельно понятно. Вот это сервер, он сгорел, нафиг, совсем, ничего нет. Что делать будешь?
Снова отказывается? Ну это его проблемы. Спокойно уходим, а если он таки прибегает с такой проблемой, то разводим руками и говорим, что мы его предупреждали. И никаких угрызений совести тут быть не должно. Это его бизнес, его риски. Вы сделали ровно то, что вас просили, остальное не ваши проблемы.
И здесь мы плавно подходим к тому, что нужно уметь твердо, но корректно говорить заказчику нет, когда он пытается попутно нагрузить вас другой проблемой. Следует пояснить, что выполнили вы один объем работ, то, что он хочет – это другое, это другой объем услуг и другая оплата.
Хороший пример был в комментариях, мол вы настроили нам обмен, а теперь у нас не идут остатки. Тут все просто, обмен – это обмен. Работает? Ну прекрасно, вот акт, вот счет.
Надо что-то решать с остатками? Это другая услуга, стоить будет примерно столько. Устраивает? Работаем.
Иначе вы так и останетесь помогатором, который будет тратить собственное время и решать при этом чужие проблемы за собственный счет.
На фоне последних событий рассмотрим еще один феномен – помогаторство.
Суть его сводится к тому, что коллеги начинают ошибочно путать процесс зарабатывания денег с помощью клиенту, даже если он об этом не просил и денег за это не предлагал.
В чем это проявляется? Обычно берут подряд на один вид работ, но в процессе всплывают некоторые сложности и вместо того, чтобы озадачить этим клиента, они начинают решать вопрос самостоятельно, либо пытаются решить задачу наличными средствами.
Например, аппаратные средства заказчика явно не соответствуют решаемой задаче. Правильно – это сделать стоп и довести до заказчика реальные требования. А не соглашаться «ну сделать пока как-то так, а там решим».
Потому что ничего «там» не решат, а будут тянуть полудохлую систему до последнего, постоянно прося вас «что-то» сделать. И если вначале просить будут вежливо и даже давать денег, то потом начнут просто требовать и возмущаться, потому как мы тебе столько денег заплатили, а ты нормально ничего сделать не можешь.
А попытка таки вернуть ситуацию на стартовую позицию с покупкой адекватного железа обернется тем «а почему ты мне сразу не сказал» и вряд ли вы снова что-то нормально заработаете. Плюс вам заказчик будет постоянно внушать чувство вины за ваш прошлый «прокол».
Следует понимать, что у вас свой бизнес, у него свой и каждый из вас преследует цель заработать денег, а не взять на себя проблемы и головняки контрагента.
Ему нужно работать? Ну так пусть покупает адекватное железо или ищет неадекватного исполнителя, которому потом будет выносить мозги тем, как у него всё плохо, и это все потому, что исполнитель не может ничего нормально наладить.
Еще раз – это его бизнес и его проблемы. А не ваши. Ваша проблема – заработать указанную сумму денег без лишних проблем и заморочек. Пытаясь решить проблему заказчика подобным образом, вы только перекладываете чужие проблемы на себя.
При этом проблема никуда не денется, ее придется решать, только уже не заказчику, а вам. Так как голова начнет болеть не у него, а у вас. Потому что это вы ему пообещали сделать хоть как-нибудь, и он с вас будет требовать обещанное.
А то, что обещанное не решается наличными средствами, так заказчику это неведомо, он и знать ничего такого не обязан, но как рачительный собственник он, конечно же, попытался у вас узнать, можно ли как-то пока поработать так, вы сказали можно.
Вторая крайность - это создание для заказчика дополнительных сервисов и услуг, которые он не заказывал. Тот же мониторинг, резервные копии и т.д. и т.п.
Возможно, это связано с профдеформацией при работе в крупных организациях, где специалист знает, что при сбоях с него в первую очередь спросят про то, где был мониторинг и откуда взять резервные копии.
Здесь все гораздо проще. Доступно объясняете заказчику, на понятном ему языке, что может произойти и какие варианты вы предлагаете на этот случай. Отказывается – объясняем еще раз. Предельно понятно. Вот это сервер, он сгорел, нафиг, совсем, ничего нет. Что делать будешь?
Снова отказывается? Ну это его проблемы. Спокойно уходим, а если он таки прибегает с такой проблемой, то разводим руками и говорим, что мы его предупреждали. И никаких угрызений совести тут быть не должно. Это его бизнес, его риски. Вы сделали ровно то, что вас просили, остальное не ваши проблемы.
И здесь мы плавно подходим к тому, что нужно уметь твердо, но корректно говорить заказчику нет, когда он пытается попутно нагрузить вас другой проблемой. Следует пояснить, что выполнили вы один объем работ, то, что он хочет – это другое, это другой объем услуг и другая оплата.
Хороший пример был в комментариях, мол вы настроили нам обмен, а теперь у нас не идут остатки. Тут все просто, обмен – это обмен. Работает? Ну прекрасно, вот акт, вот счет.
Надо что-то решать с остатками? Это другая услуга, стоить будет примерно столько. Устраивает? Работаем.
Иначе вы так и останетесь помогатором, который будет тратить собственное время и решать при этом чужие проблемы за собственный счет.
👍39💯16🥱4❤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 не будет спамить вас десятком сообщений о недоступности каждого сервиса в отдельности, а просто скажет, что узел такой-то не в сети.
Но первичны у нас именно сервисы, помните об этом!
👍11❤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.
10👍13🔥6❤2🤯1🤮1
Про эффективный менеджмент
Сегодня суббота, а поэтому будет одна поучительная история из жизни. Середина нулевых, один местечковый районный провайдер, тогда таких было много.
Мы одно время работали в одном здании с ними, а поэтому хорошо друг друга знали. Потом у них дела пошли в гору, и они переехали в отдельное здание и наши пути потихоньку разошлись.
Ребята там были неплохие, кроме директора, был он, мягко скажем, немного скуповатым, хотя если честно, то далеко не немного. Но была у него еще вторая негативная черта характера. Все, кто имел сомнительное удовольствие с ним долго общаться не именовали его иначе чем чудак на букву М.
Я тоже жил в том районе и пользовался их интернетом и вскоре начал замечать, что проблемы только растут и множатся. То скорости нет, то связь пропала, то еще что-нибудь.
Хотя были иногда и приятные моменты, скажем, на майские праздники отключился биллинг и каждый качал-закачивался. А интернет в ту пору тарифицировался, если кто не помнит или не знает, помегабайтно.
Потом я как-то спросил ребят провайдера, а что это за аттракцион невиданной щедрости был?
Выяснилось, что шеф расплевался с их давним сисадмином, который стоял еще у истоков конторы и тот ушел, хлопнув дверью и назвав шефа чудаком. За серверами с диковинной FreeBSD никто не следил, так как не понимал, как следить, и в один прекрасный день место на дисках просто закончилось.
Биллинг прилег и народ все праздники резвился, попутно загоняя контору в долги. После чего из конторы ушел второй человек, который также стоял у ее основания и понимал в сетях.
Но шефа ничего не смутило, подумаешь, сисадмин, ну и подумаешь сетевой инженер. Больно нужны, у нас же все хорошо. Были приглашены специалисты со стороны и был внедрен новый биллинг, уже на Linux.
Между тем качество услуг стремительно падало, но во всем оказались виноваты пользователи, мол это они положили сеть широковещательными чатами и DC++ обменом. После чего эти приложения попытались просто запретить. Мол у кого обнаружим – отключим.
Но отключить пришлось бы решительно всех, поэтому такая инициатива сошла на нет. Лучше, естественно, не стало. Да и как оно станет в отсутствие сетевого инженера.
Прошло еще года полтора, звонит мне их шеф, мол ты же в Linux понимаешь? Понимаю. Приезжай, дело есть.
Приехал. Новый биллинг лежит. Начинаю разбираться. В наличии неплохой по тем временам сервер и RAID 5 с запасным диском. В RAID 5 выпали два диска из трех, а запасной кто-то свистнул, поставив вместо него неисправный диск бытовой серии.
Ну что тут было сказать? Только похлопать по плечу и сообщить, что медицина бессильна. Особенно если в штате не было ни одного следящего за инфраструктурой сотрудника.
Пошарившись по серверной нашли сервер с бекапами, но там был только бекап БД биллинга.
Ну вот, не все так плохо, можно восстановить.
Он спрашивает меня, смогу ли я это сделать. Отвечаю, что нет, я этот биллинг первый раз в жизни вижу и лучше всего обратиться к его разработчикам.
Выяснилось, что это не вариант, так как он им денег должен и за поддержку не платил два года. А зачем, ведь все работало.
В общем, принес ему свои соболезнования и сказал, что мне пора и было бы неплохо дать мне денег.
На что услышал, а за что тебе денег, ты же ничем мне не помог. В итоге, пояснил ему, что он чудак, развернулся и ушел.
Провайдеру тут же настал карачун, народ разбежался. А шеф? Шеф продал сети одному из федеральных провайдеров.
А что же теперь? А он теперь начальник в местном отделении федерального провайдера. До чего-то важного его не допускают, но теплое кресло выделили. Ну и репутация чудака на букву М за ним числится до сих пор.
Он же, в свою очередь, особенно после пары рюмок, любит поучать молодежь и рассказывать как у него давно был свой бизнес и как он его удачно продал, поняв, что не может тягаться на равных с федералами.
Сегодня суббота, а поэтому будет одна поучительная история из жизни. Середина нулевых, один местечковый районный провайдер, тогда таких было много.
Мы одно время работали в одном здании с ними, а поэтому хорошо друг друга знали. Потом у них дела пошли в гору, и они переехали в отдельное здание и наши пути потихоньку разошлись.
Ребята там были неплохие, кроме директора, был он, мягко скажем, немного скуповатым, хотя если честно, то далеко не немного. Но была у него еще вторая негативная черта характера. Все, кто имел сомнительное удовольствие с ним долго общаться не именовали его иначе чем чудак на букву М.
Я тоже жил в том районе и пользовался их интернетом и вскоре начал замечать, что проблемы только растут и множатся. То скорости нет, то связь пропала, то еще что-нибудь.
Хотя были иногда и приятные моменты, скажем, на майские праздники отключился биллинг и каждый качал-закачивался. А интернет в ту пору тарифицировался, если кто не помнит или не знает, помегабайтно.
Потом я как-то спросил ребят провайдера, а что это за аттракцион невиданной щедрости был?
Выяснилось, что шеф расплевался с их давним сисадмином, который стоял еще у истоков конторы и тот ушел, хлопнув дверью и назвав шефа чудаком. За серверами с диковинной FreeBSD никто не следил, так как не понимал, как следить, и в один прекрасный день место на дисках просто закончилось.
Биллинг прилег и народ все праздники резвился, попутно загоняя контору в долги. После чего из конторы ушел второй человек, который также стоял у ее основания и понимал в сетях.
Но шефа ничего не смутило, подумаешь, сисадмин, ну и подумаешь сетевой инженер. Больно нужны, у нас же все хорошо. Были приглашены специалисты со стороны и был внедрен новый биллинг, уже на Linux.
Между тем качество услуг стремительно падало, но во всем оказались виноваты пользователи, мол это они положили сеть широковещательными чатами и DC++ обменом. После чего эти приложения попытались просто запретить. Мол у кого обнаружим – отключим.
Но отключить пришлось бы решительно всех, поэтому такая инициатива сошла на нет. Лучше, естественно, не стало. Да и как оно станет в отсутствие сетевого инженера.
Прошло еще года полтора, звонит мне их шеф, мол ты же в Linux понимаешь? Понимаю. Приезжай, дело есть.
Приехал. Новый биллинг лежит. Начинаю разбираться. В наличии неплохой по тем временам сервер и RAID 5 с запасным диском. В RAID 5 выпали два диска из трех, а запасной кто-то свистнул, поставив вместо него неисправный диск бытовой серии.
Ну что тут было сказать? Только похлопать по плечу и сообщить, что медицина бессильна. Особенно если в штате не было ни одного следящего за инфраструктурой сотрудника.
Пошарившись по серверной нашли сервер с бекапами, но там был только бекап БД биллинга.
Ну вот, не все так плохо, можно восстановить.
Он спрашивает меня, смогу ли я это сделать. Отвечаю, что нет, я этот биллинг первый раз в жизни вижу и лучше всего обратиться к его разработчикам.
Выяснилось, что это не вариант, так как он им денег должен и за поддержку не платил два года. А зачем, ведь все работало.
В общем, принес ему свои соболезнования и сказал, что мне пора и было бы неплохо дать мне денег.
На что услышал, а за что тебе денег, ты же ничем мне не помог. В итоге, пояснил ему, что он чудак, развернулся и ушел.
Провайдеру тут же настал карачун, народ разбежался. А шеф? Шеф продал сети одному из федеральных провайдеров.
А что же теперь? А он теперь начальник в местном отделении федерального провайдера. До чего-то важного его не допускают, но теплое кресло выделили. Ну и репутация чудака на букву М за ним числится до сих пор.
Он же, в свою очередь, особенно после пары рюмок, любит поучать молодежь и рассказывать как у него давно был свой бизнес и как он его удачно продал, поняв, что не может тягаться на равных с федералами.
🔥10👍5😁4❤1🤮1
Кошмар на улице Вязов
Сегодня мне приснился страшный сон, от которого я проснулся буквально в холодном поту. На его фоне любые киношные монстры, маньяки и прочие ужастики кажутся невинным детским утренником.
Сон пересказывать не буду: местами он иррациональный, как и положено сновидениям. Но суть свелась к простой фабуле: в чужом городе у меня украли телефон, и я остался в незнакомом месте — без связи, без денег и без навигации.
И ведь это реальный кошмар современного мира. Сегодня смартфон — не просто средство связи, а цифровой центр человека, в котором сосредоточено практически всё. Оказавшись без него, чувствуешь себя буквально голым.
Начнём со связи. Сколько номеров помнит наизусть современный человек? Хорошо, если один — свой собственный. Люди старой закалки, возможно, удержат в памяти два-три номера самых близких. Но и то вряд ли: мы видим цифры один раз при сохранении, а дальше просто тапаем по записи в адресной книге.
К тому же основным средством общения давно стали мессенджеры. Они хоть и привязаны к номеру, но просто попросить телефон у прохожего и «быстро черкнуть в телегу» не выйдет. В итоге, даже если добрый человек протянет вам свой аппарат, звонить будет попросту некому. Память пуста. Но это лишь верхушка айсберга.
Деньги. Многие уже много лет назад отказались от наличных, а некоторые — и от физического пластика. Зачем носить с собой карты, если их можно потерять или забыть, когда всё и так в телефоне?
Тем более что у большинства карт больше одной: повседневная, для онлайн-покупок, для регулярных автосписаний. Деньги между ними перекидываются за секунду в банковском приложении.
Без смартфона вы рискуете остаться либо без копейки вообще, либо без доступа к основной части своих средств. А это уже проблема принципиально другого масштаба.
Третий момент — навигация. Мы намертво привыкли ориентироваться по экрану. Вбил адрес — тебе проложили маршрут или сразу вызвали такси. Причем можно даже без точного адреса: просто ткни «метро такое-то» или название торгового центра.
Спросить дорогу у прохожих? Большинство знает свой дом и пару соседних дворов. Если это не центральный вокзал, вам просто неопределенно махнут рукой: мол, идите вон до того угла, а там еще у кого-нибудь спросите. Да и до того же вокзала без денег и такси еще попробуй доберись.
Но и это не всё. Цифровизация окончательно поглотила сервисы: билеты, бронирования, документы. Недавно покупал билеты на поезд: на почту упало несколько PDF, в приложении РЖД всё подтянулось.
На посадку пустят по паспорту, но номер поезда, вагон и место надо где-то подсмотреть. Ладно, вокзал — полбеды: пришел пораньше, сел и жди, проводник через любой вагон разберется.
А как быть с арендой жилья? Сейчас повсеместно внедряют бесконтактное заселение. К моменту заезда вам в мессенджер просто скидывают код от кодового замка или сейфа с ключом.
Нет телефона — нет кода. И хоть головой в дверь бейся — никто не откроет, потому что на месте никого нет, а служба поддержки сидит в чате. Имея на руках полностью оплаченную бронь, вы запросто останетесь ночевать на лавочке.
Добавьте сюда страховки, справки, медицинский полис, который давно никто не носит на бумаге, — всё лежит на «Госуслугах». А ключ к ним — опять в кармане.
Конечно, можно по старинке распечатывать стопку бумаг, возить с собой заначку наличных и выбирать отели исключительно с круглосуточным ресепшеном. Но тренд неумолим: мы всё глубже уходим в стопроцентную цифру.
И смартфон в этой реальности стал единственной точкой присутствия человека. Потерял, разбил, украли или просто сел аккумулятор — и ты в ту же секунду выброшен на обочину жизни.
Сегодня мне приснился страшный сон, от которого я проснулся буквально в холодном поту. На его фоне любые киношные монстры, маньяки и прочие ужастики кажутся невинным детским утренником.
Сон пересказывать не буду: местами он иррациональный, как и положено сновидениям. Но суть свелась к простой фабуле: в чужом городе у меня украли телефон, и я остался в незнакомом месте — без связи, без денег и без навигации.
И ведь это реальный кошмар современного мира. Сегодня смартфон — не просто средство связи, а цифровой центр человека, в котором сосредоточено практически всё. Оказавшись без него, чувствуешь себя буквально голым.
Начнём со связи. Сколько номеров помнит наизусть современный человек? Хорошо, если один — свой собственный. Люди старой закалки, возможно, удержат в памяти два-три номера самых близких. Но и то вряд ли: мы видим цифры один раз при сохранении, а дальше просто тапаем по записи в адресной книге.
К тому же основным средством общения давно стали мессенджеры. Они хоть и привязаны к номеру, но просто попросить телефон у прохожего и «быстро черкнуть в телегу» не выйдет. В итоге, даже если добрый человек протянет вам свой аппарат, звонить будет попросту некому. Память пуста. Но это лишь верхушка айсберга.
Деньги. Многие уже много лет назад отказались от наличных, а некоторые — и от физического пластика. Зачем носить с собой карты, если их можно потерять или забыть, когда всё и так в телефоне?
Тем более что у большинства карт больше одной: повседневная, для онлайн-покупок, для регулярных автосписаний. Деньги между ними перекидываются за секунду в банковском приложении.
Без смартфона вы рискуете остаться либо без копейки вообще, либо без доступа к основной части своих средств. А это уже проблема принципиально другого масштаба.
Третий момент — навигация. Мы намертво привыкли ориентироваться по экрану. Вбил адрес — тебе проложили маршрут или сразу вызвали такси. Причем можно даже без точного адреса: просто ткни «метро такое-то» или название торгового центра.
Спросить дорогу у прохожих? Большинство знает свой дом и пару соседних дворов. Если это не центральный вокзал, вам просто неопределенно махнут рукой: мол, идите вон до того угла, а там еще у кого-нибудь спросите. Да и до того же вокзала без денег и такси еще попробуй доберись.
Но и это не всё. Цифровизация окончательно поглотила сервисы: билеты, бронирования, документы. Недавно покупал билеты на поезд: на почту упало несколько PDF, в приложении РЖД всё подтянулось.
На посадку пустят по паспорту, но номер поезда, вагон и место надо где-то подсмотреть. Ладно, вокзал — полбеды: пришел пораньше, сел и жди, проводник через любой вагон разберется.
А как быть с арендой жилья? Сейчас повсеместно внедряют бесконтактное заселение. К моменту заезда вам в мессенджер просто скидывают код от кодового замка или сейфа с ключом.
Нет телефона — нет кода. И хоть головой в дверь бейся — никто не откроет, потому что на месте никого нет, а служба поддержки сидит в чате. Имея на руках полностью оплаченную бронь, вы запросто останетесь ночевать на лавочке.
Добавьте сюда страховки, справки, медицинский полис, который давно никто не носит на бумаге, — всё лежит на «Госуслугах». А ключ к ним — опять в кармане.
Конечно, можно по старинке распечатывать стопку бумаг, возить с собой заначку наличных и выбирать отели исключительно с круглосуточным ресепшеном. Но тренд неумолим: мы всё глубже уходим в стопроцентную цифру.
И смартфон в этой реальности стал единственной точкой присутствия человека. Потерял, разбил, украли или просто сел аккумулятор — и ты в ту же секунду выброшен на обочину жизни.
😁13👍7👀4❤3🤮3
Современные файловые системы Linux
Выбор файловой системы в Linux может оказаться сложной задачей для новичка. На что смотреть? На тесты и бенчмарки, которые проводятся на пустом SSD и не отражают реальность?
Сегодня мы коротко разберем актуальный квартет: ext4, XFS, Btrfs и ZFS, подсветив все их основные плюсы и минусы.
1️⃣ ext4: Проверенная временем классика
Это классическая блочная журналируемая ФС с записью «на месте» (In-place update). Максимальная стабильность, предсказуемость и надежность, минимальное потребление ресурсов CPU и RAM. Все это проверено десятилетиями.
Но это именно классическая ФС и если вы хотите снапшоты, пулы, сжатие и проверку целостности – ничего этого нет.
Есть еще «родовая травма» - таблица индексных дескрипторов (inodes) размечается один раз на этапе форматирования и впоследствии изменена быть не может.
Если диск используется под сценарии с миллионами крошечных файлов (почтовый сервер с Maildir, кэш аватарок веб-сервера, мелкие сессии, очереди задач), наступает классический парадокс: свободное место есть , а записать файл нельзя.
2️⃣ XFS: Enterprise-стандарт
XFS - 64-битная высокомасштабируемая журналируемая ФС с аллокацией по экстентам (extents) и разделением пространства на независимые группы размещения (Allocation Groups).
Обеспечивает высокую производительность при параллельной многопоточной записи/чтении и работе с крупными файлами (видео, дампы, медиа).
Дефолтная ФС в enterprise-дистрибутивах (RHEL / Rocky / AlmaLinux).
Но есть и достаточно серьезные недостатки - раздел XFS нельзя уменьшить, вообще никак: система XFS умеет расти (xfs_growfs), но архитектурно не умеет уменьшаться.
А далее имеем классический случай, на смену одним дискам на 1 ТБ (честный двоичный байт 2^40 = 1024 ГБ) купили маркетинговый «терабайт» (10^12 байт ~ 931 ГиБ). И что? И все, приехали.
3️⃣ Btrfs: «Спасение» силами гигантов индустрии
На заре своего появления (конец 2000-х / начало 2010-х) Btrfs имела репутацию крайне нестабильной, «сырой» и опасной системы. Она регулярно теряла данные при падениях питания, страдала от критических багов в аллокаторе свободного места, а алгоритмы RAID5/6 были в целом неработоспособные.
Red Hat со временем и вовсе официально признала Btrfs устаревшей (deprecated в RHEL 7.4) и полностью вырезала её поддержку в RHEL 8, сделав будущее этой ФС очень туманным.
Поворотным моментом стал приход в Meta* новой команды инженеров (Крис Мейсон, Йозеф Бачик и прочие). Они переписали и довели до ума самые проблемные места, код работы со свободным пространством, асинхронную очистку, сжатие ZSTD и интеграцию с механизмами ядра Linux.
В итоге это превратило вечную «бета» в надежную систему, которая используется по умолчанию для SUSE и Fedora.
4️⃣ ZFS: Монолитная СХД в одном флаконе
Это не просто ФС, а связка: файловая система + менеджер томов + RAID с пулом накопителей и легкими датасетами. Полный сквозной контроль целостности: контрольные суммы на каждый блок, самовосстановление, снапшоты, репликация и собственный кэш ARC в RAM.
Но за это все приходится платить, в первую очередь высокими требованиями к RAM и высоким коэффициентом WAF (что характерно для всех CoW систем).
Хотя в грамотных руках это того стоит, вы получаете очень гибкое, настраиваемое и масштабируемое хранилище корпоративного уровня.
Выводы:
🔹Нужна железобетонная стабильность «поставил и забыл»? ext4.
🔹Высокие параллельные нагрузки, базы или огромные файлы без нужды сжимать раздел? XFS.
🔹Десктоп, снапшоты системы перед апдейтом и сжатие на лету? Btrfs.
🔹СХД, отказоустойчивые пулы, виртуализация и контроль целостности? ZFS.
* Meta признана экстремистской организацией в России.
Выбор файловой системы в Linux может оказаться сложной задачей для новичка. На что смотреть? На тесты и бенчмарки, которые проводятся на пустом SSD и не отражают реальность?
Сегодня мы коротко разберем актуальный квартет: ext4, XFS, Btrfs и ZFS, подсветив все их основные плюсы и минусы.
1️⃣ ext4: Проверенная временем классика
Это классическая блочная журналируемая ФС с записью «на месте» (In-place update). Максимальная стабильность, предсказуемость и надежность, минимальное потребление ресурсов CPU и RAM. Все это проверено десятилетиями.
Но это именно классическая ФС и если вы хотите снапшоты, пулы, сжатие и проверку целостности – ничего этого нет.
Есть еще «родовая травма» - таблица индексных дескрипторов (inodes) размечается один раз на этапе форматирования и впоследствии изменена быть не может.
Если диск используется под сценарии с миллионами крошечных файлов (почтовый сервер с Maildir, кэш аватарок веб-сервера, мелкие сессии, очереди задач), наступает классический парадокс: свободное место есть , а записать файл нельзя.
2️⃣ XFS: Enterprise-стандарт
XFS - 64-битная высокомасштабируемая журналируемая ФС с аллокацией по экстентам (extents) и разделением пространства на независимые группы размещения (Allocation Groups).
Обеспечивает высокую производительность при параллельной многопоточной записи/чтении и работе с крупными файлами (видео, дампы, медиа).
Дефолтная ФС в enterprise-дистрибутивах (RHEL / Rocky / AlmaLinux).
Но есть и достаточно серьезные недостатки - раздел XFS нельзя уменьшить, вообще никак: система XFS умеет расти (xfs_growfs), но архитектурно не умеет уменьшаться.
А далее имеем классический случай, на смену одним дискам на 1 ТБ (честный двоичный байт 2^40 = 1024 ГБ) купили маркетинговый «терабайт» (10^12 байт ~ 931 ГиБ). И что? И все, приехали.
3️⃣ Btrfs: «Спасение» силами гигантов индустрии
На заре своего появления (конец 2000-х / начало 2010-х) Btrfs имела репутацию крайне нестабильной, «сырой» и опасной системы. Она регулярно теряла данные при падениях питания, страдала от критических багов в аллокаторе свободного места, а алгоритмы RAID5/6 были в целом неработоспособные.
Red Hat со временем и вовсе официально признала Btrfs устаревшей (deprecated в RHEL 7.4) и полностью вырезала её поддержку в RHEL 8, сделав будущее этой ФС очень туманным.
Поворотным моментом стал приход в Meta* новой команды инженеров (Крис Мейсон, Йозеф Бачик и прочие). Они переписали и довели до ума самые проблемные места, код работы со свободным пространством, асинхронную очистку, сжатие ZSTD и интеграцию с механизмами ядра Linux.
В итоге это превратило вечную «бета» в надежную систему, которая используется по умолчанию для SUSE и Fedora.
4️⃣ ZFS: Монолитная СХД в одном флаконе
Это не просто ФС, а связка: файловая система + менеджер томов + RAID с пулом накопителей и легкими датасетами. Полный сквозной контроль целостности: контрольные суммы на каждый блок, самовосстановление, снапшоты, репликация и собственный кэш ARC в RAM.
Но за это все приходится платить, в первую очередь высокими требованиями к RAM и высоким коэффициентом WAF (что характерно для всех CoW систем).
Хотя в грамотных руках это того стоит, вы получаете очень гибкое, настраиваемое и масштабируемое хранилище корпоративного уровня.
Выводы:
🔹Нужна железобетонная стабильность «поставил и забыл»? ext4.
🔹Высокие параллельные нагрузки, базы или огромные файлы без нужды сжимать раздел? XFS.
🔹Десктоп, снапшоты системы перед апдейтом и сжатие на лету? Btrfs.
🔹СХД, отказоустойчивые пулы, виртуализация и контроль целостности? ZFS.
* Meta признана экстремистской организацией в России.
1👍16❤5🥱1
Какую ФС на серверах с Linux вы используете? (Можно выбрать несколько значений)
Anonymous Poll
78%
ext4
15%
XFS
11%
BtrFS
33%
ZFS
0%
Свой вариант (в комментариях)
12%
Просто посмотреть ответы
👍2