​​Стоимость хранения данных на SSD и HDD

В комментариях к вчерашней заметке нам обратили внимание на то, что мы не учитываем разную стоимость хранения. А это тоже вопрос достаточно интересный. Поэтому мы сегодня провели небольшое исследование.

Мы взяли актуальный прайс известного всем магазина из трех букв и посчитали среднюю стоимость хранения 1 ГБ опираясь на массовый сегмент устройств, т.е. не беря в учет дорогие модели, а также отбросили самые дешевые.

Результат вышел вполне ожидаемый и коррелирующий с реальным положением дел.

Как мы уже говорили, стоимость SSD крайне невелика, так как это самая обычная печатная плата с несколькими распаянными на ней чипами. А также корпус и разъем (если брать 2,5” модели).

Учитывая, что самые недорогие SSD продаются от 1000 рублей, то себестоимость производства несложно себе представить.

Но это только себестоимость железа и сборки, в тоже время как на разработку контроллеров, памяти, прошивок и т.д. тратятся достаточно большие средства. Это процесс, называемый R&D или НИОКР (если по-нашему) и является основной частью себестоимости накопителей.

Расходы на НИОКР закладываются в старшие и особенно топовые модели, которые и отбивают основные расходы. А за счет вырученных денег разрабатываются еще более новые и лучшие накопители.

В массовом сегменте это менее выражено, и он является наиболее сбалансированным. Но именно он составляет долговременную основу продаж.

Но перейдем от слов к делу. Если рассматривать с точки зрения стоимости хранения, то модели объемом 120 и 256 ГБ вряд ли можно назвать оптимальной покупкой. Да, они дешевы в абсолютном представлении, но стоимость гигабайта на них получается чрезвычайно высокой.

Но здесь как раз все понятно, мы приближаемся к нижней планке стоимости, которая жестко зафиксирована, а объем накопителя невелик, вот накладные расходы на гигабайт и растут.

Начиная с 512 ГБ и до самых 4 ТБ стоимость хранения выравнивается примерно на уровне 6 – 6,5 руб. за ГБ. При этом наиболее выгодными получаются диски в 2 ТБ, но их распространение пока ограничено довольно высокой абсолютной ценой.

Но в целом даже покупка 4 ТБ SSD будет вполне выгодным предложением, стоимость хранения на нем не сильно отличается от других дисков указанного диапазона и если вам действительно нужен такой объем быстрой памяти, то каждый рубль будет вложен не зря.

Что касается HDD, то на уровне до 1 ТБ включительно мы имеем полный паритет и никакого смысла в покупке жестких дисков такого объема нет.

Явное преимущество HDD по стоимости хранения начинается с 2 ТБ и далее только растет. Но при этом надо помнить, что, выигрывая в стоимости хранения жесткие диски проигрывают твердотельникам по скоростным характеристикам, особенно по мелкоблочной записи/чтению.

Сегодня де-факто сложился паритет: твердотельники массово применяются как системные диски и для обработки горячих данных, а жесткие диски для хранения холодных, где важен объем, а скорости доступа не имеют решающего значения.

Но и здесь у них в ближайшем будущем может появиться конкурент – диски QLC, которые как раз оптимально подходят к холодным данным: один раз записал, потом читаем. И если с записью на QLC есть вопросы, то по чтению они дадут фору любому жесткому.

​​О фрагментации и заполнении жестких дисков

В комментариях к вчерашней заметке нам указали на то, что сравнение стоимости хранения одного гигабайта на разных типах носителей выполнено некорректно, так как для SSD требуется оставлять свободным 10-20% емкости диска и, следовательно, нужно скорректировать стоимость на это значение.

Однако такая же самая рекомендация существует и для жестких дисков. При этом мы даже не будем брать в расчет современную «черепицу», которой запас свободного места необходим для реорганизации лент, а разберем «классические диски».

Начнем издалека. С файловой системы, для примера рассмотрим NTFS, как наиболее распространенную на пользовательских ПК.

Для хранения данных о файлах NTFS использует специальный файл MFT (Master File Table, Главная файловая таблица), это база данных, содержащая сведения обо всех объектах файловой системы и их атрибутах.

Первые 16 записей соответствуют метафайлам и не доступны пользователю, это критически важные данные, и они дополнительно дублируются ровно посередине тома.

