Как администратор Linux может улучшить свои навыки написания сценариев и автоматизации оболочки?

В моей организации я работаю с группой сотрудников NOC, начинающими младшими инженерами и несколькими старшими инженерами; все с упором на Linux. Один интересный шаг в развитии талантов компании заключается в том, что есть путь от НОК до старших инженерных чинов. Рассматривая пул талантов в качестве относительного новичка, я вижу, что в наборах навыков есть расхождение, которое имеет тенденцию расти со временем ...

• Есть инженеры, которые хорошо знают одну или несколько конкретных технологий и постоянно погружены ... например, MySQL, брандмауэры, хранилище SAN, балансировщики нагрузки ...
• Есть другие, которые являются универсалами и могут ориентироваться в нескольких технологиях.
• Все изучают достаточно Linux (команды, процессы), чтобы делать то, что им нужно, и использовать ежедневно.

Различия между некоторыми сотрудниками заключаются в том, насколько хорошо они используют методологии сценариев, автоматизации и управления конфигурациями. Например, у нас есть два инженера, которые выполняют основную часть работы Amazon AWS CloudFormation , и еще один, который занимается большей частью инфраструктуры Puppet . Возможно, четверть инженеров имеют большой опыт в написании сценариев в BASH.

Глядя на это в контексте невероятно высокого спроса на навыки DevOps на рынке труда , мне любопытно, как другие организации способствуют развитию этих навыков и развивают свой внутренний талант. Сценарии не кажутся особенно обучаемой концепцией.

• Как системный администратор может улучшить свои сценарии оболочки?
• Есть ли еще место для инженеров, которые не / не могут идти в ногу с парадигмой DevOps?
• Должны ли мы просто предполагать, что некоторые люди останутся позади по мере развития этих технологий? Все хорошо?

У меня есть преимущество в понимании размера и сложности вашей среды. Поскольку вы работаете в облачном / хостинг-провайдере, можно с уверенностью предположить, что у вас есть большое количество сред среднего размера (10-100 серверов). Есть, конечно, ежедневные задачи, которые выполняются младшим. повторяющиеся инженеры и сотрудники NOC (создание учетных записей пользователей, настройка агентов резервного копирования и т. д.). Точно так же есть, вероятно, некоторые ручные вещи, которые делает sr. такие инженеры, как установка ESXi на новом оборудовании или настройка таких вещей, как MPIO или установка модулей VMware для определенных наборов оборудования. Все эти вещи могут и должны быть автоматизированы.

Если ваш персонал способен выполнять большую часть своей рабочей нагрузки без автоматизации, то, на мой взгляд, вы перегружены. Любой ИТ-персонал, который может работать полный рабочий день, состоящий в основном из ручных процессов, не имеет мотивации для автоматизации. Зачем изучать новый навык, который не считается необходимым и даже может быть страшным ? В конце концов, необходимость является матерью инноваций.

Таким образом, в какой-то момент в вашей организации вы достигнете размера, в котором вы будете колебаться и разваливаться, или вы начнете автоматизировать почти все и преуспеть. Конечно, старшие инженеры должны быть ответственными за работу здесь, и, возможно, даже работать с младшими инженерами и сотрудниками NOC, чтобы автоматизировать часть их рабочей нагрузки. Это дает младший. у инженеров есть возможность работать со множеством сценариев, с которыми они могут настраиваться для каждого арендатора и новой версии оборудования по мере необходимости. Это устраняет пугающую мысль о "Боже мой, с чего мне начать?" из уравнения и дает им толчок к решению реальной проблемы. Что подводит меня к моей последней точке. Книги и примеры хороши и хороши, но естьпроблема, с которой они сталкиваются. Дайте им цель, как будто на всех новых серверах для арендатора x должны быть установлены определенные модули ESXi, а затем работайте с ними для достижения этой цели. Затем адаптируйте скрипт для работы в многопользовательской среде.

Как системный администратор может улучшить свои сценарии оболочки?

По необходимости , как описано выше.

Есть ли еще место для инженеров, которые не / не могут идти в ногу с парадигмой DevOps?

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

Должны ли мы просто предполагать, что некоторые люди останутся позади по мере развития этих технологий?

Как и с любой новой технологией - да.

tl; dr У вас никогда не будет никого, кто действительно вкладывает деньги в его изучение, пока они не увидят ценность в этом. Если они могут выполнять свои ежедневные задачи вручную, то у вас слишком много персонала, и нет никаких стимулов.

