W jaki sposób administrator systemu Linux może poprawić swoje umiejętności pisania skryptów i automatyzacji?

W mojej organizacji współpracuję z grupą pracowników NOC, młodszymi inżynierami i garstką starszych inżynierów; wszystko z naciskiem na Linuksa. Ciekawym krokiem w rozwoju firmy jest talent od NOC do wyższych rang inżynieryjnych. Patrząc na pulę talentów jako względną nowość, widzę, że w zestawach umiejętności występuje rozłam, który z czasem rośnie.

• Są inżynierowie, którzy dobrze znają jedną lub kilka konkretnych technologii i są stale zanurzeni ... np. MySQL, zapory ogniowe, pamięć masowa SAN, moduły równoważenia obciążenia ...
• Są inni, którzy są generalistami i mogą poruszać się po wielu technologiach.
• Wszyscy uczą się wystarczająco dużo Linuksa (poleceń, procesów), aby robić to, czego potrzebują i używać na co dzień.

Czynnikiem różnicującym między niektórymi pracownikami jest to, jak dobrze stosują metodologie skryptów, automatyzacji i zarządzania konfiguracją. Na przykład mamy dwóch inżynierów, którzy wykonują większość prac związanych z Amazon AWS CloudFormation , i drugiego, który obsługuje większość infrastruktury Puppet . Być może jedna czwarta inżynierów jest biegła w skryptowaniu powłoki BASH.

Patrząc na to w kontekście niewiarygodnie dużego zapotrzebowania na umiejętności DevOps na rynku pracy , jestem ciekawy, w jaki sposób inne organizacje wspierają rozwój tych umiejętności i rozwijają ich wewnętrzny talent. Skrypty nie wydają się koncepcją szczególnie uczącą się.

• W jaki sposób sysadmin ulepsza swoje skrypty powłoki?
• Czy jest jeszcze miejsce dla inżynierów, którzy nie nadążają / nie mogą nadążyć za paradygmatem DevOps?
• Czy mamy po prostu zakładać, że niektórzy ludzie pozostaną w tyle wraz z rozwojem tych technologii? Czy to jest ok?

Mam tę zaletę, że rozumiem wielkość i złożoność twojego środowiska. Ponieważ pracujesz dla dostawcy chmury / hostingu, można bezpiecznie założyć, że masz dużą liczbę małych i średnich środowisk (10–100 serwerów). Jr jest z pewnością codziennymi zadaniami. inżynierowie i pracownicy NOC, którzy powtarzają się (tworzenie kont użytkowników, konfigurowanie agentów kopii zapasowych itp.). Podobnie, prawdopodobnie są pewne ręczne czynności, które wykonuje sr. inżynierowie lubią instalować ESXi na nowym sprzęcie lub konfigurować takie rzeczy jak MPIO lub instalować moduły VMware dla określonych zestawów sprzętu. Wszystkie te rzeczy mogą i powinny być zautomatyzowane.

Jeśli twoi pracownicy są w stanie wykonać większość swoich zadań bez automatyzacji, to moim zdaniem masz za dużo personelu. Każdy personel IT, który może pracować cały dzień, który składa się głównie z procesów manualnych, nie ma motywacji do automatyzacji. Po co uczyć się nowych umiejętności, które nie są uważane za konieczne, a nawet mogą być przerażające ? W końcu potrzeba jest matką, jeśli innowacja.

Tak więc w pewnym momencie swojej organizacji osiągniesz rozmiar, w którym będziesz się rozrywać i rozpadać, albo zaczniesz automatyzować prawie wszystko i przodować. Z pewnością starsi inżynierowie powinni tu przewodzić, a może nawet współpracować z młodszymi inżynierami i personelem NOC, aby zautomatyzować część ich pracy. To daje jr. inżynierowie mają możliwość korzystania z wielu skryptów do pracy, które mogą dostosowywać w zależności od potrzeb każdego najemcy i nowego sprzętu. To usuwa zniechęcającą myśl: „O mój boże, od czego mam zacząć?” z równania i daje im impuls do rozwiązania prawdziwego problemu. Co prowadzi mnie do ostatniego punktu. Książki i przykłady są dobre i dobre, ale są ”problem, z którym się borykają. Daj im cel, podobnie jak wszystkie nowe serwery dla dzierżawcy x powinny mieć zainstalowane pewne moduły ESXi, a następnie współpracować z nimi, aby je osiągnąć. Następnie dostosuj skrypt do pracy w środowisku wielodostępnym.

