小売部門では、技術的な不具合は店舗の従業員にとって大きなストレスであり、中断したビジネスプロセスによる直接的なビジネス上の損失です。 以前の資料の1つで、貿易インフラストラクチャのサポートに関与するサービス会社の第一線のサポートスペシャリストが、発生する問題をどのように解決するかを発見しました 。
今回、Pilotの技術サポートサービスの責任者である Vyacheslav Shambazovは、エンジニアが最も複雑で重大な技術インシデントを処理する2番目のサポートラインについて話しました。
2番目のサポートラインと最初のサポートラインの違い
サポートの最初の行では、顧客の要求を分類し、自分で問題の解決を試みます。 これが短時間（5〜15分）で完了しない場合、または追加の能力が必要な場合、インシデントはサポートの2番目のラインに転送されます。 従業員はより深い技術スキルを備えているため、新たな問題に迅速に対処できます。
セカンドラインエンジニアが最初のエンジニアに転送されるという情報を必ず確認してください。 これは、問題に遭遇してストレスを受けているユーザーが同じ質問を繰り返し尋ねられることを意味するものではありません。 故障の本質を素早く見つけるのに役立つ追加の詳細を彼から見つけてください。
例：データベースにエラーがある場合、最初のサポートラインの従業員はデータベース管理者（DBA）の能力を持たない可能性があるため、ユーザーとの対話中に、特定のデータベースに固有の重要な質問をすることはできません。 彼らは事件の詳細を知るだけであり、第二線の従業員はすでに適切なマシンで実行されているインスタンスとサービスとエラーコードについてより深い質問をしている。
最初のサポートラインの作業がどの程度デバッグされていても、解決できないインシデントが常に発生します。 その結果、2行目のエンジニアに連絡します。 時間が経つにつれて、受け取ったアプリケーションの遡及的分析が常に行われます-これは、将来的には最初の行のヘルプデスクの従業員がそのような問題を自分で解決できるようにする指示または自動化スクリプトを書く目的で行われます。
同じサービス部門内のさまざまなサービスの相互作用の詳細のため、遡及分析はあまり頻繁に（たとえば、1日に1回）実行できません。 このようなコミュニケーションは常に規制されているため、サポートの2行目のエンジニアは、1行目の従業員に毎日新しい指示を習得させ、スクリプトの作業を理解させることはできません。 この作業には独自のサイクルがあります-今月があります。 このアプローチにより、リソースを割り当てて問題を修正し、説明を作成し、結果のドキュメントとツールをサポートの最初の行の作業に実装できます。
実際の仕組み
2番目のサポートラインのエンジニアは常に1番目のヘルプデスクの従業員より少ないため、彼らが受け取ったアプリケーションはオンラインで実行されません。 2行目に転送するとき、アプリケーションは処理のためにキューに入れられます-通常は30〜45分かかります。
キューイングの際、アプリケーションの緊急性と重要性が分析されます-ストアが深刻な問題に直面した場合、誰もバイヤーやスタッフにソリューションを40分待たせず、インシデントの作業をすぐに開始します。 小売業者とサービス会社との間の契約は、緊急のタスクに対して常に一定レベルのSLAを規定しています。 したがって、特定の種類の問題がビジネスに重大な損害を与えると企業が個別に示した場合、そのようなアプリケーションは一般的なキューからエンジニアによって処理されます。
2番目のサポートラインの実際の例を見てみましょう。
サービス会社は、レジでレシートの印刷を停止したレジで電話を受けました。 この場合、最初のサポートラインは、レジの要素をチェックするための標準的な手順に従う必要があります。たとえば、プリンターの用紙切れ、レシートリボンの詰まり、必要なインジケーターがすべてデバイスに点灯しているかどうかの確認などです。コンセントからワイヤーを引っ張りました。
この後、ユーザーはテスト操作を実行するよう求められます。たとえば、キャッシュレジスタレポートを送信して印刷し、新製品を破損することなく機器の性能を検証します。 問題が解決しない場合、サポートサービスの従業員はリモートでチェックアウトカウンターに接続し、重要なサービスとオペレーティングシステムドライバーの操作性に関する追加の診断を行うことができます。
インシデントを解決できなかった場合、2番目のサポートラインのリクエストが作成されます。 このチケットには、問題に関するすべての情報が含まれ、問題を修正するために最初の行で実行されるアクションについて説明します。
第二線のエンジニアは、問題の解決を開始し、以前にインシデントの一部として収集されたすべてのデータを確認し、同様の障害の説明を含むナレッジベースを調査できます。 第一線のサポートスタッフとは異なり、これらのスペシャリストはすべての顧客のインシデント統計にアクセスでき、技術分野のより深い知識を持っています。 インシデントが到着すると、スケジュールされた時間内に解決するためのオプションを選択できます。これは、同様の状況が以前に満たされたり文書化されていなかった場合でも同様です。
チェック印刷の例では、印刷サービスとの競合を引き起こす更新がオペレーティングシステムにインストールされているか、オペレーティングシステムのユーザーのアクセス権の変更につながるドメインポリシーの変更があったことをエンジニアが見つける場合があります。 または、たとえば、プリンターでは、電力サージの結果として、制御プログラムのマイクロコードが劣化したため、今度はそれを再度「フラッシュ」する必要があります。
問題を見つけた後、それを解決する最も簡単な方法は、標準からシステムイメージを復元することです。 何らかの理由でリファレンスサンプルがない場合（これは技術のパイロット実装の段階である可能性があります）、必要な設定を手動で行う必要があります。
小売業におけるサービスの優先事項の1つは回復の速度であるため、私たちの実践では、このような状況は非常にまれです。 そして、問題を解決する最速の方法は、システムを標準から復元することです。
2行目をアプリケーションの処理に接続するもう1つの例は、以前は複雑だった問題の処理です。 たとえば、販売時点情報管理は、現金レポートの不一致の申請書を提出します。 最初の行は、それを受け入れて、このアプリケーションをタイプと緊急度で分類し、アプリケーションのタイプに応じて2番目のサポートラインの適切なエンジニアグループに転送します。 同時に、アプリケーションの種類に応じて、最初のサポートラインの専門家が、アプリケーションで指定されたオブジェクトに関する主要な情報のコレクションを提供します。 インストールされているソフトウェアのバージョン、構成ファイル、イベントログまたはオペレーティングシステム設定、コンピューターのアドレスまたは名前、周辺機器のモデルと数などがあります。
同様のアプリケーションを受け取った2行目は、オブジェクトに関する簡単な質問に気を取られることなく、アプリケーション自体の解決に進むことができます。つまり、この例では、レポートで検出された不一致を排除することです。 この作業には非常に長い時間がかかる可能性があり、セカンドラインエンジニアが熟知しており、必要な能力を備えているさまざまな要因の結果である可能性があります。
2行目のエンジニアを1行目のサポートレベルでは解決できない解決アプリケーションに接続する別の例は、多くの場合、サーバーハードウェアの障害です。 メンテナンスにはかなりの能力が必要であり、その操作の失敗は、サーバーハードウェアコンポーネントの明らかな失敗に必ずしも表れていません。 したがって、アプリケーションはテクニカルサポートの2行目に転送され、その専門家はインシデントを排除しようとします。 サーバーの熱動作モード、個々の要素の障害（メモリの誤動作、ハードディスクの不良セクタ、メモリキャッシュバッテリの障害）、サーバーソフトウェア（DBMS、ERP、BI）の中断、またはこのサーバーの外部の他のシステムとの相互作用。
結論：小売業者がインフラストラクチャ自体にサービスを提供しない理由
サービス会社は、小売部門で使用されているテクノロジーを使用した幅広い経験を持っています（たとえば、当社は25歳であり、知識はきちんと蓄積されています）。 弊社のエンジニアは、さまざまなサイズと種類のインフラストラクチャで発生した多数のインシデントに直面しました。 これはすべて、実際の問題を解決するための多才な経験の獲得に貢献します。
小売業者が独自のIT部門を開発することを妨げるものは何もありませんが、テクノロジーを扱うことはそのような企業のビジネスではなく、彼らの仕事は商品を売ることです。
さらに、テクノロジーアウトソーシング業者は、ほとんどの問題が発生する可能性があるビジネスアクティビティのピークに適応する能力を備えています。小売業者がAppleガジェットを販売している場合、小売店での新しいデバイスのリリース後の秋と春には、買い手が常に流入し、その結果、より多くの取引失敗が発生しますインフラストラクチャ。 すべての問題を解決するための当社のITスペシャリストの強さでは不十分な場合があり、より多くの人を雇用することはビジネスにとって有益ではありません。
そして、たとえば、サービス会社として、このようなピーク時に作業するために追加の従業員を割り当てることができ、特定の顧客のタスクに取り組むエンジニアの特別なチームを形成することさえできます。 これは、非中核ITコンピテンシーの開発にエネルギーとリソースを浪費するよりも、ビジネスにとってはるかに有益です。