Модули (расширения)

Ситуация прямо как с кластерами/экземплярами. Очень многие не разделяют понятия расширений и модулей. И я в их числе. Но все же, если делать по правильному: модуль – это набор расширений.

Расширение (extension) устанавливается напрямую в БД или сразу на весь кластер. Соответственно, чем больше у вас БД и кластеров – тем больше затраты на управление расширениями.

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

А в целом расширений для системного администратора не так уж и много. В основном, они нужны либо разработчикам, либо для интеграции с каким-либо интересным приложением, к примеру, PostGIS для интеграции с геолокационным приложением, или timescaledb для повышения производительности баз (в несколько раз на ровном месте) для того же Zabbix. Ну или они нужны настоящим DBA, чтобы выжать максимум производительности для крупных систем.

Установка расширения

Сразу скажу: устанавливайте расширения только, если они вам действительно необходимы и если вы действительно будете их использовать.

Перед тем, как добавить расширение в БД, его необходимо загрузить и установить в ОС. У всех расширений это делается по-разному. Например, некоторые расширения входят в пакет postgresql-contrib, некоторые загружаются напрямую из репозиториев PostgreSQL, а некоторые скачиваются с гитхаба или PGXN и требуют Perl, Rust или Python. И вот с языками программирования высокого уровня всегда проблема, потому что работа с ними отнимает место на диске и наше время. С расширениями, которые написаны с использованием plpgsql или C/C++ таких проблем нет.

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

Можете в целом выбрать любой удобный для вас способ установки. Только имейте ввиду, что вам также может понадобиться пакет postgresql-server-dev-XX (где XX – это мажорная версия PostgreSQL сервера, на который вы планируете устанавливать расширение, если непонятно, то замените XX на all) или другие пакеты. Читайте документацию к каждому из модулей.

Добавление расширения в БД

Установка расширения в БД происходит в несколько этапов:

1) Подключаемся к БД.

2) Добавляем расширение. Необходимо знать имя расширения и его версию, которая должна быть совместима с версией кластера, на котором находится БД.

https://www.postgresql.org/docs/current/sql-createextension.html

3) Проверяем, было ли оно добавлено в БД, при помощи SQL запроса:

SELECT * FROM pg_extension;

Или мета-команды \dx.

Изменение расширения

В основном, нам просто придется обновлять расширение на более новую версию, потому что расширения тоже получают обновления.

К примеру, обновим расширение extension1 до версии 1.1:

ALTER EXTENSION extension1 UPDATE TO '1.1';

https://www.postgresql.org/docs/current/sql-alterextension.html

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

pg_repack

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

Модуль позволяет выполнять операции перестроения индексов, полной очистки и перестановки строк таблиц на боевых серверах без прерывания подключений. Но есть и минус: вам требуется как минимум в 3 раза больше свободного места в хранилище БД, потому что чудес не бывает, а системе требуется копия таблицы, с которой она сможет работать без постороннего вмешательства. Всегда приходится чем-то жертвовать. Но зато вы можете забыть об остановке сервера для операций обслуживания, а объем баз будет минимальным. Правда, есть еще один незначительный недостаток. Некоторые блокировки все еще останутся, а очистить данные на все 100% возможно только на холодной системе. Но это все равно лучше, чем vacuumdb и reindexdb, а алгоритмы работы pg_repack в целом гораздо эффективнее, в первую очередь за счет возможности распараллеливания процессов на горячей системе.

Альтернативой для pg_repack является pg_squeeze. Его плюс в том, что больше не требуется так много свободного места на диске для перестроения таблиц. Однако, если разобраться в алгоритмах их работы, pg_repack видит цель и не видит преград, а pg_squeeze равномерно размазывает нагрузку на сервер, чтобы не мешать другим процессам, но при этом, зачастую, он не способен очистить то, что может очистить pg_repack. В целом и так у каждого из них есть свои преимущества и недостатки. Разница будет заметна только в очень крупных системах, где каждый их модулей используется для конкретной задачи. Для нас пока что основной проблемой является порог вхождения. И у pg_repack он самый низкий за счет простоты, документации и наличия обучающих материалов в интернете.

