本記事は
Google Cloudウィーク
3日目の記事です。
💻☁
2日目
▶▶ 本記事 ▶▶
4日目
☁💻
はじめに
こんにちは、木下です。Google Cloud ウィークということで、ネットコムテックブログ2回目の執筆機会がやってきました。 弊社ではGoogleCloud(GCP)を扱う比率はまだ低いですが、私が担当しているシステムではGoogleCloudを利用しています。 今回は日々の業務視点も含め、SREについて記載していきます。 GoogleCloudを使っていない方もSREの考え方は業務に活かせる点があると思いますので、ぜひ最後まで読んでいただけると嬉しいです。
SREとは
SRE (Site Reliability Engineering：サイト信頼性エンジニアリング) とは、システムを信頼性の高い状態で提供するための方法論と言えます。
SREの特徴として、ユーザへのサービス提供だけではなく、開発/運用者にも配慮している点があります。
つまり、どうすればユーザ/開発者ともに有益で幸せなれるか？を考えた方法論だと思っています。
また、SREはGoogle社が提唱したため、GoogleCloudのサービスとの親和性も高いと考えられます。
GoogleCloud公式ページでは「SRE は、信頼性の高い本番環境システムを実行するための職務、マインドセット、エンジニアリング手法のセットです。」と紹介されています。
https://cloud.google.com/sre?hl=ja
GoogleCloudの関連サービス
SREの主な関連サービスとしては以下が挙げられます。
- Cloud Logging
- Cloud Monitoring
- Cloud Build
- Artifact Registry
- Cloud Deploy
Cloud Logging、Cloud Monitoringは主に運用時のログやメトリクスを監視し、異常時にはアラートを出すことで、日々の運用や保守を実現/サポートしてくれます。
Cloud Build、Artifact Registry、Cloud Deployを用いることで、アプリの開発/テスト/リリースの自動化を実現することもできます。
業務にあてはめると(サービス面)
上記5つのサービスは私が担当しているシステムでも実際に使っています。 大きく役立った例だと、Cloud Buildでコンテナイメージを作成する際にテストを仕込んでおり、アプリ改修に伴う問題を検出できました。 ローカルでの開発中には発見されていない箇所だったため、開発～デプロイの自動化以外の恩恵もありました。 Cloud LoggingやCloud Monitoringも日々の運用/保守、障害発生時にも役立っています。
一方、もう一歩踏み込んで、SLI(サービス レベル指標)、SLO(サービス レベル目標)、エラーバジェットの観点を用いた運用を実現できれば、今後のリリース計画や運用に裏付けを持った形で進めるはずです。 この点については、私のプロジェクトでもこの機に検討していければと思いました。
業務にあてはめると(障害発生時)
障害など不測の事態が発生した場合、技術面から障害を解決するのは必須で重要ですが、関係者間のコミュニケーションや振り返りも必要な要素になります。
対応者にロール(役割)を割り当てることで、障害管理の成熟度、効率性、有効性の向上につながります。
代表的なロールは以下の3つです。
- インシデントコマンダー：インシデント対応の全体的な戦略を立て、他のロールと協力して問題の解決を図る責任者のロール。
- オペレーションリード：具体的なインシデントの解決策や作業手順を指示し、技術的な観点からインシデントを解決するロール。
- コミュニケーションリード：インシデントに関するコミュニケーションの責任を持ち、他のチームや顧客への情報の伝達を行うロール。
これらを適切に割り当てることで、自身の役割に集中することができ問題解決がスムーズに行われます。 また、チームで対応する場合、コミュニケーション不足で複数人が同じ箇所を見ていて別要因の検討がおろそかになるのを防ぐことや、顧客への状況共有が出来ておらず不安にさせることを回避できるはずです。
ただ、システムの規模や人員によっては一人が複数のロールを担うこともあると思います。 実際に私も夜間の障害を一人で対応した経験があります。 こういった場合でもロールについて知っていれば、技術的な復旧以外に必要な要素(顧客への連絡など)を漏らすことなく対応できるかもしれません。 また、一人で抱え込まずに適切なエスカレーションにもつながると思います。
障害解消後は振り返りが大切になります。 そこで出てくるのが「ポストモーテム」です。 ポストモーテムとは、インシデントとそのインパクト、その緩和や解消のために行われたアクション、根本原因（群）、インシデントの再発を避けるためのフォローアップのアクションを記録するために書かれるものです。
15章 ポストモーテムの文化：失敗からの学び - SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム [Book]
ポストモーテムを構成する要素は多くありますが、個人的に重要だと考えているのは以下の3つです。
- 根本原因の分析
問題の真の原因を特定し、それが再発しないようにするためのプロセスです。これにより、問題が再発するのを防ぐための改善策を立案することができます。 ここではヒューマンエラーという結論にならないことも大切です。 障害の原因となった箇所の担当者が責められるような形のポストモーテムが作成されることは、誤った分析になっていると思います。
- 広い範囲への共有
ポストモーテムのレビューや完成したポストモーテムは、チーム内で留めるのではなく、課、部といった広い範囲に共有することが重要です。 広い範囲でレビューしてもらうことで、チーム外やベテランエンジニアからの意見により新たな気づきを得る可能性があると思います。 また、共有されたポストモーテムを多くの人が参照することで、将来の障害を未然に防ぐ役目を果たすことも考えられます。
- 学んだ教訓
プロジェクトやタスクの完了後、または障害発生後に得られる知識や経験です。これにより、将来のプロジェクトや障害対応の効率化,改善が可能となります。
最後に私が携わっているプロジェクトのポストモーテムには、「幸運だったこと」という項目があります。 障害対応はマイナスなイメージがあると思いますが、その中でも「幸運だったこと」を記載することで、プラスに捉えることができ、より良いポストモーテムが完成すると感じています。
まとめ
SREについて個人的な視点も多くなってしまいましたが記載しました。
私自身がそうだったのですが、SREやポストモーテムについて知らない状態でも、日々の業務に取り込まれて触れているものも多かったのではないでしょうか？
このブログでは簡単な紹介になっているため、他のページや本を参考にSREについて理解を深め、ご自身のプロジェクトなどに反映することで、信頼性の高いシステムを実現できると思います。
