DevOps時代の技術サポート

DevOpsは、大企業のIT企業が、準備ができているかどうかに関係なく行っています。 多くの問題がある可能性がありますが、そのうちの1つについてお話ししたいと思います。 これは大胆な発言かもしれませんが、ほとんどのITサポートサービスの現在の組織構造は根本的に間違っていると思います。

このような状況では、DevOpsプラクティスの実装を成功させることは事実上不可能です。

別の方法として、Swarmingと呼ばれる新しい方法論を提案します。これは、大企業での実装の準備がすでに整っており、DevOps時代のテクニカルサポートタスクの実行に最適です。

現在の状況：3レベルのテクニカルサポートシステムの保守主義

まず、中規模および大規模企業に関連する組織の技術サポートサービスの大部分の根底にある確立された管理構造の簡単な概要から始める必要があります。

ITサービス管理（ITサービス管理）の原則に従って構築された従来の技術サポートには、3レベルの階層があります。

• レベル1。これは、通常は電話でユーザーと直接連絡し、テクニカルサポートサービス（サービスデスク）に連絡します。 これは、特殊化されていない問題について中レベルの技術サポートを提供することを目的としています。 主なタスクは、着信要求のほとんどがここで、最初のレベルで解決されるという条件で、サービスの安定した品質を維持することです。

  
  
  
  
  
  
  

• レベル2。通常、最初のものと密接に関連していますが、従業員のより深い一般的または特別な知識とスキルを意味します。 たとえば、第2レベルの専門家は、一般的なオペレーティングシステム（Microsoft Windowsなど）またはハードウェアをサポートする追加のトレーニングを受け、より複雑な問題を解決するために必要なスキルを習得できます。

  
  
  
  
  
  
  
• レベル3。特定の技術またはアプリケーションに特化したチームがあります。 ソフトウェア開発会社は、多くの場合、特定のアプリケーションとサービスに対して個別のサポートチームを編成します。

3層構造をよりよく理解するには、それを生成およびサポートするビジネス上の理由の分析が必要です。 検討中の方法論は、ほぼ普遍的に適用されます。 その使用を刺激するいくつかの利点があります。

• クライアントには、問題の性質に関係なく、テクニカルサポートとの単一の通信チャネルが提供されます。

  
  
  
  
  
  
  

• サポートの最初の2つのレベルで働くために必要な技術的スキルを持つ労働市場の専門家を見つけるのは簡単です。 また、タスクのアウトソーシングも容易になります。これは非常に頻繁に行われます。

  
  
  
  
  
  
  
• 特定の問題や分野の専門家は、顧客とのコミュニケーションから隔離されており、彼らの能力分野に関連するタスクを与えられています。

カスタマーサポートからサポートサービスへの旅は、ほとんど開始することなく、すでに第1レベルで終了することがあります。 実際、多くの組織では、リクエストの一部は完全に自動化されたサービスを使用して処理されますが、これはしばしば「レベル0」と呼ばれます。

ただし、最初のレベルでは解決できない多くの問題があります。 それらをレベル2およびレベル3に転送するプロセスは、エスカレーションと呼ばれます。

通常、第2レベルのスペシャリストは、最初の同僚よりも少ない数のアプリケーションを処理しますが、これらはより複雑なタスクであり、平均して解決に時間がかかります。

通常、3番目のレベルに到達するチケット（2番目のレベルからエスカレートされるか、最初のレベルから直接送信される）は、すべての受信コールのごく一部を構成します。 しかし、これらは最も複雑なタスクであり、その解決には専門家の高いスキルとかなりの時間コストが必要です。

各サポートレベルで問題を解決するための比較コストを計算するために、多くの試みが行われました。 たとえば、 この2014年の作業では、第1レベルの平均チケット終了コストは22ドル、2番目は62ドル、3番目は85ドルと見積もられています（他の調査によると、最後の数字は数倍です）。

3レベルモデルの問題

このような一般に受け入れられている構造を批判することは容易ではありません。 ただし、Swarming運動は、マルチレベルモデルの重大であるが修正可能な欠点を基礎として、これを正確に目指しました。 DevOpsに影響するいくつかの問題を見てみましょう。

