SREを自社に導入するためのプラクティス

今回は「SREを自社に導入するためのプラクティス」についてご紹介します。

関連ワード （ようこそSREの世界、特集・解説等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、ZDNet Japan様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

　前回の記事では、Site Reliability Engineering（SRE）がシステム運用にもたらす利益についてご紹介しました。結論としては、「システムの信頼性の担保」と「開発効率の向上」という対極にある2つの要素を成立させるというものでした。

　第2回となる本記事では、企業ごとに組織の体制や文化が異なる中で、どのような目的・意図を持って進めていけば、この対極にある要素を両立させたSREの導入につなげられるかのプラクティスについてご紹介します。

　前述の通りSREの目的は、「システムの信頼性の担保」と「開発効率の向上」という2つの要素を両立させることです。

　アプローチ方法としては、ソフトウェア技術によって実装されることもあれば、対話や文化の醸成などコミュニケーションに重きを置いて行うこともあります。この2つの目的は抽象度が高いため、何をすべきか細分化していくと、たくさんのやるべき事が出てくるはずです。

　SREを完全導入するには、数カ月、数年と、ある程度の時間を要します。まずはSREのプラクティスを幾つか導入し成果を少しずつ得て、組織にSREの文化を醸成していくことが重要です。

　SREで「システムの信頼性の担保」と「開発効率の向上」を両立させるために、まず取り組むべきことをご紹介します。

　システムの信頼性を担保するには、その指標としてサービスレベル目標／サービスレベル指標（SLO/SLI※1）という定量的なデータを用います。そのため、どこから・どのような指標を集めるかというモニタリングの設計と実装・信頼性の定義は、優先度が高くなります。信頼性の定義に関しては、Googleのゴールデンシグナル※2を利用すると良いでしょう。

　開発効率の向上では、継続的なインテグレーション／継続的なデリバリー（CI/CD）の優先度が高くなります。機能・品質のテスト、デプロイなどの一連の流れを自動化することにより、開発者は機能開発に集中でき、プロダクトとしては細かいリリースが可能になります。安全なリリースを行うために、CDでリリース戦略などの信頼性が介入する事もあります。

　この他にも、既存システムの見直し、パフォーマンス分析、インフラストラクチャー・アズ・コード（IaC）、運用体制の整備、文化の醸成など、取り組むべきことがさまざまにあります。そのため、SREを長期的に実践するには、今の組織にSREのどのプラクティスが効果的に働くかという観点でロードマップを作成し、チーム全体で進めていくことが重要です。

※1：「SRE サイトリライアビリティエンジニアリング」（オライリー）の「4章 サービスレベル目標」（原書）
※2：「SRE サイトリライアビリティエンジニアリング」（オライリー）の「6章 分散システムの監視」（原書）

　SREに対して開発チームが過度に期待し、運用に際限なく障害対応を任せてしまうような状況は、避けなければなりません。開発チームが運用に無関心かつ非協力的だと、運用はSREのために障害対応により多くの時間を費やすことになり、本来行うべき業務に支障が出てしまいます。これを避けるためには、開発チームの理解やプロダクション運用への参加意識が不可欠です。

　開発チームとの協働には、SREの運用業務の一部を開発チームに担当してもらうことが効果的です。具体的には開発エンジニアをオンコールシフトに組み込む、SREと協力して運用のチケット対応を行うなどの方法があります。プロダクションの運用に開発チームが無関心でいられない状況を作ることで、運用への責任感や参加意識が芽生えます。

　また運用業務の一部を担当することで、開発チームがプロダクション運用に関する知見を得られます。仮にSREが運用から撤退することになったとしても、開発チームのみで運用を継続できる点で有効でしょう。