W jaki sposób sysadmin ulepsza swoje skrypty powłoki?

Od potrzeby w celu, jak opisano powyżej.

Czy jest jeszcze miejsce dla inżynierów, którzy nie nadążają / nie mogą nadążyć za paradygmatem DevOps?

Jasne, istnieje wiele organizacji, które nie mogą lub nie przestawią się na metodologię DevOps. Wydają się być coraz bardziej nudnymi opcjami, ale mimo to są opcjami.

Czy mamy po prostu zakładać, że niektórzy ludzie pozostaną w tyle wraz z rozwojem tych technologii?

Jak w przypadku każdej nowej technologii - tak.

tl; dr Nigdy nie będziesz mieć nikogo, kto naprawdę zainwestuje w naukę, dopóki nie zobaczy w tym wartości. Jeśli mogą wykonywać codzienne zadania ręcznie, oznacza to, że masz za dużo personelu i nie ma motywacji.

• W jaki sposób sysadmin ulepsza swoje skrypty powłoki?

Ćwicz, zmieszany z popędem. Brzmi banalnie, ale trzeba chcieć się lepiej, oprócz praktyki. Jeśli naprawdę nie lubisz pisania skryptów, możesz zostać zmuszony do tego przez lata, kiedy będziesz musiał i nigdy naprawdę nie będziesz w tym dobry. Jeśli nie chcesz być lepszy, możesz codziennie pracować w pracy przy najlepszym skrypcie na świecie i nie brać ułamka umiejętności, którą możesz mieć.

Znam tych ludzi, którzy pomimo pracy w IT uparcie odmawiają nauki jakiegokolwiek skryptu. Wkrótce nie będzie miejsca dla tych ludzi w tej branży. Są częścią umierającego pokolenia.

( Nie mówię o starych ludziach, mam na myśli to w przenośni: P )

• Czy jest jeszcze miejsce dla inżynierów, którzy nie nadążają / nie mogą nadążyć za paradygmatem DevOps?

Nie. Wszystko, co robią, może być i ostatecznie zostanie zautomatyzowane.

Twierdziłbym, że być może nigdy nie powinniśmy nazywać ich „inżynierami”. Jest to na tyle złe, że przemysł IT przywłaszczył słowo „inżynier” dla siebie, co moim zdaniem jest trochę znieważenie do rzeczywistych inżynierów, który spędził wiele lat w programach studiów wyższych i uzyskanie certyfikatów prawnych, tak aby mogli oni projektować mosty, drapacze chmur, collidery Hadron itd. ... to są prawdziwi inżynierowie.

Ale istnieje podobieństwo ... Jeśli chcesz nazywać się „inżynierem” w branży IT, oznacza to przynajmniej tworzenie rzeczy. Jesteś pomysłowy i łączysz kropki na nowe sposoby, o których nikt wcześniej nie pomyślał. Budujesz rzeczy, których nikt inny nie wiedział, jak cenne będą, dopóki tego nie zrobisz.

Jeśli nie piszesz kodu ani skryptu, nie ma możliwości zrobienia wiele z komputerami poza utrzymaniem ich i może zainstalowaniem pakietu oprogramowania lub dwóch. Może wrzuć nowy dysk twardy do starego MSA. W takim razie nazwałbym cię administratorem, oczywiście, ale niekoniecznie inżynierem. I powiedziałbym, że duża część twojej pracy jest zagrożona byciem zautomatyzowanym.