Не используйте этот инструмент просто так. Всегда смотрите, что было с базой до, и что стало после (в первую очередь это объем). Основную проблему pg_repack вы уже знаете.

Если у вам в «наследство» досталась распухшая база на несколько терабайт, в которой всего 2-3% полезных данных, то pg_repack это лучшее решение. А еще лучше – VACUUM FULL.

Также отмечу, что, если вы используете Barman, то в него уже встроены алгоритмы по борьбе с распуханием БД (не знаю точно насчет других систем, я работал только с Barman).

Устанавливается pg_repack просто. Достаточно установить пакет с именем postgresql-XX-repack, где XX – это мажорная версия вашего кластера, на котором планируется использовать pg_repack (на самом деле, это не так важно, поскольку pg_repack совместим и с более старыми версиями СУБД, основная проблема в поддержке новых версий). По умолчанию будет установлена последняя актуальная версия.

https://packages.debian.org/trixie/postgresql-16-repack

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

CREATE EXTENSION pg_repack;

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

-a – обрабатывает все базы в заданном кластере.

-j – задает количество процессов. Будьте очень осторожны с этим параметром. Задавайте максимальное число ядер только, если система холодная. Если же горячая – то в зависимости от текущей загруженности CPU и, что самое важное, дисковой подсистемы. Если не знаете – оставляйте как есть, то есть 1. Да, процесс работы будет сильно дольше, но зато pg_repack не отберет у других процессов необходимые ресурсы. Также при использовании только одного ядра вам может не потребоваться так много свободного места в хранилище, поскольку один процесс может работать только с одним объектом. Но лучше не рисковать, вы же не знаете, сколько у вас таблиц в базе и сколько в процентном соотношении они занимают места. К примеру, если у вас одна огромная таблица, то вся она будет скопирована, и места может не хватить. Ну, вы уже знаете, что будет, если место внезапно закончится. Лучше не рисковать.

https://github.com/reorg/pg_repack

https://github.com/cybertec-postgresql/pg_squeeze

Мониторинг

Все, что от вас требуется – следить в первую очередь за свободным пространством в хранилище БД, а также за скоростью роста баз. Если у вас есть какая-либо система мониторинга, можете развернуть агент/клиент для PostgreSQL, либо использовать стороннее решение конкретно для PostgreSQL, как тот же PoWA, который на самом деле очень легок в установке (альтернативы: PgHero, pgwatch2 и т.п.). Если же и их нет – то мониторьте локально при помощи Linux утилит. Огромный плюс нормальной системы мониторинга в том, что вы сможете визуализировать все то, что было изучено выше: автовакуум, чекпоинты, журнал предзаписи, подключения и т.д. Также не забывайте про анализ логов. Если вы усвоили все вышенаписанное, то вам мониторинг, может быть, и не нужен, потому что у вас и так все будет в порядке. Однако убедится в том, что все работает как надо, никогда не помешает. Но самое главное – это специалисты. То есть вы. Потому что даже при наличии системы мониторинга пустоголовый выкидыш с курсов не сможет выявить проблему и ее устранить.

Что делать дальше?

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

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

Если системный администратор (или в принципе любой ИТшник или инженер) не пишет документацию, то он либо самоуверенный идиот, который просто не понимает масштаб проблем, либо не показывает документацию специально. Причины этого могут быть самые разные. Кто-то боится, что она достанется другим, и те просто на ее основе быстрее и лучше построят свою систему. Это неправда. Чтобы понять, что написано в документации по тому же PostgreSQL, надо сначала научится с этой системой работать. Они бы и так ее построили, просто без документации на текущее положение дел это заняло бы больше времени. А кто-то не показывает документацию для того, чтобы завязать все на себе, чтобы не уволили, а в случае увольнения остальные мучались и перестраивали всю систему заново, гадая на кофейной гуще (короче говоря, чтобы поиметь денег).

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

Если все три пункта выполнены, можете с чистой совестью начать изучение приложения, которое интегрируется с PostgreSQL. Мы же именно для этого изучали СУБД. Как выучите, идите дальше по пунктам.

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

