プロダクトを支えるSREの存在意義と役割

2018/12/15 に開催されたDevelopers Boost での招待講演の資料です。
https://event.shoeisha.jp/devboost/20181215/session/1892/

SREの存在意義や役割について話しました。
過去にもSREについては色々とお話しているので、よければあわせてご覧ください！
・最高のITエンジニアリングを支える守りと攻めの「設計技術」と「SRE」
https://speakerdeck.com/katsuhisa91/zui-gao-falseitenziniaringuwozhi-erushou-ritogong-mefalse-she-ji-ji-shu-to-sre
・SRE大全 スタディスト編 前半 #hbstudy 85 / SRE Taizen Studist 1
https://speakerdeck.com/katsuhisa91/sre-taizen-studist-1
・SRE大全 スタディスト編 後半 #hbstudy 85 / SRE Taizen Studist 2
https://speakerdeck.com/katsuhisa91/sre-taizen-studist-2

Transcript

1. Copyright (C) 2018 Studist Corporation. All Rights Reserved
   プロダクトを支えるSREの存在意義と役割
   #devboost
   2018/12/15 Developers Boost 招待講演
   @katsuhisa__ / Katsuhisa Kitano
   Copyright (C) 2018 Studist Corporation. All Rights Reserved
   

   View Slide

2. Copyright (C) 2018 Studist Corporation. All Rights Reserved
   #devboost
   

   View Slide

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

   View Slide

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

   View Slide

5. View Slide

6. サービスの運用に関わっている人？
   

   View Slide

7. SRE をやっている/関わっている人？
   

   View Slide

8. 今日のテーマ
   SRE の存在意義・役割への理解を通じ、
   運用業務に役立つ知見を持ち帰ってもらう
   

   View Slide

9. Site
   Reliability
   Engineering
   

   View Slide

10. SRE ?
    ● Google の運用チームを率いていた Ben Treynor 提唱
    ○ SREは、ソフトウェアエンジニアに
    運用チームの設計を依頼した時にできあがるもの
    ● class SRE implements DevOps
    ○ それ以外の役割も担う
    ○ 「それ以外」の中身は各社で異なる
    

    View Slide

11. SREが登場した背景
    〜従来型システム運用の問題〜
    

    View Slide

12. ▶　直接的なコスト
    ▶　間接的なコスト
    

    View Slide

13. 直接的なコスト
    ● 従来型のシステム運用では、
    人の手による問題解決に依存しがち
    ○ コードを書くことに対し、手作業が増えやすい傾向
    ■ デプロイ
    ■ ミドルウェアのconfig ファイルの変更
    ■ 障害対応
    ● サービスの拡大に伴い、運用コストが線形増加
    

    View Slide

14. 間接的なコスト
    ● Dev とOps で利害関係の対立が起きやすい
    ○ Dev: 「Agility」を求める
    ○ Ops: 「Stability」を求める
    ● はやく機能開発してリリースしたいDev
    VS. とにかく安定して運用したいOps
    

    View Slide

15. SRE のアプローチ
    

    View Slide

16. VS. 直接的なコスト
    →運用をソフトウェアの問題として扱う
    ● ソフトウェアでの自動化・効率化を推進する
    ○ サービス規模が拡大しても、
    運用コストの線形増加を防ぐ
    ● e.g.
    ○ 障害時に自動復旧（Self-Healing）
    ○ デプロイ自動化
    ○ モニタリングにより 問題と原因を把握する
    

    View Slide

17. VS. 間接的なコスト
    →共通目標でDevとOpsの利害関係を解消
    ● SLO (Service Level Objective ) を運用
    ○ サービスレベルを維持できている限りは、
    機能開発速度を維持する
    ○ サービスレベルを維持できなさそうであれば、
    bug fix や、性能の問題解決に注力する
    ● サービスレベルは、後ほど詳細説明します
    

    View Slide

18. 詳しくは・・・
    私がCodeZineさんに
    寄稿している
    SREの連載をぜひ！
    https://codezine.jp/article/detail/11002
    

    View Slide

19. SRE のプラクティス
    

    View Slide

