600000007

プログラムと折り紙のブログです。

障害切り分け

いつものように後輩へ障害対応方法を指南していたところ、ふと我に返り「そもそも自分はどうやって切り分けているのだろう?」という疑問が湧いてきました。
経験的にこれを確認したほうが良い、そっちは関係ないなどということは分かっているんですが、どういったルーチンを自分が行っているのかは整理されていませんでした。

というわけで自分が普段なんとなくやっている切り分け方法を整理して言語化してみました。障害に遭遇したけど原因がわからず手詰まりになった、もっと効率的に切り分けたいといった場合の一助になれば幸いです。ここでは如何に切り分けていくかということだけに焦点を当てており、障害の検知や再発防止などには触れていません。

障害とは?

ここで言う障害とは、以下のような事象を指します。

  • サイトに繋がらない
  • エラーでプログラムが落ちる
  • PCの電源が入らない

構成情報を把握する

障害が発生している環境の構成を把握しましょう。特にバージョン情報は過去事例と照らし合わせる上で重要な情報となります。

  • システム構成
    • サーバ構成
    • ネットワーク構成
    • データベース構成
    • データフロー
  • H/W詳細
    • サーバのスペック、バージョン、設置場所
    • ネットワーク機器のバージョン
    • 部品のバージョン
  • S/W詳細
    • OSのバージョン
    • フレームワークのバージョン
    • ライブラリのバージョン
    • プロトコルのバージョン
    • データフォーマットのバージョン
    • ブラウザのバージョン

時系列で整理する

発生した現象を時系列で整理しましょう。複数の障害が発生している場合、最初の障害が大元の原因となっていることが多いです。単に障害の発生時刻だけではなく、発生している環境の設定変更・環境の変化も併記するのがお勧めです。

  • 障害発生日時
  • 障害発生期間
  • 設定変更日時
  • 構成変更日時
  • メインユーザが変わった日時
  • ユーザ数が増加した日時

エラー内容をちゃんと読む

エラーメッセージをいきなりググったりせずに、まずはきちんと何を言っているのか読み込みましょう。

現象を分解する

発生している現象をフェーズで分けて、どの範囲まで正常でどこから異常なのか調べましょう。さらっと1行で書いてますがこれは切り分けの上で最も重要な作業であり、きちんと正常動作を把握しているかどうか、より細かく分解できるかどうかが切り分け力=技術力の差に直結します。

再現を試みる

ある程度発生条件の見当がついたら、現象の再現を試みましょう。可能な限りデフォルト環境で、小さい構成で再現を試みるとより効率的です。

他の環境と比べる

もし同じ構成で正常に動いている他の環境があれば、設定などの差分を調べましょう。また以前のバージョンに切り戻すと復旧する場合は、その差分が原因である可能性が高いです。

  • 各種設定
  • 各種バージョン
    • 以前のバージョンとの差分
  • システム構成
  • データ処理量
  • 処理したデータの種類
  • 負荷
  • 温度

可能であれば正常な環境と同一になるように少しずつ設定を変更して、どの時点で改善するかを調べるのも手です。

規則性を見つける

障害の規則性を見つけると、切り分けの手がかりになります。

  • 時間に偏りはないか?
    • 朝7時に発生する
    • 営業日に発生する
    • 現象が続く時間の長さが一定
    • 再発するまでの間隔が一定
  • 手順に偏りはないか?
    • 特定のユーザのみ発生する
    • 特定の操作のみ発生する
    • 特定の回数繰り返すと発生する
    • 特定の接続元からのみ発生する
  • 環境に偏りはないか?
    • 特定のサーバだけで発生する
    • 特定のネットワークを経由したときだけ発生する
    • 特定のバージョンだけで発生する
    • 特定のブラウザでのみ発生する
  • アウトプットに偏りはないか?
    • 壊れたファイルのサイズが一定
    • ファイルの破損箇所が同じ
    • 壊れる部品が同じ

知らない情報があるか調査する

実は自分が知らないだけで他にもエラーが保存されていたり、デバッグ機能があったりするケースがあります。

  • OSがcoreを吐いている
  • サーバのシステムボードの管理領域にH/Wログが出ている
  • 直前の印刷内容をダンプすることができる
  • 操作ログが出力されている
  • 設定が他にもある
  • 設定を反映するための特殊な手順がある
  • 利用してるクラウドサービスが仕様変更のニュースを出している
  • バグレポートがある

そういった情報が無いか調査をして、新しいヒントを得られることも多いです。

申告された内容を精査する

伝聞された情報は不正確な事も多いので、すべてを鵜呑みにせずに自分自身で確認したものを中心に整理しましょう。ユーザー申告の場合、どこをみて障害と判断して報告してきたのかを知ることは重要です。PCの電源が入らない!という申告があってもディスプレイの電源が入っておらず暗いからそう判断しただけ、といったケースはよくあります。

思い込みを疑う

