DevOpsチームの人員不足の典型的な兆候とシグナルは何ですか？チームへの新規追加のリクエストをどのように正当化/説明しますか？

質問を一般的なものにしたいと思いますが、いくつかの追加情報があります。

現在、2人のDevOpsスペシャリストがチームとして一緒に働いていますが、製品の需要と量と複雑さが増大しています。チームへの新たな追加をリクエストすることを考えていますが、それが良いアイデアである理由を説明し、証明するのが困難です。

チームの人員不足を感じることができる主な理由は4つあります。

1. 不十分な組織と作業計画
2. 他の誰かがやるべき仕事をする
3. すべきではない仕事をする
4. 実際に人手不足である

最初の3つのポイントのレビューから始めます。最初の方法については、フェニックスプロジェクトをご覧ください。誰かがそれを行うべきなのか、それともあなたがそのタスクを行うべきなのか、それとも自分でそれを行う必要がある人だけを有効にするべきなのか、誰でも助けるすべてのタスクを自問してください。これにより、あなたが行うすべての作業が必要な理由に関するドキュメントが得られます。

次に、フェニックスプロジェクトで言及されている4種類の作業を確認します。

1. ビジネスプロジェクト -組織内の他のチームに対して行うこと
2. 内部プロジェクト -今後の作業を容易にするためにあなたがすること
3. 定期メンテナンス -ライトを点灯させるために何をするか
4. 計画外の割り込み -何かがうまくいかなかったために何をするか

チームの作業が持続可能であれば、4つそれぞれにほぼ同じ時間を費やします。予定外の作業が時間の50％近くに忍び寄ってきたら、それは間違いなく人員不足です。

計画外の作業が時間の25％に達する前に、約1人の人を雇うことができるはずです。そうしないと、1人がチーム全体をあなたが回復できないかもしれない後押しに追いやります。人とテクノロジーの過剰なプロビジョニングには、同じ理由と利点があります。

背景： 現在のインフラストラクチャと開発者へのサポートの提供に加えて、スプリント内の開発チームと立ち上げられる新しいプロジェクトを支援することに加えて、DevOpsチームとして毎月計画を実行します。しかし、その月の間、私たちはしばしば、実行および改善が必要な余分なことに気付き、それをバックログに追加します。私たちも責任を負い、私たちの範囲を超えた他のさまざまなことを支援しますが、私たちができる限りビジネスを支援します:)

回答：たくさんのタスク、特にメンテナンスに回らなかったり、延期していないことに気づくとすぐに、それは良い指標だと思います（私が経験したことから）。また、DevOpsチームが薄くなるほど新しいプロジェクトや開発チームが増えるほど、より多くの人が必要になります。

毎日のタスクに追いつくのは非常に簡単ですが、一歩後退してこれを評価することは非常に重要です（月に一度でも）。

私は実際にこれに関するSREハンドブックからページを取りますが、これは非常に関連性が高いと思います。DevOpsの専門分野は、組織とともに水平に成長することを意図したものではありません。むしろ、物事が成し遂げられていないことがわかった場合、それは開発者にセルフサービスを適切に権限を与えていないというシグナルです。

プロセスを評価し、一般に受け入れられているDevOpsの原則にどのように沿っているか、また業界のベストプラクティスに従っているかを確認します。

この2人のチームはプロジェクトからプロジェクトに移り、DevOpsスタッフをそこに確立する（CI / CDパイプラインを作成する、Dockerfilesを作成する他の開発者をサポートする、または使用している技術）を想定しています。つまり、http://web.devopstopologies.com/に従って3、4、5、または6と入力します。

この場合、不足の兆候は単にこれら2つの作業負荷が大きすぎることです。サービスを要求するプロジェクトが多すぎる。チケットが多すぎる。時間とともに; ストレス、燃え尽き。これらの要因は、責任あるリーダーシップが能力を追加するのに十分な理由であるはずです。これにはDevOps固有の記号は表示されません。これは単に人員不足の機能です。

