はじめに
こんにちは!スタイル・エッジのpeipeiです。
この度、弊社ではプロダクト横断型の SREチーム を発足しました!
組織全体の信頼性向上を目指し、複数の開発を支援するチームとして、SRE文化の構築に挑戦しています。
この技術ブログの連載を通して、私たちが取り組む課題や解決のプロセスをリアルにお伝えしていきます。
SREとは
SRE(Site Reliability Engineering)は、システムの信頼性を向上させるためのエンジニアリング手法とされています。
Googleが提唱したこの概念は、システムの可用性・スケーラビリティ・パフォーマンスを維持、向上させることを目的とし、運用をコードで自動化することで開発と運用のギャップを埋めるという考え方に基づいています。
また、SLO(Service Level Objective)*1やエラーバジェット*2を活用し、信頼性と開発スピードのバランスを最適化することが特徴です。
一般的にはこのように説明されますが、私たちは SREの定義を簡潔にし、次のように解釈しています。
ユーザーへ提供しているサービスの機能を
利用したいタイミングで、意図したとおりに快適に利用できる状態を実現するために、
ソフトウェアエンジニアが設計やアプローチを考え、実践する活動。
SREチームが取り組む課題
弊社のSREチームは以下の課題に取り組んでいきます。
今後も様々な課題にぶつかる中で、取り組みが増えていくことかと思います。
- SLI(Service Level Indicators)*3を通じてシステムの状態を数値化し、SLOとしてユーザー体験の基準を設けることで適切な信頼性の目標を定める。
- システム障害やヒヤリハットを通じて得た学びを活かし、組織全体で改善を進める文化を育む。効果的なポストモーテム*4文化を確立し、各チームへ再発防止策を横展開する仕組みを構築する。
- オブザーバビリティを向上させることで、システムの健康状態を可視化したり、障害発生時の原因を迅速に特定できるようにする。
- 各チームのセキュリティ対策を標準化し、ばらつきをなくすことで、組織全体の安全性を向上させる。
- インフラストラクチャのコード化を推進し、自動化によって手作業のオペレーションを削減する。また、インフラ構成の一貫性を保ち、静的解析ツールを活用してセキュリティチェックを自動化することで、安全性と運用効率を向上させる。
- 各チームで実施したEOL(End of Life)対応や運用ノウハウをSREが集約し、類似の作業や他のプロダクトにも活用できる仕組みを整える。
- トイル*5を削減し、手作業によるミスを防ぐことで、システムの信頼性を向上させる。また、運用負荷を軽減し、エンジニアがより価値の高い業務に集中できる環境を整える。
連載予定
投稿日 | タイトル |
---|---|
3月 | AWS Security Hubを導入して社内セキュリティ対策の標準化を推進 〜取り組み背景・課題の可視化編〜 |
4月 | AWS Security Hubを導入して社内セキュリティ対策の標準化を推進 〜改修・予防編〜 |
5月 | SREが“消火活動”に本気で向き合って見えた、信頼性向上へのリアルな一歩 |
※内容や更新予定日は、追加・変更の可能性があります。
これから連載を通して、SREチームのチャレンジや、日々の気づきをお伝えしていきます。我々と同じように「SREって何から始めればいいの?」と悩む方や、自社の運用課題を抱える方の参考になっていければ幸いです。次回をお楽しみに!
一緒に働く仲間を募集しています!
スタイル・エッジでは、一緒に働く仲間を募集しています!
スクラムマスターやプロダクトオーナーも絶賛募集中です。
もし興味をお持ちいただけましたら、ぜひ採用サイトをご覧ください!
recruit.styleedge.co.jp
*1:事業者がサービスを展開するにあたって設定する、サーバーやネットワークなどの「稼働率」「性能」「可用性」「セキュリティ」といった項目ごとのパフォーマンスの目標値や品質の評価基準のこと。
*2:SLOからの逸脱が許容される範囲を数値化したものであり、信頼性と変更速度のバランスを取るための指標として機能する。
*3:サービスの性能や信頼性を測定する具体的な指標であり、ユーザー体験に直接影響を与える要素を数値化することで、客観的な評価を可能にする。
*4:システム障害発生後に、その原因や影響、対応プロセスを振り返り、今後の再発防止策を策定するための分析・ドキュメント作成のプロセスのこと。
*5:手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加する、といった特徴を持つ作業のこと。