SRE大全スタディスト編前半 #hbstudy 85

Slide 1

Slide 1 text

Slide 2

Slide 2 text

#hbstudy

Slide 3

Slide 3 text

最後に質疑応答の時間あります！

Slide 4

Slide 4 text

● Katsuhisa Kitano / 北野勝久 ● @katsuhisa__ ● SRE @ Studist Corporation ● Organizer of SRE Lounge / Rails Developers Meetup ● Linux カーネルと同い年

Slide 5

Slide 5 text

マニュアル作成・共有プラットフォーム

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

2016年 3 2018年 18 開発チーム

Slide 8

Slide 8 text

2016年数千ユーザー増 2018年数万ユーザー増月間ユーザー増加ペース

Slide 9

Slide 9 text

グロースフェーズに差し掛かっているチームおよびプロダクト

Slide 10

Slide 10 text

SRE 大全過去の登壇企業 ● メルカリ ● mixi ● クックパッド ● ユーザーベース

Slide 11

Slide 11 text

スタディストSRE の特色 ● 歴史が浅いチーム ● 少規模（現在 3人）

Slide 12

Slide 12 text

自分が話せそうなこと ● 0からのSRE 実践＆定着の経験 ○ 何からはじめるか、何を変えるか ● SRE チームのマネージャー職として考えていることの共有 ○ 採用やチームづくり前半後半

Slide 13

Slide 13 text

Agenda [前半] ● SRE とは何かについての自分の解釈 ● スタディストSRE の歴史 ● サービス信頼性階層 ○ 事例紹介 ■ Monitoring ■ OnCall ■ Postmortem

Slide 14

Slide 14 text

Agenda [後半] ● スキルマップ ● SRE の採用と育成 ○ SRE として大事な価値観 ● スタディストSRE チームが目指す方向性

Slide 15

Slide 15 text

Slide 16

Slide 16 text

SRE とは何か

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

Ops の責務の例 ● 安定稼働 ○ 異常時の検知と対応 ● リリースパイプライン ● 環境構築と運用 ○ インフラ構築と運用 ■ ミドルウェアのセットアップ ■ OS のセキュリティパッチ適用

Slide 22

Slide 22 text

Ops の責務の例 ● 安定稼働 ○ 異常時の検知と対応 ● リリースパイプライン ● 環境構築と運用 ○ インフラ構築と運用 ■ ミドルウェアのセットアップ ■ OS のセキュリティパッチ適用一般的にコードを書くことに比べ、手作業が多くなりがち

Slide 23

Slide 23 text

Ops の責務の例 ● 安定稼働 ○ 異常時の検知と対応 ● リリースパイプライン ● 環境構築と運用 ○ インフラ構築と運用 ■ ミドルウェアのセットアップ ■ OS のセキュリティパッチ適用そこで・・・

Slide 24

Slide 24 text

Ben Treynor の提唱する定義 ● 「 SREは、ソフトウェアエンジニアに　運用チームの設計を依頼したときにできあがるもの」

Slide 25

Slide 25 text

自分なりのSRE の解釈

Slide 26

Slide 26 text

非機能要求をチームの力とソフトウェアで実装する

Slide 27

Slide 27 text

ソフトウェアはともかく・・・チーム？

Slide 28

Slide 28 text

チーム ● SRE はDevOps を実装する役割 ”も” 担う ● class SRE implements DevOps ● DevOps 4本柱のうち 2つは、コラボレーションとアフィニティ by 『Effective DevOps』

Slide 29

Slide 29 text

非機能要求グレード6つの大項目 ● 可用性 ● 性能・拡張性 ● 運用・保守性 ● 移行性 ● セキュリティ ● 環境・エコロジー

Slide 30

Slide 30 text

非機能要求グレード6つの大項目 ● 可用性 ● 性能・拡張性 ● 運用・保守性 ● 移行性 ● セキュリティ ● 環境・エコロジー SRE の責務を理解するのに便利な箱

Slide 31

Slide 31 text

Agenda [前半] ● SRE とは何かについての自分の解釈 ● スタディストSRE の歴史 ● サービス信頼性階層 ○ 事例紹介 ■ Monitoring ■ OnCall ■ Postmortem

Slide 32

Slide 32 text

自分自身のこと ● 2016/8: スタディスト入社 ○ サーバーサイドエンジニア ● 2017/1〜4: 運用の引き継ぎ ○ サーバーサイドエンジニア + サービス運用 ● 2017/8: SRE としてのマインドチェンジ ● 2018/9: SRE チームが組織図に反映され、マネージャー職にようやくSRE の専任に

Slide 33

Slide 33 text

