Blogセプテーニ・オリジナルのエンジニアが綴る技術ブログ2019-07-24【SRE本読書会】効果的なトラブルシューティング中途三年目、社内でSREの風を吹かせております堀越です。ここ最近、弊社の中でも割と長寿なプロダクトの保守を行ってきました。ついてざっくりとまとめていこうと思います。トラブルシューティングスキルは学習可能トラブルシューティングスキルは生まれ持ったスキルのように思われがちだが、頻繁にトラブルシューティングを行う人にとっては染み付いたプロセスになっているのでそのように見えるだけとなっている。トラブルシューティングは学ぶことも教えることも可能なはずである。トラブルシューティングスキルの構成要素トラブルシューティングスキルは下記の2つの要素に依存する。一般的なプロセスと大原則の応用だけでも調査することもできるが、本来あるべき動作を理解しておく方が効率が良い。理論トラブルシューティングのプロセスは仮説演繹法の応用と捉えられ、下記プロセスの繰り返しとなる。理想的なモデルトラブルシューティングは下記のような手順化されたモデルとして表現できる。仮説の検証方法としては下記の2つ。システムの状態と仮説とを比較し考察するシステムに変更を加え、その結果を観察する後者のアプローチはシステムの状態と考えうる障害の原因についての理解を高めてくれる。トラブルシューティングにおける一般的な落とし穴トラブルシューティングの効率が悪いのは、システムに対する理解が欠けていることが主な原因。下記は注意すべき落とし穴。実際には、トラブルシューティングは理想化されたモデルの示す通りにいくようなクリーンなものではないが、苦痛の少ない生産的なものにする手順は存在する。問題のレポート問題への対応は必ず問題のレポートから始まる。効果的なレポートとは効果的なレポートには下記のような内容が記されているべき。問題となっている現象を再現させる手順さらに、レポートは一定の形式で作成し、検索可能な場所に保存しておくのがよい。おけるバグチケット作成の粒度メールやチャットで受信したものであっても、1つの問題ごとにバグチケットを切るのが主流。人への直接の報告は下記のような理由から推奨されていない。トリアージ問題のレポートを受けた次のステップは何をすべきかはっきりさせること。その問題の影響範囲に応じて適切に対応しなければならない。大規模な障害なら総力をつぎ込む緊急事態であることを宣言することが適切だが、小規模の場合に同じことをするのはやりすぎ。大切なのはシステムの動作を止めないこと大きなサービス障害に対し、いきなり根本原因を突き止めたくなる本能は無視しなければならない。行うべきはシステムがその環境下でできるかぎりうまく動作するようにすること。これは二次三次の災害を防ぐため。根本原因を探っている間にシステムが止まってしまってはユーザーを助けられない。検証システムが正しく動作しているかどうかを理解するには、システム中の各コンポーネントの動作を検証できなければならない。その際、モニタリングツールによるメトリクスやロギングによるリクエストのトレースなどが問題解決に役立つ。診断システム全体の設計を理解しているのは仮説を立てる上で必ず役に立つが、特定領域に固有の知識抜きでも役立つような一般的プラクティスもある。単純化と削減コンポーネント間を流れるデータを見て、そのコンポーネントが正しく動作しているか判断できるはず。効果的なのはテストデータを与えて各ステップでの結果が期待通りになっているか調べること。再現性のあるテストケースがあればデバッグを早く進められるようになり、同じテストケースをプロダクションでない環境でも使える。することでリスクの高いテクニックを使うことができる。問題解決のテクニックとしては非常に有効で。障害を起こしているコンポーネントを限定できる。「何が」「どこで」「なぜ」と尋ねる異常を起こしているシステムは、依然として何かをしようとし続けていることが多い。送られているのかを探れば症状を理解するのに役立つ。直近に生じた変化は問題を特定する上で効率的な出発点になる。システムの変化をシステムや環境における他の出来事と関連付けたモニタリングダッシュボードなどがあると役に立つ。自分らが受け持っているサービスを診断するためのシステムを構築することは有益。車輪の再開発を避けるためサービスやチーム間での共通性は意識するべき。潜在的な原因をある程度調べたら根本原因を調べる。アプリケーションロジックのサーバーとデータベースサーバー間のネットワーク障害か、データベースが接続を拒否しているかのどちらかと考えているものとする。アプリケーションロジックが使用しているものと同じクレデンシャルでデータベースに接続すれば後者を検証できる。飛ばしてみれば、ネットワークやファイアウォールのルール、あるいは他の要因として前者を検証できる。テスト設計テスト設計には考慮すべきことがたくさんある。理想的なテストは排他的な複数の選択肢を持つこと明らかなことから考え始めるアプリケーションへのアクセス許可がIP制限の場合は混乱を招きやすい特定のマシンからしかアクセスできないなどテストによる副作用テストのために仕込んだコードが悪化させていないかテストの結果がハッキリせず、妥協しなければいけない場合もある実行したテスト、およびその結果は記録しておくこと。同じステップを繰り返さずにすむし、このドキュメントが重要になる。実験の成果として期待された効果が得られなかった結果のこと。プロセスによるアプローチでの改善がうまくいかなかった場合も含む。否定的な結果は、無視したり過小評価してはいけない間違いを理解することは、設計上の問題に解をもたらすことがある。否定的な結果が出た実験は決定的なもの。いった実験は、プロダクションや設計の領域、パフォーマンスの限界について確実なことを示す。それらの実験は、独自の実験や設計を行う価値があるかどうかを他者が判断する助けになる。否定的な結果を直感的に実験に適用できなくても、収集された補完的なデータが、他者が新しい実験を選択したり、それまでの設計に潜む落とし穴を避けたりするのに役立つこともある。マイクロベンチマーク、ドキュメント化されたアンチパターン、ポストモーテムなどはここに分類される。実験の設計を行う際には、否定的な結果のスコープを考慮にいれなければならない。ツールや方法論は長期的にも役に立つツールや方法論は、実験そのものよりも長く残るものであり、詳細な作業の助けとなる。繰り返し行われる実験のためのツールを構築することには、間接的なメリットもある。データベースのインデックスの設定変更を簡単に試せるスクリプトを書いてそれを使ってあまりメリットを得られなかったとしても、次のプロジェクトでは最適化を忘れることはなくなる。否定的な結果を公開しよう否定的な結果や、統計的有意性の欠如を明確に説明することが、不確実性を慎重に受け入れる例を他者に示すことになる。すべてを公開することによって、他者にも同じ行動を取ることを推奨することになり、ひいてはソフトウェアに対する知識を誰もが早く学んでいけることになる。実験の結果に自分が関心を持っているなら、他の人々も関心を持つ可能性が高い。結果を公開すれば、そういった人々は同じような実験を自分たちでやらなくよくなる。実験が「失敗」だったと受け取られやすいことから、否定的な結果を報告することは避けたくなるものであり、それは一般的なことでもある。実験の中にはそもそも絶望的なものもある。多くの実験は、否定的な結果は進捗でないという誤った考えから報告されないままになっている。否定的な結果は、思慮深くリスクを取った結果の一部であり、十分に設計されたあらゆる実験にはメリットがある。逆に失敗に言及していない設計ドキュメント、パフォーマンスレビュー、小論文に対しては懐疑的に接するべき。いったドキュメントは、フィルタがかかりすぎているか、作者が自分の手法にたいして厳格ではない可能性がある。続いては、実験の成果から本当に原因であることを確かめる。その確認をプロダクションでやるのは難しいかもしれず、以下の要因で推測しかできないかもしれない。システムは複雑なので単独では原因とはならない要因が相互に関係していることが原因となっている。再現することが複雑過ぎたり、ダウンタイムを増やせられない。ポストモーテムに書く。トラブルシューティングを容易にするために最も基本的なものは下記の2つ。観察のための仕組みを構築する。ホワイトボックスのメトリクスと、構造化されたログを各コンポーネント間で取得できるようにする。システムの設計時に、コンポーネント間に観察可能なインターフェイスを持たせる。システム全体にわたって、一貫性のある形で情報が利用できることを保証するのが良い。*2まとめ個人的に重要そうなものをピックアップ。観察のための仕組みを構築し、構造化されたログを取得できるようにするシステム設計時にコンポーネント間に観察可能なインターフェイスを持たせる運や経験に頼らずにシステマティックにアプローチすることで、サービスを回復するまでの時間を抑えられる最後にトラブルシューティングスキルはある程度、体裁的に学習できるということがわかりました。セプテーニ・オリジナルでは一緒に働いていただけるエンジニアを積極募集中ですのでどしどしご応募ください。わたしと一緒にSREの風を吹かせてくれる方、大歓迎です。*3<中途採用サイト>*1:たとえば、エラーレートと新しいバージョンのデプロイ開始・終了時刻を組み合わせたグラフなど。*2:リクエストにユニークな識別子を持たせてロギングするなど*3:TwitterなどでDMいただいても構いません。中途3年目、堀越です。最初心配していた...2017-06-19ペアプログラミングの勧めみなさま、こんにちは。読書...セプテーニ・オリジナルでは一緒に働く仲間を募集中です!ぜひ一度採用サイトを御覧ください。»セプテーニ・オリジナルはScalaMatsuri2020の将軍スポンサーです。ScriptPYXISインフラチームの軌跡プログラミング初心者が3ヶ月半の研修を終えて新卒研修を終えての振り返り月別アーカイブ検索はてなブログをはじめよう!septeni-originalさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。