Як адміністратор Linux може покращити свої навички сценаріїв оболонок та навички автоматизації?

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

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

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

Дивлячись на це в умовах надзвичайно високого попиту на навички DevOps на ринку праці , мені цікаво, як інші організації сприяють розвитку цих навичок та зростають внутрішній талант. Сценарій не виглядає як особливо зрозуміла концепція.

• Як sysadmin покращує їх сценарій оболонки?
• Чи є ще місце для інженерів, які не можуть / не можуть бути в курсі парадигми DevOps?
• Чи просто ми припускаємо, що деякі люди залишаться позаду, коли ці технології розвиваються? Чи це нормально?

Я маю перевагу розуміти розміри та складність вашого оточення. Бачачи, що ви працюєте для постачальника послуг хмари / хостингу, можна припустити, що у вас є велика кількість середовищ малого та середнього розміру (10-100 серверів). Звичайно, є щоденні завдання, які виконує молодший. інженери та співробітники НОК, які повторюються (створення облікових записів користувачів, налаштування резервних агентів тощо). Так само, мабуть, є деякі ручні речі, які виконує сер. такі інженери, як установка ESXi на нове обладнання або налаштування таких речей, як MPIO, або встановлення модулів VMware для конкретних наборів обладнання. Усі ці речі можна і потрібно автоматизувати.

Якщо ваш персонал здатний виконувати основну частину своєї завантаженості без автоматизації, то, на мою думку, ви перенавантажені. Будь-який ІТ-персонал, який може працювати цілий день, що складається з переважно ручних процесів, не має мотивації до автоматизації. Навіщо вивчати нову майстерність, яка не вважається необхідною і навіть може бути страшною ? Адже необхідність - це мати, якщо новаторство.

Отже, в якийсь момент вашої організації ви виростете до розміру, коли ви будете камбати і розвалюватися, або ви почнете автоматизувати майже все та досконало. Безумовно, старші інженери повинні вести заряд тут, а може, навіть працювати з молодшими інженерами та персоналом НОК, щоб автоматизувати частину їх навантаження. Це дає jr. інженерам можливість створити основу для багатьох сценаріїв, з якими вони можуть налаштувати кожного орендаря та переглядати нове обладнання за необхідності. Це знімає загрозливу думку "О боже мій, з чого я навіть починаю?" з рівняння і дає їм стрибок до вирішення реальної задачі. Що підводить мене до моєї остаточної точки. Книги та приклади - це добре і добре, але є "проблема, з якою вони стикаються. Поставте їм мету, як і всі нові сервери для орендаря x повинні мати встановлені певні модулі ESXi, а потім працювати з ними для її виконання. Потім адаптуйте сценарій для роботи в багатосторонньому середовищі.

Як sysadmin покращує їх сценарій оболонки?

За необхідності , щоб, як описано вище.

Чи є ще місце для інженерів, які не можуть / не можуть бути в курсі парадигми DevOps?

Звичайно, існує безліч організацій, які не можуть або не перейдуть на методологію DevOps. Вони здаються все більш нудними варіантами, але все-таки є варіантами.

Чи просто ми припускаємо, що деякі люди залишаться позаду, коли ці технології розвиваються?

Як і будь-яка нова технологія - так.

tl; dr. Ви ніколи не будете нікому реально вкладати гроші в навчання, поки вони не побачать у ньому цінності. Якщо вони можуть виконувати свої щоденні завдання вручну, тоді ви перестараєтесь, і стимулів немає.

• Як sysadmin покращує їх сценарій оболонки?

Практика, змішана з приводом. Це звучить банально, але вам потрібно хотіти оздоровитись, крім практики. Якщо ви не по-справжньому насолоджуєтеся сценарієм, ви можете змусити це робити роками, коли вам доведеться і ніколи по-справжньому не виходить у цьому добре. Якщо ви не хочете поправлятися, ви можете щодня сидіти поруч із найкращим у світі сценаристом на роботі і не брати на себе частину майстерності, яку ви могли б мати.

Я знаю тих людей, які, незважаючи на роботу в ІТ, вперто відмовляються вивчати будь-які сценарії. Тим людям у цій галузі не буде місця. Вони є частиною вмираючого покоління.

( Я не говорю про старих людей, маю на увазі це образно.: P )

• Чи є ще місце для інженерів, які не / не можуть бути в курсі парадигми DevOps?

Ні. Кожна річ, яку вони роблять, може бути і врешті-решт буде автоматизована.

