Sposoby optymalizacji procesu rekrutacji DevOps poprzez paradygmat CALMS?

Większość rekrutacji DevOps odbywa się zgodnie z dopasowaniem słów kluczowych, co moim zdaniem prowadzi do skupienia się wyłącznie na technologii.

Teraz DevOps to coś więcej niż tylko technologia, a DevOps Engineer to nie tylko lepszy administrator systemu z pewnymi umiejętnościami kodowania.

Rola / profil Senior DevOps oznacza dla mnie także oferowanie stażu pracy w wielu innych podstawach i praktykach wykraczających poza umiejętności w zakresie infrastruktury i inżynierii oprogramowania, takie jak Lean, pomiar, a także otwartość i komunikatywność (kto prosi DevOps o umiejętności komunikacyjne, szczerze ?!)

Czy więc ogłoszenie o pracę / rozmowa kwalifikacyjna może być w jakiś sposób bardziej wydajna - na przykład poprzez zastosowanie kwestionowania kategorii CALMS ? - Prowadząc do pytań typu „teraz, w jaki sposób stosujesz zasady lean”. W jaki sposób uwzględniono aspekty kulturowe w swoich ostatnich projektach DevOps? ”

Dalsze opracowanie:

• C z ł e (np. Strategie zarządzania konfliktem i podejście do awarii, własne i inne ”)
• Utomation (tu poprosić o Lalek / Döcker itp umiejętności)
• L ean (podstawy Lean? Typy odpadów?)
• M owe zamówienia (poproś o narzędzia takie jak JMeter, ale przejdź także do próbkowania, modelowania danych ...)
• S haring (oczywiście zarządzanie wiedzą i odpowiednie narzędzia)

