Fusicきばんブログスマートフォン用の表示で見るFusicきばんブログFusic基盤ユニットの非公式技術ブログこの広告は、90日以上更新していないブログに表示しています。基盤ユニットの追加モジュール的な何かになりました。何書こうかなーと思い、最近あったtypoとの悲しい戦い*1をまとめなおすとかでも良かったんですが、せっかくなので違う話を。サイトが閲覧できない!な時に何をやっているか障害対応なんかに遭遇しやすい、あるいは呼ばれやすい性質でして。その時何やっているのかって話を少し。あわてない、さわがない、はしらないまあとりあえず。何もいい結果に繋がらないので。起きている状況をなるべく正確に知る「全く閲覧できない」なのか、「閲覧できるけどすごく重い」なのか、それだけでも大きな違いなので、状況確認は正確に。ネットワーク的に到達できるのか、サーバにログインできるのかこれすらできない場合は、ネットワーク起因だったりするので周辺の状況(経路でネットワークダウンの障害報が出てないかなど)を確認するOSがハングしている場合は、再起動を試みるといった対応にシフトします。リソースの使用状況の確認dstatで確認することが多いです。リソース監視を行っているのであれば、そのグラフ状況を見るなどして、リソースの使用状況を確認します。メモリが枯渇しているCPUを使い過ぎているI/O待ちが発生しまくっているといった感じで、ボトルネックを特定します。Killerなんかは特異の典型)ログが出ていないかを確認します。特異点の判断ポイントとしては明らかに普段出ないログが出力されているログの量が普段より明らかに多いといった観点になるでしょうか。目で追うのもさすがに辛いので、grepなりwcなり、コマンドと組み合わせて原因を探る感じです。あと、アクセスログを精査するのであれば、Kataribeが便利です。ISUCON御用達ツールですが、負荷の高い箇所だったりアクセス増だったりの一次調査で使えます。対策を決めて実行する原因が明確に特定できたのであれば、対応する内容も明確になります。アプリケーションの修正であったり、ミドルウェアの設定値変更であったり。緊急度と対応時間とを天秤にかけて、場合によっては一次対応(応急処置)と二次対応(抜本的な対策)を分けるケースもあります。原因が分からないケースというのも当然あるので、その際は出力するログを増やすなどして網を張るようにしています。実例だとこんな感じ1ヶ月ほど前に起きた事例ですが。特定のページに対してアクセスが集中していることが分かった(原因判明)特定のページと関連リソース(ページ内の画像)に対して一時的にキャッシュするよう設定変更(対策)実例その2こんなケースも。開発環境で再現するかを検証(原因判明)再現したのでアプリケーションを修正してリリース(抜本的な対策)というわけで何かものすごいことをやっている話ではないので恐縮なのですが、こんな感じで障害対応していますって話でした。集中管理の仕組みを設ければ、調査系で呼ばれる回数が減りそうだなーと。前時代感なまま過ごしていたんですが、この辺をKibanaに集めるような仕掛けをぼちぼち組まねばな、と。書いてしまったので、今年の前半はその辺を整備していきます。*1:100以上のコミットを経て、ようやく落ち着いた。Slack)月別アーカイブリンク株式会社FusicFusicキャリア採用ページはてなブログをはじめよう!fusicさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。