00:01
理系とーくラボラジオ部、とくおのおと。
みなさん、こんにちは。理系とーくラボラジオ部、とくおのおと、通称とくおと、をお届けします。
パーソナリティは、毎度無茶な話題でおなじみのまさきです。
今度のネタも日本しがらみを予定しています、かぎうのです。
話題は基本、本番の1時間前ぐらいに焦って考えています、かずねです。
よろしくお願いします。
このラジオは、オンラインコミュニティ、理系とーくラボに所属する研究員たちが、
ワクワクするような科学トピックや、科学を楽しんでいる人のお話をお届けする番組です。
ということでですね、かりむさん、日本しがらみですか。
はい、えっとー、
ネタバレはしなくていいんですけど。
前に日本しがらみで、タイガドラマのネタでちょっとやりましたけど、
同じタイガドラマの同じ時代で、地震が結構絡んでるときがありまして、
私専門地学ですから、
そういえばそうでしたね。
いいネタになるなと思って、日本しと地震の話をしようと思っております。
ここにして、一時間前ぐらいの設定、考えを。
そうですね、まあ。
私も似たようなものなんですけど。
僕はもう一緒だと思ってましたよ、まさきさんは。
あー、泥火ということですね。
適当な男性2人と、気まじめな女性1人ということでお届けしております。
気まじめかな。
だらしのない男性2人。
はい、すいません。
ということで、今回の特報ノートも最後までお楽しみください。
はい、というわけで今回は、まさき流トラブルシューティング時の考え方の話をしたいと思います。
ちょっと心の声として、果たしてこの話は理系なのかっていうのはちょっとあるんですけど、話をしていきます。
理系と仕事の話だからいいんじゃない?
理系の人が割合としては多いですけど、別に理系じゃなくてもできる仕事ではあるんですけど。
ライフハックみたいなね。
そうですね、なんか人生のヒントとか困った時の解決策の一端を担えればと思います。
前職の時にシステムエンジニアとして主にハードウェアの保守業務っていうのをやってました。
保守業務の中でも特に顧客へ納品したシステムとかハードウェアがトラブっているのを何とかするっていう業務が一番しんどかったです。
それはしんどいですよねっていうね。
03:01
お客が急かすよね。
そうなんですよね。横にいたりするので、結構うわーってなりながら仕事してました。
未経験で入社して半年でそういった業務を一人で担当する場面になって、経験がないので純粋に調べたりしながらリズムで対応するしかありませんでした。
その時の経験からいくつかTipsが明文化できるかなっていうのがあるので、それのお話をしたいと思います。
お断りなんですが、当たり前じゃんっていう内容もいっぱいあるんですけど。
意識的にやらないと案外できてないことが多いように見受けられてますので、ちょっとわざわざ喋ってみようと思います。
当たり前が一番難しいんですよね。
そうなんです。特に焦ってたりするとね、全然わけわかんなくなっちゃうんで。
ということでまずトラブル対応ってそもそも難しいよねっていうお話をします。
普通よくある問題って何か原因があります。その結果はどうなるでしょうっていうのを解く問題が多いんですよ。
これって普通に順を追って考えていけばある程度だいたいわかるんですね。
例えばで言うと、岩を蹴って足を骨折するって当然といえば当然じゃないですか。
で今度トラブル対応っていうのは、起きてる現象から原因を特定しなきゃいけないので向きが逆なんですよ。
これは結構難しくて、何で難しいかっていうと、起きてることを引き起こす原因っていくつもあり得るし、そもそも何がそれを引き起こすかわからないっていう二重区なんですよね。
これを例えて言うならば、足を骨折しました。なぜでしょうっていう問題を問われていることになるんですね。
でそれを解くために、どっか出かけましたとか車に引かれましたみたいな質問をいっぱいしなきゃいけなくて、やっぱ大変よねっていうのがトラブル対応みたいな問題の解き方になりますと。
というのでまあ大変なんですよ。
ちょっと遠い目をしちゃいましたけど。
はいでトラブってるシステムについてよく考えておかなきゃいけないことがあって、通常の状態のシステムとは違っていてトラブってるシステムっていうのは完全のブラックボックスだと思った方がいいっていうのがあります。
完全なブラックボックス。
完全なブラックボックス。要は通常こういうふうな動きをしているんだけれども、それも一回そうはなってないと思って対応した方がいいですっていう話です。
06:08
トラブってるということは通常起きちゃいけないことが起きているので、通常起きていることも一回忘れて対応した方が安全です。
で割とやりがちなのが、通常普通にやって問題ない操作でもトラブっている時とかトラブりかけた時にやっちゃうと大惨事を引き起こすことがあります。
これの例として2つあるんですけど、1つ目がサーバーが過負荷でわーってなってシステムの調子が悪い時に原因を調査しようと思ってわーってなってるサーバーにいっぱい問い合わせをかけると。
CPUどんぐらい使ったんやとかなんやかんやっていうのをアクセスしていろいろすることでサーバーの負荷がより上がって最後の引き金を引くことになるっていうのはちょこちょこ起きます。
なので割と気軽にトラブってる時にいろんなところを見ると事故が起きるっていうのは割とあるあるですと。
えーじゃあどうやってそれ調べるんだろうなとか思っちゃったんだけど。あんまりアクセスしない方がいいってことじゃん。
起きてる事象からどこがヤバそうかをちゃんと狙っていくというか、ある程度推測してそれに関係ないようなところから潰していくんですよ。
だからヤバそうなところは極力触らない。ここは大丈夫だよね。うん大丈夫だったっていうのを積み重ねていって、あじゃあこいつだよねっていうのを突き止めるっていうのが僕がよくやるやり方です。
安全牌からね。
大丈夫そうなところが大丈夫であることを確認するみたいな。
で次はちょっと分かりづらい例かもしれないんですけど、パソコンが起動している途中時にハードディスクが急にお亡くなりになりましたと。
でなんかその時に調子が悪いから再起動かけようと思って再起動をかけてしまうと二度と起動しなくなるわけです。
まあハードディスクがお亡くなりになっているからそうなんですけどでこの例でどういうことができるかっていうと電源を切らなければOSが動いているのであればOSの上で動いているアプリの設定情報とかは抜き出せたかもしれないんですよ。
意外とハードディスクが壊れてもいきなりパソコンダメになることってダメにならないことがあって。
つまりそのハードディスクからメモリの上に読み出したデータでパソコンが動いている状態っていうのが必ずあるんですよ。
ハードディスクがダメになってても動いている状態っていうのがあってその時に気づければ一部情報が救えたかもしれないっていう可能性があったりするので普通問題ない操作でもトラフってるときにやるとやばいよねっていうのが割とあります。
09:07
なるほどね。
再起動なんかよくやりますけどね。
通常の対応としては正しいんですよ。
正しいんですけどすごい特殊な場合においてそうしない方がいい場合もあるっていう話です。
そこの見極めは普通できないししなくてよくてなんかパソコンおかしいなと思ったらとりあえず再起動っていうのは正しいです。
普通のユーザーというか普通のパソコンはそれで大丈夫です。
なんかすごい重要なサーバーとかでそれをやるとちょっと悲しいことになることがあるっていうぐらいのニュアンスでした。
はい、で次トラブルが起きた時の典型例の話をしていきますが、だいたい何かを誰かが変えてます。
何か変化点が必ずある。ほぼ必ずあります。
誰かが何かやっちまってるってこと?
やっちまってるか、普段はやらかしたことにならないんだけどたまたまやらかしたことになっちゃったとか、
必ず誰かが何かを変えたからおかしなことになってるっていうパターンが多いです。
で、変化点があったっていうのがわかってればそこを中心にしてじゃあなってこうなってっていうのを考えてみるとわかることが多いですと。
変化点がないのにトラブってる場合は物理的に何か壊れたパターンがほとんどで、こうなってしまうと基本的に手の出しようがありません。
困ったことに、私の立場で言うとお客さんのところに行っていろんな人にヒアリングをして回るんですけど、
ヒアリングをする対象の人がいつもやってる操作だから自分のやった操作が何か変化点になってるってわかってないパターンがすごいよくあるんですよ。
で、例えばで言うと、今ネットワークが通ってる経路がありますと、なんか経路1を通ってインターネットと通信してますっていう状態で、
経路1が詰まってるから設定を変えて別の経路に一部流すようにしましたっていう時に、経路を分けるための機械がパンクするパターンがあるんですよ。
この通信はこっち、この通信はこっちとか振り分けるところの負荷が上がってパンクするっていうパターンがあったりして、
当然こっちの方がええやろうと思ってやった変更が引き金になってるみたいなのって意外と気がつかない。本人は気がつかなかったりします。
もう1個あるのが、毎月ハードディスクの容量チェックを定常業務としてやってるような現場がありましたと。
12:10
そのたまたまある月のハードディスクの容量チェックを実施した瞬間に、実はサーバーのハードディスクのアクセスがすごい集中していて、
そこに容量チェックをしたせいで状況が悪化してパンクしたみたいなパターンもあったりするんですけど、それを作業した人っていつもやってる定型業務だから、そういうことが起きるって分かってないんですよ。
分かってないことが多いんですよ。
そういうのを上手いこと聞き出す能力っていうのが、具体的にこうやったらいいというのは明確に言えないんですけど、
そういうことをちょっと意識しながらヒアリングをすると良いかもしれません。
意外と無意識にやったことがトラブル原因だったりすることはあるので。
何もしてないのに壊れたっていうパターンもよくありましたね。
もうそれはね、いろんなところであるあるとして、あるあるとしても直せてるようですね。
そのヒアリングをするとか、その状況を把握していくっていうところなんですけど、
状況を把握するって、分かってることと分かってないことを分ける作業なんですね。
この場合、分かってることと分かっていないことの分け方っていうのが結構難しくて、
分かっていることは調べたりヒアリングした内容と、そこから演繹できることのみが分かっていることですと。
分かっていないことはそれ以外全てのことが分かっていないと思いましょうっていうのが心構えとして多分正しいです。
分かっていることを考えるときに、推測を含めないようにするっていうのが結構ポイントで、
推測が入るとそこで議論がめちゃくちゃなことになることがよくあるので気をつけましょう。
なるほどな。通常こうなってるから、これはこうだろうなみたいなことは分かってないことに含めないとだめだと。
最初に言ったブラックボックスっていうのとちょっと被ってくるんですけど、そういう認識の方がトラブルを解決するのはやりやすいかなと思ってます。
次ヒアリングっていう話が2回ぐらい出てきてるんですけど、ヒアリングをするのも結構テクニックが必要で、
面と向かって画面一緒に見ながらヒアリングするのは比較的難易度が低いんですよ。
なぜなら同じものを見ながら横で会話できるから、何なら指さしてこれがこうでとかできるので難易度低いんですけど、
15:00
結構よくあったのが現場が遠いから電話口でヒアリングするっていうのがよくあったんですよ。
これが難しくて。
難しいよね。
つまり相手の画面に何が表示されてるかを想像しながら、しかもそのトラブってる状況も想像しながら、
そのヒアリングしてる人の理解度とかも想像しながら指示をして色々調べてもらうとかっていうのが必要で、
考えなきゃいけないことがいっぱいあって大変なんですけど、そういうのがやっぱり大変ですよねみたいな。
リモートで。
そうですね、どうしてもリモートというか電話口になると大変です。
もう一個ヒアリングで難しいところがあって、
ヒアリング対象が全然違うことを思い込んでたりとか、
実際トラブルが起きてるのとは関係のない別の事象も同時に発生していて、
全然違うことを言ってることもあったりして、
本当にそれ今のトラブルに関係してる話かなみたいな判断をしなきゃいけないことがあります。
本当に考えなきゃいけないことがいっぱいあって大変なんですよね。
そんな感じでヒアリングしたりとかして、
なんとなく分かってきたかなっていう時に追加で何を調査しましょうかっていう状況になってくるんですけど、
起きてるトラブルの内容、それからさっき言った分かっていることっていうのを合わせて考えた上で、
ある程度推測できるブラックボックスの中身の部分があるわけですよ。
で、そうなってきた時にある程度何を調べるなんかなっていうのが分かってくることが多くて、
それが分かんない場合っていうのは結構お手上げなんですけど、
そういう場合は経験のある人に聞くとかしかないんですけど、
ある程度見えてきたらその中で調査できそうな安全そうなところをまずリストアップしてそこから潰していくと。
で、ここ大丈夫、ここ大丈夫、ここ大丈夫っていうのを詰めていって、
だんだん原因はここら辺やなっていうのを絞っていくような作業をすることが多いです。
っていうような手順でだんだん原因に近づいていくわけなんですけど、
原因が分かった場合に即時に解消できる場合があったとして、
その対策をすることで当然多くの場合はデメリットがあるんですけど、
デメリットがなさそうなら現場で担当者に相談をして適応しちゃうっていうのもあるし、
18:04
ちょっとヤバそうかなっていう時は一旦持ち帰って社内で検討したりすることもあります。
そこでデメリットがなさそうかどうかの判断っていうのが結構重要で、
これしくると大変なことになるんですよね。
解消できない場合、その場でパッと解消できない場合は対応策を考えるんですけど、
大体2つぐらいあって、宿体運転で何とかならんかってまず考えます。
宿体運転っていうのは機能制限をして何とか持ちこたえさせるみたいな感じで、
レスポンスが悪いんですけど動きますとか、
ログインするまでの待ち時間が今までの3倍なんですけどそのうちログインできますとか、
っていうような形でギリギリ行きながらえさせるような状況にするっていうのが宿体運転です。
どうしても宿体運転もできんってなった場合には、
何とか解消するまで人海戦術で大体できへんかとかっていうのも検討したりします。
人海戦術、総力戦ってことですよね。
機械、要はシステムがやってる処理を人間がやります。
要は一時的にいろんな部署からいっぱい人かき集めて無理くり何とかする。
それが必要かどうかっていうのも状況によって必要だったり必要じゃなかったりするんですけど、
そういうところの判断もしなきゃいけなくなります。
例えば地方自治体とかのシステムでいついつまでにこれこれの資料を全部出さないといけないとかっていうときに、
システム飛んだわってなったらあとは人が手でやるしかないみたいな。
そういうようなこともいろいろ考えなあかんなあっていう状況になったりもします。
っていうようなところで一通りなんとなく私が解決するまでにこういうことを考えるよっていうのを説明したんですけど、
そもそも論が一個あって、
システムを導入するときにいろんな場所がトラブったときにどう対応するかを最初から決めておくっていうのがすごい重要で、
だいたいの場合にこれが決まってないから保守をする人がいきなり電話で呼び出されて大変な目を見るんです。
なので導入するときに対応を決めておきましょう。
対応を決める中ですっごいクリティカルなそいつがお亡くなりになったらどうしようもないですみたいなところはもう2つ準備しとくと。
性能は十分というか性能半分ずつで足りるんやけどもう2台準備しとくとか、
21:03
2台は準備できひんのであれば最初から人海戦術で対応できるようなマニュアルを作っておくとかっていうので、
私としてはトラブったときに困らないように事前に考えておくっていうのが一番のトラブル対策だと思いますので、
皆さんそのように考えていけばいいのではないでしょうか。
なおまさきは私生活については全くできていない様子です。
お後がよろしいようで。
仕事は相手のあることだけど自分のことは自分がいいやと思ってれば済んじゃうからね。
そうなんです。もういいやってなっちゃうんで、できてないです。
コールありがとうございます。
この番組では皆様からのお便りを募集しています。
Xの番組アカウントの概要欄にあるGoogleフォームよりお寄せください。
番組アカウントは全て小文字で、
アットマークTOKUO、アンダーバーNO、アンダーバーOTOです。
アットマーク特応ノートで覚えてください。
コーナー企画へのお便りや番組で取り扱ってほしいテーマ、普通他も大募集しています。
皆様振ってご参加ください。
というわけで今回の特応ノートはほぼ全編まさきでした。
お聞きくださりありがとうございました。
お相手はリケートオクラボラジオ部のいつも通り無謀なまさきと、
カリウムと、
かずででした。
さようなら。
次回もお楽しみに。
