アーカイブ動画

SREsのためのSRE定着ガイド──X-Tech5

株式会社X-Tech5
取締役CTO　馬場 俊彰氏

最初に登壇したのは、X-Tech5の馬場俊彰氏だ。システムの運用フェーズに携わること、特にモニタリング、オブザーバビリティ、パフォーマンスチューニングが大好きだというCTO馬場氏。iCARE社の技術顧問も務め、専門領域に関する著書を多数上梓している。

馬場氏はまず「SRE（Site Reliability Engineering）とは何か」を関連本を紹介しながら、こう述べた。

「SREはDevOpsの一つの実現形態であり、インフラにフォーカスされがちですが、同領域だけの取り組みではありません」（馬場氏）

さらに、日本ではインフラエンジニアやSREエンジニアといった専門人材が担うような風潮が見られるが、それは望ましくないと指摘。「オフィスの掃除と同じで、皆で取り組むことが大事です」と、続けた。

馬場氏は、SREに関するおすすめ書籍も紹介。「ベストプラクティスは一つではない。むしろ、既定から外れることこそSREの王道であり、原則だけは一致する必要がありますが、現場が先でプラクティスは後です」と、語った。

続いて、SREを実践する際に聞くことが多いという悩みを紹介。馬場氏はそれらに理解を示しながらも、「SREとは関係のない悩みであり、仕事上でよくある悩みである」と指摘。「SREとして捉えて改善しようとしても、うまくいかないのではないか」と、見解を述べた。

馬場氏は、実際にSREの推進で取り組みや効果のあった施策を3つ紹介した。「定点観測会」「モブプロ・モブオペ」「外部リソース注入」である。それぞれの取り組みの狙いも合わせて解説した。

改善サイクルを回すことが基礎であり、OODAループがおすすめだと、馬場氏は述べる。言外（直接言葉に出していない部分）の前提条件を共有し、浸透させて実現させる。さらには知識と価値の認識も同じく共有し、浸透させて実現し続けていくという。

「前提条件の擦り合わせの場をたくさん持つこと。そのような場では特定のメンバーだけが主張するのではなく、皆ですり合わせること。時系列での変化も共有することが大事です」（馬場氏）

コミュニケーションにおいては、「質は後から、まずは量が大事であり、定期的にコミュニケーションが行われる場の確保が重要」と語り、それぞれの取り組みについても紹介した。

最初に紹介したのは、馬場氏のお気に入りであり、SRE成功の鍵でもあるという「定点観測会」である。参加者に価値を提供すること、穏やかな学びの場にすることが大事だという。

逆に、網羅的にメトリクスやタスクの確認をするといった“こなす”場にはしないこと、SLO（Service Level Objective）で一喜一憂しないことも重要だと強調し、次のように狙いと成果を改めて述べた。

「コミュニケーションの量を増やし、OODAループを回していくことで、メンバーの技術力やその他判断などのレベルが上がっていくと考えています」（馬場氏）

続いて紹介したのは、「モブプロ・モブオペ」だ。取り組み方は一般的なペアプロなどと同様で、特別なツールを用意することなく、通常使っているZoomなどで十分だと馬場氏は言う。こちらもポイントはすべてを網羅的に行わないことであり、レビューもしないという。

また、「定期的に時間を設けて継続することが大切です。その結果、次第にレベルの高い人の情報共有ノウハウをメンバーが得るようになっていくでしょう」と、馬場氏はチームビルディングにも効果があると語った。

外部リソースの注入においては、「自分たちで取り組む方がよい」と前置きしながらも、自社のリソースだけで実現や継続が難しい場合は、X-Tech5が提供しているような外部のSREサービスを頼るのも一つの手だと語った。

馬場氏はSREは全員が取り組むべきテーマである一方で、SREエンジニアが不要になるとは思わないと、サッカーを例に挙げて紹介。次のように述べ、セッションをまとめた。

「原則だけはGoogle社が提唱した内容と一致させますが、完全に一致する必要はありません。正しい方法は、それぞれが成功した方法だからです。できないことより、できること。次できることに目を向けてほしいと思います」（馬場氏）

失敗・成功から醸成されたSREチームの思考フレームワーク──SHIFT

株式会社SHIFT
サービス&テクノロジー本部
ITソリューション部インフラサービス2グループ　島田 直樹氏

続いて登壇したのは、SHIFTの島田直樹氏だ。SIerでさまざまな業界のインフラシステムなどの構築プロジェクトに携わった後、Webサービスのインフラエンジニアとしてアプリケーション領域で、SRE活動に従事してきた。2023年2月、SHIFTに入社。現在はSREを切り口としたさまざまな活動に取り組んでいる。

