CALMSパラダイムを通じてDevOps採用プロセスの最適化への道は?


11

DevOpsの採用の多くはたまたまキーワードマッチングの流れに沿って行われるため、私の意見では、テクノロジーのみに焦点が当てられています。

現在、DevOpsは単なるテクノロジー以上のものであり、DevOpsエンジニアは、ある程度のコーディングスキルを持つ優れたシステム管理者ではありません。

シニアDevOpsの役割/プロファイルとは、リーン、測定、オープンでコミュニケーション能力などのインフラストラクチャおよびソフトウェアエンジニアリングスキル以外にも、他の多くの基盤と実践でシニアリティーを提供することを意味します(誰がDevOpsにコミュニケーションスキルを正直に求めていますか?)

それでは、求人広告/面接を何らかの方法でより効率的にすることができます-たとえば、質問するCALMSカテゴリも適用することによって?-「今、無駄のない原則をどのように適用しますか?最近のDevOpsプロジェクトで文化的側面はどのように扱われましたか?」のような質問につながります。

さらに詳しく:

  • Cの ulture(紛争管理と障害に対する態度、自分と他人のために例えば戦略)
  • utomation(ここではあなたが人形/ドッカーなどスキルについて尋ねます)
  • L ean(リーンの基礎?廃棄物タイプ?)
  • Mの easurementは(JMeterのようなツールを求めるが、サンプリング、データモデリングのようなものにも行きます。)
  • Sのヘリング(明らかにナレッジマネジメントと応じたツール)

更新-では、なぜ雇用主/採用担当者は、以下に示すようにCALMSによる面接を構成しないのですか(さらに、「自動化」セクションはDevOps モデルに沿って定式化できます(ドキュメントリンク、読み取り専用))?

ここに画像の説明を入力してください

サイドノート- たとえば、は実際にはもはやソフトスキルではありません。DevOpsにとって、それはこのドメインの他のすべてと同様に、コアスキルの1つです。


1
これは素晴らしい質問です。答えがあったらいいのですが。私がこれまでに見てきたリソースのほとんどと、最近数か月前にdevopsの役割について持っていたインタビューですが、確かに先輩ではありませんが、「devopsの人」になるために必要なスキルの断面には触れていません。 。とはいえ、CALMSは雇うことができるものですか?これらの強力なシステム管理スキルをCALMSと一緒に意味のある方法でもたらすことができる人は、ユニコーンのようになるでしょう。
Briansbum 2017年

1
これらの種類の質問についてここで話すのは良いと思いますが、私はあなたの仮定に疑問を投げかけなければなりません(DevOpsの男/女児を雇ったときに、すべての種類のことが現在「一般的に」起こっていない方法について)。私は確かに候補者とこれらすべてのことについて話します。採用マネージャーがそうでない場合、私は彼が本当にDevOpsに夢中ではないと思いますか?
AnoE 2017年

@Briansbum、あなたは確かに候補者のそれらすべての側面を探し、それらが弱いところと強いところを見つけることができるので、あなたは(お互いを補完する人々と)良いチームを一緒にすることができます。それらすべてに優れている人はおそらくすでに夢の仕事をしていて、とにかく見ていません。;)
AnoE 2017年

回答:


5

また、これは理由ダニエル・カーネマンの素晴らしいアイデアであり、示したあなたは5つの秤量スコアに単一のスコアを分割し、それらに数値基準と境界を追加した場合、あなたは大幅にすること偏りを減らします。履歴書採点だけでなく、電話スクリーン、オンサイトインタビューなど、採用プロセス全体をこのように設計できます。それは面接官の固有の偏見を大幅に減らすでしょう。実際、私たちはすべての採用について同様のことを始めました。

明らかに、各領域内では、そのポジションにとって会社にとって重要なことを重視する必要がありますが、あなたは十分にバランスのとれたエンジニアを採用しており、組織の運営方法に大きな変更を提案する人を求めています。限られた地域で働く特定のスキルを持つ人。多くの人は、この役割をより高額なリリースおよびビルドエンジニアと見なしており、その場合、それを採用して宣伝する必要があります。

DevOpsの採用については、リーンをラーニングに置き換えることをお勧めします。元々はCAMSであり、一部はCALMSに拡張してLeanを含めるようになっていますが、DevOpsはLeanだけにとどまらないため、多少制限があります。また、されるデミングさんに特別と共通の変動とシステム思考原因、についてのアイデアナッシュの均衡(自分自身のために、それぞれに最適化した場合、結果は誰もがグループの関心を含む場合に比べて、次善のかもしれない)、シューハートの統計的プロセス制御、ゴールドラットのを制約理論、タレブの抗脆弱性など。

