SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

【デブサミ2021夏】セッションレポート(AD)

最近よく聞くSREって何? 定義から実践に向けたロードマップまで解説【デブサミ2021夏】

【C-5】エンジニア必見!SREへの第一歩

  • このエントリーをはてなブックマークに追加

SREチームの定義から始まる、SREロードマップ

Sreke流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提供まで、幅広い領域をサポートします。

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
【デブサミ2021夏】セッションレポート連載記事一覧

もっと読む

この記事の著者

中村 仁美(ナカムラ ヒトミ)

 大阪府出身。教育大学卒。大学時代は臨床心理学を専攻。大手化学メーカー、日経BP社、ITに特化したコンテンツサービス&プロモーション会社を経て、2002年、フリーランス編集&ライターとして独立。現在はIT、キャリアというテーマを中心に活動中。IT記者会所属。趣味は読書、ドライブ、城探訪(日本の城)。...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/14742 2021/09/29 12:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング