Опасное охлаждение 😡
Привезли сегодня системный блок, а там вот такое. В целом, человека знающего, такое не удивляет, ибо это вполне предсказуемо и ожидаемо.
Но человека, имеющего небольшой опыт работы с железом, может неприятно удивить, свалившись кому-нибудь «на голову» и чего-нибудь замкнув в самый неподходящий момент.
При этом такая ситуация однозначно не будет считаться гарантийной. Но, вся соль ситуации в том, что такое «чудо инженерной мысли» можно купить не только у китайцев на Али, но и спокойно приобрести в нашей рознице: https://www.citilink.ru/product/radiator-digma-dlya-ssd-m-2-dgrdrm2a-metall-1860310/
И да, гарантия на этот кусок алюминия 12 месяцев, но, если он упадет и замкнет – это не будет гарантийным случаем.
Поэтому никаких резинок, запомните это раз и навсегда. Потому что с ними непременно произойдет то, что вы видите на фото.
На крайний случай, если все-таки угораздило купить, то хотя бы замените резинки на стяжки.
А на последнем фото причина недолгой жизни резинок - эти прокладки сильно текут. А масло очень и очень быстро резину разрушает.
Привезли сегодня системный блок, а там вот такое. В целом, человека знающего, такое не удивляет, ибо это вполне предсказуемо и ожидаемо.
Но человека, имеющего небольшой опыт работы с железом, может неприятно удивить, свалившись кому-нибудь «на голову» и чего-нибудь замкнув в самый неподходящий момент.
При этом такая ситуация однозначно не будет считаться гарантийной. Но, вся соль ситуации в том, что такое «чудо инженерной мысли» можно купить не только у китайцев на Али, но и спокойно приобрести в нашей рознице: https://www.citilink.ru/product/radiator-digma-dlya-ssd-m-2-dgrdrm2a-metall-1860310/
И да, гарантия на этот кусок алюминия 12 месяцев, но, если он упадет и замкнет – это не будет гарантийным случаем.
Поэтому никаких резинок, запомните это раз и навсегда. Потому что с ними непременно произойдет то, что вы видите на фото.
На крайний случай, если все-таки угораздило купить, то хотя бы замените резинки на стяжки.
А на последнем фото причина недолгой жизни резинок - эти прокладки сильно текут. А масло очень и очень быстро резину разрушает.
👌9👀6👍3
Полное удаление или переустановка Яндекс.Диска
Задачка вроде бы простая, но, как и везде, обнаружились свои тонкости, возможно, не только мне будет полезно.
У одного из заказчиков на неделе сломался Яндекс.Диск, причем в нескольких местах. Симптомы: Яндекс.Диск не выходит из состояния синхронизации, отмечая таким образом все файлы и папки и постепенно занимает 100% процессорного времени.
При этом другие клиенты на этом же аккаунте работают нормально, смена аккаунта на больном ПК тоже не помогает.
В таком случае логично выполнить переустановку приложения, но увы, эти попытки не увенчались успехом. А так как на Яндекс.Диск были завязаны рабочие процессы, то пришлось разбираться.
Как выяснилось, Яндекс относится к процессу удаления собственного ПО формально, фактически только исключив его из автозагрузки и убрав ярлыки, да и то делает через раз.
А навело нас на эту мысль то, что на одном из ПК после «удаления» и перезагрузки Яндекс.Диск запустился и потребовал учетные данные, а после их ввода успешно заработал, точнее снова повис на синхронизации.
Как выяснилось, при удалении Яндекс.Диска полностью сохраняется содержимое папок:
В первой живут настройки и логи, во второй сам Яндекс.Диск, который прекрасно запускается оттуда даже после «удаления».
Поэтому для полного удаления или переустановки эти директории следует удалить. Также еще советуем удалить скрытую директорию
В папке с синхронизируемыми файлами. После того как вы все удалили можете перезагрузить ПК и заново установить Яндекс.Диск.
Данный рецепт проверили на нескольких ПК и везде смогли добиться положительного результата. И более странно то, что поддержка, в которую также обращались, его не посоветовала, а прислала стандартные рекомендации переустановить, перезагрузить, поставить обновления или проверить на вирусы.
Задачка вроде бы простая, но, как и везде, обнаружились свои тонкости, возможно, не только мне будет полезно.
У одного из заказчиков на неделе сломался Яндекс.Диск, причем в нескольких местах. Симптомы: Яндекс.Диск не выходит из состояния синхронизации, отмечая таким образом все файлы и папки и постепенно занимает 100% процессорного времени.
При этом другие клиенты на этом же аккаунте работают нормально, смена аккаунта на больном ПК тоже не помогает.
В таком случае логично выполнить переустановку приложения, но увы, эти попытки не увенчались успехом. А так как на Яндекс.Диск были завязаны рабочие процессы, то пришлось разбираться.
Как выяснилось, Яндекс относится к процессу удаления собственного ПО формально, фактически только исключив его из автозагрузки и убрав ярлыки, да и то делает через раз.
А навело нас на эту мысль то, что на одном из ПК после «удаления» и перезагрузки Яндекс.Диск запустился и потребовал учетные данные, а после их ввода успешно заработал, точнее снова повис на синхронизации.
Как выяснилось, при удалении Яндекс.Диска полностью сохраняется содержимое папок:
AppData\Local\Yandex
AppData\Roaming\Yandex
В первой живут настройки и логи, во второй сам Яндекс.Диск, который прекрасно запускается оттуда даже после «удаления».
Поэтому для полного удаления или переустановки эти директории следует удалить. Также еще советуем удалить скрытую директорию
.sync
В папке с синхронизируемыми файлами. После того как вы все удалили можете перезагрузить ПК и заново установить Яндекс.Диск.
Данный рецепт проверили на нескольких ПК и везде смогли добиться положительного результата. И более странно то, что поддержка, в которую также обращались, его не посоветовала, а прислала стандартные рекомендации переустановить, перезагрузить, поставить обновления или проверить на вирусы.
👍28👀10🤔1
А давайте кого-нибудь заблокируем!
Очень часто к нам обращаются с вопросом: помогите составить правило, которое бы блокировало вот этих нехороших товарищей и приводят записи лога.
После чего сильно удивляются, когда узнают, что средствами только самого брандмауэра это сделать нельзя.
Почему? Давайте посмотрим, где у нас находится брандмауэр, а где логи. Условно цепочку мы можем построить так:
Классический брандмауэр работает на сетевом и транспортном уровне (L3 и L4) и все что он видит – это пакеты, которые бегают из сети к приложению и обратно.
Лог – это продукт работы приложения, куда оно пишет то, что считает нужным. Причем единого формата логов нет, где четко можно было бы понять, что если в этом поле стоит единичка, то это ошибка, лог – это строковая информация, которую нужно разобрать, проанализировать, определить ключевые части строки.
Любой лог рассчитан прежде всего на чтение его человеком, а не машиной, поэтому работа с логом всегда требует индивидуального подхода.
Следующий момент, лог пишется приложением в некоторое хранилище, которое живет там же, где и приложение и никакого отношения к брандмауэру не имеет.
👆 Сообщения лога через брандмауэр не проходят!
Возможно – это очевидные вещи, но мы не раз и не два слышали предложения искать сообщения лога с помощью критерия Content в брандмауэре.
Но постойте, ведь приложение сообщает клиенту об ошибке? Сообщает, но очень редко делает это открытым текстом, на улице 2026 год и подавляющее большинство коммуникаций зашифровано. Прошли те времена, когда мы могли посмотреть содержимое пакета и сказать «ага».
Все, что мы сейчас можем – это делать какие-либо выводы по косвенным критериям. Но ни один из них не дает 100% гарантии нежелательной активности. Большинство протоколов обмениваются стандартными сообщениями фиксированной длинны и не видя содержимого сообщений нельзя сказать, что именно происходит.
Поэтому в основе любых алгоритмов лежат определенные допущения. Например, при обнаружении брутфорса протокола RDP мы исходили из того, что четко знаем сколько пакетов в состоянии NEW требуется для успешного установления соединения.
Затем выдвинули предположение, что если их количество с одного адреса источника в течении некоторого промежутка времени превышает некоторый лимит – то перед нами попытка подбора пароля.
Никаких критериев, позволяющих однозначно сказать «это подбор» нет. Мы просто определяем некоторый паттерн поведения, который можем определить при помощи критериев брандмауэра и затем делать выводы на основе его повторяемости.
Т.е. в установке нового соединения само по себе криминал нет, но если некто делает это слишком часто, то скорее всего это злоумышленник.
Поэтому, прежде чем браться кого-то или что-то блокировать нужно посмотреть на этот процесс со стороны брандмауэра. Об ошибках в лог пишет приложение, а для сетевого экрана «правильное» и «неправильное» соединения могут не отличаться ничем.
Ну и, наконец, подумать, а зачем оно надо? Практический смысл отлавливать злоумышленников есть только там, где есть потенциально уязвимый сервис. Если же кто-то старательно долбится в стену там, где двери нет и никогда не было – то какая нам печаль до этого дела?
К примеру, на узле, где кроме VPN-сервера с аутентификацией по сертификатам ничего нет ловить и блокировать всяких брутфорсеров и сканеров практического смысла нет.
Современные боты прекрасно выявляют блокировки и либо подстраиваются под тайм-ауты, либо используют большой пул адресов, чтобы каждый запрос приходил с нового адреса.
Ну а если очень хочется создавать правила по событиям лога, то нужно начать писать свой Fail2ban, так как никакого иного способа научить брандмауэр взаимодействовать с логами нет.
Очень часто к нам обращаются с вопросом: помогите составить правило, которое бы блокировало вот этих нехороших товарищей и приводят записи лога.
После чего сильно удивляются, когда узнают, что средствами только самого брандмауэра это сделать нельзя.
Почему? Давайте посмотрим, где у нас находится брандмауэр, а где логи. Условно цепочку мы можем построить так:
Сеть => Брандмауэр => Приложение => Лог
Классический брандмауэр работает на сетевом и транспортном уровне (L3 и L4) и все что он видит – это пакеты, которые бегают из сети к приложению и обратно.
Лог – это продукт работы приложения, куда оно пишет то, что считает нужным. Причем единого формата логов нет, где четко можно было бы понять, что если в этом поле стоит единичка, то это ошибка, лог – это строковая информация, которую нужно разобрать, проанализировать, определить ключевые части строки.
Любой лог рассчитан прежде всего на чтение его человеком, а не машиной, поэтому работа с логом всегда требует индивидуального подхода.
Следующий момент, лог пишется приложением в некоторое хранилище, которое живет там же, где и приложение и никакого отношения к брандмауэру не имеет.
👆 Сообщения лога через брандмауэр не проходят!
Возможно – это очевидные вещи, но мы не раз и не два слышали предложения искать сообщения лога с помощью критерия Content в брандмауэре.
Но постойте, ведь приложение сообщает клиенту об ошибке? Сообщает, но очень редко делает это открытым текстом, на улице 2026 год и подавляющее большинство коммуникаций зашифровано. Прошли те времена, когда мы могли посмотреть содержимое пакета и сказать «ага».
Все, что мы сейчас можем – это делать какие-либо выводы по косвенным критериям. Но ни один из них не дает 100% гарантии нежелательной активности. Большинство протоколов обмениваются стандартными сообщениями фиксированной длинны и не видя содержимого сообщений нельзя сказать, что именно происходит.
Поэтому в основе любых алгоритмов лежат определенные допущения. Например, при обнаружении брутфорса протокола RDP мы исходили из того, что четко знаем сколько пакетов в состоянии NEW требуется для успешного установления соединения.
Затем выдвинули предположение, что если их количество с одного адреса источника в течении некоторого промежутка времени превышает некоторый лимит – то перед нами попытка подбора пароля.
Никаких критериев, позволяющих однозначно сказать «это подбор» нет. Мы просто определяем некоторый паттерн поведения, который можем определить при помощи критериев брандмауэра и затем делать выводы на основе его повторяемости.
Т.е. в установке нового соединения само по себе криминал нет, но если некто делает это слишком часто, то скорее всего это злоумышленник.
Поэтому, прежде чем браться кого-то или что-то блокировать нужно посмотреть на этот процесс со стороны брандмауэра. Об ошибках в лог пишет приложение, а для сетевого экрана «правильное» и «неправильное» соединения могут не отличаться ничем.
Ну и, наконец, подумать, а зачем оно надо? Практический смысл отлавливать злоумышленников есть только там, где есть потенциально уязвимый сервис. Если же кто-то старательно долбится в стену там, где двери нет и никогда не было – то какая нам печаль до этого дела?
К примеру, на узле, где кроме VPN-сервера с аутентификацией по сертификатам ничего нет ловить и блокировать всяких брутфорсеров и сканеров практического смысла нет.
Современные боты прекрасно выявляют блокировки и либо подстраиваются под тайм-ауты, либо используют большой пул адресов, чтобы каждый запрос приходил с нового адреса.
Ну а если очень хочется создавать правила по событиям лога, то нужно начать писать свой Fail2ban, так как никакого иного способа научить брандмауэр взаимодействовать с логами нет.
👍7🤡4❤2
Кому сейчас доверять?
С таким вопросом уже не первый раз обращаются читатели, обеспокоенные последними инициативами об ограничении параллельного импорта и пытающихся понять кто есть кто в наводнившей рынок китайской продукции.
Сразу начнем с того, что вопрос доверия к производителю – это неверная постановка вопроса, у любого производителя были, есть и будут неудачные серии, с разной степенью неудачности, вплоть до полного провала.
Но, в общем и целом, у производителей первого звена таких «косяков» меньше, чего не скажешь о китайцах, про многие из которых мы слышим в первый раз.
Как быть? Прямого ответа на этот вопрос нет, чтобы он появился нужно обладать статистикой брака и ремонтов, которая часто является информацией закрытой.
Если отталкиваться от средних цифр по отрасли, то процент брака следует рассматривать примерно на уровне 3%, причем в зависимости от типа комплектующих эта цифра может быть как выше, так и ниже.
Скажем для оперативной памяти допустимый процент брака не более 1%, а для материнских плат 3-6%, так как это гораздо более сложные устройства.
Но кроме брака, с которым все достаточно просто и понятно, есть еще и процент обращений за гарантийным обслуживанием, причем это не обязательно будет брак. Пользователь не разбирается в таких вопросах и, если устройство работает нестабильно или неправильно – его несут в гарантию.
И процент здесь выше, хотя тоже колеблется в зависимости от типа комплектующих, так для оперативной памяти 2-5%, а у материнских плат 5-12%, у видеокарт тоже достаточно высокая планка - до 11%.
Это не означает, что у вас на руках брак, но вам от этого легче не станет, наоборот, так как сдать такое устройство обратно будет квестом со звездочкой, а в некоторых случаях и вовсе невозможно.
Хороший пример – память, не работающая на максимальной частоте. На базовой частоте работает? Работает. А остальное, даже если это зашито в XMP-профиль, вам никто не обещал. И мало ли что там на коробке написано.
Также никто не заменит вам оборудование по неподходящим вам потребительским характеристикам: шум вентиляторов, высокое энергопотребление, сильный нагрев и т.д. Технические характеристики в пределах нормы? В пределах. Какие вопросы?
Вопрос совместимости – отдельная больная тема, она и с брендовым железом стояла достаточно остро, но там хотя бы были опубликованы списки совместимости, а вот где их брать для китайцев – вопрос отдельный.
И все-таки, как же быть? А сходить и посмотреть, чем торгуют крупные сети, там деньги считать умеют и все, что имеет высокий процент брака или обращения в гарантию быстро из оборота выводится. Особенно последнее, так как, в отличие от брака, это прямой убыток продавца.
Все, что лежит у них на прилавках не первый день и не имеет наклейки «новинка» брать можно, хоть у них, хоть в других местах. Но есть одна тонкость.
Сэкономить, конечно, хорошо и приятно, но экономия должна быть экономной, иначе получится совсем другая поговорка, про кроилово, которое ведет к попадалову.
Если вы вынуждены комплектовать систему китайскими комплектующими – то начните с обзоров и отзывов. Есть возможность пообщаться с теходелом продавца – сходите пообщайтесь, они не продажники, им лишний геморрой не нужен, поэтому там скажут достаточно честно.
Ну и не занимайтесь самосбором, хотя бы на первой партии. Пусть о несовместимости болит голова у продавца, а не у вас. Вы заказали рабочий ПК и должны его получить, а то, что половина планок памяти без прошивки BIOS не завелась – это не ваша проблема. А для продавца это и не проблема даже особо, так, рабочий момент.
Хотя, все сказанное выше справедливо и для брендов, там тоже все это бывает. Поэтому смотрите, читайте, думайте, а только потом принимайте решение, хорошо все взвесив и просчитав.
С таким вопросом уже не первый раз обращаются читатели, обеспокоенные последними инициативами об ограничении параллельного импорта и пытающихся понять кто есть кто в наводнившей рынок китайской продукции.
Сразу начнем с того, что вопрос доверия к производителю – это неверная постановка вопроса, у любого производителя были, есть и будут неудачные серии, с разной степенью неудачности, вплоть до полного провала.
Но, в общем и целом, у производителей первого звена таких «косяков» меньше, чего не скажешь о китайцах, про многие из которых мы слышим в первый раз.
Как быть? Прямого ответа на этот вопрос нет, чтобы он появился нужно обладать статистикой брака и ремонтов, которая часто является информацией закрытой.
Если отталкиваться от средних цифр по отрасли, то процент брака следует рассматривать примерно на уровне 3%, причем в зависимости от типа комплектующих эта цифра может быть как выше, так и ниже.
Скажем для оперативной памяти допустимый процент брака не более 1%, а для материнских плат 3-6%, так как это гораздо более сложные устройства.
Но кроме брака, с которым все достаточно просто и понятно, есть еще и процент обращений за гарантийным обслуживанием, причем это не обязательно будет брак. Пользователь не разбирается в таких вопросах и, если устройство работает нестабильно или неправильно – его несут в гарантию.
И процент здесь выше, хотя тоже колеблется в зависимости от типа комплектующих, так для оперативной памяти 2-5%, а у материнских плат 5-12%, у видеокарт тоже достаточно высокая планка - до 11%.
Это не означает, что у вас на руках брак, но вам от этого легче не станет, наоборот, так как сдать такое устройство обратно будет квестом со звездочкой, а в некоторых случаях и вовсе невозможно.
Хороший пример – память, не работающая на максимальной частоте. На базовой частоте работает? Работает. А остальное, даже если это зашито в XMP-профиль, вам никто не обещал. И мало ли что там на коробке написано.
Также никто не заменит вам оборудование по неподходящим вам потребительским характеристикам: шум вентиляторов, высокое энергопотребление, сильный нагрев и т.д. Технические характеристики в пределах нормы? В пределах. Какие вопросы?
Вопрос совместимости – отдельная больная тема, она и с брендовым железом стояла достаточно остро, но там хотя бы были опубликованы списки совместимости, а вот где их брать для китайцев – вопрос отдельный.
И все-таки, как же быть? А сходить и посмотреть, чем торгуют крупные сети, там деньги считать умеют и все, что имеет высокий процент брака или обращения в гарантию быстро из оборота выводится. Особенно последнее, так как, в отличие от брака, это прямой убыток продавца.
Все, что лежит у них на прилавках не первый день и не имеет наклейки «новинка» брать можно, хоть у них, хоть в других местах. Но есть одна тонкость.
Сэкономить, конечно, хорошо и приятно, но экономия должна быть экономной, иначе получится совсем другая поговорка, про кроилово, которое ведет к попадалову.
Если вы вынуждены комплектовать систему китайскими комплектующими – то начните с обзоров и отзывов. Есть возможность пообщаться с теходелом продавца – сходите пообщайтесь, они не продажники, им лишний геморрой не нужен, поэтому там скажут достаточно честно.
Ну и не занимайтесь самосбором, хотя бы на первой партии. Пусть о несовместимости болит голова у продавца, а не у вас. Вы заказали рабочий ПК и должны его получить, а то, что половина планок памяти без прошивки BIOS не завелась – это не ваша проблема. А для продавца это и не проблема даже особо, так, рабочий момент.
Хотя, все сказанное выше справедливо и для брендов, там тоже все это бывает. Поэтому смотрите, читайте, думайте, а только потом принимайте решение, хорошо все взвесив и просчитав.
👍18❤3
Установка и настройка WineHQ
Необходимость запуска Windows-программ возникает у пользователей Linux с завидной регулярностью, обычно это какие-то специфические пакеты или утилиты, аналогов которым просто нет.
Для этого принято использовать Wine (_Wine Is Not Emulator_) - свободную реализацию Windows API, позволяющую запускать Windows программы в Linux среде. Но мало просто установить Wine, главное - правильно его использовать, особенно если вы запускаете самые различные программы с разными требованиями и настройками.
Несмотря на то, что Wine присутствует в стандартных репозиториях мы рекомендуем использовать репозитории разработчиков, что обеспечит вам самую последнюю версию продукта и его своевременные обновления.
Пакеты Wine традиционно используют две архитектуры - AMD64 and i386, что требует включения в ОС поддержки 32-битной архитектуры. Однако начиная с Ubuntu 25.10 и Debian Testing (Wine 10.8 и новее) выполнен переход на WoW64 и 32-битные пакеты больше не требуются.
✅ Читать далее: https://interface31.ru/post/ustanovka-i-nastrojka-winehq/
Необходимость запуска Windows-программ возникает у пользователей Linux с завидной регулярностью, обычно это какие-то специфические пакеты или утилиты, аналогов которым просто нет.
Для этого принято использовать Wine (_Wine Is Not Emulator_) - свободную реализацию Windows API, позволяющую запускать Windows программы в Linux среде. Но мало просто установить Wine, главное - правильно его использовать, особенно если вы запускаете самые различные программы с разными требованиями и настройками.
Несмотря на то, что Wine присутствует в стандартных репозиториях мы рекомендуем использовать репозитории разработчиков, что обеспечит вам самую последнюю версию продукта и его своевременные обновления.
Пакеты Wine традиционно используют две архитектуры - AMD64 and i386, что требует включения в ОС поддержки 32-битной архитектуры. Однако начиная с Ubuntu 25.10 и Debian Testing (Wine 10.8 и новее) выполнен переход на WoW64 и 32-битные пакеты больше не требуются.
✅ Читать далее: https://interface31.ru/post/ustanovka-i-nastrojka-winehq/
👍12🔥1
Сборки Windows – вчера, сегодня, завтра
Сборки Windows как массовое явление появились во времена Windows XP и занимались ими практически все те, кто по специфике работы сталкивался с частой установкой ОС.
Прежде всего это было связано с тем, что после установки самой ОС требовался достаточно долгий и кропотливый процесс установки дополнительного ПО.
По факту требовалось доустановить системные компоненты, такие как пакеты Visual C++, NET Framework, DirectX и набор патчей от самых актуальных сетевых угроз.
Далее нужна была установка прикладного ПО: проигрыватели, кодеки, утилиты для записи дисков, DC++ клиенты и т.д. и т.п.
Делать это руками каждый раз было утомительно и поэтому сборка была просто отличным выходом из ситуации, существенно экономящим время.
Но у этого явления была и другая сторона – заполонившие интернет и файлообменники любительские сборки, самой известной из которых стала ZverCD.
Это был настоящий кошмар для сотрудников технических отделов и сервисов, когда клиенты приносили не работающие нормально компьютеры и стоило большого труда объяснить им, что с компьютером все нормально, не нормально с установленной на нем системой. И тем, что случай этот негарантийный.
В результате за этими сборками закрепилось народное название «г-сборки» и их использование стало ярким признаком непрофессионализма. Хотя, справедливости ради, ZverCD был далеко не худшим вариантом. Встречались разного рода «игровые» или «облегченные» сборки, в которых сборщики просто вырезали на свое усмотрение половину системы.
С выходом Windows 7 тенденция делать собственные сборки продолжилась, но акцент сместился с ПО на обновления. Потому что сети плотно вошли в повседневную жизнь, и эксплуатация не обновлённых систем стала небезопасной.
А штатный процесс скачивания и установки обновлений на новый компьютер мог занять часы, если не более. Поэтому обновления скачивались один раз и интегрировались в сборку. После чего оставалось ее регулярно обновлять и формировать новый образ.
При этом интегрируемого в сборку прикладного ПО стало меньше. Причин тому было несколько.
Во-первых, в Windows 7 появилось достаточное количество встроенного ПО, закрывающего базовые потребности: запись CD, просмотр изображений и видео, работа со скриншотами и т.д. и т.д.
Во-вторых, практически все компании стали жить «по белому» избегая установки нелицензионного ПО. Хотя, чтобы не оставлять пользователя совсем с голым ПК многие начали добавлять в образы свободное ПО.
При этом количество «г-сборок» продолжало расти и множиться. А там кто был во что горазд, тем более что собирать собственные сборки на базе Windows 7 стало легче, а интернет стал доступнее, и теперь каждый суслик мог выступить в роли агронома.
Все поменялось с выходом Windows 10 и ее полугодовым планом выпуска новых версий. Система обновлений перешла на накопительную модель, а встроенное прикладное ПО стало закрывать подавляющее число задач.
По-хорошему в чистой системе стало не хватать только офисного пакета и архиватора. Все остальное было из коробки и при этом нормально работало. Все эти наборы кодеков, просмотрщиков и т.п. ушли как страшный сон.
Обновления тоже перестали доставлять неудобства, как и системные компоненты, многие из которых скачивались автоматом при первой необходимости.
Поэтому смысл в сборках потихоньку сошел на нет, а выполнять пересборку каждые полгода стало немного накладно, так как результат не соответствовал потраченному времени.
В Windows 11 такая необходимость еще более уменьшилась, так как штатные инструменты стали лучше и появилась поддержка всех распространенных форматов архивов из коробки.
Поэтому создание сборок современных систем – это или внутренние корпоративные сборки с автоматической установкой всего прикладного ПО. Либо изменить состав предустановленного ПО и предварительно настроить меню Пуск. Либо и то и другое вместе.
В остальных случаях создание собственных сборок современных ОС оправдано сугубо в исследовательских целях, ну либо вам не дают покоя лавры создателя очередной «г-сборки».
Сборки Windows как массовое явление появились во времена Windows XP и занимались ими практически все те, кто по специфике работы сталкивался с частой установкой ОС.
Прежде всего это было связано с тем, что после установки самой ОС требовался достаточно долгий и кропотливый процесс установки дополнительного ПО.
По факту требовалось доустановить системные компоненты, такие как пакеты Visual C++, NET Framework, DirectX и набор патчей от самых актуальных сетевых угроз.
Далее нужна была установка прикладного ПО: проигрыватели, кодеки, утилиты для записи дисков, DC++ клиенты и т.д. и т.п.
Делать это руками каждый раз было утомительно и поэтому сборка была просто отличным выходом из ситуации, существенно экономящим время.
Но у этого явления была и другая сторона – заполонившие интернет и файлообменники любительские сборки, самой известной из которых стала ZverCD.
Это был настоящий кошмар для сотрудников технических отделов и сервисов, когда клиенты приносили не работающие нормально компьютеры и стоило большого труда объяснить им, что с компьютером все нормально, не нормально с установленной на нем системой. И тем, что случай этот негарантийный.
В результате за этими сборками закрепилось народное название «г-сборки» и их использование стало ярким признаком непрофессионализма. Хотя, справедливости ради, ZverCD был далеко не худшим вариантом. Встречались разного рода «игровые» или «облегченные» сборки, в которых сборщики просто вырезали на свое усмотрение половину системы.
С выходом Windows 7 тенденция делать собственные сборки продолжилась, но акцент сместился с ПО на обновления. Потому что сети плотно вошли в повседневную жизнь, и эксплуатация не обновлённых систем стала небезопасной.
А штатный процесс скачивания и установки обновлений на новый компьютер мог занять часы, если не более. Поэтому обновления скачивались один раз и интегрировались в сборку. После чего оставалось ее регулярно обновлять и формировать новый образ.
При этом интегрируемого в сборку прикладного ПО стало меньше. Причин тому было несколько.
Во-первых, в Windows 7 появилось достаточное количество встроенного ПО, закрывающего базовые потребности: запись CD, просмотр изображений и видео, работа со скриншотами и т.д. и т.д.
Во-вторых, практически все компании стали жить «по белому» избегая установки нелицензионного ПО. Хотя, чтобы не оставлять пользователя совсем с голым ПК многие начали добавлять в образы свободное ПО.
При этом количество «г-сборок» продолжало расти и множиться. А там кто был во что горазд, тем более что собирать собственные сборки на базе Windows 7 стало легче, а интернет стал доступнее, и теперь каждый суслик мог выступить в роли агронома.
Все поменялось с выходом Windows 10 и ее полугодовым планом выпуска новых версий. Система обновлений перешла на накопительную модель, а встроенное прикладное ПО стало закрывать подавляющее число задач.
По-хорошему в чистой системе стало не хватать только офисного пакета и архиватора. Все остальное было из коробки и при этом нормально работало. Все эти наборы кодеков, просмотрщиков и т.п. ушли как страшный сон.
Обновления тоже перестали доставлять неудобства, как и системные компоненты, многие из которых скачивались автоматом при первой необходимости.
Поэтому смысл в сборках потихоньку сошел на нет, а выполнять пересборку каждые полгода стало немного накладно, так как результат не соответствовал потраченному времени.
В Windows 11 такая необходимость еще более уменьшилась, так как штатные инструменты стали лучше и появилась поддержка всех распространенных форматов архивов из коробки.
Поэтому создание сборок современных систем – это или внутренние корпоративные сборки с автоматической установкой всего прикладного ПО. Либо изменить состав предустановленного ПО и предварительно настроить меню Пуск. Либо и то и другое вместе.
В остальных случаях создание собственных сборок современных ОС оправдано сугубо в исследовательских целях, ну либо вам не дают покоя лавры создателя очередной «г-сборки».
🤮10😁8💯7❤2🥱1
Про современные сборки, бессмысленные и беспощадные...
Tiny 11 - дело ZverCD живет и торжествует
Сегодня у нас будет довольно необычный обзор - на любительскую сборку Windows 11 под названием Tiny 11. Чем же примечательна данная сборка? Да в принципе - ничем, кроме того, что о ней последнее время не пишет только ленивый и она уже успела попасть в ленты новостей и заголовки крупных сетевых изданий.
Нам обещают "облегченную" сборку Windows 11, которая будет способна работать даже на слабых ПК и местами уже слагают оды и поют дифирамбы. А как обстоит ситуация на самом деле? Давайте разбираться.
Начнем с того, что наше личное отношение к сборкам довольно негативное, особенно к сборкам с частично вырезанным функционалом и сделанными непонятно кем. В этом плане Tiny 11 ничем не отличается от ZverCD и его многочисленных "родственников", которых в изобилии на любом торрент-трекере, но, когда нас несколько раз спросили коллеги от том, что мы думаем про Tiny 11 - стало ясно, надо писать обзор.
Как следует из описания создателей сборки, Tiny 11 создана на базе Windows 11 22H2 и из нее вырезаны некоторые компоненты, которые не сильно нужны для работы, благодаря чему и были достигнуты все заявленные особенности. Мы не будем подробно останавливаться на технических моментах сборки, почему - будет ясно после прочтения обзора.
А для того, чтобы выяснить все преимущества и недостатки системы, то не просто посмотрим на нее, а сравним с чистой установкой Windows 11 22H2 в тех же самых лабораторных условиях.
Для сравнения мы взяли две полностью идентичные виртуальные машины с 4 ядрами CPU, 4 ГБ оперативной памяти, а виртуальные диски разместили на недорогом SSD Crucial BX500 240 ГБ. Такая конфигурация примерно соответствует ПК нижней ценовой категории, где Tiny 11 как раз должна раскрыть себя во всей красе.
✅ Читать далее: https://interface31.ru/post/tiny-11---delo-zvercd-zhivet-i-torzhestvuet/
Tiny 11 - дело ZverCD живет и торжествует
Сегодня у нас будет довольно необычный обзор - на любительскую сборку Windows 11 под названием Tiny 11. Чем же примечательна данная сборка? Да в принципе - ничем, кроме того, что о ней последнее время не пишет только ленивый и она уже успела попасть в ленты новостей и заголовки крупных сетевых изданий.
Нам обещают "облегченную" сборку Windows 11, которая будет способна работать даже на слабых ПК и местами уже слагают оды и поют дифирамбы. А как обстоит ситуация на самом деле? Давайте разбираться.
Начнем с того, что наше личное отношение к сборкам довольно негативное, особенно к сборкам с частично вырезанным функционалом и сделанными непонятно кем. В этом плане Tiny 11 ничем не отличается от ZverCD и его многочисленных "родственников", которых в изобилии на любом торрент-трекере, но, когда нас несколько раз спросили коллеги от том, что мы думаем про Tiny 11 - стало ясно, надо писать обзор.
Как следует из описания создателей сборки, Tiny 11 создана на базе Windows 11 22H2 и из нее вырезаны некоторые компоненты, которые не сильно нужны для работы, благодаря чему и были достигнуты все заявленные особенности. Мы не будем подробно останавливаться на технических моментах сборки, почему - будет ясно после прочтения обзора.
А для того, чтобы выяснить все преимущества и недостатки системы, то не просто посмотрим на нее, а сравним с чистой установкой Windows 11 22H2 в тех же самых лабораторных условиях.
Для сравнения мы взяли две полностью идентичные виртуальные машины с 4 ядрами CPU, 4 ГБ оперативной памяти, а виртуальные диски разместили на недорогом SSD Crucial BX500 240 ГБ. Такая конфигурация примерно соответствует ПК нижней ценовой категории, где Tiny 11 как раз должна раскрыть себя во всей красе.
✅ Читать далее: https://interface31.ru/post/tiny-11---delo-zvercd-zhivet-i-torzhestvuet/
👍19🤡7🥱2
Некоторые, неочевидные особенности связки DNS и DHCP в Active Directory
Вчера, в обсуждении возник вопрос, а зачем нужна связка из MS DNS и MS DHCP, ведь можно использовать любой другой DHCP сервер.
Вроде бы очевидный ответ: для того, чтобы DHCP мог динамически изменять DNS-записи в AD.
В ответ можно услышать, мол у меня DHCP на роутере и записи прекрасно добавляются. И на первый взгляд это действительно так.
Но, на самом деле, это называется «вроде бы работает», именно «вроде бы».
Почему? Правильная работа Active Directory серьезно завязана на правильную работу DNS. Поэтому важно, чтобы DHCP-сервер мог своевременно динамически менять записи, но это может делать не абы кто, а только авторизованный сервер.
При отсутствии авторизованного сервера Active Directory может сама внести нужную запись в момент входа в домен. Но только в прямую зону. В обратную зону никаких записей добавлено не будет.
Если устройство не входит в домен, то никаких записей о нем также добавлено не будет. А таких устройств может быть много: принтеры, гипервизоры, промышленные контроллеры и т.д. и т.п.
Первая проистекающая отсюда проблема – это сложности администрирования, так как вам, чтобы подключиться к принтеру в 216 кабинете вместо
Но все это ерунда, когда вопрос коснется обратной зоны. Обратная зона нужна для правильной работы очень многих интеграций сторонних приложений в AD и без нее ситуация превращается в «жизнь – боль» или «какая гадость эта ваша Active Directory».
Как живой пример подобной интеграции можно привести взаимодействие Squid и AD через Kerberos.
И заканчивается это все для администратора довольно плохо. К нам не раз приходили читатели, мол сделал все по статье, ничего не работает. И случайный кусок лога.
Хорошо, если кусок верный и ошибка в нем сразу видна.
В противном случае заниматься дебагом Kerberos по переписке у автора, как и других читателей нет никакого желания, а квалификации вопрошающего явно недостаточно для самостоятельного решения проблемы.
Хотя львиная их часть кроется как раз в неправильной работе DNS и обратная зона только частный случай.
Поэтому нужно сразу настраивать работу ключевых компонентов правильно, а не оставлять в состоянии «вроде работает»
Вчера, в обсуждении возник вопрос, а зачем нужна связка из MS DNS и MS DHCP, ведь можно использовать любой другой DHCP сервер.
Вроде бы очевидный ответ: для того, чтобы DHCP мог динамически изменять DNS-записи в AD.
В ответ можно услышать, мол у меня DHCP на роутере и записи прекрасно добавляются. И на первый взгляд это действительно так.
Но, на самом деле, это называется «вроде бы работает», именно «вроде бы».
Почему? Правильная работа Active Directory серьезно завязана на правильную работу DNS. Поэтому важно, чтобы DHCP-сервер мог своевременно динамически менять записи, но это может делать не абы кто, а только авторизованный сервер.
При отсутствии авторизованного сервера Active Directory может сама внести нужную запись в момент входа в домен. Но только в прямую зону. В обратную зону никаких записей добавлено не будет.
Если устройство не входит в домен, то никаких записей о нем также добавлено не будет. А таких устройств может быть много: принтеры, гипервизоры, промышленные контроллеры и т.д. и т.п.
Первая проистекающая отсюда проблема – это сложности администрирования, так как вам, чтобы подключиться к принтеру в 216 кабинете вместо
printer-216 надо сначала где-то найти его текущий IP-адрес. Но все это ерунда, когда вопрос коснется обратной зоны. Обратная зона нужна для правильной работы очень многих интеграций сторонних приложений в AD и без нее ситуация превращается в «жизнь – боль» или «какая гадость эта ваша Active Directory».
Как живой пример подобной интеграции можно привести взаимодействие Squid и AD через Kerberos.
И заканчивается это все для администратора довольно плохо. К нам не раз приходили читатели, мол сделал все по статье, ничего не работает. И случайный кусок лога.
Хорошо, если кусок верный и ошибка в нем сразу видна.
В противном случае заниматься дебагом Kerberos по переписке у автора, как и других читателей нет никакого желания, а квалификации вопрошающего явно недостаточно для самостоятельного решения проблемы.
Хотя львиная их часть кроется как раз в неправильной работе DNS и обратная зона только частный случай.
Поэтому нужно сразу настраивать работу ключевых компонентов правильно, а не оставлять в состоянии «вроде работает»
👍20🥱5❤4
Samba AD DC – ожидания и реальность
Каждый раз обращаясь к этому вопросу можно услышать, что Samba AD DC в целом дорос до продуктивного уровня и если не фонтан, то все основные задачи закрывает примерно как на уровне Windows Server 2008 R2.
В общем и целом, это так, Samba предоставляет стабильные возможности домена уровня 2008 R2, поддерживает групповые политики и управляется стандартными Windows оснастками, на первый взгляд – отличная замена Windows AD и хорошая экономия на лицензиях, но это только на первый взгляд.
В качестве одиночного контроллера Samba AD DC действительно смотрится неплохо, но как мы помним, базовые правила построения Active Directory требуют наличия минимум двух контроллеров.
И это даже не вопрос высокой доступности, это базовый вопрос элементарной устойчивости, если что-то случилось с основным контроллером, скажем физически и невосстановимо вышел из строя, то его функции подхватит второй контроллер, так что даже никто ничего не заметит.
Напоминаем, что в современной AD все контроллеры равны, а роли FSMO не нужны для повседневной работы домена (некоторые вообще нужны один два раза в его жизни).
А что у нас предлагает Samba, а предлагает она нам интересные моменты – штатной репликации SYSVOL нет и не будет, потому как реализация закрытого протокола DFS-R сопряжена как с техническими, так и с юридическими сложностями.
Взамен предлагается ручная репликация любым доступным способом, скажем через rsync, но репликацией это можно назвать с большой натяжкой, так как транзакционная целостность процесса отсутствует, что серьезно осложняет дело.
Что это значит? Когда мы создаем новую политику – метаданные от нее записываются в базу AD и штатно реплицируются между контроллерами, а файлы остаются в SYSVOL контроллера и ждут пока мы их не синхронизируем руками.
В итоге получаем, что на каком-то контроллере политика есть, а файлов нет. А у клиента политика то применяется, то не применяется, смотря к какому контроллеру он подключился.
Если файлы были изменены сразу в двух местах, то просто наступает ад, какую версию считать главной? В Samba эту проблему решили костылем – контроллер с ролью PDC не может быть целью rsync-синхронизации, только источником и все изменения в AD следует вносить только на нем.
Но это только надводная часть айсберга, под водой у нас остался механизм трансляции SID Windows в Linux UID, для этого он на каждом контроллере хранит локальную базу сопоставлений idmap.ldb, которая также не реплицируется.
После того, как мы добавили в AD новые объекты, которые являются субъектами безопасности и имеют свой SID нам нужно обновить эту базу на всех контроллерах домена. Причем сделать это можно только с остановкой службы контроллера и потом обязательно перечитать права на SYSVOL.
Фактически у нас появляется три отдельных процесса:
🔹 Репликация базы AD (автоматически)
🔹 Синхронизация SYSVOL (руками, в одну сторону)
🔹 Синхронизация idmap.ldb (руками, с остановкой службы)
Про транзакционную целостность мы даже речи не ведем, нам бы тут ничего не сломать. Поэтому все многоконтроллерные и многосайтовые конфигурации тут же разбиваются об этот кошмар.
По сути, Samba предоставляет нам только две более-менее рабочие конфигурации AD.
🔸 Один контроллер + бекап (холодный резерв)
🔸 Два контроллера с постоянным ручным контролем процесса
Это даже не уровень PDC/BDC NT4, там хотя бы репликация на вторичный контроллер была автоматической. Это история про один контроллер в нетребовательной среде, не более.
Хотя каждый может принимать решение самостоятельно, главное осознавать риски и представлять в чем заключается суть проблемы.
Каждый раз обращаясь к этому вопросу можно услышать, что Samba AD DC в целом дорос до продуктивного уровня и если не фонтан, то все основные задачи закрывает примерно как на уровне Windows Server 2008 R2.
В общем и целом, это так, Samba предоставляет стабильные возможности домена уровня 2008 R2, поддерживает групповые политики и управляется стандартными Windows оснастками, на первый взгляд – отличная замена Windows AD и хорошая экономия на лицензиях, но это только на первый взгляд.
В качестве одиночного контроллера Samba AD DC действительно смотрится неплохо, но как мы помним, базовые правила построения Active Directory требуют наличия минимум двух контроллеров.
И это даже не вопрос высокой доступности, это базовый вопрос элементарной устойчивости, если что-то случилось с основным контроллером, скажем физически и невосстановимо вышел из строя, то его функции подхватит второй контроллер, так что даже никто ничего не заметит.
Напоминаем, что в современной AD все контроллеры равны, а роли FSMO не нужны для повседневной работы домена (некоторые вообще нужны один два раза в его жизни).
А что у нас предлагает Samba, а предлагает она нам интересные моменты – штатной репликации SYSVOL нет и не будет, потому как реализация закрытого протокола DFS-R сопряжена как с техническими, так и с юридическими сложностями.
Взамен предлагается ручная репликация любым доступным способом, скажем через rsync, но репликацией это можно назвать с большой натяжкой, так как транзакционная целостность процесса отсутствует, что серьезно осложняет дело.
Что это значит? Когда мы создаем новую политику – метаданные от нее записываются в базу AD и штатно реплицируются между контроллерами, а файлы остаются в SYSVOL контроллера и ждут пока мы их не синхронизируем руками.
В итоге получаем, что на каком-то контроллере политика есть, а файлов нет. А у клиента политика то применяется, то не применяется, смотря к какому контроллеру он подключился.
Если файлы были изменены сразу в двух местах, то просто наступает ад, какую версию считать главной? В Samba эту проблему решили костылем – контроллер с ролью PDC не может быть целью rsync-синхронизации, только источником и все изменения в AD следует вносить только на нем.
Но это только надводная часть айсберга, под водой у нас остался механизм трансляции SID Windows в Linux UID, для этого он на каждом контроллере хранит локальную базу сопоставлений idmap.ldb, которая также не реплицируется.
После того, как мы добавили в AD новые объекты, которые являются субъектами безопасности и имеют свой SID нам нужно обновить эту базу на всех контроллерах домена. Причем сделать это можно только с остановкой службы контроллера и потом обязательно перечитать права на SYSVOL.
Фактически у нас появляется три отдельных процесса:
🔹 Репликация базы AD (автоматически)
🔹 Синхронизация SYSVOL (руками, в одну сторону)
🔹 Синхронизация idmap.ldb (руками, с остановкой службы)
Про транзакционную целостность мы даже речи не ведем, нам бы тут ничего не сломать. Поэтому все многоконтроллерные и многосайтовые конфигурации тут же разбиваются об этот кошмар.
По сути, Samba предоставляет нам только две более-менее рабочие конфигурации AD.
🔸 Один контроллер + бекап (холодный резерв)
🔸 Два контроллера с постоянным ручным контролем процесса
Это даже не уровень PDC/BDC NT4, там хотя бы репликация на вторичный контроллер была автоматической. Это история про один контроллер в нетребовательной среде, не более.
Хотя каждый может принимать решение самостоятельно, главное осознавать риски и представлять в чем заключается суть проблемы.
1👍23❤2😁1
Используете ли вы Samba AD DC
Anonymous Poll
5%
Да, один контроллер
6%
Да, два контроллера
4%
Да, более двух контроллеров
1%
Использовал, пока все не упало
4%
Использовал, отказался
10%
Нет, но хочу попробовать
2%
Нет, но планирую внедрять
47%
Нет и пробовать не хочу
3%
Тестирую, пока не определился
18%
Ничего не понятно, но очень интересно
Хотите сгореть – купите б/у ИБП
Короткая, но поучительная история от коллеги. Не так давно в новую стойку ему понадобился ИБП, новый стоит дорого, поэтому купили на Авито Powercom без батарей. Внешне все хорошо, докинули батарейки – все работает.
До тех пор пока на выходных в здании не делали что-то с электрикой, несколько раз включая и отключая свет, чем загнали ИБП в глубокий разряд. А понедельник встретил их в офисе непередаваемым запахом паленого пластика, который исходил как раз от ИБП.
Батареи фактически кипели и что ничего не загорелось и не сгорело – это вопрос везения. Сначала не поняли, взяли новые батареи – все норм, немного разрядили – тоже вроде все нормально.
Но стоило только посадить батареи практически полностью, как у ИБП снова включился режим кипятильника. Хорошо сэкономили.
Рынок б/у – это всегда лотерея и есть вещи, с которыми в лотерею лучше не играть, ИБП – одна из таких вещей.
Короткая, но поучительная история от коллеги. Не так давно в новую стойку ему понадобился ИБП, новый стоит дорого, поэтому купили на Авито Powercom без батарей. Внешне все хорошо, докинули батарейки – все работает.
До тех пор пока на выходных в здании не делали что-то с электрикой, несколько раз включая и отключая свет, чем загнали ИБП в глубокий разряд. А понедельник встретил их в офисе непередаваемым запахом паленого пластика, который исходил как раз от ИБП.
Батареи фактически кипели и что ничего не загорелось и не сгорело – это вопрос везения. Сначала не поняли, взяли новые батареи – все норм, немного разрядили – тоже вроде все нормально.
Но стоило только посадить батареи практически полностью, как у ИБП снова включился режим кипятильника. Хорошо сэкономили.
Рынок б/у – это всегда лотерея и есть вещи, с которыми в лотерею лучше не играть, ИБП – одна из таких вещей.
👍20🔥6👨💻6❤1😁1
Раз уж подняли тему ИБП, то повторим. Так как знают не все и продолжают покупать дорогой ИБП с малой емкостью батарей, но большой мощностью и удивляться.
Как правильно выбрать ИБП
Сегодня столкнулись с тем, что не все наши коллеги умеют правильно выбрать ИБП и рассчитать приблизительное время работы оборудования.
Большинство, выбирая ИБП, исходят из его мощности, полагая что чем больше мощность, тем дольше будет держать ИБП. Что абсолютно неверно.
Почему? Начнем с того, что такое мощность. Мощность это способность электрического тока выполнить определенную работу. Потребляемая (активная) мощность электроприборов выражается в Ваттах (Вт, W).
При этом в сетях переменного тока реальная потребляемая мощность может быть выше активной мощности устройства, так как существует еще и реактивная емкость, связанная с емкостной и индуктивной составляющей устройства.
Поэтому в таких случаях принято говорить о полной мощности, которая измеряется в Вольт-Амперах (ВА, VA) и именно ее указывают для ИБП.
Чтобы правильно рассчитать полную мощность нам нужно знать коэффициент фазового сдвига, вносимый устройством, а это сделать довольно непросто. Поэтому упростим себе задачу и будем считать, что полная мощность компьютера или периферийного устройства больше активной мощности в 1,4 раза.
Таким образом, если средний офисный ПК потребляет 200 Вт активной мощности, то полную мощность такого устройства следует принять за 280 ВА.
Мощность ИБП показывает предельную мощность подключенных устройств и не более того. Грубо говоря, к ИБП на 650 ВА мы можем подключить только два условных ПК, а к ИБП на 850 ВА – уже три.
Превышение мощности приведет к перегрузке ИБП и отключению нагрузки.
А что же у нас со временем? А время у нас напрямую зависит от двух параметров: емкости батареи, которую измеряют в Ампер-часах (А-ч, Ah) и током потребления нагрузки (читай – мощностью).
Вычислить время можно по приблизительной формуле:
Где E – емкость АКБ, U – напряжение батареи АКБ, S – полная мощность нагрузки. Результат получим в часах.
Если мы возьмем две реальные модели ИБП:
▫️ DEXP CEE-E 650VA – 2999 руб.
▫️ DEXP CEE-E 850VA – 3799 руб.
То может показаться, что приобретение второй модели для нашего условного ПК предпочтительнее, как-никак на целых 200 ВА больше.
Но оба ИБП имеют в составе единственную батарею 12 В, 7 А-ч, это стандартная батарея, все их знают.
Теперь считаем:
Если нагрузить оба этих ИБП почти по полной, т.е. подключить к первому два условных ПК, а ко второму три, то время работы от батареи составит 9 и 6 минут соответственно.
Но это идеальная цифра, в реальности добавим сюда КПД инвертора и потерю емкости батареями, поэтому полученную цифру следует уменьшить примерно на 25-30%.
Это будет примерно объективной оценкой времени на которое вы можете рассчитывать.
При этом, обратите внимание, более мощный бесперебойник обеспечивает меньшее время работы чем менее мощный, но обеспечивает более высокий ток для нагрузки.
Кому-то это может показаться парадоксальным, но это факт: при использовании одного и того же набора аккумуляторных батарей с увеличением мощности ИБП время работы в автономном режиме будет падать.
И тем более нет смысла в покупке более мощного ИБП если ваша нагрузка позволяет купить менее мощный, время работы от этого не увеличится, а вы просто выбросите деньги на ветер.
Как правильно выбрать ИБП
Сегодня столкнулись с тем, что не все наши коллеги умеют правильно выбрать ИБП и рассчитать приблизительное время работы оборудования.
Большинство, выбирая ИБП, исходят из его мощности, полагая что чем больше мощность, тем дольше будет держать ИБП. Что абсолютно неверно.
Почему? Начнем с того, что такое мощность. Мощность это способность электрического тока выполнить определенную работу. Потребляемая (активная) мощность электроприборов выражается в Ваттах (Вт, W).
При этом в сетях переменного тока реальная потребляемая мощность может быть выше активной мощности устройства, так как существует еще и реактивная емкость, связанная с емкостной и индуктивной составляющей устройства.
Поэтому в таких случаях принято говорить о полной мощности, которая измеряется в Вольт-Амперах (ВА, VA) и именно ее указывают для ИБП.
Чтобы правильно рассчитать полную мощность нам нужно знать коэффициент фазового сдвига, вносимый устройством, а это сделать довольно непросто. Поэтому упростим себе задачу и будем считать, что полная мощность компьютера или периферийного устройства больше активной мощности в 1,4 раза.
S = 1,4 * P
Таким образом, если средний офисный ПК потребляет 200 Вт активной мощности, то полную мощность такого устройства следует принять за 280 ВА.
Мощность ИБП показывает предельную мощность подключенных устройств и не более того. Грубо говоря, к ИБП на 650 ВА мы можем подключить только два условных ПК, а к ИБП на 850 ВА – уже три.
Превышение мощности приведет к перегрузке ИБП и отключению нагрузки.
А что же у нас со временем? А время у нас напрямую зависит от двух параметров: емкости батареи, которую измеряют в Ампер-часах (А-ч, Ah) и током потребления нагрузки (читай – мощностью).
Вычислить время можно по приблизительной формуле:
t = E * U / S
Где E – емкость АКБ, U – напряжение батареи АКБ, S – полная мощность нагрузки. Результат получим в часах.
Если мы возьмем две реальные модели ИБП:
▫️ DEXP CEE-E 650VA – 2999 руб.
▫️ DEXP CEE-E 850VA – 3799 руб.
То может показаться, что приобретение второй модели для нашего условного ПК предпочтительнее, как-никак на целых 200 ВА больше.
Но оба ИБП имеют в составе единственную батарею 12 В, 7 А-ч, это стандартная батарея, все их знают.
Теперь считаем:
t = 7 * 12 / 280 = 18 минут
Если нагрузить оба этих ИБП почти по полной, т.е. подключить к первому два условных ПК, а ко второму три, то время работы от батареи составит 9 и 6 минут соответственно.
Но это идеальная цифра, в реальности добавим сюда КПД инвертора и потерю емкости батареями, поэтому полученную цифру следует уменьшить примерно на 25-30%.
Это будет примерно объективной оценкой времени на которое вы можете рассчитывать.
При этом, обратите внимание, более мощный бесперебойник обеспечивает меньшее время работы чем менее мощный, но обеспечивает более высокий ток для нагрузки.
Кому-то это может показаться парадоксальным, но это факт: при использовании одного и того же набора аккумуляторных батарей с увеличением мощности ИБП время работы в автономном режиме будет падать.
И тем более нет смысла в покупке более мощного ИБП если ваша нагрузка позволяет купить менее мощный, время работы от этого не увеличится, а вы просто выбросите деньги на ветер.
1👍29💯6❤3👎1🤡1
Как устроен и работает брандмауэр Windows
Брандмауэр Windows впервые был представлен в 2001 году вместе с выходом SP2 для Windows XP, а современный облик приобрел вместе с выходом Windows Vista, но не смотря на столь преклонный возраст для многих он до сих пор остается чем-то непонятным.
Такую ситуацию нельзя считать нормальной, как и полное отключение брандмауэра. Поэтому сегодня мы рассмотрим, как устроен и работает брандмауэр Windows, как он взаимодействует с пользователем и как следует составлять и читать его правила.
Мы уже не раз и не два говорили, что Microsoft имеет талант давать своим продуктам неудачные названия, которые очень часто становятся еще хуже при переводе на другие языки. Так и в этом случае, основной рабочий интерфейс брандмауэра называется Монитор брандмауэра Защитника Windows в режиме повышенной безопасности.
Длинно, мудрено и еще повышенную безопасность зачем-то приплели, но другого графического интерфейса для управления брандмауэром в Windows нет. Попасть в него можно классическим путем через Панель управления - Брандмауэр Защитника Windows - Дополнительные параметры.
Туда же туда ведут несколько разных путей, например, через свойства сетевых подключений, но в разных версиях Windows эти пути могут быть различны и нами не рассматриваются.
✅ Читать далее: https://interface31.ru/post/kak-ustroen-i-rabotaet-brandmauer-windows/
Брандмауэр Windows впервые был представлен в 2001 году вместе с выходом SP2 для Windows XP, а современный облик приобрел вместе с выходом Windows Vista, но не смотря на столь преклонный возраст для многих он до сих пор остается чем-то непонятным.
Такую ситуацию нельзя считать нормальной, как и полное отключение брандмауэра. Поэтому сегодня мы рассмотрим, как устроен и работает брандмауэр Windows, как он взаимодействует с пользователем и как следует составлять и читать его правила.
Мы уже не раз и не два говорили, что Microsoft имеет талант давать своим продуктам неудачные названия, которые очень часто становятся еще хуже при переводе на другие языки. Так и в этом случае, основной рабочий интерфейс брандмауэра называется Монитор брандмауэра Защитника Windows в режиме повышенной безопасности.
Длинно, мудрено и еще повышенную безопасность зачем-то приплели, но другого графического интерфейса для управления брандмауэром в Windows нет. Попасть в него можно классическим путем через Панель управления - Брандмауэр Защитника Windows - Дополнительные параметры.
Туда же туда ведут несколько разных путей, например, через свойства сетевых подключений, но в разных версиях Windows эти пути могут быть различны и нами не рассматриваются.
✅ Читать далее: https://interface31.ru/post/kak-ustroen-i-rabotaet-brandmauer-windows/
👍16❤1🤮1
Ток, напряжение, мощность
Как показывают обсуждения, не все читатели, а особенно читательницы, понимают основы электротехники и делают неправильные выводы, хотя это истины доступны любому студенту электротехнического колледжа.
Поэтому с них и начнем, постаравшись объяснить наиболее простым языком, в максимально упрощенном виде. Начнем с терминов и аналогий:
🔹 Напряжение – это разность потенциалов, которую можно представить как перепад высот, с которых у нас потечет вода (ток), чем больше этот перепад, тем сильнее потечет вода (больше будет ток).
🔹 Ток – поток заряженных частиц, выполняющих полезную (или бесполезную работу), в нашей аналогии та самая вода.
🔹 Мощность – та самая проделанная работа, которую выполнил поток воды (электрический ток).
Классическая формула мощности:
Как видим, формула линейно зависит как от напряжения, так и от тока. Теоретически мы можем играть от обеих сторон, но это чисто теоретически.
Вернемся к нашей аналогии, давайте возьмем мощность в 1200 Вт, для 12 В это будет ток в 100 А, а для 400 В всего в 3 А. Ну и что? А снова вернемся к воде, для выполнения одной и той же работы нам нужно или 3 куба воды или 100 кубов. Есть разница?
А что будет, если у нас что-то пойдет не так, и эта вода неконтролируемо растечется? Ну три куба спокойно по канавке стекут в ближайшую реку, а вот 100 кубов способны наделать бед.
И вода веде не просто течет на условную мельницу, кроме полезной работы она делает и совсем не полезную – подмывает берега, переносит грунт. Так и ток, протекая через проводники он их нагревает, потому как проводники обладают некоторым сопротивлением, приводящим к потерям.
А так как работу выполняет именно ток, то мощность, выделяемая на сопротивлении (а любой проводник – это сопротивление) рассчитывается по формуле:
В нашем случае результат будет отличаться на порядки, хотя полезная мощность нагрузки не изменится.
Так при сопротивлении проводника в 1 Ом и полезной нагрузке 1200 Вт при 400 В и 3 А потери в проводнике составят всего 9 Вт, не мало, но и не много, обычный пассивный радиатор проблему решит.
А вот при 12 В и 100 А на этом же проводнике в виде тепла выделится 10 кВт, которые нам нужно или куда-то деть (отопить помещение) или у нас начнет гореть и плавиться сам проводник, плата под ним, соседние детали, корпус.
Хотя на самом деле такого тока в этой цепи возникнуть не может и больше 12 А там не потечет. Закон Ома, но и 144 Вт – это уже не шутки, без активного охлаждения не обойтись.
Поэтому нормальный путь – это повышение напряжения, грубо говоря повысив напряжение в 2 раза и на столько же уменьшив ток, при одной и той же мощности нагрузки, мы уменьшаем потери в 4 раза. Именно поэтому магистральные ЛЭП сплошь высоковольтные.
Но бесконечно увеличивать напряжение мы не можем, ток, он как вода, ищет любую дырочку. И при определенной разности потенциалов он может заставить электроны начать упорядоченное движение даже в непроводящей среде.
Для бытовой техники с допусками по влажности и наличии в воздухе пыли принято считать, что 1 см воздуха пробивается 1 кВ напряжения. А это создает ненужные риски.
Поэтому импульсные блоки питания работают на уровне примерно 400 В – золотой середине, потери падают квадратично и можно отлично экономить на сечении проводов, размере компонентов и теплоотводов, но не подвергая себя риску электрического пробоя.
А все высокотоковые цепи стараются разместить как можно ближе к потребителю, не даром на материнской плате VRM прижат как можно ближе к сокету. Потому что мизерные напряжения питания процессора обуславливают крайне высокие токи.
Повысить напряжение мы не можем, так как уменьшение технологического процесса требует понижения напряжения, во избежание электрического пробоя.
Меньше напряжение – больше ток и квадратично большее тепловыделение, которое и стало главным ограничивающим фактором роста частот и быстродействия современной электроники.
Как показывают обсуждения, не все читатели, а особенно читательницы, понимают основы электротехники и делают неправильные выводы, хотя это истины доступны любому студенту электротехнического колледжа.
Поэтому с них и начнем, постаравшись объяснить наиболее простым языком, в максимально упрощенном виде. Начнем с терминов и аналогий:
🔹 Напряжение – это разность потенциалов, которую можно представить как перепад высот, с которых у нас потечет вода (ток), чем больше этот перепад, тем сильнее потечет вода (больше будет ток).
🔹 Ток – поток заряженных частиц, выполняющих полезную (или бесполезную работу), в нашей аналогии та самая вода.
🔹 Мощность – та самая проделанная работа, которую выполнил поток воды (электрический ток).
Классическая формула мощности:
P = I *U
Как видим, формула линейно зависит как от напряжения, так и от тока. Теоретически мы можем играть от обеих сторон, но это чисто теоретически.
Вернемся к нашей аналогии, давайте возьмем мощность в 1200 Вт, для 12 В это будет ток в 100 А, а для 400 В всего в 3 А. Ну и что? А снова вернемся к воде, для выполнения одной и той же работы нам нужно или 3 куба воды или 100 кубов. Есть разница?
А что будет, если у нас что-то пойдет не так, и эта вода неконтролируемо растечется? Ну три куба спокойно по канавке стекут в ближайшую реку, а вот 100 кубов способны наделать бед.
И вода веде не просто течет на условную мельницу, кроме полезной работы она делает и совсем не полезную – подмывает берега, переносит грунт. Так и ток, протекая через проводники он их нагревает, потому как проводники обладают некоторым сопротивлением, приводящим к потерям.
А так как работу выполняет именно ток, то мощность, выделяемая на сопротивлении (а любой проводник – это сопротивление) рассчитывается по формуле:
P = I^2 * R
В нашем случае результат будет отличаться на порядки, хотя полезная мощность нагрузки не изменится.
Так при сопротивлении проводника в 1 Ом и полезной нагрузке 1200 Вт при 400 В и 3 А потери в проводнике составят всего 9 Вт, не мало, но и не много, обычный пассивный радиатор проблему решит.
А вот при 12 В и 100 А на этом же проводнике в виде тепла выделится 10 кВт, которые нам нужно или куда-то деть (отопить помещение) или у нас начнет гореть и плавиться сам проводник, плата под ним, соседние детали, корпус.
Хотя на самом деле такого тока в этой цепи возникнуть не может и больше 12 А там не потечет. Закон Ома, но и 144 Вт – это уже не шутки, без активного охлаждения не обойтись.
Поэтому нормальный путь – это повышение напряжения, грубо говоря повысив напряжение в 2 раза и на столько же уменьшив ток, при одной и той же мощности нагрузки, мы уменьшаем потери в 4 раза. Именно поэтому магистральные ЛЭП сплошь высоковольтные.
Но бесконечно увеличивать напряжение мы не можем, ток, он как вода, ищет любую дырочку. И при определенной разности потенциалов он может заставить электроны начать упорядоченное движение даже в непроводящей среде.
Для бытовой техники с допусками по влажности и наличии в воздухе пыли принято считать, что 1 см воздуха пробивается 1 кВ напряжения. А это создает ненужные риски.
Поэтому импульсные блоки питания работают на уровне примерно 400 В – золотой середине, потери падают квадратично и можно отлично экономить на сечении проводов, размере компонентов и теплоотводов, но не подвергая себя риску электрического пробоя.
А все высокотоковые цепи стараются разместить как можно ближе к потребителю, не даром на материнской плате VRM прижат как можно ближе к сокету. Потому что мизерные напряжения питания процессора обуславливают крайне высокие токи.
Повысить напряжение мы не можем, так как уменьшение технологического процесса требует понижения напряжения, во избежание электрического пробоя.
Меньше напряжение – больше ток и квадратично большее тепловыделение, которое и стало главным ограничивающим фактором роста частот и быстродействия современной электроники.
1👍30❤8🤔3🤡2🔥1
У Васи есть папка с закачками, куда он скачивает без разбора всякое разное, и чтобы каждый раз не разбирать ее руками он пишет скрипт, который будет автоматически перемещать видеоролики в другую папку:
Что не так с этим скриптом?
👇 Ответы в опросе ниже 👇
for file in $(ls *.mp4); do
mv -f $file /new_path/video
done
Что не так с этим скриптом?
👇 Ответы в опросе ниже 👇
👌2❤1🤡1
Что не так со скриптом Васи?
Предположений было довольно много, но большинство указанных и неуказанных в опросе, но всплывшие в обсуждении недостатки не являются фатальными.
Основной и очень грубой ошибкой является использование для получения списка файлов команды ls, также все сказанное далее в полной мере относится и к find. Обе эти команды созданы для интерактивного взаимодействия с оператором и не предназначены для использования в скриптах.
Почему? В обсуждении было приведено несколько хороших ссылок на подробные материалы, правда на английском, но даже с переводчиком смысл будет понятен. Мы же остановимся коротко на основных проблемах.
🔹 Первая и самая очевидная - пробелы, имя файла с пробелами превратится в набор строк, каждая из которых будет обрабатываться скриптом отдельно. И если в данном примере это относительно безопасно, то в реальных сценариях это может привести к абсолютно непредсказуемым последствиям.
Например, в нашей практике мы сталкивались со скриптом, который таким образом подсчитывал количество файлов в папке, потом сортировал их по дате создания и удалял самые старые, чтобы осталось всего N-файлов. Файл с пробелами в имени сразу грубо ломает эту логику и может привести к удалению нужных данных.
Обернуть ls *.mp4 в кавычки тоже не даст результата, так как в этом случае в качестве единой строки будет использоваться весь вывод команды.
🔹Вторая проблема – возможное наличие в имени файла управляющих и подстановочных символов. На практике встречается гораздо реже, но так как Linux вполне допускает подобные имена, то вы вполне можете с ними столкнуться, например, они могут появиться в результате ошибок в работе скриптов.
Допустим у вас есть набор файлов: 1Сезон-1Серия.mp4, 1Сезон-2Серия.mp4 и т.д. и туда случайным образом затесался файл где имя состоит из единицы и звездочки за ним. Символ звездочки будет расценен как подстановочный и ls подставит туда все попадающие под маску файлы. В результате все ваши серии попадут в вывод два раза. Как мы уже говорили, если в данном случае это безопасно, то в других сценариях может привести к различным негативным эффектам.
🔹Третья основная проблема – символы национальных алфавитов. Сейчас эта проблема отошла на второй план, но актуальной быть от этого не перестала. А причина все таже – ls и find рассчитаны на то, чтобы выводить информацию на экран.
А далее все зависит от установленной локали, если локаль не содержит символа, соответствующего его коду, то на его месте появится «крякозябкрик» или знак вопроса в ромбе, иди еще что-нибудь, а также такой символ может быть просто пропущен.
👆 Теперь о том, как сделать правильно. В оболочках POSIX, которым относится bash и его производные, есть функция позволяющая использовать в именах файлов символы подстановки, поэтому вывод никаких дополнительных команд анализировать не нужно, а переменную следует обязательно обернуть в кавычки:
В этом случае корректно будут отработаны и пробелы, и спецсимволы, и символы национальных алфавитов.
Также можно подстраховаться и добавить проверку на существование файла:
Если указанный файл не существует, то цикл пропустит текущую итерацию и перейдет к следующей.
👉 P.S. Почему мы заострили внимание именно на этой проблеме, а не на проверке наличия папки и наличия закрывающего слеша?
Потому что ls/find архитектурный баг скрипта, а остальное – частный случай с неправильной конфигурацией окружения.
Если Вася проследит, чтобы папка на момент запуска скрипта существовала – проблем у него не возникнет, никогда и никаких.
А вот использование ls/find для поиска файлов - это 100% проблема, заложенная архитектурно.
Если же Вася отразит в документации, мол перед запуском скрипта обязательно проверьте наличие целевой папки, то это уже будет не баг, а фича.
Предположений было довольно много, но большинство указанных и неуказанных в опросе, но всплывшие в обсуждении недостатки не являются фатальными.
Основной и очень грубой ошибкой является использование для получения списка файлов команды ls, также все сказанное далее в полной мере относится и к find. Обе эти команды созданы для интерактивного взаимодействия с оператором и не предназначены для использования в скриптах.
Почему? В обсуждении было приведено несколько хороших ссылок на подробные материалы, правда на английском, но даже с переводчиком смысл будет понятен. Мы же остановимся коротко на основных проблемах.
🔹 Первая и самая очевидная - пробелы, имя файла с пробелами превратится в набор строк, каждая из которых будет обрабатываться скриптом отдельно. И если в данном примере это относительно безопасно, то в реальных сценариях это может привести к абсолютно непредсказуемым последствиям.
Например, в нашей практике мы сталкивались со скриптом, который таким образом подсчитывал количество файлов в папке, потом сортировал их по дате создания и удалял самые старые, чтобы осталось всего N-файлов. Файл с пробелами в имени сразу грубо ломает эту логику и может привести к удалению нужных данных.
Обернуть ls *.mp4 в кавычки тоже не даст результата, так как в этом случае в качестве единой строки будет использоваться весь вывод команды.
🔹Вторая проблема – возможное наличие в имени файла управляющих и подстановочных символов. На практике встречается гораздо реже, но так как Linux вполне допускает подобные имена, то вы вполне можете с ними столкнуться, например, они могут появиться в результате ошибок в работе скриптов.
Допустим у вас есть набор файлов: 1Сезон-1Серия.mp4, 1Сезон-2Серия.mp4 и т.д. и туда случайным образом затесался файл где имя состоит из единицы и звездочки за ним. Символ звездочки будет расценен как подстановочный и ls подставит туда все попадающие под маску файлы. В результате все ваши серии попадут в вывод два раза. Как мы уже говорили, если в данном случае это безопасно, то в других сценариях может привести к различным негативным эффектам.
🔹Третья основная проблема – символы национальных алфавитов. Сейчас эта проблема отошла на второй план, но актуальной быть от этого не перестала. А причина все таже – ls и find рассчитаны на то, чтобы выводить информацию на экран.
А далее все зависит от установленной локали, если локаль не содержит символа, соответствующего его коду, то на его месте появится «крякозябкрик» или знак вопроса в ромбе, иди еще что-нибудь, а также такой символ может быть просто пропущен.
👆 Теперь о том, как сделать правильно. В оболочках POSIX, которым относится bash и его производные, есть функция позволяющая использовать в именах файлов символы подстановки, поэтому вывод никаких дополнительных команд анализировать не нужно, а переменную следует обязательно обернуть в кавычки:
for file in ./*.mp4; do
mv -f “$file” /new_path/video
done
В этом случае корректно будут отработаны и пробелы, и спецсимволы, и символы национальных алфавитов.
Также можно подстраховаться и добавить проверку на существование файла:
for file in ./*.mp4; do
[ -e "$file" ] || continue
mv -f “$file” /new_path/video
done
Если указанный файл не существует, то цикл пропустит текущую итерацию и перейдет к следующей.
👉 P.S. Почему мы заострили внимание именно на этой проблеме, а не на проверке наличия папки и наличия закрывающего слеша?
Потому что ls/find архитектурный баг скрипта, а остальное – частный случай с неправильной конфигурацией окружения.
Если Вася проследит, чтобы папка на момент запуска скрипта существовала – проблем у него не возникнет, никогда и никаких.
А вот использование ls/find для поиска файлов - это 100% проблема, заложенная архитектурно.
Если же Вася отразит в документации, мол перед запуском скрипта обязательно проверьте наличие целевой папки, то это уже будет не баг, а фича.
👍9🔥8🥱2🤡1
Gemini PRO практически даром
На рынке аккаунтов появилось интересное предложение Gemini PRO на 18 месяцев за смешные 200-300 руб. Честно. Без обмана.
Но в чем подвох, ведь не может быть все так прекрасно? А подвох в том, что это специальная акция от индийского телеком-гиганта Jio для своих пользователей. Но технически это никто не проверяет.
А продавцам это ничего не стоит, предложение бесплатное. Поэтому и цена символическая. Но тем не менее все нормально активируется и работает на текущий аккаунт, даже если у него регион отличается от Индии.
Риски? Как без них, Google может в любой момент проверить правомерность владения подпиской и заблокировать «левые» аккаунты и примеры тому уже были, не так давно массовый бан пущенных «налево» аккаунтов устраивал Perplexity.
С другой стороны, даже если и забанят – не жалко. Главное – не увлекаться, в смысле не забивать халявные 5 ТБ диска, идущие в комплекте с подпиской. А остальное некритично, можно спокойно пережить.
Как найти? На любой площадке ищем Gemini PRO на 18 месяцев. Нормальная цена 200-300 руб.
На рынке аккаунтов появилось интересное предложение Gemini PRO на 18 месяцев за смешные 200-300 руб. Честно. Без обмана.
Но в чем подвох, ведь не может быть все так прекрасно? А подвох в том, что это специальная акция от индийского телеком-гиганта Jio для своих пользователей. Но технически это никто не проверяет.
А продавцам это ничего не стоит, предложение бесплатное. Поэтому и цена символическая. Но тем не менее все нормально активируется и работает на текущий аккаунт, даже если у него регион отличается от Индии.
Риски? Как без них, Google может в любой момент проверить правомерность владения подпиской и заблокировать «левые» аккаунты и примеры тому уже были, не так давно массовый бан пущенных «налево» аккаунтов устраивал Perplexity.
С другой стороны, даже если и забанят – не жалко. Главное – не увлекаться, в смысле не забивать халявные 5 ТБ диска, идущие в комплекте с подпиской. А остальное некритично, можно спокойно пережить.
Как найти? На любой площадке ищем Gemini PRO на 18 месяцев. Нормальная цена 200-300 руб.
😁10👍7🥱1
Управляемый хаос
Много лет информационные системы строились, да и строятся, по принципу борьбы с отказами. Давайте купим «надежное» брендовое серверное железо, аппаратный RAID с батарейкой, корпус с дублирующим блоком питания и т.д. и т.п.
Все это должно уберечь нас от отказа, который в нашей парадигме – чрезвычайное происшествие со всеми вытекающими последствиями и оргвыводами.
И самое печальное в этом, что нашему брату админу тут форменный цугцванг. Чтобы ты не делал, любой твой ход только ухудшает ситуацию.
Купил недостаточно брендовое или вообще десктопное железо? А мы говорили, а мы предупреждали, надо было…
Сделал ровно наоборот? И отказ таки приключился? А теперь поясни, дорогой наш друг, ради чего мы выделили на это все такие большие деньги…
Поэтому современный подход - Design for Failure (Проектирование с расчетом на сбои) – исходит совершенно из обратных посылов. Сбои – это неотъемлемая часть нашей жизни, как природные явления за окном, бороться с ними невозможно, тем более предотвращать.
Все что может сломаться – сломается, все что может упасть – упадет, любой кто может накосячить – накосячит.
И это не выдумки теоретиков, это то, к чему пришли гиганты индустрии: Google, Facebook или Netflix. Они честно признались в том, что не могут бороться с отказами, но могут бороться с их последствиями.
Отсюда были выведены основные принципы:
🔹 Сбои неизбежны (Assume Failure): Все, что может сломаться (железо, сеть, стороннее API, человеческий фактор), обязательно сломается. Это не баг, это закон природы.
🔹 Изоляция отказов (Bulkheading): Проблема в одном модуле не должна лавинообразно уничтожать всю систему. Если «легла» рекомендательная система, корзина и оплата должны продолжать работать.
🔹 Контролируемая деградация (Graceful Degradation): Если система не может отдать пользователю идеальный результат, она должна отдать «приемлемый». Например, вместо пустой страницы показать закешированные вчерашние данные.
🔹 Автоматическое восстановление (Self-Healing): Система должна уметь сама перезапускать упавшие контейнеры, переключаться на резервные копии баз данных и отсекать проблемные узлы без звонка дежурному админу в 3 часа ночи.
И все это легко переносится на админские будни. Мы не можем обеспечить 100% надежность, брендовое железо может оказаться бракованным, аппаратный RAID развалит массив из-за бага в прошивке, ПО ляжет из-за бага в обновлении. И, наконец, добро пожаловать самая неизвестная переменная – человек, которому свойственно ошибаться.
Попытка строить системы, которые почти никогда не упадут на таком фундаменте обречены на провал. А вот исходить из того, что все упадет и сломается (или будет сломано) – трезвый современный подход.
И все инструменты для этого у администратора есть: кластеризация, HA, виртуализация и контейнеризация, распределенные хранилища, инфраструктура как код.
Да, местами сложно, местами непривычно, но именно это современное IT, с его управляемой деградацией и способностью к самовосстановлению.
Сервер СУБД сожрал всю память? Он не уронит весь стек, а просто упадет сам, а балансировщик переключит на вторую активную ноду. Сам же контейнер будет перезапущен или вообще пересоздан из эталона. И это лучше, чем слать алерт администратору в три часа ночи.
Резко выросла нагрузка? Кластер сам перераспределит нагрузку между нодами. Упала нода? Остальные подхватят упавший флаг, да сервис деградирует, но продолжит работать. Тормозит? Да! Но работает ведь! Клиенты не уходят, бизнес-процессы не останавливаются.
И админ спит ночами спокойно, упало – да и пес с ним, завтра в рабочее время разберется, нет необходимости вскакивать посреди ночи, брать такси (выпил вечером банку пива) и нестись, теряя ботинки в серверную.
Да и вообще в этой парадигме ломать полезно, у Netflix есть Chaos Monkey – специальный скрипт который в рабочее время в случайном порядке ломает ноды или виртуалки, что помогает инженерам найти слабые места в инфраструктуре и устранить их до тех пор, пока это станет проблемой.
Много лет информационные системы строились, да и строятся, по принципу борьбы с отказами. Давайте купим «надежное» брендовое серверное железо, аппаратный RAID с батарейкой, корпус с дублирующим блоком питания и т.д. и т.п.
Все это должно уберечь нас от отказа, который в нашей парадигме – чрезвычайное происшествие со всеми вытекающими последствиями и оргвыводами.
И самое печальное в этом, что нашему брату админу тут форменный цугцванг. Чтобы ты не делал, любой твой ход только ухудшает ситуацию.
Купил недостаточно брендовое или вообще десктопное железо? А мы говорили, а мы предупреждали, надо было…
Сделал ровно наоборот? И отказ таки приключился? А теперь поясни, дорогой наш друг, ради чего мы выделили на это все такие большие деньги…
Поэтому современный подход - Design for Failure (Проектирование с расчетом на сбои) – исходит совершенно из обратных посылов. Сбои – это неотъемлемая часть нашей жизни, как природные явления за окном, бороться с ними невозможно, тем более предотвращать.
Все что может сломаться – сломается, все что может упасть – упадет, любой кто может накосячить – накосячит.
И это не выдумки теоретиков, это то, к чему пришли гиганты индустрии: Google, Facebook или Netflix. Они честно признались в том, что не могут бороться с отказами, но могут бороться с их последствиями.
Отсюда были выведены основные принципы:
🔹 Сбои неизбежны (Assume Failure): Все, что может сломаться (железо, сеть, стороннее API, человеческий фактор), обязательно сломается. Это не баг, это закон природы.
🔹 Изоляция отказов (Bulkheading): Проблема в одном модуле не должна лавинообразно уничтожать всю систему. Если «легла» рекомендательная система, корзина и оплата должны продолжать работать.
🔹 Контролируемая деградация (Graceful Degradation): Если система не может отдать пользователю идеальный результат, она должна отдать «приемлемый». Например, вместо пустой страницы показать закешированные вчерашние данные.
🔹 Автоматическое восстановление (Self-Healing): Система должна уметь сама перезапускать упавшие контейнеры, переключаться на резервные копии баз данных и отсекать проблемные узлы без звонка дежурному админу в 3 часа ночи.
И все это легко переносится на админские будни. Мы не можем обеспечить 100% надежность, брендовое железо может оказаться бракованным, аппаратный RAID развалит массив из-за бага в прошивке, ПО ляжет из-за бага в обновлении. И, наконец, добро пожаловать самая неизвестная переменная – человек, которому свойственно ошибаться.
Попытка строить системы, которые почти никогда не упадут на таком фундаменте обречены на провал. А вот исходить из того, что все упадет и сломается (или будет сломано) – трезвый современный подход.
И все инструменты для этого у администратора есть: кластеризация, HA, виртуализация и контейнеризация, распределенные хранилища, инфраструктура как код.
Да, местами сложно, местами непривычно, но именно это современное IT, с его управляемой деградацией и способностью к самовосстановлению.
Сервер СУБД сожрал всю память? Он не уронит весь стек, а просто упадет сам, а балансировщик переключит на вторую активную ноду. Сам же контейнер будет перезапущен или вообще пересоздан из эталона. И это лучше, чем слать алерт администратору в три часа ночи.
Резко выросла нагрузка? Кластер сам перераспределит нагрузку между нодами. Упала нода? Остальные подхватят упавший флаг, да сервис деградирует, но продолжит работать. Тормозит? Да! Но работает ведь! Клиенты не уходят, бизнес-процессы не останавливаются.
И админ спит ночами спокойно, упало – да и пес с ним, завтра в рабочее время разберется, нет необходимости вскакивать посреди ночи, брать такси (выпил вечером банку пива) и нестись, теряя ботинки в серверную.
Да и вообще в этой парадигме ломать полезно, у Netflix есть Chaos Monkey – специальный скрипт который в рабочее время в случайном порядке ломает ноды или виртуалки, что помогает инженерам найти слабые места в инфраструктуре и устранить их до тех пор, пока это станет проблемой.
👍27❤1
Лог включен, но мало помогает
Именно такой ответ мы получили на предложение одному из наших читателей включить лог, чтобы он помог разобраться в проблеме.
И, к сожалению, подобные отзывы не единичны. Многие считают, что лог должен… А вот что он должен?
А лог не должен никому и ничего, это записи состояний и событий системы, которые могут оказаться вам полезны, а могут быть полностью бесполезными.
Почему так? Начнем с самого лога. Чтобы лог приносил пользу – он должен содержать записи об интересующих нас событиях. А для этого нужно правильно настроить подробность лога.
Многие системы по умолчанию записывают в лог только ошибки и предупреждения, отладочной информации в них нет. Поэтому, если нам не хватает информации – увеличиваем подробность лога.
Другая ошибка – излишние подробности, в этом случае вы просто тонете в малозначительных записях и можете пропустить действительно важное событие или не сможете провести причинно-следственные связи между несколькими событиями. В этом случае нужно наоборот уменьшить подробность логирования.
Еще одна классическая ошибка – смотрим не туда. Чаще всего это связано с тем, что «ошибка» в понимании пользователя не является ошибкой для сервиса и соответственно вы не увидите никакой записи об ошибке в таком случае.
Характерный пример – это состояния HTTP, многие из которых воспринимаются клиентом именно как ошибки. Но для самой системы это вполне допустимые и документированные состояния, которые являются частью штатного рабочего процесса.
В результате получается, что мы ищем то, чего нет. Поэтому не следует ограничивать себя каким-то фильтром или иным отбором по некоторым условиям, которые могут не совсем соответствовать или совсем не соответствовать реальной ситуации.
Поэтому, если в логе тишина, то это не значит, что лог плохой или сервис работает неправильно, а значит, что вы, скорее всего, не туда смотрите.
А смотреть надо в корень – на событие, которое должно вызвать реакцию сервиса. И начинать плясать от печки, т.е. от той системы – которое это событие инициализировала, а не от той, которая должна обработать.
Это позволяет быстро и эффективно выявить ситуации, когда мы обращаемся не туда или не так. Например, как это часто бывает, ваши запросы блокируются брандмауэром, а вы пытаетесь безрезультатно терзать веб-сервер.
Поэтому всегда нужно двигаться от источника события к результату, от локальной системы к удаленной, но не наоборот.
А еще – логи нужно уметь читать. Мы сейчас не будем брать во внимание крайний случай, когда квалификации явно недостаточно и все написанное в логе является «китайской грамотой».
Очень часто при анализе логов коллеги зацикливаются именно на самом событии и пытаются искать именно его описание, часто безрезультатно, но совершенно не обращают внимание на контекст, а ведь именно контекст определяет смысл происходящих событий.
Иногда достаточно промотать десяток строк вверх или вниз от события, чтобы понять, что именно на самом деле происходило в системе. И именно для этого бывает нужно увеличить подробности лога.
Но даже если в логе нет прямых указаний, то всегда следует обращать внимание на повторяющиеся события. Если у вас перед ошибкой раз за разом происходят еще некоторые действия – то именно они могут служить причиной ошибки и заслуживают самого пристального внимания, даже если на первый взгляд с ошибкой никак не связаны.
И помните, сам себя лог не прочитает и его отсутствие или наличие никак на работу системы не влияет. Лог нужен именно вам и нужен для того, чтобы вдумчиво его читать и анализировать. Также вы должны хотя бы в общих чертах понимать, что там написано и как вообще вся эта система работает.
Да, сегодня у нас есть неплохой помощник в виде ИИ, но без самостоятельного понимания он может направить вас на неверный путь, особенно если вы «скормите» ему не ту часть лога или начнете задавать не те вопросы.
Поэтому просто включить лог – это мало, нужно понимать что именно вы хотите в нем увидеть и почему именно в нем.
Именно такой ответ мы получили на предложение одному из наших читателей включить лог, чтобы он помог разобраться в проблеме.
И, к сожалению, подобные отзывы не единичны. Многие считают, что лог должен… А вот что он должен?
А лог не должен никому и ничего, это записи состояний и событий системы, которые могут оказаться вам полезны, а могут быть полностью бесполезными.
Почему так? Начнем с самого лога. Чтобы лог приносил пользу – он должен содержать записи об интересующих нас событиях. А для этого нужно правильно настроить подробность лога.
Многие системы по умолчанию записывают в лог только ошибки и предупреждения, отладочной информации в них нет. Поэтому, если нам не хватает информации – увеличиваем подробность лога.
Другая ошибка – излишние подробности, в этом случае вы просто тонете в малозначительных записях и можете пропустить действительно важное событие или не сможете провести причинно-следственные связи между несколькими событиями. В этом случае нужно наоборот уменьшить подробность логирования.
Еще одна классическая ошибка – смотрим не туда. Чаще всего это связано с тем, что «ошибка» в понимании пользователя не является ошибкой для сервиса и соответственно вы не увидите никакой записи об ошибке в таком случае.
Характерный пример – это состояния HTTP, многие из которых воспринимаются клиентом именно как ошибки. Но для самой системы это вполне допустимые и документированные состояния, которые являются частью штатного рабочего процесса.
В результате получается, что мы ищем то, чего нет. Поэтому не следует ограничивать себя каким-то фильтром или иным отбором по некоторым условиям, которые могут не совсем соответствовать или совсем не соответствовать реальной ситуации.
Поэтому, если в логе тишина, то это не значит, что лог плохой или сервис работает неправильно, а значит, что вы, скорее всего, не туда смотрите.
А смотреть надо в корень – на событие, которое должно вызвать реакцию сервиса. И начинать плясать от печки, т.е. от той системы – которое это событие инициализировала, а не от той, которая должна обработать.
Это позволяет быстро и эффективно выявить ситуации, когда мы обращаемся не туда или не так. Например, как это часто бывает, ваши запросы блокируются брандмауэром, а вы пытаетесь безрезультатно терзать веб-сервер.
Поэтому всегда нужно двигаться от источника события к результату, от локальной системы к удаленной, но не наоборот.
А еще – логи нужно уметь читать. Мы сейчас не будем брать во внимание крайний случай, когда квалификации явно недостаточно и все написанное в логе является «китайской грамотой».
Очень часто при анализе логов коллеги зацикливаются именно на самом событии и пытаются искать именно его описание, часто безрезультатно, но совершенно не обращают внимание на контекст, а ведь именно контекст определяет смысл происходящих событий.
Иногда достаточно промотать десяток строк вверх или вниз от события, чтобы понять, что именно на самом деле происходило в системе. И именно для этого бывает нужно увеличить подробности лога.
Но даже если в логе нет прямых указаний, то всегда следует обращать внимание на повторяющиеся события. Если у вас перед ошибкой раз за разом происходят еще некоторые действия – то именно они могут служить причиной ошибки и заслуживают самого пристального внимания, даже если на первый взгляд с ошибкой никак не связаны.
И помните, сам себя лог не прочитает и его отсутствие или наличие никак на работу системы не влияет. Лог нужен именно вам и нужен для того, чтобы вдумчиво его читать и анализировать. Также вы должны хотя бы в общих чертах понимать, что там написано и как вообще вся эта система работает.
Да, сегодня у нас есть неплохой помощник в виде ИИ, но без самостоятельного понимания он может направить вас на неверный путь, особенно если вы «скормите» ему не ту часть лога или начнете задавать не те вопросы.
Поэтому просто включить лог – это мало, нужно понимать что именно вы хотите в нем увидеть и почему именно в нем.
👍11❤2👌2🥱1