実行した後では後戻りできない。

Enterキーをたたいて、コマンドを実行する前に、入力した文字列を指差し確認しろ。

特にrootの時。
特に普段使わないコマンドの時。
特に忙しい時、眠い時、急ぎたい時。

自信がなければ、面倒でも戻ってmanを見て調べろ。

壊れてから復旧させる苦労と心労を考えれば、実行前の時間などたいした事はない。

そして最後に、もう一回、深呼吸してEnterキーを押せ。

mvやcp先は同じファイル名にするなら、必ず「.(ドット)」を付けろ。ドットを省略するな。

特にmv元が「*」の複数指定なら必ず付けろ。

mv先にドットを付けずに曖昧に表現すると、同一ファイル名にどんどん上書きされるぞ。

10個のファイルをmvしたつもりが、mv先では最後の１個だけしかない事態になるぞ。

cpなら元ファイルがあるが、mvは元ファイルがなくなっているので、復旧できなくなるぞ。cpでもドットを付けて、ドットを付ける癖をつけておけ。

rootではなるだけ、「.」「*」といった曖昧な表現は使うな。面倒くさくても、ひとつずつコピーせよ。

元ファイルが不要ならmvではなく、cpしてrmしろ。

rootでmvを使う危険性を忘れるな。

良い例)
mv ./* dir/.
cp ./* dir/.

悪い例)
mv ./* dir/
cp ./* dir/

障害の原因のほとんどは直前に行った作業が原因だ。

ノートに作業記録を残せ。

記憶は曖昧ですぐに、思い出せなくなる。

作業記録を残さないと障害の原因がわからず、復旧作業が困難になる。

また、作業記録は同様の作業時の手順書にもなる。

慣れれば慣れるほど、ついroot作業である事を忘れ、一般ユーザ気分になる注意しろ。

いくつも別の端末を開いていると、rootで作業をしている事を忘れがちになる。

初心者SEはなるだけテスト機や壊れても自分たちだけの被害で済むような端末を用意し、本番機でコマンドを実行する前に、テスト機でコマンドの動きを試せ。

完璧にやろうとするな。

設定に何か疑問があっても、表面上、動いているのなら設定は変えるな。

時間があるときに原因を調べろ。動いているなら急ぐ必要はない。

設定を変えるなら、テスト環境をテスト機上に作って、確かめ、原因を調査してから、設定変更しろ。

シュートカットやtcsh等など、便利な機能は仕事を速くするが、「コンソールでは使えない」事があるぞ。

コンソールを使うような状況はトラブルの場合が多い。

普段の慣れた機能が使えず、コンソールを使えこなせなくてはトラブル時のSEとしては役に立たないぞ。

パソコンLinuxのコンソールでは分からないだろうが、パソコンのような小さな装置ではなく、メーカー独自の大型装置の場合はコンソールの機能は最小限。

トラブル時には使える機能が低下しているからあえてそうなっている（Windowsで言えば、セーフモードのようなものだ）。

単純な機能を使うのは不便だが、使いこなせる事はトラブル対応をするSEには必須だぞ。

不便な事は単純であり、ミスも少ないというメリットもあるぞ。

便利に慣れすぎるな！

障害が起きたら、現場に行って自分の目で確認しろ。

「ネットワークに繋がらない」という障害時に、お客が「ケーブルは抜けてない」と言っても、抜けている事は多々ある。

他人から聞いた情報には嘘があると思って、参考程度にとどめ、自分の目でひとつずつ確かめろ。

結局それが近道だ。

面倒くさくてもmanを読め。

調査の時には、まず、マニュアルを探せ、そして読め。

わからないと思うな！

わからないという先入観にとらわれて、分かる事も分からなくなる。

あと少しで今日中に終わりそうなら、明日やれ。

もしその帰り際の最後の作業でミスったら、結局それまでの仕事がパーだ。

もし、そのやろうとした事が、復旧作業の必要なミスだったら、深夜や徹夜でやるよりも、頭もすっきり体力にも余裕のある朝からやった方が良いに決まっているんだから、最後の作業は明日やった方がメリットが多いぞ。

明日が納期でないのなら、明日できる事は明日やれ。

どうしても原因がわからない。どうしても、設定がうまくいかない。

なら、今日は帰って寝ろ。

椅子に座って考えて分からない事は、椅子に座り続けても分からないぞ。

寝ようとしたら、寝て起きたら、ふと、一番簡単な単純な解決策を見落としている事を思いつくぞ。

違った行動をする事がきっかけで、頭の中も違った視点に切り替わるもんだぞ。