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