• マルチレベルサポートには、いくつかのキューが含まれます 。 最初のレベルでは、できるだけ早く問題を解決しようとするため、すぐに修正できなかったものはすべてキューに入れられます。 問題の実際のステータスが変わり、現在のカテゴリから遅延カテゴリに移ります。 基本的に、レベル2および3は進行中のタスク（Work in Progress）のウェアハウスであり、 DevOpsの基礎となるリーン哲学の枠組み内の問題です。 リーンの一部としてDevOpsを正常に展開するには、進行中の作業を減らすための決定的な手順が必要です。 この問題だけでも、DevOpsの技術サポートの到着を妨げる大きな要因となります。

  
  
  
  
  
  
  
• マルチレベルのサポートは、適切な専門家への道を妨げる可能性があります。 DevOpsは、従業員の独立性とエンゲージメントの向上を意味します。 開発者自身によるコードのサポートが推奨されます。 DevOpsを実践している企業は、ユーザーリクエストの処理速度を高めることに成功しています（ 2016年のレポート「State of DevOps」によると、24倍高速 ）。 しかし、適切なスペシャリストに行く前にチケットがいくつかのキューを突破しなければならない場合、これは役に立ちません。 かつて、ユーザーサポートでのSwarmingの実装について議論しているときに、 BMCサポートマネージャー（B＆C）の1人が公正な質問をしました。「最高の人材をチェーンの最後に配置する理由は？」

• マルチレベルのサポートは、魅力的なフットボールを実現します。 マルチレベルのテクニカルサポートでは、タスクは一方的にエグゼキューターに割り当てられます。 これは、以前のレベルまたは別の専門家チームで行うことができます。 請負業者は、アプリケーションがタスクキューに表示された瞬間に最初にアプリケーションを確認します。 残念ながら、スペシャリストが追加情報を必要とするか、予約が間違っていることが判明したため、チケットはしばしば返送されます。 DevOpsは、開発者、テスター、運用サービスの専門家などの専門家間の協力に基づいています。部門間の垂直および水平の障壁は、マルチレベルサポートに固有であり、受動的（受信側の参加なし）のタスク転送は、学際的な相互作用と協力の精神と完全に矛盾しています。

• マルチレベルのサポートは、専門家の専門家（Subject Matter Experts）の混雑の問題を解決しません。 マルチレベルサポートは、専門家にとって簡単すぎる質問を与える問題を解決しますが、複雑なタスクに圧倒されることから保護しません。 「ヒーロー」は、ITサービス管理（ITSM）の真の災難です。 これらは一見、組織に目に見える利益をもたらし、複雑な問題を解決するために不思議なことに定期的に取り組んでいる賢い人々です。 実際、そのようなヒーローは仕事で過負荷になった単一障害点です。 彼らは自発的または非自発的に重要な知識の管理者であり、燃え尽きやすいです。 線形で断熱構造のマルチレベルサポートは、ヒーローの崇拝を妨げるものではなく、おそらくそれをサポートすることさえあります。 従来のビジネスをDevOpsに移行する過程で、DevOpsチームの主要メンバーがエスカレーションチェーンの最後に配置されると、このような作業スキームが保存されます。 DevOpsシナリオの被害はおそらくさらに大きくなります。主要な開発者はイノベーションから遠ざかり、エスカレートして既に失っている時間のあるユーザーへの対処を余儀なくされています。

代替としての群がり

「コラボレーションコミュニティは、協力、学習、進歩を促進することにより、専門的および組織的な障壁を克服できます。」

（ドン・タプスコットとアンソニー・D・ウィリアムズ、 ウィキノミクス ）

Swarmingは、技術サポートを組織するための新しいプラットフォームとして、過去10年の終わりに導入されました。 ネットワーク相互作用モデルを支持して、保守的なマルチレベル構造を明示的に拒否します。

出典： サービスイノベーションコンソーシアム

このシステムの実装を最初に開始した主要企業はシスコです。 2008年、 Digital Swarmingという論文で、彼女は「分散コラボレーションと意思決定モデル」を紹介しました。 このコンセプトはその後、Consortium for Service Innovationで採用され、 Intelligent Swarmingに変わりました。 その原則の一部は次のとおりです。

