Здравствуй мой дорогой интроверт.
Ты пришёл в админство с целью поменьше общаться с людьми? Поздравляю тебя! Ты сильно ошибся, ведь твой путь в админы начнется с эникея, а никто не общается с пользователями больше других IT-шников, чем эникей. 50% работы эникея - это психологическая поддержка пользователей. Боится юзер неизвестного, боится, что сейчас нажмется кнопка, пропадёт отчет и юзеру попадёт за сорванные сроки. Почему он боится это отдельный разговор, тут могут быть разные причины кроме тупости.
Ты сейчас возмутишься, что это не твои проблемы и ты вообще только за мышки отвечаешь, но всем пофигу. Задача эникея, чтобы юзер был доволен (конечно в рамках разумного, про протирать пыль с клавиатуры юзера никто не говорит), а не только “комп работал”. Отсюда и растут скандалы “айтишники уроды поменяли программу, работать невозможно”. Конечно уроды, если не предоставили обучение или инструкции по использованию нового софта. Айтишники уроды, не могут помочь с формулой в excel. А еще айтишники “уроды”, потому что общаются с юзерами как с дебилами. Ну не нравится людям, когда им показывают, что они тупые, а если еще и хамят в добавок, то прям ужас ужас. Именно из-за мелкого хамства и надменного вида ты сидишь мой дорогой друг без премий и повышений, с репутацией хама и лентяя. Не выгнали тебя только потому что умеешь что-то делать, да начальник прикрывает. А репутация у тебя такая потому, что не любишь ты юзеров. А должен. Да, должен! Ты лицо IT отдела, а еще существо бесполое, бесправное и расходный материал без своего мнения. Хочешь уважения, больше денег и меньше юзеров? Засунь своё мнение, лень,усталость поглубже и вперед, прокачивать знания на курсах, домашних лабах и рабочих серверах и набирать стаж в трудовой, авось и тут премию выпишут. Конечно совсем без юзеров ты никогда не останешься, только они будут другими, например программисты или другие админы. Если ты подумал, что вот оно, нормальные люди, с которыми можно говорить на одном языке то вынужден тебя разочаровать, так бывает не всегда, но об этом в другой раз.

Интересная получается ситуация в отечественном IT.
Открыв портал с вакансиями типо suberjob.ru или rabota.ru мы обнаруживаем кучу вакансий “Системный администратор” с требованиями: уметь менять картридж, настроить сеть, администрировать винду, настраивать сетевые принтеры, AD DNS DHCP и, может быть, вам достанется в нагрузку сайт на LAMP стеке. У почтенной зажравшейся публики данные вакансии вызывают смех, однако с течением времени они закрываются - значит люди всё-таки находятся. Рассмотрим же, какими знаниями должен обладать типичный кандидат на такую вакансию. Начнем с первого пункта: уметь чинить принтер. Учитывая, что типичная, небольшая купи-продай организация не обладает мфу стоимостью больше 60к рублей, то обретение данного умения прямо пропорционально количеству вдыхаемого тонера. Админы же поумнее находят недорогой аутсорс по ремонту принтеров и радуются жизни. Тут мы подходим к первому не IT умению - уметь закупать товары и услуги. Вы скажите чего здесь сложного? Но если ваш начальник завхоз или бывший продажник\закупщик, то он с вас три шкуры снимет, заставит нарисовать 100500 таблиц со сравнениями (даже если поставщика всего два на весь город) и только потом подпишет счет, с видом что делает вам великое одолжение всей жизни.
Принтеры вроде чинятся, можно приступить к выполнению своих непосредственно админских обязанностей, например разобраться с сетью. Что же есть разбираться с сетью? Уметь настроить местный firewall, понимать часть опций DHCP, знать про маску, основной шлюз, основы маршрутизации итого примерно примерно четверть курса ICND от cisco. Сеть у нас вылизана и настроена, время заняться ОС. Вы видели количество сертификатов МС? В идеале наш админ должен обладать знаниями на 3-4 сертификата. По десктопной ОС, по серверной и по AD. Благо курсы и по сетям и по windows легко найти в открытом доступе или на торрентах и изучать, было бы время. В этом месте мы подходим ко второму не совсем админскому, но всем полезному скилу - тайм менеджмент. Конечно, есть отличная книга Т. Лимончелли - “Тайм менеджмент для системных администраторов” и я советую всем её прочитать, только вот если вы один она вас всё равно не спасёт без организации приема заявок от пользователей и какого-то прообраза ITIL. Да да. На 50 человек средней купи-продай какие-то части ITIL уже нужны, а именно CMBD (нам в любом случае надо вести учет), help desk aka система заявок ну и KEDB для себя и, в идеальном случае, пользователей.
Итак я перевел в скилы требования из вакансии. На самом же деле единственное требования к админу от нанимателя - всё должно работать! И никому не будет интересна глубина ваших знаний и сложности с которыми вы сталкиваетесь.
Вот и получается, что придя в контору вчерашним эникеем на низкую з\п мы получаем три варианта развития событий: 1)Эникей остается эникеем и решает проблему за счёт своих быстрых ног. 2)Эникей прокачивается в админа, приводит в порядок часть конторы на своё усмотрение и благополучно валит в более теплое место, не передав дела, а на его место приходит новый эникей. Новый же эникей опять переделывает половину ИТ в конторе, но уже на свой лад и далее по кругу. 3)Админ приводит всё в порядок, прокачивает навыки и остается например потому что ему 5 минут до дома, а потом начинает медленно деградировать, ведь очень немногие готовы делать стенды и изучать на них новые технологии для своего развития, да и чего ради? Всё и так работает.

