Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

katsuhisa_
October 31, 2018

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

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

katsuhisa_

October 31, 2018
Tweet

More Decks by katsuhisa_

Other Decks in Technology

Transcript

  1. • Katsuhisa Kitano / 北野 勝久 • @katsuhisa__ • SRE

    @ Studist Corporation • Organizer of SRE Lounge / Rails Developers Meetup • Linux カーネルと同い年
  2. SRE大全: スタディスト編 [前半] 2018/10/31 hbstudy#85 @katsuhisa__ / Katsuhisa kitano Copyright

    (C) 2018 Studist Corporation. All Rights Reserved \ あらためて /
  3. Ops の責務の例 • 安定稼働 ◦ 異常時の検知と対応 • リリースパイプライン • 環境構築と運用

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

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

    ◦ インフラ構築と運用 ▪ ミドルウェアのセットアップ ▪ OS のセキュリティパッチ適用 そこで・・・
  6. チーム • SRE はDevOps を実装する役割 ”も” 担う • class SRE

    implements DevOps • DevOps 4本柱のうち 2つは、 コラボレーションとアフィニティ by 『Effective DevOps』
  7. 非機能要求グレード6つの大項目 • 可用性 • 性能・拡張性 • 運用・保守性 • 移行性 •

    セキュリティ • 環境・エコロジー SRE の責務を理解するのに便利な箱
  8. 自分自身のこと • 2016/8: スタディスト入社 ◦ サーバーサイドエンジニア • 2017/1〜4: 運用の引き継ぎ ◦

    サーバーサイドエンジニア + サービス運用 • 2017/8: SRE としてのマインドチェンジ • 2018/9: SRE チームが組織図に反映され、 マネージャー職に ようやくSRE の専任に
  9. 信頼性のはかりかた • 何をはかる? ◦ Golden Signals ▪ latency ▪ error

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

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

    ▪ traffic ▪ saturation • saturation を事前に見極めるためには、 負荷試験環境の整備と継続実施が必要 アプリケーション特性によっては 他に注視すべきMonitoring 項目も
  12. [WIP] SLI 計測システム アクセスログ Kinesis Stream S3 Athena Kinesis Analytics

    Lambda 1 2 4 3 5 6 Stackdriver 柔軟にメンテできるように自前実装 アラートと集計処理を分離
  13. 信頼性を共有する • ダッシュボード • 監視結果通知 ◦ アラート ◦ チケット •

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

    スタディストで利用しているツール群 ◦ Elasticsearch/Kibana, Stackdriver, Stackdriver Error Reporting, CloudWatch, NewRelic 「メールで受信」「Slackに共有」を併用 監視通知の冗長化
  15. ストレスを減らすために • 後述するポストモーテムを書き、 問題をチームに共有することで 確実にClose する ◦ 自動復旧 or 根本原因撲滅

    or 事前検知導入 • 対処方法が不明瞭な問題が頻発すると ストレスが非常に高い(過去の経験談)
  16. 記入項目例 • 作成者 • ステータス • サマリ • インパクト •

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

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

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

    根本原因 • 発生要因 • 対応 • 検出 • アクションアイテム • 教訓 ◦ うまくいったこと ◦ うまくいかなかったこと ◦ 幸運だったこと • タイムライン • 参考情報 もし◯◯だったら・・・ も含め、対策を考慮 ヒヤリハットの発想の仕方