Шляхи оптимізації процесу найму DevOps через парадигму CALMS?

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

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

Старша роль / профіль DevOps для мене також пропонує стаж у багатьох інших закладах та практиках за межами інфраструктури та навичок програмного забезпечення, таких як Lean, Measurement та бути відкритими та комунікативними (хто запитує DevOps наймає їх навички спілкування, чесно ?!

Отже, чи може оголошення про співпрацю / співбесіду бути певним чином ефективнішим - наприклад, застосувавши анкетування категорій CALMS ? - Ведучий до питань, таких як "зараз, як ви застосовуєте пісні принципи? Як культурні аспекти вирішувались у ваших останніх проектах DevOps?"

Подальша розробка:

• C ulture (наприклад, стратегії управління конфліктами та ставлення до невдач, власних та інших)
• Utomation (тут ви питаєте про ляльковому / Докері і т.д. навичках)
• L ean (основи худорлявих? Види відходів?)
• M мірка (попросити такі інструменти , як JMeter , але йде і до речей , як відбір проби, моделювання даних ..)
• S Haring (очевидно, управління знаннями та інструменти)

ОНОВЛЕННЯ - тож чому б роботодавці / рекрутери не структурували співбесіду CALMS, як показано нижче (крім того, розділ "автоматизація" можна сформулювати за допомогою моделі ланцюгів інструментів DevOps ( посилання на документ, лише для читання )?

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

Це геніальна ідея, також завдяки Даніелу Канеману, який показав, що якщо розділити один бал на 5 зважених балів і додати до них числові критерії та межі, ви значно зменшите упередженість . Ви можете розробити не лише резюме резюме, але і весь процес найму, з екранами телефону, співбесідами на місці, і все таким чином. Це суттєво зменшило б властиві упередженості інтерв'юерів. Ми фактично почали робити щось подібне для всіх найм.

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

Для прокату DevOps я б запропонував замінити Lean на Learning. Це спочатку CAMS, і хоча деякі з них поширюють його на CALMS, включаючи Lean, це дещо обмежує, оскільки DevOps базується на набагато більше, ніж просто Lean. Це також ідеї Демінга про особливі та загальні зміни причин і системне мислення, рівновагу Неша (якщо кожен оптимізує для себе результат, результат може бути неоптимальним, порівняно з тим, коли всі включають інтерес групи), контроль статистичних процесів Шеуарта , Голдратта Теорія обмежень , анти-крихкість Талеба та багато іншого.

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

Я особисто ставлю під «Культуру» м'які навички, необхідні для ефективного вдосконалення процесів у вашій організації. CMMI , Kanban , Ліміти роботи в процесі прогресу , Agile практики тощо.

JIRA, схоже, більше схожий на інструмент спільного доступу, а Git більш тісно пов'язаний з автоматизацією.

EDIT

Я вважаю, що це залежить від організації до організації та того, що очікується зробити DevOps / Senior DevOps, тому ваше перше речення є 100% точним. Тому що DevOps повинен мати можливість використовувати набір інструментів, якими користується компанія, а також вдосконалити або принести новий набір інструментів, який дає змогу компанії та її розробникам працювати швидше і витрачати менше.

На мою думку, DevOps повинен мати сильні навички SysAdmin і, очевидно, навички кодування, як Puppet, Chef, Python, Bash, будуть широко використовуватися, а також деякі знання коду, що надходить на сервери принаймні, щоб мати можливість робити невеликі налагодження на чому додаток не веде себе так, як очікувалося від одного середовища до іншого.

Тепер, як старший DevOps, CALM може застосовуватися, однак принципи Lean та Measurement можуть / можуть не застосовуватися. Наприклад, ми розробляємо додатки за допомогою Chef / Puppet / Ansible для автоматизації мирських речей і синхронізації всього, що, очевидно, економить час і створює менше витрат .

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

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

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

Крім того, після телефонного інтерв'ю (якщо воно є) я вважаю корисним, що в інтерв'ю вам будуть задані деякі проблеми, щоб вирішити або принаймні показати процес налагодження і як ви будете вести себе в тих чи інших ситуаціях. Особисто мені не подобаються письмові тести, оскільки я вважаю, що існують «п» способи вирішення проблеми, а також, іноді Google є вашим другом, оскільки від вас, як очікується, не знаєте все напам’ять.

Як DevOps / Senior DevOps, я вважаю, що існує програма між використовуваними програмами та знаннями. Ви можете бути дивовижним у використанні цих нових / старих інструментів або написанні коду, але коли мова заходить про налагодження або просто розуміння, у чому проблема з сервером, робота Дженкінса може бути у вас, ви цього не можете зробити.

Нарешті, представлена ​​електронна таблиця, я думаю, це спосіб оцінити знання DevOps також для старшої посади. Я можу додати там деякі навички міжособистісного управління та управління, щоб зробити його повною.

Що ж стосується процесу відбору, ви можете ознайомитись з електронною таблицею та вибрати людину з оцінкою, яка, на вашу думку, є правильною для вашої організації, а також пам’ятати про її (помилкову) поведінку під час співбесіди та спосіб (и) він представив / відповів на ці питання.