Sansan Advent Calander 2018 の4日目の記事です。
adventar.org
先日参加させてもらったre:Invent、超たのしかったっす。
VIDEO www.youtube.com
拙い翻訳で心苦しい限りですが、何かしらの気付きになれば幸いです。
本人より許可いただいています。 Thank You so much.
SREとは何か
新しいものだから定義は変化し続ける。
これはSRE？
終わりのない火事場？なりやまないオンコール？トイルへの対応？
これらは症状であり、この病気に苦しんでいるのなら治癒する必要がある。
Devopsとは？
SREは、すべてではないにしても、devopsのオペレーション、及び文化上の要素を満たすことができる
SRE本にもあるように、SREはdevopsの実装の一つであると言われている。
Key SRE insight #1
計測し、人、組織、システムを改善する
SREはシステムだけを見るのではなく、インシデント発生時のプロセス、あるいはそれから何を学ぶか、組織のプロセスを改善できるか等の側面からアプローチする必要がある。
Key SRE insight #2
受動的ではなく自発的に。トイルを見つけ出し、それを排除する
自宅に火事が起こったら燃え尽きるまで見ているなんてことはせず、消防士を呼ぶだろう。
受動的ではなく自発的に。これはとてもとても重要だ。
トイルとは？
Key SRE insight #3
組織的なフィードバック
例えばデータベースのパフォーマンスがよくない状況においてはデプロイを止めた方がいい時がある。トップダウン 、ボトムアップ の双方で意識されるべきことだ。
Set Early Expectations
SREは新しい概念なので、新しい用語が多くある。
Service Level Indicators
何をどう改善すればよいか？何もなければよくわからない。
作業を進めるときなどには優先度を設定するが、それはどのように設定されるのか、客観的な指標を持つべきである。
コアメトリクス
データは大量にあるかもしれないが、そのどれもが有用とは限らない。
Four Golden Signals
Four Golden Signalsとは以下のメトリクスである。
Latency
Traffic
Errors
Saturation
これらはどんなサービスにも適用できる普遍的な指標であると言える。
Latency
レイテンシー とはクライアントがWebサーバーからレスポンスを受け取るのにどれくらい時間がかかるのかを示すものであり、顧客の経験に直接的な影響がある。
ロードバランサー で計測するか、クライアント側でラウンドトリップを計測するか、あるいはサーバー側で計測するか、様々なオプションがあるだろう。
Traffic
トラフィック とは作業量、または試行回数を意味する。トラフィック はビジネスの価値、規模に大きく関係するが、大量のトラフィック に見舞われた時にシステムのどこかで落ちてしまうことがあるだろう。しきい値 を設定する必要がある。
Errors
成功したリクエス トと失敗したリクエス トの比率をターゲットとして設定するのは簡単だし、効果的だろう。サイバーマンデー で、新たな導線を敷き、大量の消費行動が行われたとして、エラーレートが50%であれば使い物にならなず、0.1%であればそれは良い数字であると言えるだろう。
複雑なシステムではエラーが発生するのは当然起こりうることであるから、ゴールはエラーを排除することではなく、エラーをどこまで許容するかを明確にすることである。
Saturation
TrafficとSaturationは何が違うのか？
Humans and the Four Golden Signals
Four Golden Signalsは人やチーム、組織にも適用することができる。
Latencyは、人々がブロッカーを待っている時間に例えることができる。
Trafficはそれより劇的で、スタックしているチケットの数として見ることができる。
Errorについては、人間は誰しも多かれ少なかれミスをする。
Saturationを人という観点から見たときには燃え尽き症候群 のようなものがイメージしやすいのではないだろうか。燃え尽き症候群 は大企業にとって大きな課題である。
Start, Then iterate
you can't finish something that you don't start
これらの課題に対するためには、まずはどこからか始めなければならない。
繰り返し、フィードバックを与え、得ることが重要だ。ここに魔法はない。
Spreadsheets are simple, right?
さて、システム、ならびに組織にSLIを適用するにはどうすればいいだろうか。
スプレッドシート はいいぞ(突然の金言)
サービスごとのFour Golden Signalをカラムに追加することから初めてはどうだろう。
SLIs: Defining "done"
システムやサービスにSLIを規定し、スプレッドシート を作成し、運用を開始したとする。
そのためには完了した状態を定義しておくとよいだろう。
まず第一に監視システムや、JIRAのチケットに完了したことを報告する。ドキュメンテーション を行う。
これは常に明確なドキュメントでなくてもよい。
ダッシュ ボードはあなたの友達だが、注意すべきだ。ダッシュ ボードには多くの情報があるはずだが、常に十分な情報があるわけではないので、翻弄されないようにした方がよい。
すでにSLI抵触に関するイテレーション が適切に回っている？それなら問題ない。
start somewhere, this is good place to start.
付け加えておくと、大きな障害を避けるためには予測をすることもとても重要だ。
Specification Documentation
SLIの抵触はCriticalな事態だ。
例えば、元々はELBでレイテンシー を計測していたが、やはりモバイルアプリのクライアント側で計測することが最適であるとして、メトリクスを変更したとしよう。
SLIの文化を構築するには仕様文書を作成することに非常に大きな価値がある。
First SLIs, then promises
あなたは顧客のために何を約束しますか？
でも恐れることはない。良いPM、良いSREはビジネスの価値を知り、問題解決の能力があり、あなたの問いかけに回答してくれるだろう。
なぜこのようなことをしなければならないのか。工数 、難解な問題は山積みだ。
でも答えは一つ、それは約束を守るためだ。
突然の書籍紹介
Thinking in Promises.http://shop.oreilly.com/product/0636920036289.do
(とてもいい本らしい)
Concerning Promises
promiseには2つのコンポーネント があり、この場合は人間と機械である。
それらは常に対等の責任を負う必要はないが、それらの組み合わせの意味を考えることが重要である。
それは例えばAPI であったり、メッセージキューであったりするかもしれない。
Promises Example
promiseは平易に、明確に明文化すると効果的だ。
promiseはSLIに組み込まれることもある。
例として以下のようなものである。
response within 50ms
error rate will be > 1%
on call 15min
Promise Enumration
各チームはpromiseを列挙したら公式化し、維持なければならない。
When Promises are Broken...
promiseが破られることは回避できない。
インシデントが発生したらどうする？
Post-Mortems
blameless post-mortem
data driven post-mortem
ポストモーテムには色々とあるが、重要なことは正しい計測、結果の分析、対処である。
Interpreting Incidents
ステークホルダー も交えて共通言語を決定しておくとスムーズに事が運ぶ。
また、言うまでもなく発生したインシデントは広く共有すべき。
Mesuring Incident Response
インシデントを定量 的、定性的に計測するとよいだろう。定量 的にはインシデントを検知した時間、着手開始時間、リカバリ ーするまでの時間など。