Мониторинг и анализ логов. Смотрите по ситуации. Все уже сказано. Необходимо – да, а вот есть ли у вас время на изучение и внедрение всего этого добра – смотрите сами.

Безопасность. SSL, шифрование, смены паролей и т.д. и т.п.

SQL. Если вы разработчик или DBA. При помощи SQL можно много всего интересного натворить, а вот надо оно вам или нет – вопрос тоже спорный. Как правило, готовые команды уже прописаны, и выдумывать самому ничего не надо.

Кластеризация. Речь именно про кластер серверов, а не баз данных. Очень сложная и объемная тема. Все зависит от того, какая перед вами стоит задача: обеспечение отказоустойчивости или повышение производительности. В теме кластеризации очень много нюансов и подводных камней. Не учите кластеризацию, если вам она не нужна. Кластеризация – это очень дорого и по материальным ресурсам, и по временным, и по интеллектуальным. Но есть и плюс: это бесплатные решения, так что затрат на лицензирование не будет. Я специально опускаю конкретные примеры, потому что тема действительно очень сложная, особенно для новичка, и тут нельзя просто сказать: «Вы, 99%, используйте вот это вот так, и все будет хорошо».

Модули. Размазаны по всем пунктам выше. Смотрите сами, нужны они вам или нет. Я про самый полезный из них уже рассказал.

Что почитать?

Если вам нужен конкретно PostgreSQL, то я знаю 4 хорошие книги. Проблема в том, что они, скорее, предназначены для разработчиков (потому что написаны разработчиками). Если вы кодер – то они именно для вас. Там очень много полезной информации про устройство самой СУБД и запросы. Но если вы системный администратор, то не тратьте время. Гораздо больше пользы будет от чтения документации по расширениям и сторонним системам.

• PostgreSQL 16 Administration Cookbook (ISBN-13: 978-1835460580)

• PostgreSQL 16 изнутри (ISBN: 978-5-93700-305-8)

• Mastering PostgreSQL 15 (ISBN-13: 978-1803248349)

• Learn PostgreSQL (ISBN-13: 978-1838985288)

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

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

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

В чем проблема PostgreSQL?

Можно долго шутить про прокладку между креслом и монитором, однако проблемы действительно есть. Ниже я описал только те из них, которые касались лично меня (когда я только брался за изучение), а не всей системы целиком. Сама по себе СУБД задачу выполняет как надо.

Документация. Она слишком подробная. 90% информации вам никогда не пригодится. Граница между администрированием и разработкой очень сильно размыта. И это относится не только к PostgreSQL, а еще и ко многим другим продуктам. Разработчики не могут создать отдельную версию для сисадминов-дебилов, где будут описаны только базовые и самые необходимые вещи. Входить надо постепенно, шаг за шагом, а не когда ты потратил неделю на чтение документации про SQL команды, но так и не понял, куда их вбивать (просто пример). Почему так происходит? Потому что разработкой занимаются люди задроты, которые работают только с PostgreSQL, и ни с чем больше. Для них самих, конечно же, все будет легко и понятно. Интересы целевой и потенциальной аудитории им не нужны. Но вот как можно было оставить 25% для общих буферов – я не понимаю. Почему нельзя было просто написать, что у всех все будет разное, а также хотя бы примерный алгоритм расчета. Или nakhera начинающим администраторам учить SQL полностью – вопрос открытый. Поэтому пинайте разработчиков, иначе они не будут выполнять свои прямые обязанности, и так все и останется. А еще лучше: напишите свою статью на интересующую вас тему (про сравнение сторонних систем бэкапа, к примеру, уже есть). Это же open source сообщество, давайте помогать друг другу. Разумеется, настоящих DBA с 20-ти летним стажем этот абзац только рассмешит: начинающий DBA не хочет учится. Я хочу учиться, но только в правильном направлении, и учить то, что надо, а не все подряд, потому что в сутках только 24 часа. Да, у многих решений с документацией ситуация аналогичная, только это никак не оправдывает PostgreSQL.