これにより、学習への会議への参加や、会議やミートアップでのプレゼンテーションを共有として含めることもできます。必ずしもチームの一員ではない場合や、会社が同僚として同僚を作るのに十分な規模ではない場合は、職場外の関係を確立して維持し、学習の機会を維持することがさらに重要です。私たちは通常、これら2つを文化の下でグループ化しました。

私は個人的に、あなたの組織のプロセスを改善するのに効果的であるために必要なソフトスキルを文化の下に置きます。CMMIかんばんWork in Progress制限、アジャイルプラクティスなど

JIRAは共有ツールに似ており、Gitはオートメーションとより密接に関連しています。


1
Jiriに感謝します。最初の基本的な業界リファレンスシートを作成するためのオプション、特に組織の変革の観点からのDevOps用-CCライセンス-ほとんどの採用担当者が作業を開始できる一般的なオプションはありますか?
Peter Muryshkin 2017年

それはうまくいくと思います。私は確かにフィードバックを提供したいと思います。AllDayDevOpsスラックにはすぐに多くのDevOpsプロフェッショナルが参加する予定です。採用担当者もいます。そこでチャンネルを始める価値はあるでしょう。
Jiri Klouda 2017年

2

編集

これは組織によって異なり、DevOps /シニアDevOpsが何をすることが期待されるかによると思います。したがって、最初の文は100%正確です。なぜなら、DevOpsは、会社が使用する一連のツールを使用でき、会社とその開発者がより速く作業して無駄を省くことができる新しいツールのセットを改善またはもたらすことができるはずです。

私の意見では、DevOpsには強力なSysAdminスキルがあり、Puppet、Chef、Python、Bashが広く使用されるため、明らかにコーディングスキルが必要です。また、少なくともサーバー上で実行されるコードに関する知識があり、その理由についてマイナーデバッグを実行できます。アプリケーションは、ある環境から別の環境に期待どおりに動作しません。

現在、上級DevOpsとしてCALMを適用できますが、リーンおよび測定の原則が適用される場合と適用されない場合があります。たとえば、Chef / Puppet / Ansibleを使用してアプリケーションを開発し、ありふれたことを自動化し、すべてを同期させることで、明らかに時間を節約し、無駄を減らします。

測定に関しては、ほとんどの場合それが当てはまるかどうかはわかりません。ただし、他のCALM原則はDevOpsポジションの一部です。

優れたコミュニケーションスキルを持つことはDevOpsとしても重要ですが、シニアDevOpsとしてより重要です。チームに対応し、知識を共有し、開発者とチームをサポートする必要があるため、それらをサポートする必要があるためです。レポートを作成し、経営陣の前でプレゼンテーションを維持します。

私はあなたが追加したスプレッドシートが好きで、ポイントシステムを持っているのは良いですが、会社によっては求人広告に必要以上のスキルや技術を追加しているところもあります。

また、電話によるインタビューの後(ある場合)、面接で解決すべき問題が表示されるか、少なくともデバッグプロセスと特定の状況での動作を示すことが役立つと思います。個人的には、問題を解決する方法が「n」だと思うので筆記テストは嫌いです。また、すべてを暗記することは期待されていないため、Googleが友だちになることもあります。

DevOps /シニアDevOpsとして、私は使用されるアプリケーションと知識の間に線があると信じています。これらの新しいツールや古いツールを使用したり、コードを記述したりするのはすばらしいかもしれませんが、サーバーの問題をデバッグしたり理解したりするだけでは、Jenkinsの仕事はそうすることができないかもしれません。

最後に、提示されたスプレッドシートは、DevOpsの知識を評価する方法であり、上級職でもあるため、対人スキルと管理スキルを追加して完成させることができます。

そして、選択プロセスに関しては、スプレッドシートを見て、あなたの組織にとって適切なスコアだと思う人を選ぶことができます。また、面接時や途中での彼/彼女の行動を念頭に置いてください。 (s)彼はそれらの質問を提示/回答しました。


これは正しい方向に進むと思いますが、質問に直接対処しません。必要に応じて、もう少し詳しく説明してください。
Peter Muryshkin 2017年

1
@PeterMuryshkin私はあなたが私に何を拡張したいのか確信が持てませんでしたが、私はこれについて追加の考えを追加しました
Sergiu

また、はい、それは多すぎるかもしれないと思っていましたが、あなたが私に詳しく説明してほしいことを確信していませんでした
Sergiu
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.