• サポートグループレベルに分割しないでください。

  
  
  
  
  
  
  

• あるグループから別のグループへのエスカレーションはありません。

  
  
  
  
  
  
  

• タスクは、それを解決できる可能性が高い従業員に直接転送する必要があります。

  
  
  
  
  
  
  
• 治療を受け入れた人が最後まで責任を負います。

スウォーミングの練習：DevOpsのサンプル構造

スウォーミングには、明確に定義された単一の構造はありません。 これは部分的には新規性と、それに伴う低い有病率によるものです。 ただし、以下の例は（BMCで使用される大量のユーザーサポート方法に基づく）典型的なものです。 彼はサポートサービスを大幅に改善しました（ 2015年の英国のServicedeskとITサポートショーで説明されています）。

スウォーミングは、ユーザーが要求したときにすぐには解決できない問題が発生したときに始まります。 タスクのクイック初期ソートは、2つのグループ（Swarms）のいずれかに送信することで終了します。

プライマリスウォームソート

各グループ（Swarm）は、着信アプリケーションをほぼリアルタイムモードで処理する小さなチームです。

「重大度1」Swarm （最初の重大度インシデントチーム）

• 計画された週次ローテーションで働く3人の従業員 。
• フォーカス：迅速な対応を提供し、できるだけ早く問題を解決します。

このグループは、最も深刻な問題を解決することを目指しています。 その参加者は、困難な状況への反応を調整し、適切な人々を結び付け、重大な問題に対する最も迅速な解決策を編成しようとします。 このプロセスは、従来のマルチレベルモデルで使用されている主要なインシデントの手順と大差ありません。 ただし、別のグループも並行して展開され、はるかに多くの呼び出しを処理します。

ディスパッチスウォーム （ ディスパッチグループ）

• 60〜90分ごとに会議を開催します。
• 地域と製品ラインに焦点を当てています 。
• 主な焦点： 「さくらんぼをつかむ」（まず、非常に迅速に修正できるものを引き受けます）。
• セカンダリタスク：コールを製品ラインサポートチームに送信する前に確認します。

このタイプのグループは、マルチレベルサポートの主な問題に対する答えとして登場しました。適切な専門家に連絡したときに非常に迅速に解決できる多くの呼び出しは、未完了のタスクのリストで失われます。 したがって、5分間の問題の解決策は数​​日間続くことがあります。

このグループのメンバーは、即座に修正できない問題に注意を払わずに、文字通りチェリーをつかむように押されています。 したがって、かなりの数の種類のタスクを解決するのにかかる時間を大幅に短縮できます。

追加の利点があります。 経験の浅い従業員を含めると、高度な専門チームに異動した場合にのみ、マルチレベルモデルでその知識にアクセスできるという知識が得られます。 同時に、第3レベルのサポートの有能なスペシャリストがクライアントにより近くなります。

Dispatch Swarmingを使用すると、多数のタスク（BMCでの数は約30％）の迅速な解決につながり、残りの呼び出しは個々の製品ラインを扱うより馴染みのあるサポートチームのキューに入ります。 ここでは、多くのタスクがチームの普通のメンバーになじみやすく理解しやすいため、それらのソリューションが問題を引き起こすことはありません。 同時に、構造的な所属に関係なく、コールの別の部分（おそらく約30％）は、最高のサポートサービススペシャリストの注目に値する可能性があります。

これは、3番目のタイプのグループBacklog Swarmを使用します。

バックログスウォーム （ バックログタスクグループ）

• 通常は毎日、定期的に会議を開催します。
• 主な焦点：製品ラインサポートチームから受け取った複雑な問題を解決します。
• 二次的タスク：単一の専門家を交換します。

Backlog Swarmは、地理的または構造的な境界に関係なく、経験豊富で熟練したエンジニアのチームを集めて、最も複雑な問題に対処します。 彼らは、専門家から個別に直接連絡することを現在禁止されている専門家からタスクを受け取ります。 代わりに、タスクを適切なBacklog Swarmに転送する必要があります。

群がる例