何かを変えるもう1つの兆候は、よく見てみると、「DevOpsサイロ」を作成していることに気づいた場合です。これら2つは「DevOpsを行う」ことです。それはDevOpsのポイントではありません。その場合は、文化的側面について考え、他のチームのより多くの伝道者/教師/コーチになるようにそれらを修正してください。

どちらの場合も、最初にDevOpsを使用することが良い理由（一般的なGood Stuff）である理由のより深い理由は、上級管理職に明らかです。そのメッセージを伝えることができない場合は、チームの作業を通常の開発/運用に移してスケールダウンします（とにかくそうなのですが）。

私は、DevSecOpsがチームではなく考え方であるという印象を受けていました-Dev（Sec）Opsの「チーム」がある場合、それは間違っています... 2人の「DevOps Engineers」一緒に「DevOpsチーム」と呼びます。

開発チーム、SCM、アプリケーションセキュリティ、システムエンジニアがすべて連携して、コードと構成/システムの変更を特定のエンドポイント（ステージングまたはプロダクション）にプッシュするための迅速な展開/リリースモデルに取り組んでいます。

これは、「devOps」エンジニアとは関係ありません。

タスクのグループ化

過去に同様の状況で使用してきたアプローチは、4つの主要なタスクグループにチームの作業を編成し、2つのFTE（Full Time Equivalents）に相当するタスクをそれらのタスクに割り当てる（試行する）ことです。私たちの場合、メインフレーム環境でSCMヘルプデスクを実行することに関連しており、約300人の開発者が2人のFTEからあらゆる種類のヘルプ/介入を求めています。タスクのグループは、4つの可能な優先度で編成されています。

• 優先度1および2のタスクを完了する必要があります（言い訳/交渉はできません）
• 優先度3つのタスクは「完了されるとすぐに、時間の許す限り」。
• 優先度4のタスクは、「時間が許せば」完了します。

これら4つのグループのそれぞれのタスクの種類に関する詳細をお読みください...

タスクの説明

優先度1-ヘルプデスクを操作する

• 簡単にアクセスでき、常に利用可能な専門家による。
• 営業時間中に電話、メール、または発券システムで。
• 事前定義されたSLAに準拠。
• すべてのコールの定期的なレポートを使用した、すべてのヘルプデスクコールのITILベースの登録。
• 重大な問題に対して緊急のカスタマイズ（回避策）を適用します。

優先度2-監視サービス

• 24時間/日、週7日/オンコールの可用性。
• 事前定義されたSLAに準拠。
• すべての監視義務コールの報告。
• 必要に応じて管理エスカレーション。

優先度3-定期的なメンテナンス

• 管理。
• アプリケーション搭乗。
• ハウスキーピング。
• パフォーマンスの強化。
• スペース管理。
• リソース消費の調整。
• ヘルプデスクへの電話や監視義務の介入の数を減らすためのカスタマイズの強化を提案します。

優先度4-修正と機能強化

• ユーザードキュメントを作成および管理します。
• 新しいカスタマイズのQAテスト。
• 拡張リクエストを作成して実装します。
• DRPテストに参加します。

評価

上記の方法を使用している場合、さまざまなことが起こります（！）。

• チームの人員が不足している場合、おそらくほとんどの時間は優先度1および2のタスクに進みますが、優先度3のタスクを取得するには時間がかかる場合があります...優先度4のタスクは飢sufferに苦しむ可能性がありますそれらのタスク）。
• 優先度4のタスクに「投資」する時間があればあるほど、優先度1および2のタスクに必要な時間が短縮され、（2人のFTEの利用可能な予算の）さらに多くの時間を「投資」できます。 "優先度4のタスク。
• しばらくすると、優先度1と2のタスクの数がどのように減少するかを見て驚くでしょう。そして、それらのタスクについて十分なレポートを作成する場合、それは経営陣が聞きたいものです。私たちの場合、その数は約300 /月から100 /月未満に減少しました...
• ただし、2人のFTEが優先度4のタスクを行う時間がない（またはほとんどない）ように見える場合は、経営陣に対して完璧な説明と証拠があります...人員不足です。