$30 off During Our Annual Pro Sale. View Details »

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

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

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

katsuhisa_
PRO

October 31, 2018
Tweet

More Decks by katsuhisa_

Other Decks in Technology

Transcript

  1. SRE大全: スタディスト編 [前半]
    2018/10/31 hbstudy#85
    @katsuhisa__ / Katsuhisa Kitano
    Copyright (C) 2018 Studist Corporation. All Rights Reserved

    View Slide

  2. #hbstudy

    View Slide

  3. 最後に質疑応答の時間
    あります!

    View Slide

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

    View Slide

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

    View Slide

  6. View Slide

  7. 2016年
    3
    2018年
    18
    開発チーム

    View Slide

  8. 2016年

    千ユーザー増
    2018年

    万ユーザー増
    月間ユーザー増加ペース

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  15. SRE大全: スタディスト編 [前半]
    2018/10/31 hbstudy#85
    @katsuhisa__ / Katsuhisa kitano
    Copyright (C) 2018 Studist Corporation. All Rights Reserved
    \ あらためて /

    View Slide

  16. SRE とは何か

    View Slide

  17. View Slide

  18. View Slide

  19. View Slide

  20. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  25. 自分なりのSRE の解釈

    View Slide

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

    View Slide

  27. ソフトウェアはともかく・・・
    チーム?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  33. スタディストSRE の歴史

    View Slide

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

    View Slide

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

    View Slide

  36. View Slide

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

    View Slide

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

    View Slide

  39. View Slide

  40. Site
    Reliability
    Engineering

    View Slide

  41. View Slide

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

    View Slide

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

    View Slide

  44. View Slide

  45. View Slide

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

    View Slide

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

    View Slide

  48. View Slide

  49. View Slide

  50. View Slide

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

    View Slide

  52. サービス信頼性階層

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  56. 事例紹介

    View Slide

  57. ▶ Monitoring
    ▶ OnCall
    ▶ Postmortem

    View Slide

  58. Monitoring

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  70. OnCall

    View Slide

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

    View Slide

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

    View Slide

  73. Postmortem

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  80. 前半終了

    View Slide

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

    View Slide