Array ( [0] => 355 ) 1234
Elasticsearchの導入事例が3分で分かる!
無料資料ダウンロード

デメリットの多いログ分析の属人化。脱却のための方法とは?

ログ運用

企業のセキュリティ対策として必須のログ分析業務ですが、担当エンジニアによって方法が異なるなど、属人化しているケースがあります。では、属人化によって起こる弊害にはどのようなものがあるでしょうか。本記事では、ログ分析の属人化によるデメリットと、解決策としてログ分析の標準化を実現した事例を紹介します。

お役立ち資料
著名企業9社から学ぶ取り組み事例

属人化が起きやすいログ分析業務

企業の情報システム部門では、セキュリティ対策としてシステム障害の検知や分析を迅速に行う必要があります。しかし、サービスごとに担当のエンジニアがいることが多く、エンジニアによってログ分析の方法が異なる場合があり、ログ分析の属人化が起こりやすい状態です。
また、ログ分析は専門的な知識やスキル、経験が求められるため、各エンジニアが我流で技術を習得していると他のエンジニアとなかなか共有できません。これも属人化が起きやすい理由です。

こうしたログ分析の属人化にはどのようなデメリットがあるのでしょうか。代表的なものを以下で紹介します。

ログ分析の属人化によるデメリット

ログ分析の属人化によるデメリットとして、以下の3つがあります。

人材の流動性がなくなる

1つ目は、人材の流動性が失われることです。
属人化とは、ログ分析の方法を理解している人が一部に限られることを意味します。そのため、人員の配置転換を容易に行えません。結果として人材の流動性が失われ、組織の活性化が図りづらくなるほか、多様な経験を積みにくくなることで、エンジニア個人のキャリアアップにも悪影響を及ぼします
また、属人化している状態でログ分析を担っていた人材が退職や異動してしまうと、分析方法がブラックボックス化する懸念もあります。

サービスごとにログ分析の方法が違う

2つ目は、サービスごとにログ分析の方法が異なる点です。この場合、異動や退職などによって担当者が変わると、業務の進め方を理解するまでに時間がかかります
また引継ぎも煩雑であるため、新旧双方のエンジニアにとって大きな負担です。さらに、サービスごとにログ分析の方法が異なると、サービスやシステムを横断した分析を行えず、非効率な業務が発生してしまいます。

インシデントへの対応が遅れやすい

3つ目は、インシデントへの対応が遅れやすい点です。
情報システム部門の担当者は、多くの場合ログ分析以外の業務も抱えています。そのため、ユーザー部門でインシデントが発生し対応依頼があっても、専任の担当者しか対応できなければすぐにログ分析できず、解決までに時間がかかります
また属人化に加えて、複数のシステムが動いているケースも望ましくありません。なぜなら、どのシステムのログが最短ルートの解決につながるのか専任の担当者にしかわからず、対応が非効率的になるからです。
セキュリティ上のトラブルやネットワーク障害は、初動対応が遅れると被害が拡大するため、一刻も早く対処しなければなりません。そのため、本来の担当者が不在でも対処できる体制を整えることが大切です。

このような属人化のデメリットを克服するには、ログ分析の標準化が不可欠です。そこで以下では、ログ分析を標準化したことで属人化を脱却した事例を紹介します。

ログ分析の脱属人化を図るならElasticSearch

Elasticsearchは、さまざまなユースケースを解決する分散型RESTful検索/分析エンジンであり、データを手軽かつ一元的に格納、検索、分析できる点が特長です。超高速検索や、関連性の細かな調整や、データの傾向やパターンを幅広く探る分析も大規模に実行でき、ログ分析の属人化を解消します。

以下の資料では、著名企業9社における導入・取り組み事例を紹介しています。ログ分析の標準化による属人化の解消に興味をお持ちの方は、ぜひご覧ください。

ログ分析を標準化し、属人化を脱却した事例  ―株式会社KADOKAWA Connected様―

株式会社KADOKAWA Connected様は、KADOKAWAグループのDX推進を担い、ICTコンサルティングや働き方改革支援なども手掛ける企業です。同社の中にあるサービスインフラチーム(KADOKAWA Cloud Service部)では、これまでエンジニアが長く同じ仕事に携わるケースが多く、業務の属人化が進行していました。
属人化が起きている状態でサービスごとにログの検索・収集・格納に使う技術が異なると、エンジニアは担当するサービスが変わるたびに新しい技術の使い方を習得しなければなりません。その結果、人材の流動性が高まらず、各エンジニアのキャリア選択の幅が狭まります。
この点が社内で問題視され、ログ検索・収集・格納の仕組みを単一のソリューションで標準化・共通化することが求められていました。

そこで注目したソリューションがElasticsearchです。ただ、Elasticsearch単体では頻繁なバージョンアップに対応した仕組みをサービスごとに構築する必要があったため、ECE (Elastic Cloud Enterprise)を活用し、Elasticsearchのバージョンアップを簡単に行えるようにしました。
またESaaS (Elastic Stack as Service)の構築にも着手し、Elasticsearchクラスター利用のセルフサービス化を実現しました。これにより、障害調査や関係者へのアラート発信のプロセスを効率化・自動化し、サービスを管理・運用する担当者の負担を大きく減らすことに成功。調査作業の際に特殊なスキルが不要になり、エンジニアの組織内での流動性を高める効果もありました

以上の事例のように、Elasticsearchを活用することで、ログ分析の標準化を図れます。

株式会社KADOKAWA Connected様の事例は以下の記事で詳しく紹介していますので、興味のある方はぜひご覧ください。

株式会社 Kadokawa CONNECTED Elasticsearch、Kibanaの簡単活用を可能にする Elastic Stackのプライベートクラウドサービスを実現

お役立ち資料
著名企業9社から学ぶ取り組み事例

関連記事はこちら

データ検索一覧を見る

お問合せ・資料請求

Elasticsearch 製品の導入、販売に関するお問合せはお気軽にご相談下さい。

Elasticsearch 製品の導入・販売に関するご質問はこちら
※関連サイトへ遷移します
お問合せフォームから質問する
Elasticsearch 製品のサービス資料はこちら
サービス資料を読む