拝啓SEさん「何か変なんです」
こんにちは、白井です。
あっという間の年末ですね。
なんだか一年あっという間だったなぁ、、、
みなさまはいかがお過ごしでしょうか
さて今日の話はというと、イベント関連の話を書こうかな？と考えていたんですが
直近で実はサーバトラブルがありまして、、、
「そういえばシステム目線でのトラブル対応についての話って書いてないなー」と
という訳で今回はトラブル対応フロー？について書いてみます。
■それはいつも突然に、、、
「何か変なんですよね」
「動作がすごく重いんですよね、、、」
「真っ白なんですけど？(ブラウザ画面を指差しながら)」
殆どの場合ごく日常的な会話やメールから、こんなワードが突然飛んで来ます。
非エンジニアな方々からすると、割と軽い感じなんでしょうが
これ実はシステムエンジニアからするとかなりの恐怖ワードだったりします。
このワードを聞いた時の心情は大凡下のような感じ
「、、、まじですか」
、、、と
■トラブル対応その１：まずは現状把握と確認
クライアントをはじめ割と多くの人は、それが不具合なのか仕様なのか、、、というかそれさえも認識してません
「システムが自分の意図した通りに動かない」その事実が存在するのみ
そういった場合にまず最初に行うのが
・何をやりたかったのか
・どう操作したのか
・どこが上手くいかなかったのか
そもそも話を振られた時点では仮説や調査に必要な情報が圧倒的に足りてません。
情報が足りない＝何も対応出来ない、に等しく
通常はまず聞くところから始めます、そりゃもう徹底的に聞きます。
この徹底的に聞く部分を割と嫌がる方も居るんですが
これが無いと本当に手の出しようがありません。
なぜなら普通システムは「正常に動く」という事を命題として作られます。
で多くのエンジニアは正常に動く様に、多くのケースや事象を想定して
「想定通り(正常)に動かないであろう原因」を潰しています。
それでも正常に動かないという事は、そもそも「想定外」なんです、、、
■トラブル対応その２：データをくれ！！！
前段階で現状把握が完了して
「何か起こっているのか」を理解します。
そしてその後に発生するのが不具合を確認する為の「再現」という作業
対応を開始する時点では不具合発生は過去の事で
大抵の場合「既に事故が起こった後」となっている事が多く
現在進行形な事は希です。
では既に起こってしまった事象に対してどう対処するのかというと、、、
・不具合の記録を調査する
・不具合をもう一度発生させて観測する
といった事をやります、前者のみで解決する事もありますが
大概の場合解決出来なかったり、そもそも記録(ログ)が無かったりする事も
所謂、警察の現場検証といった行為なのですが
それって遺留品や現場的証拠が手に入るのみで犯人逮捕には遠い、、、といった状態に近く
現行犯なら即逮捕できる(不具合箇所の特定)のに！といった感じです。
なので必然的に対応として後者の「再現」という作業を行う事が多くなります。
その１でヒアリングした時点で「どう操作したのか」は把握出来ていますが
同じ事を行う為の材料(データやファイル)がまだありません。
システムの不具合は、特定の状況やデータなどで発生し
「全く同じ状況」を作り出さないと発生しない、といった事もよくあります。
だからこう叫ぶのです
「データをくれ！！！」
■トラブル対応その３：ようやく、、、？その先も長く
さてこれで現状把握と材料が揃いました。
そしてこの段階で初めてシステム(プログラム)の調査に入れるようになります。
ここからは不具合を引き起こす状況を再現しながら
システム内で異常を引き起こす箇所を、プログラムの処理を追いかけながら特定していきます。
データの状態を確認 → 異常あり？なし？
プログラムを確認 → 異常あり？なし？
という事を地道に繰り返していきます。
これが自身が作ったシステムなら、内容を把握していて
目星をつけて、ある程度原因箇所を絞り込んだ状態で開始出来るので
検証箇所が比較的少なくて済むのですが、まったく未知のシステムだったりすると
膨大な時間や労力が必要になってきます。
ちなみに経験則やエンジニアの知見や技術でもある程度カバー出来るので全部が全部、、という訳ではありません。
この辺がスキルレベルとか言われる部分でもあります
(経験や知見・技術が多かったり高かったりすると対応が早いというやつです)
そして原因箇所を特定できたら、ようやくソースコードの修正という段階へ進めます。
■その後も
この後は前述したソースコードの修正や
修正したコードのテスト、リリースなどまだまだ対応は続きます。
稼働中のシステムであれば、その間に色々なタイミングの調整や
説明資料の作成であったり、設計図の修正などなど
やる事は山のように積み上がります。
もちろん修正後のシステムの稼働状況なども気にしないといけません。
■まとめ
今回書いたのは「ほんの一部の対応ケース」に過ぎません
原因となるのがシステムのみ想定として、今回の文章を書いていますが
実際には更に動作環境であったり構成であったりと、考える事は更に多岐にわたります。
「トラブル対応」と一口に言いますが、その裏には本当に膨大な思考と作業が、、、
ですから多くのエンジニアや関係者は思うのです。
「どうか、、、どうか無事にシステムが正常に稼働しますように、、、」
、、、とまぁ、若干変なテンションで書きましたが
こういった色んなケースを想定して「モノをつくる事」「有事の際にも対応出来る事」
所謂「問題解決能力」というのもエンジニアの価値だったりするので(他業種でもそうですね)
沢山失敗して沢山経験できると良いなー、なんて思ったりもします。
(ユーザーに迷惑がかからないのが一番ですが)
いつかまたトラブル対応について書けるとしたら、今回のフロー的な内容ではなくて
思考部分について書いても面白そうです。
ではでは、今回はこの辺で
facebookでも情報を発信しています
facebookをフォロー