20. ▶　サービスレベル
    ▶　OnCall
    

    View Slide

21. サービスレベル
    

    View Slide

22. サービスレベルに関する用語
    ● SLI (Service Level Indicator)
    ○ サービスレベルの具体的な指標
    ● SLA (Service Level Agreement)
    ○ サービスレベルに関する顧客との合意
    ● SLO (Service Level Objective)
    ○ サービスレベルに関する目標
    ○ 主にチーム内で運用
    

    View Slide

23. サービスレベルは何を測ればよい？
    ● 可用性
    ○ 一定タイムウィンドウ内でのエラーを集計
    ○ エラーレートが一定値を越えれば、
    そのウィンドウをダウンタイムとして計測
    ○ ダウンタイムが一定時間継続すれば障害とみなす
    ■ リクエストが一定数以下の場合、未計測とする
    ● レイテンシ
    ○ 一定タイムウィンドウ内でのレイテンシを集計
    ○ レイテンシの 99%tile を計測
    

    View Slide

24. サービスレベルは何を測ればよい？
    ● 可用性
    ○ 一定タイムウィンドウ内でのエラーを集計
    ○ エラーレートが一定値を越えれば、
    そのウィンドウをダウンタイムとして計測
    ○ ダウンタイムが一定時間継続すれば障害とみなす
    ■ リクエストが一定数以下の場合、未計測とする
    ● レイテンシ
    ○ 一定タイムウィンドウ内でのレイテンシを集計
    ○ レイテンシの 99%tile を計測
    測定しやすいものから始めるとよい
    e.g. エラーリクエスト / 全リクエスト
    

    View Slide

25. サービスレベルは何を測ればよい？
    ● 可用性
    ○ 一定タイムウィンドウ内でのエラーを集計
    ○ エラーレートが一定値を越えれば、
    そのウィンドウをダウンタイムとして計測
    ○ ダウンタイムが一定時間継続すれば障害とみなす
    ■ リクエストが一定数以下の場合、未計測とする
    ● レイテンシ
    ○ 一定タイムウィンドウ内でのレイテンシを集計
    ○ レイテンシの 99%tile を計測
    マルチテナンシーなサービスの場合
    顧客ごとに集計できると、より良い
    

    View Slide

26. https://royal.pingdom.com/2009/03/24/a-handy-uptime-and-downtime-conversion-cheat-sheet/
    可用性については、
    ダウンタイムを参考にすると
    どれくらいのサービスレベルかを
    意識しやすい
    

    View Slide

27. Google App Engine のSLA 定義
    https://cloud.google.com/appengine/sla
    

    View Slide

28. スタディストでのSLI 計測システム
    アクセスログ Kinesis Stream S3 Athena
    Kinesis Analytics Lambda
    Stackdriver
    

    View Slide

29. スタディストでのSLI 計測システム
    アクセスログ Kinesis Stream S3 Athena
    Kinesis Analytics Lambda
    Stackdriver
    Stream SQL を使った
    リアルタイム計測基盤
    時間軸方向に対して
    無限のデータ
    →どこかで時間を区切る
    

    View Slide

30. スタディストでのSLI 計測システム
    アクセスログ Kinesis Stream S3 Athena
    Kinesis Analytics Lambda
    Stackdriver
    集計とアラートを分離
    測定方法を後から変更しても
    過去の推移を再計測できる
    

    View Slide

31. OnCall
    

    View Slide

32. OnCall
    → 障害対応など、呼び出しへの対応
    

    View Slide

33. OnCallに関するSREのプラクティス
    ● Run Book
    ● アラート疲労をへらす
    ● Postmortem
    

    View Slide

34. Run Book
    ● SOM ( Systems Operation Manual ) のこと
    ● 記載項目の例
    ○ フェイルオーバーの手順
    ○ パッチの適用
    ○ トラブルシューティングの一般的な流れ
    

    View Slide

35. スタディストでのRun Book
    ● 自動化されていない処理に関するSOM の
    ドキュメント作成はマスト
    ○ GUI 操作を行う場合は、
    自社サービス（Teachme Biz ）でマニュアル作成
    ■ Excelにスクショぺたぺたをしなくて済む
    ○ 障害対応時の心得などは、
    社内ドキュメントを公開している
    

    View Slide