Остальная часть MFT представляет собой файл, в который добавляются записи о каждом новом объекте файловой системы, при удалении файла в MFT появляется брешь, которая может быть использована повторно, но размер файла MFT при этом не уменьшается.

Так как о скорости доступа к MFT напрямую зависит производительность файловой системы, то очень важно не допустить его фрагментации, для этого операционная система при подключении тома автоматически резервирует на нем 12,5% пространства как зону MFT.

Данное пространство не показывается занятым и входит в размер свободного места на томе, которое показывают стандартные инструменты.

Но данные для расположения пользовательских данных будут выделяться в первую очередь за пределами этой области.

К чему это приводит? Даже если свободное место на томе позволяет записать файл одним фрагментом, то он все равно будет фрагментирован, так как ОС будет стараться расположить его за пределами выделенной зоны.

Поэтому можно говорить о том, что по исчерпании 75-80% свободного пространства NTFS том начинает стремительно фрагментироваться.

Если же мы исчерпаем всю зону для пользовательских файлов, то для их размещения будет выделяться пространство из зоны MFT, а после появления свободного места зона MFT снова будет расширяться.

Это уже приведет к фрагментации самого MFT файла и катастрофическому падению производительности тома.

Также при большом проценте заполнения тома становится невозможно нормально провести дефрагментацию, так как банально нет непрерывного свободного пространства для размещения крупных фрагментов файлов. Что также негативно скажется на производительности.

И хотя мы рассматривали NTFS подобные процессы происходят и в других файловых системах, так как физику никто не отменял и переход от последовательного доступа к случайному (что является следствием фрагментации) означает сильное падение производительности жестких дисков.

Таким образом для поддержания оптимальной производительности также нежелательно заполнение жестких дисков более чем на 75-80%, а значение 87,5% является критическим.

​​Общие принципы работы SSD

Как показали последние обсуждения – не все читатели представляют себе базовые принципы работы твердотельных накопителей и подвержены различным заблуждениям.

Поэтому в очередной раз предлагаем ознакомиться со статьей на нашем сайте. Статья не новая, но ничего принципиально нового с тех пор и не произошло. Базовые принципы работы SSD не менялись.

В ней на общем уровне показано как работает запись и перезапись в SSD, для чего нужна очистка страниц, как работает сборка мусора и для чего нужен TRIM (точнее, что он делает, а что нет).

В статье дана упрощенная модель происходящих процессов, но достаточная для базового понимания происходящего внутри твердотельного накопителя и помогающая не попасть под влияние различных мифов и заблуждений.

https://interface31.ru/tech_it/2015/04/mozhno-li-effektivno-ispolzovat-ssd-bez-podderzhki-trim.html

💯Финансисты, аналитики, руководители и пользователи 1С!  

Разберитесь с отчетами о движении денежных средств, движении доходов и расходов, оценке финансовых результатов! Познакомьтесь с конструктором отчетов подсистемы бюджетирования и МСФО!

👉Регистрируйтесь на занятие онлайн-курса «Бизнес-аналитик 1С» — «Основные управленческие отчеты разделов конфигурации 1С:ERP»: регистрация

Посмотрите по-новому на продажи, закупки, производство, склад, казначейство, финансовый результат и контроллинг, бюджетирование и МСФО. Научитесь находить, настраивать, сохранять отчеты под нужды собственников и топов.

И вот тогда сможете с ними и работать по-новому, удовлетворять их потребности удобным для них и выгодным для вас способом. Хороший отчет — сила!

👌А понравится занятие — продолжите обучение на курсе по специальной цене и даже в рассрочку!

Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

​​Все бегут, бегут, бегут

Debian всегда отличался осторожностью и консервативностью, оставаясь всегда на шаг позади. Устанавливая Debian, вы заранее соглашались, что у вас будут более старые версии софта и ядер.

В целом это шло на пользу проекту, позволяя поддерживать высочайшую стабильность, а нужный софт можно было поставить и из иных репозиториев.

С другой стороны, такая отсталость служила вечным источником упреков в отсталости и замшелости, при этом обычно ставили в пример ту же Ubuntu, которая в те же временные промежутки предоставляла более свежий софт и также не испытывала особых проблем со стабильностью.

И вот это случилось, Debian 12 сумел выпрыгнуть из штанов и побежал впереди паровоза! Новейшее ядро, свежий софт, дистрибутив буквально помолодел на глазах.

