SREという“コト売りを支える仕組み”を、どう実現するか：特集：「DevSecOps」実現を支えるSRE（1）
モノ売りからコト売りの時代に変容し、ITサービスが重要な顧客接点となった近年、SRE（Site Reliability Engineer）を取り入れる企業が国内でも急速に増えつつある。ITサービスをビジネスとして成立させ、収益・ブランド向上に生かしていく上で欠かせない役割ではあるが、その実践は実に難しい。本特集では事例を通じてSRE実装の在り方を考える。
“サービス売り”を支えるSREという役割
Web、モバイルが社会に深く浸透し、ITサービスが自社の収益・ブランドを左右する重要なビジネスコミュニケーション手段となって久しい。今や一部のWebサービス系企業に限らず、製造、流通、小売りなど、顧客が存在するおよそ全ての企業がITサービスを提供している。
特に近年は開発を内製化し、アジャイル／DevOpsのアプローチでスピーディーにITサービスを届けることはもちろん、リリース後の安定運用や信頼性も強く求められるようになった。今やITサービスはビジネスそのものであり、リアル店舗と同様に、その対応に問題があれば、即座に機会損失や信頼失墜につながる。それがスマートフォンアプリなら、機能や使い勝手に少しでもストレスを感じたり、ほんの数秒待たされたりしただけで即座に削除されてしまうことも多い。優れたITサービスをいかにスピーディーに企画、開発、リリースできても、安定的かつ安全に提供・改善できなければ、そもそもビジネスとして成立し得ないのだ。
こうした中、Googleが提唱し、Netflixなど海外企業が続々と取り入れたSRE（Site Reliability Engineer）という役割が、2016年ごろから国内企業にも急速に広がりつつある。サイボウズ、メルカリなどをはじめWebサービス系企業が中心ではあるが、昨今は取り組み事例の発表機会も増え、認知度はかなり高まったといえるだろう。
無論、SREに関する情報源は増えたものの、実践のハードルが低くなったわけではない。「サイトの信頼性向上のために、自動化、障害対応、パフォーマンス管理、可用性担保などを通じて収益・ブランドを支える役割」といった概念こそ浸透したが、具体的にはどのような体制で、どのようなスキルを持って、何を行うのか、特に「“自社の場合”はどう適用すればよいのか」というところまでは腹落ちしていない例が多いのではないだろうか。
ただ、SREの基本的な概念や取り組み内容を俯瞰（ふかん）してみると、そのポイントが“ITサービスというビジネス”を運営するためだけではなく、「DX（デジタルトランスフォーメーション）」や「サブスクリプション」という概念が重視されるコト売りの時代を勝ち残る鉄則でもあることが、改めて明確に浮かび上がってくる。
全ては開発・運用チームのためではなく、ビジネスと顧客のため
まずSREの実践体制を振り返ると、従来のように開発チームと運用チームが明確に線引きされ、サービスを開発した後は運用チームに運用を丸投げするといったスタイルではなく、そもそも障害が起きにくい設計を考えるなど、開発チームが運用にも責任を持つことが前提となる。
運用チームもインフラだけではなく、アプリケーションのパフォーマンスまで監視し、必要に応じてコードの書き方の改善提案もするなど、コードを軸に開発者とコミュニケーションを取りつつ、共通のビジネスゴールを見据える体制が求められる。従来のように、言われたものを作る、マニュアル通りに運用するのではなく、開発と運用が共にビジネス目標やユーザーニーズを見据えて“プロダクトを作る”というスタンスだ。
その取り組みにおいて、重要なポイントとなるのがSLO（Service Level Objective：サービスレベル目標）だ。SLOは「レイテンシ」「スループット」「リクエスト率」「可用性」などのSLI（Service Level Indicator：サービスレベルインジケータ）を使って、ビジネス目標に基づく「明確な数値」として設定する。このSLOの重要な設定基準となるエラーバジェット（Error Budget：サービスを止めても良い時間）という考え方が、ITサービスの開発・運用がまさしくビジネス開発・運用と同義であることを改めて印象付ける。
例えばSLOとして「可用性」を99.95％に設定すると、年間 4.38 時間、月間21.9分停止することになる。つまり「このサービスにとって、この停止時間がどれほどのビジネスインパクトを持つのか」「ユーザーエクスペリエンスにどれほどの影響があるのか」を基にSLOを設定し、実際の運用がSLOを上回れば、「その時間をサービス改善やメンテナンスに充てる」といった判断を行う。
下回っても、ユーザーエクスペリエンスやビジネスへの影響が少なければ、「可用性の維持にリソースを投入するよりSLO自体を見直す」といった判断もできる。すなわち、「サービスをどれほどの時間止めてもいいか」という経営層やエンドユーザーにも伝わる「明確な数値」を基に、ITサービスという“ビジネスの経営判断”を適切かつ合理的に行う仕組みとなっているわけだ。
見落とせないのが、SREは「障害は必ず起こる」という前提に立っていることだろう。
サービスの安定運用だけを目指すなら、動いているサービスには極力手を加えない方がいい。だがニーズは刻々と変化し、追従できなければビジネスとして縮退してしまう。かと言って、イノベーティブな機能を追加するなど、リスクを取るが故にエラーバジェットを使いすぎてしまうようでは、そもそも信頼性を保つことができない。ITサービスはあくまでビジネスとエンドユーザーの満足のためのものであり、エンジニアの自己満足のためのものではない。エラーバジェットは“ビジネスとして正しいゴール”に向けて、開発・運用エンジニアを適切に導く基準となっているわけだ。
参考リンク：米Google SREディレクターに聞く、運用管理の意義、価値、役割（＠IT）
DevSecOpsという“コト売り時代の当たり前”を、どう実装するか
このようにSREの基本概念を振り返ると、開発・運用が誰のための取り組みなのか、改めて痛感させられる。と同時に、単にモノを作って届けるのではなく、「求められている価値を見極め、スピーディーに提供し、ユーザーニーズに継続的に応え続ける」――すなわちDXと呼ばれる経営環境を勝ち残る上での重要なポイントが、ノウハウとして体系化されていることがうかがえる。「Toil（スピーディーなビジネス展開を阻害する要因）を日常業務の50％以下に抑える」というSREの取り組み要素も、ビジネスにとって本質的ではない作業を自動化することで「価値の創出・提供に集中する」ためであるなど、開発・運用の全業務のベクトルが「ビジネス」に向けられているわけだ。
SREの概念もかなり浸透した今、このようにまとめてしまえば当たり前のようではある。だが、この当たり前のことを実践するのが非常に難しい。SREの概念は理解していても、人や予算が限定的で業務も多忙を極める中では、改善のための時間を取れず、Toilを8割以下に抑えることも難しい組織の方が圧倒的に多いはずだ。それ以前に自動化そのものに拒否反応を示す向きもあるなど、SRE実践には組織の体制、文化、制度というハードルも立ちはだかる。
とはいえ、SREによってビジネスを下支えしている企業が増えていることは事実であり、コト売りの時代になった以上、こうした取り組みがサービスを売る全業種にとって無視できないものになっていくことは間違いないだろう。企業ITがクラウドネイティブにシフトしていく中で、それをどう生かすかという意味でも、多くの企業にとって重要なテーマになっていくはずだ。
では具体的に、さまざまな制約がある中で、“自社の場合”はどんな組織体制で、どんなツールを使い、どんなメトリクスを、どう監視し、どうアクションにつなげていけばよいのだろうか？――。
本特集では、制約を乗り越えてSREを適用した3つの事例を紹介する。ご存じの通り、「求められている価値を見極め、スピーディーに提供し、ユーザーニーズに継続的に応え続ける」ための概念、DevOpsが国内で注目されて10年以上が経過し、5年ほど前からようやくその意義が認知され始めた。特にITサービスに高度な品質、安全性が当たり前のように求められている近年は、DevOpsのプロセスにセキュリティ対策を組み込むDevSecOpsも注目されている。だが、実践できている企業は限定的だ。
SREのノウハウは、このDevOps／DevSecOpsを実装するための方法論となるもの。3つの事例を基に、自社の場合はどう適用すればよいのか、ITがビジネスコアとなったコト売り時代を勝ち抜く道筋を、具体的にイメージしてみてはいかがだろうか。
特集：「DevSecOps」を支えるSRE
ユーザーに素早く価値を提供しつつセキュアなサービスを運用していく上では「DevSecOps」の考え方が欠かせない。そのような中でGoogleが実践、提唱している「Site Reliability Engineering」（SRE）という役割の導入が、Webテクノロジー企業の間で進んでいる。サービスの信頼性向上をミッションとして改善を行うSREにサービスのセキュリティ部分を担当させる動きもある。一方で、限られたリソースの中でSREを実践することは容易ではない。SREが成果を果たすためには、複数の目標／方針を定め、インシデント対応はもちろん、ロギング、サービス監視、インフラのコード化、運用自動化など並行して取り組んでいく必要があるためだ。日常業務に加えて、自動化に向けた取り組み、そして企業によってはセキュリティへの対応などすべきことは多い。SREを実践している企業は、SREの考え方をどうデザインして実践し、SRE実践に当たって抱えた課題にどう取り組んでいるのか。インタビューや事例を通じて俯瞰（ふかん）してみよう。
Copyright © ITmedia, Inc. All Rights Reserved.