7サイトと信頼性レッスン

GoogleとAmazonのような会社は、ある技術的問題に対するアプローチについて多くの素晴らしい内容を共有している.今年、インターンを発明しましたAmazon Builders' Library . これは、Amazonのアーキテクチャとソフトウェアの配信プロセスにかかるアプローチを議論する記事のコレクションです.同様に、Googleは彼らのサイト信頼性工学のレッスンの大きなコレクションを共有しましたfree SRE book .
このポストでは、これらの2つの大きなリソースから学ぶことができる7サイトの信頼性のレッスンを超える.

1警告をactionableにする
良い監視は、美術です.This chapter Google SREの本から効果的にあなたのシステムを監視するために必要なすべてのシングルストップです.なぜ、何を監視するのか.この章からの断片は実際に私たちの監視リポジトリのプルリクエストテンプレートです.何度も何度もモニターしたいと思っていたことをもう一度考えてみました.

When creating rules for monitoring and alerting, asking the following questions can help you avoid false positives and pager burnout:

- Does this rule detect an otherwise undetected condition that is urgent, actionable, and actively or imminently user-visible?
- Will I ever be able to ignore this alert, knowing it’s benign? When and why will I be able to ignore this alert, and how can I avoid 
  this scenario?
- Does this alert definitely indicate that users are being negatively affected? Are there detectable cases in which users aren’t being 
  negatively impacted, such as drained traffic or test deployments, that should be filtered out?
- Can I take action in response to this alert? Is that action urgent, or could it wait until morning? Could the action be safely 
  automated? Will that action be a long-term fix, or just a short-term workaround?
- Are other people getting paged for this issue, therefore rendering at least one of the pages unnecessary?

アラート疲労防止
警告の大量の取引は本当に課税されます.隣にcontext switching , すべてのアラートは、あなたが評価しなければならない新しい、そして、潜在的にストレスの多い状況です.警告の影響または原因を仮定し始めるか、しばしばトリガーする警告を無視するのは非常に一般的です.にGoogle SRE book chapter この場合、あまりにも多くのことについての非常に具体的な概念があります.

We’ve found that on average, dealing with the tasks involved in an on-call incident—root-cause analysis, remediation, and follow-up activities like writing a postmortem and fixing bugs—takes 6 hours. It follows that the maximum number of incidents per day is 2 per 12-hour on-call shift.

それに基づいて、彼らはほとんどの日はゼロインシデントを持っている必要があります.
私はそれが通過し、先月のすべてのアラートを分析するのは本当に良い運動だとわかった.あなたがそれを行うとき、あなたは頻繁に警告が頻繁にトリガされている非常に迅速に通知されます.また、特定のアラートは、常に水曜日の朝に起動するなど、現時点ではあまり明らかではないパターンを参照することがあります.これを行うし、あなたの警告の品質を向上させるために上記のチェックリストを使用してトリガされたアラートをチェックする.

3 .停止をシミュレートする
私は本当にデバッグと実践する方法として停電をシミュレートするアイデアが好きです.それはあなたのシステムが動作する方法についての詳細を学ぶための安全な方法です.これは、より良い以前の停電を理解するためのツールとして動作することができます何が難しいことは、同じ方法を破るために行うことができます.グーグルdoes Disaster Role Playing , オンボードツールとして、彼らのSREのグループ内のさまざまな経験レベルの間の知識を共有し、楽しい運動として.
次に、ロールプレイングの代わりに、いくつかの方法であなたの実際のシステムに失敗を注入することもできます.この実践は、失敗が何をもたらすのかという仮説と組み合わせると、カオス工学と呼ばれます.手動では、手動であなたのアプリケーションを考えることができる任意の方法で失敗することができます周りの多くのツールがあります.あなたが始めることを知りたいか、あなたがカオス工学権をすることができた方法について詳しく知るならば、私は読書を非常に推薦しますthese blog posts by Adrian Hornsby .

失敗に対する変更を防ぐ
それはあなたのシステムを“自己治癒”しようとする誘惑です.しかし、ほとんどの場合、失敗が進行中であるとき、自動化された変化は何が起こっているかを理解するのをより難しくします.多くの場合、自動変更は実際に事態を悪化させるかもしれません.一般的な例としては、クラスタ内のノードがドロップアウトした場合のデータの再分配や再配置がある.データ転送と負荷この原因は実際にノードが存在していないよりも大きな負の影響を持つ可能性があります.インフラストラクチャの冗長性を考えた場合、冗長インフラストラクチャが失敗した場合に何が起こるかについても考えてください.これは常に可能ではないが、理想的には、何も起こらない.
Amazonのエンジニアがどのように信頼性を向上させるためにアーキテクトシステムを作ったかを説明しました.そこに関連するアイデアがしばしば名前の下で参照されたStatic stability . AWS公開a nice article Amazonビルダーのライブラリでは、EC 2と他のAWSサービスにスタティックな安定性を適用する方法を説明しています.

5 .失敗した失敗を防ぐ
アプリケーションが失敗すると、これも他のアプリケーションをダウンさせてはいけません.カスケードの失敗を防ぐいくつかの方法があります.

遮断器の使用つまり、現在動作していないようであるなら、サービスの呼び出しを停止します.この方法では、要求に依存するサービスをオーバーロードしません.

用途smart retry strategies .

追加timeouts リクエストする.リクエストがオーバーロードされているアプリケーションが失敗した場合に一般的です.これは遅い要求を引き起こします.タイムアウトせずに、このアプリケーションに依存するすべてのサービスも遅くなります.

インフラストラクチャを剃る
シャッフルは、失敗の影響を減らすために別の本当に興味深い方法です.ほとんどの例では、これはアプリケーションの悪意のあるクライアントから保護する方法として使用されました.スタートとして、あなたのクライアントのカップルにグループをシャードすることができます.各シャードには、アプリケーションを実行している別のインフラストラクチャがあります.さて、悪意のあるクライアントがアプリケーションに影響を及ぼすとき、その同じシャードに割り当てられたクライアントだけが効果を見るでしょう.これは非常に単一の悪意のあるクライアントの影響を減らすことができます.
この1つのステップをさらに取るには、1つのクライアントの代わりに2つのシャードに置くことができます.今、悪意のあるクライアントは、2つの破片をもたらすことができます.しかし、正確に同じ2つの破片に割り当てられている他のクライアントの可能性はかなり小さいです.クライアントは彼らのシャードのうちの1つが失敗するのを見るでしょう、しかし、クライアントの大きいグループはまだ働いているシャードに戻ることができます.
このどれも意味がないならばread this blog post アマゾンビルダーの図書館から.それはどのように動作を説明し、可視化で優れた仕事をしています.

古いデータを受け入れる
ほとんどの場合、データよりも古いデータを表示する方が良いです.あなたは自分自身に失敗をマスクする必要はありませんが、多分あなたはあなたの顧客にそれらをマスクする必要があります.これを適用する明白な場所は、現在の結果をキャッシュしている場所です.あなたはどちらかをあなたにプッシュ結果を呼び出しているものを作る動的を変更することができます.または、あなたは少しよりスマートにキャッシュすることができます.

結論
うまくいけば、これらのヒントは、あなたのシステムをより信頼性の高い方法について考えるのに役立ちました.信頼性に関しては、本当に良い資源のトンがあります.私はすでにこのポストにカップルを共有し、それらをチェックしてください!
私はすべてのあなたの考えを聞くのが大好きだ!