anykeynotes

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

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

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

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

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

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

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


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

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

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



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

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

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

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

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

Здравствуйте, дорогие мои. Сегодня мы поговорим о мудаках и мудацких решениях в IT.
Дабы не травмировать обилием некрасивого слова мудак у нас будет чудак, а мудацкое – чуднОе.
Называть чудаком предыдущего админа конторы - добрая традиция всех начинающих и уже опытных админов. Приходит такой админ на новое рабочее место и давай разносить, всё что было построено непосильный трудом: он витуху 2-ух парную кинул, вот же чудак! А у него контроллер домена еще 2003р2 в 2016 году! А у него бекапы батниками! А у него вообще всё на винде, не умел в линукс чудак! А у него программный рейд на винде! Это одни из множества комментариев, которые можно услышать или сказать устроившись на новое место. Конечно, зачастую они будут по делу, но, как всегда, могут быть нюансы. Допустим вы страшно негодуете на чудака, что проложил сеть 2-ух парным кабелем, прям возмущаетесь, но не знаете, что ваш предшественник очень хотел нормальную cat 5e и гигабитную сеть, но, когда начальство увидело прайс на прокладку всего офиса 2-ух парным и 4-ёх парным проводом, то решило сэкономить и взять 2-ух парный. Или вот допустим бекапы батниками: база 1с, да файловая помойка, настроил и забыл, зачем плодить лишние сущности решил человек и так и оставил. Бекапится? Бекапится! А то что не модно, ну так уж извините. А вы его чудаком. Есть и более интересные варианты, например, комп, который стоял под ногами главбуха тёти Клавы и служил сервером древней программы отчётности для всей бухгалтерии, а узнаете вы о нем только когда он умирает и вы совершенно обоснованно кричите в бессильной злобе чудак.
Однако подумайте вот о чем. А сколько у вас таких костылей? А сколько из них задокументировано и сколько обосновано решением начальства, внешними факторами сколько было костылей сделано потому что лень делать нормально? А вы уверены, что пришедший за вами не будет вас вспоминать по матушке? Отдельного разговора заслуживают гос организации и прочие любители тендеров. Сложно решать уравнение из трёх неизвестных, бюджет, хотелки руководства и долгосрочные планы. Ведь зачастую бывает, что на момент прихода железа меняются и цели, и хотелки, а то и руководство, так что не спешите огульно хаять всех чудаками и бросаться всё переделывать, ни одного хорошего админа сгубили эти привычки, да и в глазах работодателя вы будете выглядеть очередным чудаком, впрочем это уже совсем другая история.