36. Run Book はテンプレが
    世の中にたくさん存在
    → 活用しよう
    https://github.com/SkeltonThatcher/run-book-template
    

    View Slide

37. アラート疲労を減らす
    ● OnCallが頻繁だと注意力が低下する
    ○ 感度が低下すると、
    重要なアラートの見落としが発生する
    ● アラート疲労を減らすために
    ○ モニタリングアウトプットの分類を意識する
    ○ 優れたアラートロジック/エスカレーションポリシー
    ○ 1つ1つ問題を確実に対処する
    

    View Slide

38. モニタリングのアウトプット分類は3つ
    

    View Slide

39. There are
    alerts, which say a human must take action right now. Something
    that is happening or about to happen, that a human needs to take action
    immediately to improve the situation.
    The second category is
    tickets. A human needs to take action, but not
    immediately. You have maybe hours, typically, days, but some human action is
    required.
    The third category is
    logging. No one ever needs to look at this
    information, but it is available for diagnostic or forensic purposes. The
    expectation is that no one reads it.
    What is ‘Site Reliability Engineering’?
    https://landing.google.com/sre/interview/ben-treynor.html
    

    View Slide

40. スタディストでのアラート疲労対策
    ● Slack Channel 通知先を分ける
    ○ emergency ( 書き込まれると常に関係者にプッシュ通知 )
    ○ info ( 必要なタイミングで対応 )
    ● アラートロジックは、要修正であれば即修正
    ● 後述するポストモーテムを運用し、
    問題は1つずつ確実に対処
    

    View Slide

41. スタディストでのアラート疲労対策
    ● Slack Channel 通知先を分ける
    ○ emergency ( 書き込まれると常に関係者にプッシュ通知 )
    ○ info ( 必要なタイミングで対応 )
    ● アラートロジックは、要修正であれば即修正
    ● 後述するポストモーテムを運用し、
    問題は1つずつ確実に対処
    運用者の人数が増えれば、
    インシデントレスポンスの専用ツール導入予定
    e.g. PagerDuty
    

    View Slide

42. スタディストでのアラート疲労対策
    ● Slack Channel 通知先を分ける
    ○ emergency ( 書き込まれると常に関係者にプッシュ通知 )
    ○ info ( 必要なタイミングで対応 )
    ● アラートロジックは、要修正であれば即修正
    ● 後述するポストモーテムを運用し、
    問題は1つずつ確実に対処
    運用者の人数が増えれば、
    インシデントレスポンスの専用ツール導入予定
    e.g. PagerDuty
    エスカレーションロジックの
    管理コストが高くなるため
    

    View Slide

43. ポストモーテム
    ● 障害振り返りドキュメント
    ● 人を非難するためのものではない
    ● SREにとって障害復旧完了は、仕事の半分
    ○ 詳細な原因究明と、
    再発防止をエンジニアリングで行うまでがSREの仕事
    

    View Slide

44. スタディストのポストモーテム運用
    ● ポストモーテム読書会
    ○ 似た局面で同じ失敗を繰り返さないように
    ● 社内向けに全公開
    ○ 他のチームの人からコメントをもらう
    ● 「幸運だったこと」を書くようにしている
    ○ 今回はたまたまこの被害規模で済んだけど、
    もし、この状況で、XXX だったら…を想像する
    ■ ヒヤリハットの考え方
    

    View Slide

45. まとめ
    

    View Slide

46. まとめ
    ● SREは、サービス運用を
    ソフトウェアの問題として取扱う
    ● SREの考え方を適用することで、
    より信頼性の高い運用ができる
    ○ エンジニアリングでの問題解決を基本としつつも、
    それに留まらない幅広いプラクティスが共有されている
    

    View Slide

47. ウェブオペレーションは
    技芸であり科学ではない
    

    View Slide

48. SRE に決まった答えはない
    ぜひ皆さんなりのSRE を！
    おわり
    

    View Slide