AKTUALIZACJA - dlaczego więc pracodawcy / rekruterzy nie mieliby strukturyzować wywiadu przez CALMS, jak pokazano poniżej (dodatkowo sekcja „automatyzacja” mogłaby zostać sformułowana zgodnie z modelem łańcucha narzędzi DevOps ( łącze do dokumentu, tylko do odczytu )?

Uwaga dodatkowa - tak więc na przykład kultura nie jest już tak naprawdę tylko miękką umiejętnością, dla DevOps jest to jedna z podstawowych umiejętności - podobnie jak wszystkie inne w tej dziedzinie.

To genialny pomysł, również z powodu Daniela Kahnemana, który pokazał, że jeśli podzielisz pojedynczy wynik na 5 ważonych wyników i dodasz do nich kryteria liczbowe i granice, znacznie zmniejszysz stronniczość . Możesz zaprojektować nie tylko podsumowanie CV, ale cały proces zatrudniania, z ekranami telefonu, wywiadami na miejscu, wszystko w ten sposób. Znacznie zmniejszyłoby to nieodłączne nastawienie ankieterów. Właściwie zaczęliśmy robić coś podobnego dla wszystkich pracowników.

Oczywiście w każdym obszarze powinieneś nadać wagę temu, co jest ważne dla firmy na tym stanowisku, ale zatrudniasz dobrze przygotowanego inżyniera i potrzebujesz kogoś, kto zaproponuje poważne zmiany w sposobie działania Twojej organizacji, nie tylko zatrudniasz ktoś o określonych umiejętnościach do pracy na ograniczonym obszarze. Wiele osób po prostu postrzega tę rolę jako lepiej płatnego Inżyniera ds. Wydań i Budowania, a jeśli tak, to właśnie to powinieneś zatrudnić i zareklamować.

W przypadku wynajmu DevOps sugerowałbym zastąpienie Lean uczeniem się. Jest to pierwotnie CAMS i chociaż niektórzy rozszerzają go na CALMS, aby uwzględnić Lean, jest to nieco ograniczające, ponieważ DevOps opiera się na znacznie więcej niż tylko Lean. Są to również pomysły Deminga na temat specjalnej i wspólnej zmienności przyczynowej i myślenia systemowego, równowaga Nasha (jeśli każda z nich zoptymalizuje się dla siebie, wynik może być nieoptymalny, w porównaniu do sytuacji, gdy wszyscy są zainteresowani grupą), statystyczna kontrola procesu Shewharta , Goldratta Teoria ograniczeń , przeciwdziałanie kruchości Taleba i wiele innych.

Umożliwiłoby to również włączenie uczestnictwa w konferencjach w Nauka oraz prezentacji na konferencjach lub spotkaniach jako Udostępnianie. W sytuacji, gdy nie zawsze jesteś częścią zespołu lub Twoja firma może nie być wystarczająco duża, aby mieć rówieśników jako współpracowników, jeszcze ważniejsze jest ustanowienie i utrzymanie relacji poza miejscem pracy i możliwości uczenia się. Zasadniczo zgrupowaliśmy te dwie grupy w ramach Kultury.

Osobiście oddałbym pod Kulturę umiejętności miękkie wymagane do skutecznego usprawnienia procesów w twojej organizacji. CMMI , Kanban , limity Work in Progress , praktyki Agile itp.

JIRA wydaje się bardziej narzędziem do udostępniania, a Git jest bliżej związany z automatyzacją.

EDYTOWAĆ

Uważam, że zależy to od organizacji i od tego, czego oczekuje się od DevOps / Senior DevOps, dlatego twoje pierwsze zdanie jest w 100% dokładne. Ponieważ DevOps powinien móc korzystać z zestawu narzędzi używanych przez firmę, a także ulepszać lub wprowadzać nowy zestaw narzędzi, który umożliwia firmie i jej twórcom szybszą pracę i mniejsze marnotrawstwo.

Moim zdaniem DevOps powinien mieć silne umiejętności SysAdmin i oczywiście umiejętności kodowania, ponieważ Puppet, Chef, Python, Bash będą szeroko używane, a także pewną wiedzę na temat kodu, który działa na serwerach, przynajmniej w celu umożliwienia drobnego debugowania, dlaczego aplikacja nie zachowuje się zgodnie z oczekiwaniami w zależności od środowiska.

Teraz, jako Senior DevOps, można zastosować CALM, jednak zasady Lean i Measurement mogą / mogą nie mieć zastosowania. Na przykład tworzymy aplikacje przy użyciu Chef / Puppet / Ansible do automatyzacji przyziemnych rzeczy i utrzymywania synchronizacji wszystkiego, co oczywiście oszczędza czas i produkuje mniej odpadów .

Jeśli chodzi o pomiar, nie jestem pewien, czy ma to zastosowanie w większości przypadków. Jednak inne zasady CALM są częścią pozycji DevOps.

Posiadanie dobrych umiejętności komunikacyjnych jest również ważne jako DevOps, ale ważniejsze jako Senior DevOps, ponieważ będziesz musiał nie tylko radzić sobie ze swoim zespołem i dzielić się wiedzą oraz z programistami, którzy tam są, aby je wspierać, ale także może być konieczne twórz raporty i prezentacje przed zarządem.

Podoba mi się dodany przez Ciebie arkusz kalkulacyjny i dobrze jest mieć system punktowy, jednak niektóre firmy dodają także więcej umiejętności / technologii w ogłoszeniu o pracę, niż jest to wymagane.

Ponadto, po rozmowie telefonicznej (jeśli taka jest), przydałoby się, że podczas wywiadu dostaniesz pewne problemy do rozwiązania lub przynajmniej pokazania swojego procesu debugowania i tego, jak będziesz się zachowywać w danych sytuacjach. Osobiście nie lubię testów pisemnych, ponieważ uważam, że nie ma sposobów na rozwiązanie problemu, a czasami Google jest twoim przyjacielem, ponieważ nie oczekuje się, że będziesz wiedział wszystko na pamięć.

Jako DevOps / Senior DevOps uważam, że istnieje granica między używanymi aplikacjami a wiedzą. Możesz być niesamowity w korzystaniu z tych nowych / starych narzędzi lub pisaniu kodu, ale jeśli chodzi o debugowanie lub po prostu zrozumienie problemu z serwerem, zadanie Jenkins może być niemożliwe.

Na koniec zaprezentowany arkusz kalkulacyjny, moim zdaniem, jest sposobem oceny wiedzy DevOps również na stanowisku wyższego szczebla. Mogę tam dodać pewne umiejętności interpersonalne i zarządcze, aby go uzupełnić.

A jeśli chodzi o proces selekcji, możesz rzucić okiem na arkusz kalkulacyjny i wybrać osobę z wynikiem, który Twoim zdaniem jest odpowiedni dla Twojej organizacji, a także pamiętać o jego (er) zachowaniu podczas wywiadu i sposobie (s) przedstawił / odpowiedział na te pytania.