スタディストSRE の歴史

Slide 34

Slide 34 text

SRE前夜: 〜2017/8 ● 従来型のシステム運用 ○ 人間ががんばることで問題を収束させることを繰り返す ● ユーザー増加に伴い、障害増加傾向 ○ モニタリング基盤が整っていないので、障害調査に時間がかかる ○ OnCallつらい

Slide 35

Slide 35 text

SRE前夜にやったこと ● 運用に関わるドキュメントを整備した ○ 後々、運用者を増やす際に役立った ● 目の前のタスクをこなす時間と学習時間の比率を変えた ○ 学習時間を増やした ○ いろんな学習が結びつかず断片的な知識

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

SRE0→1: 2017/8〜2018/1 ● 技術顧問として、ex-Cybozu 萩原さんが入社 ○ SREやっていき ● この頃、SRE 本の日本語訳が発売された

Slide 38

Slide 38 text

SRE0→1 やったこと ● Monitoring 基盤整備 ○ ダッシュボード構築 ○ アラート再設計、監視項目追加 ● OnCall ワンオペからの脱却 ● ポストモーテムを書く文化の共有

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

Site Reliability Engineering

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

SRE1→10: 2018/1〜2018/9 ● 障害発生頻度が低減 ● より、SRE らしい仕事へ ○ インフラのコードを書く時間の確保 ○ AWS Lambda で運用省力化 ○ 性能向上のための実装 ■ bulk insert 化

Slide 43

Slide 43 text

SRE1→10 やったこと ● 管理しているサーバーのインフラコード化が一通り完了 ● サービスのパフォーマンスに向き合うWG の発足

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

SRE10→？: 2018/9〜 ● 組織図にSREチームが反映 ● ようやくSRE のタスクに専任で作業できる人が ● SRE本は、後続の二冊が発売される

Slide 47

Slide 47 text

SRE10→？やっていること ● SRE チームとしての開発プロセス・評価・Onboarding の設計や導入 ● 哲学や思想、チームとして導入したいプロセスのドキュメントをつくる

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

No content

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

Agenda [前半] ● SRE とは何かについての自分の解釈 ● スタディストSRE の歴史 ● サービス信頼性階層 ○ 事例紹介 ■ Monitoring ■ OnCall ■ Postmortem

Slide 52

Slide 52 text

サービス信頼性階層

Slide 53

Slide 53 text

サービス信頼性階層 https://landing.google.com/sre/sre-book/chapters/part3/#fig_part-practices_reliability-hierarchy

Slide 54

Slide 54 text

サービス信頼性階層 https://landing.google.com/sre/sre-book/chapters/part3/#fig_part-practices_reliability-hierarchy スタディストSRE も階層を下から積み上げてきた

Slide 55

Slide 55 text

サービス信頼性階層 https://landing.google.com/sre/sre-book/chapters/part3/#fig_part-practices_reliability-hierarchy

Slide 56

Slide 56 text

事例紹介

Slide 57

Slide 57 text

▶　Monitoring ▶　OnCall ▶ Postmortem

Slide 58

Slide 58 text

Monitoring

Slide 59

Slide 59 text

Why Monitoring? 1. 信頼性をはかるため 2. 信頼性を共有するため

Slide 60

Slide 60 text

信頼性のはかりかた ● 何をはかる？ ○ Golden Signals ■ latency ■ error ■ traffic ■ saturation ● saturation を事前に見極めるためには、負荷試験環境の整備と継続実施が必要

Slide 61

Slide 61 text

信頼性のはかりかた ● 何をはかる？ ○ Golden Signals ■ latency ■ error ■ traffic ■ saturation ● saturation を事前に見極めるためには、負荷試験環境の整備と継続実施が必要実際は、細かい監視項目が大量に存在 e.g. 各種OSメトリクス, Apdex ...

Slide 62

Slide 62 text

信頼性のはかりかた ● 何をはかる？ ○ Golden Signals ■ latency ■ error ■ traffic ■ saturation ● saturation を事前に見極めるためには、負荷試験環境の整備と継続実施が必要アプリケーション特性によっては他に注視すべきMonitoring 項目も

Slide 63

Slide 63 text

はかりかたと運用方法の例 ● 可用性 ○ 一定タイムウィンドウ内でのエラーを集計 ○ エラーレートが一定値を越えれば、そのウィンドウをダウンタイムとして計測 ○ ダウンタイムが一定時間継続すれば障害とみなす ● レイテンシ ○ 一定タイムウィンドウ内でのレイテンシを集計 ○ レイテンシの 99%tile を計測

Slide 64

Slide 64 text

Google App Engine のSLA https://cloud.google.com/appengine/sla

