キラキラした事例に惑わされるな――SRE活動、まずやるべきは自動化……ではない!:リクルート流、SREコトハジメ(4)(1/2 ページ)
SRE活動というと、どうしても自動化やツール導入から進めたくなるものですが、一呼吸置きましょう。まずは現状を正しく把握することが先決です。これは、SRE活動を行うための「健康診断」といえるでしょう。
事業との密なコミュニケーションによりサービスを理解し、サービスの特性を意識しながら、個々の対応を適切に実施する。SRE活動とはこれが本質であり、組織を作る中で、各メンバーにこうした意識を浸透させることが大切である――。
これまでの連載では、SREの概要と組織の立ち上げについてお話ししてきました。今回からはいよいよ、リクルートで実際に行われているSRE活動を紹介していきます。
SRE活動のための「健康診断」――四半期ごとのインフラ情報棚卸し
突然ですが、皆さんは自身が担当しているサービスの規模や作業分量について即座に答えられますか? 例えば、構成サーバの台数や月間の作業件数、月間のPV数、月間の障害件数などです。いかがでしょうか。
「もちろん答えられる」という人もいるとは思いますが、「普段チェックしていないからな……」という人もいるでしょう。普段から触れているシステムであっても、定量的な情報を常時把握するのは、意外と大変です。それでは現状を把握せずに、SRE活動を行うことはできるのでしょうか? 答えは「No」です。
Webで検索すれば、SREの活動事例は多数出てきますが、その多くが自動化やツール導入の話です。もちろんそれは非常に参考になるのですが、どうしても、その目的より自動化、ツール導入といった“キラキラした話”の方が目立ってしまい、問題や課題が何なのか、そして、システムを運用する組織にマッチしているかといったポイントを見逃してしまいがちです。
自動化やツールの導入自体が目的になってしまうと、結果として「●●ツールを入れたけれど、使われていないな……何でだろう」という事態に陥りがちです。「このツールを使いましょう」といきなり言っても、すぐには皆使ってくれません。たとえ、それが良いものであっても、定着し、有効に機能するまでは時間がかかるのです。
SRE活動を行う上では、サービスの特性を理解することが非常に重要です。そのため、まずは問題や課題を把握するために、システムを客観的かつ定量的に測ることができ、かつ、組織内の誰もが理解できるようなシンプルなデータを定期的に観測することにしました。具体的には、定期的に行う健康診断のようなイメージで、四半期ごとにインフラ目線で「サイト棚卸し」を実施しています。
サーバ情報は構成管理資料から取得し、作業や障害の件数は、日々の運用でタスク管理に利用している「JIRA」の件数を集計。PV数はユーザーからのアクセスを受けるフロントサーバのアクセスログから集計し、DBの分析データは統合管理ツールから取得するなど、現環境に存在するデータソースから情報を得ています。それに加え、インフラ観点での気付きを、実際にSREとして運用を行っているエンジニアに記載させています。
初回のサイト棚卸しを実施した後、その結果をサービス関係者に展開したところ、思わぬ問題が見つかりました。想定以上のHTTP status code 500系エラーが発生していたのです。
関連記事
- コレ1枚で分かる「SRE(Site Reliability Engineer)」
これからの運用技術者に求められるアプローチとして注目される「SRE(Site Reliability Engineer)」について解説します。 - APIで社内、そして世界とつながる――リクルートのAI活用、そのキーマンに迫る
自社サービスにAIを積極的に導入しているリクルートだが、その活用を推進する部署がリクルートテクノロジーズにある。彼らがどのようにして業務部門と連携しているのか。そのカギの1つに「API」があるという。 - 脆弱性発見のプロ集団ーーリクルート「レッドチーム」の仕事とは?
インシデントを未然に防ぐために、社内のセキュリティリスクを洗い出す「レッドチーム」。日本でいち早く“自前”のレッドチームを立ち上げたリクルートテクノロジーズに、そのミッションと日々の活動を聞いた。 - ビッグデータで社会をあっと言わせるサービスを リクルートテクノロジーズ・泉さん
月間で数十億レコードという大量データを生成するリクルートは、ビッグデータの専門組織を立ち上げ、ビジネス成果を生み出すためのデータ活用基盤を構築。そのプロジェクトを率いる泉さんが考える未来像とは――。
Copyright © ITmedia, Inc. All Rights Reserved.