プロダクトを支えるSREの存在意義と役割 / Significance and role of SRE

C0479b152c326746e911be790617f75b?s=47 katsuhisa_
December 15, 2018

プロダクトを支えるSREの存在意義と役割 / Significance and role of 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

C0479b152c326746e911be790617f75b?s=128

katsuhisa_

December 15, 2018
Tweet

Transcript

  1. 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
  2. 3.

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

    @ Studist Corporation • Organizer of SRE Lounge / Rails Developers Meetup • Linux カーネルと同い年
  3. 5.
  4. 10.

    SRE ? • Google の運用チームを率いていた Ben Treynor 提唱 ◦ SREは、ソフトウェアエンジニアに

    運用チームの設計を依頼した時にできあがるもの • class SRE implements DevOps ◦ それ以外の役割も担う ◦ 「それ以外」の中身は各社で異なる
  5. 14.

    間接的なコスト • Dev とOps で利害関係の対立が起きやすい ◦ Dev: 「Agility」を求める ◦ Ops:

    「Stability」を求める • はやく機能開発してリリースしたいDev VS. とにかく安定して運用したいOps
  6. 17.

    VS. 間接的なコスト →共通目標でDevとOpsの利害関係を解消 • SLO (Service Level Objective ) を運用

    ◦ サービスレベルを維持できている限りは、 機能開発速度を維持する ◦ サービスレベルを維持できなさそうであれば、 bug fix や、性能の問題解決に注力する • サービスレベルは、後ほど詳細説明します
  7. 22.

    サービスレベルに関する用語 • SLI (Service Level Indicator) ◦ サービスレベルの具体的な指標 • SLA

    (Service Level Agreement) ◦ サービスレベルに関する顧客との合意 • SLO (Service Level Objective) ◦ サービスレベルに関する目標 ◦ 主にチーム内で運用
  8. 24.

    サービスレベルは何を測ればよい? • 可用性 ◦ 一定タイムウィンドウ内でのエラーを集計 ◦ エラーレートが一定値を越えれば、 そのウィンドウをダウンタイムとして計測 ◦ ダウンタイムが一定時間継続すれば障害とみなす

    ▪ リクエストが一定数以下の場合、未計測とする • レイテンシ ◦ 一定タイムウィンドウ内でのレイテンシを集計 ◦ レイテンシの 99%tile を計測 測定しやすいものから始めるとよい e.g. エラーリクエスト / 全リクエスト
  9. 25.

    サービスレベルは何を測ればよい? • 可用性 ◦ 一定タイムウィンドウ内でのエラーを集計 ◦ エラーレートが一定値を越えれば、 そのウィンドウをダウンタイムとして計測 ◦ ダウンタイムが一定時間継続すれば障害とみなす

    ▪ リクエストが一定数以下の場合、未計測とする • レイテンシ ◦ 一定タイムウィンドウ内でのレイテンシを集計 ◦ レイテンシの 99%tile を計測 マルチテナンシーなサービスの場合 顧客ごとに集計できると、より良い
  10. 29.

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

    Stackdriver Stream SQL を使った リアルタイム計測基盤 時間軸方向に対して 無限のデータ →どこかで時間を区切る
  11. 30.

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

    Stackdriver 集計とアラートを分離 測定方法を後から変更しても 過去の推移を再計測できる
  12. 31.
  13. 34.

    Run Book • SOM ( Systems Operation Manual ) のこと

    • 記載項目の例 ◦ フェイルオーバーの手順 ◦ パッチの適用 ◦ トラブルシューティングの一般的な流れ
  14. 35.

    スタディストでのRun Book • 自動化されていない処理に関するSOM の ドキュメント作成はマスト ◦ GUI 操作を行う場合は、 自社サービス(Teachme

    Biz )でマニュアル作成 ▪ Excelにスクショぺたぺたをしなくて済む ◦ 障害対応時の心得などは、 社内ドキュメントを公開している
  15. 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
  16. 40.

    スタディストでのアラート疲労対策 • Slack Channel 通知先を分ける ◦ emergency ( 書き込まれると常に関係者にプッシュ通知 )

    ◦ info ( 必要なタイミングで対応 ) • アラートロジックは、要修正であれば即修正 • 後述するポストモーテムを運用し、 問題は1つずつ確実に対処
  17. 41.

    スタディストでのアラート疲労対策 • Slack Channel 通知先を分ける ◦ emergency ( 書き込まれると常に関係者にプッシュ通知 )

    ◦ info ( 必要なタイミングで対応 ) • アラートロジックは、要修正であれば即修正 • 後述するポストモーテムを運用し、 問題は1つずつ確実に対処 運用者の人数が増えれば、 インシデントレスポンスの専用ツール導入予定 e.g. PagerDuty
  18. 42.

    スタディストでのアラート疲労対策 • Slack Channel 通知先を分ける ◦ emergency ( 書き込まれると常に関係者にプッシュ通知 )

    ◦ info ( 必要なタイミングで対応 ) • アラートロジックは、要修正であれば即修正 • 後述するポストモーテムを運用し、 問題は1つずつ確実に対処 運用者の人数が増えれば、 インシデントレスポンスの専用ツール導入予定 e.g. PagerDuty エスカレーションロジックの 管理コストが高くなるため
  19. 44.

    スタディストのポストモーテム運用 • ポストモーテム読書会 ◦ 似た局面で同じ失敗を繰り返さないように • 社内向けに全公開 ◦ 他のチームの人からコメントをもらう •

    「幸運だったこと」を書くようにしている ◦ 今回はたまたまこの被害規模で済んだけど、 もし、この状況で、XXX だったら…を想像する ▪ ヒヤリハットの考え方
  20. 45.