Курсы. Хорошо, допустим, мы захотели пойти по простому пути, чтобы лишний раз не напрягать наш пустой мозг, и решили найти какие-то готовые курсы или статьи по администрированию для начинающих. И там опять будет подробное изучение SQL и прочая jebanina, которая начинающим администраторам (не разработчикам) просто не нужна. У того же PostgresP*O есть курсы DBA 1-3, их можно найти в свободном доступе. Пример отличный: 90% информации можно просто выкидывать, а рекомендаций никаких конкретных нет, потому что этот курс разработан программистами, а не сисадминами. То же можно сказать и про книги. Но PostgresP*O можно похвалить хотя бы за то, что выложили курсы в общий доступ, потому что полезная информация там все же есть. Вы также можете подумать, что я за то, чтобы снижать порог вхождения. С одной стороны да, с другой – нет. Просто в достаточном количестве специалистов у вас не будет. Да и в целом ниже падать все равно уже некуда. Эта статья именно для начинающих, для широкой аудитории, чтобы поднять минимальный уровень.

Почти для всех задач используются сторонние решения. Резервное копирование, мониторинг, анализ логов и их ротация, пул подключений, да даже алгоритмы zlib и gzip по умолчанию – это все больные места PostgreSQL. Так что эту СУБД нужно рассматривать как основу, на которой мы будем строить все остальное. Напоминаю, что инкремент для физических резервных копий добавят только в 17 версии. Сам по себе PostgreSQL очень легок в изучении (могу говорить только про область администрирования), основной объем – это Linux, а также сторонние утилиты и модули.

Нет защиты от дурака. Делай, что хочешь. Хочешь – отключай автовакуум. Хочешь – не делай резервные копии вообще. Или делай дампы только конкретных баз, без схемы. Ладно, шучу. И так понятно, что это проблемы тех, кто не читает документацию. С одной стороны, есть гибкость, и с системой можно делать вообще что угодно, в отличие от того же MS SQL Server. Но, с другой стороны, эта самая гибкость может только навредить.

Подытожить это все можно одной фразой: добро пожаловать в open source.

Про форки PostgreSQL

Сейчас опять набегут адепты PostgresP*O и будут в комментариях доказывать, что это не пустая трата денег. Продолжайте дуться и платить налоги, которые уйдут в карманы фирм по «разработке» отечественного ПО аналоговнет, которое просто является переименованной (или даже перекрашенной) копией уже готового open source решения. А потом руководство гос. организаций должно страдать, потому что им сверху пришел приказ тратить ежегодно 1 млн. рублей на 100 лицензий A***a Linux (зато техподдержка работает!). Пока есть газ и нефть, пока выделяются бюджеты на эту hujetu, это не прекратится.

Хорошо, пусть скопировали PostgreSQL, подкрутили пару особенностей, и даже создали учебные материалы… 99% информации в которых это просто пересказ документации обычного PostgreSQL. Роли alice и bob мне уже в кошмарах сняться, вот честно.

То же было и с пользователем vivek, когда я изучал Windows Server. То есть наши соотечественники просто взяли и скопировали учебные программы либо из документации, либо украли у загорелых специалистов из стран третьего мира. И даже не изменили имена учетных записей. А потом еще и меня обвиняют в плагиате или использовании нейросетей.

Не согласны? Хорошо, вот вам наглядный пример. Компания PostgresP*O разработала утилиту резервного копирования pg_probackup (на гитхабе есть бесплатная версия, которая уже пару лет как перестала развиваться, разработчики бросили все силы на платную версию). И вот они со своими подпевалами часто сравнивают ее со встроенными в стандартный PostgreSQL утилитами pg_basebackup и pg_dump. Почему они не сравнивают их с Barman, WAL-G, pgBackRest и другими БЕСПЛАТНЫМИ решениями, я не могу понять. Хотя нет, могу, это же просто бизнес. Надо же всем показать, что стандартный PostgreSQL ни на что не способен.

В чем смысл?

Дописав эту статью до конца и думая над этим подразделом, я задаю себе тот же вопрос. А зачем учить PostgreSQL, если до него нужно выучить Linux со всеми вытекающими?

Зачем он нужен? Мы же можем просто использовать для той же 1Ски SQL Server либо для разработчиков, либо взломанный. Мы же в России живем. Зачем учить страшные и неудобные команды, если можно просто тыкать мышкой.

