SREはインフラの「攻守」を担う率先的な技術者集団
SRE（Site Reliability Engineering）と呼ばれる概念・手法は、もともとGoogleのインフラを担う一部門の名称だった。2003年にエンジニアリング担当 VPであったBen Treynor Slossが入社時に作った組織であり、手順書に沿った安定運用を行う「従来のインフラ運用」と、変化に柔軟に対応する「ソフトウェア対応」という「攻守」を併せ持つことで、可用性・スケーラビリティを担保しながらサイトパフォーマンスなどの改善を図り、サービス向上を目指すというものだ。
「もちろん、発想自体はどこにでもありました。しかし、担当を人や部門で区切るのではなく、1人もしくは1チームで両方の業務を担うのです。例えば、50%の時間を既存のオペレーション業務にあて、残りの時間を『進化』のための自動化などの業務にあてるといった感じですね。結果、その場その時の『点』で仕事をしていたものが、サービスの未来の運営まで意識した仕事へと変化していくのです」（河村氏）
河村氏が取り組みを始めた2014年時点でのメンバーは数人だった。しかし現在は協力会社を含めて220名の大所帯へと成長。その人数も特徴的だが、組織も大規模なサービスを多数抱えるリクルートならではの構造をしている。
現在、SREと商用サービスのインフラを担当する部門「サイトリライアビリティエンジニアリング部」は6つのグループに分かれている。1つは高岡氏がマネジャーを務める「クラウドグループ」であり、パブリッククラウドをサービスに活用するための最適化を担う。そして、リクルートのオンプレミス基盤「RAFTEL」を開発・管理するグループが1つ。この2つのグループは従来のインフラ部門に近い業務に携わっている。残る4グループがSREを中心に活動しており、それぞれのサービスを提供する事業会社ごとに分かれている。
「そこがサービスの全てをカバーするスタートアップ企業のSREとは若干異なっているかもしれませんね。私はクラウドグループのマネジャーをしながら、並行して、リクルートライフスタイルのSREグループでいくつかのサービスを担当しています」（高岡氏）
複数のサービスに横断的に携わる中で、最も大きな課題となっていたのは要件対応の煩雑化だ。事業会社側からの対応申請はExcelシートのメール添付で行われており、効率化を目指してテンプレート化が進められてきた。しかし、それぞれの担当者のリテラシーが異なる状況下では記入できない項目も多く、ドキュメントが増大。技術の進化によって影響範囲が広がったことで申請書自体も増え、負担が増えていく傾向にあった。
「高効率・高集約を目指してきたはずが逆行していたのです。考えてみると、そもそも事業会社が何を実現したいのかを理解していれば申請書も不要だし、先回りして対応ができる。無駄な作業もなくなるでしょう。例えば『スマートフォンの顔認証を使って新しいサービスを作りたい』という構想が共有できれば、計画前からインフラ側でも何が必要か事前に検討することが可能になります。それがSREの真価ではないでしょうか」（高岡氏）
そこでミーティングを密に行うなど、事業会社との「人と人」の直接的なコミュニケーションを充実させてきた。仕様変更といった業務のやりとりに加え、新しいサービス機能や将来の方向性などまで共有するのが目的だ。
「双方の理解が断然早くなりましたね。これまで『なぜそうなっているのか』が説明されずに物事が進むことが多く、それが原因で対応方法がズレてしまうこともありました。しかし、理由が判明すれば、なぜ障害が起きるのか、どう対応すればいいのかもわかるし、未然に防げる可能性も高まります」（高岡氏）
SREを推進するために欠かせない「コミュニケーションツール」、さらなる効率化を目指して開発した「自動化システム」
では、リクルートテクノロジーズにおけるSREの業務は、どのような技術やツールを用いて進められているのだろうか。大きな鍵を握っているのが、事業会社とのギャップを埋めるためのコミュニケーションツールだ。
「近年ではSlackがメインになってきました。リアルタイムにオープンなコミュニケーションを図れるため、1対1の口頭のみで伝えたといった状況はなくなり、かなり風通しが良くなったように思います。実は今もExcelでのやりとりも続いているのですが、詳細はSlackでやりとりして、それにまつわるタスクをプロジェクトツールの『JIRA』で管理することで、対応漏れや遅れが少なくなりました」（河村氏）
チケットによって対応が全て管理されてグラフ化まで行われるため、ナレッジやスキルの分布がわかり、スキルセットの見直しやタスクの分配などにも活用できるようになった。さらに、ビジネス向けWikiの「Confluence（コンフルエンス）」に貼り付け、ナレッジや進捗を共有している。
「問題点や課題が整理されて見えますし、サービス担当者も閲覧できるようにしているので、こちらから対応状況を知らせなくても把握してもらえるようになりました」（河村氏）
重視しているのは事業会社とのコミュニケーションだけではない。リクルートテクノロジーズではSREの担当者220名が誰でも参加できる情報共有会を隔週で行っている。それぞれのサービス担当者が2人ずつ、どのような取り組みを行い、成果があったのか発表を行うというものだ。毎回100名以上が参加し、興味深いことや問題点を共有している。
「かつては機能単位でのナレッジ共有だけだったため、横断的なトラブルになるとお手上げという状況に陥りがちでした。しかし、機能ごとはもちろんミドルウェア、サーバ、OS、ネットワークといった組織内の縦串でも情報や状況が共有されるようになり、障害対応はもちろん、改善においてもシームレスな連携が可能になってきました」（河村氏）
コミュニケーションの改善以外では、インフラ構築を、より効率的に行う環境の整備も進めている。河村氏は、通常は手間がかかるサーバ環境構築をボタン1つで可能にするシステムを開発したエピソードを例にあげた。
「それぞれのサービスに合わせた最適なインフラを迅速に構築するには、『サービスを開発する事業会社の担当者がアーキテクチャまで自ら設計・実装できるようになると良いのでは？』という仮説をもとに、GUIで簡単にインフラを構築できるシステムを作ったんです。それによってサーバの要件が確定すると同時に、構築まで完了するのではないかと考えました」（河村氏）
このシステムは約1年を経て2017年10月にカットオーバーされ、社内で使用されている。
「仮想基盤であるVMWare上にサーバを載せているのですが、NSXでネットワークを仮想化してシステムを使用できるようにして、リクルート用に要件設定の仕組みをスクラッチ開発しました。ネットワークの払い出しやDNSの設定、サーバの配置、OSの設定などを全自動で行う『オーケストレーション』としての機能を持っています」（河村氏）
こうした自動化システムの提供、そして前述したコミュケーションツールの活用によって仕事は大きく変化しつつある。最も大きいのは運用・管理の効率化が進み、改善や新機能開発といった「攻め」のための時間が増えたことだという。
「作業を整理して見える化し、重複しているものを探って改善する泥臭い仕事もやりました。その結果、倍の処理能力・規模となり、右肩上がりに管理すべきサーバは増えましたが、インフラ担当者の人数は前期から50名ほど減り、過去5年で最少の人数で回せるようになっています。それ以上に、仕事の質が変わってきたことにこそ意味があると考えています」（河村氏）
