昨今注目されているSREとはどんな職務を担うのか
SRE技術支援サービスをはじめ、セキュリティ脆弱性診断サービス、クラウド型ETL/パイプラインサービス、ハイスキルなフリーランスエンジニア紹介サービスなどさまざまな事業を展開しているスタートアップ、スリーシェイク。2018年10月にスリーシェイクに参画し、大手からベンチャーまで規模を問わず、さまざまな組織に対してSREのコンサルティングや実践を行っているのが、SREコンサルティング事業部部長の手塚氏だ。
「エンジニア必見！SREへの第一歩」というタイトルを掲げた今回のセッションでは、まずSREとは何かという概念を整理するところから始まった。
書籍『SRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチーム』（オライリー）、通称SRE本の序章で、著者の一人であるBetsy Beyerは「SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものです」と説明している。「書かれていることは簡単だが、理解するのは難しいので、紐解いていきたい」と手塚氏は話す。
一般的に運用（Ops）の現場では、煩雑で繰り返しの多い運用作業、日々追われる障害対応とメンバーへの超負荷、守りを重視するが故にリリーススピードが遅いなどの問題を抱えていることが多い。このように「Opsの現場は泥臭い要素が根強く残っている」と手塚氏は指摘する。そしてSREは、このように根強く残っている泥臭さを解決する一つのアプローチを担う役割や職務だと手塚氏は考えているという。
SRE本の第二章では「SREの原則」が語られている。そこで挙げられている項目は「リスクの受容」「SLO（Service Level Objective：サービスレベル目標）の定義」「分散システムモニタリング」「Toil（トイル）の削減」「自動化の推進」「適切なリリースエンジニアリング」の6点。「リスクの受容とSLOの定義では、100％の可用性を目指すことなく、しっかりリスクを受け入れながら、SLOとなる指標に向かってしっかりサービスレベルを高めていくことが非常に大事になるということが言われている」と手塚氏は説明する。
分散システムのモニタリングでは、長期的なトレンドの把握や適切なアラートによる問題解決の修復などを行うために、各種モニタリングやアラート設定を行っていくことが大事だと書かれている。トイルの削減や自動化の推進という項目では、サービスの成長に比例して拡大する永続的な価値を提供しない、ありふれた反復的な運用作業を自動化して削減していくことが語られている。適切なリリースエンジニアリングでは、多くの障害は人の手が加わることで発生するので、そのために適切な構成管理やリリースエンジニアリングの仕組みを構築する必要があるという。これらの原則を総括して、手塚氏は「SREとは、これらの原則を、ソフトウェアエンジニアリングを通じて実現させる運用を行う職務だと独自解釈している」と説明する。
では、スリーシェイクはどのようにSREを実践しているのか。「そのためのロードマップを用意している」と手塚氏は続ける。ファーストステップはSREチームの定義をすること。「これが非常に大事になる」と手塚氏。SREはシステマティックなものではなく、もっとウェットで粘着質なモノだからだ。手塚氏は組織組成や改革するときに起こりがちの失敗パターンについて説明を始めた。失敗パターンとは、組織の役割が曖昧で、メンバーに目的が浸透していない、活動が他のチームや上層部から理解を得られない、現実と折り合いを付けずに、到達困難な高すぎる目標を立ててしまう、新しい活動に割けるリソースがなく、コミット量が少ないなどである。
SREチームに限らず、あらゆる組織を立ち上げるときはさまざまな苦労や困難な壁にぶつかるものだ。「重要なのは組織組成や改革は当事者や周りが冷めてしまったら終わりだということ。そのために生まれたての組織はなおさら慎重に活用していく必要がある」と手塚氏は強調する。
SREを実践するためには文化的な側面も大きいという。例えば、Googleが公開している『class SRE implements DevOps』では、DevOpsという思想や方針に対する実装者としてのSREが語られているが、そもそも以下の表で語られているような手法を受け入れるだけの組織的土壌があるのか、なければ作れるのか、他チームから理解を得て協働が可能かどうかを確認することが必要だ。
class SRE imperilments DevOps
SREはDevOpsの実装者としての役割も持つため、当然、開発や運用と密に関わる。そのほかにもSLOやSLAの定義をするためには、ビジネスサイドとも密接に関わる。「SREは単一組織として自分たちのタスクに終始すれば良いものではない。さまざまな組織や役割と密接に連携し合いながら、実践していく必要がある」と手塚氏は語る。
だが、その際に気を付けなければならないことがある。それはSREチームがやること、頼まれることが多くなり、本来の仕事ができなくなりがちということだ。例えばSLI（Service Level Indicator：サービスレベル指標）やSLOの定義、障害対応、自動化の推進、振り返りの文化の浸透、CI/CDの整備、監視環境の整備、インフラの環境構築、アーキテクトレビューなどがすべてSREに任されてしまうことがあるという。だからこそ、先のような文化を受け入れるような土壌が重要になると手塚氏は言うのである。
SREは他チームとの協働が重要なカギを握る。つまりSREはSREチームだけで成立するものではないということ。そこで大事になるのが、SREの役割を明確にして、理解を得ることだ。もう一つ大事なことは、「GoogleのSREの形にとらわれすぎないこと」と手塚氏は言う。今の組織やシステム構成に合わせた形で、SREの定義を行わなければうまくいかないというのだ。その理由は「組織が持っているキャパシティやケイパビリティなどが異なるため」（手塚氏）だ。
SREチームの定義から始まる、SREロードマップ
Sreke流SREロードマップ
ファーストステップでSREチームの定義ができれば、SREの開始となる。その際のコツは、「まずは小さく、効果が最大限に出るところからコツコツと始めること」と手塚氏。その例として監視基盤の導入やSLI/SLOの定義、運用体制整備、IaC（Infrastructure as Code）、CI/CD導入、パフォーマンス分析などを挙げる。もちろん、これらを複数のサービスにまたがって、一気にすべて実践するわけではない。「とにかく一つのサービスを対象に初めて、成功体験を得て、徐々に広げていくことがポイントです」（手塚氏）
対象サービスもできれば、新規のサービスが望ましいという。なぜ、既存サービスでは難しいのか。その理由について手塚氏は、新しくSLI/SLO設定する元となる情報を取得するための基盤導入が難しいこと、既存の運用があるため、新しい活動への導入が難しいケースがあること、そもそも手を加える前提で作られていないことを挙げる。
実践する上でもう一つ大事なことがある。それは「データドリブンな世界にすること」と手塚氏。データがない状態ではSLI/SLOの設定はそもそも不可能であるように、SREを始めるに当たっては元となるあらゆるデータが揃っていることが前提になるからだ。「監視基盤の見直しなどを通じて、とにかくデータを収集し、具現化できるところまで持って行くことで、初めてSREを始めることができます」（手塚氏）
サードステップはSREの実践。SLI/SLOを設定し、トイルの削減を行う。SLIは何を基にシステムの善し悪しを判断するかの指標で、これを使ってサービスレベルに対する内的な目標値であるSLOを定義するのだが、「上質なSLOを設定するためにも、まずはあらゆる指標となりうるメトリクスを収集し、可視化できるようにすること」と手塚氏は指摘する。
SLOの設定については、クリティカルユーザージャーニー（CUJ）を検討していくことから始まる。「ただ最初のSLO設定は“エイヤー”で決めてしまうのも一つの手」と手塚氏。ただしSLO100％はアンチパターンとなるので、そういう設計はしないことだという。それより大事になるのが、Biz/Devを置き去りにせず、共通認識を意識しながら設定していくことだという。「定期的に振り返りながら、組織一丸となって、一緒に高品質なプロダクトを目指していくことが重要です」（手塚氏）
振り返りの文化を定着させるために必要となるのが、ポストモーテムの実施だ。ポストモーテムとは、インシデントとその影響、インシデントを軽減または解決するために採ったアクション、根本原因、およびインシデントの再発を防止するためのフォローアップアクションを書面で記録すること。「ポストモーテムを行うことで、振り返りから学ぶ文化を作ることができる」（手塚氏）
ポストモーテムを実施するためには、障害を追跡できるようにしておくことが必須となる。加えて実施の際には、「特定個人を非難しない文化を作ること」が大切になるという。
スリーシェイクではPagerDutyとの組み合わせで、SREを加速させているという。オンコール機能や、実践的なアラーティング、インシデント管理、障害発生時の対応の追跡など、ポストモーテムが容易に実現できるからだ。「Slackなどのチャット通知も簡単に行え、通知の中身によって通知パターンを実装できるので、ノイズのない通知が行える」と手塚氏。またJiraなどのチケット管理ツールとインシデントの連携が可能なので、スクラムとの連携もしやすい。そのため「トイルの測定やエラー予算の管理にも役立つ」と手塚氏は言う。
一方のトイルの削減について。トイルとは「手作業」「繰り返される」「自動化が可能」「戦術的・長期的な価値がない」「サービスの成長に比例して増加する」という特徴を持つ作業のことだ。これを削減するには、Devチームからの依頼対応、障害対応、割り込みタスク、SREとしての定型業務、定期的に発生するメンテナンス作業など、どういう作業がどの程度の頻度発生し、どれだけの工数をかけてどんな効果が得られたのかを測定し、取得することが第一歩となる。これらを測定した後、振り返り、自動化のサイクルを回していくことで「トイルが削減される」と手塚氏は言う。
最終ステップはSREの発展と継続である。SREの文化を浸透させるためには、一つの成功体験が得られたら、他のサービスに展開していくことはもちろん、何より定期的な振り返りを通じてさらなる改善を行うことが大事になるという。またエラーバジェットを基にした業務のコントロールについてもSRE本の中では語られているが、「これはかなり難易度が高いと思う」と手塚氏。大前提として十分な体制やSLI/SLOの定義が必要になることに加え、サービスのビジネス的な意味合いによるところもあるからだ。
「GoogleのSREは素晴らしい見本だが、自分たちの組織やメンバー構成を考えながら最適なSREを実践すること。その際は手を付けやすいところから小さく始めることをお勧めします」（手塚氏）
SRE総合支援サービス「Sreake」
Sreake（スリーク）は、金融・医療・動画配信・AI・ゲームなど、技術力が求められる領域で豊富な経験を持つSREの専門家が集まったチームです。戦略策定から設計・構築・運用、SaaS提供まで、幅広い領域をサポートします。