Итого на первых двух раскладах мы получаем среднее качество IT сервиса в организации. Третий же случай лично мне не часто встречался. Что с этим делать? Да ничего. Некоторые организации всю свою жизнь будут малым бизнесом в силу тех или иных причин. Не надо хаять такие места, они просто есть и это отличные места для получения первичных навыков при правильном подходе. Не надо пытаться сделать ИТ в этой организации идеальным - времени уйдет много, а всё равно кроме вас и друзей админов никто больше не оценит. Выполняйте свою работу хорошо(как не делать плохо мы уже обсудили выше) и тогда возможно вас вспомнят тёплым словом, а если и не вспомнят, то фиг с ними. Ведь как говорится в известной книге: “Ты - это не твоя работа.” Помните об этом.

P.S. Знающий читатель скажет, что вместо эникейщика можно отдать ИТ на аутсорс и я согласен, что аутсорс для малого бизнеса зачастую удобнее, но подводных камней там не меньше.

А теперь немного другой взгляд на админа в средней конторе.
Не многие об этом пишут, но на фоне нытья "нет денег на железо, не повышают зп" написать об этом надо.
Зачем вообще нужен IT отдел на предприятии?
Обслуживать IT инфраструктуру предприятия. Зачем нужна IT инфраструктура предприятию?
Потому что в 1с делать баланс быстрее, чем в Книге учета доходов и расходов.
Потому что накидать аналитику в excel быстрее и удобнее, чем чертить табличку от руки. Быстрее = экономия времени, а время как известно - деньги.
Бизнес умеет (в большинстве своём) считать деньги, надо учиться и вам.
Пока вы говорите с руководством на птичьем языке "нууу бекапыы нужны" хер вам, а не новая железка. А вот "если сервер с 1с сдохнет, то восстанавливаться будет 10 часов и потеряем данные за последние сутки" звучит уже более уверенно и называется RTO/RPO.
После этого на стол кладуться два решения. Одно херовое и дорогое, другое ваше ( психология у руководителей такая, надо им из чего-то выбирать).
И к описанию этих решений кладутся новые цифры RTO/RPO которое обеспечит это решение. Только русским языком. "При смерти сервера с 1с мы будем восстанавливаться час и потеряем данные за 3 часа" уже звучит понятнее.
Хотите зарплату выше? А за что вам её поднимать, если и так всё работает. Но зарплату вы всё же хотите? Тогда так подумайте, как приносить больше пользы фирме. Возьмите логи (вы же их собираете), почитайте про дата сайнс, про анализ их, накидайте простой скрипт и отдайте эту аналитику отделу маркетинга.
Считаете, что надо автоматизировать раскатку рабочих мест? Подумайте как это повлияет на бизнес. Если в фирме большая текучка и время ожидания рабочего места сократится с 6 часов до часу, то это будет хорошим аргументом просить зп.
Главное правило: сначала сделай, потом проси.
Не прокатило выбить железку и уж тем более за аналитику никто даже спасибо не сказал - валите оттуда! Правило “не работайте с мудаками” никто не отменял.
А вот если прокатило, то продолжайте в том же направлении. IT не должно быть в компании обузой, вы должны стать драйвером роста компании (если конечно компании не приходят тендеры за откаты, но тут см пункт про мудаков), а там и до IT директора недалеко. Хотите быть просто сисадмином не в IT конторе? Значит будьте, страдайте и знайте, что рано или поздно вас заменят скриптом на хаскеле.

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

