SREってなんだろう

Drecom SRE Sunday Vol.2 で話した内容です

Transcript

1. SREってなんだろう
2. About Me • 橘田隼一 / Twitter： @hayabusa333 / Github： hayabusa333 • 株式会社ドリコム ◦ Work ▪ エンジニアリーダー • 技術スタックを考えたり、更新計画を立てたり • golang で開発したり ▪ サーバー/インフラエンジニア • SREチームとして色々とやったり • Community ◦ tokyo.ex • Hobby ◦ お酒 ◦ TRPG
3. ゴール • ターゲット ◦ SREについて知らない方々 • ゴール ◦ SREが、どのようなものかわかる ◦ SREになりたいと思ってもらう
4. SREとは • Site Relaiability Engineer ◦ Google 来るべきシステム管理の姿として考えられたもの ◦ デプロイ、運用、改善、平穏なる撤去をエンジニアリングで解決 ▪ SREはエンジニアである
5. SREとDevOpsの違いは？ • SREとDevOps は混じり合う箇所があるという人もいる • DevOpsは開発からデプロイまでの箇所を見て、SREはその拡張であるという人も いる • SREはDevOpsチームを支えて、高い信頼性でリリースするために集中するっとい う人もいる • DevOpsは思想で、それを実践するのがSREという人もいる • SREは従来の運用の進化系、DevOpsは最新情報を把握してチームを横断してビ ジネスを強化するっという人もいる SREとDevOpsは共存できるししていくべきではあるが、定義は人によってまちまちであ る
6. SREの用語 • SLI ◦ サービスレベル指標 ▪ サービスの挙動に関する単一の計測可能なメトリクス ▪ 何を測定して、何を使用するかが重要 • 可用性 • レスポンスタイム • SLA ◦ ユーザーがサービスに期待する挙動の全体を定義 ▪ SLIを組み合わせたもの ▪ 何を適切として、何を不適切とするかを考えるのが重要
7. SREの用語 • SLO ◦ サービスレベル目標 ◦ SLAと同じものであり、SLAのレベルを引き上げるのが一般的 ◦ SLAとSLOの違いは制約の強さ
8. SREの用語 • トイル ◦ プロダクションサービスを動作させるために必要な手作業 ◦ 自動化することが可能なもの ◦ 割り込みで発生し長期的な価値を持たないもの ◦ 作業量がサービスの成長に比例する • トイルの作業はできるだけ少なくする必要がある ◦ トイルがあると仕事をしている感が出るが何も生み出していない ◦ サービスに機能を追加するエンジニアリングプロジェクトにこそ時間を費やす べきである
9. SREってどこから入っていくの？ • 正直わからん • いろいろな会社で違うので一概にはどこからっと言えないと考える ◦ SREはインフラストラクチャを管理しないという人もいる ◦ インフラストラクチャの管理と開発がSREという会社もある ◦ 信頼性の高いシステムとアプリケーションの構築と管理するというところもある ◦ 開発に強いバックグラウンドがある運用者というところもある ◦ ステージング環境、CI/CDパイプライン、自動テストの用意とかを行うというとこ ろもある
10. ドリコムのSRE • インフラチーム ◦ 開発環境、本番環境の用意、デプロイパイプラインの用意 • アプリケーションチーム ◦ 性能試験、負荷試験の対応 • クライアントチーム ◦ ライブラリの用意、更新
11. SREのスキルセット • オペレーティングシステムの内部 • ネットワーキング • モニタリングとアラート • トラブルシューティング • デバッグ • インシデント管理 • ソフトウェアエンジニアリング • ソフトウェアのパフォーマンス • ハードウェア • 分散システム • キャパシティプランニング • セキュリティ
12. SREチームの学び • ポストモーテム ◦ 発生した障害と影響度、障害の緩和や解消のために行われた対応、根本原 因、再発防止のためのアクションを記録する • プロダクションミーティング ◦ 開発者とSREが集まってサービスの状態を議論する週次のプロダクトミーティ ング ◦ チーム全体としてサービスのパフォーマンスや発生している問題について情報 を得ることができる ◦ 新しく入ったエンジニアはミーティングで理解できなかったことを書き留めてリ ストにする ◦ リストの内容をメンターは教えることによって、ドキュメントや知識の更新を行う ことができる
13. ポストモーテム • ドリコムのポストモーテムに関しては以前話させていただきました ◦ https://speakerdeck.com/hayabusa333/posutomotemukarazhen-rifan-ru ◦ https://www.youtube.com/watch?v=wua__TdBOtk
14. SREチームの学び • Wheel of Misfortune：不運の輪 ◦ ロールプレイングゲーム ◦ ゲームマスター1名とチームメンバー 1名で行う ◦ 何らかのイベントが発生していることをチームメンバーに伝える ◦ チームメンバーは問題の権限、根本原因分析、解決を行う ◦ ゲームマスターはチームメンバーが行った内容に対して何が起こったかをシ ミュレートする ◦ ゲームの内容は過去起こったインシデントで行う
15. なぜSREチームは学ぶのか • SREチームが学ばないとサービスの障害の原因を作ってしまう • SREチームが学ばないと障害の発生時間が延びてしまう • セキュリティ問題で会社の信頼問題になる ◦ 上記は何度も発生させて良い問題ではない ◦ そのためSREチームとして教訓から学ぶ方法が用意されている
16. SREの作業 • ソフトウェアエンジニアリング ◦ コードの作成や修正、設計やドキュメンテーションの作成 ▪ 自動化スクリプトの作成 ▪ ツール・フレームワークの作成 ▪ サービスへのスケーラビリティや信頼性のための機能の追加 ▪ インフラストラクチャのコード修正 • システムエンジニアリング ◦ プロダクションシステムの設定 ◦ システムに関するドキュメントの作成 ▪ モニタリングのセットアップ・更新 ▪ サーバーの設定 ▪ パラメータのチューニング
17. SREの作業 • トイル ◦ サービスを稼働させることに直結する作業 • オーバーヘッド ◦ サービスを稼働させることに直結していない管理的な作業 ▪ 採用 ▪ 人事の事務作業 ▪ ミーティング
18. まとめ • SRE自体は新しい考えではない ◦ 運用を良い形でやるためにはどうすれば良いかという流れ ◦ DevOpsと混じり合ったり喧嘩したり • SREはエキスパートとゼネラリストを兼ねている ◦ 全てに対してエキスパートである必要はない ◦ 自分自身の強みはどこにするのか ◦ 幅広い知識は必要になってくる • SREを始めるに対しても、どこから始めていくかは自由だと思う
19. 参考資料 • SRE サイトリアイアビリティエンジニアリング ◦ https://www.oreilly.co.jp/books/9784873117911/ • サイトリアイアビリティワークブック ◦ https://www.oreilly.co.jp/books/9784873119137/ • SREの探究 ◦ https://www.oreilly.co.jp/books/9784873119618/