Только вот сразу что-то пошло не так. Первую версию дистрибутива разработчики настоятельно не рекомендовали устанавливать кроме как для тестов ввиду большого количества ошибок, которые они обещали исправить в выпуске 12.1.

Сейчас выпущен уже четвертый релиз – 12.3, вроде бы все должно быть отлажено и исправлено. Но нет, как гром среди ясного неба:

Разработчики проекта Debian объявили о приостановке публикации установочных образов с обновлением Debian 12.3 из-за выявления в ядре Linux ошибки, приводящей к повреждению данных в файловой системе Ext4. Пользователям уже установленных систем рекомендовано воздержаться от установки обновлений пакетов с ядром из репозитория до публикации исправления.

Проблема проявляется в стабильной ветке ядра Linux 6.1, в которую было перенесено исправление, изначально добавленное в ветку 6.5 и устраняющее аварийное завершение из-за ошибки в коде обновления размера файла, сократившегося после операции прямого ввода/вывода с флагом O SYNC.

При этом проблема возникла именно в процессе бекпортирования, так как:

Ветки 6.5 и 6.6 проблеме не подвержены, так как в них изначально присутствовало исправление в iomap dio complete, которое при бэкпортирвоании не попало в ветку 6.1.64.

Версия ядра, содержащая ошибку, в Debian имеет номер 6.1.0-14, исправленная 6.1.0-15.

Вариантов здесь ровно два: обновиться или откатиться на более ранние версии (что на наш взгляд более предпочтительно).

Но проблема не в ошибке, от них никто не застрахован, а в появлении подобных ошибок в стабильном дистрибутиве вообще. Ведь основная причина использования именно Debian – его стабильность.

А что теперь? От былой стабильности не осталось и следа и теперь перед каждым обновлением системы надо внимательно изучать новости? Так может стоит взять что-нибудь другое?

В общем бежать за прогрессом весело и интересно, но как быть тем кому нужна стабильность?

​​Сохранить нажитое нелегким трудом

Сегодня днем мы разбирали проблемы со стабильностью некогда сверхстабильного Debian в связи с чем снова остро встает вопрос резервного копирования.

Но современное резервное копирование это не про скачал отсюда – залил туда. Современные объемы информации просто не позволяют ни перемещать их подобным образом, ни хранить, особенно с обеспечением некоторой глубины хранения.

В таком случае может получиться, что затраты на резервное копирование информации будут превосходить возможный ущерб от потери этой самой информации. А дальше в дело вступает принцип меньшего зла.

Поэтому современное копирование – это специализированные системы, которые обеспечивают дифференциальное копирование, позволяющее передавать только изменившиеся блоки данных и дедупликацию, обеспечивающую эффективное использование хранилища.

Если вы используете гипервизор Proxmox VE, то самым разумным решением будет добавить в инфраструктуру сервер резервного копирования Proxmox Backup Server, которой обеспечивает не только резервное копирование виртуальных машин и контейнеров, но также может использоваться для выборочного резервного копирования узлов под управлением Linux.

🔹 Установка и настройка Proxmox Backup Server

Если же стоит задача копировать данные с физических или виртуальных серверов Linux которые размещаются у сторонних хостеров, то можно обратить внимание на Borg.

Borg – это простой в использовании, но мощный инструмент резервного копирования, который также поддерживает дифференциальное копирование и дедупликацию.

А еще его очень просто внедрить и еще проще использовать.

🔹 Borg Backup - простой и современный инструмент резервного копирования

🔹 Быстрый и простой перенос Borg Backup на другой сервер

Но копируя данные многие забывают о настройках, а ведь потеря какого-нибудь сложного файла конфигурации может наделать не меньше бед, чем потеря данных.

При этом попутно было бы очень неплохо одновременно с копированием ввести версионный контроль, чтобы можно было легко отслеживать и откатывать изменения.

Для этих целей отлично подойдет инструмент Etckeeper, который поставит все ваши настройки под контроль Git и сам настроит все необходимое.

🔹 Etckeeper - ставим под контроль изменения конфигурации сервера

Не меньшего внимания заслуживают и конфигурации сетевого оборудования, которые тоже не только нужно копировать, но и отслеживать вносимые в них изменения.

В этом нам поможет Oxidized – система управления конфигурациями сетевого оборудования на базе Git. Один раз настроенная она станет единой точкой контроля и управления конфигурацией вашей сети.

