6/16(火)、Infra Study Meetup #3「SREのこれまでとこれから」に参加しましたので、レポートを書きます。
目次
イベントページ
SREとは
※Wikipediaより引用しました
- SRE(Site Reliability Engineering) は、Google社が提唱、実践しているシステム管理とサービス運用の方法論
- サイト信頼性エンジニアリングと訳される場合もある
- サイトリライアビリティエンジニアリングを担当するエンジニアをサイトリライアビリティエンジニア(SRE)と呼ぶ
※以下は自分の浅い理解のもと書いた言葉です。違っていたらツッコんでください。
- Webシステムの信頼性を向上させ、システムそのものの価値を向上させるための取り組み
基調講演「SREの文化と組織」 株式会社はてな SRE 古川 雅大氏
資料
SREのこれまでとこれから
- これまでSREはGoogleの一プロセスからWebサービス事業者のプラクティスへ
- 「企業のプラクティス」から「研究分野」へ
- これからは?
- 企業や組織ごとに合ったSREの実践、実装の登場
- セキュリティ分野など他の分野との連携
- 組織やコミュニケーション、文化の話は不可欠
- 「SREとは」を再整理する必要がある
SREとは???
ソフトウェアエンジニアに運用チームの設計を依頼した時に出来上がるもの
- 意思決定?
- ソフトウェアエンジニアリングによる自動化?
- システムのモニタリング?
- DevOpsの実装?
SREの内容をはっきりとは表現できていない
- SREという言葉が意味する役割と意味をもっとうまく定義する必要がある
SREを紐解く
- システムの信頼性に焦点を当てる。信頼性に関わることならYes.
- 信頼性こそプロダクトの基本
誰も使えないシステムは有益なものではない
- 信頼性とは
- システムが求められる機能を、定められた条件のもとで、定められた機関にわたり障害なく運用できること
システムとは?
- Webサービスには「人のシステム」(運用チーム、開発チーム、会社全体など)と「機械のシステム」(サーバ、ネットワークなど)がある
- この2つのシステムを考慮する必要がある
定められた条件(ビジネス的条件)とは?
- 限られたコスト(人、金、時間)
- 売り上げの増加(魅力的な新機能の開発)
- 市場の変化への対応(スケーリング)
- 信頼性とは
発表者の考えるSREとは
- 信頼性のあるWebサービスを提供するために、条件を考慮したシステムを設計、実装、運用の課題を解決すること
SREの文化
どういった考え方、文化を持っていれば現在のSREを生み出せるか?
- 文化を習得すれば応用し新たなプラクティスを生み出せる。
人と機械のシステム
- Webシステムは開発運用する人の組織や利用するユーザ、機能を提供するアプリケーションやインフラなどのシステムから成り立っている
- 開発チームと運用チームでの信頼関係、ユーザとの信頼関係を築く必要がある
- 目標、意思決定の基準、考え方を共有すること
- インフラやアプリケーションの信頼性は、技術で殴る!
信頼性にフォーカスする
- 判断基準を「信頼性」にし、信頼性に関して興味を持つこと
- インシデント対応
- 「変化」など信頼性が落ちる事項への対応、
- 人の心理やチーム間との信頼関係
- 他分野の信頼性に関する知見(信頼性工学、安全工学、心理学、組織論など)
- 判断基準を「信頼性」にし、信頼性に関して興味を持つこと
完全(信頼性100%)を目指さない
- オペレーションですべてをなくせない
- 1回のチャレンジで完全を目指さない
- 1人で出来る必要はない
信頼性とのトレードオフを理解する
エンジニアリング
- ソフトウェアエンジニアリング
- システムエンジニアリング
- 信頼性に関する課題の解決
SREと組織
どうやって導入するか?
- 組織もシステム。組織にSREという大きな機能を実装すると考える
- システムに編子を加えると信頼性が下がることを注意し、段階的に入れていく
- 変更料と信頼性(少しずつ導入)
組織が変更容易な組織か?
- 組織の規模
- 組織のマネジメント
- 組織に対する変更手順が整備されているか?(リリース手順)
- カナリアリリース(一部部署で試せるか)
- 組織が挑戦可能で批判的でない文化か?
誰に説明するか?
- 条件を考慮したシステムを設計、実装、運用の課題を解決
- 条件を決定できる人へSREを説明する必要がある
- システムに関係する人に説明する必要がある
- SREのすべてを説明するのは難しい
- ビジネスにとってSREは便利なツールであることを示す
- 条件を考慮したシステムを設計、実装、運用の課題を解決
どうやってSLI/SLOを導入するか?
- どこかのチームに導入するための準備をする
- サービス開発と同じように構成図やデザインドキュメントを書く
- サイクルを回すことが重要
その他
- CTOなど決定権を持つ人と共同で進める
- チーム横断的組織で進める
- プラクティスの共有 など
まとめ
- これからはより組織に合ったSREを実践、応用する必要がある
- プラクティスをまねるだけでなく、思想、哲学、文化を理解することが大事
LT1「Incident Response」 tjun氏
資料
インシデントとは
- 予期せず提供しているサービスが提供できない状態になったり、期待している機能が提供できないこと
インシデントレスポンスとは
- インシデントを解決するための組織的な仕組み
インシデント前にやること
- インシデントは必ず起きる
- 役割を決める
- トリガーを用意する
インシデント中にやること
- 慌てない
- 必要なメンバーを招集する
- 役割ごとに必要な対応を行う
インシデント後にやること
- 人を責めない
- ふりかえりを行う
インシデントレスポンスを始めよう
- ①インシデントを定義する
- ②コミュニケーションの仕組みを作る
- ③インシデント対応の役割を決める
- ④ふりかえりのテンプレを作る
- ⑤練習する
まとめ
- インシデントレスポンスはSREだけのものではない
- 組織全体で対応することが重要
LT2「AIスタートアップにおけるSRE」大川 遥平氏
各種Webサービス開発・保守
- コーポレートサイト
- LPの運用
AIの実行環境の開発・保守
- 推論用サーバ
LPの運用方法
AI推論サーバの運用方法
まとめ
LT3「Production Readyと開発プロセス改善」ぐりもお。氏
資料
Production Readyとは?
- サービスを本番トラフィックを任せられるほどの信頼がある状態
- 本番環境にリリースできる状態ということではない
一般的なProduction Readyのプラクティス
- Production Readiness Review
- Production Readiness Checklist
- Production Readiness Roadmap
- SRE Onboarding/Takeover
Production Ready対応(以前)
- レビュー不十分
- ロードマップ行えていない
- オンボーディングも行えていない
早期エンゲージメントモデル
- Production Ready活動の導入モデルのひとつで、早い段階から開発のライフサイクルに関わること
OPTiM Cloud IoT OSにおける早期エンゲージメントモデル
- 企画から運用までのプロセスを対象としている
プロダクションレディ対応(現在)
- ロードマップ以外は対応できるようになった
- サービスのドキュメントを整備
- フォーマットをそろえ、項目の抜け漏れをなくす
まとめ
- Production Readyで項目漏れや手戻りのないレビューが可能になった
- Production Readyのアプローチはサービス/チームによって違う
全体の感想
SREという言葉は知っていましたが勉強不足でした。予習してから臨んだ方がより理解できたと思います。信頼性向上はソフトウェアやWebシステムに限った話ではないため、SREの考え方は何にでも応用できるのでは?と思いました。「SRE難しそう」と思っていて手を付けずにいましたが、これを機に勉強してみようと思いました!
以上です。最後まで読んでいただきありがとうございました!