Pull to refresh
0
0

Системный администратор

Send message

Мои глаза. Да не волнуйтесь вы так, пишите нормально. Ай ти инду стрия в ах уе. Ну да ладно, не важно. Важно ведь содержание. Отвечаю по пунктам:

1) В этой статье описаны только базовые вещи и порядок их изучения. Все остальное - самостоятельно. Очень тяжело выучить IP-телефонию, если человек не знает компьютерное оборудование и сети. Знаю по себе. То же и про сайты, и про программирование, и про специфичные программы (к примеру, тот же БАРС в медицине). То же и про видеонаблюдение, и про СКУД. Про компании, кол-во сотрудников и т.п. рассуждать нет смысла.

2) PostgreSQL не заменит никогда ни MS SQL Server, ни Oracle DB, особенно в крупных системах. И это не потому, что он плохой. Просто он другой. Представляю, как у какой-то организации N есть 1000 баз на том же Oracle DB по 1 TB каждая (в среднем). Сколько баз можно будет перенести на PostgreSQL? 10? 50? Но не более.

15 "террабайт" это про суммарный объем всех баз или про объем одной? В любой случае, нет. У меня всегда просто много маленьких баз, раскиданных по разным экземплярам.

3) Если вам действительно нужны возможности PostgresPRO - то всегда пожалуйста. Но большинство может обойтись обычным PostgreSQL.

4) Да, все верно. Я из отпрыск мелкого и нищего бизнеса. Но опять же: лицензии - это деньги. Мы их потратим, хорошо. А это окупится? Если да - флаг в руки. Если нет - проект закрываем. Значительная часть бизнеса покупала M$ просто потому, что большинство сисадминов не могли себя заставить учить Linux и тот же PostgreSQL. Да, раньше PostgreSQL до версии 9.5-10 по сравнению с MS SQL Server в той же 1С был куском известно чего. Но теперь ситуация стабилизировалась.

5) Нет, все компании я не опрашивал. Но вот практически все, с которыми приходилось иметь дело, считали, что у них HL.

Таких компаний, как ваша, не сильно много. 95% - это не более 200 АРМ и 2-3 ИТшника. Никакой специализации там нет. Считайте это ответом на другие ваши вопросы про высокие нагрузки и т.п. Хотя PostgreSQL не виноват в том, что пользователи не читали документацию и не умеют с ним работать. Куча статей по оптимизации параметров для конкретных приложений есть, да и смотря, какое приложение. Если приложение наплодило по 100 временных таблиц для каждого пользователя - это не вина СУБД. Если админ не настроил очистку, не делает vacuum full и reindex, а потом базы распухли, то это вина админа, а не СУБД.

Админ SQL (по всей видимости, MS SQL Server) не знает, что такое маска подсети, и вы его взяли. Все понятно с вами. А бухгалтеров, не знающих, что такое ИНН, у вас не берут?

Формулировки в стиле "Стоимость лицензий не имеет значения" обычно подразумевают пиратство, я такое уже видел. А потом уволенный сисадмин пишет куда надо заявление, проходит по делу как свидетель, а компании выставляют чудовищные штрафы и руководство ищет козла отпущения среди нынешних сотрудников. Да, друзья, учите MS SQL Server на здоровье.

Обожаю словосочетание "High Load". Каждая компания думает, что у нее HL, покупает MS SQL Server, но не обновляет оборудование. Классика.

Большое спасибо за большой комментарий. Но что именно вы сказать-то хотели? Я не совсем улавливаю смысл.

Про личные качества уже все сказал в первой части.

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

У меня тоже пачка интересных историй есть, даже несмотря на то, что опыта откровенно мало. Например, как на собеседовании я пытался доказать одному руководителю ИТ отдела, что типовые конфигурации 1С нормально работают с PostgreSQL, после моего вопроса о том, что у них с лицензированием MS SQL Server. Ответа я так и не получил, а потом вдруг выяснилось, что лицензий нет, равно как и нет технического образования у этого индивида. Собеседования это, в одном случае из трех, просто тихий ужас. Делают вид, что у них все прекрасно, и что это ты пришел выпрашивать работу, а на испытательном сроке оказывается вдруг, что документацию съела собака, а в техническом помещении мышь повесилась.

Ну ладно, везде все по-разному, так что выносить сор из избы я не буду. Прежде всего потому, что это выглядит однобоко, и неплохо было бы опросить все стороны конфликта. Думаю, в интернете на том же пикабу можно найти кучу интересных историй. Я уже намекал на все это в первой части: "Вы еще успеете познакомиться с неприятной стороной работы" - или как-то так.

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