SHIFTでは、SRE推進を目指す企業のさまざまなサポートを提供している。SRE活動の定着を実現させたいが自社だけでは難しい企業、ツールを導入して自動化を実践し、オブザーバビリティに取り組んでいるが、成果が出ていない企業などに対し、アセスメントから導入・最適化・コーチングなどを行っている。

島田氏は、まずSREの一般的な定義を説明した。その上で、サービス品質と信頼性を高めるためには、さまざまな活動を実践する必要があることを述べ、SREが求められる時代背景について、SHIFTとしての考えを示した。

品質とスピードは、開発・運用どちらのフェーズにおいても求められている。一方、両者はトレードオフの関係にあること、SREの定義は企業や人により異なることなどから、SREの導入や実践は難しい面もある。

そこでSHIFTでは、まずモニタリングをしっかりと行い、そこから改善を通じてSRE活動につなげていく。島田氏は具体的なフローチャートも紹介した。

島田氏は、実際にSREサービスを提供した事例の紹介も行った。一つ目は、失敗事例である。ストリーミングを配信するWebサービスを提供している企業から、SREに取り組みたいとの打診があり、ヒアリングを行った。その結果、経営層は人的リソースの最適な配置を懸念しており、IT部門は今後ますます増えるであろうユーザー数について心配していることが分かった。

そこで島田氏は、クラウドモニタリングツールの導入を提案した。しかし、先方の反応は芳しくなかった。IT部門が構築した現システムでも現状は問題がなく、SREとの言葉はあくまでキーワードとして使っただけであり、SREを実践することが主目的ではなかったからだ。島田氏は次のように振り返った。

「コミュニケーション量が完全に足りていなかったこと、信頼関係も築けていなかったことが、失敗の要因だったと思っています。まずは、お客様にとってSREとは何なのかを一緒に定義し、お客様の歴史や文化に寄り添うアプローチが必要でした」（島田氏）

続いては、ECサイトのWebサービスを提供している企業の事例を紹介。同企業では、2年ほど前からクラウドモニタリングツールを導入し、オブザーバビリティなどに取り組んでいたが、思ったような効果が出ていなかった。 そこで、SHIFTに相談したのである。

島田氏は先の失敗を踏まえ、しっかりと顧客とコミュニケーションを取り、顧客が考えるSREとは何なのか、ツール導入の期待値なども把握するように心がけた。具体的に5つの課題・対策・効果を整理し、明文化した。

このように対策を進めていこうと打診するが、「忙しすぎてできない」という答えが返ってきてしまう。そこで島田氏は、指標に優先順位をつけることを提案した。その際に活用したのが、重要度と緊急度を示したマトリクスである。

上記の取り組みを以下スライドのようにマトリクスに重ね、結果として「1・3・5」の取り組みを実施することとした。

まずは「No.1」の取り組みである。改めて確認すると、アラートの7割以上が不要であることが分かった。そこで、不要なアラートは通知しないこととした。

具体的には、以下スライド赤枠の「アプリ―ケーション監視は通知させない」のみを通知することとした。

運用中に感じた不要アラートを報告・削除するためのフローも整備した。GitLabでブランチを切り、マージリクエストを行い、レビュー、デプロイという流れで行う。また、監視要件をモニタリングする会を週次で実施し、不要なアラートを先のフローを活用して削除していった。

このような取り組みを行った結果、作業時間が確保できるように改善された。さらにはチーム内外のコミュニケーションが活発になったことで、運用から開発に対してアーキテクチャの設計について意見が挙がるなど、「建設的な会話が生まれるようにもなった」と島田氏は成果を述べる。そして、SREの役割について次のような見解を述べた。

「オンプレからクラウドに変わったことで、アプリケーションの作り方も構造も変わってきました。そこでは開発・運用、インフラ・アプリの両方が改めて歩み寄り、いろいろと議論することが大切です。つまりSREは単なるインフラ監視ではなく、サービスを一緒に考えていく。そのようなスタンスで取り組むことが重要だと考えています」（島田氏）

続いては、CI/CDの環境を実践するものの、エラー発生時の対応を整備していなかった「No.3」の課題である。

エラー原因を考えると、デプロイ先の環境、デプロイ対象のバージョンなど、簡単に判断できるものではないことが分かった。

そこで、暫定・恒久と対策を二分化。ここでも先のマトリクスを活用し、手動デプロイできるようにするという取り組みを行うこととした。

その結果、問題は解決した。だが、なぜエラーが生じるのか、いわゆるブラックボックスに手を加える取り組みについては、今後の課題となった。