Slide 65

Slide 65 text

[WIP] SLI 計測システムアクセスログ Kinesis Stream S3 Athena Kinesis Analytics Lambda 1 2 4 3 5 6 Stackdriver

Slide 66

Slide 66 text

[WIP] SLI 計測システムアクセスログ Kinesis Stream S3 Athena Kinesis Analytics Lambda 1 2 4 3 5 6 Stackdriver 柔軟にメンテできるように自前実装アラートと集計処理を分離

Slide 67

Slide 67 text

余談: Apdex の活用 http://apdex.org/apdexfaq.html 平均レスポンスタイムは、一部の問題あるリクエストに値が左右されやすい Apdex はべんり

Slide 68

Slide 68 text

信頼性を共有する ● ダッシュボード ● 監視結果通知 ○ アラート ○ チケット ● スタディストで利用しているツール群 ○ Elasticsearch/Kibana, Stackdriver, Stackdriver Error Reporting, CloudWatch, NewRelic

Slide 69

Slide 69 text

信頼性を共有する ● ダッシュボード ● 監視結果通知 ○ アラート ○ チケット ● スタディストで利用しているツール群 ○ Elasticsearch/Kibana, Stackdriver, Stackdriver Error Reporting, CloudWatch, NewRelic 「メールで受信」「Slackに共有」を併用監視通知の冗長化

Slide 70

Slide 70 text

OnCall

Slide 71

Slide 71 text

小規模チームでのOnCall ● 前提: OnCall ローテーションを組めない ○ 過去、OnCall要員は最大でも3人という規模感 ● 休暇前に、対応可否を共有する ○ ネットのつながらない場所に行かないか？

Slide 72

Slide 72 text

ストレスを減らすために ● 後述するポストモーテムを書き、問題をチームに共有することで確実にClose する ○ 自動復旧 or 根本原因撲滅 or 事前検知導入 ● 対処方法が不明瞭な問題が頻発するとストレスが非常に高い（過去の経験談）

Slide 73

Slide 73 text

Postmortem

Slide 74

Slide 74 text

Postmortem ● 障害振り返り ● 書く基準: 顧客影響の有無 ○ 影響規模は関係ない ● 書いたら、全体に共有 ○ 常に誰でも見れるようにしておく ○ 良いPostmortem は教育材料に

Slide 75

Slide 75 text

記入項目例 ● 作成者 ● ステータス ● サマリ ● インパクト ● 根本原因 ● 発生要因 ● 対応 ● 検出 ● アクションアイテム ● 教訓 ○ うまくいったこと ○ うまくいかなかったこと ○ 幸運だったこと ● タイムライン ● 参考情報

Slide 76

Slide 76 text

記入項目例 ● 作成者 ● ステータス ● サマリ ● インパクト ● 根本原因 ● 発生要因 ● 対応 ● 検出 ● アクションアイテム ● 教訓 ○ うまくいったこと ○ うまくいかなかったこと ○ 幸運だったこと ● タイムライン ● 参考情報問題を正しく認識しないと書けない（重要）数字の曖昧さを意識

Slide 77

Slide 77 text

記入項目例 ● 作成者 ● ステータス ● サマリ ● インパクト ● 根本原因 ● 発生要因 ● 対応 ● 検出 ● アクションアイテム ● 教訓 ○ うまくいったこと ○ うまくいかなかったこと ○ 幸運だったこと ● タイムライン ● 参考情報監視範囲と粒度の見直しに役立つ

Slide 78

Slide 78 text

記入項目例 ● 作成者 ● ステータス ● サマリ ● インパクト ● 根本原因 ● 発生要因 ● 対応 ● 検出 ● アクションアイテム ● 教訓 ○ うまくいったこと ○ うまくいかなかったこと ○ 幸運だったこと ● タイムライン ● 参考情報もし◯◯だったら・・・も含め、対策を考慮ヒヤリハットの発想の仕方

Slide 79

Slide 79 text

失敗を責めない文化を維持する ● 当然、Postmortem は、人を批判するためのものではない ● 維持するためには「常日頃の関係性」に勝るものはない ○ 今後OnCall 要員になるメンバーに、心がけとしてドキュメントでの共有も最近はじめた ■ →詳細は [後半] で

Slide 80

Slide 80 text

前半終了

Slide 81

Slide 81 text

前半まとめ 1. まずは、運用をチームで回すためにドキュメントを整備した（SRE 以前の問題） 2. SRE 定着までにやったことは、サービス信頼性階層を下から積み上げた 3. SRE 本から、Postmortem 文化を導入したり、 Monitoring の設計を学び業務に取り入れたりした