まえがき
おつかれさまです。mochiです。
今回は今勉強している資格に登場してきた『サイト信頼性エンジニアリング』について書こうと思います。SREと略されることが多いですね。
資格勉強をしていると、知らない単語や用語などがたくさん出てきます！でもそれを自分の中にインプットすることで頭良くなったように思えるので、頑張れます（笑）
軽く流し見してください。
SREって？
SREは、2000年代初頭にGoogleが開発したアプリケーション開発やソフトウェア開発におけるアプローチのことです。AWSなどで使われているフレームワークにあったりする信頼性（ユーザーが期待した通りの動作）に近い印象です。DevOpsにも近いものかと思います。
SREは人間が行うタスクや問題解決、システム管理を自動化します。SREチームはサービスの変更管理・緊急時対応・監視・可用性・パフォーマンス・レイテンシ・効率・キャパシティ計画を担当し、通常はプロセス自動化用のソフトウェア開発を行っています。
GoogleにおけるSREの原則
1, サービスレベル指標（SLI）の設定: システムのパフォーマンスや信頼性を測定するための指標を定義します。
2, サービスレベル目標（SLO）の設定: SLIに基づいて、システムが満たすべき目標を定義します。これはユーザー体験やビジネス目標に関連します。
3, エラーバジェットの設定: SLOと実際のパフォーマンスの間に許容される差を定義し、この差をエラーバジェットと呼びます。エラーバジェットを超えると、システムの安定性に関する新しい変更を停止します。
4, トイルミティゲーションとインシデント対応の自動化: インシデントが発生した場合やエラーバジェットが超過した場合に、自動化された手順を用いて迅速かつ効果的に対応します。
これらの原則に基づき、Googleはシステムの信頼性を向上させると提唱しています。
自動化とシステムの監視はヒューマンエラーを減らし、迅速なインシデント削減を実現します。また、これによってUXの向上やビジネスの安定性も確保されるかと思います。
DevOpsとの違い
DevOps
DevOpsは、開発チームと運用チームの連携とコラボレーションを重視します。これにより、開発と運用の壁を取り除き、ソフトウェアのリリースサイクルを迅速化し、品質を向上させることを目指します。
DevOpsでは、自動化、継続的な統合（CI）、継続的なデリバリー（CD）などのプラクティスが重要視されます。
DevOpsは、ソフトウェアの開発、テスト、デプロイ、運用などのフルライフサイクルをカバーし、開発と運用の連携を通じてビジネス価値を最大化します。
SRE
SREは、システムの信頼性と安定性を確保することに焦点を当てています。これは、サービスの可用性、パフォーマンス、セキュリティなどを最大化し、障害に対する迅速な対応を実現することを目指します。
SREでは、サービスレベル目標（SLO）、エラーバジェット、自動化、トイルミティゲーションなどのプラクティスが重視されます。
SREは、Googleが開発したアプローチであり、開発と運用の間に位置する役割とプロセスを提供します。SREは、運用チームとしての責任を持ちつつも、開発チームとの密接な連携を通じてサービスの信頼性を確保します。
Devopsは開発と運用の効率化を目指すものであり、SREはシステムの信頼性や安定性を重視しているものなのかなと思います。
mochi所感
IT業界に限らずSREはかなり重要です。ECサイトの顧客に対する趣向に基づいたレコメンデーションや、金融機関のシステム等では可用性が特に求められるため、より高いSLAが必要かと思います。
インフラエンジニアとしてSREのベストプラクティスを頭の片隅に押さえておくだけでも、その人のIT市場価値は上がるのではないかと思いました。
自分の持っているクラウドの導入フレームワークに関する知識と合わせれば、お客様へのハイブリッド環境の導入提案やマルチクラウドの導入アドバイスもできますし、新規サービスをバリデーションしている時、どのようにロールアウトし、デプロイすべきかのベストプラクティスも提唱できると思います。(最初は一部の顧客でテストを実施してから本番にロールアウトする。など)
ITインフラはシステムの土台となっているため、業界問わず多くのニーズが高まっているかと思いますので、この知識は自分の中でも抑えておき、クラウドの導入提案をするときが来たら、パッと出せるようにしておきます！！おわり。