SRE大全 スタディスト編 前半 #hbstudy 85 / SRE Taizen Studist 1

C0479b152c326746e911be790617f75b?s=47 katsuhisa_
October 31, 2018

SRE大全 スタディスト編 前半 #hbstudy 85 / SRE Taizen Studist 1

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

C0479b152c326746e911be790617f75b?s=128

katsuhisa_

October 31, 2018
Tweet

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. マニュアル作成・共有プラットフォーム

  6. None
  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 とは何か

  17. None
  18. None
  19. None
  20. None
  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前夜にやったこと • 運用に関わるドキュメントを整備した ◦ 後々、運用者を増やす際に役立った • 目の前のタスクをこなす時間と 学習時間の比率を変えた ◦ 学習時間を増やした

    ◦ いろんな学習が結びつかず断片的な知識
  36. None
  37. SRE0→1: 2017/8〜2018/1 • 技術顧問として、ex-Cybozu 萩原さんが入社 ◦ SREやっていき • この頃、SRE 本の日本語訳が発売された

  38. SRE0→1 やったこと • Monitoring 基盤整備 ◦ ダッシュボード構築 ◦ アラート再設計、監視項目追加 •

    OnCall ワンオペからの脱却 • ポストモーテムを書く文化の共有
  39. None
  40. Site Reliability Engineering

  41. None
  42. SRE1→10: 2018/1〜2018/9 • 障害発生頻度が低減 • より、SRE らしい仕事へ ◦ インフラのコードを書く時間の確保 ◦

    AWS Lambda で運用省力化 ◦ 性能向上のための実装 ▪ bulk insert 化
  43. SRE1→10 やったこと • 管理しているサーバーのインフラコード化 が 一通り完了 • サービスのパフォーマンスに向き合うWG の発足

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

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

  48. None
  49. None
  50. None
  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 の設計を学び業務に取り入れたりした