トップ > ぐるなびを支える技術 > SREエンジニアがヘルプデスク体制を作ってみた話

SREエンジニアがヘルプデスク体制を作ってみた話

ぐるなびを支える技術 【執筆者】小野

こんにちは。データ・AI戦略部 SREチームの小野です。2020年8月に入社してから早3年。SREエンジニアとして、日々業務改善に励んでいます。

ここ一年ほど、SRE業務の一環で組織作りに挑戦しています。SREエンジニアの責務は自社サービスを安定稼働させ障害に強い基盤を作ることであり、どちらかというと「システム」に焦点が置かれがちです。しかし、個人的にはシステムを運用するメンバーのマネジメント(ピープルマネジメント)を含めた組織作りも重要だと考えています。なぜなら、どれだけ最先端で素晴らしいシステムを構築してもそれを運用するメンバーの行動次第では、障害につながる恐れがあるためです。

私にとってのSREは組織作りにおける文化のようなものであり、「SRE(文化)を組織にインストールする」気概で色々と挑戦しています。

今回は、その挑戦の一つとして「ヘルプデスク体制を構築した話」をお伝えしたいと思います。

<目次>

ヘルプデスク体制導入の背景

「ヘルプデスク体制」とは、組織や企業が提供するカスタマーサポートを指しており、依頼者からの問い合わせやトラブルに対応し、技術サポートを提供するサービスです。

イメージは、以下の通りです。

ヘルプデスクイメージ

この体制を構築することになった背景として、私たちが抱えていた組織的な課題について簡単にお伝えします。

組織課題

以前執筆したブログSREエンジニアが組織改善プロジェクトを立ち上げてみたでも触れましたが、私が所属しているデータ・AI戦略部では以下の組織課題を抱えていました。

<組織課題>

  • メンバー交代による引継ぎリスク
  • タスクやナレッジの属人化
  • コミュニケーションロス

組織課題

これらの課題はどのような組織でも起こり得ることだと前回お伝えしました。 加えて、私たちはデータ基盤を運用しており、組織内外から様々な依頼を請け負っています。

<依頼例>

  • データの抽出依頼
  • データウェアハウス/データマート作成
  • 障害対応依頼
  • etc…

しかし、一元的に問い合わせを受け付ける仕組みが存在していなかったため、組織課題に呼応するかのように次の問題が発生していました。

<依頼対応時の問題>

  1. バイネームによる依頼
    バイネームにすることで、特定のメンバーに仕事が偏る。

  2. ナレッジの属人化
    個人にタスクが偏ることで、属人化になる。

  3. 組織化の阻害
    属人化になることで、組織で課題に対処できない。

  4. 担当者不在
    組織でない場合、担当者不在時の問い合わせ先が不明。

  5. 事象解決コストの増加
    担当者不在や属人化により、問題解決にコストがかかる。

  6. 成長の阻害
    問題解決コスト増により、組織の成長が阻害される。

問い合わせに対する課題

このような問題に対処するため、ヘルプデスク体制を導入することにしました。

ヘルプデスク体制とは

「SREエンジニアが組織改善プロジェクトを立ち上げてみた」でも紹介しましたが、DAOという組織改善プロジェクトに取り組んでいます。このプロジェクトは組織内で発生するあらゆるイベントを「機能」として定義・実装し、それらを束ねてサービスとして組織内外に提供するプロジェクトです。

DAOでは組織体制の見直しも行なっており、先にあげた「組織課題」を解決すべく、業務フローの構築・コミュニケーションの改善・ドキュメントの強化などを実施し、個人で働く組織から組織で働く組織にアップデートしました。これにより組織で課題に対応できる体制を構築したので、この体制を流用してヘルプデスク体制を作りました。

ヘルプデスク体制の概要は、以下になります。

ヘルプデスク体制

