Допустимые типы контента для хранилищ Proxmox
Собрали в небольшую, но полезную таблицу допустимые типы контента для разных типов хранилищ.
С ее помощью можно быстро оценить какой тип хранилища лучшим образом подходит для ваших задач.
Вся информация взята из официальных источников.
Поводом для создания подобной таблички послужили злоключения молодого коллеги, который потратил время на установку и настройку iSCSI-таргета, но только подключив его к Proxmox обнаружил, что оно не поддерживает LXC-контейнеры.
Собрали в небольшую, но полезную таблицу допустимые типы контента для разных типов хранилищ.
С ее помощью можно быстро оценить какой тип хранилища лучшим образом подходит для ваших задач.
Вся информация взята из официальных источников.
Поводом для создания подобной таблички послужили злоключения молодого коллеги, который потратил время на установку и настройку iSCSI-таргета, но только подключив его к Proxmox обнаружил, что оно не поддерживает LXC-контейнеры.
5👍28❤3🔥3🤔2
Вектор развития. Продолжение
Читатели задали очень хороший вопрос: а в чем смысл развития сотрудника по собственному вектору, вне трека предприятия? Ведь работодателю нужны не знания, а опыт – и он совершенно прав.
Что такое знания? Это просто теория. А опыт – это умение применять знания на практике. И платят хорошему специалисту именно за опыт, а не за знания. Так что получается? Менять работу?
Разные гуру и коучи бодро скажут – да! Не бойся меняться, отбрось страхи и неуверенность и вперед к новым вершинам! Но языком истории рассказывать, это не мешки разгружать, поэтому вернемся в суровую реальность.
Что значит поменять работу ради перспектив развития? Вы уходите с крепкой позиции (мидл или даже сеньор) в своем стеке на позицию начинающего (джуниора) в новом стеке, проседая как в зарплате, так и в разных прочих плюшках, включая ценность вас в глазах работодателя.
И хорошо если вам 20 с хвостиком и у вас за плечами нет детей, кредитов, ипотек, жены, тещи и стареньких родителей.
А в ином раскладе эта авантюра является именно авантюрой, с непонятным итоговым результатом. Оставить все как есть? Тоже опасно. В этом случае вы станете заложником вашего работодателя, особенно если он поймет, что за его воротами вы по факту «человек без профессии».
Как быть? Что делать? К счастью, мы живем в современном мире и не связаны именно своей локацией. Если вы понимаете, что вам надо развиваться, но в рамках своего рабочего места вы не можете этого сделать – то к вашим услугам сеть.
Начнем с открытых проектов. Многие из них держатся на паре-тройке активных разработчиков и поэтому каждый активный участник ими только приветствуется. А это отличная строка в резюме, да и просто пыль в глаза пустить – у кого еще в штате есть разработчик открытого проекта?
А работодатель вполне может оценить вашу активность в проекте и прикинуть возможный опыт, который перекроет ваш опыт с прошлой работы. Мол, да, на старом месте он со всякой ерундой работал, но вот же проект вел, активно. Нам такие нужны.
Другой вариант – пет-проекты, это тоже хороший способ рассказать о себе и показать свои умения. Особенно если этот проект имеет практическое применение. А для этого можно найти себе какое-нибудь небольшое предприятие, на котором это обкатывать в свободное от работы время.
Малый бизнес он вообще не избалован вниманием и стеснен в средствах и если вы ему за сумму малую предложите стать «подопытным кроликом» и выгоды для него будет больше чем возможного убытка – он согласится.
Также не забывайте про профессиональные сообщества. Если брать мир 1С, то тот же Инфостарт. Написали отчет или обработку? Опубликуйте. И не важно, что там есть уже сотни таких же, важен сам факт публикации. Из которых потом соберется ваше портфолио.
Работодатель не будет вникать в тонкости, он отметит, что вы ведете активную жизнь в профессиональных сообществах, имеете собственные разработки и публикации, что заменит вам опыт в рамках текущего работодателя.
И не стесняйтесь продвигать себя везде, где это возможно. Есть возможность что-то написать или опубликовать в техническом сообществе – напишите и опубликуйте. Есть возможность поехать на конференцию – езжайте.
В общем – чем больше вы засветитесь в профессиональных тусовках – тем лучше. Это та же самая строчка в резюме про опыт. Да, вы работали с устаревшим стеком, но в сообществе вас знают как грамотного специалиста по новому стеку. И это будет ваш плюс при смене работы.
Теперь вы сможете поменять рабочее место примерно с равной позиции на равную. Но, главное, вы должны быть, а не казаться. Иначе может быть очень больное приземление, когда вы уже не там и не здесь. И куда теперь идти – непонятно.
Но если вы реально втянулись в новую тему, активны в профессиональных сообществах, имеете публикации и проекты, то всем будет все равно на ваш бэкграунд, вас будут воспринимать как современного специалиста с опытом, что вам и надо.
Читатели задали очень хороший вопрос: а в чем смысл развития сотрудника по собственному вектору, вне трека предприятия? Ведь работодателю нужны не знания, а опыт – и он совершенно прав.
Что такое знания? Это просто теория. А опыт – это умение применять знания на практике. И платят хорошему специалисту именно за опыт, а не за знания. Так что получается? Менять работу?
Разные гуру и коучи бодро скажут – да! Не бойся меняться, отбрось страхи и неуверенность и вперед к новым вершинам! Но языком истории рассказывать, это не мешки разгружать, поэтому вернемся в суровую реальность.
Что значит поменять работу ради перспектив развития? Вы уходите с крепкой позиции (мидл или даже сеньор) в своем стеке на позицию начинающего (джуниора) в новом стеке, проседая как в зарплате, так и в разных прочих плюшках, включая ценность вас в глазах работодателя.
И хорошо если вам 20 с хвостиком и у вас за плечами нет детей, кредитов, ипотек, жены, тещи и стареньких родителей.
А в ином раскладе эта авантюра является именно авантюрой, с непонятным итоговым результатом. Оставить все как есть? Тоже опасно. В этом случае вы станете заложником вашего работодателя, особенно если он поймет, что за его воротами вы по факту «человек без профессии».
Как быть? Что делать? К счастью, мы живем в современном мире и не связаны именно своей локацией. Если вы понимаете, что вам надо развиваться, но в рамках своего рабочего места вы не можете этого сделать – то к вашим услугам сеть.
Начнем с открытых проектов. Многие из них держатся на паре-тройке активных разработчиков и поэтому каждый активный участник ими только приветствуется. А это отличная строка в резюме, да и просто пыль в глаза пустить – у кого еще в штате есть разработчик открытого проекта?
А работодатель вполне может оценить вашу активность в проекте и прикинуть возможный опыт, который перекроет ваш опыт с прошлой работы. Мол, да, на старом месте он со всякой ерундой работал, но вот же проект вел, активно. Нам такие нужны.
Другой вариант – пет-проекты, это тоже хороший способ рассказать о себе и показать свои умения. Особенно если этот проект имеет практическое применение. А для этого можно найти себе какое-нибудь небольшое предприятие, на котором это обкатывать в свободное от работы время.
Малый бизнес он вообще не избалован вниманием и стеснен в средствах и если вы ему за сумму малую предложите стать «подопытным кроликом» и выгоды для него будет больше чем возможного убытка – он согласится.
Также не забывайте про профессиональные сообщества. Если брать мир 1С, то тот же Инфостарт. Написали отчет или обработку? Опубликуйте. И не важно, что там есть уже сотни таких же, важен сам факт публикации. Из которых потом соберется ваше портфолио.
Работодатель не будет вникать в тонкости, он отметит, что вы ведете активную жизнь в профессиональных сообществах, имеете собственные разработки и публикации, что заменит вам опыт в рамках текущего работодателя.
И не стесняйтесь продвигать себя везде, где это возможно. Есть возможность что-то написать или опубликовать в техническом сообществе – напишите и опубликуйте. Есть возможность поехать на конференцию – езжайте.
В общем – чем больше вы засветитесь в профессиональных тусовках – тем лучше. Это та же самая строчка в резюме про опыт. Да, вы работали с устаревшим стеком, но в сообществе вас знают как грамотного специалиста по новому стеку. И это будет ваш плюс при смене работы.
Теперь вы сможете поменять рабочее место примерно с равной позиции на равную. Но, главное, вы должны быть, а не казаться. Иначе может быть очень больное приземление, когда вы уже не там и не здесь. И куда теперь идти – непонятно.
Но если вы реально втянулись в новую тему, активны в профессиональных сообществах, имеете публикации и проекты, то всем будет все равно на ваш бэкграунд, вас будут воспринимать как современного специалиста с опытом, что вам и надо.
👍12🤔9❤2👌2🫡1
Спрашивают – отвечаем
Вопрос вот в чем: есть энтерпрайз SSD за очень много денег, там все ок. А как быть бедным, кто ставит nvme в лучшем случае из топа потребительских? Что выбрать, на что смотреть?
Начнем с того, что выбрать можно все что угодно, даже не из топа, все зависит от доступного бюджета. Но перед выбором нужно внимательно посмотреть.
Начнем с того, что пишут в спецификациях. А именно с ресурса. Это основной показатель, от которого зависит как часто вы будете менять диски. Соизмеряем его с текущей нагрузкой и прикидываем затраты. Может оказаться так, что взять более дорогой диск будет выгоднее.
А может произойти ровно наоборот. Иногда выгоднее чаще менять дешевые диски, чем дорогие, но реже.
При этом следует понимать, что никакой серебряной пули в потребительском сегменте нет. Все упирается в ресурс. Это для настольного компьютера вы покупаете топовый Samsung и несколько лет радуетесь жизни.
В случае серверного применения ресурс дорого Samsung будет тратиться также быстро, как и ресурс более дешевого аналога. А если все равно через год менять, то можно не выпендриваться и взять что-нибудь попроще.
Дальше смотрим на еще один важный параметр: модель работы SLC-кеша. В описаниях его нет, тут помогут только обзоры. Например, есть полностью аппаратно одинаковые диски, но с разными вариантами кеширования и разным поведением под нагрузками.
Грубо говоря, есть два основных варианта. В первом под кеш отдается все свободное место (33% от свободной емкости накопителя TLC), который пишется на максимальной скорости. А вот потом наступает самый плохой для диска сценарий – контроллер одновременно пишет и уплотняет данные и скорость там может упасть до неприлично низких значений.
Второй вариант – небольшой кеш и потом достаточно высокая и стабильная скорость записи, но далеко уже не та, что указана в спецификациях диска.
Тут нельзя однозначно сказать, что хорошо, а что плохо, смотрите по своим задачам и нагрузкам. Где-то лучше себя покажет одна модель кеширования, где-то другая.
Определились, хорошо. Теперь обращаем внимание на потребительские характеристики. В частности, на теплоотвод и возможность его снять без потери гарантии. Лучше всего брать модели, где теплоотвод сразу не приклеен, ну или понимать, что гарантии на диск у вас не будет.
Почему? Да потому что серверная нагрузка сильно отличается от настольной и вашему диску в обязательном порядке нужен хороший теплоотвод, иначе он постоянно будет находится в состоянии перегрева или близкого к нему.
Чтобы оградить себя от внезапного отказа в обязательном порядке собираем RAID. И в этом случае нам важно добиться идентичных режимов работы у обоих дисков.
Если вы используете разъемы на материнской плате – убедитесь, что к ним подведено одинаковое количество линий PCIe и одинакового поколения.
Иначе ваш массив будет работать на скорости самого медленного диска и это в лучшем случае.
Также очень важно еще и соблюдать идентичность скоростных характеристик дисков, в частности режимов кеширования. Если один диск продолжает принимать данные на полной скорости, а второй ее резко снизил, то есть ненулевые шансы, что такой диск выкинет из массива, хотя он будет полностью исправен.
Либо мы получим резкую деградацию производительности, иногда буквально «на ровном месте».
Это условие важно соблюдать и при замене дисков в массиве. Если купить точно такой же диск нет возможности, то приобретайте максимально похожий, желательно на контроллере того же производителя.
Если это невозможно – меняйте оба диска. Также не следует сочетать в одном массиве диски на разных поколениях шины PCIe, итоговая скорость записи может упасть ниже скорости самого медленного диска.
Ну и постоянный мониторинг. Температуры, ресурса и свободного места на массиве. Не допускайте заполнения более 60-70%, лучше всего иметь запас примерно на 50%, иначе задумайтесь о приобретении более емких моделей.
Также заведите за правило менять диски раз в три года (средний срок гарантии) даже если с ними все в порядке. Кстати это касается не только NVMe.
Вопрос вот в чем: есть энтерпрайз SSD за очень много денег, там все ок. А как быть бедным, кто ставит nvme в лучшем случае из топа потребительских? Что выбрать, на что смотреть?
Начнем с того, что выбрать можно все что угодно, даже не из топа, все зависит от доступного бюджета. Но перед выбором нужно внимательно посмотреть.
Начнем с того, что пишут в спецификациях. А именно с ресурса. Это основной показатель, от которого зависит как часто вы будете менять диски. Соизмеряем его с текущей нагрузкой и прикидываем затраты. Может оказаться так, что взять более дорогой диск будет выгоднее.
А может произойти ровно наоборот. Иногда выгоднее чаще менять дешевые диски, чем дорогие, но реже.
При этом следует понимать, что никакой серебряной пули в потребительском сегменте нет. Все упирается в ресурс. Это для настольного компьютера вы покупаете топовый Samsung и несколько лет радуетесь жизни.
В случае серверного применения ресурс дорого Samsung будет тратиться также быстро, как и ресурс более дешевого аналога. А если все равно через год менять, то можно не выпендриваться и взять что-нибудь попроще.
Дальше смотрим на еще один важный параметр: модель работы SLC-кеша. В описаниях его нет, тут помогут только обзоры. Например, есть полностью аппаратно одинаковые диски, но с разными вариантами кеширования и разным поведением под нагрузками.
Грубо говоря, есть два основных варианта. В первом под кеш отдается все свободное место (33% от свободной емкости накопителя TLC), который пишется на максимальной скорости. А вот потом наступает самый плохой для диска сценарий – контроллер одновременно пишет и уплотняет данные и скорость там может упасть до неприлично низких значений.
Второй вариант – небольшой кеш и потом достаточно высокая и стабильная скорость записи, но далеко уже не та, что указана в спецификациях диска.
Тут нельзя однозначно сказать, что хорошо, а что плохо, смотрите по своим задачам и нагрузкам. Где-то лучше себя покажет одна модель кеширования, где-то другая.
Определились, хорошо. Теперь обращаем внимание на потребительские характеристики. В частности, на теплоотвод и возможность его снять без потери гарантии. Лучше всего брать модели, где теплоотвод сразу не приклеен, ну или понимать, что гарантии на диск у вас не будет.
Почему? Да потому что серверная нагрузка сильно отличается от настольной и вашему диску в обязательном порядке нужен хороший теплоотвод, иначе он постоянно будет находится в состоянии перегрева или близкого к нему.
Чтобы оградить себя от внезапного отказа в обязательном порядке собираем RAID. И в этом случае нам важно добиться идентичных режимов работы у обоих дисков.
Если вы используете разъемы на материнской плате – убедитесь, что к ним подведено одинаковое количество линий PCIe и одинакового поколения.
Иначе ваш массив будет работать на скорости самого медленного диска и это в лучшем случае.
Также очень важно еще и соблюдать идентичность скоростных характеристик дисков, в частности режимов кеширования. Если один диск продолжает принимать данные на полной скорости, а второй ее резко снизил, то есть ненулевые шансы, что такой диск выкинет из массива, хотя он будет полностью исправен.
Либо мы получим резкую деградацию производительности, иногда буквально «на ровном месте».
Это условие важно соблюдать и при замене дисков в массиве. Если купить точно такой же диск нет возможности, то приобретайте максимально похожий, желательно на контроллере того же производителя.
Если это невозможно – меняйте оба диска. Также не следует сочетать в одном массиве диски на разных поколениях шины PCIe, итоговая скорость записи может упасть ниже скорости самого медленного диска.
Ну и постоянный мониторинг. Температуры, ресурса и свободного места на массиве. Не допускайте заполнения более 60-70%, лучше всего иметь запас примерно на 50%, иначе задумайтесь о приобретении более емких моделей.
Также заведите за правило менять диски раз в три года (средний срок гарантии) даже если с ними все в порядке. Кстати это касается не только NVMe.
👍15🤔5❤3🤯1
Особенности использования райзеров для M.2 NVMe дисков
В комментариях подняли интересную тему – райзеры для M.2 дисков, что это такое? Говоря простым языком – это плата переходник, которая позволяет подключиться к штатному слоту PCIe x16 материнской платы и на полной скорости от процессора подключить до 4 NVMe дисков.
Но не все так просто в нашем мире. Нет, сама идея райзера хороша, вы не только получаете 4 диска на полной пропускной способности шины, но еще и выносите их в сторону от горячих участков материнской платы, а многие модели райзеров, как показанная на рисунке модель от ASRock, обеспечивают еще и отличное охлаждение.
Основная проблема кроется в линиях PCIe, которые конечны и которые должны быть правильно сконфигурированы. Самые распространенные райзеры – пассивные, т.е. просто плата переходник с одного разъема на другой. Без какого-либо преобразования.
И тут нам нужно не просто подать туда PCIe x16, а заставить контроллер (который в процессоре) работать в режиме x4/x4/x4/x4. Только в этом случае у нас будут видеться и работать все четыре диска райзера.
А дальше уже все не так просто и сильно зависит от железа. Начнем с процессоров AMD.
Процессоры AMD старших серий предоставляют пользователю 24 линии PCIe, 16 из них идут на первый слот для видеокарты, еще 4 линии на разъем M.2, остальные разводятся по дополнительным разъемам в самых разных вариациях.
Но если процессор содержит встроенное видеоядро, которому самому нужны PCIe линии, то решается это по-разному, в сериях AM4 (Ryzen 3000G / 4000G / 5000G) вместо PCIe 4.0 вы получите те же 24 линии PCIe 3.0.
А вот в новых сериях AM5 (Ryzen 8000G) линии сильно урезаны. На старших моделях (8700G/8600G) под основной GPU-слот выделено только 8 линий PCIe 4.0. На младших (8500G/8300G) — всего 4 линии на основной слот.
Но при этом процессоры AMD, если это реализовано в BIOS материнской платы поддерживают бифуркацию до x4/x4/x4/x4, никаких проблем с этим нет.
Кроме процессора линии PCIe может предоставлять чипсет, но он связан с процессором 4 линиями PCIe и может служить узким горлышком, особенно если вы используете сеть 2,5 G и выше или прочие линии от чипсета.
Поэтому нормальная практика в том, что чипсет предоставляет линии предыдущего поколения, если у процессора поддержка PCIe 4.0, то чипсет будет отдавать линии PCIe 3.0 и вряд ли вы найдете платы, где чипсет отдает 16 линий.
Если перейти в стан их конкурентов, то у Intel не все так радужно. Если мы берем процессоры LGA1700 — Core 12, 13, 14 поколений, то там пользователю доступно 20 линий PCIe, 16 на основной слот, 4 для NVMe.
Для LGA1851 — Core Ultra 200S / Arrow Lake количество линий было увеличено до 24 и делятся они как 16 линий на основной слот, а остальные 8 на два M.2 разъема.
Но процессоры Intel не поддерживают бифуркацию до x4/x4/x4/x4, максимум x8/x4/x4, что не дает возможности полноценно использовать пассивные райзеры.
Из хороших новостей: для общения с чипсетом процессор использует шину DMI 4.0 x8, что аналогично восьми линиям PCIe 4.0 и чипсетные линии не являются узким горлышком, ну а как и кто их развел – это уже надо спрашивать с производителей плат.
Если ваша плата или процессор не поддерживают полноценную бифуркацию до x4/x4/x4/x4, то вам нужен активный райзер, на котором установлен дополнительный чип PCIe коммутатора (моста) и который сам разложит поступившие ему 16 линий на 4 набора по 4 линии, но такие райзеры дороже.
Поэтому нельзя просто так купить и поставить райзер, а надо изучить структуру своей материнской платы, процессора и их совместные возможности, иначе можно очень сильно разочароваться.
В комментариях подняли интересную тему – райзеры для M.2 дисков, что это такое? Говоря простым языком – это плата переходник, которая позволяет подключиться к штатному слоту PCIe x16 материнской платы и на полной скорости от процессора подключить до 4 NVMe дисков.
Но не все так просто в нашем мире. Нет, сама идея райзера хороша, вы не только получаете 4 диска на полной пропускной способности шины, но еще и выносите их в сторону от горячих участков материнской платы, а многие модели райзеров, как показанная на рисунке модель от ASRock, обеспечивают еще и отличное охлаждение.
Основная проблема кроется в линиях PCIe, которые конечны и которые должны быть правильно сконфигурированы. Самые распространенные райзеры – пассивные, т.е. просто плата переходник с одного разъема на другой. Без какого-либо преобразования.
И тут нам нужно не просто подать туда PCIe x16, а заставить контроллер (который в процессоре) работать в режиме x4/x4/x4/x4. Только в этом случае у нас будут видеться и работать все четыре диска райзера.
А дальше уже все не так просто и сильно зависит от железа. Начнем с процессоров AMD.
Процессоры AMD старших серий предоставляют пользователю 24 линии PCIe, 16 из них идут на первый слот для видеокарты, еще 4 линии на разъем M.2, остальные разводятся по дополнительным разъемам в самых разных вариациях.
Но если процессор содержит встроенное видеоядро, которому самому нужны PCIe линии, то решается это по-разному, в сериях AM4 (Ryzen 3000G / 4000G / 5000G) вместо PCIe 4.0 вы получите те же 24 линии PCIe 3.0.
А вот в новых сериях AM5 (Ryzen 8000G) линии сильно урезаны. На старших моделях (8700G/8600G) под основной GPU-слот выделено только 8 линий PCIe 4.0. На младших (8500G/8300G) — всего 4 линии на основной слот.
Но при этом процессоры AMD, если это реализовано в BIOS материнской платы поддерживают бифуркацию до x4/x4/x4/x4, никаких проблем с этим нет.
Кроме процессора линии PCIe может предоставлять чипсет, но он связан с процессором 4 линиями PCIe и может служить узким горлышком, особенно если вы используете сеть 2,5 G и выше или прочие линии от чипсета.
Поэтому нормальная практика в том, что чипсет предоставляет линии предыдущего поколения, если у процессора поддержка PCIe 4.0, то чипсет будет отдавать линии PCIe 3.0 и вряд ли вы найдете платы, где чипсет отдает 16 линий.
Если перейти в стан их конкурентов, то у Intel не все так радужно. Если мы берем процессоры LGA1700 — Core 12, 13, 14 поколений, то там пользователю доступно 20 линий PCIe, 16 на основной слот, 4 для NVMe.
Для LGA1851 — Core Ultra 200S / Arrow Lake количество линий было увеличено до 24 и делятся они как 16 линий на основной слот, а остальные 8 на два M.2 разъема.
Но процессоры Intel не поддерживают бифуркацию до x4/x4/x4/x4, максимум x8/x4/x4, что не дает возможности полноценно использовать пассивные райзеры.
Из хороших новостей: для общения с чипсетом процессор использует шину DMI 4.0 x8, что аналогично восьми линиям PCIe 4.0 и чипсетные линии не являются узким горлышком, ну а как и кто их развел – это уже надо спрашивать с производителей плат.
Если ваша плата или процессор не поддерживают полноценную бифуркацию до x4/x4/x4/x4, то вам нужен активный райзер, на котором установлен дополнительный чип PCIe коммутатора (моста) и который сам разложит поступившие ему 16 линий на 4 набора по 4 линии, но такие райзеры дороже.
Поэтому нельзя просто так купить и поставить райзер, а надо изучить структуру своей материнской платы, процессора и их совместные возможности, иначе можно очень сильно разочароваться.
1🔥16👍12❤6👌3🥱1
Деградация данных
Деградация данных (bitrot, битовое гниение) – это достаточно актуальный в настоящее время тип разрушения цифровых данных вследствие накопления некритичных ошибок на запоминающем устройстве.
К сожалению, многие коллеги путают деградацию с выходом из строя ячеек накопителя (бед-блоки) и не придают этому вопросу серьезного значения. А зря.
С бед-блоками достаточно эффективно позволяет справляться RAID, когда в случае ошибки чтения блок заменяется резервным, а его содержимое считывается с исправной копии. Да, возможен эффект появления скрытых бед-блоков, но он решается периодическом перечитыванием содержимого массива.
Проблема битового гниения лежит глубже и именно этот термин представляется нам наиболее удачным. Как и обычное гниение он медленно и незаметно повреждает данные до тех пор, пока разрушения не перейдут в критическую фазу.
Причинами битового гниения становятся ошибки в процессе записи, не связанные с повреждением непосредственно ячеек, они могут даже произойти в оперативной памяти и при отсутствии ECC ваши данные также могут быть незаметно повреждены.
Чаще всего деградация данных происходит при длительном хранении, вследствие деградации заряда ячейки или уровня намагниченности сектора. Ошибок чтения с накопителя это не вызывает, но приводит к нарушению целостности данных.
Как правило большинство современных форматов данных имеют избыточность и изменение одного бита может быть откорректировано встроенными средствами, но для этого эти данные нужно хотя бы открыть.
В противном случае подобные ошибки могут накапливаться и в определенный момент привести к невосстановимому повреждению данных. При этом процесс битового гниения не сопровождается ошибками чтения с накопителя и может происходить на полностью исправном диске.
А так как нет никаких ошибок, то и RAID вам ничем не поможет, особенно уровни без четности. Так, например, в случае зеркала у нас могут оказаться изменены биты в произвольных местах обеих копий. И чем больше по размеру файл и реже обращения к нему – тем вероятнее такое развитие событий.
Некоторую защиту могут предоставлять массивы с четностью (RAID 5 и 6), но здесь многое зависит от контроллера или программной реализации, главное у которых – уметь производить такую проверку в фоновом режиме.
В таком случае имея одну правильную копию и целые данные четности массив может проверить целостность данных и автоматически восстановить их.
Но оптимальным решением проблемы будет вынос таких проверок на уровень файловой системы, так как это позволяет действовать наиболее эффективно и с наименьшей нагрузкой на систему.
Современные системы с контролем целостности – это ZFS, btrfs и ReFS – и именно они рекомендуются для систем хранения больших объемов информации. Каждая из них умеет в фоновом режиме проверять целостность файлов и восстанавливать поврежденные фрагменты используя контрольные суммы (при наличии избыточности, разумеется).
И именно по этой причине тот же Proxmox категорически не рекомендует использование mdadm для хранилищ виртуальных машин в производственных средах.
Деградация данных (bitrot, битовое гниение) – это достаточно актуальный в настоящее время тип разрушения цифровых данных вследствие накопления некритичных ошибок на запоминающем устройстве.
К сожалению, многие коллеги путают деградацию с выходом из строя ячеек накопителя (бед-блоки) и не придают этому вопросу серьезного значения. А зря.
С бед-блоками достаточно эффективно позволяет справляться RAID, когда в случае ошибки чтения блок заменяется резервным, а его содержимое считывается с исправной копии. Да, возможен эффект появления скрытых бед-блоков, но он решается периодическом перечитыванием содержимого массива.
Проблема битового гниения лежит глубже и именно этот термин представляется нам наиболее удачным. Как и обычное гниение он медленно и незаметно повреждает данные до тех пор, пока разрушения не перейдут в критическую фазу.
Причинами битового гниения становятся ошибки в процессе записи, не связанные с повреждением непосредственно ячеек, они могут даже произойти в оперативной памяти и при отсутствии ECC ваши данные также могут быть незаметно повреждены.
Чаще всего деградация данных происходит при длительном хранении, вследствие деградации заряда ячейки или уровня намагниченности сектора. Ошибок чтения с накопителя это не вызывает, но приводит к нарушению целостности данных.
Как правило большинство современных форматов данных имеют избыточность и изменение одного бита может быть откорректировано встроенными средствами, но для этого эти данные нужно хотя бы открыть.
В противном случае подобные ошибки могут накапливаться и в определенный момент привести к невосстановимому повреждению данных. При этом процесс битового гниения не сопровождается ошибками чтения с накопителя и может происходить на полностью исправном диске.
А так как нет никаких ошибок, то и RAID вам ничем не поможет, особенно уровни без четности. Так, например, в случае зеркала у нас могут оказаться изменены биты в произвольных местах обеих копий. И чем больше по размеру файл и реже обращения к нему – тем вероятнее такое развитие событий.
Некоторую защиту могут предоставлять массивы с четностью (RAID 5 и 6), но здесь многое зависит от контроллера или программной реализации, главное у которых – уметь производить такую проверку в фоновом режиме.
В таком случае имея одну правильную копию и целые данные четности массив может проверить целостность данных и автоматически восстановить их.
Но оптимальным решением проблемы будет вынос таких проверок на уровень файловой системы, так как это позволяет действовать наиболее эффективно и с наименьшей нагрузкой на систему.
Современные системы с контролем целостности – это ZFS, btrfs и ReFS – и именно они рекомендуются для систем хранения больших объемов информации. Каждая из них умеет в фоновом режиме проверять целостность файлов и восстанавливать поврежденные фрагменты используя контрольные суммы (при наличии избыточности, разумеется).
И именно по этой причине тот же Proxmox категорически не рекомендует использование mdadm для хранилищ виртуальных машин в производственных средах.
3👍13
Почему доступ в интернет по белым спискам это плохая идея
Каждый раз, когда обсуждается вопрос ограничения доступа в интернет поднимается тема белых списков. Казалось бы, что там сложного? Запретил все и разрешил нужное, теперь можно спать спокойно.
Сделать это можно несколькими способами. При помощи списков адресов, когда адрес назначения сравнивается с заранее составленным списком и либо разрешается, либо блокируется. Пример такой настройки на оборудовании Mikrotik вы можете найти в статье:
🔹 Настройка черного и белого списков в роутерах Mikrotik
Второй вариант – это настройка собственного фильтрующего DNS-сервера. Принцип работы его схож с первым методом, но производится на уровне DNS-запросов, еще до того, как браузер попытается открыть страницу.
Для разрешенных доменов имя исправно разрешается в IP-адрес, для всех иных сервер отвечает, что такого домена не существует. Более подробно это описано в статье:
🔹 Создаем собственный фильтрующий DNS-сервер на базе Pi-hole
Но если попытаться реализовать указанными способами белый список, то вам придется столкнуться с многими сложностями.
Дело в том, что современный сайт – это технически сложный программный продукт и далеко не все его компоненты расположены на одном с ним домене.
Первая сложность настигнет вас буквально сразу, браузер не сможет проверить сертификат. Почему? Потому что ему нужен доступ с CRL (списку отозванных сертификатов), адрес которого указан в сертификате.
Его нужно выяснить и добавить в белый список. Причем таких адресов может быть несколько и для следующего сайта с сертификатом этого же УЦ адрес может быть иным.
Ок, с сертификатами разобрались, но почему вместо сайта белая страница? Или он очень долго загружается?
Потому что для нормального функционирования ему нужно подгрузить скрипты, находящиеся на сторонних адресах. Снова включаем отладку, выясняем эти адреса и добавляем их в белый список.
Для чего так делается? По нескольким причинам. Основная – скорость доставки, скрипты расположенные на CDN доставляются пользователю одинаково быстро в любой точке мира, не загружают канал сайта и не оказывают нагрузки на сервер.
Вторая – это поддержание актуальных версий скриптов используя общедоступные репозитории, где они будут автоматически обновляться в пределах текущей версии при обнаружении багов или уязвимостей.
Ладно, нашли эти адреса и добавили. Но что это? Почему он так выглядит? Что это за кошмар?
Все просто, со сторонних ресурсов также подтягиваются шрифты и элементы оформления. И что? И снова ищем откуда и снова добавляем, добавляем, добавляем…
Нет картинок и мультимедийного содержимого? Снова ищем с каких CDN они распространяются, а их может быть и не один адрес. Т.е. сегодня все показывает нормально, а завтра в коде страницы другой CDN и снова начинайте сначала.
Ну вроде победили… Но радоваться рано. Пробуем войти на сайт и ничего не работает. Потому что вход реализован через сторонние сервисы вроде ЕСИА, соцсетей, Яндекса и т.д.
Потом на сайте могут не работать некоторые функции, все по той же причине подгрузки скриптов со стороны, скажем оплата.
И таких проблем может быть очень много и не все из них всплывут сразу. Поэтому заниматься подобной ерундой не имеет никакого практического смысла. В реальности достаточно заблокировать десяток сайтов – пожирателей времени, если вопрос именно в этом.
Единственный вариант, когда белый список оправдан, это когда криво работающий сайт будет наименьшим злом, по сравнению с открывшимся сторонним. Такой подход актуален, например, в образовании, где если проверка откроет не тот сайт, то проблем не избежать.
В остальном будьте благоразумны и ищите адекватные решения для поставленных задач.
Каждый раз, когда обсуждается вопрос ограничения доступа в интернет поднимается тема белых списков. Казалось бы, что там сложного? Запретил все и разрешил нужное, теперь можно спать спокойно.
Сделать это можно несколькими способами. При помощи списков адресов, когда адрес назначения сравнивается с заранее составленным списком и либо разрешается, либо блокируется. Пример такой настройки на оборудовании Mikrotik вы можете найти в статье:
🔹 Настройка черного и белого списков в роутерах Mikrotik
Второй вариант – это настройка собственного фильтрующего DNS-сервера. Принцип работы его схож с первым методом, но производится на уровне DNS-запросов, еще до того, как браузер попытается открыть страницу.
Для разрешенных доменов имя исправно разрешается в IP-адрес, для всех иных сервер отвечает, что такого домена не существует. Более подробно это описано в статье:
🔹 Создаем собственный фильтрующий DNS-сервер на базе Pi-hole
Но если попытаться реализовать указанными способами белый список, то вам придется столкнуться с многими сложностями.
Дело в том, что современный сайт – это технически сложный программный продукт и далеко не все его компоненты расположены на одном с ним домене.
Первая сложность настигнет вас буквально сразу, браузер не сможет проверить сертификат. Почему? Потому что ему нужен доступ с CRL (списку отозванных сертификатов), адрес которого указан в сертификате.
Его нужно выяснить и добавить в белый список. Причем таких адресов может быть несколько и для следующего сайта с сертификатом этого же УЦ адрес может быть иным.
Ок, с сертификатами разобрались, но почему вместо сайта белая страница? Или он очень долго загружается?
Потому что для нормального функционирования ему нужно подгрузить скрипты, находящиеся на сторонних адресах. Снова включаем отладку, выясняем эти адреса и добавляем их в белый список.
Для чего так делается? По нескольким причинам. Основная – скорость доставки, скрипты расположенные на CDN доставляются пользователю одинаково быстро в любой точке мира, не загружают канал сайта и не оказывают нагрузки на сервер.
Вторая – это поддержание актуальных версий скриптов используя общедоступные репозитории, где они будут автоматически обновляться в пределах текущей версии при обнаружении багов или уязвимостей.
Ладно, нашли эти адреса и добавили. Но что это? Почему он так выглядит? Что это за кошмар?
Все просто, со сторонних ресурсов также подтягиваются шрифты и элементы оформления. И что? И снова ищем откуда и снова добавляем, добавляем, добавляем…
Нет картинок и мультимедийного содержимого? Снова ищем с каких CDN они распространяются, а их может быть и не один адрес. Т.е. сегодня все показывает нормально, а завтра в коде страницы другой CDN и снова начинайте сначала.
Ну вроде победили… Но радоваться рано. Пробуем войти на сайт и ничего не работает. Потому что вход реализован через сторонние сервисы вроде ЕСИА, соцсетей, Яндекса и т.д.
Потом на сайте могут не работать некоторые функции, все по той же причине подгрузки скриптов со стороны, скажем оплата.
И таких проблем может быть очень много и не все из них всплывут сразу. Поэтому заниматься подобной ерундой не имеет никакого практического смысла. В реальности достаточно заблокировать десяток сайтов – пожирателей времени, если вопрос именно в этом.
Единственный вариант, когда белый список оправдан, это когда криво работающий сайт будет наименьшим злом, по сравнению с открывшимся сторонним. Такой подход актуален, например, в образовании, где если проверка откроет не тот сайт, то проблем не избежать.
В остальном будьте благоразумны и ищите адекватные решения для поставленных задач.
💯14👍11❤1🥱1
Форматируем раздел как ReFS в Windows 10/11
Файловая система ReFS была представлена в 2012 году и имеет ряд существенных преимуществ над своей предшественницей – NTFS. Также она имеет ряд особенностей и ограничений.
Например, на ReFS не может быть расположен загрузочный том, поэтому установить систему на эту ФС не удастся.
Подробнее обо всем этом можно почитать в первоисточнике: https://learn.microsoft.com/ru-ru/windows-server/storage/refs/refs-overview
Первоначально ReFS была доступна без ограничений как в клиентских, так и серверных выпусках ОС Windows, но это продолжалось недолго.
Начиная с выпуска 1709 в Windows 10 убрали поддержку ReFS для всех редакций кроме Professional for Workstation и Enterprise.
Но убрали ее по-хитрому: просто отключили возможность форматировать разделы в ReFS, сама же поддержка этой файловой системы была сохранена в полноценном виде.
Это, кстати, вполне объяснимо: ломать совместимость для пользователей уже успевших отформатировать диски в ReFS никто не рискнул.
Да и толку от этой затеи немного, поддержка файловых систем реализована на уровне ядра и выпилить ее полностью – задача непростая. А все остальное достаточно легко обходится различными твиками.
В общем Microsoft поступили в своем репертуаре, сначала дали попробовать, потом спрятали.
Но они бы не были собой, если бы с последними обновлениями Windows 11 не случилось второго пришествия ReFS под видом «дисков для разработки», о чем мы писали в дневной заметке.
Однако, если вам нужна ReFS не следует бежать за Windows 11 и срочно обновлять ее. Можно поступить проще.
Энтузиастом создана утилита mkrefs, которая позволяет быстро и просто отформатировать любой том в ReFS в любых выпусках Windows 10 и 11.
Скачать ее можно с репозитория разработчика на Github: https://github.com/0xbadfca11/mkrefs
Чтобы использовать утилиту вам потребуется создать том и присвоить ему букву, можно без форматирования, либо переформатировать уже существующий.
Чтобы получить справку просто запустите утилиту без ключей. В самом простом виде, с параметрами по умолчанию, можем отформатировать том под ReFS так:
Ключ
Также доступны ключи:
▫️ /V:label
▫️
▫️ /I:{enable | disable} – включение проверки целостности файловой системы, по умолчанию выключено
Например:
После чего в вашей системе появится диск с файловой системой ReFS который вы сможете полноценно использовать.
Также существует альтернативный способ с правкой реестра, но мы не рекомендуем его использовать, так как после такой правки у некоторых пользователей наблюдались проблемы с пробросом
Файловая система ReFS была представлена в 2012 году и имеет ряд существенных преимуществ над своей предшественницей – NTFS. Также она имеет ряд особенностей и ограничений.
Например, на ReFS не может быть расположен загрузочный том, поэтому установить систему на эту ФС не удастся.
Подробнее обо всем этом можно почитать в первоисточнике: https://learn.microsoft.com/ru-ru/windows-server/storage/refs/refs-overview
Первоначально ReFS была доступна без ограничений как в клиентских, так и серверных выпусках ОС Windows, но это продолжалось недолго.
Начиная с выпуска 1709 в Windows 10 убрали поддержку ReFS для всех редакций кроме Professional for Workstation и Enterprise.
Но убрали ее по-хитрому: просто отключили возможность форматировать разделы в ReFS, сама же поддержка этой файловой системы была сохранена в полноценном виде.
Это, кстати, вполне объяснимо: ломать совместимость для пользователей уже успевших отформатировать диски в ReFS никто не рискнул.
Да и толку от этой затеи немного, поддержка файловых систем реализована на уровне ядра и выпилить ее полностью – задача непростая. А все остальное достаточно легко обходится различными твиками.
В общем Microsoft поступили в своем репертуаре, сначала дали попробовать, потом спрятали.
Но они бы не были собой, если бы с последними обновлениями Windows 11 не случилось второго пришествия ReFS под видом «дисков для разработки», о чем мы писали в дневной заметке.
Однако, если вам нужна ReFS не следует бежать за Windows 11 и срочно обновлять ее. Можно поступить проще.
Энтузиастом создана утилита mkrefs, которая позволяет быстро и просто отформатировать любой том в ReFS в любых выпусках Windows 10 и 11.
Скачать ее можно с репозитория разработчика на Github: https://github.com/0xbadfca11/mkrefs
Чтобы использовать утилиту вам потребуется создать том и присвоить ему букву, можно без форматирования, либо переформатировать уже существующий.
Чтобы получить справку просто запустите утилиту без ключей. В самом простом виде, с параметрами по умолчанию, можем отформатировать том под ReFS так:
mkrefs E: /X
Ключ
/X используется для форсирования форматирования, полезно если вы переформатируете уже существующую файловую систему, на которой могут быть открытые файловые дескрипторы.Также доступны ключи:
▫️ /V:label
– метка тома, задаем произвольно, при наличии пробелом заключаем в кавычки▫️
/A:{4096 | 64K} – размер блока файловой системы, по умолчанию 4К▫️ /I:{enable | disable} – включение проверки целостности файловой системы, по умолчанию выключено
Например:
mkrefs E: /X /V:”My ReFS Vol” /A:64K /I:enabled
После чего в вашей системе появится диск с файловой системой ReFS который вы сможете полноценно использовать.
Также существует альтернативный способ с правкой реестра, но мы не рекомендуем его использовать, так как после такой правки у некоторых пользователей наблюдались проблемы с пробросом
👍20🔥3❤1
Длина имени файла и абсолютного пути
Вопрос, на первый взгляд простой, но с регулярной периодичностью возникают ситуации, когда неверное понимание этого вопроса приводит к разного рода недоразумениям. Особенно в мультиплатформенных средах.
☝️ Начнем с Windows. Классическая длина имени – 255 символов, максимальная длина пути – 260 символов.
Обратите внимание – символов, максимальная длина имени директории – 244 символа, так как система резервирует часть пути для файла в формате 8.3.
Однако начиная с Windows 10 1607 и Server 2016 эти ограничения можно отключить, в этом случае лимит имени файла или абсолютного пути будет определяться файловой системой, для NTFS это 32767 символов, для ReFS - 32000 символов.
👉 Теперь Linux. Имена файлов в Linux могут быть длиной до 255 байт. Полная длина пути не должна превышать 4096 байт. В отличие от Windows в ограничениях используются не символы, а байты. А кодировка UTF-8 для символов национальных алфавитов предусматривает до 4 байт на 1 символ.
Таким образом длина имени у нас может неожиданным образом оказаться ограниченной 63 символами, а максимальный путь стать 1024 символа.
Кириллица занимает 2 байта на символ, поэтому в Linux вы будете ограничены 127 символами в имени файла и 2048 символами в пути.
Смешивая различные символы, вы получите различные варианты лимитов между максимальными и минимальными.
Обычно это вызывает сложности при копировании или распаковке файлов из систем с кодировками CP-1251 или KOI-8.
Еще одна особенность связана с использованием криптографических файловых систем, таких как eCryptFS , в этом случае длина пути будет ограничена 143 байта или 71 символ на кириллице.
Вопрос, на первый взгляд простой, но с регулярной периодичностью возникают ситуации, когда неверное понимание этого вопроса приводит к разного рода недоразумениям. Особенно в мультиплатформенных средах.
☝️ Начнем с Windows. Классическая длина имени – 255 символов, максимальная длина пути – 260 символов.
Обратите внимание – символов, максимальная длина имени директории – 244 символа, так как система резервирует часть пути для файла в формате 8.3.
Однако начиная с Windows 10 1607 и Server 2016 эти ограничения можно отключить, в этом случае лимит имени файла или абсолютного пути будет определяться файловой системой, для NTFS это 32767 символов, для ReFS - 32000 символов.
👉 Теперь Linux. Имена файлов в Linux могут быть длиной до 255 байт. Полная длина пути не должна превышать 4096 байт. В отличие от Windows в ограничениях используются не символы, а байты. А кодировка UTF-8 для символов национальных алфавитов предусматривает до 4 байт на 1 символ.
Таким образом длина имени у нас может неожиданным образом оказаться ограниченной 63 символами, а максимальный путь стать 1024 символа.
Кириллица занимает 2 байта на символ, поэтому в Linux вы будете ограничены 127 символами в имени файла и 2048 символами в пути.
Смешивая различные символы, вы получите различные варианты лимитов между максимальными и минимальными.
Обычно это вызывает сложности при копировании или распаковке файлов из систем с кодировками CP-1251 или KOI-8.
Еще одна особенность связана с использованием криптографических файловых систем, таких как eCryptFS , в этом случае длина пути будет ограничена 143 байта или 71 символ на кириллице.
👍14❤2🤔2🔥1🤯1
Безопасность? Нет, не слышали…
Попросили третьего дня одни заказчики проверить действительно ли были удалены все доступы уволившегося сотрудника. Сотрудник был важный и ушел не очень хорошо, поэтому руководство попросило нас перепроверить за своими сотрудниками.
Доступы у нас были, но особо в чужие дела мы нос не совали, но вот пришлось. Хотя лучше бы мы этого не делали. Потому что ситуация показала все недра бардака в сфере безопасности. Впрочем, так оно практически везде, где нет отдельной службы информационной безопасности и админы сами себе хозяева.
Нет, плохого про них ничего сказать не хочу, но человек такое существо, что если его не поддерживать в тонусе, постоянно пиная палкой, то постепенно он перейдет к политике наименьшего сопротивления, ну а зачем делать сложно, если можно сделать просто.
Расписывать все не будем, коснемся основных косяков, от которых у нас задергался глаз:
🔷 Предсказуемая система паролей, построенная по принципу постоянная часть + уникальная, в виде ФИО. Т.е. если уволенный человек не дурак и ему надо зайти – он зайдет под любым сотрудником.
🔷 OpenVPN без списка отзыва сертификатов, сертификаты на 10 лет, эти же сертификаты используются для доступа еще к некоторому количеству сервисов (мы насчитали пять).
🔷 Пароли от сервисов расшарены через корпоративную файлопомойку в виде отдельного файла-блокнота OneNote, кроме паролей там также логины, IP-адреса и прочая информация уровня «явки-пароли.
Папка доступна только IT-отделу, но мы все прекрасно понимаем, что одно неловкое движение – и все это будет достоянием общественности.
🔷 Секреты от тестовой среды, залитые на Git вместе с композами и плейбуками внезапно подошли к проду.
🔷 Сертификаты руководителей и сотрудников с МЧД просто лежали в общедоступной папке, потому что нужны почти везде, задолбались с ними. И установлены прямо в реестр целевых ПК.
🤷♂️ В общем отчет мы написали, и он не понравился ни руководству, ни админам. Но тут уж извините, если мы отрапортуем, что все хорошо, а завтра их сломают – вопросы будут уже к нам.
Попросили третьего дня одни заказчики проверить действительно ли были удалены все доступы уволившегося сотрудника. Сотрудник был важный и ушел не очень хорошо, поэтому руководство попросило нас перепроверить за своими сотрудниками.
Доступы у нас были, но особо в чужие дела мы нос не совали, но вот пришлось. Хотя лучше бы мы этого не делали. Потому что ситуация показала все недра бардака в сфере безопасности. Впрочем, так оно практически везде, где нет отдельной службы информационной безопасности и админы сами себе хозяева.
Нет, плохого про них ничего сказать не хочу, но человек такое существо, что если его не поддерживать в тонусе, постоянно пиная палкой, то постепенно он перейдет к политике наименьшего сопротивления, ну а зачем делать сложно, если можно сделать просто.
Расписывать все не будем, коснемся основных косяков, от которых у нас задергался глаз:
🔷 Предсказуемая система паролей, построенная по принципу постоянная часть + уникальная, в виде ФИО. Т.е. если уволенный человек не дурак и ему надо зайти – он зайдет под любым сотрудником.
🔷 OpenVPN без списка отзыва сертификатов, сертификаты на 10 лет, эти же сертификаты используются для доступа еще к некоторому количеству сервисов (мы насчитали пять).
🔷 Пароли от сервисов расшарены через корпоративную файлопомойку в виде отдельного файла-блокнота OneNote, кроме паролей там также логины, IP-адреса и прочая информация уровня «явки-пароли.
Папка доступна только IT-отделу, но мы все прекрасно понимаем, что одно неловкое движение – и все это будет достоянием общественности.
🔷 Секреты от тестовой среды, залитые на Git вместе с композами и плейбуками внезапно подошли к проду.
🔷 Сертификаты руководителей и сотрудников с МЧД просто лежали в общедоступной папке, потому что нужны почти везде, задолбались с ними. И установлены прямо в реестр целевых ПК.
🤷♂️ В общем отчет мы написали, и он не понравился ни руководству, ни админам. Но тут уж извините, если мы отрапортуем, что все хорошо, а завтра их сломают – вопросы будут уже к нам.
👍20😱5👀2❤1👨💻1
Продление сертификата
В IT существуют и активно используются множество терминов, которые либо неверно отражают суть происходящих процессов, либо являются неудачным переводом зарубежных терминов.
Один из таких терминов – это широко используемое «продление» сертификата, которое вводит в ступор многих начинающих, которые изучив документацию к собственному CA не находят там такой функции.
И не найдут, потому что у сертификата нет такой функции – продлить. Почему нет? Да потому что не предусмотрена.
Что такое сертификат? Это еще один пример не лучшего использования термина, но из песни, как говорится, слов не выкинешь.
Говоря сертификат чаще всего, подразумевается ключевая пара: закрытый и открытый ключ. Сертификат – это открытый ключ плюс некоторая дополнительная информация о владельце, которые подписаны ключом CA, что позволяет убедиться в их подлинности.
Закрытый ключ является секретным, а сертификат – публичным. С его помощью наши контрагенты могут убедиться, что мы – это действительно те, за кого себя выдаем или проверить подлинность нашей электронной подписи, начать защищенный сеанс связи с нами и т.д. и т.п.
Поэтому важной частью сертификата является его владелец (юридическое или физическое лицо, доменное имя или сетевой узел), который указан в поле Common Name (CN).
В настоящий момент это поле считается устаревшим и для размещения данных о владельце сертификата используется поле Subject Alternative Name (SAN), которое может содержать сразу несколько значений. Это может быть как несколько доменных имен, так и доменные имена вместе с IP-адресами, что позволяет защищать объекты с разным набором доступных имен и разными вариантами обращений.
При этом поле Common Name продолжает поддерживаться для сохранения обратной совместимости и там принято указывать «основное» имя владельца.
Кроме владельца сертификат имеет срок действия. Причем это не срок действия самого сертификата, это срок действия ключевой пары.
Почему нельзя сделать сертификат бессрочным? Можно, но крайне нежелательно с точки зрения безопасности. Ключ может быть потерян, утрачен, скомпрометирован и т.д. и т.п. Причем владелец об этом может и не знать. Поэтому короткий срок действия ключа снижает такие риски.
А также повышает доверие к такому ключу, так как говорит о том, что CA довольно регулярно проверяет владельца этого ключа и доверяет ему.
Так как же продлить сертификат с закончившимся сроком действия? Никак. Он закончился и никакой волшебной силы, способной продлить срок его жизни, сохранив ему доверие, не существует.
Что нужно сделать? Выпустить новый сертификат (читай ключевую пару) для тех же самых значений CN и SAN. Таким образом сертификат будет новый, но владелец старый и все, кто доверял ему продолжат это делать.
Таким образом следует крепко запомнить – никакой операции «продления» сертификата не было, нет и никогда не будет. Можно только выпустить новый сертификат для прежнего владельца.
Так откуда же пошел этот странный термин? Наше мнение – из маркетинга. Когда клиенту, получившему коммерческий сертификат и обратившемуся повторно для его перевыпуска делали скидку.
Отсюда и придумали термин «продление», чтобы отличать от обычного «выпуска». А потом пошло-поехало. Вот такой вот маркетинг, бессмысленный и беспощадный.
В IT существуют и активно используются множество терминов, которые либо неверно отражают суть происходящих процессов, либо являются неудачным переводом зарубежных терминов.
Один из таких терминов – это широко используемое «продление» сертификата, которое вводит в ступор многих начинающих, которые изучив документацию к собственному CA не находят там такой функции.
И не найдут, потому что у сертификата нет такой функции – продлить. Почему нет? Да потому что не предусмотрена.
Что такое сертификат? Это еще один пример не лучшего использования термина, но из песни, как говорится, слов не выкинешь.
Говоря сертификат чаще всего, подразумевается ключевая пара: закрытый и открытый ключ. Сертификат – это открытый ключ плюс некоторая дополнительная информация о владельце, которые подписаны ключом CA, что позволяет убедиться в их подлинности.
Закрытый ключ является секретным, а сертификат – публичным. С его помощью наши контрагенты могут убедиться, что мы – это действительно те, за кого себя выдаем или проверить подлинность нашей электронной подписи, начать защищенный сеанс связи с нами и т.д. и т.п.
Поэтому важной частью сертификата является его владелец (юридическое или физическое лицо, доменное имя или сетевой узел), который указан в поле Common Name (CN).
В настоящий момент это поле считается устаревшим и для размещения данных о владельце сертификата используется поле Subject Alternative Name (SAN), которое может содержать сразу несколько значений. Это может быть как несколько доменных имен, так и доменные имена вместе с IP-адресами, что позволяет защищать объекты с разным набором доступных имен и разными вариантами обращений.
При этом поле Common Name продолжает поддерживаться для сохранения обратной совместимости и там принято указывать «основное» имя владельца.
Кроме владельца сертификат имеет срок действия. Причем это не срок действия самого сертификата, это срок действия ключевой пары.
Почему нельзя сделать сертификат бессрочным? Можно, но крайне нежелательно с точки зрения безопасности. Ключ может быть потерян, утрачен, скомпрометирован и т.д. и т.п. Причем владелец об этом может и не знать. Поэтому короткий срок действия ключа снижает такие риски.
А также повышает доверие к такому ключу, так как говорит о том, что CA довольно регулярно проверяет владельца этого ключа и доверяет ему.
Так как же продлить сертификат с закончившимся сроком действия? Никак. Он закончился и никакой волшебной силы, способной продлить срок его жизни, сохранив ему доверие, не существует.
Что нужно сделать? Выпустить новый сертификат (читай ключевую пару) для тех же самых значений CN и SAN. Таким образом сертификат будет новый, но владелец старый и все, кто доверял ему продолжат это делать.
Таким образом следует крепко запомнить – никакой операции «продления» сертификата не было, нет и никогда не будет. Можно только выпустить новый сертификат для прежнего владельца.
Так откуда же пошел этот странный термин? Наше мнение – из маркетинга. Когда клиенту, получившему коммерческий сертификат и обратившемуся повторно для его перевыпуска делали скидку.
Отсюда и придумали термин «продление», чтобы отличать от обычного «выпуска». А потом пошло-поехало. Вот такой вот маркетинг, бессмысленный и беспощадный.
👍13👌3😱1
Почему у нас все так плохо с безопасностью?
В продолжение вчерашней заметки хочется рассмотреть более широкий вопрос: почему там, где нет отдельного отдела информационной безопасности – с безопасностью плохо, хотя внешне все может выглядеть хорошо.
Коллеги могут утверждать обратное, но исходя из собственного опыта и опыта коллег, с которыми успел пообщаться, могу сказать, что в большинстве случаев системное администрирование и безопасность идут где-то параллельными курсами, вроде и есть, но не пересекаются.
Почему? Да потому что их пересечение порождает массу проблем и не всегда виноваты в этом администраторы. Хотя скажем честно, большинство администраторов имеют скудные и обрывочные знания в этой области.
Типичный набор «безопасности» от администратора:
🔹 Закрыть периметр и (возможно) наиболее критичные узлы брандмауэром.
🔹 Настроить политику паролей согласно формальных требований (часто по минимуму)
🔹 Нарезать доступ по группам, спискам, адресам и т.д.
🔹Время от времени ставить обновления (да и то не факт)
Вроде бы грамотно, но вроде бы. Понятие периметра сегодня сильно размыта, и угроза может прийти даже из доверенного сегмента. Пароли могут оказаться шаблонными, словарными или откровенно слабыми, хотя формально будут удовлетворять политике.
Но даже грамотно настроенная система обязательно будет деградировать. Почему? Потому что требования безопасности часто идут в разрез с требованиями к системному администратору.
Задача администратора – это поддержание рабочего состояние информационной инфраструктуры, которая должна работать без сбоев и сложностей. Безопасность – это как раз про сложности и затруднения.
Вот придумал администратор всем действительно сложные пароли. Уже завтра половина их забыла, половина не может правильно ввести с первого раза. Послезавтра они появляются на листочках у монитора.
А через три месяца их надо поменять, это если по уму. А после такой замены у кабинета руководителя состоится митинг недовольных пользователей и админу это поставят на вид. Мол нам работать надо, а не твои пароли разгадывать.
И чего не коснись – везде будет так. А у админа нет ни рычагов, ни оправданий – его брали чтобы работать было проще, а не наоборот. Другое дело – безопасник, его брали именно для того, чтобы бдел и жить нерадивым сотрудникам мешал.
Да и самим админам нафиг это надо, особенно когда все работает. Один пароль на все сервисы? А что такого, это наши, админские сервисы.
Один SSH-ключ на всех устройствах – так проще и удобнее. Общие пароли в тесте и проде? Так удобнее тестировать, все равно это наш тест и наш прод.
И так далее в том же духе. В итоге еще непонятно, где окажется более дырявое решето – с клиентской части или с серверной. Особенно с классической нелюбовью к обновлениям, мол чего заморачиваться, это сугубо внутренний сервис.
Про установку программ и утилит из неизвестных источников, бинарников с гита или скриптов оттуда-же я вообще промолчу.
В результате имеем что имеем. И, повторимся, вовсе не потому, что админы такие плохие, а потому, что это не их вид деятельности.
Это, совсем другая профессия, с другими подходами и другими методами, которым администраторов не учили и многие из которых идут в разрез с привычными им нормами.
В продолжение вчерашней заметки хочется рассмотреть более широкий вопрос: почему там, где нет отдельного отдела информационной безопасности – с безопасностью плохо, хотя внешне все может выглядеть хорошо.
Коллеги могут утверждать обратное, но исходя из собственного опыта и опыта коллег, с которыми успел пообщаться, могу сказать, что в большинстве случаев системное администрирование и безопасность идут где-то параллельными курсами, вроде и есть, но не пересекаются.
Почему? Да потому что их пересечение порождает массу проблем и не всегда виноваты в этом администраторы. Хотя скажем честно, большинство администраторов имеют скудные и обрывочные знания в этой области.
Типичный набор «безопасности» от администратора:
🔹 Закрыть периметр и (возможно) наиболее критичные узлы брандмауэром.
🔹 Настроить политику паролей согласно формальных требований (часто по минимуму)
🔹 Нарезать доступ по группам, спискам, адресам и т.д.
🔹Время от времени ставить обновления (да и то не факт)
Вроде бы грамотно, но вроде бы. Понятие периметра сегодня сильно размыта, и угроза может прийти даже из доверенного сегмента. Пароли могут оказаться шаблонными, словарными или откровенно слабыми, хотя формально будут удовлетворять политике.
Но даже грамотно настроенная система обязательно будет деградировать. Почему? Потому что требования безопасности часто идут в разрез с требованиями к системному администратору.
Задача администратора – это поддержание рабочего состояние информационной инфраструктуры, которая должна работать без сбоев и сложностей. Безопасность – это как раз про сложности и затруднения.
Вот придумал администратор всем действительно сложные пароли. Уже завтра половина их забыла, половина не может правильно ввести с первого раза. Послезавтра они появляются на листочках у монитора.
А через три месяца их надо поменять, это если по уму. А после такой замены у кабинета руководителя состоится митинг недовольных пользователей и админу это поставят на вид. Мол нам работать надо, а не твои пароли разгадывать.
И чего не коснись – везде будет так. А у админа нет ни рычагов, ни оправданий – его брали чтобы работать было проще, а не наоборот. Другое дело – безопасник, его брали именно для того, чтобы бдел и жить нерадивым сотрудникам мешал.
Да и самим админам нафиг это надо, особенно когда все работает. Один пароль на все сервисы? А что такого, это наши, админские сервисы.
Один SSH-ключ на всех устройствах – так проще и удобнее. Общие пароли в тесте и проде? Так удобнее тестировать, все равно это наш тест и наш прод.
И так далее в том же духе. В итоге еще непонятно, где окажется более дырявое решето – с клиентской части или с серверной. Особенно с классической нелюбовью к обновлениям, мол чего заморачиваться, это сугубо внутренний сервис.
Про установку программ и утилит из неизвестных источников, бинарников с гита или скриптов оттуда-же я вообще промолчу.
В результате имеем что имеем. И, повторимся, вовсе не потому, что админы такие плохие, а потому, что это не их вид деятельности.
Это, совсем другая профессия, с другими подходами и другими методами, которым администраторов не учили и многие из которых идут в разрез с привычными им нормами.
💯23👌3🤝3❤2
И снова о выборе мыши
Сегодня снова пришлось покупать новую мышь, и посему будет полезно в очередной раз вспомнить какие основные показатели влияют на эргономику работы с мышью.
Начнем с того, что мышь - это некий физический прибор, преобразующий движение руки в пространстве в движение курсора на экране. И хороший манипулятор должен позволять это делать с наибольшим удобством для человека.
Сегодня основной размер экранов в пикселях – это FHD, так, для 1920 x 1080 диагональ экрана составит 2202 px, а для 2K экрана – уже 2937 px.
Много это или мало? Все зависит от того, как далеко нам нужно передвинуть физическую мышь чтобы пройти это расстояние курсором на экране.
Для этого существует понятие разрешения мыши, которое обычно выражают в DPI, на самом деле это не совсем верно, но в рамках рассматриваемой нами темы вполне приемлемо.
Возьмем дешевую мышь с разрешением 800 dpi, это значит, что при движении мыши на 1 дюйм в физическом пространстве курсор пройдет на экране 800 px.
Нетрудно посчитать, что для того, чтобы переместить курсор из одного конца диагонали FHD экрана в другой нам нужно физически передвинуть мышь на 2,75 дюйма или почти 7 см.
Это много, очень много, фактически мы целый день будем гонять мышь с одного края коврика на другой и не факт, что нам будет хватать для этого свободного пространства, заодно будем нагружать запястья лишними действиями, что плохо для здоровья рук.
Но если мы увеличим разрешение мыши вдвое, то нам потребуется для этого всего 3,5 см физического расстояния, а если взять мышь с разрешением 2400 dpi, то получим весьма комфортные 2,33 см.
Хотя здесь начинает проявляться другой эффект – мышь становится слишком быстрой и не все могут комфортно работать с такой скоростью. Ведь малейшее движение – и мышь улетела на другую сторону экрана.
Также высокое разрешение требует более высокого качества сенсора мыши. Мышь с плохой точностью сенсора будет двигаться хаотично, рывками. Обычно это характерно для дешевых мышей, где высокое разрешение сенсора может быть достигнуто программными средствами и к этому мы еще вернемся.
В то же время качественная мышь с увеличением разрешения до комфортных человеку уменьшает количество физических движений, что приводит к меньшей усталости и увеличивает комфорт работы за счет более точного позиционирования.
Почему так происходит? Все просто, обычная геометрия. Допустим, человек прикинул, что ему нужно подвинуть мышь на 45 градусов, но человек не робот и он на самом деле подвинул ее на 43 градуса.
А дальше вспоминаем про круговой сектор и длину хорды, которая растет с увеличением радиуса сектора. Т.е. чем на большее расстояние мы физически перемещаем мышь, тем больше у нас на экране расхождение от точки позиционирования курсора.
И это вне зависимости от характеристик сенсора мыши. Чем больше расстояние физического перемещения мыши, тем больше погрешность позиционирования на экране.
Это приводит к тому, что человеческий глаз замечает это несоответствие и человек предпринимает действия для коррекции, т.е. это новые дополнительные движения рукой и дискомфорт от низкой точности мыши.
Но подождите, скажет другой читатель, я же могу увеличить скорость мыши программно, средствами операционной системы. Тогда нам тоже придется меньше ее двигать физически, а по экрану она будет проходить большие расстояния.
Вроде бы так. Но вот мышь – тоже не идеальное устройство и имеет свою точность. Грубо говоря даже строго подвинув мышь на 45 градусов, мы не получим идеальной прямой. А получим тот же круговой сектор, в котором может оказаться курсор мыши.
Чем точнее мышь, тем уже угол данного сектора, а площадь сектора – это набор точек пространства, где может оказаться курсор. Только вот площадь сектора растет не в прямой, а в геометрической пропорции от радиуса.
Так увеличив радиус всего на 10, мы увеличим площадь на 100. В нашем случае 10 – это скорость, а 100 – точность. Ну это совсем ни в какие ворота. И именно этим страдают дешевые мыши, где разрешение подняли программно.
Сегодня снова пришлось покупать новую мышь, и посему будет полезно в очередной раз вспомнить какие основные показатели влияют на эргономику работы с мышью.
Начнем с того, что мышь - это некий физический прибор, преобразующий движение руки в пространстве в движение курсора на экране. И хороший манипулятор должен позволять это делать с наибольшим удобством для человека.
Сегодня основной размер экранов в пикселях – это FHD, так, для 1920 x 1080 диагональ экрана составит 2202 px, а для 2K экрана – уже 2937 px.
Много это или мало? Все зависит от того, как далеко нам нужно передвинуть физическую мышь чтобы пройти это расстояние курсором на экране.
Для этого существует понятие разрешения мыши, которое обычно выражают в DPI, на самом деле это не совсем верно, но в рамках рассматриваемой нами темы вполне приемлемо.
Возьмем дешевую мышь с разрешением 800 dpi, это значит, что при движении мыши на 1 дюйм в физическом пространстве курсор пройдет на экране 800 px.
Нетрудно посчитать, что для того, чтобы переместить курсор из одного конца диагонали FHD экрана в другой нам нужно физически передвинуть мышь на 2,75 дюйма или почти 7 см.
Это много, очень много, фактически мы целый день будем гонять мышь с одного края коврика на другой и не факт, что нам будет хватать для этого свободного пространства, заодно будем нагружать запястья лишними действиями, что плохо для здоровья рук.
Но если мы увеличим разрешение мыши вдвое, то нам потребуется для этого всего 3,5 см физического расстояния, а если взять мышь с разрешением 2400 dpi, то получим весьма комфортные 2,33 см.
Хотя здесь начинает проявляться другой эффект – мышь становится слишком быстрой и не все могут комфортно работать с такой скоростью. Ведь малейшее движение – и мышь улетела на другую сторону экрана.
Также высокое разрешение требует более высокого качества сенсора мыши. Мышь с плохой точностью сенсора будет двигаться хаотично, рывками. Обычно это характерно для дешевых мышей, где высокое разрешение сенсора может быть достигнуто программными средствами и к этому мы еще вернемся.
В то же время качественная мышь с увеличением разрешения до комфортных человеку уменьшает количество физических движений, что приводит к меньшей усталости и увеличивает комфорт работы за счет более точного позиционирования.
Почему так происходит? Все просто, обычная геометрия. Допустим, человек прикинул, что ему нужно подвинуть мышь на 45 градусов, но человек не робот и он на самом деле подвинул ее на 43 градуса.
А дальше вспоминаем про круговой сектор и длину хорды, которая растет с увеличением радиуса сектора. Т.е. чем на большее расстояние мы физически перемещаем мышь, тем больше у нас на экране расхождение от точки позиционирования курсора.
И это вне зависимости от характеристик сенсора мыши. Чем больше расстояние физического перемещения мыши, тем больше погрешность позиционирования на экране.
Это приводит к тому, что человеческий глаз замечает это несоответствие и человек предпринимает действия для коррекции, т.е. это новые дополнительные движения рукой и дискомфорт от низкой точности мыши.
Но подождите, скажет другой читатель, я же могу увеличить скорость мыши программно, средствами операционной системы. Тогда нам тоже придется меньше ее двигать физически, а по экрану она будет проходить большие расстояния.
Вроде бы так. Но вот мышь – тоже не идеальное устройство и имеет свою точность. Грубо говоря даже строго подвинув мышь на 45 градусов, мы не получим идеальной прямой. А получим тот же круговой сектор, в котором может оказаться курсор мыши.
Чем точнее мышь, тем уже угол данного сектора, а площадь сектора – это набор точек пространства, где может оказаться курсор. Только вот площадь сектора растет не в прямой, а в геометрической пропорции от радиуса.
Так увеличив радиус всего на 10, мы увеличим площадь на 100. В нашем случае 10 – это скорость, а 100 – точность. Ну это совсем ни в какие ворота. И именно этим страдают дешевые мыши, где разрешение подняли программно.
👍10🥱5❤1🤡1
Почему IT всегда проигрывает?
Сегодня мы поднимем одну больную, но актуальную тему, которая не понравится многим нашим коллегам. А именно, почему при возникновении конфликтных ситуаций между IT и пользователями – руководство обычно становится на сторону пользователей.
На самом деле никакого секрета тут нет, достаточно вспомнить основную цель бизнеса – заработать денег. Именно заработать, а не потратить и не спустить на благотворительность. Поэтому бизнес-процессы, приносящие фирме прибыль будут всегда иметь наивысший приоритет.
Потому что если эти самые пользователи, которые могут знать компьютер через пень-колоду не заработают денег, то платить зарплату IT будет ничем, а то и вообще фирма закроется и все пойдут по миру.
И тут можно услышать классический контраргумент – мол ну-ну, посмотрим мы чего они там без IT наработают. В этом есть доля истины, но следует понимать, что IT нужен фирме для того, чтобы помогать пользователям зарабатывать деньги, а не чтобы мешать и создавать различные затруднения.
Тем более, что IT это исключительно расходная статья, даже если это IT-фирма, внутреннее IT в ней точно также будет сугубо расходным.
Чтобы понять роль и место IT в фирме проведем простую аналогию. Вот у нас есть стадо овец, пастух и овчарка. Прибыль у нас исключительно с овец (шерсть и мясо), а овчарка только ест, с нее ни шерсти, ни мяса.
Но хорошая овчарка выполняет две важные функции: защищает стадо от внешних угроз (волков) и занимается внутренним микроменеджментом – не позволяет стаду разбегаться, а отдельным особям отбиться или забрести в реку или овраг.
После чего пастуху остается только вовремя перегонять стадо на новое пастбище, где трава сочнее, не отвлекаясь на непосредственное управление стадом и его охрану.
Так и в бизнесе. Овцы – это пользователи, зарабатывающие деньги. Пастух – руководство, которое занимается стратегическим планированием. А овчарка – сопровождающие службы, включая IT.
И как хорошая овчарка, хорошее IT должно пользователей оберегать и направлять, не мешая выполнять основные обязанности.
А если собака окажется «дурной», будет весь день бегать, лаять, кусать овец за ноги? В результате овцы перестанут нормально пастись, и пастух перестанет такую овчарку кормить, а то и вообще выставит на мороз.
Тоже самое происходит и в случае сильно мешающего IT, если его требования начинают мешать непосредственно рабочему процессу, то после ряда жалоб руководство поставит вопрос: а зачем нам такое IT? Которое не помогает, а только мешает.
При этом у руководства есть вполне понятные цифры и факты. Скажем, вчера торговый Иванов не смог вовремя оформить заявку, потому что не смог подключиться к информационной системе из-за 2FA, в результате заказчик недоволен, прямой убыток такой-то.
И если дальше так пойдет, то мы начнем терять клиентов и обороты. А это снова вполне конкретные суммы в рублях.
После чего на разговор вызывается IT. Вопрос простой: зачем вы это сделали? Чтобы не сломали. А нас ломают? Вроде нет, но… Хорошо, какая вероятность что сломают? Ну или сломают или нет…
То же самое касается и выхода из строя оборудования, и прочих моделей IT-рисков. Там все как в анекдоте про блондинку и динозавра. Или сломается или нет, 50/50.
Естественно, бизнесу такие размытые вероятности совсем не нравятся, потому что он знает, что, если станет снабжение – запасов хватит на три дня. Если бухгалтерия не перечислит до среды оплату – товар не отгрузят. Если не сдаст вовремя отчет – получим такой-то штраф и блокировку счета.
Причем этот вполне конкретные события, которые наступят со 100% вероятностью. IT ничем таким похвастаться не может, там или произойдет или нет. Скорее всего нет, потому что давно ничего такого не происходило.
Поэтому в любой конфликтной ситуации между IT и другими подразделениями руководство всегда займет сторону других подразделений, потому что там модель угроз понятная и конкретная: если - то. А не может быть, а может не быть.
Сегодня мы поднимем одну больную, но актуальную тему, которая не понравится многим нашим коллегам. А именно, почему при возникновении конфликтных ситуаций между IT и пользователями – руководство обычно становится на сторону пользователей.
На самом деле никакого секрета тут нет, достаточно вспомнить основную цель бизнеса – заработать денег. Именно заработать, а не потратить и не спустить на благотворительность. Поэтому бизнес-процессы, приносящие фирме прибыль будут всегда иметь наивысший приоритет.
Потому что если эти самые пользователи, которые могут знать компьютер через пень-колоду не заработают денег, то платить зарплату IT будет ничем, а то и вообще фирма закроется и все пойдут по миру.
И тут можно услышать классический контраргумент – мол ну-ну, посмотрим мы чего они там без IT наработают. В этом есть доля истины, но следует понимать, что IT нужен фирме для того, чтобы помогать пользователям зарабатывать деньги, а не чтобы мешать и создавать различные затруднения.
Тем более, что IT это исключительно расходная статья, даже если это IT-фирма, внутреннее IT в ней точно также будет сугубо расходным.
Чтобы понять роль и место IT в фирме проведем простую аналогию. Вот у нас есть стадо овец, пастух и овчарка. Прибыль у нас исключительно с овец (шерсть и мясо), а овчарка только ест, с нее ни шерсти, ни мяса.
Но хорошая овчарка выполняет две важные функции: защищает стадо от внешних угроз (волков) и занимается внутренним микроменеджментом – не позволяет стаду разбегаться, а отдельным особям отбиться или забрести в реку или овраг.
После чего пастуху остается только вовремя перегонять стадо на новое пастбище, где трава сочнее, не отвлекаясь на непосредственное управление стадом и его охрану.
Так и в бизнесе. Овцы – это пользователи, зарабатывающие деньги. Пастух – руководство, которое занимается стратегическим планированием. А овчарка – сопровождающие службы, включая IT.
И как хорошая овчарка, хорошее IT должно пользователей оберегать и направлять, не мешая выполнять основные обязанности.
А если собака окажется «дурной», будет весь день бегать, лаять, кусать овец за ноги? В результате овцы перестанут нормально пастись, и пастух перестанет такую овчарку кормить, а то и вообще выставит на мороз.
Тоже самое происходит и в случае сильно мешающего IT, если его требования начинают мешать непосредственно рабочему процессу, то после ряда жалоб руководство поставит вопрос: а зачем нам такое IT? Которое не помогает, а только мешает.
При этом у руководства есть вполне понятные цифры и факты. Скажем, вчера торговый Иванов не смог вовремя оформить заявку, потому что не смог подключиться к информационной системе из-за 2FA, в результате заказчик недоволен, прямой убыток такой-то.
И если дальше так пойдет, то мы начнем терять клиентов и обороты. А это снова вполне конкретные суммы в рублях.
После чего на разговор вызывается IT. Вопрос простой: зачем вы это сделали? Чтобы не сломали. А нас ломают? Вроде нет, но… Хорошо, какая вероятность что сломают? Ну или сломают или нет…
То же самое касается и выхода из строя оборудования, и прочих моделей IT-рисков. Там все как в анекдоте про блондинку и динозавра. Или сломается или нет, 50/50.
Естественно, бизнесу такие размытые вероятности совсем не нравятся, потому что он знает, что, если станет снабжение – запасов хватит на три дня. Если бухгалтерия не перечислит до среды оплату – товар не отгрузят. Если не сдаст вовремя отчет – получим такой-то штраф и блокировку счета.
Причем этот вполне конкретные события, которые наступят со 100% вероятностью. IT ничем таким похвастаться не может, там или произойдет или нет. Скорее всего нет, потому что давно ничего такого не происходило.
Поэтому в любой конфликтной ситуации между IT и другими подразделениями руководство всегда займет сторону других подразделений, потому что там модель угроз понятная и конкретная: если - то. А не может быть, а может не быть.
👍12💯5❤3🥱3
Почему 99% AI-агентов не доживают до продакшена?
Вы тратите недели на разработку «умного» агента, а в итоге — счёт за сожжённые токены и грустный архив в GDrive. Знакомо?
В новой статье экспертразбирает 5 главных причин:
🔹Недетерминированность
🔹Безграничная автономность
🔹Передача контекста — самая больная тема 2026 года.
🔹Тестирование — мокировать нейронку бесполезно, а семантические матчеры никто не настраивает.
🔹Мониторинг — как понять, что агент «ведёт себя разумно»? (Подсказка: KPI для людей тут работают лучше нейросетей).
В статье —живые примеры, фрагменты кода (Ruby, семантическое сравнение), чёткий роадмап внедрения👇
ЗАБРАТЬ СТАТЬЮ В БОТЕ
Вы тратите недели на разработку «умного» агента, а в итоге — счёт за сожжённые токены и грустный архив в GDrive. Знакомо?
В новой статье экспертразбирает 5 главных причин:
🔹Недетерминированность
🔹Безграничная автономность
🔹Передача контекста — самая больная тема 2026 года.
🔹Тестирование — мокировать нейронку бесполезно, а семантические матчеры никто не настраивает.
🔹Мониторинг — как понять, что агент «ведёт себя разумно»? (Подсказка: KPI для людей тут работают лучше нейросетей).
В статье —живые примеры, фрагменты кода (Ruby, семантическое сравнение), чёткий роадмап внедрения👇
ЗАБРАТЬ СТАТЬЮ В БОТЕ
Роутеры бывают разные
Читатели спрашивают: кто что использует сейчас в качестве роутера, чтобы удовлетворял всем современным требованиям к трубопроводам, КВН и всему такому прочему?
Вопрос интересный, поэтому решили сделать отдельную заметку. Скажем сразу – это не про домашний роутер простого человека. Мы будем исходить из того, что рассматриваем ситуацию, когда владелец всего этого добра знает, понимает и умеет, хотя бы на базовом уровне.
Сразу скажем – одного роутера сегодня вам будет мало. Потому что ситуация меняется с каждым днем и то, что еще вчера работало, сегодня работать перестает. Трубы засоряются, команды КВН внезапно испытывают глубокий творческий кризис и т.д. и т.п.
Это все требует определенной гибкости и вариативности, которую роутер не всегда может предоставить или предоставить не в полном объеме, или вообще иметь собственное представление о прекрасном, которое не совсем сочетается с вашим.
Следующий момент – роутер достаточно ограничен по ресурсам и не всегда может полноценно тянуть заданную вами нагрузку, даже если он поддерживает нужные вам технологии и протоколы.
Поэтому мы приходим к тому, что кроме роутера вам понадобится отдельный хост для работы вспомогательных сетевых служб, который позволяет быстро поднять на нем все, что вам потребуется без оглядки на поддержку, совместимость, ресурсы и т.д. и т.п.
Это может быть как «малинка» / «бананка» / «репка» или что-то более серьезное на x86. Из нового – это компактные неттопы на N100, которые можно купить от 18 000 - 25 000 руб., из б/у можно посмотреть на Авито неттопы на J1900 / N 3xxx, которые можно купить в хорошем состоянии где-то за 8000-10 000 руб.
А если у меня есть NAS / Медиасервер / Домашняя лаба (нужное подчеркнуть)? Нет и еще раз нет. Сетевые службы являются критически важными и поэтому должны быть доступны 24/7 вне зависимости от других сервисов.
Поэтому отдельная железка – самое то. Сегодня на нее, как минимум, логично возложить функции VPN / Прокси и локального кеширующего DNS.
А что же роутер? А роутеру оставим его основную функцию – маршрутизацию.
Что касается самого роутера, то мы видим тут три основных варианта:
🔹 Mikrotik – умеет все, что нужно домашнему роутеру и даже намного больше. Но требует определенных знаний и умений. В наше время еще и дороговат, также потребует стороннего решения для Wi-Fi, если вы не садомазохист.
🔹 Keenetic – достаточно мощная и продвинутая платформа с низким порогом входа и дружелюбным интерфейсом. Может многое и не требует специфичных знаний для настройки. Минусы – достаточно дорого. Плюсы – хороший Wi-Fi из коробки.
🔹 OpenWRT – привет красноглазие. Порог входа не ниже, чем на Mikrotik, а то еще и побольше. Потому как надо еще уметь прошивать, заливать, разблокировать и прочую аппаратно-программную магию. Но возможности там практически как у нормального Linux и роутер можно взять относительно недорогой. По Wi-Fi – как повезет, но скорее да, чем нет.
А так вообще вариантов достаточно много, если вы вынесете все основные сетевые сервисы на дополнительный ПК, то можно вообще взять обычный роутер в стоке и пробросить нужные порты куда надо.
Еще есть варианты с перешивкой под Keenetic некоторых недорогих моделей роутеров, но там прошивкой занимается один энтузиаст и вы будете полностью зависеть от него, как в вопросах доверия, так и в ситуации «я устал, я ухожу».
Но в целом общая концепция следующая – роутер, как роутер, т.е. занимается маршрутизацией, предоставляет функции межсетевого экрана и все такое прочее.
Отдельный хост – как сосредоточие сетевых служб: VPN, Proxy, DNS и все что может понадобиться еще. Там стоит классический Linux и возможности ограничены только вашей фантазией и наличием пакетов.
Читатели спрашивают: кто что использует сейчас в качестве роутера, чтобы удовлетворял всем современным требованиям к трубопроводам, КВН и всему такому прочему?
Вопрос интересный, поэтому решили сделать отдельную заметку. Скажем сразу – это не про домашний роутер простого человека. Мы будем исходить из того, что рассматриваем ситуацию, когда владелец всего этого добра знает, понимает и умеет, хотя бы на базовом уровне.
Сразу скажем – одного роутера сегодня вам будет мало. Потому что ситуация меняется с каждым днем и то, что еще вчера работало, сегодня работать перестает. Трубы засоряются, команды КВН внезапно испытывают глубокий творческий кризис и т.д. и т.п.
Это все требует определенной гибкости и вариативности, которую роутер не всегда может предоставить или предоставить не в полном объеме, или вообще иметь собственное представление о прекрасном, которое не совсем сочетается с вашим.
Следующий момент – роутер достаточно ограничен по ресурсам и не всегда может полноценно тянуть заданную вами нагрузку, даже если он поддерживает нужные вам технологии и протоколы.
Поэтому мы приходим к тому, что кроме роутера вам понадобится отдельный хост для работы вспомогательных сетевых служб, который позволяет быстро поднять на нем все, что вам потребуется без оглядки на поддержку, совместимость, ресурсы и т.д. и т.п.
Это может быть как «малинка» / «бананка» / «репка» или что-то более серьезное на x86. Из нового – это компактные неттопы на N100, которые можно купить от 18 000 - 25 000 руб., из б/у можно посмотреть на Авито неттопы на J1900 / N 3xxx, которые можно купить в хорошем состоянии где-то за 8000-10 000 руб.
А если у меня есть NAS / Медиасервер / Домашняя лаба (нужное подчеркнуть)? Нет и еще раз нет. Сетевые службы являются критически важными и поэтому должны быть доступны 24/7 вне зависимости от других сервисов.
Поэтому отдельная железка – самое то. Сегодня на нее, как минимум, логично возложить функции VPN / Прокси и локального кеширующего DNS.
А что же роутер? А роутеру оставим его основную функцию – маршрутизацию.
Что касается самого роутера, то мы видим тут три основных варианта:
🔹 Mikrotik – умеет все, что нужно домашнему роутеру и даже намного больше. Но требует определенных знаний и умений. В наше время еще и дороговат, также потребует стороннего решения для Wi-Fi, если вы не садомазохист.
🔹 Keenetic – достаточно мощная и продвинутая платформа с низким порогом входа и дружелюбным интерфейсом. Может многое и не требует специфичных знаний для настройки. Минусы – достаточно дорого. Плюсы – хороший Wi-Fi из коробки.
🔹 OpenWRT – привет красноглазие. Порог входа не ниже, чем на Mikrotik, а то еще и побольше. Потому как надо еще уметь прошивать, заливать, разблокировать и прочую аппаратно-программную магию. Но возможности там практически как у нормального Linux и роутер можно взять относительно недорогой. По Wi-Fi – как повезет, но скорее да, чем нет.
А так вообще вариантов достаточно много, если вы вынесете все основные сетевые сервисы на дополнительный ПК, то можно вообще взять обычный роутер в стоке и пробросить нужные порты куда надо.
Еще есть варианты с перешивкой под Keenetic некоторых недорогих моделей роутеров, но там прошивкой занимается один энтузиаст и вы будете полностью зависеть от него, как в вопросах доверия, так и в ситуации «я устал, я ухожу».
Но в целом общая концепция следующая – роутер, как роутер, т.е. занимается маршрутизацией, предоставляет функции межсетевого экрана и все такое прочее.
Отдельный хост – как сосредоточие сетевых служб: VPN, Proxy, DNS и все что может понадобиться еще. Там стоит классический Linux и возможности ограничены только вашей фантазией и наличием пакетов.
👍11👎1
Привет! 👋
Меня зовут Рома, я fullstack-разработчик с 6 летним опытом. Недавно я завел канал, где разбираю ошибки при работе с OpenClaw и AI-агентами, показываю разные фишки и делюсь кейсами своих проектов, которые можно применить у себя.
Если вы только начали или уже работаете с AI-агентами - залетайте ко мне на канал, будем развиваться в этом направлении вместе. Ну а я постараюсь давать только реально полезную инфу, которую использую сам в работе.
📌Подписывайтесь,
Буду рад каждому🤝
#реклама
О рекламодателе
Меня зовут Рома, я fullstack-разработчик с 6 летним опытом. Недавно я завел канал, где разбираю ошибки при работе с OpenClaw и AI-агентами, показываю разные фишки и делюсь кейсами своих проектов, которые можно применить у себя.
Если вы только начали или уже работаете с AI-агентами - залетайте ко мне на канал, будем развиваться в этом направлении вместе. Ну а я постараюсь давать только реально полезную инфу, которую использую сам в работе.
📌Подписывайтесь,
Буду рад каждому🤝
#реклама
О рекламодателе
🤡4🤮3🤬1
Узкий профиль или болото?
В комментариях время от времени всплывает вопрос эксплуатации откровенно старых систем. Мол все что вы пишете – хорошо, но попробуйте это применить на … (можете вписать любой устаревший софт).
На аргументы, что данный софт уже много лет как снят с поддержки применяется контраргумент, что мол много таких систем, где все это живо до сих пор и жить будет еще долго.
Несомненно, что так оно и есть, особенно среди специфических промышленных систем. Но есть один тонкий момент – квалификация, точнее ее потеря. А чтобы было понятнее что под этим имеется ввиду я специально попросил написать эту заметку коллегу, который побывал в подобной ситуации.
Далее от его лица, моя только литературная обработка.
Довольно давно, еще в начале десятых я попал на одно торгово-производственное предприятие. Им нужен был программист для 1С с навыками этой самой 1С администрирования. Компания только-только перешла на «восьмерку», и старый программист не тянул.
Но зато он отлично тянул еще одно внутреннее приложение, которое отвечало за всю внутреннюю кухню, включая производство и даже расчет зарплаты. Понемногу втянулся в это дело и я. Приложение было полностью самописное, на базе FoxPro.
Шли годы, мой начальник ушел на пенсию, и я занял его место, по деньгам было неплохо, я стал обрастать жирком и в какое-то время перестал интересоваться делами в отрасли. Ну не до того. На работе своих дел хватает, а дома семья, дети, стройка.
Стек технологий у меня оставался стабильным, точнее стабильно древним: FoxPro, Visual Basic 6, Windows, COM и 1С на обычных формах. Новая 1С, которая 8.3 и на управляемых формах как-то не зашла (там сильно переучиваться надо было) и стояла только в бухгалтерии, благо дорабатывать ее было не нужно.
Жизнь шла по налаженной стезе, и я даже немного гордился тем, что я достаточно редкий специалист, так как найти кого-то на этот стек было практически невозможно.
Первый звоночек прозвучал в короновирус, когда мы серьезно просели по выручке и несколько месяцев получали голый оклад. Стало, мягко говоря, тяжело, тем более что накоплений особо не было (все ушло на стройку), а кредиты сами себя не заплатят.
Когда жизнь снова стала входить в привычное русло меня пригласили на один проект хорошие знакомые. Они как раз мигрировали подобную внутреннюю систему с FoxPro на новую 1С и им нужен был человек разбирающийся в FoxPro.
И вот тут я понял, что жизнь прошла мимо меня и я все пропустил. Ребята говорили о каких-то абсолютно неведомых мне вещах: Linux, виртуализация, контейнеры, кластеры, веб-сервисы. При том, что «серверная» там составляла всего один небольшой шкафчик.
Также посмотрел я и на «новую» 1С, которая оказалось может и умеет гораздо большее, чем я мог себе представить.
А дальше я понял, что как специалист я представляю из себя практически полный ноль и никому кроме своего «дяди» я не нужен.
Но если придется менять работу, то максимум я могу претендовать на позицию «джуна», но «джун» возрастом под 40 лет – это не то, что способно заинтересовать работодателя.
В общем весь этот проект я активно вникал в используемые в нем технологии, много спрашивал про то, как, что и на чем. И все больше понимал, насколько я отстал и что с этим нужно срочно что-то делать.
Но что делать как-то в голову не приходило. Да, надо было учить, но когда?
Второй звоночек прозвенел, когда я уехал на месяц по семейным обстоятельствам и работать мог урывками и то удаленно. После чего и мне и дяде стало понятно, что никто кроме меня всю нашу кухню не тянет.
По приезду состоялся разговор, мол, а если тебе завтра кирпич на голову упадет? Я сказал, что тоже об этом думал и «покаялся», рассказал дяде про халтурку и то, как там было все устроено.
После чего дядя сказал, мол, а чего ты раньше молчал? Давай думай, предлагай, нужно двигаться вперед. Надо учиться – отправим, но мы не должны отставать от технологий.
Сейчас я второй год активно переделываю всю внутреннюю кухню, от старого приложения отказаться еще не получилось, но многое уже перевели на современные технологии.
В комментариях время от времени всплывает вопрос эксплуатации откровенно старых систем. Мол все что вы пишете – хорошо, но попробуйте это применить на … (можете вписать любой устаревший софт).
На аргументы, что данный софт уже много лет как снят с поддержки применяется контраргумент, что мол много таких систем, где все это живо до сих пор и жить будет еще долго.
Несомненно, что так оно и есть, особенно среди специфических промышленных систем. Но есть один тонкий момент – квалификация, точнее ее потеря. А чтобы было понятнее что под этим имеется ввиду я специально попросил написать эту заметку коллегу, который побывал в подобной ситуации.
Далее от его лица, моя только литературная обработка.
Довольно давно, еще в начале десятых я попал на одно торгово-производственное предприятие. Им нужен был программист для 1С с навыками этой самой 1С администрирования. Компания только-только перешла на «восьмерку», и старый программист не тянул.
Но зато он отлично тянул еще одно внутреннее приложение, которое отвечало за всю внутреннюю кухню, включая производство и даже расчет зарплаты. Понемногу втянулся в это дело и я. Приложение было полностью самописное, на базе FoxPro.
Шли годы, мой начальник ушел на пенсию, и я занял его место, по деньгам было неплохо, я стал обрастать жирком и в какое-то время перестал интересоваться делами в отрасли. Ну не до того. На работе своих дел хватает, а дома семья, дети, стройка.
Стек технологий у меня оставался стабильным, точнее стабильно древним: FoxPro, Visual Basic 6, Windows, COM и 1С на обычных формах. Новая 1С, которая 8.3 и на управляемых формах как-то не зашла (там сильно переучиваться надо было) и стояла только в бухгалтерии, благо дорабатывать ее было не нужно.
Жизнь шла по налаженной стезе, и я даже немного гордился тем, что я достаточно редкий специалист, так как найти кого-то на этот стек было практически невозможно.
Первый звоночек прозвучал в короновирус, когда мы серьезно просели по выручке и несколько месяцев получали голый оклад. Стало, мягко говоря, тяжело, тем более что накоплений особо не было (все ушло на стройку), а кредиты сами себя не заплатят.
Когда жизнь снова стала входить в привычное русло меня пригласили на один проект хорошие знакомые. Они как раз мигрировали подобную внутреннюю систему с FoxPro на новую 1С и им нужен был человек разбирающийся в FoxPro.
И вот тут я понял, что жизнь прошла мимо меня и я все пропустил. Ребята говорили о каких-то абсолютно неведомых мне вещах: Linux, виртуализация, контейнеры, кластеры, веб-сервисы. При том, что «серверная» там составляла всего один небольшой шкафчик.
Также посмотрел я и на «новую» 1С, которая оказалось может и умеет гораздо большее, чем я мог себе представить.
А дальше я понял, что как специалист я представляю из себя практически полный ноль и никому кроме своего «дяди» я не нужен.
Но если придется менять работу, то максимум я могу претендовать на позицию «джуна», но «джун» возрастом под 40 лет – это не то, что способно заинтересовать работодателя.
В общем весь этот проект я активно вникал в используемые в нем технологии, много спрашивал про то, как, что и на чем. И все больше понимал, насколько я отстал и что с этим нужно срочно что-то делать.
Но что делать как-то в голову не приходило. Да, надо было учить, но когда?
Второй звоночек прозвенел, когда я уехал на месяц по семейным обстоятельствам и работать мог урывками и то удаленно. После чего и мне и дяде стало понятно, что никто кроме меня всю нашу кухню не тянет.
По приезду состоялся разговор, мол, а если тебе завтра кирпич на голову упадет? Я сказал, что тоже об этом думал и «покаялся», рассказал дяде про халтурку и то, как там было все устроено.
После чего дядя сказал, мол, а чего ты раньше молчал? Давай думай, предлагай, нужно двигаться вперед. Надо учиться – отправим, но мы не должны отставать от технологий.
Сейчас я второй год активно переделываю всю внутреннюю кухню, от старого приложения отказаться еще не получилось, но многое уже перевели на современные технологии.
👍6🫡4❤1👨💻1