SREという“コト売りを支える仕組み”を、どう実現するか：特集：「DevSecOps」実現を支えるSRE（1）

モノ売りからコト売りの時代に変容し、ITサービスが重要な顧客接点となった近年、SRE（Site Reliability Engineer）を取り入れる企業が国内でも急速に増えつつある。ITサービスをビジネスとして成立させ、収益・ブランド向上に生かしていく上で欠かせない役割ではあるが、その実践は実に難しい。本特集では事例を通じてSRE実装の在り方を考える。

[編集部,＠IT]

“サービス売り”を支える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は「障害は必ず起こる」という前提に立っていることだろう。