設定を直したのに改善しない!原因はこれで間違いないはずなのに!と思ったら違うサーバで操作していた、なんて経験はないでしょうか?落ち着いて自分がやった作業を見直してみましょう。

  • 違うサーバで作業している
  • 違う設定ファイルを開いている
  • 設定を編集したが保存していない
  • 違うユーザのデータを見ている
  • 読んでいるドキュメントが違う


エラー番号を見ただけで過去事例と結びつけ、原因を決めつけてしまうケースもあります。あくまで目の前の事象と向き合って切り分けましょう。原因を特定できたと断定できるのは現象が改善した時のみです。

人に聞く

1人で調査しても埒が明かない時は、同僚やコミュニティに助力を求めましょう。有料サポートを契約しているならもちろん有効活用しましょう。

  • 同僚に聞く
  • メーカーに聞く
  • コミュニティに聞く
  • stackoverflowで質問する
  • twitterハッシュタグをつけて質問を垂れ流してみる

コミュニティに質問する場合は、事前にドキュメントを読み込んで質問方法、質問場所を確認しましょう。

・・・大体自分がいつもやっていることは出尽くしたと思います。これらはそれぞれ1度行えばよいというものではなく、何度もぐるぐると行ったり来たりして徐々に原因を追い詰めていきます。繰り返しになりますが、原因が確定するのはあくまで障害が改善したその瞬間です。それはエンジニアにとって喜びの瞬間でもあるので、解決を目指して突き進みましょう。

バックギャモン動画撮影

私の職場では、昼休みの度に同僚とバックギャモンをプレイしています。
参加者が増えるにつれ、トーナメントをやってみたり、レーティングをつけてみたりと徐々に遊び方も進化していったのですが、そうなると当然やりたくなるのが動画撮影ですよね。
プレイ動画を撮って後で棋譜を起こし、XGで解析するのは上達の近道です。参考までに実際どんな機材を使っているのかをご紹介します。


f:id:sakamoto_desu:20170530122342j:plain

これが実際に撮影している様子です。GoProを三脚で固定して撮影しています。


GoPro

1世代前のGoPro HERO+LCDモデルを使っています。やはり背面LCDがあるとすぐに写りを確認できて便利ですね。撮影後はUSBでPCにデータをダウンロード -> Youtubeに限定公開でアップロードして管理しています。Youtubeは容量無制限でアップロードできるので助かりますね。今はアップした動画を見ながら棋譜を起こしていますが、そのうち日本バックギャモン協会の有料棋譜起こしサービスも使ってみるつもりです。

最新の上位モデルだと、GoProから直接Youtubeにアップロードできるみたいです。

Ventlax

このVentlaxというのは要するに自撮り棒なんですが、オプションの三脚を使うと固定して使うこともできます。色々調整したところ先端のアームを1個外すと良い画角になりました。

実際に撮影した映像はこんな感じです。

f:id:sakamoto_desu:20170704202618j:plain

これで十分盤面が見えます。本当は自分から見た向きにしたいのですが、この機材だとどうにもならないですね。
そして実際に解析をしてみると、想像以上にダメな手を打っていたり、キューブアクションを見逃していたりと盛りだくさんで動画をとった甲斐がありました。
その他様々なハプニングが撮れたりして面白いことずくめなので、ぜひ動画撮影をやってみてください。

JJUG CCC 2016 Fallとキャリア

JJUG CCC 2016 Fallに参加しました。
可能な限りセッションは見たのですが、特に印象的だったものについて。

トレンドとキャリア

いちエンジニアとしては「何の技術を身につけるか」は大事です。それによって歩めるキャリアがだいぶ変わってきます。
それ故に今のトレンドは何なのか、どんな技術を身につけるべきか悩んでいたのですが、

「Webの先輩なんていなかったから、参考となるキャリアパスなんてなかった。好きなことをやればいい」

という言葉にガツンとやられました。
たぶん自分はキャリアの「正解」みたいなのを探していたのですが、よく考えたら業界自体が変化してる真っ最中なので正解もクソもないんですよね。
とは言っても自分の好きなことばかりを中心にするとあまりにもトレンドとかけ離れすぎてご飯を食べていけなくなりそうなので、その辺はバランス取らないといけないのでしょう。
ぼんやりした不安がすっきり消えたので2017年は迷わず進めそうです。

その他CCCで達成した野望

  • 後輩を連れてくる
    • 後輩と一緒にひしだまさんにお礼を言う
  • 夏の納涼LT大会で発表できなかったネタをやる

かっこわるいプルリク

JNAにプルリクをマージしてもらえました。
やったー。
長かったー。

どれくらい長かったかというと、2ヶ月以上かかってます。
マージしてもらったプルリクをみるとオープンしたのは3日前なのですが、これはぐだぐだになったプルリクをクローズして作り直したからです。
どうしてこんなに時間がかかったのか、オープンソースへの参加ハードルを下げるためにも恥を晒しておこうかと思います。

1週間に1回

8月末にプルリクを送ったんですが、予想外にやりとりが続き忙しい時期とバッティングしてしまいました。
そのため実際に対応できるのは1週間に1回。先方もよく付き合ってくれましたね・・・