• Czy mamy po prostu zakładać, że niektórzy ludzie pozostaną w tyle wraz z rozwojem tych technologii?

Rynek się dostosuje. Może się zdarzyć, że niektórzy ludzie nie będą zarabiać sześciocyfrowych pensji, jeśli tak naprawdę na nie nie zasługują, co zdarza się dość często w tej branży.

Uważam, że kluczowym czynnikiem jest kreatywność, a nie tylko umiejętność kodowania / pisania skryptów. To kreatywność, którą musisz powiedzieć sobie: „ Och, hej, mógłbym to zautomatyzować! ”, A potem umiejętność zaczyna działać dopiero później. Jeśli odkryjesz, że piszesz coś dopiero po tym, jak każe ci szef, możesz nie mieć takiego popędu ani kreatywności, o której mówiłem ... i są to dwie cechy, których nauczenie jest bardzo trudne, a może niemożliwe.

W jaki sposób sysadmin ulepsza swoje skrypty powłoki?

Jak można poprawić się w czymkolwiek? Czytaj książki, uczęszczaj na zajęcia, a następnie zastosuj wyuczone zasady. (Lub kombinacja metod.) Jest to celowo uproszczone, ponieważ nie ma nic specjalnego w nauce pisania skryptów, a nie nauce gotowania i naprawy samochodu.

Czy jest jeszcze miejsce dla inżynierów, którzy nie nadążają / nie mogą nadążyć za paradygmatem DevOps?

Trudno jest odpowiedzieć na to pytanie w zakresie tej witryny (gdzie istnieje wymóg jasnych / zdefiniowanych odpowiedzi na zadawane pytania). Możemy przewidzieć, że tak, ale występują problemy z modelem DevOps. Uważam, że bardzo trudno jest jednej osobie być bardzo biegłą w obu dyscyplinach. Oszczędności kosztów pracownika 2 w 1 są obecnie bardzo atrakcyjne dla firm, ale trudno powiedzieć, czy ten trend się utrzyma. Z pewnością jest to krótkoterminowe.

Czy mamy po prostu zakładać, że niektórzy ludzie pozostaną w tyle wraz z rozwojem tych technologii?

Przy obecnym tempie tego, co się dzieje, tak. Większość z was prawdopodobnie obserwuje to we własnych miejscach pracy. Zdecydowanie powinieneś nadążać za ofertami pracy i wiedzieć, czego wymaga obecnie rynek. (W Twojej okolicy jest wiele ofert pracy dla Hadoop? Naucz się Hadoop.) Jeśli nie nadążasz za rynkiem, ryzykujesz pozostanie w tyle.

Ogólnie rzecz biorąc, nie wysyłamy młodszych inżynierów do złożonego środowiska produkcyjnego, które ma kluczowe znaczenie dla misji. Masz do tego starszych inżynierów. Stopnie młodsze powinny mieć możliwość pracy w piaskownicach deweloperskich / testowych.

Jeśli potrzebujesz inżyniera do Technologii X i chcesz wypełnić tę rolę wewnętrznie, znajdź kogoś, kto zechce się jej nauczyć, znajdź zorganizowane szkolenie i połącz te dwa elementy.

Dowiedz się, jakich umiejętności potrzebujesz w dziale. Znajdź kogoś, kto chce się ich nauczyć. Naucz / Rozdaj pieniądze na szkolenie.

Czy jest jeszcze miejsce dla inżynierów, którzy nie nadążają / nie mogą nadążyć za paradygmatem DevOps?

„devops” to tylko nowe słowo określające coś, co sysadmini robili od dziesięcioleci.

Czy mamy po prostu zakładać, że niektórzy ludzie pozostaną w tyle wraz z rozwojem tych technologii?

Wręcz przeciwnie. Z biegiem czasu ludzie techniczni stają się coraz bardziej potrzebni. Każdy, kto posiada wiedzę inżynierską i umiejętności techniczne, będzie miał miejsce do pracy.