• Как сисадмин улучшает свои сценарии оболочки?

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

Я знаю тех людей, которые, несмотря на работу в IT, упорно отказываются изучать какой-либо сценариев. Скоро этим людям в этой отрасли не будет места. Они часть умирающего поколения.

( Я не говорю о стариках, я имею в виду это в переносном смысле.: P )

• Есть ли место для инженеров, которые не / не могут идти в ногу с парадигмой DevOps?

Нет. Все, что они делают, может быть и в конечном итоге будет автоматизировано.

Я бы сказал, что, возможно, нам никогда не следовало бы называть их «инженерами». Это достаточно плохо , что ИТ - индустрии присвоили слово «инженер» для себя, на мой взгляд , это своего рода оскорбление для реальных инженеров , которые потратили годы на программы высшего образования и получать юридические сертификаты , чтобы они могли проектировать мосты, небоскребы, адронных коллайдеров и т.д ... это настоящие инженеры.

Но есть сходство ... Если вы хотите назвать себя «инженером» в ИТ-индустрии, то это по крайней мере означает, что вы создаете вещи. Вы изобретательны, и вы соединяете точки новыми способами, о которых раньше никто не думал. Вы создаете вещи, которые никто не знал, насколько ценными они будут, пока вы не сделали это.

Если вы не пишете код и не пишете сценарии, то вы ничего не можете сделать с компьютерами, кроме как просто поддерживать их и, возможно, установить один или два программных пакета. Может быть, бросить новый жесткий диск в старый MSA. И в этом случае я бы назвал вас администратором, конечно, но не обязательно инженером. И я бы сказал, что большая часть вашей работы находится под угрозой автоматизации.

• Должны ли мы просто предполагать, что некоторые люди останутся позади по мере развития этих технологий?

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

Я считаю, что креативность, а не только навыки написания кода / написания сценариев, является ключевым фактором. Это то творчество, которое вы должны сказать себе: « О, эй, я мог бы автоматизировать это! », И тогда навык вступает в игру только после этого. Если вы обнаружите, что пишете что-то, только после того, как ваш босс скажет вам об этом, то у вас может не быть той тяги или той креативности, о которой я говорил ... и это два качества, которые очень трудно, возможно, невозможно преподавать.

Как системный администратор может улучшить свои сценарии оболочки?

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

Есть ли еще место для инженеров, которые не / не могут идти в ногу с парадигмой DevOps?

Это трудно ответить в рамках данного сайта (там, где есть требование четких / определенных ответов на заданные вопросы). Мы можем предсказать, что так и будет, но есть проблемы с моделью DevOps. Я чувствую, что одному человеку очень трудно быть чрезвычайно опытным в обеих дисциплинах. Экономия средств сотрудника 2 на 1 сейчас очень привлекательна для бизнеса, но трудно сказать, сохранится ли эта тенденция. Это конечно на короткий срок.

Должны ли мы просто предполагать, что некоторые люди останутся позади по мере развития этих технологий?

При нынешних темпах, как идут дела, да. Большинство из вас, вероятно, наблюдают это на своих рабочих местах. Вы должны определенно следить за списком вакансий и знать, чего требует рынок в настоящее время. (В вашем регионе много списков вакансий для Hadoop? Изучите Hadoop.) Если вы не успеваете за рынком, вы рискуете остаться позади.

Как правило, младших инженеров не отправляют в сложную производственную среду, которая является критически важной. У вас есть старшие инженеры для этого. Младшие ранги должны быть допущены к работе в тестовых песочницах dev / test.

Если вам нужен инженер по технологии X и вы хотите выполнять роль внутри компании, найдите кого-то, кто хочет научиться этому, найдите структурированное обучение и объедините их.

Выясните, какие навыки вам нужны в отделе. Найдите кого-то, кто хочет выучить их. Учим / Раздаем деньги за обучение.

Есть ли еще место для инженеров, которые не / не могут идти в ногу с парадигмой DevOps?

«devops» - это просто новое слово для того, что сисадмины делали на протяжении десятилетий.

Должны ли мы просто предполагать, что некоторые люди останутся позади по мере развития этих технологий?

Наоборот. Со временем все больше и больше людей нуждаются в технических людях. Любой, имеющий какие-либо инженерные знания и технические навыки, найдет место для работы.