В моей организации я работаю с группой сотрудников NOC, подающими надежды младшими инженерами и несколькими старшими инженерами; все с упором на Linux. Один интересный шаг на пути к развитию талантов в компании заключается в том, что есть путь от NOC до высших инженерных должностей. Рассматривая кадровый резерв как относительного новичка, я вижу, что есть разделение в наборах навыков, которое имеет тенденцию расти со временем ...
Различие между некоторыми сотрудниками заключается в том, насколько хорошо они используют методологии создания сценариев, автоматизации и управления конфигурациями. Например, у нас есть два инженера, которые занимаются большей частью Amazon. AWS CloudFormation работа, и другой, который обрабатывает большую часть Кукольный инфраструктура. Возможно, четверть инженеров имеют большой опыт в написании сценариев оболочки BASH.
Глядя на это в контексте невероятно высокий спрос на DevOps-навыки на рынке трудаМне любопытно, как другие организации способствуют развитию этих навыков и расширяют свои внутренние таланты. Сценарии не кажутся особенно обучаемой концепцией.
• Как сисадмин может улучшить свои сценарии оболочки?
Практика, смешанная с драйвом. Звучит банально, но надо хотеть чтобы поправиться, помимо практики. Если вам не очень нравится писать сценарии, вы можете быть вынуждены делать это годами, когда вам нужно, и никогда не добьетесь успеха. Если вы этого не сделаете хотеть Чтобы поправиться, вы можете каждый день сидеть на работе рядом с лучшим сценаристом в мире и не набирать часть навыков, которыми вы могли бы обладать.
Я знаю тех людей, которые, несмотря на работу в IT, упорно отказываются изучать какой-либо сценариев. Этим людям скоро не будет места в этой индустрии. Они часть умирающего поколения.
(Я не говорю о стариках, я имею в виду образно. :П)
• Есть ли еще место для инженеров, которые не поддерживают / не могут придерживаться парадигмы DevOps?
Нет. Все, что они делают, может быть и в конечном итоге будет автоматизировано.
Я бы сказал, что, возможно, нам вообще не стоило называть их «инженерами». Достаточно плохо, что ИТ-индустрия присвоила себе слово «инженер», что, на мой взгляд, оскорбительно для актуальный инженеры, которые годами обучались программам высшего образования и получали юридические сертификаты, чтобы они могли проектировать мосты, небоскребы, адронные коллайдеры и т. д. настоящий инженеры.
Но есть сходство ... Если вы хотите называть себя «инженером» в ИТ-индустрии, то это, по крайней мере, означает, что вы Создайте вещи. Ты изобретательный и вы соединяете точки новыми способами, о которых никто никогда раньше не думал. Вы создаете вещи, о которых никто не знал, насколько они ценные, пока вы их не сделали.
Если вы не кодируете или не пишете сценарии, то вы не сможете ничего сделать с компьютерами, кроме как просто поддерживать их и, возможно, установить пакет программного обеспечения или два. Может, закинуть новый жесткий диск в старый MSA. И в этом случае я бы назвал вас администратором, но не обязательно инженером. И я бы сказал, что большая часть вашей работы находится под угрозой автоматического удаления.
• Неужели мы просто предполагаем, что некоторые люди останутся позади по мере развития этих технологий?
Рынок адаптируется. Может случиться так, что некоторые люди не будут получать шестизначную зарплату, если они на самом деле не заслуживают ее, что довольно часто случается в этой отрасли.
Я считаю, что креативность, а не только навыки программирования / написания сценариев, является ключевым фактором. Это то творчество, о котором вы должны сказать себе: "Ой, я мог бы это автоматизировать!"и тогда навык вступает в игру только после этого. Если вы обнаружите, что пишете что-то только после того, как начальник скажет вам об этом, у вас может не быть того драйва или творчества, о которых я говорил ... и это два качества, которым очень трудно, а может быть, и невозможно научить.
У меня есть преимущество в понимании размера и сложности вашей среды. Видя, как вы работаете на облачного провайдера / хостинг-провайдера, можно с уверенностью предположить, что у вас большое количество сред малого и среднего размера (10-100 серверов). Конечно, есть ежедневные задачи, которые выполняет младший. повторяющиеся инженеры и сотрудники NOC (создание учетных записей пользователей, настройка агентов резервного копирования и т. д.). Точно так же, вероятно, есть некоторые ручные операции, которые выполняет sr. инженерам нравится устанавливать ESXi на новое оборудование или настраивать такие вещи, как MPIO, или устанавливать модули VMware для определенных наборов оборудования. Все это можно и нужно автоматизировать.
Если ваш персонал способен выполнять основную часть своей рабочей нагрузки без автоматизации, то, на мой взгляд, вы перегружены штатом. Любой ИТ-персонал, который может работать полный рабочий день, состоящий в основном из ручных процессов, не имеет мотивации автоматизировать. Зачем изучать новый навык, который не рассматривается как нужно и может даже быть страшно? В конце концов, необходимость - это мать инноваций.
Итак, в какой-то момент в вашей организации вы вырастете до размеров, в которых вы запутаетесь и развалитесь, или вы начнете автоматизировать почти все и преуспеть. Безусловно, здесь должны руководить старшие инженеры и, возможно, даже работать с младшими инженерами и персоналом NOC для автоматизации некоторых их рабочих нагрузок. Это дает младшему. инженерам предоставляется возможность иметь основу для работы с множеством скриптов, которые они могут настраивать для каждого клиента и новой версии оборудования по мере необходимости. Это избавляет от пугающей мысли: «Боже мой, с чего мне вообще начать?» из уравнения и дает им толчок к решению настоящий проблема. Это подводит меня к моему последнему пункту. Книги и примеры хороши и хороши, но нет ничего, что могло бы заменить чувство выполненного решения актуальный проблема, с которой они сталкиваются. Дайте им цель, например, на всех новых серверах для клиента x должны быть установлены определенные модули ESXi, а затем работайте с ними для ее достижения. Затем адаптируйте сценарий для работы в мультитенантной среде.
Как сисадмин может улучшить свои сценарии оболочки?
По нуждающийся к, как описано выше.
Есть ли еще место для инженеров, которые не поддерживают / не могут придерживаться парадигмы DevOps?
Несомненно, есть множество организаций, которые не могут или не захотят перейти на методологию DevOps. Кажется, их становится все больше и больше скучный варианты, но тем не менее они варианты.
Неужели мы просто предполагаем, что некоторые люди останутся позади по мере развития этих технологий?
Как и с любой новой технологией - да.
tl; dr Вам никогда не придется вкладывать деньги в изучение этого, пока они не увидят в этом ценность. Если они могут выполнять свои ежедневные задачи вручную, значит, вы перегружены кадрами и у вас нет стимула.
Как сисадмин может улучшить свои сценарии оболочки?
Как стать лучше в чем-либо? Читайте книги, посещайте занятия, а затем применяйте изученные принципы. (Или комбинацию методов.) Это намеренно упрощено, поскольку нет ничего особенного в изучении сценариев вместо обучения тому, как готовить или ремонтировать машину.
Есть ли еще место для инженеров, которые не поддерживают / не могут придерживаться парадигмы DevOps?
На это трудно ответить в рамках этого сайта (где есть требование четких / определенных ответов на заданные вопросы). Мы можем предсказать, что это будет, но есть проблемы с моделью DevOps. Я чувствую, что одному человеку очень сложно быть очень опытным в обеих дисциплинах. Экономия затрат на сотрудника «2 к 1» сейчас очень привлекательна для бизнеса, но трудно сказать, сохранится ли эта тенденция. Это, конечно, на короткий срок.
Неужели мы просто предполагаем, что некоторые люди останутся позади по мере развития этих технологий?
При нынешних темпах развития событий - да. Большинство из вас, вероятно, наблюдают это на своих рабочих местах. Вам определенно следует следить за списками вакансий и знать, что в настоящее время требует рынок. (В вашем районе много объявлений о вакансиях по Hadoop? Изучите Hadoop.) Если вы не успеваете за рынком, вы рискуете остаться позади.
Обычно не отправляют младших инженеров в сложную производственную среду, критически важную. Для этого у вас есть старшие инженеры. Младшим рангам должно быть разрешено работать в песочницах для разработки и тестирования.
Если вам нужен инженер для Technology X и вы хотите выполнять эту роль внутри компании, найдите кого-нибудь, кто хочет его изучить, найдите структурированное обучение и объедините их.
Выясните, какие навыки вам нужны в отделе. Найдите кого-нибудь, кто захочет их изучить. Обучайте / Раздайте деньги на обучение.
Есть ли еще место для инженеров, которые не поддерживают / не могут придерживаться парадигмы DevOps?
DevOps - это новое слово для обозначения того, чем сисадмины занимались десятилетиями.
Неужели мы просто предполагаем, что некоторые люди останутся позади по мере развития этих технологий?
Наоборот. Со временем потребность в технических специалистах становится все больше и больше. Любому, у кого есть инженерные знания и технические навыки, будет где работать.