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

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

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

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

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

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

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


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

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

https://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-ов.
Что делать дево псам? Ничего нового - стараться не привязываться к платформе, развивать программирование и понимание основ.