「No.5」については、一人当たりの負荷が増えて、何もできない状態の解決に向けた取り組みだ。同課題に関しては現状の対応策がないため、暫定的にあきらめることとなるが、「まずはできることからやることが重要」だと、島田氏は語る。

最後に、島田氏は「SREはアクセサリーだと思っている」という私見を述べた。それぞれの領域の専門エンジニアが他の領域を経験し、実践に取り組むことがSREの本質だからである。そして次のようにメッセージを述べ、セッションを締めた。

「『能力と善意を前提する』。私の大好きなGoogleのコードレビューのルールです。仲間が間違いをしたとしても、それは能力がないからではなく、情報が不足していることが原因である。つまり、情報の共有は大事だということです。私もこのようなスタンスで仕事をしたいし、私に対するアクションも同じであると嬉しく思います」（島田氏）

SREの適切な体制・スピーディーなサービス運用を実現──NTTデータグループ

株式会社NTTデータグループ
技術革新統括本部　システム技術本部
クラウド技術部　クラウド担当
技術オファリンググループ　課長代理　工藤 佑介氏

最後に登壇したのは、NTTデータグループの工藤佑介氏だ。新卒でNTTデータに入社した工藤氏は、インフラからスマホアプリまで、さまざまなシステムやサービスの性能問題改善や開発業務に従事している。

工藤氏は、2020年に金融案件でSREチームの立ち上げから参画したことをきっかけに、SREについて実践も含め、深く取り組むようになっていった。現在は複数業界のプロジェクトにおいて、SRE やGoogle Cloudを中心としたアーキテクチャ設計に従事している。

昨今、アジャイル開発やCI/CDの普及により、頻繁なサービスデプロイが可能になり、開発と運用でのインフラも含めたサポートを頻繁に実施する必要が生じている。工藤氏は、SREの必要性についてこのように述べた。

「NTTデータの案件でもCI/CDが増えてきています。SREという言葉を聞く機会も増え、実践するケースも増えてきました」（工藤氏）

一方で、実践の壁としては、「どのような体制でSREを導入するのか、SREチームとサービスチームの関係性を考慮する必要がある」と、工藤氏は語る。

そして、「SREエンゲージメントモデル」と謳った、いくつかの体制モデルを紹介した。

これは工藤氏が実際に取り組んだモデルであり、上記3つは既存の体制から取り組みやすい。一方、下記3つはSREとしてさらに価値を高めるために、プラスアルファ的に取り組むためのモデルだと説明した。

「どのエンゲージメントモデルを使えばよいかは規模やプロジェクトにより異なるので、万能なモデルはありません」（工藤氏）

工藤氏は、実際の導入事例も紹介した。アジャイル開発により、頻繁にサービスをデリバリーすることで、ビジネスの高速化を狙った金融エンタープライズ案件である。共通基盤であるデジタルプラットフォームを構築し、その上に各サービスが乗るマルチテナント方式を採用した。

そして開発だけでなく、頻繁なデプロイとサービスの高速化の両立を目指し、SREチームもデジタルプラットフォームにつながる体制で設立された。

工藤氏は、SREチームも含めたプロジェクト全体のチーム体制の変遷についても紹介した。まず初期のサービスが一つだったときは、特にSREチームを意識することなく、インフラ（プラットフォーム）チームとアプリチームのような関係性で進んでいった。

その後サービスが増えていくにつれ、スライドの中央のようにそれぞれのサービスにSRE担当が加わっていった。先のモデルで示すところのエンベデッド型である。

さらにサービスが増えると、いわゆるCoE的なSREチームが求められるようになり、チームを発足。結果として、各サービスに入り込むSREエンジニアの外交官チームとの2チーム体制となった。

初期はもちろん、その後SREチームを新たに構築していく際などには、アジャイル開発でいうところのインセプションデッキに該当する「SRE憲章」を定めることで、チーム内の認識合わせや齟齬を防ぐ取り組みを行っていった。

憲章の内容は、ミッションやクライテリア、フェーズごとにおけるSREの関わり方などである。工藤氏は、作成の意図と成果を次のように述べた。

「憲章を作成しておくことで、メンバーが新しく入ってきたときや入れ替わった際に、すぐに理解できる指標として機能すると考えています」（工藤氏）

さらに同プロジェクトでは、コンサルティングSREモデルも導入した。その理由や主な目的は信頼性向上だが、新しい技術を導入することで、エンジニアのワクワク感を醸成する取り組みでもある。同モデルを導入することでさらなる付加価値も期待しているという。

工藤氏は、同プロジェクトにおける学びを次のように述べた。

