最初の自動化で「大失敗」して得た気付き――SREはトライ&エラーが全てである:リクルート流、SREコトハジメ(5)(1/3 ページ)
現状の把握も終え、いよいよ運用作業を自動化しようとしているアナタ。私自身もSRE活動を始めてすぐに自動化に取り組みましたが、実は最初に「大失敗」をしてしまいました。そこで「トイルの削減=自動化」と勘違いしていたことに気付いたのです。
SRE活動と言うと、どうしても自動化やツール導入から進めたくなるものですが、その前にすべきこととして、Webサイトの現状を把握する「棚卸し」をするべきだ――。前回の記事では、その理由と具体的な取り組みについてお話ししました。
棚卸しを終えたら、いよいよ自動化、つまりはトイル(Toil=自動化できるのに手作業で行う運用作業にかける労働時間)の撲滅へと動き出すことになります。トイルというのは、SRE活動の中でもクローズアップされやすいキーワードで、全てが自動化された夢の世界を思い浮かべる方もいるかもしれません。
SREの取り組みをスタートした直後、私も例に漏れず、現行の運用作業を自動化しようと動き出しました。トイル撲滅のお題目として「インフラの運用作業を楽にしよう」と掲げ、最初は全体の作業のうち、インフラに関するものだけを洗い出し、その自動化を行えばいいと考えていたのです。
最も頻度が高い作業の一部を自動化し、「これでいけそうだね」と一部のメンバーと話していた矢先、思わぬ事態が発覚しました。「前より多少楽にはなったけど、全体としてはそれほど変わらない」という意見が出てきたのです。
フロー全体を把握して分かった、局所的な対応の限界
衝撃的でした。なぜこんなことが起きてしまったのでしょうか。改めて作業フロー全体を把握するため、目の前の作業以外も含めて周囲のメンバーに聞いて回ったところ、作業よりも、作業を進めるためのフロー全体に課題があることが見えてきました。つまり、フロー全体を把握せず、作業のみをフォーカスして自動化しようとしていたのが間違いの原因だったのです。
自動化を念頭に置き、抜本的にフローを変えようとあちこちに聞いて回ると、「フロー全体が変わるとタスクが漏れてしまうかもしれない」といった懸念や、「フロー内の一部自動化は実装漏れの心配がある。手動の方が安心ではないか」という慎重な意見も出てきました。
これらの意見はいずれも否定的なものではなく、新しい形を作るために検討しなければいけない事項であり、そこまで十分に考慮できていなかった自分自身の至らなさを痛感しました。把握できた全体フローのイメージは下記の通りで、当初実施しようとしていた自動化が、非常に局所的な範囲にすぎなかったことが分かります。これでは、自動化したところであまり意味がありません。
関連記事
- コレ1枚で分かる「SRE(Site Reliability Engineer)」
これからの運用技術者に求められるアプローチとして注目される「SRE(Site Reliability Engineer)」について解説します。 - APIで社内、そして世界とつながる――リクルートのAI活用、そのキーマンに迫る
自社サービスにAIを積極的に導入しているリクルートだが、その活用を推進する部署がリクルートテクノロジーズにある。彼らがどのようにして業務部門と連携しているのか。そのカギの1つに「API」があるという。 - 脆弱性発見のプロ集団ーーリクルート「レッドチーム」の仕事とは?
インシデントを未然に防ぐために、社内のセキュリティリスクを洗い出す「レッドチーム」。日本でいち早く“自前”のレッドチームを立ち上げたリクルートテクノロジーズに、そのミッションと日々の活動を聞いた。 - ビッグデータで社会をあっと言わせるサービスを リクルートテクノロジーズ・泉さん
月間で数十億レコードという大量データを生成するリクルートは、ビッグデータの専門組織を立ち上げ、ビジネス成果を生み出すためのデータ活用基盤を構築。そのプロジェクトを率いる泉さんが考える未来像とは――。
Copyright © ITmedia, Inc. All Rights Reserved.