826
1
0
SRE の初歩の初歩の話
はじめに
契機
- 先日 @shirayee に誘われて SRE meetup at Fukuoka vol.3 に参加したのでアウトプット
- もとより興味がある分野なので勉強がてら
イベントのご紹介
- SRE meetup at Fukuoka vol.3
- 1 月の SRE NEXT にも行きたい
SRE 本
- イベントに行くにあたって何も知識がない状態だったので、インプットとして読み始めた。
-
SRE サイトリライアビリティエンジニアリング ―― Googleの信頼性を支えるエンジニアリングチーム
-
The Site Reliability Workbook: Practical Ways to Implement SRE
SRE is 何?
サービス管理へのシステム管理者の歴史
-
「dev」 と 「ops」 チームの分断
- ソフトウェア開発の一連の流れは、サーバの準備、ネットワークの構築などから始まり、ユーザが利用し始めたら障害が発生し、それを監視したり、対応したりと運用してような作業が発生する。つまり、ソフトウェアを開発する役割(Dev)とソフトウェアの価値をユーザーに届け続ける役割(Ops)が存在していると言える。ここでいう後者の役割を担うのが、システム運用です。そこで今では、上記のようなチーム分けをする会社や組織が多くなってきているかと思う。
- チームの分断によるデメリット
- 上記のようなチーム分けによるデメリットが大きく 2 つに分けて述べられている。
- 直接的なコスト:サービスそのものの成長やトラフィックの増大に伴ってチームも大きくして行かざる得ない
-
間接的なコスト:開発チームと運用チームの分断によるコミュニケーションや目標の衝突
- 「
好きなものを好きな時に邪魔なしにローンチしたいんだ
」 vs 「いったん動いたシステムはいっさい変更したくないね
」
- 「
Google のアプローチ: SRE ( Site Reliability Engineering )
- Google が提唱したエンジニアの役割
-
SREは、ソフトウェアエンジニアに運用チームの設計を依頼した時にできあがるものです。
-
- SRE と従来のシステム運用の違い
- 上で述べたデメリットを解消すべく生まれたのが、SRE という役割。つまり、これまでのシステム運用と異なる概念という訳ではなく、現在の問題を解決すべく誕生したものという理解が望ましい。
- システム運用に伴う作業の多くをエンジニアリングによって効率化・自動化
- 人手による管理を自動化するソフトウェアの設計や開発を業務時間の 50 % を当てることでサービスの成長・拡大とともに発生する直接的なコストを削減することができる。
- エラーバジェットの考え方を採用
- エラーを予算のように捉え、予め超えてはならない予算を設定しておく。その予算がなくなれば(許容量を超えるエラーが発生すれば)追加開発は行わず、バグ対応に優先するというルールを設ける。それにより、Dev と Ops の間にあった心理的障壁を取り除き、協力体制を築くことが可能になる。
- DevOps と何が違うの?
- 巷でよく聞く DevOps とは何が違うのか?
- DevOps の原典とも呼ばれる資料では「Dev's job is to add new features」「Ops’ job is to keep the site stable and fast 」1 と説明されており、非常に SRE と近しい問題意識と解決方法のように思える。
- また What's the Difference Between DevOps and SRE? | YouTube という動画では 「class SRE implements DevOps」 2 というセリフが登場する。
- これは、DevOpsを哲学とするならば、SREはその哲学を達成するための規範的な方法 のように解釈できるし、SREは、DevOpsを推進するための実装も行うが、従来のシステム運用における管理も担うという意味
- 巷でよく聞く DevOps とは何が違うのか?
まとめ
-
SRE はシステム運用に非常に有効な方法だと思う。必ずしも効率化や自動化だけではないし、「いま、組織でこういう問題が起きているけど、SREの考え方を取り入れれば解決する?」など SRE を取り入れるにあたってのメリットはあるのかを自分たちで議論することが重要だと思う。
-
もともと Google のベストプラクティスです。全てを鵜呑みにせず自分たちの組織にあった SRE を作るべきです。しかし、「ボトルネックを発見し、それを解消するために0から考えることを厭わない」企業として有名で、これが SRE が生まれた所以であり、参考にすることは多分にあると思う。