機能名 用途 目的
⓵ 問い合わせフロー 依頼者からの問い合わせに対し、障害受付窓口を提供する。 バイネーム問題および担当者不在の解決。
⓶ トラブルシューティング ナレッジデータベースを活かしつつ、問い合わせ内容を適切に分析し、解決策を見つける。 ナレッジの属人化問題の解決。
⓷ レポートとトラッキング 依頼者からの問い合わせやトラブルの詳細を記録し、必要な場合には問題の進捗状況をトラッキングする。 組織化の阻害問題の解決。
⓸ ナレッジデータベースの管理 頻繁に発生する問題に対する解決策や手順を蓄積したナレッジデータベースを構築・運用する。 事象解決コスト増加問題の解決。
⓹ リモートサポート 依頼者に対して、リモートで問題解決のサポートを行う。 成長の阻害問題の解決。

ヘルプデスクフロー

先の図では抽象的すぎたかもしれないので、実際に運用しているフローをいくつか紹介します。

問い合わせフロー

まずは、問い合わせフローを紹介します。

「依頼者」から問い合わせを受け付けた後、「一次切り分け担当者」が内容を確認し、依頼内容の振り分けを行います。仮に問い合わせ内容が自分で回答可能であればそのまま回答し、詳細な調査が必要であれば別途担当者をアサインするフローになっています。

問い合わせフロー

課題対応フロー

課題対応フローは、問い合わせを受け付け、それを解決するまでのフローに焦点を当てています。 このフローでは、「過去事例/ナレッジ検索」が特に重要になってきます。SREエンジニアとして「ポストモーテム」と呼ばれるシステム障害についてまとめたドキュメント文章を作成・管理しており、このドキュメントを蓄積し、過去事例(ナレッジ)データベースを構築しています。

私がSREエンジニアとしてヘルプデスク体制を構築したかった理由の一つは、ポストモーテムの利活用にありました。ポストモーテムは「作成したらそのままお蔵入り」ということになりがちであり、見返される機会はあまりありませんでした。しかし、このフローを構築することで常にポストモーテムが検索される状態になりました。

課題対応フロー

サポートフロー

最後にサポートフローの紹介です。

後述しますが、基本的に問い合わせ窓口は「Slack」によるテキストベースの依頼になります。しかし、テキストだけでは伝えきれないこともあると思いますので、「ディスカッション」という形でGoogle Meetから一次切り分け担当者 or 担当者と直接相談できる窓口を作りました。

さらに対応完了後には依頼者へアンケートの回答をお願いし、ヘルプデスク体制の更なる品質向上に努めています。

サポートフロー

問い合わせの仕組み

ヘルプデスク体制には色々なアイデアを詰め込みましたが、本ブログはエンジニアブログであるため「技術的な取り組み」についても触れておきます。

ヘルプデスク体制を構築する上で大変だった取り組みの一つが、問い合わせ窓口を作ることでした。

問い合わせ窓口

弊社ぐるなびでは、チャットツールとしてSlackを活用していたので、このツールを活用して問い合わせ窓口を作ることにしました。

技術選定

使用技術の一覧を記載します。

技術 選定理由
Slack Slack AppおよびSlack ワークフローからアプリを作成できる。
Jira Jira APIを経由してJira上にタスクを作成できる。
AWSサービス(API Gateway, Lambda, ECR) Slack ワークフロー(およびアプリケーション)とJira APIを中継するインフラ基盤。

インフラ構成と処理フロー

下図は、ヘルプデスクシステムの簡単なインフラ構成になります。弊社はTFCB(Terraform Cloud Business)を導入しているため、インフラ(AWS)周りは一瞬で構築できます。 ※ TFCBについてはTerraformとTerraform Cloud Businessを導入してインフラ環境の構築・運用を改善してみたを参照ください

ヘルプデスクインフラ

依頼者には、問い合わせ用チャネルから指定のフォームで問い合わせをしてもらいます。すると、リクエスト(依頼)がAPI Gatewayを経由してLambda上で動くアプリケーションをキックし、Jira APIに接続後、Jiraにタスクを作ります。そして、問い合わせチャネルに受付完了連絡、問い合わせ対応用チャネルに問い合わせ受信連絡を行うフローになっています。

SlackからJiraのタスクを作れるとめちゃくちゃ便利です。