🔹 Устанавливаем и настраиваем систему управления конфигурациями сетевого оборудования Oxidized

👆 Ну и в любом случае помним, что ни одна система резервного копирования не является 100% надежной, поэтому недостаточно того, что она просто создает копии. Копии нужно регулярно проверять на возможность восстановления из них.

При этом учитывать не только саму возможность восстановления, но и время, которое придется на это затратить, в некоторых случаях оно может оказаться неприемлемым и потребует пересмотра всей системы резервного копирования.

​​DNS over HTTPS (DoH) на роутерах Mikrotik и Яндекс

👍 Говорим спасибо нашему читателю Алексею, который довел вопрос до конца.

Общался с поддержкой как MikroTik, так и Яндекса. Данная проблема вызвана обратной несовместимостью используемых протоколов HTTP. RouterOS (и встроенный DoH) использует HTTPS с заголовками HTTP/1.1, а Яндекс использует версию выше, т.к. версия 1.1 по их мнению устарела. Из-за этого и возникает ошибка парсинга. Со стороны Яндекса версию HTTP/1.1 включать не планируется. В RouterOS в перспективе пларируют добавить HTTP выше версии 1.1, тогда все будет работать, но конкретные сроки реализации со стороны MikroTik не установлены.

Пишут о массовых сбоях в доступе к интернет.

В частности есть проблемы доступа с доступом к сайтам в зоне RU.

На профильных ресурсах пишут, что проблема может быть связана с что проблема может быть связана с DNSSEC.

Официальное заявление.

https://cctld.ru/media/news/kc/35564/

​​Как сэкономить на регистрации и продлении доменов

Не так давно мы размещали подаренные нам при продлении доменов промокоды на бесплатную регистрацию в доменной зоне SITE, но были несколько удивлены реакциями, состоявшими преимущественно из дизлайков.

При обсуждении выяснилось, что отдельное недовольство вызывает ценовая политика регистратора и высокая цена продления, от чего многие воспринимают такие предложения как завуалированный лохотрон и подобное мнение имеет под собой основание.

Но если подойти к вопросу грамотно, то можно существенно экономить на регистрации и продлении доменов, а также не пропускать привлекательных предложений.

Но для начала разберемся кто есть кто на этом рынке и какие функции он выполняет.

Прежде всего у каждой доменной зоны есть администратор, для RU и РФ — это Координационный центр доменов .RU/.РФ, сам он не выдает домены, но осуществляет общее управление зонами и осуществляет аккредитацию регистраторов.

Количество регистраторов невелико, всего в списке их 131 организация, но крупных, обслуживающих более 10 000 доменных имен ровно 20. Полный их список приведен тут: https://cctld.ru/domains/reg/

Кроме регистраторов есть еще их партнеры, которые не являются регистраторами, но могут регистрировать домены через одного из них. При этом ценовые условия у партнеров обычно существенно приятнее, чем у регистраторов.

Чем обусловлена подобная щедрость? Ведь, как известно, бесплатного сыра не бывает. Все просто: обычно партнеры имеют смежный бизнес, для которого продажа доменных имен является сопутствующей.

Чаще всего это хостинг-провайдеры, которые таким образом формируют полный пакет услуг, а низкие цены на домены используют как еще одно конкурентное преимущество. В тоже время они будут совсем не против если вы просто купите или перенесете к ним свои домены. Все эти процессы обычно хорошо автоматизированы и кушать не просят, а копеечка капает.

Сами же регистраторы поддерживают куда более высокий уровень цен и любят наводить тень на плетень с запутанными тарифами, больше всего они любят скрывать стоимость продления.
А это один из основных параметров на который следует обратить внимание при выборе доменной зоны. Потому как регистрируете вы домен один раз, а продлять его придется ежегодно.

Сейчас средняя стоимость продления домена RU у регистраторов составляет примерно 600 руб. за домен. Если же брать партнеров, то продлить домен у них в среднем обойдется в 200 руб. Как говорится – почувствуйте разницу.

Что касается приобретения, то зарегистрировать домен можно вообще за копейки, а то и бесплатно. Например, самая вкусная цена на домены RU сегодня у Джино, всего 39 руб., правда за продление с вас уже попросят стандартные 589 руб.

Но приобретение домена не привязывает вас к регистратору или его партнеру, вы можете свободно передавать домены как между партнерами, так и регистраторами.

