Gremlinが公開しているサービスの信頼性をランク付けするツールを使ってみる

GremlinのメルマガでCalculate the reliability of your servicesというタイトルのメールが来まして、 中を見たところ 各サービスの全体的な信頼性をランク付けするのに役立つ信頼性計算ツールを作ったからやってみてね　という内容でした。 興味深いなと思ったので試してみます。

どういうツールかというと、

9つの簡単な質問に答えると、信頼性の向上に役立つ、パーソナライズされた実用的な推奨事項が送信される

というものです。

信頼性というのは、故障/障害の発生しにくさ、安定性を表す指標 と考えて良いかと思います。

信頼性の向上を目指すチームからよく聞かれる質問の1つは、「どこから始めればよいのか」 というのがあり、この質問に対する答えとしてこのツールを使用すると何をしなければいけないかがわかる/ヒントになるものとなっています。

質問内容

1.Think about one of your services

サービスの重要度について。

サービスが保持される基準を測定します。 簡単に言えば、顧客向けのミッションクリティカルなサービスには、内部サービスとは異なる信頼性要件があります。

Tier 1からTier ３までの選択肢があります。 １が最も重要度が高いもの。

2.What is the mean time between failure (MTBF) for this service?

平均故障間隔（MTBF）。時間単位で入力します。

平均故障間隔（MTBF）は、特定のサービスのインシデント間の平均時間です。

3.What is the mean time to recover (MTTR) for this service?

平均修復時間（MTTR）。時間単位で入力します。

平均修復時間（MTTR）は、システムが通常の動作に戻るまでにかかる時間を表します.

※ MTTRは、インシデントが検出されたときではなく、インシデントがいつ開始したかを考慮する

4.What is your availability service-level objective (SLO)?

可用性サービスレベル目標（SLO)の設定値。

サービスレベル目標（SLO）は、特定の主要業績評価指標（KPI）について合意された目標で、SLOは、サービスの実行方法に関する内部の期待を確立します。

可用性SLOは、サービスが利用可能になることを目指している時間の割合を指します（99.999%, 99.95%など)

5.Do you currently have an incident management or disaster recovery plan in place?

インシデント管理(IMまたは災害復旧計画(DRP)を実施しているかどうか。

インシデント管理: インシデントを検出して軽減するために実行される一連の手順

災害復旧計画: 災害などによる被害からの回復措置、あるいは被害を最小限に抑えるための文書化された特定の手順

6.Have you established error budgets ?

エラーバジェットを確立しているかどうか？

エラーバジェットは、サービスのSLOと測定された実際の稼働時間の差を表します。

たとえば、サービスAの月の可用性SLOが99.999％ならば、サービスのエラーバジェットがその月の0.001％のダウンタイム（25.92秒のダウンタイム）であることを意味します。 予算が残っている限り、通常のエンジニアリング作業を続けることができます。 予算を超えた場合は、システムの復元力を高めるために、追加のテスト、カオスエンジニアリング、および開発に作業を移す必要があります。

7.Do you currently have an on-call rotation that covers this service?

オンコールローテーションがあるかどうか。　24時間年中無休/営業時間のみ/ない　の中から選択。

8.Does this service have dedicated monitoring and alerting ?

サービス専用の監視とアラートがあるかどうか。

監視していてアラート閾値が存在/監視はしている/ない　の中から選択。

9.How often do you practice Chaos Engineering against this service ?

Chaos Engineeringの頻度。

Chaos Engineeringは、障害が発生した場合にシステムがどのように動作するかを学習するために、慎重に計画された実験を実行する方法です。

これらの実験は3つのステップに従います。

• 何か問題が発生したときにシステムがどのように動作するかについて仮説を立てます。
• システムでテストするために、可能な限り最小の実験を設計します。
• 各ステップで失敗の影響を測定し、成功または失敗の兆候を探します。

実験が終了すると、システムの実際の動作をよりよく理解できます。

結果

９つの質問に答えると、ランクが計算されて表示されます。

例：

完全なサマリーを取得するには、このページのフォームに必要な項目を入力して送信します。

推奨事項の完全なリストとスコアの計算方法

完全なサマリーを表示すると、

信頼性の向上に役立つ、パーソナライズされた実用的な推奨事項が表示されます。

例えば、

• MTBFを見積もる
• MTTRとMTTDを測定する
• インシデント対応手順を文書化してテストする
• Tier1サービスのエラーバジェットの設定を検討する
• IMOC(インシデント対応を管理するための明確な担当者（「コールリーダー」または「インシデントマネージャーオンコール」)を割り当て、オンコールローテーションを確立します
• オンコールローテーションを拡大する
• 最初のカオス実験を実行する

などです。 詳しい説明も書かれているので、実際に試して読んでみましょう。

計算方法に関しての説明も記載されています。

サービスの信頼性に最も大きく貢献すると思われる要素として 重要度、可用性、継続的なメンテナンス作業 に分けて計算しているようです。

• パート１: 重要度

重要度スコアは、1から3までの数値として表され、サービスの重要性、したがってサービスが保持される基準を測定します。簡単に言えば、顧客向けのミッションクリティカルなサービスには、内部サービスとは異なる信頼性要件があります。

• パート2: 可用性

可用性SLOをすでに設定しているチームの場合、このスコアは、単にそれらをどれだけうまく達成しているかの測定値です。ただし、これらのKPIの一部をまだ測定していないチームの場合、Tier 1サービスの5ナイン可用性SLO、Tier 2の4ナイン、Tier3の3ナインに対して可用性を計算します。パート2の出力は0から1までの数値です。

• パート3: 継続的なメンテナンス

パート3では、サービスを利用できるようにするためにあなたとあなたのチームが行うさまざまなことに対してポイントを蓄積します。たとえば、専用の監視を行うと0.10ポイントを獲得できますが、専用の監視とアラートを使用すると0.25ポイントを獲得できます。パート3の出力は、0から1までの数値です。

成績を計算するために、パート2とパート3のスコアを掛け合わせます。Tier 2サービスの場合、これに1.3の係数が掛けられます。Tier 3サービスの場合、パート2とパート3のスコアの積に1.7の係数が掛けられます。以下の範囲が最終成績を決定します。

※ スコアの範囲

おわりに

自分たちが持っているサービスの信頼性がどれくらいなのか実際に数値化されるので、信頼性の指標としての目安に使えてとても便利だと思います。 こういったことをした方がいいよという事項も出してくれるので、これから何を進めればいいか迷っている人の助けになりますね。

無料で提供されているので、まずはやってみましょう。 改善の役に立つと思います。

参考

• Gremlin
  • Gremlinシナリオを使用すると、停止を簡単に再現して、将来同様の障害に耐えられるようにすることができます。