Я заперечую, що, можливо, ми ніколи не мали б їх називати "інженерами". Це досить погано, що ІТ-індустрія привласнила собі слово "інженер", що, на мою думку, є образливим для справжніх інженерів, які витрачали роки на програми вищої освіти та отримували юридичні сертифікати, щоб вони могли розробляти мости, хмарочоси, адронні колайдери тощо ... це справжні інженери.

Але є подібність ... Якщо ви хочете називати себе "інженером" в ІТ-індустрії, то це, принаймні, означає, що ви створюєте речі. Ви винахідливі і з'єднуєте крапки новими способами, про які раніше ніхто не думав. Ви будуєте речі, які ще ніхто не знав, наскільки це буде цінним, поки ви не зробили це.

Якщо ви не кодуєте чи скрипт, то немає жодного способу зробити багато з комп'ютерами, крім того, щоб просто їх підтримувати, а можливо, встановити пакет програм або два. Можливо, киньте новий жорсткий диск у ol 'MSA. І в такому випадку я б назвав вас адміністратором, звичайно, але не обов’язково інженером. І я б сказав, що значна частина вашої роботи під загрозою автоматизації виїзду.

• Чи просто ми припускаємо, що деякі люди залишаться позаду, коли ці технології розвиваються?

Ринок адаптується. Можливо, деякі люди не будуть заробляти 6-цифрову зарплату, коли вони насправді їх не заслуговують, що трапляється зовсім небагато в цій галузі.

Я вважаю, що креативність, а не лише навичка кодування / написання сценаріїв, є ключовим фактором. Це та творчість, яка вам повинна сказати собі: « Ой, ей, я міг би це автоматизувати! », І тоді майстерність вступає в гру лише після цього. Якщо ви виявите, що щось сценарізуєте лише після того, як ваш начальник скаже вам, то, можливо, у вас не буде такого драйву чи творчості, про яку я говорив ... і це дві якості, які дуже важко, можливо, неможливо, навчити.

Як sysadmin покращує їх сценарій оболонки?

Як можна в чомусь поліпшитись? Читайте книги, відвідуйте заняття, а потім застосовуйте вивчені принципи. (Або комбінація методів.) Це навмисно спрощено, оскільки немає нічого особливого в навчанні сценаріїв над тим, як навчитися готувати їжу чи як ремонтувати машину.

Чи є ще місце для інженерів, які не можуть / не можуть бути в курсі парадигми DevOps?

На це важко відповісти в межах цього веб-сайту (де є вимога чітких / визначених відповідей на задані питання.) Ми можемо передбачити, що це буде, але є проблеми з моделлю DevOps. Я відчуваю, що одній людині дуже важко бути надзвичайно обізнаним в обох дисциплінах. Збереження витрат працівника «2 на 1» зараз дуже привабливе для бізнесу, але важко сказати, чи збережеться ця тенденція. Звичайно, це на короткий термін.

Чи просто ми припускаємо, що деякі люди залишаться позаду, коли ці технології розвиваються?

При нинішньому темпі того, як все йде, так. Більшість із вас, ймовірно, спостерігають це на власних робочих місцях. Вам неодмінно слідкувати за списками робочих місць та знати, що зараз вимагає ринок. (У вашому районі є чимало списків вакансій для Hadoop? Дізнайтеся Hadoop.) Якщо ви не будете йти в ногу з ринком, ви ризикуєте залишитися позаду.

Як правило, ніхто не надсилає молодших інженерів у складне виробниче середовище, яке є найважливішим завданням. У вас є старші інженери для цього. Молодші звання повинні бути дозволені до роботи в пісочницях для розробки / тестування.

Якщо вам потрібен інженер для технології X і хочете заповнити роль всередині, знайдіть когось, хто бажає цього навчитися, знайдіть структуровану підготовку та поєднайте їх.

З’ясуйте, які навички вам потрібні у відділі. Знайдіть когось, хто бажає їх вивчити. Навчіть / роздайте гроші на навчання.

Чи є ще місце для інженерів, які не можуть / не можуть бути в курсі парадигми DevOps?

"девепс" - це лише нове слово для того, що систематики роблять десятиліттями.

Чи просто ми припускаємо, що деякі люди залишаться позаду, коли ці технології розвиваються?

Зовсім навпаки. З плином часу потреба в технічних людях виникає лише все більше. Будь-хто з будь-якими інженерними знаннями та технічними навичками матиме місце для роботи.