Поэтому покупаете домены, где вам удобно, а затем в течении года переносите их к партнеру с низкими ценами и продляете их у него.

Многие опасаются переносить домены к партнерам, так как это обычно небольшие организации или ИП, не вызывающие особого доверия и уверенности в завтрашнем дне. Но это абсолютно необоснованное опасение.

Никаких прав на домены партнеры не имеют и работают сугубо через регистратора. Для переноса доменов от одного партнера к другому в пределах регистратора достаточно простого письма.

Если партнер морозится или вообще перестал существовать, то перенос домена к другому партнеру обязан выполнить регистратор. Это несложно и такие ситуации у нас были.

Для переноса домена между регистраторами вы просто запрашиваете у текущего AuthInfo-код и передаете его в поддержку нового. Обычно это имеет смысл делать, если партнеры нового регистратора предлагают более выгодные условия, нежели партнеры старого. Причем это может быть одна и таже организация.

Если регистратор прекратил свое существование или отказывает вам в переносе, то AuthInfo-код можно запросить у Координационного центра.

​​Без бумажки ты букашка, а с бумажкой человек

Сегодня была одна достаточно неприятная история. Утром раздался звонок и представитель одного старого и лояльного заказчика сразу предъявил претензии: мол ребята, что же вы так накосячили?

А днем ранее мы переключали филиал на нового провайдера и вносили некоторые изменения в сетевые настройки и маршрутизацию. Все согласно присланному администратором филиала документу.

В целом наличие этого документа нас и спасло. Потому что вопрос стоял не только и не столько в финансовом плане, сколько в репутационном. С этим заказчиком мы работаем уже порядка 20 лет и в его инфраструктуре чувствуем себя как дома, имея полные допуски абсолютно везде.

Их начальник IT с которым мы знаемся уже лет 15, начиная с той поры, когда он был простым админом и мы его вводили в суть дел после ушедшего со скандалом коллеги сию бумагу прочитал и сказал, что к нам вопросов не имеет.

Точнее имеет, но уже в виде встречного предложения. Надо все срочно переделать. Не вопрос, пиши бумагу. Он тоже воробей стреляный, поэтому такому предложению не удивился и не возмутился.

В общем к обеду все было исправлено, оба счета ушли на оплату (и за «косячную» настройку, и за «правильную»).

Как потом выяснилось, админ филиала подошел к своему делу формально, т.е. где-то взял старый файл, со старыми настройками, добавил в него новую информацию, вычитать поленился и прислал все это нам.

Мы же как написано, так и сделали.

Но дальше он сам повел себя неправильно, вместо того чтобы возникшую проблему решить с нами напрямую он доложил в центр, что ничего не знает, это мы вчера сеть настраивали.

В результате теперь он обиделся что мы его подставили. Хотя вопрос можно было решить в течении рабочего утра и отписаться на всякие независящие от нас причины. Мы обычно относимся к коллегам лояльно и их косяки перед руководством не выпячиваем.

А мораль сей басни такова: любые действия серьезнее чем поменять картридж должны каким-либо образом документироваться, если не официально, то хотя бы в почтовой переписке или в мессенджерах.

Причем из этой переписки должно быть понятно, что именно от вас хочет заказчик, неважно внешний или внутренний. Если заказчик затрудняется сформулировать задачу – формулируем ее сами, но обязательно получаем подтверждение, что все нужно сделать именно так.

Потому что в случае возникновения проблем самое любимое занятие у нас – это искать крайнего. А в отсутствии документального подтверждения крайним будет именно тот, кто непосредственно это сделал.

С чего начать изучение работы с RabbitMQ?

С бесплатного практического урока «Очереди сообщений и протокол AMQP» от OTUS.

На вебинаре разберём:
- возможности протокола AMQP;
- как подключаться к брокеру из вашего языка программирования;
- как отправить и принять сообщение;
- как организовать простейший RPC-сервис.

Встречаемся 6 февраля в 20:00 мск в рамках курса «RabbitMQ для разработчиков и администраторов». Доступна рассрочка на обучение!

Регистрируйтесь прямо сейчас, чтобы посетить бесплатный урок: https://otus.pw/pfYqh/?erid=LjN8KaCjz

​​LibreOffice 24.2 – и эти туда же…

Вчера без лишнего шума и пыли вышла в свет очередная версия LibreOffice. Только вот номер продукта сразу и радикально изменился с 7.х на 24.2, что вызвало у многих недоумение. Очередная дань моде?

