SREとはサイト・リライアビリティ・エンジニアリングの略称で、Googleが提唱するシステム運用の方法論です。
SREの説明、実践方法などは、色々なサイトでご紹介されていますので、ここでは省略します。
我々のSREに対する考え方、取り組む実情を紹介することによって、サービスの信頼性向上、安心感に繋がれば幸いです。また、これからはじめるという企業様の参考になれば、嬉しいです。
SREの解釈と考え方
SREに取り組むべき理由は、サービスの安定稼働、信頼性の担保はもちろんですが、そこばかり求めてしまうとシステムのレガシー化が進み、結果的にサービスの有用性が低下するという事態に陥る可能性があります。
そのためには、リスクの許容範囲を明確化し、顧客に最大限の価値を提供できるための体制の構築が必要という解釈です。
つまりは、システムの信頼性を担保するための守りのアプローチを行いつつも、手作業の自動化等の省力化、体制の見直しなど、継続的な改善の攻めのアプローチも併せて行っていくということです。
我々としては、はじめから完璧な体制を整えることは難しいので、現状況下でまずは始めるということが重要と考えます。
マーケライズでは、エンジニアはサービスの開発と運用の両方ともを担っていますので、SREチームはありません。人的リソースが少ないという事情もありますが、開発者もサービス安定稼働、信頼性向上のための活動に取り組み、対処するべきという考え方が根底にあるからです。
SRE導入の経緯
SRE導入の経緯をお話しすると、最初からSREを導入すると決めて取り組みをした訳ではなく、特に意識していませんでした。
プロダクトを運用する中で、日々不具合対応、調査等に奮闘し、開発者は全く余裕がなく、何とか品質を向上させ、かつ安定したサービスを維持できるようにならないかと思い悩んでいる状況でした。そこで、問題点・課題を洗い出し、対応の優先付けを行い、優先度の高いものから徐々に取り組みを始めた中で、SREという方法論を知ったという経緯です。
SREの目的、役割、ミッションを定義
最初に、開発チームの行動のベクトルの方向を合わせるために、SREの目的、役割、ミッションを定義しました。
目的、役割
- サービスの信頼性を高める（機会損失となる障害を最小化し、サービスを安定稼働する）ため
- ユーザー（利用者）の意向に沿った最大限の価値を提供するため
ミッション
- クリティカルな不具合をなくし、可用性99.9%を実現
- 繰り返し及び誤操作が起きるような手作業をなくし、可能なものは全て自動化
- セキュリティリスクの徹底管理
- 開発者が安心、安全、かつ集中できる環境、体制の構築
SREの取り組み事例
以下に、定義した役割を元に業務で実施している取り組み事例を紹介します。
- SLI(サービスレベル指標)/SLO(サービスレベル目標)を定義
- マイクロサービス化を推進
- AWSのマネージドサービスによるインフラストラクチャ構築
- サーバレスプラットフォームによる利用率の自動最適化
- 膨大なトラフィックへのスケーラビリティ確保
- 自動監視、及びアラート発泡
- ステージング、本番環境へのデプロイの自動化
- テスト（単体、API、受入）の自動化
- 事業継続、インシデント管理
- スクラム開発、プルリクエスト、コードレビューの文化
- プロジェクトチームによる部門間の連携
- モダン技術、情報共有ツールの積極的採用
さいごに
現状、まだ課題もたくさんある状況で、取り入れたいことも多くありますが、Googleのベストプラクティスを参考にしつつ、自社にあったやり方で適用していければ良いということと、SREの取り組みは、進化し続ける必要があると思っています。
今回は、具体的な内容までご紹介できませんでしたので、別記事で紹介していく予定です。
