В прошлый раз мы остановились на том, что необходимо себе задавать вопросы: Как? Почему?
Так вот, а почему вы решили, что эти вопросы надо задавать только себе?
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-ов.
Что делать дево псам? Ничего нового - стараться не привязываться к платформе, развивать программирование и понимание основ.