Именно таким было первое впечатление. Но немного подумав начинаешь понимать, что разработчики поступили правильно.

Вообще с нумерацией версий продуктов у нас сейчас полный бардак, каждый развлекается как считает нужным. Но подобные действия предпринимаются отнюдь не от хорошей жизни.

Когда-то давно все было относительно просто и понятно. Версии нумеровались последовательно и изменение первой цифры обозначало существенные изменения в продукте, которые действительно тянули на новую версию.

Но и изменений этих приходилось ждать долго, буквально годами. А все потому, что отсутствовал канал быстрой доставки кода пользователю. Перед тем как выпускать продукт его надо было всесторонне проверить, так как оперативно устранить ошибки не представлялось возможным.

Поэтому цикл разработки был долгим, а выход каждой новой версии становился долгожданным событием.

Сегодня все поменялось, интернет позволяет распространять обновления и патчи буквально в режиме реального времени, а разработка ведется в последовательном режиме. Сделали функцию – выпустили новый релиз и т.д. и т.п.

В результате изменения происходят последовательно и нет эффекта новизны, хотя если сравнить выпуски на большом временном промежутке, то разница будет отлично видна.

Вот тут и возникает проблема. На каком этапе считать, что продукт получил достаточно обновлений чтобы поменять первую цифру? И чем условно этот 3.0 будет отличаться от 2.99?

От выхода новой версии всегда ждут чего-то нового и фактически пользователь будет обманут в своих ожиданиях.

Разработчики браузеров решили вопрос просто: начали увеличивать первые цифры при каждом выпуске и сегодня уже уверенно разменивают вторую сотню. Только вот беда, за этими номерами все уже давно перестали следить и вряд ли кто-то уверенно скажет какая сегодня последняя версия браузера или насколько стара версия 1хх.

Но чем плоха старая нумерация? А тем, что создает у пользователя ошибочное представление о застое в разработке продукта. И это отчетливо понимают многие разработчики.

Тот же GNOME перешел от варианта 3.х на вариант 40 исключительно из подобных соображений, так как неясно, когда и как удастся набрать изменений на пятую версию и будет ли она вообще.

Что касается LibreOffice, то сами разработчики еще летом прошлого года высказали мнение, что развитие продукта является постепенным и повода к смене первой цифры нет. Но и продолжать старую схему нумерации не представляется возможным, так как она не дает возможности быстро оценить степень актуальности версии.

Действительно, кто навскидку скажет, когда вышла версия 7.2 или 7.3? А увидев на сайте новую 7.6 быстро поймет пора ли обновляться или можно пропустить?

Ну и психологический эффект. Мол что там нового у LibreOffice? Да ничего, все та же седьмая версия.

При том из всех современных версий нумерации выбранный разработчиками вариант с использованием года и месяца представляется нам наиболее разумным и правильным.

Сразу снимается вопрос актуальности продукта, по версии это сразу видно. Также это позволяет видеть, насколько активно развивается проект и понимать цикл выпусков.

А так ничего революционного в новом выпуске нет, обычное последовательное развитие.

​​Куда я попал и где мои вещи?

Рано или поздно любой администратор попадает на незнакомый ему сервер. Как быстро разобраться в ситуации и определить, где тут и что?

Начните с команды:

hostnamectl 

Она покажет основную информацию о системе, а также поможет определить тип платформы и наличие виртуализации.

Затем будет полезно определиться в каком часовом поясе живет сервер и какое на нем текущее время:

timedatectl

Этим действием никак не следует пренебрегать, мы не раз сталкивались с различными нелепыми и неприятными историями, связанными с «неправильным» временем.

После этого сразу же посмотрим локаль, чтобы понимать в какой языковой среде мы работаем:

locale

Теперь посмотрим активные службы в системе:

systemctl list-units --type=service

И активные таймеры:

systemctl list-units --type=timer

В современных системах таймеры заменяют задания Cron, но не отменяют их. Поэтому также проверяем и его:

crontab -l

Также systemd сегодня используется для монтирования файловых систем, особенно съемных и сетевых. Поэтому смотрим и их:

systemctl list-units --type=mount

И изучаем содержимое fstab:

cat /etc/fstab

А все имеющиеся в наличии блочные устройства можно посмотреть командой:

lsblk

Также полезно проверить и USB-устройства:

lsusb