Личные качества нельзя наработать за счет чтения книг, только личный опыт.

Отслеживание нагрузки на всю физическую сеть - да, полезно, куча инструментов существует, и с ними надо учиться работать. Но другой вопрос: а оно действительно необходимо? Забегая вперед: да.

Но есть две крайности: крайне низкая и крайне высокая пропускная способность сети (т.е. сильно ниже или выше необходимого, к примеру, на клиентах 10Мб и 1Гб, включая сетевые интерфейсы и сами кабели), так что там пытаться что-либо мониторить бесполезно и бессмысленно, потому что в первом случае просто ничего не сделаешь, и придется перестраивать ЛВС, а во втором случае можно просто забить.

Отмечу также, что ЛВС - это вещь с очень высоким сроком эксплуатации, в отличие от того же ПО. И заложив в условном 2020 году 1 - 2,5Гб на клиентах, на нем можно будет сидеть вплоть до 2050 года, потому что больше просто не надо.

300 страниц сложного технического текста - это ни о чем, на самом деле, если есть время и силы.

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

Изучал разработку конфигураций по книге Радченко и Хрусталевой:

1С:Предприятие 8.3.22, Практическое пособие разработчика.

И понял, что "это", мягко сказать, очень далеко от сферы ИТ, и лучше бы "это" оставить специальным людям, которые специализируются именно на 1С.

Спасибо за ваш подробный и развернутый комментарий. Я полностью согласен со всем вышенаписанным.

За винду вас сейчас закидают тапками адепты свободного сообщества.

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

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

Вот советы из личного опыта, может, кому пригодятся:

1) Одевайтесь как нормальный белый человек, а не как чмошник или студент. По одежке встречают.

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

3) Будьте нормальным мужиком, а не маминой радостью.

4) Научитесь корчить серьезную и недовольную рожу. Научитесь показывать зубы.

5) Несите ответственность за свою жизнь и поступки. Вы самостоятельное многоклеточное существо, а не амеба.

6) Будьте дисциплинированным, все делайте вовремя и по порядку. Требуйте того же и от остальных.

7) Гнобите всех тех, кто это заслужил. Безумных студентов, вайтишников, девопсов и т.п.

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

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

10) Не будьте наивным.

11) Умейте распознавать ложь.

12) Сами не лгите или хотя бы не попадайтесь на лжи.

13) Не общайтесь просто так с кем попало. Умейте отделять своих от чужих. Представьте, что у нас кастовое классовое общество, потому что от общения с людьми вас потом будет тошнить.

14) Не рассказывайте подробности о своей или чужой жизни и не сплетничайте.

15) Уважайте тех, кто это заслужил. Не будьте бунтарем и выньте шило известно откуда, остепенитесь.

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

Для всех:

Администрирование платформы и разработка конфигураций - это разные вещи. Сисадмину нужно знать администрирование, а разработчику 1С - и администрирование, и разработку. Все. Ситуация, как и с СУБД или разработкой сайтов. Оставляйте это специалистам по другим направлениям.

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

Вижу, что вы по направлению M$ и всего далее проприетарного. Как вы считаете, должны ли сисадмины учить Linux и open-source решения? Должны ли организации, если возможно, переходить на open-source альтернативы? К примеру, на те же PVE и PostgreSQL?

Проводите ли вы аудиты соответствия лицензионным соглашениям (для ПО)?

У вас карьера сложилась вот так, но это не значит, что у всех остальных она сложится также. Видимо, это вина блогеров и манагеров по типу Рудя и ему подобных, которые рассказывают про прелести проприетарного ПО, но сами в 30-40 лет толком не читали книг и не работали с Linux и open-source решениями в целом.

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

Ну, это хоть что-то. Тогда времена другие были, так что не могу вас судить.

У меня к вам есть вопросы по MS SQL Server и Exchange, раз вы их так выпячиваете. Сразу уточню, что я по ним читал книги, но в продуктивной среде с ними не работал, только в тестовой (еще до 2022 года).

Организации в принципе могут обойтись без них?

Какие сервисы требуют в роли СУБД только MS SQL Server?

Какие альтернативы (бесплатные или платные) есть у Exchange?

Ваше мнение про лицензирование?

Также вопросы немного вбок:

Работали ли вы с Hyper-V?

Ваше мнение о книге по Powershell?