http://telegra.ph/Pochemu-zhe-izuchenie-modnyh-tehnologij-ne-ubivaet-v-vas-ehnikeya-02-05

В прошлый раз мы остановились на том, что необходимо себе задавать вопросы: Как? Почему?
Так вот, а почему вы решили, что эти вопросы надо задавать только себе?
http://telegra.ph/Kak-zhit-nachinayushchemu-adminu-v-okruzhenii-materyh-kolleg-04-10

Занятные мысли про русскую инженерную школу пишет канал “Человек и машина” https://t.me/manandthemachine/233
Дескать проблема русского инженера, что он всегда копает до самой сути, а в европейских компаниях сама суть не всегда и не нужна.
А есть ли проблема в инженере и стране, где он получал свои навыки?
У инженера есть сильная сторона - он копает до сути, это же и его слабая сторона - задача не завершена пока не докопали или пока управленец не остановил. Управленцем в данном случае может быть, как менеджер, так и тимлид. С другой стороны, есть команда, которая умеет вовремя остановиться и делает это сама, без участия управленца.
И вот мы получаем классическую проблему: человек не подошёл команде. Не по техническим знаниям, просто по характеру и отношению к работе.
Что делать инженеру? Качать self-managed скилы или искать другую команду. Что делать команде: учитывать такие вещи на собеседовании и более внимательно отбирать кандидатов. Однако разумнее привлечь к этому in-house HR или получить самим необходимые для найма компетенции. Тут мы приходим к вопросу о bigger picture. Хватает ли у вас вообще компетенции видеть происходящее в команде? Не упускаете ли вы за своей технической возней простые человечески мелочи, которые могут вредить команде?


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

А пока мне не пишется о bigger picture держите очередной пост.
На этот раз несмотря на название будут претензии к old school админам.

http://telegra.ph/Dlya-teh-kto-tolko-chto-k-nam-prisoedinilsya-07-04

Сегодня попробуем отойти от насущных эникейсих вопросов и обозрим более общую тему - бесполезность холивара OpenSource vs Enterprise.
TL;DR Разные задачи - разные решения, но всем похер, поэтому этот холивар будет вечным.
https://telegra.ph/Opensource-vs-Enterprise-02-12

Пока telegra.ph открывается только через прокси - попробуем писать на medium.
А порассуждаем мы сегодня над разницей в мышлении админов и програмистов.
https://medium.com/@mzguchkov/%D0%B0%D0%BC%D0%B8%D0%BD%D1%8B-%D1%81-%D0%BC%D0%B0%D1%80%D1%81%D0%B0-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%81%D1%82%D1%8B-%D1%81-%D0%B2%D0%B5%D0%BD%D0%B5%D1%80%D1%8B-a2c83b0b1020

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