SlackからJiraのタスクを作成した時のサンプル

Slack Appの開発

Slack Appは、Slack上で動作するアプリケーションやボットを指します。このSlack Appを使用してPythonベースのアプリケーションを作成しています。

使用したライブラリは以下の通りになります。

ライブラリ名 バージョン 補足
slack_bolt 1.18.0 Slackアプリ構築用のライブラリ
Jira 3.2.0 Jira API用のライブラリ

以下のフォルダ構成でアプリケーションを開発しました。

.
├── .github
│   └── workflows
│       └── deploy.yaml #Github Actionsで実行するワークフローファイル
├── README.md
├── docker
│   └── Dockerfile #Dockerイメージ作成用のファイル
└── src
    ├── lambda_function.py #Lambda上で実行するスクリプト。SlackAppやJiraの操作を行う
    └── requirements.txt   #lambda_function.pyで利用するライブラリを管理するファイル

ちなみに、Slack AppはDocker コンテナ化してLambdaに乗せて運用しています。

Slack ワークフローの構築

Slack ワークフローは、Slack上で特定の業務プロセスを自動化するための手順やスクリプトのセットになります。これにより特定のイベントやトリガーに応じてタスクが実行され、効率的なフローを作成することができます。

例えば、以下のようなワークフローが作れます。

Slackワークフロー

Slackでフォームも作成できます。

Slackフォーム

Slackワークフローを起動し、投稿メッセージ内でSlack Appへメンションを飛ばすことで、リクエストがAPI Gateway -> Lambda(Slack App)に飛びます。

受付完了後、Slackの各チャネルには以下のメッセージが通知される仕様にしました。

問い合わせ用チャネル

問い合わせ対応用チャネル

問い合わせ対応チャネルに依頼者からのメッセージが届いたら対応スタートになります。

タスクの管理はJira上で行えるので、使い勝手としてはかなり便利です。

ヘルプデスク体制構築の所感

2023年10月にヘルプデスク体制を導入したばかりで、まだ一部のチーム内の利用に留まっていますが、既に以下のメリットを感じています。

  1. 問い合わせの一元管理
    今まではSlackからBy Name(個人宛)で問い合わせがきており、属人化が発生していた。しかし、Slack App + ワークフローで問い合わせ窓口を作り、Jiraに直接タスクが登録される仕組みを作ったことで解消できた。

  2. 問い合わせ対応品質の向上
    問い合わせを組織で対応できるようにしたことで、依頼者は問い合わせ先に悩む必要はなくなった。また、チームメンバー間で問い合わせ内容を共有化することができるようになったため、対応品質の向上に繋げることができた。

  3. 過去事例/ナレッジの蓄積
    Jiraのタスク登録やポストモーテム作成などの工程を業務フロー内に組み込むことができた。これにより、過去事例やナレッジを蓄積し、システムの改善やメンバー教育に繋げる土壌を作ることができた。

デメリットは今のところ感じていませんが、今後ヘルプデスクの利用が増えてきた際、一次切り分け担当者の負担が増えるのではないかと懸念しています。そうなった場合でも組織的に対処できるようにメンバーとコミュニケーションをとりつつ、ヘルプデスク体制を運用していきたいと思います。

おわりに

ヘルプデスク体制の導入は、SREエンジニアとしてサービス品質の向上に貢献できたと強く感じています。システムは構築して終わりではなく、むしろ運用フェーズが本番だと言っても過言ではありません。

  1. システムを構築する <<< 大切
  2. システムを運用する <<< すごく大切
  3. システムを改善する <<< とても大切

構築し、運用し、改善する、このプロセスをうまく回せるように援助することがSREエンジニアの責務の一つであると考えています。

今後はAIなども活用し、更なる業務改善を図りたいと考えています。そうなった場合、またこのエンジニアブログで紹介できたら幸いです。

ここまでお読みいただき、ありがとうございました。

小野
小野

2020年中途入社です。ぐるなびではSRE活動を推進しています。いつか自分でもサービスを企画・開発できるようになりたいです。最近、ゴルフをはじめました。

ono-hiroki