почему меня блокирует cloudflare
Плохая доступность сайтов на Cloudflare в России, в связи с блокировкой IP сервиса Роскомнадзором
moder
Администратор
Cloudflare это CDN сервис, предоставляющий бесплатную защиту от ддос-атак и много других полезных функций. Cloudflare не реагирует на абузы Роскомнадзора, соответственно, общие IP Cloudflare попадают в реестр вместе с доменами.
Проблема возникла после блокировки Telegram, когда Дуров, для поддержания работы мессенджера в России, стал использовать различные прокси-сервисы, в т.ч. Cloudflare. Тогда, в разгар противостояния, Роскомнадзор заблокировал половину Интернета. С тех пор большинство IP, попавших под замес, удалили, но какая-то часть до сих пор в реестре, даже спустя 1,5 года.
Вот список IP Cloudflare, внесенных в реестр в целях блокировки web-сервисов Telegram (решение 27-31-2018/Ид2971-18).
Нахождение IP вашего домена в этом перечне означает, что у многих российских пользователей ваш сайт не открывается. Проверить доступность сайта можно через сервис https://ping-admin.ru/index.sema.
Как решить проблему?
Если вам Cloudflare нужен только для защиты от ддос атак, то можно просто отключить проксирование и включать его по мере необходимости.
Для этого зайдите в раздел DNS. И кликните по облачку.
Если вам нужен CDN постоянно, тогда потребуется смена IP.
Как сменить IP на Cloudflare
Как вариант, можно удалить сайт временно из Cloudflare и добавить его позже. Если вы просто удалите сайт из одного аккаунта и добавите в другой, без смены ns, с высокой вероятностью за вами останется тот же IP. Нужно какое-то время погонять сайт без Cloudflare.
После получения нового IP, еще раз проверьте доступность сайта.
Чтобы повысить шанс получить не заблокированный IP, есть одна маленькая хитрость.
CloudFlare — рак интернета
Когда CloudFlare только появился, это была настоящая революция в веб-хостинге: в два клика, без переезда на другой сервер, к своему сайту можно было подключить профессиональный CDN(Сеть доставки содержимого — географически распределённая сетевая инфраструктура, позволяющая оптимизировать доставку и дистрибуцию содержимого конечным пользователям в сети Интернет), который экономил кучу трафика, ускорял загрузку статических файлов и еще защищал от DDoS. Раньше позволить себе такое могли только компании за большие деньги, а теперь это стало доступно каждому, еще и бесплатно!
Дисклеймер: я сам много пользуюсь CloudFlare и считаю, что они делают большое дело, помогают развивать интернет, дают бесплатно крутые продукты, и в целом отличные ребята. Статья описывает проблемы глобализации и новые угрозы, когда децентрализованный интернет становится централизованным.
С тех пор CloudFlare сильно вырос и сегодня проксирует через свою инфраструктуру треть интернета. Из-за этого появились проблемы, которых раньше не существовало. В посте мы разберем, как CloudFlare угрожает нормальной работе интернета, мешает обычным людям пользоваться сайтами, имеет доступ к зашифрованному трафику, и что с этим делать.
Как сломать треть интернета
В прошлом году, 2 июля 2019 года в результате ошибки CloudFlare полностью сломался. В результате были недоступны все сервисы, так или иначе использующие их сеть. Среди наиболее известных: Discord, Reddit, Twitch. Это коснулось не только веб-сайтов, но и игр, мобильных приложений, терминалов и т.д. При этом, даже те сервисы, которые не используют напрямую CloudFlare, испытали проблемы в работе из-за сторонних API, которые стали недоступны.
В большинстве случаев, для использования CloudFlare, клиенты направляют свои домены на их DNS-серверы. В момент аварии стала недоступна также и контрольная панель и API, из-за чего клиенты не могли перенаправить свои домены в обход сети CloudFlare, таким образом оказавшись в ловушке: нельзя было оперативно отключить проксирование и вернуться на свою инфраструктуру. Единственным выходом было делегировать домен на свои собственные DNS-серверы, но такое обновление могло занять более суток, и большинство клиентов не были к такому готовы и не имели запасных мастер-DNS серверов на такой случай.
Несмотря на то, что даунтайм был небольшим, всего несколько часов, это существенно сказалось на всей индустрии. Из-за неработающих платежных сервисов компании несли прямые убытки. Этот инцидент вскрыл очевидную проблему, которая до этого обсуждалась только в теории: если интернет настолько зависим от одного поставщика услуг, в какой-то момент все может сломаться.
Если одна компания контролирует такую большую часть интернета, это угрожает устойчивости сети как с технической стороны, так и с экономической.
Сама концепция интернета предполагает децентрализацию и устойчивость к подобным ошибкам. Даже в случае отключения части сети, система маршрутизации автоматически перестраивается. Но когда одна компания управляет такой большой частью трафика, сеть становится уязвима перед ее ошибками, саботажем, взломами, а так же недобросовестными действиями для извлечения прибыли. Эта идея важна для понимания остальных проблем, которые мы обсудим далее.
Вы выглядите подозрительно
Если фирменные алгоритмы определения вредоносного трафика CloudFlare сочтут, что вы недостойный пользователь интернета, веб-серфинг превратится в мучение: на каждом пятом сайте вы будете видеть требования пройти унизительную капчу.
Автор этих строк выходит в интернет с офисного IP-адреса, за которым сидят сотни других сотрудников. Видимо CloudFlare посчитал, что мы все выглядим как боты, и стал показывать всем очень злую капчу. Иногда это доходит до абсурда, когда некоторые мобильные приложения не могут залогиниться. В итоге, чтобы нормально ходить по интернету, приходится подключать VPN.
Получается, CloudFlare в любой момент может отключить вас лично от большой части интернета, если вы ей не понравитесь, или из-за ошибочного детектирования превратить обычное использование сервисов в мучение.
Мы можем видеть сквозь HTTPS
Чтобы правильно кешировать и фильтровать контент, серверы CloudFlare должны иметь возможность видеть расшифрованный HTTP трафик. Для этого они всегда работают в режиме MiTM (Man-in-the-middle), подставляя конечному посетителю сайта свой SSL-сертификат.
Картинки в инструкциях по настройке HTTPS могут вводить в заблуждение, будто в режиме Full, на всем пути следования трафика используется шифрование. На самом деле сервер CloudFlare расшифровывает трафик от сервера и шифрует его заново своим сертификатом уже для посетителя сайта.
Даже если вы имеете на своей стороне действующий SSL-сертификат, CloudFlare все равно будет иметь доступ ко всем передаваемым данным. Это дискредитирует всю идею SSL, которая предполагает шифрование от клиента до конечного сервера без расшифровки по пути.
Также нужно иметь в виду, что спецслужбы той страны, в юрисдикции которой работает компания Cloudflare Inc, могут запрашивать доступ к расшифрованному трафику, даже если оригинальный сервер находится в другой юрисдикции. Это превращает основную идею SSL в фикцию.
Не только инфраструктура, но и цензура
Изначально, компания Cloudflare заявляла, что будет только предоставлять инфраструктуру для клиентов и не планирует цензурировать ресурсы по содержимому, обещая ограничиваться только законными требования от государственных органов. Так было с сайтом знаменитой группировки LulzSec, которые координировали взломы и DDoS-атаки. По этому поводу Cloudflare выпустили заявление.
Однако спустя время, Cloudflare решает отказать сайту 8chan в обслуживании на основании своих представлений о морали. При этом никаких судебных решений или иных формальных причин для этого не было — просто они так решили. Это вызвало общественную дискуссию о том, может ли провайдер сам решать, какой сервис достоин обслуживаться на его инфраструктуре, а какой нет. Статья с размышлениями на эту тему в New York Times: Why Banning 8chan Was So Hard for Cloudflare: ‘No One Should Have That Power’.
Несмотря на то, что Cloudflare невероятно полезный сервис и помогает значительно ускорить доставку контента, а так же развивает интернет, его опасный рост и грядущая монополия угрожает устойчивости всего интернета. Попробуем резюмировать все вышесказанное в простых тезисах:
1. Нельзя хранить все яйца в одной корзине. Это просто небезопасно, цена ошибки в таком случае слишком высока. Если все секреты мира будут у одной компании, она всегда может быть взломана, допустить ошибку или просто действовать нечестно для выдавливания конкурентов с рынка.
2. Коммерческая компания всегда заинтересована в одном — зарабатывании денег. Если ключевые элементы узлы интернета захватит одна компания, она сможет монопольно управлять ценами на услуги, уничтожать конкурентов и диктовать свои правила, задавливая конкурентов в зачатке.
3. SSL больше не защищает данные от третьих лиц. Все ваши шифрованные данные, передаваемые по сети Cloudflare, доступны этому самому третьем лицу — CloudFlare. Это дает неограниченный доступ к чувствительным данным миллионов пользователей.
Данный пост не призывает отказываться от Cloudflare, а только описывает, чем в перспективе угрожает такой бурный рост и влияние этой компании. Подумайте, действительно ли использование Cloudflare необходимо для ваших задач, и если без него никак, предусмотрите план Б, на случай экстренного переезда.
Лига Сисадминов
655 постов 12.3K подписчиков
Правила сообщества
— # mount /dev/good_story /sysodmins_league
— # mount /dev/photo_it /sysodmins_league
— # mount /dev/best_practice /sysodmins_league
— # mount /dev/tutorial /sysodmins_league
И главная беда в том, что у них действительно хороший сервис. Из-за этого они стали популярны настолько, что завязали на себя огромную часть интернета. И в случае любого выхода из строя какого-то их сервиса, что бывает весьма часто в столь крупных и сложных проектах, во всей мировой сети могут быть проблемы.
В офисе случаем СБ не использует какой нибудь израильский софт? Там трафик сканится и тоже mitm. Поэтому CF и капчит.
а как узнать юзает ли сервис Cloudflare? отдам я ему свои персональные данные или нет.
Еще у провайдеров может быть установка, типа прослушивать трафик с тех же IP адресов, и они начинают впихивать свой ssl сертификат, короче дичь.
Клон клона статьи с хабра
Представьте что существует море компаний управление серверами которых отдано на аутсорс, и о ужас, все их данные, абсолютно все(а не только какой-то там сайтик) доступны третьим лицам с неограниченным доступом, живите теперь с этим.
Это вызвало общественную дискуссию о том
С Днем системного администратора!
Для меня самого сегодняшний праздник оставался незамеченным до первого поздравления. Вот так внезапно наступила последняя пятница июля, когда по традиции отмечается День системного администратора.
«Эталонных», стереотипных админов с бородой, пузом и пивом наперевес остается все меньше, границы профессии расширяются, специализаций становится всё больше, так хочу поздравить всех админов, девопсов, эникеев и всех-всех причастных к стабильному функционированию компов, серверов и сервисов с профессиональным праздником!
Ну и грех будет не запилить этот мувик про сисадмина 2008 года
про баян помню, но для данного сообщества норм)
Только начал изучать
Как мое рабочее место менялось с годами
в разное время рабочее место может выглядеть по разному.
у меня как то так менялось с годами )))
Как переставить жесткий диск с Windows на борту в новое железо, не переустанавливая систему
Все дело в том, что при установке Винда создает временные файлы, заполняет системный журнал событий и ставит драйвера комплектующих под текущее железо. При перестановке диска в другой компьютер, с отличным от первого железом, система, проще говоря, не поймет как ей работать с новым оборудованием, т.к. настроена для работы с другими комплектующими. То есть, в теории (да и на практике), системный диск можно переставлять из одного компьютера в другой, при абсолютной идентичности оных: одинаковая материнка, одинаковый проц и т.п.
Логичный вывод: нужно каким-то образом «сбросить» уже установленные драйвера и конфигурации. Для этого существует безмерное количество различного софта, но в этом посте я расскажу про встроенную утилиту «sysprep».
Утилита позволяет очистить журнал событий, временные файлы, сбросить драйвера устройств и активацию(!) системы, не удаляя пользовательские файлы и программы.
Находится по адресу C:\Windows\system32\sysprep\sysprep.exe
Вызвать можно двумя способами:
1. Зайти по указанному выше адресу, и запустить вручную
2. Нажать сочетание клавиш Win + R и в открывшемся окне ввести sysprep. (бм ругается на скрин :D)
Здесь предстоит выбрать параметры отвязки системы от железа.
Для переноса системы на другую машину, выбираем «Переход в окно приветствия», ставим галочку напротив пункта «Подготовка к использованию» и в параметрах завершения работы указываем «Завершение работы». Это важно, так как, например, при выборе «Перезагрузка», по завершению сброса системы, компьютер, что логично, перезагрузится, подсосав драйвера для этого же железа после загрузки.
В итоге должно получиться следующее:
Нажимаем «Ок» и ждем завершения работы утилиты
По завершению, компьютер отключится. Ни в коем случае не включайте его, ибо, в таком случае, всю процедуру придется проводить заново.
Теперь можно переставлять диск в новый комп.
При первой загрузке, винда откроет окно первичной настройки, как при установке. Не пугаемся, просто выбираем нужные пункты и жмем «Да», «Далее» и т.д.
При первичной настройке нужно создать нового пользователя для входа в систему. После завершения всех настроек, его можно будет удалить. Для Windows 10 советую создавать локального пользователя, без подключения к аккаунтам Microsoft, если есть такая возможность (зависит от дистрибутива).
Также, не забываем про то, что sysprep сносит активацию системы. Так что после загрузки ее придется активировать заново.
4. Сфера применения
1. Перенос диска с компьютера на компьютер, как описано выше.
2. Создание бекапа системы и файлов (большинство бесплатных бекап-софтин пляшут от аналогичного скрипта действий)
3. Создание корпоративного дистрибутива с предустановленными программами для установки на офисные машины. Полезно для админов, если нет централизованной системы управления конфигурациями.
Пост адресован начинающим администраторам и обычным пользователям, оказавшимся в ситуации, схожей с Васиной из начала поста.
UPD. Многие говорят что десятка сама прекрасно умеет подсасывать драйвера на новые компоненты. Отчасти это правда, зачастую так и происходит и статья больше относится к Win 7 и 8.1, однако и с десяткой раз на раз не приходится, имею горький опыт.
Вопросы с собеседований по Linux
Какие вопросы вам задавали на собеседованиях на должность линукс админа, помощника админа и т.п., всё что связано с линуксами?
Собираю базу вопросов с собеседований, думаю, будет полезно новичкам, да и в целом интересно почитать. Вопросы выложу в открытый доступ по ссылке. Просьба также указывать должность, на которую подавали.
Отказы ИС 0.Twilio и Redis
Введение. В IT существует такое понятие как post-mortem, обозначающее исследование, проводимое с целью выявления причин возникновения проблемы и недопущения их в будущем. В результате такого анализа IT-специалисты формируют post-mortem отчет, некоторые из которых выкладываются в открытый доступ.
В серии постов (если, конечно, она получится) планируется краткое изложение некоторых из подобных отчетов.
Сразу оговорюсь, что посты пишутся в свободное время, поэтому не ругайте сильно за ожидаемую их нерегулярность.
В качестве первого отчета выбран отчет компании Twilio (занимается предоставлением различных программных сервисов, в т.ч. автоматизированной отправки sms-сообщений и телефонных звонков). Отчет представлен на сайте компании и датируется 23 июля 2013 года.
Сам инцидент возник 18 июля 2013 и затронул 1,4; пользователей компании и заключался в следующем:
— во время инцидента при оплате с банковских карт в пользу Twilio пользователи не видели соответствующих изменений на своем балансовом счете;
— автоплатежи выполнялись несколько раз (так как баланс клиента в Twilio не обновлялся после оплаты);
— часть учетных записей были заблокированы из-за деактивации банковских карт, связанной с повторяющимся списанием средств;
— отчеты об использовании сервисов не доставлялись клиентам из-за того, что что биллинговая система (система выставления счетов) находилась в режиме оффлайн.
18.07.2013 08:35 UTC: из-за обрыва сетевого соединения с ведущим (master) узлом ведомые узлы выполнили переподключение и запустили процесс полной синхронизации одновременно.
18.07.2013 09:39 UTC: сервисы, использующие ведущий узел, начали отказывать из-за повышенной нагрузки на него.
18.07.2013 09:42 UTC: redis-master был перезапущен для того, чтобы справиться с нагрузкой.
18.07.2013 10:28 UTC: системы мониторинга Twilio зафиксировали аномалию в системе выставления счетов (ошибки платежей по картам и блокировки учетных записей пользователей). Затронуто было 1.1% пользователей. Проблемой начала заниматься дежурная команда инженеров.
18.07.2013 11:10 UTC: биллинговая система была отключена для избежания дальнейших ошибок обработки банковских карт.
18.07.2013 13:24 UTC: были разблокированы все затронутые учетные записи. Система выставления счетов оставалась в режиме оффлайн пока специалисты занимались поиском основной причины ошибки.
18.07.2013 18:58 UTC: биллинговая система была включена.
18.07.2013 21:57 UTC: Twilio начал возврат денежных средств. Работа по возврату заняла следующие 24 часа.
19.07.2013 22:00 UTC: возврат ден. средств был завершен.
19.07.2013 22:30 UTC: всем затронутым учетным записям на счет было зачислена сумма в размере 10% от их трат за последние 30 работы в сервисе.
20.07.2013 02:30 UTC: система выставления счетов запускалась постепенно для учетных записей, разделенных на группы.
20.07.2013 03:14 UTC: биллинговая система была запущена для всех групп пользователей (процесс запуска был завершен).
20.07.2013 04:15 UTC: работоспособность всех систем была восстановлена.
Основная причина. Twilio использует СУБД Redis для хранения баланса учетных записей. Кластер реализован на одном ведущем (master) и нескольким ведомым (slave) узлам, распределенным по разным ЦОД. Обрыв соединения 18.07.2013 08:35 UTC привел к значительному падению производительности Redis и возникновению тайм-аутов взаимодействия между ведомыми и ведущими узлами. Деградация была настолько значительной, что связанные сервисы начали отказывать.
Дежурная группа из-за высокой нагрузки на кластер Redis приняла ошибочное решение о необходимости его перезагрузки, так как она привела к чтению ошибочного файла конфигурации. Из-за ошибки конфигурационного файла Redis принял решение выполнить восстановление из AOL файла (файл, содержащий лог всех операций), которого не существовало, вместо использования бинарного снимка файловой системы (snapshot). В связи с этим Redis удалил все сведения о балансе учетных записей. Кроме того некорректная конфигурация привела к тому, что Redis сам запустился в режиме ведомого (slave) узла, что привело к его работе в режиме «только на чтение» и не давало биллинговой системе изменять сведения о балансе учетных записей.
У учетных записей с небольшим балансом и подключенными автоплатежами после выполнения платной операции производилось автоматическое списание ден. средств с привязанных банковских карт.
Состояние счетов хранится в двух независимых реляционных базах даннных. Эти сведения впоследствии использовались для восстановления корректного состояния баланса на учетных записях.
После восстановления состояния счетов биллинговая система была запущена, но системы мониторинга опять сообщали об ошибках. В связи с этим система была остановлена вновь и далее запускалась уже по частям для разных групп пользователей.
Что было сделано. В процессе решения проблемы кластер Redis был полностью заменен. Ошибка в конфигурационном файле была выявлена и поправлена. Во избежание проблем в будущем практика перезагрузки ведущего узла Redis была прекращена. Теперь он заменяется одним из ведомых узлов.
Потеря сведений о платежах также была признана ошибочной в системе автоплатежей. Ее отказ был высокорисковым, приводящим к неверным платежам клиентов и блокировкам их учетных записей. Теперь в случае, если счета клиентов не существуют или не могут быть изменены система не выполняет списаний и не блокирует учетные записи. Кроме того биллинговая система теперь сверяется также с бухгалтерскими базами данных в реальном времени.
Только треть поисковых запросов в Google приводит к переходу на сайт — юзерам достаточно тех данных, которые даёт сам Google
Притом, на мобильных устройствах эта цифра и того меньше — пользователи переходят на сайты всего лишь в 22% случаев.
Это значит, что созданная за 30 лет поисковая экосистема, приводящим к росту посещений вашего сайта, больше не работает. А Google наращивает мощь не только как поисковик, но и как платформа, агрегирующая контент.
И самое главное: пользователям это нравится.
Тест на применение черепичной записи (SMR) в жестком диске
Кратко о том, что такое SMR и почему о применении этой технологии в жестком диске полезно знать
Преимущество технологии черепичной записи (Shingled Magnetic Recording, SMR) по сравнению с традиционной (Conventional Magnetic Recording, CMR) в том, что благодаря частичному наложению друг на друга, можно сделать ширину трека меньше, при той же ширине головки записи. Что позволяет разместить больше треков на пластине, повысив тем самым плотность записи.
Недостаток же SMR в том, что в процессе записи уничтожаются данные на соседнем, следующем за записываемым треком. Поэтому требуется перезаписывать и соседний трек тоже. Но при этом потребуется перезаписать данные уже на следующем треке. И так далее.
Для того, чтобы не пришлось перезаписывать весь диск до конца, «черепичные» треки разбиваются на группы, называемые лентами. При этом на современных SMR дисках механизм позиционирования не обладает достаточной точностью для того, чтобы обеспечить частичную перезапись ленты. Лента записывается только целиком, сразу от начала до конца.
Также пластины SMR дисков содержат и «обычные» треки, которые используются для кэширования данных в процессе записи лент. Эти треки размещаются в отдельных, выделенных для этих целей областях, часто между лентами.
В процессе работы диск сначала пишет данные в кэш, на обычные треки. И пока кэш не заполнен, скорость записи сравнима с таковой для CMR дисков. Потому что при этом и происходит обычная запись. Затем устройство в фоновом режиме раскладывает данные по лентам.
Таким образом, для обновления данных в конкретном секторе жесткому диску с технологией SMR может потребоваться выполнить объём записи во много раз превышающий таковой для CMR диска в аналогичной ситуации.
Пока кэш не заполнен полностью, SMR диск будет вести себя вполне пристойно. Но после заполнения, что может запросто происходить при определённых сценариях использования, произойдёт многократное падение скорости записи.
Поэтому, если ваши планы включают в себя большие объёмы нелинейной записи, совершенно точно стоит для их осуществления использовать CMR диск а не SMR.
Как узнать, какая технология записи используется в жестком диске
До недавнего времени все производители за исключением Toshiba скрывали использование технологии SMR в своих устройствах. Она не упоминалось в описаниях моделей и не обозначалась предназначенным для этой цели стандартом битом в паспорте накопителя.
После ряда скандалов Seagate и WDC начали публиковать списки накопителей, в которых иcпользуется технология SMR. Также в сети можно подобные списки составленные независимыми от производителей людьми.
Тем не менее, эта характеристика до сих пор не указывается в описании устройств при их продаже в онлайн и офлайн магазинах. По крайней мере, я этого нигде не видел.
Таким образом, если вы обдумываете покупку конкретной модели жесткого диска, то ищите упомянутые выше списки, вбив в поисковую строку «smr drive list» или «список SMR дисков».
Если же устройство уже попало к вам в руки, то тут способа определения три:
• На устройствах нарушающих стандарт и скрывающих применение SMR, утилита R.tester умеет определять использование этой технологии на основе определения вендор-семейства и знаний об их особенностях.
• Тесты чтения-записи с должным образом подобранными параметрами наглядно выявляют использование SMR. И иллюстрируют причины нередкого возмущения владельцев подобных устройств.
Далее о каждом из этих способов подробнее.
Для дисков Toshiba
На жестких дисках с SMR установлены соответствующие биты в паспорте накопителя, как и положено в соответствии с АТА-стандартом.
Определение использования SMR по вендор-семействам
Паспорт можно смотреть чем угодно. По вендор-семействам наличие SMR, на сколько мне известно, сейчас умеет определять только R.tester.
Тесты жесткого диска SMR и сравнение с CMR накопителем
Если диск заполнен информацией частично, то определить использование SMR можно даже с помощью теста чтения.
Благодаря особенности работы прошивки, на данный момент характерной только для SMR устройств. Микропрограмма знает какие из секторов пустые и даже не пытается их читать, сразу отдавая нули в ответ на запрос чтения. Чтение с поверхности пластины при этом не выполняется. Вот так в результате выглядит график чтения до середины SMR диска, заполненного данными на четверть:
Наиболее наглядным тестом записи будет такой вариант, при котором кэш заполняется максимально быстро, а его раскладывание по лентам потребует записи в разные ленты.
Предполагаю, что для большинства моделей SMR дисков и способов подключения к компьютеру, таким способом будет случайная запись блоками размером в 2048 секторов.
Если заменить случайную запись на линейную с прыжками и подобрать размер прыжков таким образом, чтобы попадать в каждую ленту один-два раза, кэш будет заполняться с той же скоростью, но результат будет более наглядным. Так как ось адреса на графике будет одновременно являться осью времени, хоть и в нелинейном масштабе.
В качестве характерного размера ленты можно ориентироваться на 524288 блоков. Это число я и использовал в качестве размера прыжка в настройках теста.
По итогу выполнения большого количества тестов SMR дисков могу сказать, что формы графиков могут отличаться достаточно сильно. Даже для одного конкретного экземпляра диска. Причём очень сильно влияют даже такие казалось бы малозначительные вещи как отступ от нулевого LBA перед началом записи. Не говоря уже о заполненности кэша перед началом записи, распределении данных по диску и особенностей работы конкретных моделей.
Тем не менее, одного взгляда на результаты теста SMR диска, в сравнении с результатами CМR, вам будет достаточно для того, чтобы понять что за устройство перед вами.
Диск исправен. За все три цикла записи пишется всего порядка 30 Гигабайт. Обратите внимание на катастрофическое падение скорости записи.
Теперь другая модель, снова одинаковые параметры тестов:
Почему я написал о том, что конкретная форма графика в данном случае не важна? Потому что всё равно сразу понятно кто есть кто, если знать как должен выглядеть график для исправного CMR диска:
Фоновый процесс раскладывания кэша по лентам влияет на производительность устройства в целом, не только скорость записи. Даже скорость чтения падает. Вот тест чтения, который был выполнен сразу после записи в одном наборе тестов:
Такие тесты также можно использовать для определения использования SMR.
Мой коллега сделал видеоролик на тему тестирования SMR дисков. Он получился достаточно коряво, но было решено что лучше выложить сейчас как есть, поскольку перспектива появления улучшенной версии с нашими навыками видеоблогинга выглядела сомнительной.
Русская смекалка
Есть у меня один клиент из России. Переехал в Испанию, работает уже несколько лет в сфере IT в одной крупной европейской компании.
По итогу клиенту надоело это дело и он просто взял и написал код для сайта, на что потратил около 5 часов времени. Зато когда поставил «бот систему», то уже через 8 часов была взята запись на приём. Ибо зачем самому сидеть тыкаться, когда можно просто заставить это ловить алгоритмы. Сам я не программист и не рублю в терминах, но попытался объяснить весь великолепный лайфхак.
Если бы не он, то дальше так же бы сидели и в ручную тыкались в этих испанских правительственных «говносайтах» тормозящих вечно. Теперь одной проблемой меньше.
Русская смекалка в действии))) Памятник человеку надо за такое поставить!)
Последствия дефолтных паролей на боевом сайте
Никогда не оставляйте дефолтные/распространенные пароли от админки на боевом сайт.
Панические атаки, антидепрессанты и обучение по 16 часов в день. Как я пытаюсь стать программистом
Интернет пестрит рекламными баннерами в духе «Изучи programmingLanguageName (подставьте название любого популярного языка) с нуля за 3 месяца и устройся на работу с зп от 100 000 вечнодеревянных». Предложение, конечно, заманчивое, но вряд ли осуществимое на практике для среднего человека без опыта разработки и не являющегося гением. Попытаюсь рассказать о своём пути в IT.
Программирование я открыл для себя совершенно случайно. Началось всё с того, что полтора года назад мне пришлось кое-что поправить в HTML разметке сайта компании в которой я на тот момент работал. С помощью Гугла удалось решить эту задачу. HTML мне показался весьма интересной штукой, к тому же я узнал, что существует ещё более интересный CSS. На Ютубе были найдены видео с вёрсткой примитивных лендингов. Сначала я тупо повторял за спикером и параллельно гуглил все непонятные моменты, потом начал верстать самостоятельно. Через пару месяцев пришло время JavaScript. Идея обучаться на платных курсах была отброшена почти сразу по нескольким причинам: 1. Множество негативных комментариев от программистов о качестве выпускников таких курсов. 2. Все платные курсы открывают часть уроков, чтобы заманить клиентов. Меня не удовлетворила полнота информации, предоставляемая в бесплатных уроках. 3. Не было цели как можно быстрее получить работу. Мне просто нравилось учить JS.
На данный момент прошло 1,5 года с момента, как я впервые встретился с HTML. До сих пор не получилось устроиться на работу. Программирование мне очень нравится и, думаю, что я его не брошу, даже если ничего не выйдет с работой. Идея окунуться в омут с головой, не имея солидной финансовой подушки, была весьма авантюрной. О решении не идти на платные курсы, готовящие профессиональных разработчиков за срок от недели до 3 месяцев не жалею, поскольку до сих пор не вижу их преимуществ перед самообучением.