https://medium.com/@mzguchkov/%D0%BA%D1%83%D0%BB%D1%8C%D1%82%D1%83%D1%80%D0%BD%D1%8B%D0%B9-%D0%B2%D0%B0%D0%BA%D1%83%D1%83%D0%BC-fef94e9a4c4a?sk=3e6213d73baccaed8b765454a61344a2

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

Почему писать скрипты на Python, а не Bash считается неким элитаризмом?

Особенность bash - читаемость скриптов падает прямо пропорционально количеству строк кода. Да, на python можно писать ужасно, однако для избежания этого есть PEP8, следуя которому ваш код будет читаемый. Поэтому в командах применяют правило: если скрипт на bash больше 50-100 строк кода, то его переписывают на python/golang.


Я пишу на golang, остальные херово пишут на bash, python и не прочтут мой код. Получается я буду мудаком для остальной команды?

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

Первый сложнее, но интереснее. Второй проще и легче. Третий вариант: оставить всё как есть и использовать bad pattern вместе с командой. Да, с точки зрения определений в этой команде будет культура. Только вот людей, кидающих мусор мимо урны, называют бескультурными, а людей оставляющих скрипты в cron без комментариев и уведомления коллег бескультурными не называют.



p.s.
Мои посты часто содержат очевидные вещи. Очевидные для специалистов, которые уже всё видели и для талантов, которые и сами до всего дойдут. Мне хочется, чтобы эти очевидные вещи доходили до спящих талантов. Тех, кто в силу воспитания, образования, круга общения и даже рекомендательных систем может не замечать этих очевидностей. Мне хочется показать им существование другого мира в который нужно стремиться и ради которого надо учиться и качать скиллы. Ведь если человек не знает, что есть море и купаться в нём интересно, он и не будет хотеть ради него учиться плавать.

Немного чужого контента. Он для тестировщиков, но переклиается с постами выше.
https://testitquickly.com/2019/07/16/numele-skimonosit/

Очень весело наблюдать, как люди хаят 1с за переизобретение костылей (1С: Центр Администрирования), а потом рассказывают о крутом CI/CD для Kubernetes или том же Helm.

Вы либо трусы наденьте, либо крестик снимите.

Я еще тут. И хочу поговорить с вами про аутсорсинг.
https://telegra.ph/Pro-greblyu-na-galerah-10-12

Поговорим сегодня о том как неправильно внедрять DevOps и возможно начать по-другому относиться к коллегам.

https://telegra.ph/Kak-nepravilno-vnedryat-DevOps-12-25

Если вы хотите больше узнать про DevOps, то приятного прослушивания.
https://linkmeup.ru/blog/584.html

Если вы хотите сами рассказать о DevOps, то у нас открыт приём заявок на доклады!
https://cfp.devopsconf.io

А сегодня мы порассуждаем о SRE. На этот раз в видео формате. https://youtu.be/g7ysWOhWxwE

Kubernetes в его текущем использовании тупиковая ветвь развития отравляющая индустрию.

В человеческую оперативную память влезает 5-7 абстракций одновременно.
Данное свойство принято называть кошелёк Миллера. В википедии написано 7 плюс минус 2, но чаще всего это именно 7, а не 9.
Считаем основные абстракции kubernetes : pod, service, deployment, configmap, ingress. Уже 5. Ещё несколько абстракций добавит ваш CI и всё - кошелёк Миллера в вашей голове полон.
Отсюда получаем, что человек занимающийся kubernetes не может заниматься ни чем кроме kubernetes и чуть чуть CI. Так что современные DevOps одновременно и эникейщики для программистов и рабы kubernetes.

Продвинутые компании стараются прятать абстракции kubernetes, делая внутренние heroku like платформы.
Это даёт возможность ещё проще запускать новые приложения и уменьшить затраты на kubernetes DevOps-ов.
Что делать дево псам? Ничего нового - стараться не привязываться к платформе, развивать программирование и понимание основ.