Только вот вы здесь системный администратор. Может быть, даже единственный в вашей компании. Взломать ПО и нарушить лицензионное соглашение – это одно и то же с точки зрения нашего законодательства (учитывая то, как оно работает на практике). Если к вам приедет ревизор из отдела К, вас сделают виноватым все, сговорившись за вашей спиной без всяких сказок в стиле «Мы одна команда, поэтому сядут все, а всех не посадят» или «У нас супер-юристы, они от такой ерунды вас отмажут». Не отмажут, только если вы не чей-то родственник, чтобы был смысл тратить деньги на какого-то урода, который вчера пришел. Читайте 146 УК РФ. Когда замаячит реальный срок – люди пойдут на что угодно. Хорошо это или плохо – может рассуждать только тот, кто в подобную ситуацию не попадал. Оно вам надо? Ради этого вы учились? Ради денег руководства какой-то фирмы, которое плевать на вас хотела и терпит вас только потому, что вы приносите прибыль? Вы просто наемный рабочий, не генеральный директор, не акционер, не совладелец. Так что вам в целом без разницы, что с этой компанией будет дальше. Сегодня вам все улыбаются, а завтра попросят уйти или лишат премии. И нет смысла рисковать ради того, чтобы какая-то жирная свинья купила себе и своим детям новенький мерседес, последний айфон, квартиру в центре, и всей семьей они улетели на отдых в какую-нибудь очень дорогую страну Северной Америки или Европы. Сначала они экономят на лицензиях, чуть позже на оборудовании, далее на условиях труда, затем на зарплатах, а потом будут экономить и на вашей безопасности. Не верите – почитайте комментарии к любой статье или видео на очередную тему про дефицит кадров или почему люди не хотят работать.

Вы еще успеете познакомиться с jebanutymi HR, менеджерами, ИТ-директорами и с СБшниками с их полиграфом, которые могут отказать вам в трудоустройстве только потому, что до этого вы с другого работодателя через суд выбивали деньги. То есть, кидать людей на деньги можно, а вот добиваться справедливости оказывается нельзя. Без вот этих всех сказок про то, какой бизнес несчастный, белый и пушистый, и какое плохое у нас государство, что заставляет выплачивать белую з.п., соблюдать ТК РФ и душит налогами. Как по мне, так этим тварям и надо.  Да, есть хорошие компании, где руководство адекватное. Но, к сожалению, далеко не все компании такие. Например, рано или поздно вы обязательно столкнетесь с ситуацией, когда вам позвонили/написали и предложили работу по вашей специальности, хотя вы работу не ищите и никогда до этого не слышали об этой компании. Не надо думать, что это сарафанное радио, и что вы востребованный специалист, не льстите сами себе. Просто ваши данные кто-то продал. Собеседования по 10 минут удаленно и вакансии, висящие на протяжении нескольких недель или даже месяцев – это именно оно.

Так, мы отвлеклись. Вернемся к теме ИТ. Почти везде пиратский MS SQL Server, несмотря на санкции – это правда. И эта статья призвана хоть немного это дело исправить. И да, я видел, как люди «администрируют» MS SQL Server. Next, next, next, finish, 30 баз на одном экземпляре. Производительность ужасная, оптимизаций нет, документации нет, лицензий нет, имени хоста нет, и статических адресов на NIC тоже, фаервол не настроен или вообще выключен, подключайтесь кто хочет. Зато есть бэкапы. Просто прекрасно. Так что эти люди PostgreSQL тем более освоить не смогут. То же касается и тех, кто тыкает мышкой в pgAdmin/DBeaver. А потом я постоянно слышу про то, что MS SQL Server потребляет очень много памяти. С одной стороны, это правда, все же он предназначен для более высокого уровня, чем PostgreSQL, так что там производительность достигается любой ценой. Но, с другой стороны, люди даже не попытались разобраться, почему так происходит, и не знают, к примеру, про существование такого параметра как Maximum server memory (который по умолчанию равен 2 TB). А дальше наши «специалисты» рассказывают сказки о том, что «PostgreSQL не соответствует требованиям бизнеса». На деле же это просто измененная фраза «Я тупой и не могу себя заставить учить Linux и PostgreSQL, и поэтому, чтобы не напрягаться, я подвожу себя и своих коллег под уголовную статью». Туда же можно отнести и фразы в стиле: «PostgreSQL не подходит для 1С (или подставляйте свое приложение), поскольку при объеме баз от N GB или при количестве клиентов от N единиц система начинает тупить». Это же программа виновата, что пользователь не научился с ней работать. Прочитав эту статью и проработав все основные параметры, вы уже понимаете, в чем проблема: эти параметры никто не настраивает. А потом они рассказывают про свой богатый опыт. Он действительно важен, с этим никто не спорит. Но наша профессия в первую очередь интеллектуальная, и без теории практика мертва. Результат вашей работы зависит в первую очередь от того, как вы учились.

