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

#hbstudy 85 「SRE大全 スタディスト編」で登壇した際の資料（前半）です。
後半の資料はこちら。
https://speakerdeck.com/katsuhisa91/sre-taizen-studist-2

Transcript

1. SRE大全: スタディスト編 [前半] 2018/10/31 hbstudy#85 @katsuhisa__ / Katsuhisa Kitano Copyright (C) 2018 Studist Corporation. All Rights Reserved
2. #hbstudy
3. 最後に質疑応答の時間 あります！
4. • Katsuhisa Kitano / 北野 勝久 • @katsuhisa__ • SRE @ Studist Corporation • Organizer of SRE Lounge / Rails Developers Meetup • Linux カーネルと同い年
5. マニュアル作成・共有プラットフォーム
7. 2016年 3 2018年 18 開発チーム
8. 2016年 数 千ユーザー増 2018年 数 万ユーザー増 月間ユーザー増加ペース
9. グロースフェーズに差し掛かっている チームおよびプロダクト
10. SRE 大全 過去の登壇企業 • メルカリ • mixi • クックパッド • ユーザーベース
11. スタディストSRE の特色 • 歴史が浅いチーム • 少規模（現在 3人）
12. 自分が話せそうなこと • 0からのSRE 実践＆定着の経験 ◦ 何からはじめるか、何を変えるか • SRE チームのマネージャー職として 考えていることの共有 ◦ 採用やチームづくり 前半 後半
13. Agenda [前半] • SRE とは何かについての自分の解釈 • スタディストSRE の歴史 • サービス信頼性階層 ◦ 事例紹介 ▪ Monitoring ▪ OnCall ▪ Postmortem
14. Agenda [後半] • スキルマップ • SRE の採用と育成 ◦ SRE として大事な価値観 • スタディストSRE チームが目指す方向性
15. SRE大全: スタディスト編 [前半] 2018/10/31 hbstudy#85 @katsuhisa__ / Katsuhisa kitano Copyright (C) 2018 Studist Corporation. All Rights Reserved ＼ あらためて ／
16. SRE とは何か
21. Ops の責務の例 • 安定稼働 ◦ 異常時の検知と対応 • リリースパイプライン • 環境構築と運用 ◦ インフラ構築と運用 ▪ ミドルウェアのセットアップ ▪ OS のセキュリティパッチ適用
22. Ops の責務の例 • 安定稼働 ◦ 異常時の検知と対応 • リリースパイプライン • 環境構築と運用 ◦ インフラ構築と運用 ▪ ミドルウェアのセットアップ ▪ OS のセキュリティパッチ適用 一般的にコードを書くことに比べ、 手作業が多くなりがち
23. Ops の責務の例 • 安定稼働 ◦ 異常時の検知と対応 • リリースパイプライン • 環境構築と運用 ◦ インフラ構築と運用 ▪ ミドルウェアのセットアップ ▪ OS のセキュリティパッチ適用 そこで・・・
24. Ben Treynor の提唱する定義 • 「 SREは、ソフトウェアエンジニアに 　運用チームの設計を依頼したときにできあがるもの 」
25. 自分なりのSRE の解釈
26. 非機能要求を チームの力とソフトウェアで実装する
27. ソフトウェアはともかく・・・ チーム？
28. チーム • SRE はDevOps を実装する役割 ”も” 担う • class SRE implements DevOps • DevOps 4本柱のうち 2つは、 コラボレーションとアフィニティ by 『Effective DevOps』
29. 非機能要求グレード6つの大項目 • 可用性 • 性能・拡張性 • 運用・保守性 • 移行性 • セキュリティ • 環境・エコロジー
30. 非機能要求グレード6つの大項目 • 可用性 • 性能・拡張性 • 運用・保守性 • 移行性 • セキュリティ • 環境・エコロジー SRE の責務を理解するのに便利な箱
31. Agenda [前半] • SRE とは何かについての自分の解釈 • スタディストSRE の歴史 • サービス信頼性階層 ◦ 事例紹介 ▪ Monitoring ▪ OnCall ▪ Postmortem
32. 自分自身のこと • 2016/8: スタディスト入社 ◦ サーバーサイドエンジニア • 2017/1〜4: 運用の引き継ぎ ◦ サーバーサイドエンジニア + サービス運用 • 2017/8: SRE としてのマインドチェンジ • 2018/9: SRE チームが組織図に反映され、 マネージャー職に ようやくSRE の専任に
33. スタディストSRE の歴史
34. SRE前夜: 〜2017/8 • 従来型のシステム運用 ◦ 人間ががんばることで 問題を収束させることを繰り返す • ユーザー増加に伴い、障害増加傾向 ◦ モニタリング基盤が整っていないので、 障害調査に時間がかかる ◦ OnCallつらい
35. SRE前夜にやったこと • 運用に関わるドキュメントを整備した ◦ 後々、運用者を増やす際に役立った • 目の前のタスクをこなす時間と 学習時間の比率を変えた ◦ 学習時間を増やした ◦ いろんな学習が結びつかず断片的な知識
37. SRE0→1: 2017/8〜2018/1 • 技術顧問として、ex-Cybozu 萩原さんが入社 ◦ SREやっていき • この頃、SRE 本の日本語訳が発売された
38. SRE0→1 やったこと • Monitoring 基盤整備 ◦ ダッシュボード構築 ◦ アラート再設計、監視項目追加 • OnCall ワンオペからの脱却 • ポストモーテムを書く文化の共有
40. Site Reliability Engineering
42. SRE1→10: 2018/1〜2018/9 • 障害発生頻度が低減 • より、SRE らしい仕事へ ◦ インフラのコードを書く時間の確保 ◦ AWS Lambda で運用省力化 ◦ 性能向上のための実装 ▪ bulk insert 化
43. SRE1→10 やったこと • 管理しているサーバーのインフラコード化 が 一通り完了 • サービスのパフォーマンスに向き合うWG の発足
46. SRE10→？: 2018/9〜 • 組織図にSREチームが反映 • ようやくSRE のタスクに専任で作業できる人が • SRE本は、後続の二冊が発売される
47. SRE10→？やっていること • SRE チームとしての 開発プロセス・評価・Onboarding の設計や導入 • 哲学や思想、チームとして導入したいプロセスの ドキュメントをつくる
51. Agenda [前半] • SRE とは何かについての自分の解釈 • スタディストSRE の歴史 • サービス信頼性階層 ◦ 事例紹介 ▪ Monitoring ▪ OnCall ▪ Postmortem
52. サービス信頼性階層
53. サービス信頼性階層 https://landing.google.com/sre/sre-book/chapters/part3/#fig_part-practices_reliability-hierarchy
54. サービス信頼性階層 https://landing.google.com/sre/sre-book/chapters/part3/#fig_part-practices_reliability-hierarchy スタディストSRE も 階層を下から積み上げてきた
55. サービス信頼性階層 https://landing.google.com/sre/sre-book/chapters/part3/#fig_part-practices_reliability-hierarchy
56. 事例紹介
57. ▶　Monitoring ▶　OnCall ▶ Postmortem
58. Monitoring
59. Why Monitoring? 1. 信頼性をはかるため 2. 信頼性を共有するため
60. 信頼性のはかりかた • 何をはかる？ ◦ Golden Signals ▪ latency ▪ error ▪ traffic ▪ saturation • saturation を事前に見極めるためには、 負荷試験環境の整備と継続実施が必要
61. 信頼性のはかりかた • 何をはかる？ ◦ Golden Signals ▪ latency ▪ error ▪ traffic ▪ saturation • saturation を事前に見極めるためには、 負荷試験環境の整備と継続実施が必要 実際は、細かい監視項目が大量に存在 e.g. 各種OSメトリクス, Apdex ...
62. 信頼性のはかりかた • 何をはかる？ ◦ Golden Signals ▪ latency ▪ error ▪ traffic ▪ saturation • saturation を事前に見極めるためには、 負荷試験環境の整備と継続実施が必要 アプリケーション特性によっては 他に注視すべきMonitoring 項目も
63. はかりかたと運用方法の例 • 可用性 ◦ 一定タイムウィンドウ内でのエラーを集計 ◦ エラーレートが一定値を越えれば、 そのウィンドウをダウンタイムとして計測 ◦ ダウンタイムが一定時間継続すれば障害とみなす • レイテンシ ◦ 一定タイムウィンドウ内でのレイテンシを集計 ◦ レイテンシの 99%tile を計測
64. Google App Engine のSLA https://cloud.google.com/appengine/sla
65. [WIP] SLI 計測システム アクセスログ Kinesis Stream S3 Athena Kinesis Analytics Lambda 1 2 4 3 5 6 Stackdriver
66. [WIP] SLI 計測システム アクセスログ Kinesis Stream S3 Athena Kinesis Analytics Lambda 1 2 4 3 5 6 Stackdriver 柔軟にメンテできるように自前実装 アラートと集計処理を分離
67. 余談: Apdex の活用 http://apdex.org/apdexfaq.html 平均レスポンスタイムは、 一部の問題あるリクエストに 値が左右されやすい Apdex はべんり
68. 信頼性を共有する • ダッシュボード • 監視結果通知 ◦ アラート ◦ チケット • スタディストで利用しているツール群 ◦ Elasticsearch/Kibana, Stackdriver, Stackdriver Error Reporting, CloudWatch, NewRelic
69. 信頼性を共有する • ダッシュボード • 監視結果通知 ◦ アラート ◦ チケット • スタディストで利用しているツール群 ◦ Elasticsearch/Kibana, Stackdriver, Stackdriver Error Reporting, CloudWatch, NewRelic 「メールで受信」「Slackに共有」を併用 監視通知の冗長化
70. OnCall
71. 小規模チームでのOnCall • 前提: OnCall ローテーションを組めない ◦ 過去、OnCall要員は最大でも3人という規模感 • 休暇前に、対応可否を共有する ◦ ネットのつながらない場所に行かないか？
72. ストレスを減らすために • 後述するポストモーテムを書き、 問題をチームに共有することで 確実にClose する ◦ 自動復旧 or 根本原因撲滅 or 事前検知導入 • 対処方法が不明瞭な問題が頻発すると ストレスが非常に高い（過去の経験談）
73. Postmortem
74. Postmortem • 障害振り返り • 書く基準: 顧客影響の有無 ◦ 影響規模は関係ない • 書いたら、全体に共有 ◦ 常に誰でも見れるようにしておく ◦ 良いPostmortem は教育材料に
75. 記入項目例 • 作成者 • ステータス • サマリ • インパクト • 根本原因 • 発生要因 • 対応 • 検出 • アクションアイテム • 教訓 ◦ うまくいったこと ◦ うまくいかなかったこと ◦ 幸運だったこと • タイムライン • 参考情報
76. 記入項目例 • 作成者 • ステータス • サマリ • インパクト • 根本原因 • 発生要因 • 対応 • 検出 • アクションアイテム • 教訓 ◦ うまくいったこと ◦ うまくいかなかったこと ◦ 幸運だったこと • タイムライン • 参考情報 問題を正しく認識しないと 書けない（重要） 数字の曖昧さを意識
77. 記入項目例 • 作成者 • ステータス • サマリ • インパクト • 根本原因 • 発生要因 • 対応 • 検出 • アクションアイテム • 教訓 ◦ うまくいったこと ◦ うまくいかなかったこと ◦ 幸運だったこと • タイムライン • 参考情報 監視範囲と粒度の 見直しに役立つ
78. 記入項目例 • 作成者 • ステータス • サマリ • インパクト • 根本原因 • 発生要因 • 対応 • 検出 • アクションアイテム • 教訓 ◦ うまくいったこと ◦ うまくいかなかったこと ◦ 幸運だったこと • タイムライン • 参考情報 もし◯◯だったら・・・ も含め、対策を考慮 ヒヤリハットの発想の仕方
79. 失敗を責めない文化を維持する • 当然、Postmortem は、 人を批判するためのものではない • 維持するためには「常日頃の関係性」に 勝るものはない ◦ 今後OnCall 要員になるメンバーに、 心がけとしてドキュメントでの共有も最近はじめた ▪ →詳細は [後半] で
80. 前半終了
81. 前半まとめ 1. まずは、運用をチームで回すために ドキュメントを整備した（SRE 以前の問題） 2. SRE 定着までにやったことは、 サービス信頼性階層を下から積み上げた 3. SRE 本から、Postmortem 文化を導入したり、 Monitoring の設計を学び業務に取り入れたりした