アンチパターン＠SREing¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. アンチパターン集 (Dropbox)¶
はじめに¶
1. サイトリライアビリティオペレーション¶
▼ パターンの概要¶
今までのシステム運用 (例：NOC) をSREingと言い換えるだけの方法のこと。
▼ 問題点¶
- SREerの作業内容には、システム運用だけなく、開発も含まれる。またこの開発では、できるだけ人の手を離れていて、障害の発生頻度が少ないようなシステムを構築する必要がある。
-
NOCのような場所は、作業に集中できる環境ではない。
-
-
ヒーローパターンはアンチパターン。
- ヒーローパターンでは作業が属人化するため、チームが育たず、またドキュンメントが残らずに本人がいなくなってしまうことがある。
-
▼ 解決策¶
- 作業時間の最適化
- SREerは、勤務時間の半分以上を、システム運用ではなく開発に割り当てる。
- 作業場所の最適化
- NOCのように、24時間365日、システムのすぐそばでオンコール担当者がこれの面倒を見るのではなく、リモートでどこからでもすぐに対応可能にする。
- オンコール担当者がメトリクスの時系列データの共有リンクをインシデントに関心がある人に共有すれば、共通の視点でインシデントを見ることができる。
2. 画面を見つめる人間¶
▼ パターンの概要¶
- 自動検出されたエラーイベントからアラートを手動で作成すること。
- 作成した全てのアラートを通知し、手動でインシデントか否かを判断してしまうこと。
▼ 問題点¶
インシデントの解決作業のせいで、それ以外の業務に集中できない。
▼ 解決策¶
- アラート通知前の自動解決
- エラーイベントのアラートが作成された時、すぐにオンコール担当者に通知するのでなく、システムに自動的に解決する。
- KubernetesのlivenessProbe機能やNode停止時のPodの移動は、この自動的解決の
1個である。
- KubernetesのlivenessProbe機能やNode停止時のPodの移動は、この自動的解決の
- 通知後の自動タスク化
- 解決できなかったエラーイベントをインシデントか否か判断してタスク化する作業も自動化する。
3. 群衆によるインシデント対応¶
▼ パターンの概要¶
インシデントの担当者を無秩序に配置してしまうこと。
▼ 問題点¶
- 様々な仮説が入り混じり、むしろ解決が長引く。
- インシデントの解決作業のせいで、それ以外の業務に集中できない。
▼ 解決策¶
- インシデントが発生した時に、無秩序的ではなく、組織的に担当者を配置する。
- インシデントコマンドシステムを採用し、インシデントの対応の組織化する。
4. 根本原因 = ヒューマンエラー¶
▼ パターンの概要¶
ヒューマンエラーが、インシデントの根本原因 (ただ1個の原因) であると見なしてしまうこと。
▼ 問題点¶
ヒューマンエラーが根本原因だったとしても、人間には様々な状況が背景にあり、不正確な原因しか突き止められない。
▼ 解決策¶
- インシデントの発生時には解決に注力する
- インシデントが発生した時に、ヒューマンエラーを原因と見なし、原因になった犯人を突き止めようとしない。
- 犯人を突き止めて、インシデントを解決した気にならないようにする。
- あくまで、インシデントそのものを解決することだけに専念する。
- 事後評価ではインシデントの原因が
1個だと考えない - インシデントの事後評価では、ヒューマンエラー、ソフトウェア、ハードウェア、といった特定の何か
1個が根本の原因と判断しない。 - あらゆる側面から、複雑に絡み合う複数の原因や、寄与要因 (潜在的な原因) を突き止める。
5. ページャーの引き渡し¶
▼ パターンの概要¶
開発に携わっていない人にオンコールを任せてしまうこと。
(ページャー：ポケベル)
▼ 問題点¶
- 自分自身の開発したシステムが本番環境でどのように振る舞うのか、といったことを学ぶ機会を奪う。
- アプリ領域に関係するインシデントを迅速に解決できなくなる。
▼ 解決策¶
- オンコールは全てのエンジニアの仕事であり、アプリ開発チームはSREerにオンコールを全て丸投げしないようにする。
- アプリ開発者もオンコールの担当になるようなルール (例：交代制、二次オンコール担当) を設ける。
6. マジックスモークを消すのは私だ！¶
▼ パターンの概要¶
インシデントの発生を予防するための様々な行動よりも、インシデントの解決を最も高く評価すること。
▼ 問題点¶
- 現場のエンジニアが、忍耐的な作業にモチベーションを感じてしまう
- インシデントの担当者は適切に休めず、幸福度が下がる。
▼ 解決策¶
- インシデントを予防できる仕組みを作る。
- インシデントの解決よりも、予防する仕組みを作ることをより高く評価する文化を普及させる。
7. アラートリライアビリティエンジニアリング¶
▼ パターンの概要¶
あらゆるものをエラーベントと見なし、アラートを通知してしまうこと。
▼ 問題点¶
アラートが通知されるたびに、それ以外の作業が中断されてしまう。
▼ 解決策¶
ユーザーの満足度に影響を与える問題 (例：UX、単一障害点の異常、レプリカ数の過剰な減少) が発生した場合は、アラートを通知する。
8. ペットを散歩させてくれるドッグウォーカーを雇う¶
▼ パターンの概要¶
インフラのプロビジョニングツールを、イミュータブルなインフラを構築するためではなく、既存のミュータブルなインフラを冗長化させるために使用してしまうこと。
▼ 問題点¶
- プロビジョニングツールの使い方が間違っている。
- 状態の管理が煩雑になるため、ミュータブルなインフラはやめよう (個人的見解)
▼ 解決策¶
インフラのプロビジョニングツールは、イミュータブルなインフラを構築するために使用する。
9. スピードバンプエンジニアリング¶
▼ パターンの概要¶
信頼性を高めようと慎重になり、機能変更からリリースまでの間に、関門になるステップを設けてしまうこと。
▼ 問題点¶
- 関門となるステップ (例：変更管理委員会) が、必ずしも、機能変更のリリースに良い付加効果をもたらすわけでもなく、またユーザーからの評価を提供してくれるわけでもない。
- 不要なステップがあると、変更、リリース、ユーザー評価のサイクルの速度が落ちるため、システムの信頼性が高まりにくくなる。
▼ 解決策¶
- 最小限の関門ステップ
- 関門ステップを設けるとしても、特定の状況下 (例：機能ではなくプロダクト全体のリリース) で、プロダクトの内容には無関係なステップ (例：キャパシティプランニングなど) のみにする。
- エラーバジェットの導入
- エラーバジェットを導入し、優先順位決めや承認のスピードを上げる。
10. 設計の難所¶
▼ パターンの概要¶
システム設計時のSREerのコンサルがボトルネックになってしまう。
▼ 問題点¶
SREerの役割の1個として、システムの設計段階でレビュー (例：派遣型、窓口型) を行う必要がある。
一方で、システムの数が多くなると、コンサルのステップがボトルネックになり、リリースの頻度が低くなる。
▼ 解決策¶
コンサルをフレームワーク化 (例：チェックリスト) したり、ツールで自動的にコンサル可能にする。
11. 棒が多すぎてニンジンが不足¶
▼ パターンの概要¶
SREingの実現に必要なツールをアプリ開発チームに導入したい時に、まずは提案するのではなく、使用を強制してしまうこと。
▼ 問題点¶
- SREingはプッシュ型ではなくプル型であり、アプリ開発チームから課題を聞き出す必要がある。
- ツールをプッシュ型で強制的に導入した結果、エンジニアの開発がより非効率になることがある。
▼ 解決策¶
アプリ開発者チームから、開発の効率性に関する課題を聞き出し、それに合ったツールを提案する。
12. プロダクションの延期¶
▼ パターンの概要¶
リリース前にエラーイベントの原因になりそうなことを未然に全て解決しようとしてしまうこと。
▼ 問題点¶
機能変更からリリースまでに必要以上に時間がかかると、ユーザーからの評価が遅くなる。
▼ 解決策¶
- テストの自動化
- あらゆるエラーイベントを予防するために、機能変更のリリース前にテストを実施することは重要であるが、リリースまでに必要以上に時間がかからないようにする。そのために、テストを自動化して時間を短縮する。
- ユーザーからの評価を素早く得る
- ユーザーからの評価を素早く得られるTesting in productionを含むデプロイ手法 (例：ダークローンチ、カナリアリリース) を採用する。
- ロールフォワード、ロールバックの自動化
- リリース前の予防を完璧にしない代わりに、リスクヘッジとして、リリース後のロールフォワードとロールバックを自動的に実行できるようにしておく。
- Progressive Deliveryを採用し、SLOを判定基準とした自動ロールバックを実現する。
-
13. リカバリー時間ではなく障害回避の最適化 (MTTF > MTTR)¶
▼ パターンの概要¶
MTTFを重要視し、MTTRを軽視してしまうこと。
▼ 問題点¶
障害は発生するものであり、MTTFを最適化することは現実的ではない。
▼ 解決策¶
- 障害の範囲の縮小
- 障害範囲 (あるいはblast-radius) が最小限になるようにする。
- 復旧力の向上
- 人間による修復は時間がかかるため、人間ができるだけ介入せずに修復可能にする。
- 復旧力の維持
- Testing in production (例：カナリアリリース中のテスト、カオスエンジニアリング) を定期的に実行することにより、システムがデグレーションしないようにし、復旧力を維持する。
14. 依存性地獄¶
▼ パターンの概要¶
システムが新旧様々なコンポーネントからなる場合、コンポーネント間の依存関係が闇になってしまっていること。
▼ 問題点¶
新旧コンポーネント間の依存関係が闇になっており、とある機能変更の影響範囲を人間が予測することは不可能である。
▼ 解決策¶
機能変更によって、コンポーネント間にどのような依存関係が新しく追加されるかを自動的に検出し、記録可能にする。
15. 小回りの利かないガバナンス¶
▼ パターンの概要¶
組織単位ではなく、プロジェクト単位で承認/予算策定/成果が設計されてしまうこと。
▼ 問題点¶
プロジェクト単位で承認/予算割り当て/成果が求められると、種々の問題 (例：予算割り当てに時間がかる、不要な機能がそのまま、開閉が繰り返されるプロジェクト) が起こり、アジャイル開発を実現できない。
▼ 解決策¶
組織単位で承認/予算割り当て/成果を設計する。
また、各組織は、目標 (例：方針管理、Catchball、OKR) までのプロセスに対して、自由に承認/予算策定/成果を設計する。
16. 不適切な「おやおや」のSLO¶
▼ パターンの概要¶
ビジネスとは無関係にSLOを決めてしまっていること。
また、一度決まったSLOが更新されないままになってしまうこと。
▼ 問題点¶
ユーザーニーズに基づいたSLOではないため、いずれシステムの不備 (例：スループット不足、過負荷、ハードウェアキャパシティ不足) が浮き彫りになる。
また、SLOが最新の状況に則していないと、ユーザーからの評価を下げることになる。
▼ 解決策¶
ビジネス側と話し合い、ユーザーニーズ、ビジネスの収益、に基づいたSLOを設定する。
ビジネスとSLOの双方向で、定期的に更新する (例：SLOに合わせて営業時間を更新する) 。
またSLOは高過ぎれば良いということもなく、例えば99.5%と99.9%の信頼性の間でユーザー評価が変わらないのであれば、労力をかけて99.99%にする必要はない。
17. ファイアウォール越しにAPIを投げ渡す¶
▼ パターンの概要¶
パートナーに機能 (例：API) を提供するようなビジネスをしている場合、パートナーのSLOに無関心で、自社のSLOのみを守ろうとしてしまうこと。
▼ 問題点¶
自社がパートナーの問題に無関心になることによって、チーム間の無関心で起こる問題と同じようなことが起こる。
▼ 解決策¶
- 共通認識からなるSLIとSLOの設定
- 自社とパートナーの間でSLIを共有し、自社とパートナーのシステムを合わせたSLOを設定する。
- インシデントを共通管理
- 自社とパートナーの間でインシデントを共通管理する。インシデントを協働的に解決できるように、対処の権限をお互いに与える。
18. 運用チームの修復¶
▼ パターンの概要¶
運用手法のみを改善すればSREingを実践できる、と考えてしまうこと。
▼ 問題点¶
SREingの実践のために、運用のみでなく、ビジネス (例：優先順位付け、計画と実行、意思決定) 、システム (例：設計、構築、トイル、ヒューマンエラー) 、チーム (コミュニケーション) も改善する必要がある。
SREingの最終目標はシステムの信頼性を高めることであり、これらはその手段である。
▼ 解決策¶
上層部から理解が得られず、SREingを十分に実践できなくとも、少なくともシステムとチームは改善できる。
19. 最後にもう一言¶
- SREingのアンチパターンは、変化し続ける。
- 筆者が集めたアンチパターンは、全体のほんの一部分でしかない。
- SREingの失敗事例を、自社内外問わず、共有していく必要がある。
- 失敗事例があれば、Twitterアカウント
@BlakeBisset宛に、#SREantipatternsをつけて共有してほしい。