Затем посмотрим какие порты слушает наш сервер, сначала на TCP:

ss -tpln

Потом на UDP:

ss -upln

Данный перечень команд не является исчерпывающим, но покрывает большую часть задач по изучению новой для администратора системы, ее устройства и запущенных в ней процессов.

​​Узкий профиль или болото?

В комментариях недавно всплыл вопрос эксплуатации откровенно старых систем. Мол все что вы пишете – хорошо, но попробуйте это применить на … (можете вписать любой устаревший софт).

На аргументы, что данный софт уже много лет как снят с поддержки применяется контраргумент, что мол много таких систем, где все это живо до сих пор и жить будет еще долго.

Несомненно, что так оно и есть, особенно среди специфических промышленных систем. Но есть один тонкий момент – квалификация, точнее ее потеря. А чтобы было понятнее что под этим имеется ввиду я специально попросил написать эту заметку коллегу, который побывал в подобной ситуации.

Далее от его лица, моя только литературная обработка.

Довольно давно, еще в начале десятых я попал на одно торгово-производственное предприятие. Им нужен был программист для 1С с навыками этой самой 1С администрирования. Компания только-только перешла на «восьмерку», и старый программист не тянул.

Но зато он отлично тянул еще одно внутреннее приложение, которое отвечало за всю внутреннюю кухню, включая производство и даже расчет зарплаты. Понемногу втянулся в это дело и я. Приложение было полностью самописное, на базе FoxPro.

Шли годы, мой начальник ушел на пенсию, и я занял его место, по деньгам было неплохо, я стал обрастать жирком и в какое-то время перестал интересоваться делами в отрасли. Ну не до того. На работе своих дел хватает, а дома семья, дети, стройка.

Стек технологий у меня оставался стабильным, точнее стабильно древним: FoxPro, Visual Basic 6, Windows, COM и 1С на обычных формах. Новая 1С, которая 8.3 и на управляемых формах как-то не зашла (там сильно переучиваться надо было) и стояла только в бухгалтерии, благо дорабатывать ее было не нужно.

Жизнь шла по налаженной стезе, и я даже немного гордился тем, что я достаточно редкий специалист, так как найти кого-то на этот стек было практически невозможно.

Первый звоночек прозвучал в короновирус, когда мы серьезно просели по выручке и несколько месяцев получали голый оклад. Стало, мягко говоря, тяжело, тем более что накоплений особо не было (все ушло на стройку), а кредиты сами себя не заплатят.
Когда жизнь снова стала входить в привычное русло меня пригласили на один проект хорошие знакомые. Они как раз мигрировали подобную внутреннюю систему с FoxPro на новую 1С и им нужен был человек разбирающийся в FoxPro.

И вот тут я понял, что жизнь прошла мимо меня и я все пропустил. Ребята говорили о каких-то абсолютно неведомых мне вещах: Linux, виртуализация, контейнеры, кластеры, веб-сервисы. При том, что «серверная» там составляла всего один небольшой шкафчик.

Также посмотрел я и на «новую» 1С, которая оказалось может и умеет гораздо большее, чем я мог себе представить.

А дальше я понял, что как специалист я представляю из себя практически полный ноль и никому кроме своего «дяди» я не нужен.

Но если придется менять работу, то максимум я могу претендовать на позицию «джуна», но «джун» возрастом под 40 лет – это не то, что способно заинтересовать работодателя.

В общем весь этот проект я активно вникал в используемые в нем технологии, много спрашивал про то, как, что и на чем. И все больше понимал, насколько я отстал и что с этим нужно срочно что-то делать.

Но что делать как-то в голову не приходило. Да, надо было учить, но когда?

Второй звоночек прозвенел, когда я уехал на месяц по семейным обстоятельствам и работать мог урывками и то удаленно. После чего и мне и дяде стало понятно, что никто кроме меня всю нашу кухню не тянет.

По приезду состоялся разговор, мол, а если тебе завтра кирпич на голову упадет? Я сказал, что тоже об этом думал и «покаялся», рассказал дяде про халтурку и то, как там было все устроено.

После чего дядя сказал, мол, а чего ты раньше молчал? Давай думай, предлагай, нужно двигаться вперед. Надо учиться – отправим, но мы не должны отставать от технологий.

Сейчас я второй год активно переделываю всю внутреннюю кухню, от старого приложения отказаться еще не получилось, но многое уже перевели на современные технологии.