Boost」など、さまざまなカンファレンスを企画・運営しています。BOOKS(コードジン・ブックス)は、CodeZineの連載からカットアップした、開発現場の課題解決に役立つ書籍シリーズです。Engineering)」。実践しようとしても、なかなか難しい。それはSREがリスクの受容やSLOの定義、分散システムモニタリング、Toilの削減、自動化の推進、適切なリリースエンジニアリングというような、運用保守が求める理想的な原則をソフトウェアエンジニアリングというアプローチを通じて実現させていくことを担っているからだ。やって実践していけば成功するのか。そのコツについて、スリーシェイクでSREのコンサルティング、および導入、定着化支援を行っている手塚卓也氏が明かした。されているSREとはどんな職務を担うのかSRE技術支援サービスをはじめ、セキュリティ脆弱性診断サービス、クラウド型ETL/パイプラインサービス、ハイスキルなフリーランスエンジニア紹介サービスなどさまざまな事業を展開しているスタートアップ、スリーシェイク。2018年10月にスリーシェイクに参画し、大手からベンチャーまで規模を問わず、さまざまな組織に対してSREのコンサルティングや実践を行っているのが、SREコンサルティング事業部部長の手塚氏だ。「エンジニア必見!SREへの第一歩」というタイトルを掲げた今回のセッションでは、まずSREとは何かという概念を整理するところから始まった。Beyerは「SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものです」と説明している。「書かれていることは簡単だが、理解するのは難しいので、紐解いていきたい」と手塚氏は話す。一般的に運用(Ops)の現場では、煩雑で繰り返しの多い運用作業、日々追われる障害対応とメンバーへの超負荷、守りを重視するが故にリリーススピードが遅いなどの問題を抱えていることが多い。このように「Opsの現場は泥臭い要素が根強く残っている」と手塚氏は指摘する。SREは、このように根強く残っている泥臭さを解決する一つのアプローチを担う役割や職務だと手塚氏は考えているという。SRE本の第二章では「SREの原則」が語られている。Objective:サービスレベル目標)の定義」「分散システムモニタリング」「Toil(トイル)の削減」「自動化の推進」「適切なリリースエンジニアリング」の6点。「リスクの受容とSLOの定義では、100%の可用性を目指すことなく、しっかりリスクを受け入れながら、SLOとなる指標に向かってしっかりサービスレベルを高めていくことが非常に大事になるということが言われている」と手塚氏は説明する。分散システムのモニタリングでは、長期的なトレンドの把握や適切なアラートによる問題解決の修復などを行うために、各種モニタリングやアラート設定を行っていくことが大事だと書かれている。トイルの削減や自動化の推進という項目では、サービスの成長に比例して拡大する永続的な価値を提供しない、ありふれた反復的な運用作業を自動化して削減していくことが語られている。適切なリリースエンジニアリングでは、多くの障害は人の手が加わることで発生するので、そのために適切な構成管理やリリースエンジニアリングの仕組みを構築する必要があるという。これらの原則を総括して、手塚氏は「SREとは、これらの原則を、ソフトウェアエンジニアリングを通じて実現させる運用を行う職務だと独自解釈している」と説明する。スリーシェイクはどのようにSREを実践しているのか。「そのためのロードマップを用意している」と手塚氏は続ける。ファーストステップはSREチームの定義をすること。「これが非常に大事になる」と手塚氏。SREはシステマティックなものではなく、もっとウェットで粘着質なモノだからだ。手塚氏は組織組成や改革するときに起こりがちの失敗パターンについて説明を始めた。失敗パターンとは、組織の役割が曖昧で、メンバーに目的が浸透していない、活動が他のチームや上層部から理解を得られない、現実と折り合いを付けずに、到達困難な高すぎる目標を立ててしまう、新しい活動に割けるリソースがなく、コミット量が少ないなどである。SREチームに限らず、あらゆる組織を立ち上げるときはさまざまな苦労や困難な壁にぶつかるものだ。「重要なのは組織組成や改革は当事者や周りが冷めてしまったら終わりだということ。そのために生まれたての組織はなおさら慎重に活用していく必要がある」と手塚氏は強調する。SREを実践するためには文化的な側面も大きいという。DevOps』では、DevOpsという思想や方針に対する実装者としてのSREが語られているが、そもそも以下の表で語られているような手法を受け入れるだけの組織的土壌があるのか、なければ作れるのか、他チームから理解を得て協働が可能かどうかを確認することが必要だ。DevOpsSREはDevOpsの実装者としての役割も持つため、当然、開発や運用と密に関わる。そのほかにもSLOやSLAの定義をするためには、ビジネスサイドとも密接に関わる。「SREは単一組織として自分たちのタスクに終始すれば良いものではない。さまざまな組織や役割と密接に連携し合いながら、実践していく必要がある」と手塚氏は語る。その際に気を付けなければならないことがある。それはSREチームがやること、頼まれることが多くなり、本来の仕事ができなくなりがちということだ。推進、振り返りの文化の浸透、CI/CDの整備、監視環境の整備、インフラの環境構築、アーキテクトレビューなどがすべてSREに任されてしまうことがあるという。先のような文化を受け入れるような土壌が重要になると手塚氏は言うのである。SREは他チームとの協働が重要なカギを握る。SREはSREチームだけで成立するものではないということ。そこで大事になるのが、SREの役割を明確にして、理解を得ることだ。一つ大事なことは、「GoogleのSREの形にとらわれすぎないこと」と手塚氏は言う。今の組織やシステム構成に合わせた形で、SREの定義を行わなければうまくいかないというのだ。その理由は「組織が持っているキャパシティやケイパビリティなどが異なるため」(手塚氏)だ。大手化学メーカー、日経BP社、ITに特化したコンテンツサービス&プロモーション会社を経て、2002年、フリーランス編集&ライターとして独立。現在はIT、キャリアというテーマを中心に活動中。趣味は読書、ドライブ、城探訪(日本の城)。NEW1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。NEW1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。NEW1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。12:00法務担当者、6割超が今後業務で「生成AIを使用したい」と回答。NEW新着記事一覧を見るイベント今後の予定を見るCodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。イラストの無断転載を禁じます。記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。