昨今注目されている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の定義を行わなければうまくいかないというのだ。その理由は「組織が持っているキャパシティやケイパビリティなどが異なるため」（手塚氏）だ。