英語力不足

そのやりとりが増えた原因の一つが英語力不足でした。駄目出しを受けてることはわかるけど何をどうすればいいのかわからないということが多かったです。

  • 誤読して不要なことをする
  • コメント不足でレビュワーと意思疎通がうまくいかない
  • ソースコード書くよりも英語コメント書く方が時間がかかる

こりゃいかんということで途中からしごとの基礎英語 | NHKゴガクで英語の勉強を再開したのですが、これがヒットして後半は大分楽になりました。
英語は勉強というより練習ですねー。

JNA知識不足

単純に知らない機能・知らない使い方を紹介されて、こうすればもっと良くなるよ!みたいな話が多かったですね。
おかげさまでdllマッピングについて詳しくなりました。
というかドキュメント読んでも書いてないマニアックな話ばかりで、プルリク送らなかったら一生知ることはなかったでしょうね。
このへんはプルリク様様です。

マージ失敗

そして最後の最後でマージ失敗・・・。
最後の方はレビュワーもサンプルコードを書いてくれていて、コピーするならマージしてね!と言われたのでマージにチャレンジしたのですが、最終的にコンフリクトを解消できず。何がいけなかったんだろう・・・
そしてもーどうせコミット多くてdirtyなプルリクになっているから、と開き直ってプルリクを作り直しました。
gitはまだ理解が足りてないですねー。


という感じでレビュワーに迷惑をかけながらもどうにかマージしてもらえました。
根気良く付き合ってくれる良い人に面倒見てもらえてありがたかったです。
さすがに適当なプルリクをじゃんじゃん送ろう!という話ではないですが、こんな風に誰もがスマートでかっこいいプルリクばかりを送ってるわけではないので、皆さんもチャレンジしましょう。

Backgammon:エースポイントゲームの定理。

バックギャモンとは | 日本バックギャモン協会

要するにエースポイントゲームに対してどんなに上手に対応したとしても、最悪の目が出てブロットができてしまうことがあるのはしょうがないよね、というお話です。

定理

エースポイントゲームでは、ブロットができてしまうダイスの目のパターンが必ず存在する。

証明

相手はエースポイントにずっと2駒残っているとする。
自陣のあらゆる初期状態から、限りなくブロット作らないで進めることができたとしても、最後の1手前ではインナーボードに2コマ必ず残る。
そのとき、次の手で以下のような目が出ると必ずブロットになる。
・片方はエースポイントをふさがれていることによって動かない目
・もう片方は動ける目
よってすべてのエースポイントゲームでどんな目に対してもブロットを作らないで安全にベアオフすることは不可能。
証明終わり。


・・・あってるかな?

第9回Jenkins勉強会 Jenkins+Windows

第9回Jenkins勉強会 - connpassにてLTで登壇させて頂きました。

slides.com

CIツールは乱立していますが、Windowsに対応しているものって少ないですよね。ただこんな手間がかかる状況だとJenkinsおじさんを量産するのでは?という意見は反論できませんでした。
実際自分も社内でJenkinsおじさんと化しています。その上Gradleおじさんも兼任しているので加齢臭が心配です。

あと引き続きvSphere PluginとLibvert Slave Pluginの簡単なJNLP接続方法を募集中です。
いやとっととJIRAにチケット登録しろという話なのかもしれませんが。
今後はもっと簡単にWindowsを扱えるようにできないか考えたいですね。

他にも言いたかったこと
  • xp/2003以降でGitが動く
    • Git Plugin + Artifactoryで自動インストールが可能
      1. Git for Windowsをインストール
      2. 設定を編集してからzipで固める
      3. Artifactoryへアップロード
      4. Git Pluginで自動配布

JJUG CCC 後日談

社内にて

今回は初めて同僚をJJUG CCCに誘ってみました。
その結果、後輩が一人参加してくれて、会場を右往左往する姿を見ることができました。

そして後日、週一で行っている社内勉強会にて実際に見たセッションを紹介することになりました。
私と後輩で交互に発表。ひとり7分。他人の資料でLTをやるような奇妙なイベントになりましたが、勉強会の同志の意識を高くすることには成功したようで、Java Puzzlersの購入(会社のお金)が決定しました。

Jenkinsと

当日の懇親会でJenkins作者の川口さんとお話をすることができました。
できました、というか酔っ払って絡みました。申し訳ございません。

その場にて熱い想いと酒臭い息をぶつけてしまい、
「スレーブをWindowsサービス化するために.Net Framework3をインストールしないといけないのめんどくさいんです」
.Net Framework2でビルドしてれば問題ないのかと思ってました」
「確か互換性がなくて・・・どうすべきか調べてご報告します!」
と約束をしてしまいました。

してしまいました、というよりは約束したかったんです。Jenkinsに関わりたかったんです。
その後Jenkinsのコードとissueとプルリクとドキュメントを読み漁った結果、このプルリクがマージされれば.Net Framework3のインストールが不要になることが判明。
川口さんにその旨連絡したところ、マージしていただけました。万歳。