SEにお勧めしたい洋ドラDr.HOUSE

-

Dr.HOUSEというドラマ

皆さんはDr.HOUSEというドラマをご存じだろうか。
ざっくりいうと、アメリカのドラマで過去の病気の後遺症で鎮静剤バイコディン中毒になった性格の悪い天才医者ハウスさんが、友達の医師ウィルソンらゆかいな仲間にちょっかいを掛けつつ、搬送されてきた原因不明の患者の病気を特定して回復させる物語である。

大体の筋としては、以下のような流れで物語が進んでいく。
  1. 原因不明の病気の患者が運ばれてくる
  2. 症状をもとに対処療法を行う
  3. 患者死にかける（別の症状が出てくる）
  4. 新たな症状に対する対処を行う
  5. また患者死にかける
  6. 病気の真因が判明
  7. 快方に向かう（もしくは手遅れで死ぬ）

Everybody Lies(人は誰しも嘘をつく）

このドラマの面白いところは、病気にかかった本人や、周りの人間の証言の中に、嘘や何らかの認識誤りや事実の欠落があり、それが元で病気の原因が不明で一筋縄では解決に向かわず、それらの「嘘」を排除して真因を炙り出すため患者の調査や原因の推理、対処療法を行っていくところにある。

ハウスは「Everybody Lies(人は誰しも嘘をつく）」という信念を持っており、患者やその周りの人間は「過誤」を必ず起こすのでそれらの証言を一切信用しない。

医療物の殻をかぶってはいるものの、要は推理小説と同じ構造の物語なのだ。
（主人公の名前はホームズ→ハウス、親友の名前もワトソン→ウィルソンでシャーロックホームズのオマージュ）

それらの証言は基本無視して、名探偵のように過去の病歴や現在の生活環境、遺伝的疾患や治療に対する反応などの事実を調査し、真因にたどり着くのである。

SEにお勧めしたい点

病気をバグ、患者をユーザーと置き換えるとSEにお勧めしたい理由がわかると思うが、要は「システムの障害発生時に問題の真因を特定する」という点がシステムの問題解決にも共通しているのである。

特に「Everybody Lies(人は誰しも嘘をつく）」は重要である。

システムを使っている人が報告してきたバグの内容が問題を100%表しているわけでもないし、システムやミドルウェアが出力するメッセージがエラー原因をすんなり教えてくれることは（悲しいことに）余りないし、実は別のシステムのエラーをこのシステムのエラーだと言ってくることもあれば、パソコンのモニターの電源が消えているだけの場合もある。

ユーザーがこっちが思いつかないような操作法や使い方してる場合もあるので、実際にどんな操作をしているのか確認する必要もある。

コミュニケーションギャップにより事象がうまく伝わらない場合もあるので、スクリーンショットで説明したり、遠隔で画面共有したりすることも早期解決の手段の一つである。

さらにややこしい場合は、Aシステムで正常に処理した内容が、実はBシステム側ではNGでBシステム側でエラーになったり、作ったシステムが悪いと思ってたら、OSの設定が悪かったとか日常茶飯事である。

何が悪いのかを切り分けていく作業がトラブル解決には重要である。

また、患者が死んでは元も子もないのと同様に、サービスが提供できなくなると損失が発生するので、とりま復旧を目指すことも大事である。

トラブル対応時に意識したいこと

「Everybody Lies(人は誰しも嘘をつく）」は自分を含めて人間嘘をつくので、以下のことを心にとどめてトラブル対応に当たりたい。

  1. 客の言うことは信用するな。目で見ろ。
  2. 身内が言うことも信用するな。
  3. 仕様書を信用するな。ソース見ろ。
  4. システムパラメータ設計を信用するな。実機見ろ。
  5. システムのログは100％信用するな
  6. ミドルのエラーはさっさとサポートに投げろ。サポートの回答も100％信用するな。
  7. OS（特にWindows)を100％信用するな
  8. 自分の仮説にも疑問を持て。自説にこだわりすぎるな。
  9. 複数のパラメータを同時にいじるな
  10. 考え込まずに手を動かせor手下を動かせ
  11. とりあえずググれ。英語のページも嫌がらずに見ろ。
ほんとトラブル対応は地獄だぜヒャッハー！！

コメント

コメントを投稿

このブログの人気の投稿

ヤマダ電機の安心会員住所変更をした

-
安心会員住所変更 ヤマダ電機の住所変更の顛末を記す。 結論から言えば実にあっさりと住所変更ができた。 重い腰を上げる 昨年三月末に引っ越しをしたので、当然ながら住所が変わったのだが、郵便局に転送依頼をかけておけば1年間は郵便物を新住所に転送してもらえる。 それに甘えて２～３の会員登録で住所変更をさぼっていたのだが、そろそろ転送の期限も近づいてきたので重い腰を上げてみた。 昨今、ネットのサイトから住所変更できるところが大半なので、ヒッキーの私でも安心して変更できるのだが、ネットでできないところは正直めんどくさい。 電話が怖いのよ電話が(((((( ;ﾟДﾟ)))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ …まぁ、社会人○○年目の大人だから必要があったらやるけどさ。 ということで、勇気を出してヤマダ電機の安心会員専用窓口に住所変更の電話を掛けてみた。 まったく簡単だ！！！ 簡単に言えば下記のようなホップステップからのホイップである。 住所変更の依頼である旨をご担当者様に申告すると、「とある情報」を聞かれるのでそれに答える。 その情報をキーとして、ご担当者様が会員情報を検索し、ヒットした情報が電話を掛けている人間のものであるか確かめるためにいくつか質問をされる。 回答した内容が正解であれば、住所変更の手続きに入る。 一応、「とある情報」というのは伏せておくが、引っ越しによって変わる可能性のある情報なので、個人情報にあたるもので引っ越し前後で変わったものがあれば、電話する前に書き出しておくことをお勧めする。 また、旧住所の情報も必要なので、番地、マンション名なども回答できるようにしておこう。 俺はしどろもどろになりながら答えた！だが、ご担当者は優しく対応してくれた！ 上記のプロセスを経て、晴れて住所変更が完了する。 ただ、つい最近変更したところなので、本当に住所変更できたか、郵便物がちゃんと届くのかといったところはわかり次第、追記したい。 追記：ちゃんと新住所に届きました！
続きを読む

JP1の定義をドキュメント化するjp1ajs2.jobdocが超便利

-
素晴らしいツール こちらの作者さん が作成されているJP1の定義からドキュメントのhtmlを生成するツールが超便利な件。 jp1ajs2.jobdoc https://github.com/mizukyf/jp1ajs2.jobdoc/ 必要とした経緯 JP1の標準で作成した定義を Excelに落とせるツール はあるのだが、なぜかJP1 Viewが入っている端末にExcelが入っていなかった。 （ちなみに、JP1用語だと定義を抜き出すのが「インポート」、定義を登録するのが「エクスポート」らしく大変ややこしい。） 見ようと思えば 定義ファイルの中身の記述が公開されている ので人力でも解析可能ではあるが、そんなのクソ面倒なので、誰か偉い人が作ってくれてるだろうと他力本願したところ、jp1ajs2.jobdocに出会った。 おすすめポイント 定義情報をjp1ajs2.jobdocに食わせると、html形式で解析対象配下のジョブ定義のパラメータをテーブル形式で表示してくれたり、マップもsvg形式で出力してくれる。 ブラウザがあれば定義情報とマップの両方を参照できるのが素晴らしい。 コード値に対応した日本語の説明文も出力してくれるので、わかりやすい。 また、これでドキュメント化しておけば、定義を確認するのにJP1 View開いて確認する必要がないので、JP1 Viewを見れない人に情報共有をしたり、自席で定義をサクッと確認したりするのにちょうどいいと思う。
続きを読む

curlでADのドメインユーザーでプロキシを超える

-
curlでADのドメインユーザーで認証してプロキシを超えたい こちらのサイト でslackにsnmp trapを送信する方法が書かれていたのに触発されてシステムのエラーを通知するのに、MicrosoftのTeamsのWebhookにjsonで飛ばしてみようと思ったらcurlでつながらない。 ADユーザーでプロキシ認証しないと外に出られない、Linux好きにとっては反吐の出る環境のため、それが原因で外に出れなかった。 ネット上にcurlで認証通す場合こうしたらいいよ～みたいなのがいっぱい転がっているが、なんかいまいちなので自分のやったことを備忘録として乗っけとく。 実際のコマンド例 ほんとは出力するメッセージを加工したりする処理を入れているのだが、要素だけ掲載すると下記のようなコマンドで飛ばせる。 WEBHOOKのURL作ったりするところはggrksでよろしくお願いします。 #環境変数定義 MESSAGE=<なんかメッセージ> TEAMS_WEBHOOKURL=＜TEAMSのWEBHOOKURL＞ #コマンド実行 echo "{ \" text \" : \" ${MESSAGE} \" } " | \ curl -H 'Content-type:application/json' \ -U "<ドメイン>\<ユーザー名>:<パスワード>" \ --proxy-ntlm \ -proxy <プロキシサーバ>:<ポート> \ -insecure -d @- ${TEAMS_WEBHOOKURL} プロキシ越えの肝となるオプション ポイントは下記の3つで、特にADのドメインユーザーで認証する場合、ntlm認証のために「--proxy-ntlm」オプションが必要らしい。 -U "<ドメイン>\<ユーザー名>:<パスワード>" --proxy-ntlm -proxy <プロキシサーバ>:<ポート>
続きを読む