Работали ли вы с PostgreSQL, PVE, Zabbix и какой-либо почтовой системой, отличной от Exchange? Если да, то что можете о них сказать?

А что насчет книг? Вы специально пропускаете целые куски моих сообщений или что?

"Сборник наивных глупостей" - это не критика, это просто мнение. На каких примерах? Про WSUS и Veeam? Можем уйти в темы PostgreSQL и Proxmox VE, но я уже и так в статье сказал о них все, что хотел. Дальше просто надо учить.

Список рекомендуемой литературы есть в самом конце первой статьи. Можете нажать комбинацию Ctrl+F и ввести слово "книг" - так вы найдете все книги в статьях.

Вы упомянули курсы. Как вы считаете, есть ли от них польза? Какие платные/бесплатные курсы вы проходили?

Все еще жду от вас ответа касательно книг.

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

Объяснили бы лучше, чем статья плоха, с чем именно вы не согласны и почему, а не самоутверждались бы за счет других, устраивая технические опросы через интернет. А еще лучше: написали бы свою разоблачительную статью, или описали бы свой бесценный опыт работы с учетными записями AD через PS.

Я просто не могу понять логику таких людей. Что именно вас оскорбляет? То, что я рекомендовал nano вместо вашего боготворимого vim (или, что еще хуже, vi)? То, что я назвал людей без профильного образования и вкатышей с курсов недочеловеками или что? Или что я прошелся катком по девопсам, блогерам и лжецам?

Давайте начнем с простого. Чтобы не засорять комментарии и дать читателям больше полезного. Вы читали обе части статей, и, вероятно, обратили внимание на книги, которые я рекомендую к прочтению. Какие из них вы читали (может, старые или более новые издания)? Какие книги вы бы убрали, а какие добавили? Или может, опровергните полезность чтения книг в целом?

1) Ваша речь тоже не чиста. Сейчас тупые дети предпочитают употреблять слова "душный", "токсичный" и т.д.

2) Я писал про бесплатную версию Veeam в первой части статьи. Если не ошибаюсь, при развертывании клиентов на серверах, там одна лицензия считается как три, но я не уверен. Надо уточнять.

3) Не могу в двух пассажах рассказать все, что знаю. Лучше обратитесь к документации и книгам. WSUS все еще дрыгается, поддерживается и сносно работает. На WS 2022 точно в домене с 2016 уровнем леса. Может, подвох в AD? Просто с 2008 версии она переименована в AD DS. Или вы про СУБД? Так я использовал WID, его достаточно, даже не стал смотреть в сторону MS SQL Server. Да, база пухнет и ее приходится время от времени вручную чистить (просто удалять все файлы в директории). Или вы про процесс получения обновлений? Скажу так, последние пару лет наблюдаются определенные проблемы, но их я решил. Конечно, можно было бы просто забить и настроить службу обновлений через групповые политики, к примеру. Но ресурсы физической сети не бесконечны, а перестроить ее очень дорого и долго. Также у меня нет 10000 клиентов, так что я просто не знаком с возможными проблемами в больших системах.

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

Снова присасываетесь к словам? Насколько мне известно, роль только одна - WSB. Не знаю, есть ли еще. Чем она плоха для бэкапа AD DS?

Все еще жду нормальной критики статьи. А то я смотрю в интернете все умные, в любой момент можно найти ответ в интернете.

Бывает. Но ничего страшного, гайки крутить и канавы рыть тоже кто-то должен.

Windows/Linux - сравнение некорректное, я описал для чего конкретно используется и то, и другое. То же и про дистрибутивы Linux.

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

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

Barman - для PostgreSQL лучшее.

UrBackup и Amanda - лучшее для бэкапа клиентов из бесплатных.

Borg и Restic - для бэкапа серверов Linux.

Ну и Windows Server с AD DS можно бэкапить встроенными решениями, они тоже имеют право на жизнь и бесплатны.

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

Нашли один недочет в статье на 10 тысяч слов, прекрасно. Есть чем гордится. Можете еще поискать?

Критики от вас я так и не увидел. Это не критика. Если бы постарались объяснить, что именно не так и, что самое важное, почему, то это была бы критика, а не просто "Статья ни о чем, автор дурак".

Очередной девопес? Уже видно по характеру написания текста. Откуда вы такие беретесь?

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

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

У вас все в порядке? Сначала вы написали про "европейскую философию", а теперь и вот это. Просто невероятно.

Information

Rating
Does not participate
Location
Челябинск, Челябинская обл., Россия
Registered
Activity