「プラットフォーム、エンベデッド、コンサルティングと、結果として3つのモデルを導入しています。その時々の課題や時間的な変化でベストなモデルを選ぶことで、チームとして一番よい体制にしていく。それが実践で得たウハウでもあります」（工藤氏）

工藤氏はSREチームの実運用例も示した。まずは、Kubernetesや Terraformなどに加え、セキュリティにおけるCI/CDを実現するPrisma Cloudを活用したシステムである。

Prisma Cloudの導入により、権限が強過ぎた際などにアラートがPagerDutyに伝えられ、そこからさらにSREや開発チームにも連絡がいくという流れとなっている。工藤氏は以下のように成果を語った。

「金融案件だったため高いセキュリティが求められましたが、一方で体制は比較的軽量で実現できた事例になります」（工藤氏）

続いて紹介されたのは、SREチームとサービスチームが合同で最大8チーム100名ものメンバーが、クラウド上で発生した大規模障害に対応する訓練事例である。

座学だけでは得られないこともある。実際に障害が発生した際に動けるかどうか、特定のメンバーだけでなく経験が浅いメンバーも含め、属人的ではない対応ができるかどうかだ。

このような対応や確認を目的とした訓練であり、回数を重ねていくことでRunbookやPlaybookの不足などに気づくことができた。また、実際にドキュメントを充実させることなどで、耐障害性の高い組織を作り上げることができたと手応えを述べた。

昨今は、リモートで本番運用ならびに障害発生対応を求めるニーズが非常に高いと工藤氏。続いての事例は、同ニーズを実現したものである。

実際、現場にかけつけることなくリモートで障害対応した結果、復旧までの時間が1～2時間ほど削減するという成果を得た。工藤氏は、トイル削減の事例も紹介した。

「最初に大きな仕組みを作り、同じような手法を派生していくことで自動化が進み、トイルが減っていく。このような流れがポイントです。例えば監査ではある程度まで自動化を行い、人が確認するのは最後だけにするなどです」（工藤氏）

NTTデータでは、クラウド運用における各種業務プロセスにおける、ベストプラクティスを体系化したxOpsを掲げている。その中心に位置するのがSREである。

工藤氏は最後にSREの重要性と、NTTデータの強みである「伴走型SRE」と「Ops」を掛け合わせた強みを改めて語り、セッションをまとめた。

【Q＆A】参加者からの質問に登壇者が回答

セッション後は、イベント参加者からの質問に登壇者が回答した。抜粋して紹介する。

Q．定点観測会を行う際の準備は、具体的にどのようなことを行うのか

馬場：話題を振ることができるような準備をしています。具体的には、オブザーバビリティツールやイベントカレンダーを下調べしておいたり、レイテンシの変動、エラーのタイミングなどを、レポートとしてまとめておいたりしています。

このような準備をすることで、例えばエラー発生時にユーザーや事業側はどのようなことが起こっていたのか、議論が活発になることが多いからです。

その他、クラウド費用などコストの状況変化なども取り上げることがあります。網羅的に行うのではなく、実践的なものに注力して準備することが大切だと考えています。

Q．既存プロジェクトにSREを導入する際に、反対されたときの対応ノウハウは？

島田：難しく考えずに、信頼関係を築くことが大事だと思います。何でも屋になってもいいと僕は思っています。そうした上で、イニシアチブを取っていく。まずは相手が何を求めているのかを聞いていくことが大切だと思います。

Q．何でも屋にならないためには？

工藤：最初はどうしても何でも受けてしまいがちになります。しかし、徐々にサービスチーム側が自分たちでやるべき必要があることや、その範囲をしっかりと決めて、気づいてもらうようにすることが大事だと思います。

Q．コミュニケーションにおけるポイントは？

島田：最初のアクションを間違えると取り返しがつかないので、まずは相手の話をよく聞くように心がけています。その上で、相手の頭の中にはどういった辞書が書かれているのか、そこを整理してからリアクションするようにしています。

馬場：感謝すること、褒めることを心がけています。私がそのようにされて嬉しかったことでもありますし、HRMを研究している方に相談して教わったことでもあります。

Q．モブプロやモブオペを実施する際に気をつけることは？

馬場：私が心がけていることですが、どこに着目してそのような判断になったのか。また、そのような判断をなぜしたのか、ロジックを聞くようにしています。聞き方についても高圧的にならないよう意識しています。

Q．自動化のポイントや要因は？

工藤：トイルの割合が高いもの、1カ月など単位時間あたりの回数は頻度が大きいものなど、優先度をつけて徐々に進めていくのがよいと思います。私自身もそのように取り組んできました。

株式会社SHIFT
https://www.shiftinc.jp/

株式会社SHIFTの採用情報
https://recruit.shiftinc.jp/