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

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

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

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

No content

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

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

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

Site Reliability Engineering

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

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

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

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

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

SRE のアプローチ

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

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

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

SRE のプラクティス

▶　サービスレベル ▶　OnCall

サービスレベル

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

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

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

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

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

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

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

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

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

OnCall

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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