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