SRE Meetup Tokyo
SRE Meetup Tokyo @ Google JP オフィス 20170925
こちらに参加してきたまとめです。
発表内容
- モニタリング結果に騙されるな
- SLOのすすめ
- Managing Risk with Error Budgets
1.モニタリング結果に騙されるな
by @tsekine
The Many Ways Your Monitoring Is Lying To You
時系列ベースのモニタリング
- モニタリングは2種類
- white box monitoring
- black box monitoring
- サーバが自分で収集
- モニタリングサーバはなるべく生の情報を取る
- そのあとにデータを加工する
欠落したデータ
- 全体のリクエストは変わらないが、1分あたりの平均は変わってしまう
- 平均の変化は必ずしも実際にそいとはk切らない
粒度(モニタリング問題)
- スケールすると、無駄にデータとってたら無駄に
どこで監視するか
- clientとserver間でネットワークに障害があった場合
- クライアントとサーバをモニタリングからは見れても無理な場合もある
- black box monitoringも必要になる
複数のデータソース
- 時系列を揃える
グラフ
- y軸の設定に騙されない
2.SLOのすすめ
by @SawadaTakeo
- SREの原則
- 4章 サービスレベル目標
- 5章 トイルの領域
SLOとは
- あるサービスの信頼性についての数値目標
- メリット
SLOの定義のしかた
- SLIにするメトリクスを決める
- 目標を決める
具体的な決め方
- SLIの選び方
- SLIをモニターする
- SLOの定義の色々
- SLOを達成できなかったら?
- リリースをフリーズ
- 障害の多くは変更に付随して発生する
- 信頼性に関する改善の優先順位を上げる
- 目標そのものを見直す
- リリースをフリーズ
- Public SLAへ
- 外部に公開するSLAはプロダクトデザインレベルの選択になる
- SREが技術的な判断や情報を提供しつつ、開発者、PMと議論する
トイル
トイルとは
- プロダクションサービスを動作させることに関係する作業で、
- 手作業で行うつまらないルーチンてきなもの
トイルの例
- リリース作業
- 手作業のテスト
- バックアップ作業
- データベースのクリーンアップ
- VMのセットアップ、追加、削除
- アラート、障害対応
- トイルが多すぎると
- トイルの削減: オンコール対応の例
- 行っている作業を見直し、地道に自動化、改善していくしかない
- 週に数十以上アラートが発生して、多大なオンコール対応負荷が生じていた
- 対応
- 毎週プロダクションミーティングを開催
- その週におきた全てのアラートをその対応をレビュー
- 重大な障害にはポストモーテムを書き、その後ポストモーテムレビューを実施
- 場当たり的な修正を変えて
- 根本原因の修正
- 他チームのバグの積極的な修正依頼
- プレイバック(手順書)の強化
- 不要なアラートの見直し
- 数ヶ月の取り組みで1/5程度に
- 行っている作業を見直し、地道に自動化、改善していくしかない
3.Managing Risk with Error Budgets
エラーバジェットによるリスク管理
by Paul Newson
One of the most important concepts in the SRE philosophy is the Error Budget. This talk will discuss how an error budget can help you delight your customers by managing risk in a principled way, striking the right balance between risk and velocity, while keeping your development and operations teams healthy.
開発の目的
- 開発の目的
- 新しい機能を提供する
- SREの目的
- 信頼性
- 会社の目的
- 新しい機能を確実に提供する
- SLOを明確に定義する必要がある
エラーバジェット
- 定義:error budget = 1 - uptime
- エラーバジェット管理
- この機能をデプロイすべきか
- 変更をどのようなスピードでデプロイすべきか
- 冗長性をもっと高めるべきか
- テストを追加実装すべきか
- 機能を開発すべきか、信頼性を高めるべきか