DevOpsと組み合わせて従来のテクニカルサポートを使用する場合、マルチレベルモデルの問題は激化するだけです。 この場合、未解決のタスク（Work in Progressバックログ）が活発に蓄積され、その結果、独立性と柔軟性が制限されます。 このようなシステムは、本質的に断熱性があります。 これらの問題は、DevOpsの哲学と矛盾しており、従来のビジネスモデルを持つ組織でのDevOpsプラクティスの実装に対する主な課題です。

すでに次のマイナス点を強調できます。

• DevOpsは、ソフトウェア開発者がそのサポートを引き受けることを奨励します（一般的に「自分で書いて-それを理解する」と呼ばれることもあります）。 ただし、大規模な組織の特徴である開発されたサポートサービスでは、複数レベルの構造が、ユーザーの問題がエンジニアに届く主要なチャネルです。 既にご存知のように、サポートの第1レベルとDevOpsチームの間の障壁は、問題の解決の遅れにつながり、コールの質の悪いプライマリ処理につながる可能性があります。

  
  
  
  
  
  
  

• DevOpsコマンドのソフトウェアライフサイクルを確保するためのアプリケーションおよびツールを受信するためにITSMシステム間で使用される「フェンスを越えて投げる」タイプの統合モデルは、従業員の状況認識の欠如につながります。

  
  
  
  
  
  
  
• 垂直および水平の障壁を強制的に導入しようとすると、さまざまな部門の専門家の相互作用が妨げられます。これは、DevOpsの使用を成功させるための重要な要素です。

対照的に、Swarmingの概念は、主にDevOpsの成功の根底にある同じ原則に基づいて構築されています。

• さまざまなスキルと能力の領域を持つ1人のチームスペシャリストをまとめることができる動的な機能横断的協力。

  
  
  
  
  
  
  

• 堅固な階層構造とは対照的な柔軟なチーム。

  
  
  
  
  
  
  

• 独断的なプロセスとは対照的な独立性（ここでの重要な例は、Dispatch Swarmの一部として作業中に「チェリーをつかむ」機能です）。

  
  
  
  
  
  
  

• 保留中のタスクの数を減らします。

  
  
  
  
  
  
  
• さまざまなプロファイルの専門家間のスキルと経験の交換。

おわりに

「愚かな、またはテクノロジーを嫌う人々がそこで働いているので、大企業はゆっくりと変わりません。 ユーザーがいるだけです。」

（2015年ベルギー、Puppet Labs。Configuration Management Campの創設者兼CEO、Luke Kaines氏）

DevOpsは、確立された保守的な作業方法の本質に疑問を投げかけ、開発者と運用サービスの専門家のこれまで孤立していた役割を組み合わせ、根深い非効率的な慣行を排除しようとします。 この哲学は、ほとんどの場合（完全ではないにしても）、新世代の組織で形成されました。多くの場合、時代遅れだが動作しているシステムとそのユーザーを維持する必要はありません。

これが非常にうまく行われたことに注意することが重要です：

出典：2016 Devops Status Report

現在、DevOpsは従来の組織に到達しており、実装の過程で（多くの場合非常に苦しい）彼は新しい課題に直面します。 しかし、そのような企業にとっては、これはもはや改善の問題ではなく、生存のための闘争に必要なステップです。 「創造的破壊」の形の変化は、大企業の存在に対する絶え間ない本当の脅威です。 2014年には1955年のFortune 500リストの12％しか残っていませんでした。

IT企業は、可能な限り新鮮なアイデアを使用し、常に保守的な慣行に疑問を投げかけるよう努力する必要があります。

Swarming運動はマルチレベルのサポートモデルへの攻撃を開始しましたが、従来の企業のITサービスの管理の進歩は、少数の先見の明がある組織での使用に限定されているため、遅いです。 ただし、SwarmingとDevOpsの主要な要素が近接していることを否定することは困難であるため、同様の実装上の問題があり、その解決策により両方のシステムを使いやすくなります。

したがって、マルチレベルのサポートモデルを再考する必要があります。 新しい方法論では、大企業全体で操作性と効率を維持しながら、DevOpsを活用する必要があります。 Swarmingはこの役割に適していると思います。