Обращение к читателям

Большое спасибо вам за то, что дочитали эту статью до конца. Получилась она достаточно объемной. Надеюсь, что она была для вас полезной и что-то новое вы из нее вынесли.

Статью пришлось разделить на несколько частей, потому что платформа просто не вытягивает такой объем. Я выложил все части в примерно одно время, но готов поспорить, что последнюю (эту) часть прочитает в 10 раз меньше человек, чем первую. Я также специально разметил темы про производительность, автовакуум, чекпоинты и журнал предзаписи перед подключениями. Иначе вы бы просто научились работать с самим сервером, ролями, базами, а все остальное просто бы проигнорировали. Система же работает. Приложение базу видит. Так какой смысл учить все остальное, правда? Надеюсь, никто из вас не пропустил темы резервного копирования и модулей.

Также прошу меня понять, если я что-то где-то не досказал, сильно сократил или проигнорировал. Это не значит, что я глупый (хотя кто знает), просто я считаю это бесполезным именно для начинающих. К примеру, зачем вам знать организацию файлов WAL? Или что WAL можно разместить на другом диске? Или для чего вам индексы объектов БД? А язык SQL? Что вы будете делать с этой информацией? Вам и так нужно еще очень многое изучить, так что нет смысла тратить силы и время на то, с чем вы не будете работать (по крайней мере, на первых порах). Все, что я считаю важным для начинающих системных администраторов, уже написано. Аналогично с повторениями: я сделал это специально, поскольку это важная информация, которую вы должны заметить и запомнить. Ну и еще свою роль сыграло то, что я печатал статью на протяжении месяца, когда было свободное время.

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

Я прекрасно знаю, что есть mrazee, которые берут готовую информацию из статей и перепродают в своих курсах. Моя статья бесплатна для всех, потому что это open source, и я просто хочу внести хоть какой-то вклад. Почему именно habr? Потому что я и сам с него начинал, когда только школу заканчивал (без вот этих всех сказок про то, как я в 10 лет разработал свою видеоигру или веб-сайт). Плюс примерно 1/5 всех полезных статей я находил именно здесь. Я также прекрасно вижу, что здесь полно и бесполезных статей, к примеру, про небритых инвертировано-белых ИТ-директоров менеджеров с гор без технического образования, которые рассказывают сказки про KPI, CRM и прочую hujetu. Или очередной wyser про то, что системные администраторы уходят в прошлое, и все должны учить K8s и Ansible. А на практике мы получаем сисадминов с 15-20 летним стажем, которые ни разу не работали с Linux, фанатеют по Mikrotik/CISCO и не пишут документацию (не хочу никого обидеть, это просто собирательный негативный образ). Или, наоборот, юных дарований без технического образования после курсов, которые внедряют все подряд, безумно вбивая команды из статей и не разбираясь, работает ли система или нет, а если и работает, то как, а о том, что будет, если система перестанет работать, они даже не думают. Возможно, эти люди в каких-то моментах в техническом плане действительно хорошо разбираются. Но вот с точки зрения того, как это все должно быть устроено в организации, с точки зрения подхода и логики – просто тихий ужас. Проработают полгода-год, а затем уволятся и пойдут «наводить порядок» в другом месте. А потом нормальным людям придется сносить все это непотребство, потому что проще и быстрее все развернуть заново, чем пытаться разобраться.

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